DIT is designed and implemented to be fully integrated into a DICOM-compliant infrastructure with the ability to capture and maintain longitudinal patient-specific exam indices of interest for all diagnostic and procedural uses of imaging modalities. This information system consists of six modules: a DICOM receiver accepting and parsing imaging files sent from equipment or PACS, a knowledge base (i.e., modalities, manufacturers, model, and software versions of known equipment) with mappings of the standard and proprietary DICOM tags of interest, a patient episode tracking database, dosimetry analyzer tools, a configurable web reporter, and an automated alert/messaging mechanism (e.g., unknown scanners, high radiation exposure, etc.). The system architecture of DIT, including the composite modules and the connection with other software, are shown in Figure . The implementation and evaluation of each component is summarized as follows.
The architecture of DIT.
DICOM Receiver and Parser
In DIT, the module called ‘DICOM Receiver and Parser’ receives images from DICOM-compliant devices/systems, extracts the tag information, and stores them into a DIT database. The Receiver takes advantage of the DICOM transport protocol12
—the de facto standard in medical imaging transfer fully supported by the majority of device manufacturers and PACS vendors. DIT is able to receive and process medical images from various locations, modalities, and equipment. Following the receipt of images, the DICOM header information is parsed and transformed to XML format and then desposited to the tables in DIT database. DIT does not store image data (it can accept the DICOM Secondary Capture) to enhance performance and reduce storage needs.
Knowledge Base DICOM tags commonly differ by modality, vendor, and software version even for the same vendor and modality. The continuously evolving DICOM standard often results in a given vendored product version being behind the newer DICOM committee standards. Nonetheless, even the base standard provides extensive information about the patient, the exact medical examination protocols, and the imaging modality acquisition settings. Every DICOM-compliant image file contains modality-/exam-specific attributes including: patient age, gender, examination ordered, protocol, and series descriptors, location of equipment, equipment software version, etc. Radiation dose-specific information varies by modality, but includes: kVp, mA and/or mAs, field of view, exposure index, air kerma at the patient entrance reference point (PERP), breast organ dose, body part, and with some nuclear equipment, the administered radioactivity (Bq). In the case of mammography, mean glandular organ dose is provided. Other important information might be in an image file (DICOM Secondary Capture). An example of this is the Exam Protocol screenshot, a method commonly used with CT to record the CT dose index (CTDIvol) and dose length product (DLP) for individual series and total examination.Because of the variation in supplied DICOM tags from different scanners, the Knowledge Base architecture design (Fig. ) is included. Its schema identifies known scanners (defined as those having their hardware and software specifications, as well as the standard and proprietary dose-related tags present with this equipment) as being fully known by the database. The tag mappings drive the proper algorithm selection for calculating a dose approximation. Specifically, each known scanner (termed Known_scanners) belongs to one group of specific tags (termed Grp_specific_tags). In Known_scanners, the Grp_ID defines the group of proprietary data elements that will be harvested (chosen once, during a new equipment installation or with a new software version) from the DICOM header (in addition to the standard elements e.g., image UID, accession). The mapping from Grp_ID to dose-related information is defined in Grp_specific_tags. The advantage of such schema design is that it provides the system extensibility. For example, when a new scanner is added, or for an existing scanner, an update of software version, one record is added to known_scanners, and its list of dose-related tags are determined and appended into Grp_specific_tags. Importantly, this extension does not interfere with the processing of existing images, and it does not require any modification of programming with new images. Overall, the cost of adding an unknown scanner software version to DIT is minimal.
Since the Knowledge Base serves as the foundation of the DIT system, its comprehensive and accurate content is essential for a successful implementation. The list of vendor modality specific tags was initially created as a team effort: radiology specialists from each modality, DICOM engineering staff, quality assurance staff, and system developer. The task ensures that the collected tags will satisfy all the facets of technical and expected QA needs e.g., dose calculation and quality monitoring within system technical constraints.
The database schema of Knowledge Base.
DIT Database The database is designed to store all harvested tags while avoiding redundancy and maintaining a balanced storage to optimize data access efficiency. The resultant schema contains five parts: patient information, exam information (e.g., protocol), series information, image information, and vendor modality-specific-related information (e.g., dose). When images are sent from varied imaging devices into the DIT, the DICOM header is extracted; the data elements are parsed out and populated into the database. The specified elements are placed in database tables appropriate to the level of the information.In Figure , the table Patient has one record for each patient with information such as patient_local_ID, gender, and DOB. The table Exam contains the basic information pertinent to each exam common with each modality. This includes exam information (exam description, referring doctor, and radiologist), exam time, location, etc. The table Series stores the information related to series, such as series_UID and Series Description; and the table Images keeps the information at the image level, such as Image_UID and image acquisition time. The table Dose_Related_Info contains the data elements appropriate for the modality, device, and software. The schema is in a serial arrangement as in Figure , where the relationships between two neighboring tables are all one to many. That is, one Patient may have one or more exams, one Exam record contains one or more series, one Series usually have one or more Image records, and one Image record may be related to one or more Dose_Related_Info records. In this manner, the hierarchical structure of patient, exam, series, images, and dose information is reflected in the database design.
The DIT database connects with the Knowledge Base to populate Dose_Related_Info. When each exam reaches DIT, tags for modality, manufacturer, model, and software version will be used to match the image to a known scanner in Knowledge Base. If the match is successful, DIT will fetch the list of specific desired tags from the Knowledge Base table Grp_specific_tags and populate these tags (taken from image header) into the DIT Database table Dose_Related_Info. If the match fails (the scanner/software is unknown), the database will automatically alert the database manager or medical physicist of the need to exactly specify DICOM tag dose-related fields for future archiving.Such database design minimizes data redundancy and accelerates a database search. The lower-level tables (left side of table in Fig. ) have a far greater number of records, and thus, results in signficant computational cost to conduct the query as compared to the higher-level (right side of table in Fig. ) tables. For example, to list the exams of specific patients, a query on the tables Patient and Exam is sufficient without involving table Series, Images, and Dose_Related_Info. Additionally, the design of table Dose_Related_Info gives improved flexibilty for querying any desired information since the number of dose-related data elements, their meaning, and units are not restricted by the table structure.
The database schema of DIT Database.
Dosimetry Analyzer For each ionizing radiation modality, i.e., CT, CR, XA, PET, DX, etc., the computation of a patient-specific radiation dose estimate for a single (and each) episode of care is required in order to develop an overall cumulative estimate of dose associated with an individual. Extracted (tag) information available in the DIT includes wide ranging dose information; examination, and protocol, gender, age, projection angles, fluoroscopy exposure rate and time, air kerman rate, air kerman area, PERP, DLP, Bq breast organ dose, CTDIvol, dose area product (DAP), etc. This modality-specific information can be used by physicists to assess or estimate a dose particular to a specific exam, or to compare types of procedures, different vendors, or software versions, physican or technologist operator, and even different medical facilities. In some cases, the equipment and software version do not support any tag to precisely compute the dose. For example, with CT, a lack of consensus currently exists on the best method of computing an estimate of dose. Nonetheless, at least a recording of the number of specific examinations, by modality, can be identified for each patient.
With increasing numbers and multi-location episodes of diagnostic and interventional radiation examinations and procedures, IT systems must be capable of providing online reporting; this is arguably the only appoach to handling the complexity of access to dose information. It is also needed to provide distributed real-time review by current practice.13
For quality assurance purposes, a web reporting module enables the management, and performs ad hoc execution, of configurable reports. Each report template is created in Oracle® Reporter (Oracle®, Redwood Shores, CA) to run on an Oracle Report® server. The report profile can be selected in ASP.NET web pages; users set their configuration and generate reports online. As the focus of this project is quality assurance, in which the content is varied but not fully defined, the tool is intentionally general in design, providing flexibility to other database-based web reporting applications.This tool can be modified to provide reports on many of the DICOM tag values that may be of future interest. Alternatively, the results of a search also create a listing of the data requested which is rendered in a data table. A mammography search might include radiation dose, breast thickness, and the filter type (either chosen by the technologist or automatically selected by the equipment). A Save button creates an Excel file that is available for creation of any desired graph format using i.e., Chart Wizard (the user-friendly Excel function to generate charts).14
A box to insert legal disclaimers regarding the appropriate use of privileged QA information is included.
Alert Mechanism This highly important instant message alert system enables the time by notification of user-defined critical events. By setting different levels of urgency, the designated QA staff are alerted to preconditioned events in near real-time. DIT alerts are generated automatically during user-configurable time period monitoring (i.e., every hour, or at midnight). When the service level reaches some warning threshold or Triggers, an alert is sent.At this time, alerts are sent via internal email, designated cell phone text messaging, and internal pager text messages. All messaging are organized by a distribution list, and multiple staff receive specific messages. Alerts are also needed to maintain the robustness and accuracy of the system; any newly arriving images received by an unknown scanner generate an email message to support staff for a review of the data record and for an update on the Knowledge Base with the appropriate DICOM tags.