Implementation of a semi-automated post-processing system for parametric MRI mapping of human breast cancer

Abstract

Magnetic resonance imaging (MRI) investigations of breast cancer incorporate computationally intense techniques to develop parametric maps of pathophysiological tissue characteristics. Common approaches employ, for example, quantitative measurements of T (1), the apparent diffusion coefficient, and kinetic modeling based on dynamic contrast-enhanced MRI (DCE-MRI). In this paper, an integrated medical image post-processing and archive system (MIPAS) is presented. MIPAS demonstrates how image post-processing and user interface programs, written in the interactive data language (IDL) programming language with data storage provided by a Microsoft Access database, and the file system can reduce turnaround time for creating MRI parametric maps and provide additional organization for clinical trials. The results of developing the MIPAS are discussed including potential limitations of the use of IDL for the application framework and how the MIPAS design supports extension to other programming languages and imaging modalities. We also show that network storage of images and metadata has a significant (p < 0.05) increase in data retrieval time compared to collocated storage. The system shows promise for becoming both a robust research picture archival and communications system working with the standard hospital PACS and an image post-processing environment that extends to other medical image modalities.

Fig 1.

MIPAS relies on the database to store and track all metadata and post-processing states for all incoming and temporary images. Post-processing programs, which include user interfaces to MIPAS and individual programs, use the database to determine how and where to access images and other data stored in the operating systems file system.

Fig 2.

Each research protocol requires certain tasks to be performed in a specific order to properly create the parametric maps for this research project. The main menu is the starting point where the user selects the initial image dataset load program, which is followed by appropriate branches in the processing cycle based on the MR image protocol and finishes with the final map stored in the file system and made available for pick-up or delivery to the investigator.

Fig 3.

The IDEF0 diagram documents the inputs, outputs, and triggering event(s) for each interactive or image processing function of the system. User selections, newly acquired image datasets, or retrieved image datasets output from previous post-processing steps are inputs, while image datasets and metadata or process control information are outputs. Event triggers (new images or a post-processing request) are external system events that can evoke automated or interactive responses from the MIPAS system.

Fig 4.

Image datasets follow a flow through the file system storage structure to facilitate easy access to image types and external verification of processing status. This structure also provides a means to access datasets in an intermediate form for reuse.

Fig 5.

The MIPAS database structure is based on four distinct types of metadata and function: image metadata, post-processing protocols, DICOM standards, and system configuration. Each table is composed of primary keys (PK), foreign keys linking tables (FK), and the metadata within that table. These keys enable fast access to specific records needed throughout the post-processing cycle. The metadata for each table is described further in the text.

Fig 6.

In this DICOM IDL code module, you can see how a set of DICOM tags (Txxxx_xxxx) are composed and placed into the appropriate program statements and function calls to access the database. The DICOM dictionary facilitates the creation of these consistent, well-defined code modules that match the DICOM standard. Hundreds of these code modules are required to process DICOM images.

Fig 7.

Main menu user interface where post-processing protocol tasks are loaded from the database into a hierarchical structure organized by imaging modality, protocol name, and sequence. Selections can be expanded through the “+” preceding each folder icon. Information about a protocol task can be viewed by single-click selection of the task. Double-click selection of the task executes that task by way of a task-load function in this program.

Fig 8.

In this DCE-MRI user interface, the way the database supports processing can be illustrated. In step 1, the program takes the SessionID and uses it to retrieve the image metadata to locate and load the appropriate T₁-registered images for this DCE-MRI analysis, loading them into the top left window. At the same time, the registered DCE-MRI images are loaded into the top center window. For step 2, the ROI is extracted from the T₁ image and stored for later use. Step 3 creates the single-slice time series from the 3D DCE-MRI image volume seen in the top right window and step 4 runs the actual analysis producing the K^trans, v_e, and τ_i maps.