MIRC CTP

This article describes the stand-alone processing application for clinical trials data using MIRC components and the MIRC internet transport mechanism.

1 Background

MIRC supports clinical trials through two applications, one for data acquisition at an imaging center (FieldCenter) and one for management of the data at a principal investigator's site (MIRC).

The FieldCenter application acquires images via the DICOM protocol, anonymizes them, and transfers them (typically using HTTP, although DICOM is also supported) to a principal investigator's MIRC site. It also supports other types of data files and includes an anonymizer for XML files as well. FieldCenter also contains a client for the Update Service of a MIRC site, allowing the application to save data on, and obtain software updates from, the principal investigator's site.

The MIRC site software contains a partially configurable processing pipeline for clinical trials data, consisting of:

HttpImportService

A receiver for HTTP connections from FieldCenter applications transferring data files into the processing pipeline.

DicomImportService

A receiver form DICOM datasets for insertion into the processing pipeline.

Preprocessor

A user-defined component for processing data received by the HttpImportService before it is further processed by other components.

Anonymizer

A component for anonymizing DICOM objects or XML objects.

DatabaseExportService

A component providing queue management and submission of data objects to a user-defined interface to an external database management system.

HttpExportService

A component in the DicomImportService pipeline providing queue management and transmission of data objects to one or more external systems using the HTTP protocol.

DicomExportService

A component in the HttpImportService pipeline providing queue management and transmission of data objects to one or more external systems using the DICOM protocol.

The processing pipelines for the HttpImportService and DicomImportService are different. They are not symmetrical. For example, the HttpImportService does not have access to the anonymizer except as part of the DatabaseExportService. Another limitation is that objects received via one protocol can only be exported via the other. While these limitations are consistent with the requirements of most trials, it became clear that a more general design would provide better support for trials requiring complex processing while still satisfying the normal requirements.

2 ClinicalTrialProcessor (CTP)

ClinicalTrialProcessor is a stand-alone program that provides all the processing features of a MIRC site for clinical trials in a highly configurable and extensible application. It connects to FieldCenter applications and can also connect to MIRC sites when necessary. ClinicalTrialProcessor has the following key features:

1. Single-click installation.
2. Support for multiple pipelines.
3. Processing pipelines supporting multiple configurable stages.
4. Support for multiple quarantines for data objects which are rejected during processing.
5. Pre-defined implementations for key components:
   • HTTP Import
   • DICOM Import
   • DICOM Anonymizer
   • XML Anonymizer
   • File Storage
   • Database Export
   • HTTP Export
   • DICOM Export
6. Web-based monitoring of the application's status, including:
   • configuration
   • logs
   • quarantines
   • status

2.1 Installation

The installer for ClinicalTrialProcessor is available on the RSNA MIRC site. To run the installer, the Java 1.5 (or better) JRE must be present on the system.

To run the installer, double-click the CTP-installer.jar file and choose a directory in which to install the program. The installer can also be run in a command window using the command:

java -jar CTP-installer.jar

To run the ClinicalTrialProcessor program, the Java Advanced Imaging ImageIO Tools must be present on the system. Java and all its components are available on the java.sun.com website. When obtaining the ImageIO Tools, pay close attention to the fact that the Java Advanced Imaging component is not the same as the Java Advanced Imaging ImageIO Tools. Only the latter are required.

The ClinicalTrialProcessor has no user interface. It can be run by double-clicking the CTP.jar file, or it can be run in a command window. To do so, open a command window, navigate to the directory in which the program was installed, and enter the command:

java -jar CTP.jar

When the program starts, it runs without intervention. Status and other information can be obtained through the program's integrated webserver. Accessing the server with no path information displays a page presenting buttons for each of the servlets. Accessing the server with the path /shutdown stops the program.

The program uses two configurable files: config.xml, which is located in the same directory as the program itself, and index.html, which is located in the server's ROOT directory. Both files are intended to be configured for the specific application. The installer does not overwrite these files when it runs; instead, it installs two example files: example-config.xml and example-index.html. When ClinicalTrialProcessor starts, it looks to see if the non-example files are missing, and if so, it copies the example files into the non-example ones. This process allows upgrades to be done without losing any configuration work. After installing the program the first time, it should be run once in order to make the copies, and then the copies can be configured. Configuration is done by hand with any text editor (e.g., TextPad or NotePad). Care should be taken, especially with config.xml, to keep it well-formed. Opening it with a program like InternetExplorer will check it for errors.

2.2 Pipelines

A pipeline is a manager that moves data objects through a sequence of processing stages. Each stage in the pipeline performs a specific function on one or more of the four basic object types supported by MIRC:

• FileObject
• DicomObject
• XmlObject
• ZipObject

Each pipeline must contain one ImportService as its first stage. Each pipeline stage may be provided access to a quarantine directory into which the stage places objects that it rejects, thus aborting further processing. Quarantine directories may be unique to each stage or shared with other stages. At the end of the pipeline, the manager calls the ImportService to remove the object from its queue.

There are four types of pipeline stages. Each is briefly described in subsections below.

2.2.1 ImportService

An ImportService receives objects via a protocol and enqueues them for processing by subsequent stages.

2.2.2 StorageService

A StorageService stores an object in a file system. It is not queued, and it therefore must complete before subsequent stages can proceed. A StorageService may return the current object or the stored object in response to a request for the output object, depending on its implementation.

2.2.3 Processor

A Processor performs some kind of processing on an object. Processors are not intended to be queued. In the context of the current MIRC implementation, a Preprocessor is a Processor, as is an Anonymizer. The result of a processing stage is an object that is passed to the next stage in the pipeline.

2.2.4 ExportService

An ExportService provides queued transmission to an external system via a defined protocol. Objects in the queue are full copies of the objects submitted; therefore, subsequent processing is not impeded if a queue is paused, and modifications made subsequently do not affect the queue entry, even if they occur before transmission. (Note: This behavior is different from that of the current MIRC implementation.) After entering an object in its queue, an ExportService returns immediately.

2.3 Configuration

The ClinicalTrialProcessor configuration is specified by an XML file called config.xml located in the same directory as the program. There can be one Server element specifying the port on which the HTTP server is to operate, and multiple Pipeline elements, each specifying the stages which comprise it. The name of the element defining a stage is irrelevant and can be chosen for readability; each stage in a pipeline is actually defined by its Java class, specified in the class attribute. Stages are loaded automatically when the program starts, and the loader tests the stage's class to determine what kind of stage it represents. It is possible to extend the application beyond the pre-defined stages available in the implementation as described in Extending ClinicalTrialProcessor.

The following is an example of a simple configuration with one pipeline which receives objects via the HTTP protocol, stores them, and exports them to a DICOM destination:

<Configuration>
   <Server port="80" />
   <Pipeline name="Main Pipeline">
        <ImportService 
            name="HTTP Import"
            class="org.rsna.ctp.stdstages.HttpImportService"
            root="roots/http-import" 
            port="7777" />
        <StorageService
            name="Storage"
            class="org.rsna.ctp.stdstages.FileStorageService"
            root="D:/storage" 
            return-stored-file="no"
            quarantine="quarantines/StorageServiceQuarantine" />
        <ExportService
            name="PACS Export"
            class="org.rsna.ctp.stdstages.DicomExportService"
            root="roots/pacs-export" 
            url="dicom://DestinationAET:ThisAET@ipaddress:port" />
   </Pipeline>
</Configuration>

Note that in the example above, non-DICOM objects are stored in the StorageService, but they are not exported by the DicomExportService. Each pipeline stage is responsible for testing the class of the object which it receives and processing (or ignoring) the object accordingly.

The following is an example of a more complex configuration. This configuration receives objects, passes them to a trial-specific Processor stage to test whether they are appropriate for the trial, anonymizes objects which make it through the preprocessor, exports them to a database, anonymizes them again to remove information which is not intended for storage, then stores them and exports them to a PACS.

<Configuration>
   <Server port="80" />
   <Pipeline name="Main Pipeline">
        <ImportService 
            name="HTTP Import"
            class="org.rsna.ctp.stdstages.HttpImportService"
            root="roots/http-import" 
            port="7777" />
        <Processor
            name="The Preprocessor"
            class="org.myorg.MyPreprocessor"
            quarantine="quarantines/PreprocessorQuarantine" />
        <Processor
            name="Main Anonymizer"
            class="org.rsna.ctp.stdstages.Anonymizer"
            root="roots/main-anonymizer" 
            dicom-script="dicom-anonymizer-1.properties"
            xml-script="xml-anonymizer-1.script" 
            zip-script="zip-anonymizer-1.script"
            quarantine="quarantines/MainAnonymizerQuarantine" />
        <ExportService
            name="Database Export"
            class="org.rsna.trials.DatabaseExportService"
            adapter-class="org.myorg.MyDatabaseAdapter"
            root="roots/database-export" />
        <Processor
            name="Provenance Remover"
            class="org.rsna.ctp.stdstages.Anonymizer"
            dicom-script="dicom-anonymizer-2.properties"
            root="roots/provenance-remover" 
            xml-script="xml-anonymizer-2.script" 
            zip-script="zip-anonymizer-2.script"
            quarantine="quarantines/ProvenanceRemoverQuarantine" />
        <StorageService
            name="Storage"
            class="org.rsna.ctp.stdstages.FileStorageService"
            root="D:/storage" 
            return-stored-file="no" />
         <ExportService
            name="PACS Export"
            class="org.rsna.ctp.stdstages.DicomExportService"
            root="roots/pacs-export" 
            url="dicom://DestinationAET:ThisAET@ipaddress:port" />
    </Pipeline>
</Configuration>

Multiple Pipeline elements may be included, but each must have its own ImportService element, and their ports must not conflict.

Each pipeline stage class has a constructor that is called with its configuration element, making it possible for special processor implementations to be passed additional parameters from the configuration. See Implementing a Pipeline Stage for details.

2.4 Server

To provide access to the status of the components, the application includes an HTTP server which serves files and provides servlet-like functionality. Files are served from a directory tree whose root is named ROOT. The ROOT directory contains a file, index.html, which provides buttons which link to several servlets providing information about the operation of the program. This file is intended to be configured with logos, additional links, etc., and upgrades do not overwrite it. The standard servlets are:

• ConfigurationServlet displays the contents of the configuration file.
• StatusServlet displays the status of all pipeline stages.
• LogServlet provides web access to all log files in the logs directory.
• QuarantineServlet provides web access to all quarantine directories and their contents.
• SysPropsServlet displays the Java system properties.
• DicomAnonymizerServlet allows the user to configure any DICOM anonymizers in the pipelines.

2.5 Standard Stages

The application includes several built-in, standard stages which allow most trials to be operated without writing any software. The sections below show all the configuration attributes recognized by the standard stages.

Attributes which specify directories can contain either absolute paths (e.g., D:/TrialStorage) or relative paths (e.g., quarantines/http-import-quarantine). Relative paths are relative to the directory in which the ClinicalTrialProcessor is located.

Most standard stages have attributes which determine which object types are to be accepted by the stage. These attributes are:

• acceptDicomObjects
• acceptXmlObjects
• acceptZipObjects
• acceptFileObjects

The allowed values are "yes" and "no. The default value for all these attributes is "yes". The DicomImportService and DicomExportService, which are both restricted to DicomObjects, ignore the values of these attributes.

If a standard ImportService receives an object which it is not configured to accept, it quarantines the object, or if no quarantine has been defined for the stage, it discards the object.

If a Processor, StorageService, or ExportService receives an object that it is not configured to accept, it either ignores the object or passes it unmodified to the next pipeline stage. Thus, if an anonymizer which is not configured to anonymize XmlObjects receives an XmlObject, it passes the object on without anonymization.

2.5.1 HttpImportService

The HttpImportService listens on a defined port for HTTP connections from FieldCenter applications and receives files transmitted using the HTTP protocol with Content-Type equal to application/x-mirc. The configuration element for the HttpImportService is:

        <ImportService 
            name="stage name"
            class="org.rsna.ctp.stdstages.HttpImportService"
            root="root-directory"
            port="7777"
            ssl="yes"
            acceptDicomObjects="yes"
            acceptXmlObjects="yes"
            acceptZipObjects="yes"
            acceptFileObjects="yes" 
            quarantine="quarantine-directory" />

where:

• name is any text to be used as a label on configuration and status pages.
• root is a directory for use by the ImportService for internal storage and queuing.
• port is the port on which the ImportService listens for connections.
• ssl determines whether the port uses secure sockets layer (yes) or unencrypted http (no).
• acceptDicomObjects determines whether DicomObjects are to be enqueued when received.
• acceptXmlObjects determines whether XmlObjects are to be enqueued when received.
• acceptZipObjects determines whether ZipObjects are to be enqueued when received.
• acceptFileObjects determines whether FileObjects are to be enqueued when received.
• quarantine is a directory in which the ImportService is to quarantine objects that it receives but is configured not to accept.

2.5.2 PollingHttpImportService

The PollingHttpImportService obtains files by initiating HTTP connections to an external system. This ImportService is designed to work in conjunction with the PolledHttpExportService to allow penetration of a firewall without having to open an inbound port, as described in Security Issues. The configuration element for the PollingHttpImportService is:

        <ImportService 
            name="stage name"
            class="org.rsna.ctp.stdstages.PollingHttpImportService"
            root="root-directory"
            url="http://ip:port"
            acceptDicomObjects="yes"
            acceptXmlObjects="yes"
            acceptZipObjects="yes"
            acceptFileObjects="yes" 
            quarantine="quarantine-directory" />

where:

• name is any text to be used as a label on configuration and status pages.
• root is a directory for use by the ImportService for internal storage.
• url is the URL of the PolledHttpExportService.
• acceptDicomObjects determines whether DicomObjects are to be enqueued when received.
• acceptXmlObjects determines whether XmlObjects are to be enqueued when received.
• acceptZipObjects determines whether ZipObjects are to be enqueued when received.
• acceptFileObjects determines whether FileObjects are to be enqueued when received.
• quarantine is a directory in which the ImportService is to quarantine objects that it receives but is configured not to accept.

Note: The protocol part of the url can be http or https, the latter causing connections to be initiated using secure sockets layer.

2.5.3 DicomImportService

The DicomImportService listens on a defined port for HTTP connections from FieldCenter applications and receives files transmitted using the DICOM protocol. The configuration element for the DicomImportService is:

        <ImportService 
            name="stage name"
            class="org.rsna.ctp.stdstages.DicomImportService"
            root="root-directory" 
            ae-title="AE Title"
            port="port number" />

where:

• name is any text to be used as a label on configuration and status pages.
• root is a directory for use by the ImportService for internal storage and queuing.
• ae-title is the Application Entity Title of the ImportService's DICOM Storage SCP.
• port is the port on which the ImportService listens for connections.

2.5.4 Anonymizer

The Anonymizer is a processor stage that includes anonymizers for each of the object types which contain defined data. When the anonymizer stage is called to process an object, it calls the anonymizer which is appropriate to the object type. Each anonymizer is configured with a script file. If a script file is either not configured or absent for an object type, objects of that type are returned unmodified. The configuration element for the Anonymizer is:

        <Anonymizer
            name="stage name"
            class="org.rsna.ctp.stdstages.Anonymizer"
            root="root-directory" 
            acceptDicomObjects="yes"
            acceptXmlObjects="yes"
            acceptZipObjects="yes"
            lookup-table="lookup-table.properties"
            dicom-script="dicom-anonymizer.properties"
            xml-script="xml-anonymizer.script" 
            zip-script="zip-anonymizer.script"
            quarantine="quarantine-directory" />

where:

• name is any text to be used as a label on configuration and status pages.
• root is a directory for use by the Anonymizer for temporary storage.
• acceptDicomObjects determines whether DicomObjects are to be anonymized.
• acceptXmlObjects determines whether XmlObjects are to be anonymized.
• acceptZipObjects determines whether ZipObjects are to be anonymized.
• lookup-table specifies the path to the lookup table used by the anonymizer.
• dicom-script specifies the path to the script for the DICOM anonymizer.
• xml-script specifies the path to the script for the DICOM anonymizer.
• zip-script specifies the path to the script for the Zip anonymizer (which anonymizes the manifest in a ZipObject).
• quarantine is a directory in which the Anonymizer is to quarantine objects that generate quarantine calls during processing.

Notes:

1. Any object which is accepted but for which no script has been defined is quarantined. If no quarantine has been defined for the stage, the object is passed on unmodified.
2. Since FileObjects do not contain formatted information, the anonymizer does not modify such objects.
3. If the lookup-table attribute is missing, the lookup anonymizer function is disabled.

2.5.5 FileStorageService

The FileStorageService stores objects in a file system. It automatically defines subdirectories beneath its root directory and populates them accordingly. The configuration element for the StorageService is:

        <StorageService
            name="stage name"
            class="org.rsna.ctp.stdstages.FileStorageService"
            root="D:/storage" 
            acceptDicomObjects="yes"
            acceptXmlObjects="yes"
            acceptZipObjects="yes"
            acceptFileObjects="yes" 
            return-stored-file="yes"
            quarantine="quarantine-directory" />

where:

• name is any text to be used as a label on configuration and status pages.
• root is the root directory of the storage tree.
• acceptDicomObjects determines whether DicomObjects are to be stored.
• acceptXmlObjects determines whether XmlObjects are to be stored.
• acceptZipObjects determines whether ZipObjects are to be stored.
• acceptFileObjects determines whether FileObjects are to be stored.
• return-stored-file specifies whether the original object or a new object pointing to the file in the storage system is to be returned for processing by subsequent stages. Values are "yes" and "no". The default is "yes".
• quarantine is a directory in which the StorageService is to quarantine objects that cannot be stored.

Notes:

1. Files are stored in a tree of directories with the root of the tree as defined in the root attribute of the configuration element.
2. Below the root are directories organized by year and month, e.g. "2007/09".
3. Below a month directory are directories organized by StudyInstanceUID, thus grouping all objects received for a specific study together in one directory.
4. Objects are stored with standard file extensions:
   • .dcm for DicomObjects
   • .xml for XmlObjects
   • .zip for ZipObjects
   • .md for FileObjects
5. Any object not containing a StudyInstanceUID or StudyUID is stored in the month's bullpen directory.

2.5.6 HttpExportService

The HttpExportService queues objects and transmits them via HTTP with Content-Type application/x-mirc. The configuration element for the HttpExportService is:

        <ExportService
            name="stage name"
            class="org.rsna.ctp.stdstages.HttpExportService"
            root="root-directory" 
            url="http://ipaddress:port/path"
            acceptDicomObjects="yes"
            acceptXmlObjects="yes"
            acceptZipObjects="yes"
            acceptFileObjects="yes"
            interval="10000" />

where:

• name is any text to be used as a label on configuration and status pages.
• root is a directory for use by the ExportService for internal storage and queuing.
• url specifies the destination system's URL.
• acceptDicomObjects determines whether DicomObjects are to be exported.
• acceptXmlObjects determines whether XmlObjects are to be exported.
• acceptZipObjects determines whether ZipObjects are to be exported.
• acceptFileObjects determines whether FileObjects are to be exported.
• interval is the sleep time (in milliseconds) between polls of the export queue.

Notes:

• The default interval is 10 seconds. The minimum allowed value is one second. The maximum allowed value is 20 seconds.
• The protocol part of the url can be http or https, the latter causing connections to be initiated using secure sockets layer.

2.5.7 PolledHttpExportService

The PolledHttpExportService queues objects and transmits them in the HTTP response stream of a received connection. Files are transmitted with Content-Type equal to application/x-mirc. This ExportService is designed to work in conjunction with the PollingHttpImportService to allow penetration of a firewall without having to open an inbound port, as described in Security Issues. The configuration element for the Polled HttpExportService is:

        <ExportService
            name="stage name"
            class="org.rsna.ctp.stdstages.PolledHttpExportService"
            root="root-directory" 
            port="listening-port"
            ssl="yes"
            acceptDicomObjects="yes"
            acceptXmlObjects="yes"
            acceptZipObjects="yes"
            acceptFileObjects="yes" />

where:

• name is any text to be used as a label on configuration and status pages.
• root is a directory for use by the ExportService for internal storage and queuing.
• port is the port on which the ExportService listens for connections.
• ssl determines whether the port uses secure sockets layer (yes) or unencrypted http (no).

Note: The ssl attribute must correspond to the protocol used in the PollingHttpImportService which connects to the PolledHttpExportService. Since these services are typically used to penetrate a firewall within an institution, secure sockets layer is not normally needed for security.

• acceptDicomObjects determines whether DicomObjects are to be exported.
• acceptXmlObjects determines whether XmlObjects are to be exported.
• acceptZipObjects determines whether ZipObjects are to be exported.
• acceptFileObjects determines whether FileObjects are to be exported.

2.5.8 DicomExportService

The DicomExportService queues objects and transmits them to a DICOM Storage SCP. The configuration element for the DicomExportService is:

        <ExportService
            name="stage name"
            class="org.rsna.ctp.stdstages.DicomExportService"
            root="root-directory" 
            url="dicom://DestinationAET:ThisAET@ipaddress:port"
            interval="10000" />

where:

• name is any text to be used as a label on configuration and status pages.
• root is a directory for use by the ExportService for internal storage and queuing.
• dest-url specifies the destination DICOM Storage SCP's URL.
• interval is the sleep time (in milliseconds) between polls of the export queue.

Note: The default interval is 10 seconds. The minimum allowed value is one second. The maximum allowed value is 20 seconds.

2.5.9 DatabaseExportService

The DatabaseExportService queues objects and submits them to a DatabaseAdapter class, which must be written specially for the database in question. The configuration element for the DatabaseExportService is:

        <ExportService
            name="stage name"
            class="org.rsna.ctp.stdstages.DatabaseExportService"
            adapter-class="org.myorg.MyDatabaseAdapter"
            root="root-directory"
            acceptDicomObjects="yes"
            acceptXmlObjects="yes"
            acceptZipObjects="yes"
            acceptFileObjects="yes"
            interval="10000" />

where:

• name is any text to be used as a label on configuration and status pages.
• adapter-class is the class name of the database's adapter class. See Implementing a DatabaseAdapter for more information.
• root is a directory for use by the ExportService for internal storage and queuing.
• acceptDicomObjects determines whether DicomObjects are to be exported.
• acceptXmlObjects determines whether XmlObjects are to be exported.
• acceptZipObjects determines whether ZipObjects are to be exported.
• acceptFileObjects determines whether FileObjects are to be exported.
• interval is the sleep time (in milliseconds) between polls of the export queue.

Note: The default interval is 10 seconds. The minimum allowed value is one second. The maximum allowed value is 20 seconds.

3 Extending ClinicalTrialProcessor

ClinicalTrialProcessor is designed to be extended with pipeline stages of new types. Stages implement one or more Java interfaces, so it is necessary to get the source code for ClinicalTrialProcessor in order to extend it, even though in principle you don't need to modify the code itself.

3.1 Obtaining the Source Code

The software for ClinicalTrialProcessor is open source. All the software written by the RSNA for the project is released under the RSNA Public License. It is maintained on a CVS server at RSNA headquarters. To obtain the source code, configure a CVS client as follows:

Protocol:           Password server (:pserver)
Server:             mirc.rsna.org
Port:               2401
Repository folder:  /RSNA
Username:           cvs-reader
Password:           cvs-reader
Module:             ClinicalTrialProcessor

Together, this results in the following CVSROOT (which is constructed automatically if you use something like Tortoise-CVS on a Windows system):

:pserver:cvs-reader@mirc.rsna.org:2401/RSNA

This account has read privileges, but it cannot write into the repository, so it can check out but not commit. If you wish to be able to commit software to the CVS library, contact the MIRC project manager.

3.2 Building the Software

When you check out the ClinicalTrialProcessor module from CVS, you obtain a directory tree full of the sources and libraries for building the application. The top of the directory tree is ClinicalTrialProcessor. It contains several subdirectories. The source code is in the source directory, which has two subdirectories, one each for the Java sources and the files required by the application.

Building ClinicalTrialProcessor requires the Java 1.5 JDK and Ant. Running ClinicalTrialProcessor requires the JDK or JRE and the JAI ImageIO Tools.

The Ant build file for ClinicalTrialProcessor is in the ClinicalTrialProcessor directory and is called build.xml. To build the software on a Windows system, launch a command window, navigate to the ClinicalTrialProcessor directory, and enter ant all.

The build file contains several targets. The all target does a clean build of everything, including the Javadocs, which are put into the documentation directory. The Javadocs can be accessed with a browser by opening the file:

ClinicalTrialProcessor/documentation/index.html

The default target, ctp-installer, just builds the application and places the installer in the products directory.

3.3 The Object Classes

ClinicalTrialProcessor provides four classes to encapsulate files of various types. The classes are located in the org.rsna.ctp.objects package:

• DicomObject - a DICOM dataset
• XmlObject - an XML file containing identifiers relating the data to the trial and the trial subject
• ZipObject - a zip file containing a manifest.xml file providing identifiers relating the zip file's contents to the trial and the trial subject
• FileObject - a generic file of unknown contents and format

Each class provides methods allowing pipeline stages or database adapters to access the internals of an object without having to know how to parse it. See the Javadocs for a list of all the methods provided by these classes.

3.4 Implementing a Pipeline Stage

To be recognized as a pipeline stage, a class must implement the org.rsna.ctp.pipeline.PipelineStage interface. An abstract class, org.rsna.ctp.pipeline.AbstractStage, is provided to supply some of the basic methods required by the PipelineStage interface. All the standard stages extend this class.

Each stage type must also implement its own interface. The interfaces are:

• org.rsna.ctp.pipeline.ImportService
• org.rsna.ctp.pipeline.Processor
• org.rsna.ctp.pipeline.StorageService
• org.rsna.ctp.pipeline.ExportService

The Javadocs explain the methods which must be implemented in each stage type.

Each stage class must have a constructor which takes its configuration file XML Element as its argument. The constructor must obtain any configuration information it requires from the element. While it is not required that all configuration information be placed in attributes of the element, the getConfigHTML method provided by AbstractStage expects it, and if you choose to encode configuration information in another way, you must override the getConfigHTML method to make that information available to the configuration servlet.

3.5 Implementing a DatabaseAdapter

The DatabaseExportService pipeline stage provides a queuing mechanism for submitting files to a database interface, relieving the interface from having to manage the queue. It calls the overloaded process method of the interface with one of the four object types. Each of the objects includes methods providing access to the internals of its file, allowing the interface to interrogate objects to obtain some or all of their data to insert into an external system.

The DatabaseExportService dynamically loads the database interface class, obtaining the name of the class from the configuration element's adapter-class attribute.

3.5.1 The DatabaseAdapter Class

The DatabaseAdapter class, org.rsna.ctp.stdstages.database.DatabaseAdapter, is a base class for building an interface between the DatabaseExportService and an external database. To be recognized and loaded by the DatabaseExportService, an external database interface class must be an extension of DatabaseAdapter.

The DatabaseAdapter class provides a set of methods allowing the Database Export Service to perform various functions, all of which are explained in the Javadocs. The basic interaction model is:

• When the DatabaseExportService detects that files are in its queue, it determines whether the database interface class is loaded and loads it if necessary.
• It then calls the database interface’s connect() method.
• For each file in the queue, it instantiates an object matching the file’s contents and calls the database interface’s process() method. There are four overloaded process methods, one for each object class.
• When the queue is empty, it calls the database interface’s disconnect() method.

All the methods of the DatabaseAdapter class return a static instance of the org.rsna.ctp.pipeline.Status class to indicate the result. The values are:

• Status.OK means that the operation succeeded completely.
• Status.FAIL means that the operation failed and trying again will also fail. This status value indicates a problem with the object being processed.
• Status.RETRY means that the operation failed but trying again later may succeed. This status value indicates a temporary problem accessing the external database.

All the methods of the base DatabaseAdapter class return the value Status.OK.

3.5.2 Extending the DatabaseAdapter Class

To implement a useful interface to an external database, you must extend the DatabaseAdapter class.

Since the DatabaseAdapter class implements dummy methods returning Status.OK, your class that extends DatabaseAdapter only has to override the methods that apply to your application. If, for example, you only care about XML objects, you can just override the process(XmlObject xmlObject) method and let DatabaseAdapter supply the other process() methods, thus ignoring objects of other types.

Although the DatabaseAdapter class includes reset() and shutdown() methods, they are not called by the DatabaseExportService because restarts are not done in ClinicalTrialProcessor and there is no notice of an impending shutdown. You should therefore ensure that the data is protected in the event of, for example, a power failure. Similarly, since one connect() call is made for possibly multiple process() method calls, it is possible that a failure could result in no disconnect() call. Thus, depending on the design of the external system, it may be wise to commit changes in each process() call.

3.5.3 Connecting Your Database Interface Class to ClinicalTrialProcessor

The easiest way to connect your class into ClinicalTrialProcessor is to create a package for it under the ctp tree and then build the entire application. This will avoid your having to change the manifest declaration in the build.xml file, and it will ensure that the class is included in the installation without having to add a jar file.

4 Security Issues

In a clinical trial, transmission of data from image acquisition sites to the principal investigator site involves penetrating at least one firewall. Since the image acquisition site initiates an outbound connection, this only rarely requires special action. At the principal investigator's site, where the connection is inbound, some provision must be made to allow the connection to reach its destination. There are two basic solutions. The simplest solution is to open a port in the firewall at the principal investigator's site and route connections for that port to the computer running the ClinicalTrialProcessor application. In some insitutions, however, security policies prohibit this solution. The alternative is to use the PolledHttpExportService and PollingHttpImportService to allow data to flow without having to open any ports on the internal network to inbound connections.

Using this latter solution requires two computers, each running ClinicalTrialProcessor. One computer is placed in the border router's DMZ with one port open to the internet, allowing connections to the HttpImportService of the program running in that computer. That program's pipeline includes a PolledHttpExportService which queues objects and waits for a connection before passing them onward. The second computer is placed on the internal network. Its program has a pipeline which starts with a PollingHttpImportService. That ImportService is configured to make outbound connections to the DMZ computer when a file is requested. This allows files to pass through the firewall on the response stream of the outbound connection without having to open any ports to the internal network.

5 Notes

5.1 The Central Remapping Service

Anonymizers have many functions for remapping PHI into trial-specific identifiers which cannot be traced back to the patient. These functions can be grouped into two categories, one which uses remapping tables to maintain correspondences between PHI and its remapped values, and one which avoids the need for remapping tables by using hashing algorithms to provide the remapped values.

The FieldCenter application includes anonymizers which have both categories of remappers. In the category of remappers which use tables, FieldCenter provides both a local remapping table capability and one which can use a central remapping agent provided by a MIRC site.

Hashing algorithms are both more efficient and more secure, so they are preferred over those that use remapping tables, and all new trials are encouraged to use them.

ClinicalTrialProcessor does not provide a central remapping agent. It also does not provide table-based functions in its anonymizers.

5.2 The Update Service

The Update Service is not currently implemented in ClinicalTrialProcessor. One of the primary motivations for the Update Service was for automatic backups of FieldCenter applications' local remapping tables. As this approach is being deprecated, the motivation now is only for software and anonymizer table distribution. Trials which need those functions today can install MIRC sites to provide them in the interim until the service is implemented in ClinicalTrialProcessor.