Informatics in radiology: an information model of the DICOM standard

Abstract

The Digital Imaging and Communications in Medicine (DICOM) Standard is a key foundational technology for radiology. However, its complexity creates challenges for information system developers because the current DICOM specification requires human interpretation and is subject to nonstandard implementation. To address this problem, a formally sound and computationally accessible information model of the DICOM Standard was created. The DICOM Standard was modeled as an ontology, a machine-accessible and human-interpretable representation that may be viewed and manipulated by information-modeling tools. The DICOM Ontology includes a real-world model and a DICOM entity model. The real-world model describes patients, studies, images, and other features of medical imaging. The DICOM entity model describes connections between real-world entities and the classes that model the corresponding DICOM information entities. The DICOM Ontology was created to support the Cancer Biomedical Informatics Grid (caBIG) initiative, and it may be extended to encompass the entire DICOM Standard and serve as a foundation of medical imaging systems for research and patient care.

Figure 1

Entity-relationship diagram illustrates the DICOM real-world model, in which a Patient has one or more Studies and each Study contains one or more Series. The Series serves as a container that aggregates zero or more objects such as Waveforms, Images, Raw Data, and Presentation States. The numbers next to the arrows or shapes indicate the cardinality of the relationship: 1 = exactly one, 0-n = zero or more, and 1-n = one or more. For example, in the “Patient” to “Study” relationship, a Patient has one or more Study objects, but a Study pertains to only one Patient. (Adapted, with permission of the National Electrical Manufacturers Association, from the DICOM Standard [2009 edition; Part 3, Figure 7-1a].)

Figure 2

Entity-relationship diagram shows the DICOM information model, which distinguishes real-world objects, such as patients, from their corresponding DICOM objects, the information-system representations of real-world objects. Instead of the real-world “Patient,” the information model depicts the Patient IOD, which references one or more Study IODs. 1 = exactly one, 0-n = zero or more, and 1-n = one or more. (Adapted, with permission of the National Electrical Manufacturers Association, from the DICOM Standard [2009 edition; Part 3, Figure 7-2a].)

Figure 3

A portion of the DICOM Ontology model in the Protégé system shows the specific types of real-world objects. The open circle next to “Real_World_Object” indicates that this class is abstract; it cannot have any instances. The closed circles next to the other entities indicate that they are concrete classes and therefore may have instances. Thus, “Patient” describes the properties of a patient, and an instance of this class would describe a specific patient. According to this diagram, “CT_Image” is a subsclass of “Image,” which is a subclass of “Real_World_Object.”

Figure 4

The “Patient” object. View of the Protégé ontology development system shows the “Patient” object. In addition to the hierarchical relationship to “Real_World_Object” (at left), the “Patient” object has two attributes, or slots. The “has_study” attribute indicates an instance of the “Study” class; thus, an instance of “Patient” (ie, a specific patient) will have one or more “has_study” links to specific “Study” instances. Similarly, the “makes_visit” relation indicates one or more “Visit” instances. The “has_DICOM_IE” relation (bottom right) links the real-world “Patient” object to corresponding information entities in DICOM, namely, the “Patient_Module” and “Clinical_Trial_Subject_Module” objects.

Figure 5

The CT Image IOD. The CT Image IOD is defined as a list of modules: The first column gives the name of each Information Entity, the second column gives the name of a DICOM module, and the third column gives the section of Part 3 of the DICOM Standard in which the module is defined. The last column specifies whether a module is mandatory (M), user-defined (U), or conditional (C). (Reprinted, with permission of the National Electrical Manufacturers Association, from the DICOM Standard [2009 edition; Part 3, Table A.3-1].)

Figure 6

Ontology model of the CT Image IOD. View of the Protégé ontology model of the CT Image IOD shows the representation of each line of the table in Figure 5 as a “CT_Image_IOD_Specification” object, which specifies the module name (eg, Patient_Module) and usage (eg, “M”). The “CT_Image_IOD” object has an attribute (“IOD Module Specifications”) that associates all of these modules with the IOD.

Figure 7

A portion of the table that defines the attributes of the CT Image module. Attribute names and their tags are defined in Part 6 of the DICOM Standard. Each data element (attribute) has a unique pair of tags that consist of four hexadecimal (base-16) digits. The “Type” indicates whether elements are required (type 1) or optional (type 2). (Reprinted, with permission of the National Electrical Manufacturers Association, from the DICOM Standard [2009 edition; Part 3, Table C.8-3].)

Figure 8

Attributes that constitute the CT Image module. View of the Protégé ontology shows the attributes that make up the CT Image module. Each module contains a slot that lists all of its constituent data elements (attributes), which are listed here as “children” or subclasses of the “CT_Image_Attribute” class. Each attribute includes pointers to a data element (as defined in the DICOM Data Dictionary, Part 5) and a data element type.

Figure 9

A portion of the table that defines the attributes of the Patient module shows attribute names and their tags, which are defined in Part 6 of the DICOM Standard. “Type” specifies whether attributes are required (type 1), optional (type 2), or conditional (type 3). An SOP, the functional unit of DICOM, pairs a service class with an information object and contains both fully enumerated macros (eg, the “SOP Instances Reference Macro”) and inline macros (eg, the “Other Patient IDs Sequence”). (Reprinted, with permission of the National Electrical Manufacturers Association, from the 2009 DICOM Standard [Part 3, Table C.7-1].)

Figure 10a

Protégé ontology development environment shows the “SOP Instance Macro,” a fully enumerated macro (a), and the “Other Patient IDs Macro,” an inline macro (b). In DICOM, macros provide a way to specify frequently used or repeated data elements within modules. In b, the table reference indicates the corresponding table in the DICOM Standard, and “Macro Attributes” lists the data elements included in the macro.

Figure 10b

Protégé ontology development environment shows the “SOP Instance Macro,” a fully enumerated macro (a), and the “Other Patient IDs Macro,” an inline macro (b). In DICOM, macros provide a way to specify frequently used or repeated data elements within modules. In b, the table reference indicates the corresponding table in the DICOM Standard, and “Macro Attributes” lists the data elements included in the macro.

Figure 11

Diagram shows the relationships between various objects that constitute the CT Image IOD.