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

From MircWiki
Jump to navigation Jump to search
Line 16: Line 16:
 
The configuration of a CTP instance is specified by an XML file called <tt><b>config.xml</b></tt>. See [[CTP-The RSNA Clinical Trial Processor]] for detailed information about pipelines, pipeline stages, plugins, and the general processing model of the program.  
 
The configuration of a CTP instance is specified by an XML file called <tt><b>config.xml</b></tt>. 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.
+
This article presents a combined configuration file example including both of the research use cases, but it should be understood that the configuration can be reduced to include only one use case when required.
  
In all the configurations shown below, the server is put on port 80, and SSL is not enabled for access to the server itself, although communication with the Clearinghouse is always secure.
+
In the configuration shown below, the server is put on port 80, and SSL is not enabled for access to the server itself, although communication with the Clearinghouse is always secure.
 
==Configuration File for the Research Sender==
 
The 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.  
 
  
In this configuration, all the stages except the CachingXDSExportService are standard CTP stages. They are all documented in [[CTP-The RSNA Clinical Trial Processor]].
+
==The Configuration File==
 
+
This configuration example includes the separate pipelines for the research sender and research receiver:
Note: The DicomDecompressor and DicomPixelAnonymizer stages in this configuration can be removed if PHI is known not to be burned into the pixels. If the DicomPixelAnonymizer is in the pipeline, the DicomDecompressor must also be present, and it must appear in the sequence shown below.
 
 
<pre>
 
<pre>
<Configuration>
+
<Configuration log="yes">
 
+
    <Server port="80"
  <Server port="80" />
+
    keystore="keystore.jks"
 
+
    keystorePassword="edge1234"
  <Pipeline name="Research Sender Pipeline">
+
    truststore="truststore.jks"
 
+
    truststorePassword="edge1234"/>
 +
    <Pipeline name="Sender">
 
         <DicomImportService
 
         <DicomImportService
             name="DicomImportService-RS"
+
             calledAETTag="00120010"
 
             class="org.rsna.ctp.stdstages.DicomImportService"
 
             class="org.rsna.ctp.stdstages.DicomImportService"
             root="roots/DicomImportService-RS"  
+
             logConnections="rejected"
             port="104"
+
             name="DicomImportService"
             calledAETTag="00097770"  
+
             port="1081"
             callingAETTag="00097772"
+
             quarantine="quarantines/Transmitter/DicomImportService"
             logConnections="no"
+
             root="roots/Transmitter/DicomImportService"
            suppressDuplicates="no"
+
    servletContext="export" />
            quarantine="quarantines/DicomImportService-RS" />
 
 
 
 
         <ObjectCache
 
         <ObjectCache
 
             name="ObjectCache-RS"
 
             name="ObjectCache-RS"
 
             class="org.rsna.ctp.stdstages.ObjectCache"
 
             class="org.rsna.ctp.stdstages.ObjectCache"
 
             id="ObjectCache-RS"
 
             id="ObjectCache-RS"
             root="roots/ObjectCache-RS" />
+
             root="roots/Transmitter/ObjectCache-RS" />
 
 
 
         <DicomAnonymizer
 
         <DicomAnonymizer
            name="DicomAnonymizer-RS"
 
 
             class="org.rsna.ctp.stdstages.DicomAnonymizer"
 
             class="org.rsna.ctp.stdstages.DicomAnonymizer"
            root="roots/DicomAnonymizer-RS"
 
 
             lookupTable="scripts/lookup-table.properties"
 
             lookupTable="scripts/lookup-table.properties"
             script="scripts/dicom-anonymizer.script"
+
             name="DicomAnonymizer"
             quarantine="quarantines/DicomAnonymizer-RS" />
+
             quarantine="quarantines/Transmitter/DicomAnonymizer"
 
+
             root="roots/Transmitter/DicomAnonymizer"
        <DicomDecompressor
+
             script="scripts/Transmitter.script"/>
            name="DicomDecompressor-RS"
 
            class="org.rsna.ctp.stdstages.DicomDecompressor"
 
             root="roots/DicomDecompressor-RS"
 
            quarantine="quarantines/DicomDecompressor-RS" />
 
 
 
        <DicomPixelAnonymizer
 
            name="DicomPixelAnonymizer-RS"
 
            class="org.rsna.ctp.stdstages.DicomPixelAnonymizer"
 
            root="roots/DicomPixelAnonymizer-RS"  
 
             script="scripts/DicomPixelAnonymizer.script"
 
            quarantine="quarantines/DicomPixelAnonymizer-RS" />
 
 
 
 
         <CachingXDSExportService
 
         <CachingXDSExportService
 +
            servletContext="xds-export"
 
             name="CachingXDSExportService-RS"
 
             name="CachingXDSExportService-RS"
 
             class="org.rsna.isn.ctp.xds.sender.CachingXDSExportService"
 
             class="org.rsna.isn.ctp.xds.sender.CachingXDSExportService"
             root="roots/CachingXDSExportService-RS"
+
             root="roots/Transmitter/CachingXDSExportService-RS"
             cacheID="ObjectCache-RS"
+
             objectCacheID="ObjectCache-RS"
            servletContext="researchsender"
 
 
             minAge="300"
 
             minAge="300"
 
             timeDepth="30"
 
             timeDepth="30"
 +
    iti8Pix="mllps://clearinghouse.lifeimage.com:8888"
 +
    iti8Reg="mllps://clearinghouse.lifeimage.com:8890"
 +
    iti41="https://clearinghouse.lifeimage.com/services/xdsrepositoryb"
 +
    iti41SrcId="1.3.6.1.4.1.19376.2.840.1.1.2.1"
 +
    timeout="120000"
 +
            quarantine="quarantines/Transmitter/CachingXDSExportService-RS">
  
             ...more attributes, once we know what they are...
+
             <Destination
 
+
            name="Trial 1"
            quarantine="quarantines/CachingXDSExportService-RS" />
+
            key="871d2ec562ce294726451492eb90430e8245f55763e1b0ad199c074029cbc420" />
  
 +
        </CachingXDSExportService>
 
     </Pipeline>
 
     </Pipeline>
 
+
    <Pipeline name="Receiver">
 +
<PollingXDSImportService
 +
    name="PollingXDSImportService-RR"
 +
    class="org.rsna.isn.ctp.xds.receiver.PollingXDSImportService"
 +
    root="roots/Receiver/PollingXDSImportService-RR"
 +
    interval="60"
 +
    rad69URL="https://clearinghouse.lifeimage.com/ImagingDocumentSource_Service?wsdl"
 +
    registryURL="https://clearinghouse.lifeimage.com/services/xdsregistryb"
 +
    repositoryURL="https://clearinghouse.lifeimage.com/services/xdsrepositoryb"
 +
    repositoryUniqueID="rsna.domain.repository"
 +
    assigningAuthorityUniversalID="1.3.6.1.4.1.19376.2.840.1.1.1.1"
 +
    assigningAuthorityUniversalIDType="ISO"
 +
    homeCommunityID="rsna.domain&lt;/HomeCommunityId"
 +
    siteID="871d2ec562ce294726451492eb90430e8245f55763e1b0ad199c074029cbc420"
 +
    imagesPerRequest="100"
 +
    servletContext="xds-import" />
 +
        <Processor
 +
            name="ObjectLogger-RR"
 +
            class="org.rsna.ctp.stdstages.ObjectLogger"
 +
            interval="1"
 +
            verbose="yes" />
 +
        <FileStorageService
 +
            class="org.rsna.ctp.stdstages.FileStorageService"
 +
            name="FileStorageService"
 +
            port="1086"
 +
            quarantine="quarantines/Receiver/FileStorageService"
 +
            root="roots/Receiver/FileStorageService"/>
 +
  </Pipeline>
 
</Configuration>
 
</Configuration>
 
</pre>
 
</pre>
 +
==The Server Element==
 +
The <b><tt>Server</tt></b> element specifies the port of the web server. It also allows the specification of the keystore and truststore files. In the Imasge Sharing Network (ISN), these are special files and their names and passwords must be supplied.
 +
 +
==The Research Sender Pipeline==
 +
The Research Sender Pipeline configuration 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.
 +
 +
In this configuration, all the stages except the CachingXDSExportService are standard CTP stages. They are all documented in [[CTP-The RSNA Clinical Trial Processor]].
 +
 +
Note: The DicomDecompressor and DicomPixelAnonymizer stages can be added to this pipeline if PHI is burned into the pixels of images received for transmission. If the DicomPixelAnonymizer is in the pipeline, the DicomDecompressor must also be present, and it must precede the DicomPixelAnonymizer.
  
 
===CachingXDSExportService===
 
===CachingXDSExportService===
Line 97: Line 120:
 
*<b>timeDepth</b> specifies the length of time in days that studies are stored. The default value is <b>0</b>, which means forever. If timeDepth is greater than zero, studies older than that value are automatically removed from the cache, making them no longer available for export.
 
*<b>timeDepth</b> specifies the length of time in days that studies are stored. The default value is <b>0</b>, which means forever. If timeDepth is greater than zero, studies older than that value are automatically removed from the cache, making them no longer available for export.
  
===CachingXDSExportService Servlet API===
+
====The Destination Element====
 +
The CachingXDSExportService must have at least one Destination child element specifying both a name and key for the destination on the Clearinghouse.
 +
 
 +
====The CachingXDSExportService Servlet====
 
The servlet provided by the CachingXDSExportService is installed on the CTP servlet container at the context specified by the servletContext attribute. The servlet provides the following APIs:
 
The servlet provided by the CachingXDSExportService is installed on the CTP servlet container at the context specified by the servletContext attribute. The servlet provides the following APIs:
  
* <b><tt>/{servletContext}</tt></b> - GET returns an HTML page containing a form for selection of studies and destinations.
+
* <b><tt>/{servletContext}</tt></b> - GET returns an HTML page containing a form for selection of studies and destinations. The page also lists the studies that have already been transmitted and shows their status (number of images transmitted, total size of the study, success or failure of the transmission).
 
* <b><tt>/{servletContext}</tt></b> - POST accepts a completed form and returns a new HTML page.
 
* <b><tt>/{servletContext}</tt></b> - POST accepts a completed form and returns a new HTML page.
  
* <b><tt>/{servletContext}/ES</tt></b> - GET returns an HTML page like the one above, but with styles consistent with those of the Edge Server.
+
==The Research Receiver Pipeline==
* <b><tt>/{servletContext}/ES</tt></b> - POST accepts a completed form and returns a new HTML page.
+
The Research Receiver Pipeline polls the Clearinghouse for submission sets, imports them, and passes the objects down the pipe. In the configuration shown above, the same key is used for both sending and receiving, so o
 
 
* <b><tt>/{servletContext}/status</tt></b> - returns an XML structure encapsulating the status of all studies in the cache.
 
* <b><tt>/{servletContext}/status/notdone</tt></b> - returns an XML structure encapsulating the status of studies in the cache that do not have the <tt>done</tt> status.
 
* <b><tt>/{servletContext}/status?study={StudyInstanceUID}</tt></b> - returns an XML structure encapsulating the status of the specified study.
 
 
 
A status response is returned with Content-Type: <tt><b>text/xml;charset=UTF-8</b></tt>. The schema is in the form:
 
 
 
<pre>
 
<Status>
 
 
 
<Study
 
status="incomplete|complete|intransit|done"
 
size="number of cached objects"
 
destination="..."
 
patientName="..."
 
patientID="..."
 
studyInstanceUID="..."
 
noOfObjectsSent="n"/>
 
 
...more <Study> elements as necessary...
 
 
</Status>
 
</pre>
 
 
 
==Configuration File for the Research Receiver==
 
The configuration shown below polls the Clearinghouse for submission sets, imports them, and passes the objects down the pipe.  
 
 
 
<pre>
 
<Configuration>
 
 
 
  <Server port="80" />
 
 
 
  <Pipeline name="Research Receiver Pipeline">
 
 
 
        <PollingXDSImportService
 
            name="PollingXDSImportService-RR"
 
            class="org.rsna.isp.PollingXDSImportService"
 
            root="roots/PollingXDSImportService-RR"
 
            interval="300"
 
           
 
            rad69URL="..."
 
            registryURL="..."
 
            repositoryURL="..."
 
            repositoryUniqueID="..."
 
            assigningAuthorityUniversalId="..."
 
            assigningAuthorityUniversalIdType="..."
 
           
 
            homeCommunityId="..."
 
           
 
            keystore="..."
 
            keystorepassword="..."
 
            truststore="..."
 
            truststorepassword="..."
 
           
 
            siteID="..."
 
            servletContext="xds" />
 
 
 
        <DicomExportService
 
            name="DicomExportService-RR"
 
            class="org.rsna.ctp.stdstages.DicomExportService"
 
            root="roots/DicomExportService-RR"
 
            quarantine="quarantines/DicomExportService-RR"
 
            url="dicom://DestinationAET:ThisAET@ipaddress:port" />
 
 
 
    </Pipeline>
 
 
 
</Configuration>
 
</pre>
 
  
 
===PollingXDSImportService===
 
===PollingXDSImportService===
 
The special attributes of the PollingXDSImportService are:
 
The special attributes of the PollingXDSImportService are:
 
*<b>root</b> is a directory within which the PollingXDSImportService stores its import queue.
 
*<b>root</b> is a directory within which the PollingXDSImportService stores its import queue.
*<b>interval</b> specifies the sleep time in seconds between polls of the Clearinghouse. The default value is <b>60</b>. Thye minimum accepted value is <b>60</b>.
+
*<b>interval</b> specifies the sleep time in seconds between polls of the Clearinghouse. The default value is <b>60</b>. The minimum accepted value is <b>60</b>.
*<b>siteID</b> specifies the key or keys on which to poll the Clearinghouse. See the notes below for details.
+
*<b>siteID</b> specifies the key on which to poll the Clearinghouse. See the notes below for details.
 
*<b>servletContext</b> specifies the context of a servlet that provides a user interface allowing a user to manually enter a key to import a submission set. The purpose of the servletContext attribute is to allow each PollingXDSImportService to have its own servlet in cases where multiple import pipelines are present in the same CTP instance.
 
*<b>servletContext</b> specifies the context of a servlet that provides a user interface allowing a user to manually enter a key to import a submission set. The purpose of the servletContext attribute is to allow each PollingXDSImportService to have its own servlet in cases where multiple import pipelines are present in the same CTP instance.
  
Line 184: Line 142:
 
* The siteID can be specified as either a single key or a series of keys separated by semicolons.
 
* The siteID can be specified as either a single key or a series of keys separated by semicolons.
 
* The PollingXDSImportService polls on each key in turn, importing all the submission sets that are available. It then sleeps for the specified interval and then polls again.
 
* The PollingXDSImportService polls on each key in turn, importing all the submission sets that are available. It then sleeps for the specified interval and then polls again.
* All submission sets imported by a single PollingXDSImportService will flow down its pipe, so unless two clinical trials are sending their data to the same DICOM destination, it is best to put each trial in its own pipe, giving each PollingXDSImportService only a single key.
+
* All submission sets imported by a single PollingXDSImportService will flow down its pipe, so unless two clinical trials are sending their data to the same DICOM destination, it is best to put each trial in its own pipe.

Revision as of 14:08, 28 August 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 Project 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 a combined configuration file example including both of the research use cases, but it should be understood that the configuration can be reduced to include only one use case when required.

In the configuration shown below, the server is put on port 80, and SSL is not enabled for access to the server itself, although communication with the Clearinghouse is always secure.

1 The Configuration File

This configuration example includes the separate pipelines for the research sender and research receiver:

<Configuration log="yes">
    <Server port="80"
    	keystore="keystore.jks"
    	keystorePassword="edge1234"
    	truststore="truststore.jks"
    	truststorePassword="edge1234"/>
    <Pipeline name="Sender">
        <DicomImportService
            calledAETTag="00120010"
            class="org.rsna.ctp.stdstages.DicomImportService"
            logConnections="rejected"
            name="DicomImportService"
            port="1081"
            quarantine="quarantines/Transmitter/DicomImportService"
            root="roots/Transmitter/DicomImportService"
	    servletContext="export" />
        <ObjectCache
            name="ObjectCache-RS"
            class="org.rsna.ctp.stdstages.ObjectCache"
            id="ObjectCache-RS"
            root="roots/Transmitter/ObjectCache-RS" />
        <DicomAnonymizer
            class="org.rsna.ctp.stdstages.DicomAnonymizer"
            lookupTable="scripts/lookup-table.properties"
            name="DicomAnonymizer"
            quarantine="quarantines/Transmitter/DicomAnonymizer"
            root="roots/Transmitter/DicomAnonymizer"
            script="scripts/Transmitter.script"/>
        <CachingXDSExportService
            servletContext="xds-export"
            name="CachingXDSExportService-RS"
            class="org.rsna.isn.ctp.xds.sender.CachingXDSExportService"
            root="roots/Transmitter/CachingXDSExportService-RS"
            objectCacheID="ObjectCache-RS"
            minAge="300"
            timeDepth="30"
	    iti8Pix="mllps://clearinghouse.lifeimage.com:8888"
	    iti8Reg="mllps://clearinghouse.lifeimage.com:8890"
	    iti41="https://clearinghouse.lifeimage.com/services/xdsrepositoryb"
	    iti41SrcId="1.3.6.1.4.1.19376.2.840.1.1.2.1"
	    timeout="120000"
            quarantine="quarantines/Transmitter/CachingXDSExportService-RS">

            <Destination
            	name="Trial 1"
            	key="871d2ec562ce294726451492eb90430e8245f55763e1b0ad199c074029cbc420" />

        </CachingXDSExportService>
    </Pipeline>
    <Pipeline name="Receiver">
	<PollingXDSImportService
	    name="PollingXDSImportService-RR"
	    class="org.rsna.isn.ctp.xds.receiver.PollingXDSImportService"
	    root="roots/Receiver/PollingXDSImportService-RR"
	    interval="60"
	    rad69URL="https://clearinghouse.lifeimage.com/ImagingDocumentSource_Service?wsdl"
	    registryURL="https://clearinghouse.lifeimage.com/services/xdsregistryb"
	    repositoryURL="https://clearinghouse.lifeimage.com/services/xdsrepositoryb"
	    repositoryUniqueID="rsna.domain.repository"
	    assigningAuthorityUniversalID="1.3.6.1.4.1.19376.2.840.1.1.1.1"
	    assigningAuthorityUniversalIDType="ISO"
	    homeCommunityID="rsna.domain</HomeCommunityId"
	    siteID="871d2ec562ce294726451492eb90430e8245f55763e1b0ad199c074029cbc420"
	    imagesPerRequest="100"
	    servletContext="xds-import" />
        <Processor
            name="ObjectLogger-RR"
            class="org.rsna.ctp.stdstages.ObjectLogger"
            interval="1"
            verbose="yes" />
        <FileStorageService
            class="org.rsna.ctp.stdstages.FileStorageService"
            name="FileStorageService"
            port="1086"
            quarantine="quarantines/Receiver/FileStorageService"
            root="roots/Receiver/FileStorageService"/>
   </Pipeline>
</Configuration>

2 The Server Element

The Server element specifies the port of the web server. It also allows the specification of the keystore and truststore files. In the Imasge Sharing Network (ISN), these are special files and their names and passwords must be supplied.

3 The Research Sender Pipeline

The Research Sender Pipeline configuration 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.

In this configuration, all the stages except the CachingXDSExportService are standard CTP stages. They are all documented in CTP-The RSNA Clinical Trial Processor.

Note: The DicomDecompressor and DicomPixelAnonymizer stages can be added to this pipeline if PHI is burned into the pixels of images received for transmission. If the DicomPixelAnonymizer is in the pipeline, the DicomDecompressor must also be present, and it must precede the DicomPixelAnonymizer.

3.1 CachingXDSExportService

The special attributes of the CachingXDSExportService are:

  • root is a directory within which the CachingXDSExportService caches objects and stores its indexing information.
  • cacheID specifies the ID of an ObjectCache stage that may be accessed by the CachingXDSExportService to obtain pre-anonyization information so it can index the objects by their PHI and make that information available to a user who accesses the servlet. If the cacheID attribute is not supplied, the CachingXDSExportService indexes the objects by the anonymized values.
  • servletContext specifies the context of a servlet that provides a user interface allowing as user to select cached studies and assign them destinations for export. The purpose of the servletContext attribute is to allow each CachingXDSExportService to have its own servlet in cases where multiple export pipelines are present in the same CTP instance.
  • minAge is the minimum age in seconds which defines the completion of a study. When the last object received for a study is at least minAge old, the study is considered complete and is available for selection for export. The default value is 300; the minimum accepted value is 60.
  • timeDepth specifies the length of time in days that studies are stored. The default value is 0, which means forever. If timeDepth is greater than zero, studies older than that value are automatically removed from the cache, making them no longer available for export.

3.1.1 The Destination Element

The CachingXDSExportService must have at least one Destination child element specifying both a name and key for the destination on the Clearinghouse.

3.1.2 The CachingXDSExportService Servlet

The servlet provided by the CachingXDSExportService is installed on the CTP servlet container at the context specified by the servletContext attribute. The servlet provides the following APIs:

  • /{servletContext} - GET returns an HTML page containing a form for selection of studies and destinations. The page also lists the studies that have already been transmitted and shows their status (number of images transmitted, total size of the study, success or failure of the transmission).
  • /{servletContext} - POST accepts a completed form and returns a new HTML page.

4 The Research Receiver Pipeline

The Research Receiver Pipeline polls the Clearinghouse for submission sets, imports them, and passes the objects down the pipe. In the configuration shown above, the same key is used for both sending and receiving, so o

4.1 PollingXDSImportService

The special attributes of the PollingXDSImportService are:

  • root is a directory within which the PollingXDSImportService stores its import queue.
  • interval specifies the sleep time in seconds between polls of the Clearinghouse. The default value is 60. The minimum accepted value is 60.
  • siteID specifies the key on which to poll the Clearinghouse. See the notes below for details.
  • servletContext specifies the context of a servlet that provides a user interface allowing a user to manually enter a key to import a submission set. The purpose of the servletContext attribute is to allow each PollingXDSImportService to have its own servlet in cases where multiple import pipelines are present in the same CTP instance.

Notes:

  • The siteID can be specified as either a single key or a series of keys separated by semicolons.
  • The PollingXDSImportService polls on each key in turn, importing all the submission sets that are available. It then sleeps for the specified interval and then polls again.
  • All submission sets imported by a single PollingXDSImportService will flow down its pipe, so unless two clinical trials are sending their data to the same DICOM destination, it is best to put each trial in its own pipe.