Difference between revisions of "CTP Configuration for the Image Sharing Project"

From MircWiki
Jump to navigation Jump to search
Line 17: Line 17:
 
   
 
   
 
==Configuration File for the Research Sender==
 
==Configuration File for the Research Sender==
The example configuration shown below assumes that unanonymized DICOM data objects are transmitted to CTP by an external application using the DICOM protocol. The objects are anonymized, removing PHI from both the text elements and the pixels. The objects are then cached until a user manually selects the study and assigns a definition, after which they are exported to the clearing house.  
+
The example configuration shown below assumes that unanonymized DICOM data objects are transmitted to CTP by an external application using the DICOM protocol. The objects are anonymized, removing PHI from both the text elements and the pixels. The objects are then cached until a user manually selects the study and assigns a destination, after which they are exported to the clearing house.  
 
<pre>
 
<pre>
 
<Configuration>
 
<Configuration>

Revision as of 14:02, 3 July 2012

++++++++++++++++++++ UNDER CONSTRUCTION ++++++++++++++++++++++++++

This article describes how the CTP application can be configured for use in the RSNA Image Sharing Project. This article is intended for Image Sharing Projerct developers. There are several CTP articles on the RSNA MIRC wiki. All would be useful references when reading this article.

The Image Sharing Project is separated into two main use cases, one for the transfer of images for clinical use and one for transfer of anonymized research data. Each use case has a sender and a receiver.

  • The clinical sender is completely contained in the Edge Server and does not involve CTP.
  • The clinical receiver has two alternative configurations, one using both the Edge Server and CTP and the other using CTP stand-alone.
  • The research sender uses both the Edge Server and CTP together.
  • The research receiver uses CTP stand-alone.

The configuration of a CTP instance is specified by an XML file called config.xml. See CTP-The RSNA Clinical Trial Processor for detailed information about pipelines, pipeline stages, plugins, and the general processing model of the program. This article presents separate configuration file examples for each of the use cases, but it should be understood that the configurations can be combined when multiple use cases are served by the same CTP instance.

1 Configuration File for the Research Sender

The example configuration shown below assumes that unanonymized DICOM data objects are transmitted to CTP by an external application using the DICOM protocol. The objects are anonymized, removing PHI from both the text elements and the pixels. The objects are then cached until a user manually selects the study and assigns a destination, after which they are exported to the clearing house.

<Configuration>

   <Server port="80" />

   <Pipeline name="Source Pipeline">

        <ImportService 
            name="DicomImportService"
            class="org.rsna.ctp.stdstages.DicomImportService"
            root="roots/DicomImportService" 
            port="104"
            calledAETTag="00097770" 
            callingAETTag="00097772"
            logConnections="no"
            suppressDuplicates="no"
            quarantine="quarantines/DicomImportService" />

         <Processor
            name="ObjectCache"
            class="org.rsna.ctp.stdstages.ObjectCache"
            id="ObjectCacheID"
            root="roots/ObjectCache" />

        <Anonymizer
            name="DicomAnonymizer"
            class="org.rsna.ctp.stdstages.DicomAnonymizer"
            root="roots/DicomAnonymizer" 
            lookupTable="scripts/lookup-table.properties"
            script="scripts/dicom-anonymizer.script"
            quarantine="quarantine-directory" />

        <StorageService
            name="DirectoryStorageService"
            cacheID="ObjectCacheID"
            class="org.rsna.ctp.stdstages.DirectoryStorageService"
            root="roots/DirectoryStorageService"
            structure="(0010,0020)/[00080050]/0020,000D"
            quarantine="quarantines/DirectoryStorageService" />

    </Pipeline>

</Configuration>

1.1 Server

The configuration file above places the CTP admin web server on port 80.

1.2 DicomImportService

The configuration file puts the DicomImportService on port 104.

The DicomImportService is configured not to log connections (whether rejected or not), and not to log duplicate objects that are received.

The CalledAET and CallingAET are being stored in group 0009 for future use.

1.3 ObjectCache

The ObjectCache is required in order to make the unanonymized values available to the DirectoryStorageService for use in defining the storage hierarchy.

The cacheID attribute is critical in this configuration. It provides a way for the DirectoryStorageService to find the ObjectCache stage and obtain the cached object containing the unanomymized values.

1.4 DicomAnonymizer

The configurtion file specifies the use of the same anonymization script for all objects. This can be used for testing, but for a production system handling multiple trials, a change to the DicomAnonymizer stage will be made to allow the script file to be selected based on the contents of an element. The intent is that the element will be populated by the DicomImportService based on the contents of the CalledAET or CallingAET, both of which are bering stored in group 0009 in the configuration above.

1.5 DirectoryStorageService

The structure attribute is configured to construct a hierarchy consisting of: PatientID/AccessionNumber/StudyInstanceUID. Files are stored by SOPInstanceUID, with no extension (e.g., .dcm).

The cacheID attribute is critical in this configuration. It identifies the ObjectCache from which to obtain the unanonymized object.

The returnStoredFile attribute is not included in this configuration. Its default is yes, meaning that the object passed to the next stage will point to the stored object. Since there is no next stage, this doesn't affect the flow of the pipe, but the default is used just to make the status page show the location in the store of the last object stored.

2 Configuration File for the Image Receiver

The Image Receiver polls the clearinghouse for images.

<Configuration>

   <Server port="80" />

   <Pipeline name="Source Pipeline">

        <PollingXDSImportService
            name="PollingXDSImportService"
            class="org.rsna.isp.PollingXDSImportService"
            root="roots/PollingXDSImportService" 
            
            rad69URL="..."
            registryURL="..."
            repositoryURL="..."
            repositoryUniqueID="..."
            assigningAuthorityUniversalId="..."
            assigningAuthorityUniversalIdType="..."
            
            homeCommunityId="..."
            
            keystore="..."
            keystorepassword="..."
            truststore="..."
            truststorepassword="..."
            
            siteID="..."
            servletContext="xds" />

        <DicomExportService
            name="DicomExportService"
            class="org.rsna.ctp.stdstages.DicomExportService"
            root="roots/DicomExportService" 
            quarantine="quarantines/DicomExportService"
            url="dicom://DestinationAET:ThisAET@ipaddress:port" />

    </Pipeline>

</Configuration>