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 System-level Modes
There are two operating modes which cannot be changed during operation of the system:
- the system mode
- the addressing mode
Both modes are defined in the Query Service's configuration file, which is located in Tomcat/webapps/mirc/mirc.xml. At the top of the file is a DOCTYPE declaration containing several entities:
<!DOCTYPE mirc [
<!ENTITY mode "rad">
<!ENTITY sitename "P4">
<!ENTITY addresstype "dynamic">
<!ENTITY siteurl "http://192.168.0.96:8080">
<!ENTITY queryurl "&siteurl;/mirc">
<!ENTITY storageurl "&siteurl;/mircstorage">
<!ENTITY mircforum "http://forums.rsna.org/forumdisplay.php?forumid=9">
<!ENTITY mircdocs "http://mircwiki.rsna.org">
<!ENTITY radlex "http://mirc.rsna.org/radlex/service">
<!ENTITY tcusersclass "org.rsna.mircsite.util.TomcatUsersXmlFileImpl">
<!ENTITY acctenb "yes">
<!ENTITY defroles "SS-user,SS-author">
<!ENTITY gpenb "yes">
<!ENTITY version "T29alpha"> ]>
2.1 Setting the System Mode
The system mode is defined by the mode entity. The currently supported modes are:
- rad: radiology
- vet: veterinary medicine
The choice of system mode configures the enumerated values for sexes, races, species, and breeds. These parameters, among many others, are stored in the root directory of the Query Service in a file named enumerated-values.xml.
The software is preconfigured for rad mode. To change to vet mode, it is necessary to edit the mirc.xml file with a text editor and change the value of the mode entity.
2.2 Setting the Addressing Mode
The IP address for a MIRC site can be chosen when the MIRC software is initially installed. The installer does not provide an option to change the address or the means by which it is obtained when the software is upgraded. When a server is moved on the network, it may be necessary to reconfigure the IP address after installation.
2.2.1 Dynamic vs. Static IP Addressing
The MIRC software must know its IP address in order to handle queries and document accesses properly. The Query Service configuration file contains two parameters which together determine either the IP address itself or the way the address is obtained. In no case does the value of the IP address actually affect the IP address of the host machine; it only affects the IP addresses used for communication between services on the site and those returned to users in query results.
The way the MIRC software obtains the IP address is determined by the addresstype entity. The entity can have two possible values, dynamic or static. If the value is dynamic, the software obtains the IP address from the operating system. In most cases, this is the preferred method, whether the host computer has a fixed IP address or obtains its address from a DHCP server. If the host system contains multiple network adapters, however, the service may not obtain the address of the desired adapter, so static addressing is required.
If the value of the addresstype entity is static, the software obtains the IP address from the siteurl entity. The siteurl entity can contain a numeric IP address or a domain name address.
If dynamic addressing is used, the IP address specified in the siteurl entity must be numeric, or the method which obtains the IP address from the operating system will refuse to overwrite it.
During the initial installation, the installer asks the administrator to choose the type of addressing. During upgrades, however, there is no option to change it.
2.2.2 Reconfiguring the IP Address
To change the IP addressing method after installatio of the system, change the value of the addresstype entity using a text editor. If static addressing is employed, put the static IP address of the host in the value of the siteurl entity.
Important: The protocol and port fields in the siteurl entity are always used, even in the case of dynamic addressing, so they must be set correctly in all cases.
If an alphabetic value is inserted in the IP address field of the siteurl entity, the system will use that value for addressing and not obtain an IP address from the operating system, even if dynamic addressing is selected.
2.3 Restarting the System
After changing the system mode or the addressing mode, it is necessary to restart Tomcat in order to force the init methods of the MIRC servlets to run and reload the new enumerated values and/or IP address.
3 The storage.xml File
4 The Storage Service Index File
The storage service maintains a list of its active documents in a file descirbed in a separate article.
5 The Standard Templates
6 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.
6.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.
6.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.
6.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.
After changing the configuration of the DICOM Service, you must first click the Update fileservice.xml button to save the changes, and then click the Start/restart the DICOM Service button to make the DICOM Service recognize them.
6.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 configuration and 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.
6.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 age. 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.
6.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.
6.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 or the garbage collector can delete those files.