Difference between revisions of "MIRC Administrator's Manual"

From MircWiki
Jump to: navigation, search
Line 1: Line 1:
=== The Architecture of the RSNA MIRC Implementation ===
 
 
The RSNA MIRC implementation meets all the requirements for participation in a MIRC community. It also includes many other features not required by MIRC but desirable for the integration of MIRC into teaching institutions, institutions participating in clinical trials, etc.  
 
The RSNA MIRC implementation meets all the requirements for participation in a MIRC community. It also includes many other features not required by MIRC but desirable for the integration of MIRC into teaching institutions, institutions participating in clinical trials, etc.  
  
Line 6: Line 5:
 
This article describes the architecture of the RSNA MIRC implementation in some detail, starting with a block diagram showing all the key servlets:
 
This article describes the architecture of the RSNA MIRC implementation in some detail, starting with a block diagram showing all the key servlets:
 
[[Image:RsnaMircBlockDiagram-1.GIF]]
 
[[Image:RsnaMircBlockDiagram-1.GIF]]
====Installation====
+
==Installation==
=====Addressing Modes=====
+
==Addressing Modes==
=====Setting the System Mode=====
+
===Setting the System Mode===
====The mirc.xml File====
+
==The mirc.xml File==
====The storage.xml File====
+
==The storage.xml File==
====The Storage Service Index File====
+
==The Storage Service Index File==
 
The storage service maintains a list of its active documents in a file descirbed in a [[The Storage Service Index File|separate article]].
 
The storage service maintains a list of its active documents in a file descirbed in a [[The Storage Service Index File|separate article]].
====The Standard Templates====
+
==The Standard Templates==
====The Admin Service====
+
==The File Service==
=====Autoindexing=====
+
This section describes how to configure the File Service. The File Service provides personal file cabinets and a shared file cabinet that has a DICOM Storage SCP for receiving DICOM objects from modalities, workstations, and PACS.
=====The Case of the Day=====
+
===Controlling Access to the File Service===
====System-Level Services====
+
Each authenticated user who has the FS-user role is provided a personal file cabinet which only that user can access. In addition, all authenticated users with the FS-user role can access the shared file cabinet. Only users with the FS-admin role can access the File Service admin page and configure the File Service.
=====User Role Manager=====
+
===Accessing the File Service Admin Page===
=====Log Viewer=====
+
To access the admin service, go to the query page for the site, select the storage service in the list at the top of the query pane, and click the “Admin Service” button on the right side of the window.
=====Controller=====
+
 
====MIRC URL Index====
+
On the Admin page, click the <b>File Service Admin<b> button. The result will be a page as shown below.
=====Protected Health Information=====
+
===Configuring the DICOM Service===
 +
The File Service has its own DICOM Service. Release T24 contains a DICOM Storage SCP which receives DICOM objects, optionally anonymizes them, and places them in the shared file cabinet. When the IHE Teaching Files and Clinical Trials Export Integration Profile is released, the File Service will be extended to support it.
 +
 
 +
To change the Application Entity Title or port of the DICOM SCP, change the values on the admin page. These values must not conflict with those of other DICOM SCPs running on the MIRC site. Each Storage Service also has a DICOM SCP. The default values provided with the installation do not collide with one another, but if you make changes or if you have multiple Storage Services running on the system, care is necessary. The AE Title and port for each Storage Service’s DICOM Service is shown on the Storage Service’s admin page.
 +
If you want the DICOM Service to start automatically when the MIRC site is initialized, select “yes” in the “Autostart” field.
 +
===Configuring the Anonymizer===
 +
The DICOM Service has its own copy of the MIRC Anonymizer and its own copy of the anonymization scripts. This allows each DICOM Service to anonymize according to its own specific rules. The Anonymizer Configurator is accessed by clicking the “Update the Anonymizer” button. The operation of the Anonymizer Configurator is described in “How to Configure the Anonymizer for MIRC Clinical Trial Services” on the RSNA MIRC site.
 +
To enable the anonymizer, select “yes” in the “Anonymizer Enabled” field.
 +
 +
<b>Important Note:</b> If the anonymizer is not enabled, DICOM objects will be placed in the shared file cabinet without modification. Accesses to objects in the shared file cabinet are not logged because it is not possible to know whether an object in a file cabinet contains PHI (since it may have been anonymized before it was sent). The scripts provided with the standard installation anonymize an image in a reasonable and practical way, but some institutions have more stringent rules than others, and it is prudent to review the scripts to ensure that they meet your requirements.
 +
===Saving Configuration Changes===
 +
To save the changes you have made to the configuration, click the “Update fileservice.xml” button. Changes do not become effective until they are saved.
 +
 
 +
Anonymizer script changes are saved on the Anonymizer Configurator and do not require a separate button click on the admin page.
 +
===Starting the DICOM Service===
 +
If the Autostart field contains “yes”, the DICOM Service is started when Tomcat starts and the MIRC site is initialized. If the Autostart field does not contain “yes”, you can start the DICOM Service by clicking the “Start/Restart the DICOM Service” button.
 +
Caution: Whenever you make changes to the DICOM Service configuration, you must save those changes by clicking the “Update fileservice.xml” button before you start or restart the DICOM Service; otherwise, the changes will be lost. If you change the AE Title or port, you must restart the DICOM Service to cause the SCP to change its parameters.
 +
===Managing the Shared File Cabinet===
 +
Users who do not possess the FS-admin role are allowed to delete any files in their personal file cabinet, but only those files in the shared file cabinet that they added to it. Users who possess the FS-admin role can any delete files from the shared file cabinet.
 +
The DICOM service does not assign an owner to the files it places in the shared file cabinet. Thus, only the administrator can delete those files.
 +
 
 +
==The Admin Service==
 +
===Autoindexing===
 +
==The Case of the Day==
 +
==System-Level Services==
 +
===User Role Manager===
 +
===Log Viewer===
 +
===Controller===
 +
==MIRC URL Index==
 +
==Protected Health Information==

Revision as of 16:55, 10 July 2006

The RSNA MIRC implementation meets all the requirements for participation in a MIRC community. It also includes many other features not required by MIRC but desirable for the integration of MIRC into teaching institutions, institutions participating in clinical trials, etc.

The RSNA MIRC implementation is based on the Apache Tomcat servlet container. A servlet container can be thought of as a web server that knows how to run Java programs called servlets. A group of related servlets is called a webapp. The RSNA MIRC implementation is essentially a collection of webapps, one for the query service, one for each storage service installed on the server, one for a file service, and one for server-level administration functions.

This article describes the architecture of the RSNA MIRC implementation in some detail, starting with a block diagram showing all the key servlets:

Error creating thumbnail: Unable to save thumbnail to destination

1 Installation

2 Addressing Modes

2.1 Setting the System Mode

3 The mirc.xml File

4 The storage.xml File

5 The Storage Service Index File

The storage service maintains a list of its active documents in a file descirbed in a separate article.

6 The Standard Templates

7 The File Service

This section describes how to configure the File Service. The File Service provides personal file cabinets and a shared file cabinet that has a DICOM Storage SCP for receiving DICOM objects from modalities, workstations, and PACS.

7.1 Controlling Access to the File Service

Each authenticated user who has the FS-user role is provided a personal file cabinet which only that user can access. In addition, all authenticated users with the FS-user role can access the shared file cabinet. Only users with the FS-admin role can access the File Service admin page and configure the File Service.

7.2 Accessing the File Service Admin Page

To access the admin service, go to the query page for the site, select the storage service in the list at the top of the query pane, and click the “Admin Service” button on the right side of the window.

On the Admin page, click the File Service Admin<b> button. The result will be a page as shown below.

7.3 Configuring the DICOM Service

The File Service has its own DICOM Service. Release T24 contains a DICOM Storage SCP which receives DICOM objects, optionally anonymizes them, and places them in the shared file cabinet. When the IHE Teaching Files and Clinical Trials Export Integration Profile is released, the File Service will be extended to support it.

To change the Application Entity Title or port of the DICOM SCP, change the values on the admin page. These values must not conflict with those of other DICOM SCPs running on the MIRC site. Each Storage Service also has a DICOM SCP. The default values provided with the installation do not collide with one another, but if you make changes or if you have multiple Storage Services running on the system, care is necessary. The AE Title and port for each Storage Service’s DICOM Service is shown on the Storage Service’s admin page. If you want the DICOM Service to start automatically when the MIRC site is initialized, select “yes” in the “Autostart” field.

7.4 Configuring the Anonymizer

The DICOM Service has its own copy of the MIRC Anonymizer and its own copy of the anonymization scripts. This allows each DICOM Service to anonymize according to its own specific rules. The Anonymizer Configurator is accessed by clicking the “Update the Anonymizer” button. The operation of the Anonymizer Configurator is described in “How to Configure the Anonymizer for MIRC Clinical Trial Services” on the RSNA MIRC site. To enable the anonymizer, select “yes” in the “Anonymizer Enabled” field.

<b>Important Note: If the anonymizer is not enabled, DICOM objects will be placed in the shared file cabinet without modification. Accesses to objects in the shared file cabinet are not logged because it is not possible to know whether an object in a file cabinet contains PHI (since it may have been anonymized before it was sent). The scripts provided with the standard installation anonymize an image in a reasonable and practical way, but some institutions have more stringent rules than others, and it is prudent to review the scripts to ensure that they meet your requirements.

7.5 Saving Configuration Changes

To save the changes you have made to the configuration, click the “Update fileservice.xml” button. Changes do not become effective until they are saved.

Anonymizer script changes are saved on the Anonymizer Configurator and do not require a separate button click on the admin page.

7.6 Starting the DICOM Service

If the Autostart field contains “yes”, the DICOM Service is started when Tomcat starts and the MIRC site is initialized. If the Autostart field does not contain “yes”, you can start the DICOM Service by clicking the “Start/Restart the DICOM Service” button. Caution: Whenever you make changes to the DICOM Service configuration, you must save those changes by clicking the “Update fileservice.xml” button before you start or restart the DICOM Service; otherwise, the changes will be lost. If you change the AE Title or port, you must restart the DICOM Service to cause the SCP to change its parameters.

7.7 Managing the Shared File Cabinet

Users who do not possess the FS-admin role are allowed to delete any files in their personal file cabinet, but only those files in the shared file cabinet that they added to it. Users who possess the FS-admin role can any delete files from the shared file cabinet. The DICOM service does not assign an owner to the files it places in the shared file cabinet. Thus, only the administrator can delete those files.

8 The Admin Service

8.1 Autoindexing

9 The Case of the Day

10 System-Level Services

10.1 User Role Manager

10.2 Log Viewer

10.3 Controller

11 MIRC URL Index

12 Protected Health Information