Clinical Trial Administrator's Manual

From MircWiki
Jump to navigation Jump to search

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.

Error creating thumbnail: Unable to save thumbnail to destination

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, shown here as the standard SSL port (8443), 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.

Error creating thumbnail: Unable to save thumbnail to destination

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 it.
    • If the MIRCdocument does not exist, it creates a new MIRCdocument by copying the template.xml file from the storage service's trial directory.
  • Once it has a MIRCdocument corresponding to the Study Instance UID of the image, the Object Processor inserts the image. Note that, as described in MIRC Templates, templates (which are actually MIRCdocuments) can contain template elements that instruct the insertion process how to obtain information from images or other files and place it in the document.
  • 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 interface, an externally developed program which does whatever its designers have designed it to do. A separate article describes the database interface in detail.

2 The Key Steps in Setting Up a Clinical Trial

3 The DICOM Service

3.1 The DICOM Import Service

3.2 The HTTP Import Service

3.3 The DICOM Export Service

3.4 The HTTP Export Service

3.5 The Database Export Service

4 The Update Service

5 The FieldCenter Application

6 The Clinical Trial Template File