Difference between revisions of "MIRC Pipelines"

From MircWiki
Jump to navigation Jump to search
Line 104: Line 104:
 
The <b><tt>fsNameTag</tt></b> attribute of the <b><tt>StorageService</tt></b> element specifies a DICOM element from which to  obtain a username. If the element exists in the object received by the stage, and if the value of the element corresponds to a MIRC user's username, the StorageService places the object in the user's file cabinet. If the element is missing or if it does not correspond to a MIRC user, then the object is placed in the Shared File Cabinet.
 
The <b><tt>fsNameTag</tt></b> attribute of the <b><tt>StorageService</tt></b> element specifies a DICOM element from which to  obtain a username. If the element exists in the object received by the stage, and if the value of the element corresponds to a MIRC user's username, the StorageService places the object in the user's file cabinet. If the element is missing or if it does not correspond to a MIRC user, then the object is placed in the Shared File Cabinet.
  
If you decide to change the location in which the Called AET is stored, you must change it in both stages; otherwise, all objects will go to the Shared File Cabinet.
+
If you decide to change the location in which the Called AET is stored, you must change it in both the ImportService and StorageService stages; otherwise, all objects will go to the Shared File Cabinet.

Revision as of 12:34, 25 April 2011

This article describes the pipelines used in the CTP MIRC plug-in to implement various DICOM and HTTP functions. It is intended for administrators configuring or upgrading their systems. This article does not apply to the Tomcat MIRC version.

MIRC is implemented as a plug-in to CTP. Most of the functionality is provided through servlets that the plug-in inserts into the CTP servlet container, but certain asynchronous functions are deployed as CTP pipelines. A CTP pipeline is a sequence of processing steps called pipeline stages. Pipelines start with one or more ImportServices that receive data objects from outside the program and queue them for processing by subsequent stages.

1 The CTP config.xml File

Pipelines are defined in the CTP/config.xml file. A default configuration is provided when the system is first installed. Subsequent upgrades do overwrite this file. Thus, changes to this file will not be lost.

A graphical editor for this file is planned, but for now, if you wish to reconfigure the pipelines, you must edit the file with a text editor. If you choose to do so, you may wish to refer to the CTP article that describes all the standard stages, CTP-The RSNA Clinical Trial Processor.

Editing an XML file must be done carefully to keep it well-formed. If you are not familiar with XML, this article may be helpful, XML Primer.

The standard MIRC config.xml file is shown below:

<Configuration>
    <Server port="80"/>
    <Plugin
        class="mirc.MIRC"
        name="MIRC Site"
        root="mircsite"/>
    <Pipeline name="File Service Pipeline">
        <ImportService
            calledAETTag="00120010"
            class="org.rsna.ctp.stdstages.DicomImportService"
            logConnections="rejected"
            name="File Service DicomImportService"
            port="1081"
            quarantine="quarantines/FileService/DicomImportService"
            root="roots/FileService/DicomImportService"/>
        <Anonymizer
            class="org.rsna.ctp.stdstages.DicomAnonymizer"
            lookupTable="scripts/lookup-table.properties"
            name="File Service DicomAnonymizer"
            quarantine="quarantines/FileService/DicomAnonymizer"
            root="roots/FileService/DicomAnonymizer"
            script="scripts/FileService/MircFileServiceAnonymizer.script"/>
        <StorageService
            class="mirc.stages.MircFileStorageService"
            fsNameTag="00120010"
            name="MircFileStorageService"
            quarantine="quarantines/FileService/MircFileStorageService"
            root="roots/FileService/MircFileStorageService"/>
    </Pipeline>
    <Pipeline name="DICOM Service Pipeline">
        <ImportService
            class="org.rsna.ctp.stdstages.DicomImportService"
            logConnections="rejected"
            name="DICOM Service DicomImportService"
            port="1082"
            quarantine="quarantines/DicomService/DicomImportService"
            root="roots/DicomService/DicomImportService"/>
        <Anonymizer
            class="org.rsna.ctp.stdstages.DicomAnonymizer"
            lookupTable="scripts/lookup-table.properties"
            name="DICOM Service DicomAnonymizer"
            quarantine="quarantines/DicomService/DicomAnonymizer"
            root="roots/DicomService/DicomAnonymizer"
            script="scripts/DicomServiceAnonymizer.script"/>
        <StorageService
            class="mirc.stages.MircDocumentStorageService"
            name="MircFileStorageService"
            ssid="ss1"
            quarantine="quarantines/DicomService/MircDocumentStorageService"
            root="roots/DicomService/MircFileStorageService"/>
    </Pipeline>
    <Pipeline name="TCE Service Pipeline">
        <ImportService
            class="org.rsna.ctp.stdstages.DicomImportService"
            logConnections="rejected"
            name="TCE Service DicomImportService"
            port="1083"
            quarantine="quarantines/TCEService/DicomImportService"
            root="roots/TCEService/DicomImportService"/>
        <ImportService
            class="org.rsna.ctp.stdstages.HttpImportService"
            logConnections="rejected"
            name="TCE Service HttpImportService"
            port="1084"
            quarantine="quarantines/TCEService/HttpImportService"
            root="roots/TCEService/HttpImportService"/>
        <StorageService
            class="mirc.stages.TCEStorageService"
            name="TCEStorageService"
            ssid="ss1"
            quarantine="quarantines/TCEService/TCEStorageService"
            root="roots/TCEService/TCEStorageService"/>
    </Pipeline>
</Configuration>

The meanings of all the attributes is described in the article referenced above. In this article the intent is to describe the flexibility you have in configuring this file.

2 The MIRC Plug-in

The root attribute of the MIRC Plugin element specifies the root directory under which the entire MIRC site is located. This is the parent directory, for example, of all the storage libraries that contain teaching file cases. The default configuration places this directory under the CTP directory. You can change this attribute to point to any directory visible to the system. If you move it outside the CTP directory tree, however, you must include an absolute path to the desired directory. In the config.xml file, relative paths are always relative to the CTP directory.

3 The File Service Pipeline

The File Service Pipeline provides a DICOM Storage SCP to receive images from DICOM Storage SCUs, anonymize them, and store them in the File Service's file cabinets.

The port attribute of the ImportService element specifies the port on which the SCP listens for connections. You may change it to any unused port on your system.

The calledAETTag attribute of the ImportService element specifies a DICOM element tag in which to store the Called Application Entity Title (AET). This is used to provide a way for the sending application to specify a username for the file cabinet. For example, if the DICOM association includes the Called AET admin, that name will be stored in the element identified by the calledAETTag attribute. This makes the value available to subsequent stages, as described below. The default value of the calledAETTag attribute is an element in the group 0012, the group reserved for clinical trials data.

the Anonymizer element provides a DICOM anonymizer initially configured to use the DICOM Supplement 142 Basic De-identification Profile. The anonymizer script can be edited graphically through the Admin menu on the MIRC main page. See The CTP DICOM Anonymizer and The CTP DICOM Anonymizer Configurator for more information. If you do not want to anonymize objects received for storage in the file cabinets, you can remove this element (and have your head examined).

The fsNameTag attribute of the StorageService element specifies a DICOM element from which to obtain a username. If the element exists in the object received by the stage, and if the value of the element corresponds to a MIRC user's username, the StorageService places the object in the user's file cabinet. If the element is missing or if it does not correspond to a MIRC user, then the object is placed in the Shared File Cabinet.

If you decide to change the location in which the Called AET is stored, you must change it in both the ImportService and StorageService stages; otherwise, all objects will go to the Shared File Cabinet.