MIRC Administrator's Manual
This article describes the administration of a MIRC site running the RSNA MIRC implementation, with the exception of those features specifically used by clinical trials, which are described in a separate article.
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.
- 1 Installation
- 2 Addressing Modes
- 3 The mirc.xml File
- 4 The storage.xml File
- 5 The Storage Service Index File
- 6 The Standard Templates
- 7 The File Service
- 8 The Admin Service
- 9 The Case of the Day
- 10 System-Level Services
- 11 MIRC URL Index
- 12 Protected Health Information
- 13 Appendix: System Block Diagram
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 button. The result will be a page as shown below.
7.3 Configuring the DICOM Service
The File Service has its own DICOM Service which receives DICOM objects, optionally anonymizes them, and places them in the shared file cabinet.
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 a separate article.
To enable the anonymizer, select yes in the Anonymizer Enabled field.
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 Configuring the Garbage Collector
To simplify the management of the shared file cabinet, the File Service has a garbage collector that automatically removes files older than a specified timeout. Set the timeout in the Shared File Cabinet Timeout (hours) field. A typical value is 48 hours. If the timeout is set to zero, the garbage collector is disabled and files remain in the shared file cabinet until they are manually deleted.
7.6 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.7 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.
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.