The purpose of this page is to serve as a beginner's guide to Clinical Trials Processor (CTP) with particular emphasis on internal de-identification of DICOM images and submission of this data to an instance of NBIA. Note: It is currently a work in progress. This note will be removed once documentation is considered mostly complete.
The basic outline of steps required to utilize CTP include:
- Installing prerequisite software
- Installing CTP
- Configuring CTP for your needs
- Importing your data
- Processing your data
- Exporting your data
Each step is described in detail below. At the end of the page there is also a section with customized configuration files and scripts for the most common CTP use cases.
1. Installing prerequisite software
It's possible you may not actually need to install anything prior to using CTP and there are only 2 potential things you may need to obtain prior to using CTP:
- Java 1.5 (or better) JRE must be present on the system. Java 1.6 is recommended. Note that only the JRE is required, not the JDK, and therefore this is already installed on most typical computers.
- If you wish to utilize some of CTP's advanced functionality you must also install the Java Advanced Imaging ImageIO Tools. Note that this is not required if all you wish to do is use CTP to de-identify DICOM images or submit de-identified images to NBIA.
2. Installing CTP
CTP can be found in 2 locations. Generally the two packages stay reasonably close together in terms of functionality. If you are looking for a new feature that you've heard about in CTP use the RSNA link. If you're just looking for a stable way to de-identify your data or if you need to submit de-identified data to NBIA use the GForge link.:
- http://mircwiki.rsna.org/index.php?title=CTP-The_RSNA_Clinical_Trial_Processor - The official RSNA wiki site that is updated regularly by the developer of CTP. This always contains the latest bleeding edge release of CTP.
- http://gforge.nci.nih.gov/frs/?group_id=312 - The National Biomedical Imaging Archive (NBIA) software's download site lists all the binaries for installing NBIA. Each release of NBIA includes a .zip distribution of CTP (e.g. "nbia_CTP_Client_5.0.1.zip"). This version usually lags behind the RSNA site but has been tested for compatibility with the latest NBIA release.
Once you have downloaded CTP you will need to extract it to a location on your local hard drive. The method for doing this varies by operating system and the installer you chose to download.
- NBIA GForge installer - use your favorite zip extraction tool and unzip the nbia_CTP_Client_X.X.X.zip to a location on your local hard drive.
- RSNA installer
- Windows Installation - Simply double click the CTP-installer.jar and use the GUI installer program to select the location where you'd like to install CTP.
- Linux/Mac Installation - Open a console/terminal and navigate to the location where you saved CTP-installer.jar. Then type "java -jar CTP-installer.jar" and the GUI installer program will initiate, allowing you to choose where you'd like to install CTP.
3. Configuring CTP for your needs
Once you've installed CTP you must setup some configuration options prior to running it. All of these options are specified with the config.xml file located in the root of the CTP installation directory. This can be easily modified using any text editor and is divided into several "pipeline stages" for importing, processing, and exporting your data. The rest of this section explains the basic structure of the config.xml file. For practical ready-to-use config.xml files tailored for common use cases please continue on to the next section on Example use cases and configuration files.
Importing your data
There are 3 primary locations which you can import data from with CTP.
- Your local hard drive
- A DICOM compatible workstation or PACS
- A remote computer
The RSNA site's documentation contains detailed information on customizing CTP based on your incoming data source.
Processing your data
CTP contains a number of specialized processing "pipelines" for modifying the contents of your data. Again the RSNA wiki site explains all of the CTP Processors in full detail, but below you will find a list of the most common types of processing pipelines and a short summary of their function:
- Anonymizers - These can be used to systematically de-identify the contents of DICOM header elements, or of XML metadata.
- Filters - Very similar to Anonymizers, these can be used to check for specific conditions within DICOM or XML. If the conditions are met these can be "filtered" out for further review prior to processing.
- IDMap - This pipeline stage can be used to generate a mapping of identified and de-identified values of important DICOM elements such as PatientID, UIDs, or accession numbers.
- DatabaseVerifier - This is mainly utilized in conjunction with NBIA. It allows CTP to keep a record of every object sent to the remote NBIA server and subsequently query the NBIA database to ensure it was received to verify no images were lost in transit.
Exporting your data
The most common ways of exporting the data which you've processed in CTP include:
- DICOM export - This is useful for sending your processed data back to a PACS
- HTTP(s) export - This is the method typically utilized to submit your data to an NBIA server (or potentially XNAT - testing needs to be performed to see how this would work)
- Hard drive export - This is called a Storage Service in CTP, which can simply store the processed data to a specified location on a hard drive.
Full details relating to how each of these can be customized along with the other export methods can be found on the RSNA wiki in the Export Services section and the Storage Service section respectively.
Example use cases and configuration files
The goal of this section is to provide the necessary configuration file, de-identification scripts, and filters that a user would need for common use cases.
The first decision you must make is how aggressively to de-identify your images. Supplement 142 has recently been approved by the DICOM Standards Committee as the standard for safely de-identifying DICOM image data while providing flexibility for scenarios which necessitate preservation of certain information needed for quality control and analysis. This is achieved by providing a number of Application Level Confidentiality Profiles which includes a Basic Profile along with a number of Option Profiles. These profiles provide the necessary instructions for how to safely clean DICOM elements which may contain PHI.
Since the early draft stages of Supplement 142's development there has been an effort to integrate its guidance into CTP. Below you will find a list of common de-identification scripts based on Supplement 142 which are ready to use in CTP. The full document as generated by DICOM Working Group 18 can be obtained here: ftp://medical.nema.org/medical/dicom/Final/sup142_ft.pdf
- Basic Application Confidentiality Profile - INSERT SCRIPT LINK - This is the most aggressive de-identification settings from S142 and is intended to remove any potential PHI from DICOM headers.
- Basic Profile + Retain Longitudinal Temporal Information with Modified Dates - INSERT SCRIPT LINK - Implements everything that is in the Basic Profile, except instead of removing the date related elements completely they are modified by some user selected number of days to provide protection against identifying patients, yet retaining the relative time between image studies to allow for research that requires this longitudinal information.
Using CTP for local de-identification
- running the jar file
- sending your source data to CTP
- Archive Import
- File Sender
- going to the browser
- viewing status page
- log files
Sample config.xml: LocalDeId-config.xml
Using CTP to submit to NBIA
There are two common ways which you may wish to configure CTP to send data to NBIA.
- De-identification with local QC review - This is useful if the submitter wishes to do their own review of the de-identified data prior to providing it to the NBIA host. The NBIA host can subsequently choose to perform additional quality control reviews when the data reaches their server.
- De-identification with central NBIA QC review - This is useful if the group performing the submission is the same as the people managing the NBIA server. In this scenario the users can leverage NBIA's built in quality control tools to review the data before making it "visible" to end users of the NBIA site.
Sample configurations for both scenarios are described below, along with pointers to which information will need to be filled in based on your particular use case.
De-identification with local QC review
Sample config.xml: LocalDeId-NBIA-config.xml
Customizations required for use:
De-identification with central NBIA QC review
Sample config.xml: LocalDeId-Automated-NBIA-config.xml
- follow CTP installation steps above
- utilize/tweak NBIA centric config.xml (provide link)
- Submitting to NBIA after local de-identification
- editing your existing config.xml to add an NBIA export service
- sending your de-identified data to the export service
Using CTP to submit to XNAT
Sample config.xml: (still needs to be written)
- Submitting directly to XNAT
- follow CTP installation steps above
- utilize/tweak XNAT centric config.xml (provide link)
- Submitting to XNAT after local de-identification
- editing your existing config.xml to add an XNAT export service
- sending your de-identified data to the export service