Clinical Trial Administrator's Manual

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.

1 Overview

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 also 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.

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 site 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 storage service 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 local 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 Setting Up a Clinical Trial

There are many ways to use MIRC in a clinical trial. This section describes the most common approach, where a multi-center trial is focused on a single principal investigator, which controls all the software and manages all the configuration files.

2.1 Install a storage service for the trial

Each trial must have its own storage service. To add a storage service to a MIRC site, run the installer, and on the Storage Service Installation page, click Install and follow the instructions in the sequence of dialog boxes:

• For the one-word name of the storage service, you can choose any word you wish, but it is usually best to use the name or acronyn of the trial so the storage service's URL will be both short and memorable.
• For the two- or three-character prefix, choose a prefix that is unique on the MIRC site. This will allow you to control which users can access the documents and images on the storage service.
• When asked whether documents should be indexed automatically, answer yes. This is secure because alll documents will be restricted to authenticated users who have the permissions granted through the unique prefix.
• Because you created a unique prefix, you will have to add the appropriate roles to the administrator's role. On the Create Administrator User page, click Create and enter your username.

2.2 Configure the network for the trial

If the trial is entirely within an institution and the network is secure, you can use port 8080 and not bother with setting up a Secure Sockets Layer (SSL) connection for Tomcat. For most trials, however, the data transmission will take place across the internet, and you should configure SSL on port 8443 as described in Configuring Tomcat to Support SSL.

After doing that, you need to ensure that port 8443 is open for inbound connections from the internet. This must be done by the IT staff at the principal investigator's site. In some cases, the IT staff may be concerned about security problems and may want to put the server in the border router's DMZ. This will not affect the ability of the site to receive images, but it will make it impossible for the site to forward images to a PACS or workstation inside the main network. The solution to that problem is to open the necessary port from the DMZ to the main network, limiting the source to the MAC address of the server and the destination to the MAC address of the required destination workstation.

Experience has shown that some image acquisition sites are unable to allow outbound connections on all ports. If any of the sites in the trial fall into that category, they will have to transmit to port 8080 and it will therefore be necessary to open that port to the internet on the principal investigator's site as well. (MIRC is designed not to require opening any ports for inbound connections at the image acquisition sites.)

Some trials have used virtual private networks for security. This requires more support during installation at the image acquisition sites than is usually available, but it has been shown to work.

2.3 Configure the DICOM Service

The trial directory, which is located in the root directory of the storage service, contains all the parameter files associated with the DICOM Service:

• trial.xml - the trial configuration
• dicom-anonymizer.properties - the script file for the DICOM anonymizer
• idtable.properties - the remapping database
• template.xml - the template used to create MIRCdocuments to reference objects received by the DICOM Import Service and the HTTP Import Service
• dictionary.xml - a convenience listing of DICOM elements (not used by the software, but useful for copying element references when editing the template.xml file)

In addition, two other files may be created manually and used in certain trials:

• lookup-table.properties - a table of remapping values used in some trials to assign, for eacmple, trial patient IDs to hospital patient IDs.
• xml-anonymizer.script - the script file for the XML anonymizer, used only in trials that produce XML data files.

The DICOM Service is configured by clicking the Update Configuration button in the DICOM Service column on the storage service's admin page. The details of configuring the DICOM Service are described in The DICOM Service Configurator.

2.4 Create the template.xml file

When files are received from image acquisition sites, the DICOM Service automatically creates MIRCdocuments, grouping the objects by Study Instance UID. The MIRCdocuments are created from the template.xml file which is located in the storage service's trial directory. Templates are described in the MIRC Templates article. More detail on the elements in a template can be found in The MIRCdocument Schema.

The MIRC software includes an example DICOM Service template which can serve as a starting point for creating the template for the trial. Careful consideration should be given to all the sections in the template. The example DICOM tempate is not intended to be appropriate for any trial; it is intended only to provide examples of the kinds of data that can be made available in the MIRCdocument. The template should be carefully designed before the trial begins so that all the documents created for the trial are consistent. Special consideration should be given to several items:

• The title element should be constructed to make it easy for the trial administrator to identify the study in a list of query results. Generally, the title should include the name of the trial, the acquisition site ID, the patient ID, the modality, and the study date. Acquisition sites are typically identified not by name but by a code. In the example below, the anonymizers at the image acquisition sites are assumed to be configured to insert the site's code in the Institution Name element.

<title>
    TRIALNAME/<g0008e0080 desc="Institution Name"/>:
    <g0010e0020 desc="Patient ID"/>
    <g0008e0060 desc="Modality"/>
    <g0008e0020 desc="Study Date"/>
</title>

• The abstract element should contain information that may be helpful in a list of query results, but the total length of the text should be small so that scrolling through query results is not tedious. While it is possible to insert tables and other HTML in the abstract, it is generally not advisable.
• If the anonymization rules permit PHI to be contained in the images and/or the MIRCdocuments that reference them, then the template should contain the phi element as in this example:

<phi>
    <study>
        <si-uid><g0020e000D desc="Study Instance UID"/></si-uid>
        <pt-id><g0010e0020 desc="Patient ID"/></pt-id>
        <pt-name><g0010e0010 desc="Patient Name"/></pt-name>
    </study>
</phi>

• The authorization element should be preconfigured to restrict access to the document to those users who have the proper roles. If the unique prefix for the trial is XYZ and the trial administrator's user name is jsmith, an example of an authorization element would be:

<authorization>
    <owner>jsmith</owner>
    <read>XYZ-user</read>
    <update>XYZ-author</update>
    <export>XYZ-user</export>
</authorization>

• To enable MIRC's special export features for DICOM objects, it is best to specify the value of the document-type element as research dataset as shown in the example DICOM Service template.

2.5 Decide on the anonymization requirements

The anonymization requirements for a trial determine how the data will be handled as it is processed at the image acquisition sites and transmitted to the principal investigator site.

Typically, studies done for a trial are acquired as clinical examinations which contain all the PHI required by the institution's clinical systems (HIS, RIS, PACS). Rarely, some trials preserve the PHI in the images thorughout the trial. Far more often, the PHI is either removed or replaced with trial-specific identifiers for patient IDs, etc. The latter process can be done in two ways, either retaining the relationship between the PHI and the remapped values in internal tables or discarding it. The MIRC anonymizer supports all these anonymization methods.

The first question is therefore whether PHI is to be preserved in the data files obtained in the trial. If it is to be preserved, the anonymizers in the FieldCenter applications can be disabled.

If PHI is to be anonymized, the next question is what data elements must be modified. HIPAA provides a list of 18 categories of elements which is often used as a starting point for this analysis:

1. Name
2. Location; all geographic subdivisions smaller than a state, including street address, city, county, precinct, zip code, and their equivalent geocodes.
3. Dates (all dates related to the subject of the information, e.g. birth dates, admission dates, discharge dates, encounter dates, surgery dates, etc.)
4. Telephone numbers
5. Fax numbers
6. Electronic mail addresses
7. Social security numbers
8. Medical record numbers
9. Health plan beneficiary numbers
10. Account numbers
11. Certificate / license numbers
12. Vehicle identifiers and serial numbers, including license plate numbers
13. Device identifiers and serial numbers
14. Web Universal Resource Locators (URLs)
15. Internet Protocol (IP) address numbers
16. Biometric identifiers, including finger and voice prints
17. Full face photographic images and any comparable images
18. Any other unique identifying number, characteristic, or code

Local IRBs may impose other requirements, and even the ones above are subject to revision if properly described on consent forms.

The details of how to configure the anonymizer and how to use all its functions are contained in the MIRC DICOM Anonymizer. The article contains several examples of how specific trials have dealt with certain issues. This section, therefore, will offer only a few notes, with the understanding that every institution, and every trial, generally sees itself as being unique, so the notes below are meant to serve only as a guide to some of the issues.

2.5.1 Patient Names

Patient names are almost always removed. It is convenient, however, to have different patients have different values in the PatientName element, so the anonymizer provides several functions that can be used to do the mapping. The best is probably the hash function, and a script like hash(PatientName,8,2) works well in most cases.

There are four ways to handle the PatientID element.

1. Trials which use external registration often have the modality operator enter the patient ID in a comment field in the user interface of the modality. The anonymizer is then configured to verify the form of the data in the comment field and then to move it over to the PatientID element, replacing the PHI that was present with the patient ID for the trial.
2. Some trials that use external registration will produce a lookup table containing a pre-defined mapping between PHI and replacement values. The lookup function is then used to perform the mapping function. This only works, however, when the complete mapping of PHI to replacement values is known in advance.
3. The hash function can also be used to generate a remapped value for the PatientID element.
4. Some trials generate patient IDs automatically, using the anonymizer's ptid function.

2.5.2 UIDs

There is a spirited debate over whether DICOM UIDs are truly required to be remapped, with passionate advocates on both sides. One telling argument is that in order to use a UID to identify a patient, one must have access to data containing PHI, in which case confidentiality has already been compromised, so remapping UIDs adds nothing. The anonymizer's uid and hashuid functions provide remapping of UIDs when necessary.

2.5.3 Dates

Dates can be remapped in at least two ways:

1. The offsetdate function can reset the first date encountered to a specific value and then remap all other dates by the same amount, destroying the absolute value of the dates but preserving intervals between them.
2. The incrementdate function adds a predefined offset to every date, with the same effective result as the offsetdate function, but at much lower computational cost. Generally, the incrementdate function is also slightly better when applied to birthdates.

2.5.4 Patient Ages

When it is necessary to remap patient ages, the standard approach is to bin them using the round function, choosing a bin size that is appropriate for the ages of the patients in the trial.

2.6 Build the FieldCenter application for the trial

• properties file - preset for the update service, destination url

2.7 Create Update Service directories for the trial

The Update Service allows the trial administrator at the principal investigator site to manage the key data files used at all the image acquisition sites. These are:

• the DICOM anonymizer script file (dicom-anonymizer.properties)
• the XML anonymizer script file (xml-anonymizer.script)
• the lookup table (lookup-table.properties)
• the FieldCenter program and its related sofware libraries

If the Update Service is enabled in the FieldCenter application at an image acquisition site, it checks the Update Service at the principal investigator site whenever it needs a configuration file (either of the anonymizer scripts or the lookup table). If the version on the principal investigator site is newer than the one on the local site, it is downloaded. This allows the trial administrator to provide configuration expertise for all the image acquisition sites without imposing on the IT staff in the field. Likewise, the sites in the field automatically update the principal investigator site whenever a local change is made to the configuration files.

The use of the Update Service is recommended not only because it simplifies the inevitable configuration work but also because it provides a backup of the key files from the field and allows the administrator to know exactly what is going on at all the sites.

To set up the Update Service, first create a user account for each image acquisition site and give it a special role name that you created when you installed the storage service. For example, if you chose the prefix XYZ, you must give each user the XYZ-update role. This can be done through the User Role Manager, which is described in the MIRC Administrator's Manual.

Next, go to the Tomcat/webapps/[StorageServiceName]/trial directory and create one directory for each site, plus one directory called software. In the end, the directory tree will look something like this:

• trial
  • update
    • software
    • site1
    • site2
    • site3

where site1, site2, site3, etc. are replaced by the user names that you created for the sites.

In the software directory, you will place the FieldCenter files, once they have been created as described below.

In each site's directory, you will place the anonymizer files. Most trials do not use the XML anonymizer, and if yours does not, you will not have that file. Similarly, most trials do not use lookup tables for special remapping, and if yours does not, it will not be present as well.

2.9 Install FieldCenter at the imaging sites

• testing - HttpTest / proxy server issues

3 Clinical Trial Operation

• Decipher