MIRC CTP

This article describes a proposed project to develop a stand-alone, configurable processing application for clinical trials data, based on MIRC components and using the MIRC internet transport mechanism. The article is intended for people who have used MIRC for clinical trials data acquisition and management. Please use the Discussion tab to add comments.

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. FieldCenter also contains a client for the Update Service of a MIRC site, allowing the FieldCenter application to save date 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 iinsertion 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 is clear that a completely symmetrical design would provide better support for more sophisticated trials while still satisfying the requirements of simple ones.

2 Requirements

The following are proposed top-level requirements for the implementation:

1. Single-click installation.
2. Processing pipeline supporting configurable number of stages, with the class implementing each stage being configurable.
3. Pre-defined implementations for key components:
   • HTTP Import
   • DICOM Import
   • DICOM Anonymizer
   • XML Anonymizer
   • Storage Interface
   • Database Export
   • HTTP Export
   • DICOM Export
4. Web-based monitoring of the application's status, including access to logs.