Difference between revisions of "Clinical Trial Administrator's Manual"
Line 31: | Line 31: | ||
</center> | </center> | ||
+ | The boxes outlined in red are the ones of primary interest in a clinical trial. | ||
+ | |||
+ | The general processing flow begins at a modality or workstation at an imaging center: | ||
+ | * The modality transmits one or more images to a computer running the FieldCenter application. | ||
+ | * The FieldCenter application receives the images via the DICOM protocol and queues them for anonymization. | ||
+ | * After anonymization, the FieldCenter application queues the images for transmission to the principal investigator site via the HTTP or HTTPS protocol. | ||
+ | * The HTTP Import Service at the principal investigator site receives each image individually and queues it for processing by the Object Processor. | ||
+ | * The Object Processor parses the image and obtains its DICOM Study Instance UID. | ||
+ | * The Object Processor looks to see if a MIRCdocument for the Study Instance UID already exists in the storage service. | ||
+ | ** If the MIRCdocument already exists, it opens the MIRCdocument and inserts the image. | ||
+ | ** If the MIRCdocument does not exist, it creates a new MIRCdocument by copying the <b>template.xml</b> file from the storage service's <b>trial</b> directory and then inserting the image. | ||
+ | * After creating and/or updating the MIRCdocument for the image, the Object processor queues the image for all the destinations (if any are configured) for the DICOM Export Service. | ||
+ | * The Object Processor then queues the image for the Database Export Service, if enabled. | ||
+ | * The DICOM Export Service forwards all images in its queues to their respective DICOM Storage SCP destinations. | ||
+ | * The Database Export Service presents all images in its queue to the database adapter, an externally developed program which does whatever its designers have designed it to do. | ||
+ | ==The Key Steps in Setting Up a Clinical Trial== | ||
==The DICOM Service== | ==The DICOM Service== | ||
===The DICOM Import Service=== | ===The DICOM Import Service=== |
Revision as of 23:28, 8 August 2006
This article describes how to configure a MIRC storage service for clinical trials. It applies to the RSNA MIRC implementation, and it is intended for MIRC site administrators.
A MIRC storage service includes several components specifically oriented to clinical trials. These components, called services, work together to support a single trial. When a MIRC site must support multiple clinical trials, multiple storage services are installed, one for each trial. Generally, if one or more teaching file components are required on a site, they are supported by separate storage services.
The key services related to clinical trials are:
- DICOM Import Service - a DICOM Storage SCP that receives DICOM objects (typically from modalities or PACS) using the DICOM protocol.
- HTTP Import Service - a service that receives DICOM, XML, or Zip objects (typically from remotely located imaging centers) using the HTTP or HTTPS protocol.
- DICOM Export Service - a DICOM Storage SCU that forwards DICOM objects received by the HTTP Import Service to DICOM Storage SCPs using the DICOM protocol.
- HTTP Export Service - a service that forwards DICOM objects received by the DICOM Import Service to HTTP Export Services (typically at other locations).
- Database Export Service - a service that forwards DICOM, XML, Zip, or file objects to an interface to an external database, allowing athe construction of a trial-specific database outside the scope of MIRC.
For historical reasons, these are called the DICOM Service, even though they support more than DICOM objects.
To facilitate the management of a multi-site trial, MIRC also includes the Update Service, a service that provides the clinical trial administrator control over the software and configuration files at remotely located imaging centers.
The RSNA MIRC project has developed several supporting applications and tools that cooperate in the operation of a trial. The most important of these is the FieldCenter application, which runs at a remotely located imaging center and automatically transmits images to the principal investigator site.
1 Overview
In a typical trial, the principal investigator's site is a MIRC site and each of the imaging centers run the FieldCenter application. The flow of data is depicted in the diagram below.
The diode symbols depict firewalls at each site. The ones at the imaging centers block all inbound connections. The one at the principal investigator blocks all inbound connections except for at least one port, which is used to allow imaging centers to upload images and data files and to make connections to the MIRC site for downloading configuration files and software updates.
Typically, all transfers are done across the internet using secure sockets layer (SSL). A separate article describes how to configure Tomcat to support SSL.
The overall layout of the components in a MIRC site is shown below.
The boxes outlined in red are the ones of primary interest in a clinical trial.
The general processing flow begins at a modality or workstation at an imaging center:
- The modality transmits one or more images to a computer running the FieldCenter application.
- The FieldCenter application receives the images via the DICOM protocol and queues them for anonymization.
- After anonymization, the FieldCenter application queues the images for transmission to the principal investigator site via the HTTP or HTTPS protocol.
- The HTTP Import Service at the principal investigator site receives each image individually and queues it for processing by the Object Processor.
- The Object Processor parses the image and obtains its DICOM Study Instance UID.
- The Object Processor looks to see if a MIRCdocument for the Study Instance UID already exists in the storage service.
- If the MIRCdocument already exists, it opens the MIRCdocument and inserts the image.
- If the MIRCdocument does not exist, it creates a new MIRCdocument by copying the template.xml file from the storage service's trial directory and then inserting the image.
- After creating and/or updating the MIRCdocument for the image, the Object processor queues the image for all the destinations (if any are configured) for the DICOM Export Service.
- The Object Processor then queues the image for the Database Export Service, if enabled.
- The DICOM Export Service forwards all images in its queues to their respective DICOM Storage SCP destinations.
- The Database Export Service presents all images in its queue to the database adapter, an externally developed program which does whatever its designers have designed it to do.