Understanding and Using DICOM, the Data Interchange Standard for Biomedical Imaging

Abstract

The Digital Imaging and Communications in Medicine (DICOM) Standard specifies a non-proprietary data interchange protocol, digital image format, and file structure for biomedical images and image-related information. The fundamental concepts of the DICOM message protocol, services, and information objects are reviewed as background for a detailed discussion of the functionality of DICOM; the innovations and limitations of the Standard; and the impact of various DICOM features on information system users. DICOM addresses five general application areas: (1) network image management, (2) network image interpretation management, (3) network print management, (4) imaging procedure management, (5) off-line storage media management. DICOM is a complete specification of the elements required to achieve a practical level of automatic interoperability between biomedical imaging computer systems—from application layer to bit-stream encoding. The Standard is being extended and expanded in modular fashion to support new applications and incorporate new technology. An interface to other Information Systems provides for shared management of patient, procedure, and results information related to images. A Conformance Statement template enables a knowledgeable user to determine if interoperability between two implementations is possible. Knowledge of DICOM's benefits and realistic understanding of its limitations enable one to use the Standard effectively as the basis for a long term implementation strategy for image management and communications systems.

The Digital Imaging and Communications in Medicine DICOM Standard, (originally published as the American College of Radiology—National Electrical Manufacturers Association Standard for Digital Imaging and Communications in Medicine; now maintained by the multi-specialty DICOM Standards Committee) specifies a nonproprietary data interchange protocol, digital image format, and file structure for biomedical images and image-related information.¹ A DICOM Interface involves far more than a simple hardware specification for something like an electric outlet or parallel printer cable. In fact, DICOM does not define a “plug and socket” at all; it defines the form and flow of the electronic messages that convey images and related information between computers. At the time of this writing, the DICOM Standard is a thirteen volume set of engineering information that is used by engineers as a blueprint for the information structures and procedures that control the input and output of data from medical imaging systems. If properly designed (to the DICOM specifications), properly configured and used appropriately, equipment having a DICOM interface will communicate reliably with other DICOM equipment. Since DICOM interfaces are available for nearly every model of diagnostic imaging equipment, imaging system implementers now have the freedom to select equipment based on merits rather than on proprietary considerations.

In spite of the proven effectiveness of the DICOM Standard and the increasing availability of commercial equipment that uses DICOM, there is still misunderstanding of the benefits of DICOM and the real impact of DICOM on the imaging system user. In-depth understanding of the DICOM Standard requires some familiarity with medical imaging, linguistics/semantics, computer science and engineering. Fortunately, a working knowledge of the practical aspects of DICOM will be sufficient for most readers. With knowledge of the main concepts and realistic expectations, one will be equipped either to consult with appropriate experts or to pursue further independent study. Our goal is to answer three main questions:

• For practical purposes, what should one know about DICOM?

• In what ways does DICOM directly impact one's day-to-day work?

• How can one take advantage of the benefits of DICOM?

For Practical Purposes, What Should One Know About DICOM?

Overview of the DICOM Standard

DICOM provides detailed engineering information that can be used in interface specifications to enable network connectivity among a variety of vendors' products. The Standard describes how to format and exchange medical images and associated information, both within the hospital and also outside the hospital (e.g., teleradiology, telemedicine). DICOM interfaces are available for connection of any combination of the following categories of digital imaging devices: (a) image acquisition equipment (e.g., computed tomography, magnetic resonance imaging, computed radiography, ultrasonography, and nuclear medicine scanners); (b) image archives; (c) image processing devices and image display workstations; (d) hard-copy output devices (e.g., photographic transparency film and paper printers).

DICOM is a message standard (i.e., a specification for interchange of information between computer systems). DICOM is a comprehensive specification of information content, structure, encoding, and communications protocols for electronic interchange of diagnostic and therapeutic images and image-related information. Some other healthcare data interchange standards specify only a subset of the properties that impact interoperability. The Health Level Seven (HL7) Standard² specifies a message model, but provides only an abbreviated specification for network communications. The CEN/TC 251/PT3-033 (European Standardization Committee: Technical Committee for Healthcare, Project Team 22) Request and Report Messages for Diagnostic Service Departments”³ document specifies a semantic data model and model-based compositional rules for messages, but only partial guidelines for electronic document interchange. Thus, the HL7 and CEN/TC 251 specifications leave major communications issues unresolved. Implementors depend on bilateral negotiation between information system vendors to determine parameters for the unspecified details. DICOM is a complete specification “from top to bottom” of the elements required to achieve a practical level of automatic interoperation.

DICOM Protocol, Services, and Objects

DICOM specifies a protocol for message exchange (Fig. 1). The DICOM message protocol provides the communications framework for DICOM services. The DICOM protocol is compatible with Transmission Control Protocol and Internet Protocol. This enables DICOM application entities to communicate over the Internet.

Figure 1.

This figure depicts three different implementations of the DICOM protocol scheme. A DICOM network connection exists between the application software programs (peer DICOM application entities) of imaging devices. In configuration 1 the application software generates the DICOM command request (RQ) and command response (RSP) messages that flow from one device to another. In configuration 2 a separate DICOM Message Service Element (DIMSE) protocol machine generates the command messages on behalf of the application software. The DIMSE protocol machine is the DICOM service provider (DSP). The application software is the DICOM service user (DSU). Configuration 3 uses separate modules for all communications and applications functions. A second layer of DICOM messages is used within each device. These are the DIMSE service primitives: the Request Primitive (REQP), Indication Primitive (INDP), Response Primitive (RSPP), and Confirmation Primitive (CFMP). A freestanding DSU module generates the DIMSE service primitives on behalf of the application software. Even though the protocol machine and DICOM service user module may be implemented in various ways, the external command messages are identical for all configurations.

The DICOM services fall into two groups: composite and normalized. The composite services were designed for compatibility with previous versions of the ACR-NEMA Standard. They were originally intended for storage (C-STORE), query (C-FIND), retrieval (C-GET), and transfer (C-MOVE) of images. However, the composite services are also useful for other types of information, such as interpretation reports. Note that the composite group does not include an “update” service. This omission is intentional. The architects of the original ACR-NEMA Standard elected to omit “update” to reduce the possibility of altering an image record. Thus, the composite services are optimized for image interchange. However, this optimization limits the usefulness of the composite services for other domains. Interpretation data interchange is an area in which the composite services are useful. Since alteration of medical records is, of course, forbidden, amendments of original interpretation reports are typically issued as new documents. This business model translates precisely into the composite service paradigm.

The normalized services were designed to provide broader information management functionality. Note that the name “normalized” does not relate to the normalization of databases. The normalized services were envisioned for use with records representing the properties of a single real-world entity, whereas the composite services were used initially only with documents (images) that contain information derived from more than one real-world entity (e.g. pixel data, equipment, and patient identification number). The normalized services support the basic information management operations: create (N-CREATE), delete (N-DELETE), update (N-SET), and retrieve (N-GET). In addition, domain-specific operations (N-ACTION) such as “print a sheet of film” can be defined. A notification service (N-EVENT_NOTIFY) is also specified in the normalized group.

In spite of its flexibility, the normalized service group has some notable limitations. The update service (N-SET) has limited usefulness for the “sequence of items” datatype. N-SET must update an entire sequence rather than an individual data element within a sequence. The normalized group also lacks a query service. This glaring omission is the result of the lack of industry consensus on network query protocols at the time the standard was written. For the Information System-Imaging System (ISIS) interface, this limitation is ameliorated by the Basic Modality Worklist service-object pair (SOP) class (see the definition of SOP class in the next paragraph). The Modality Worklist SOP Class specifies a composite query service for retrieval of demographic and scheduling information by imaging devices.

Real-world entities (e.g., images, procedures, or interpretation reports) are represented in the DICOM semantic data model by templates of attributes. The formal specifications of these templates are documented in the DICOM information object descriptions (IODs). An IOD is an abstract description of a class of entities. An ordered set of values representing the properties of one member of a class may be operated upon by one or more DICOM composite or normalized services. A DICOM Service-Object-Pair (SOP) Class specifies the combination of an IOD and the set of services (DIMSE service group) that are useful for a given purpose. SOP Classes (such as the Basic Modality Worklist SOP Class) are specified within Service Classes according to their purpose. SOP Classes that use composite services are Composite SOP Classes. Normalized SOP Classes use normalized services. An instance of a SOP Class is known as a service-object-pair (SOP) instance. Composite objects and normalized objects are synonyms for composite and normalized SOP instances.

DICOM object terminology is eclectic, but it is certainly also precise. For brevity, DICOM SOP Classes are often referred to as objects or information objects. Note, however, that DICOM objects are “static” objects. They are passive information structures that may be operated upon by external methods. They are not self-contained software components capable of polymorphism, encapsulation, and inheritance. Their design suits their purpose. DICOM SOP classes (and instances) are useful abstractions for data interchange. They are not application components, per se. The data structure of DICOM SOP classes maps well to the data structures of software components and DIMSE service groups map to object methods.

Message transactions using DICOM begin with association establishment. A DICOM association is a communications session involving a pair of peer DIMSE-service-users (see Fig. 1). In other words, a DICOM association is an open channel for message exchange between two devices that use the DIMSE protocol machine (software) to generate and receive DICOM messages. During the association establishment process, the two devices arrive at a shared understanding of the information structures that will be exchanged and the services that will be invoked (i.e. the abstract syntax). Additional parameters essential to interoperability, such as the byte order and data compression method are also negotiated (i.e. the Transfer syntax). Associations are managed by a software process known as the Association Control Service Element (ACSE). The DICOM protocol specifies the coordination of ACSE and DIMSE functionality.

DICOM Service Classes support five general application areas. Each will be described separately in the sections that follow. The Service Classes enable:

• Network image management

• Network image interpretation management^4,16

• Network print management

• Imaging procedure management

• Off-line storage media management

Network Image Management

DICOM network image management supports two general contexts of interaction between imaging devices: push mode and pull mode. The basic service is “push” mode, in which one device simply sends images to another device over a computer network (Fig. 2). “Pull mode” is a more elaborate two-stage process that allows the user first to query a remote device and then to retrieve selected images (Fig. 3).

Figure 2.

Image transfer. The scanner initiates routine image transfers. DICOM does not specify the behavior of the scanner device; the scanner may begin sending images whenever it is ready. This may be done automatically as individual images are completed during a scan procedure, or it may be done at some later time after all images of a procedure have been acquired and the scanner operator has initiated the transfer by activating a “send images” key on the scanner console. When the scanner is ready to send, it sends images one by one to the workstation. The scanner initiates a DICOM communications session (called an “association”) with the workstation for the transfer of each image. Various details are negotiated during association establishment, so that the workstation can prepare to handle the image that it is about to receive.

Figure 3.

Image query and retrieval. Acting on a specific request entered by the user a the workstation console, the workstation software provides to the scanner a query request message, asking for image records that have values matching a set of query keys. The scanner returns a list of matching images. Now, having knowledge of the identification numbers of the images, the workstation user selects the pertinent images from the displayed list and enters a “retrieve images” command at the keyboard. The workstation software then sends a message to the scanner, listing the image identification numbers and requesting the scanner to send the images. The scanner sends the requested images, one at a time, to the workstation, using the DICOM Storage Service, as illustrated in Figure 2.

DICOM network image management provides two important operational capabilities that are lacking in systems that use generic file transfer protocols. These capabilities are enabled by the explicit semantics of DICOM. Explicit semantics means “shared understanding between client and server of the information structure of objects” as well as a shared understanding of methods (functions or services). Having a standard template (information object description) of properties of each type of image (including a small sample of associated demographic and procedure-related information), the receiving device is aware of the information structure of the image before receiving it. This shared understanding enables storage and retrieval of sets of images using a clinically relevant indexing system based on image attributes rather than on a file name alone. With DICOM it is possible for a device to search for images using a meaningful query key such as the patient's name. Once received the image can be stored in context with others that relate to it. Explicit semantics also enables software processes to allocate appropriate resources for management of each class of DICOM object.

Five DICOM network image management services (transaction types) are specified in the Storage, Query/Retrieve, and Storage Commitment Service Classes. The services specified in these Service Classes are defined only for DICOM composite objects. The Storage Service Class specifies the C-STORE service. C-STORE enables a client to transfer (push) a DICOM object to a server for storage. In the negotiation that occurs between client and server processes at the establishment of a DICOM C-STORE association (session), the client notifies the server of the class of object that it proposes to transfer and the server confirms that it supports that information object class. A unique service class identifier, the (Storage) SOP Class UID, is defined for storage of each information object class so that the server can allocate appropriate resources.

The Query/Retrieve Service Class specifies the C-FIND, C-MOVE, and C-GET services and the DICOM query/retrieve information model. The C-FIND, C-MOVE, and C-GET services are specified in the context of a specific view of the query/retrieve information model that defines the semantics of queries and constrains the set of keys. The desired view of the query/retrieve information model is selected by sending the appropriate (Query/Retrieve) SOP Class UID in the query request message.

The C-FIND service enables a client to query a server for matches against a template of key values. C-FIND also enables the server to return the object instance identifiers of any matching records to the client. The C-MOVE service enables a third party to initiate the transfer of DICOM objects between two locations. For example, an imaging workstation may use C-MOVE to invoke the transfer of DICOM image objects from a scanner to an archive. The C-GET service is essentially an inverse C-STORE. An application process uses C-GET to retrieve (pull) objects that match a set of key values.

Since 1995, all of the major diagnostic imaging modalities have been standardized. This list includes computed tomography (CT), magnetic resonance imaging (MRI), computed radiography, ultrasonography, nuclear medicine, radiofluoroscopy, x-ray angiography, and secondary capture (for digitized video). The DICOM Visible Light (VL) image specification (for endoscopy, microscopy, and photography) has been placed under revision control and is available for trial implementation.¹⁷ Network image management is the most widely implemented DICOM service. Products conforming to DICOM network image management are available from many vendors.

The Storage Commitment Service Class specifies the fifth DICOM network image management service. Storage Commitment enables an image source (most often an acquisition device) to obtain a commitment from an image storage device that images have been stored reliably (Fig. 4). Typically, two types of devices provide this service: long-term and short-term storage devices. Long term storage devices (image archives) commit to store images permanently. Short-term storage devices commit to retain images only for a limited time. For example, an acute-care hospital might use a high-throughput, medium-capacity storage device as an image distribution center to minimize waiting time for images of hospitalized patients. The intermediate storage device might later transfer the images to low-throughput, high-capacity optical storage media for permanent archival after patient discharge from hospital. The short term and the long term storage devices both commit to storage images reliably. However, they commit to different values of storage duration, retrieval latency (delay), and storage capacity. From the user's perspective, it is essential that devices claiming to provide reliable storage actually do so. To conform to the DICOM Storage Commitment Standard, devices must reliably store images and related information for at least a specified minimum duration and must meet or exceed other performance parameters stated in a DICOM Conformance Statement (see Specifying DICOM, below).

Figure 4.

Reliable storage. Storage Commitment is an extension of the basic DICOM Storage Service illustrated in Figure 2. After sending a set of images to an archive device, the scanner operator sends a Storage Commitment Request message to the archive. The purpose of the message is two-fold. First, the message requests the archive device to verify that all of the intended images have been received. Second, the message requests that the archive device assume responsibility for the safe-keeping of the images, so that the scanner can, for example, delete its local copies of the images. If all is well, then the archive returns a confirmation message to the scanner. If there is a problem with one or more images or with the entire operation, then the archive device returns an appropriate error message to the scanner operator.

Network Image Interpretation Management

Supplement 23 of the DICOM Standard defines a network image interpretation object (the Structured Interpretation SOP Class) and a corresponding interpretation storage service. At the time of this writing, the specification is under a formal revision control procedure and it will be frozen for trial implementation.

The Structured Interpretation information SOP class specification utilizes the composite service group. Therefore, the same set of services defined for images are used for Structured Interpretation objects. A Structured Interpretation SOP instance conveys observations that constitute a portion of the results of an imaging procedure. Supplement 23 illustrates the set of observation classes that are defined for observation reporting in DICOM (Table 1). Observations may be linked to other observations via relationships of specified relationship type. Supplement 23 introduces the ability to link text, code, and measurement concepts to sets of coordinates (i.e., link observations to the image features that evoked the observer judgments). This capability goes beyond the capture of observations. It enables documentation of observer knowledge.

Table 1.

DICOM Observation Classes

Observation Class	Description
Text	Free text or categorical text
Code	Categorical code or controlled terminology
Measurement	Measurement record encoded in structured form. (Note: Essentially a superset of the CODE observation class. A precoordinated network of diagnostic measurement concepts that are supported by HL7 and/or are known to be clinically useful, such as Measurement Name (i.e., Method), Measurement Method Modifier, Value, Units of Measurement, and Precision).
Coordinates	Spatial coordinates in a DICOM coordinate system
Audio_dictation	Digitized audio dictation of observation(s). (Note: Although audio dictation is digitized SOUND, audio dictation is distinguished as a distinct class because the data represent spoken language that conveys observational information produced directly by an Observer. Thus, AUDIO_DICTATION is essentially a superset of language-mediated observation classes, such as TEXT, CODE, and MEASUREMENT.)
Image	Binary representation of an image.
Sound	Binary representation of a sound. (Note: Although digitized sound data has time dependency, its importance and the special set of contextual information required to support it are sufficient to justify categorization as an Observation Class distinct from WAVEFORM.)
Waveform	Binary representation of time-dependent data.
Curve	Binary representation of vector data. (Note: The DICOM Curve IOD specifies a vector representation of n-dimensional data, and associated units. Thus, a DICOM Curve SOP instance can be used to convey a static representation of time-dependent WAVEFORM or SOUND data. However, the Curve IOD is only a minimal specification.)
Overlay	Binary representation of image overlay data.
HC_presentation	Binary representation of presentation data for hard-copy layout or formatting of an IMAGE, CURVE, OVERLAY, or WAVEFORM. See Section C.6.7.1.2.1 of the Standard for further definition.
SC_presentation	Binary representation of presentation data for soft-copy layout or formatting of an IMAGE, CURVE, OVERLAY, or WAVEFORM. See Section C.6.7.1.2.2 of the Standard for further definition.
Transposed	A placeholder that shall denote, in the Context specified by (flags), the Concept described by (referenced Observation UID.)
Document_image	Digital Image representation of document (Note: Although a DOCUMENT_IMAGE is a digital IMAGE, DOCUMENT_IMAGE is distinguished as a distinct class because the data may represent written language that conveys observational information produced directly by an Observer. Thus, DOCUMENT_IMAGE is essentially a superset of language-mediated observation classes, such as TEXT, CODE, and MEASUREMENT. The DOCUMENT_IMAGE may contain written or printed text, graphics, or other forms of information.)
Other	Binary data of unrestricted type.

The Structured Interpretation object is a highly adaptive generic message template that can be specialized for diverse applications by referencing the SNOMED DICOM Microglossary (Systematized Nomenclature of Human and Veterinary Medicine, College of American Pathologists, Northfield, IL).^18,20 The structured reporting object can be adapted to different specialty contexts by substitution of appropriate term lists as the domains of coded entry data elements. To ad a new type of report (e.g., a gastrointestinal endoscopy or cardiac catheterization report) to DICOM, no reballot of the Structured Interpretation object is needed. Necessary updates are accomplished by making appropriate additions to the SNOMED DICOM Microglossary database.

The Structured Interpretation object introduces the concept of observation subject (Table 2). Each observation made by an observer is tagged with an Observation UID (Observation Unique Identifier) and assigned to one and only one observation subject. This formalism enables aggregation of all observations for any given observation subject. The observation subject is particularly useful in obstetric ultrasonography, where it is frequently necessary to disambiguate observations of the mother from observations of the fetus. Observation subject permits observers to retrieve separately the observations of Twin A or Twin B recorded throughout the pregnancy in a series of ultrasound examinations and other procedures.

Table 2.

Observation Subject Classes

Enumerated Value	Observation Subject Class Description
Unconstrained	No contextual constraint of Observations to an Observation Subject
Procedure	Administrative context of the Imaging PROCEDURE and Interpretative PROCEDURE
Person	A living PERSON existing as an independent entity
Fetus	An unborn baby carried within a living mother
Specimen	A SPECIMEN derived from the physical substance of a PERSON or a FETUS
Data	Binary data. Observation instances of the DATA Observation Subject Class shall describe only technical factors intrinsic to the data acquisition process. Examples of technical factors include description of the: Exposure quality of a digital radiograph; positioning of an Imaging Subject; static offset of a dynamic waveform; selective high frequency attenuation of sound; or magnetic field inhomogeneity artifacts in magnetic resonance image. An Observation having Observation Subject Class (0040,A403) = “DATA” shall not describe the intrinsic properties of a PERSON, a FETUS, a SPECIMEN, or any OTHER observation subject. Observations having Observation Subject Class = “DATA” may, however, be linked via the Relationship Sequence (0040,A731) to instances of any other class of Observations (defined for any class of Observation Subject).
Other	All other classes of Observation Subjects

The Structured Interpretation specification was adopted in December 1996 by the National Electrical Manufacturers Association (NEMA) Ultrasound industry group for trial implementation. As of January 1997, trial implementation projects are planned in radiology, pathology, gastrointestinal endoscopy, dentistry, and ophthalmology.

Network Print Management

DICOM Network Print Management enables image acquisition devices and workstations to share a printer on a DICOM network (Fig. 5), similar to the way that personal computers share a networked laser printer. Annex H of PS 3.4 specifies the Print Management Service Class.²¹ The DICOM Print Management specification defines a core set of mandatory functions and some optional extensions. Four meta SOP classes (sets of interdependent objects designed to be used in a coordinated manner) are specified to support basic printing applications. The mandatory meta SOP classes support (1) basic grayscale printing, (2) basic color printing, (3) grayscale printing with lookup table enhancement, and (4) color printing with lookup table enhancement. At least one of the four mandatory meta SOP classes must be implemented in order to claim conformance to the Standard. Any combination of optional SOP classes may also be used. The optional SOP classes enable film annotation, image overlays, and enhanced reporting of print job execution status.

Figure 5.

Network printing. In preparation for printing, the workstation first establishes a communications session with the printer (a Print Management Association, established in a similar manner as the Image Storage Association illustrated in Figure 2). At association establishment, various details are negotiated. Then the workstation informs the printer of the desired layout of the printed output so that the printer can prepare the appropriate format to receive the images. The workstation then sends the images, one by one, to the printer. The printer returns status notifications to the workstation so the user can monitor the progress of the print job.

The Basic Grayscale Print Management Meta SOP Class is described in more detail to illustrate the need for a coordinated group of Print SOP Classes. The Basic Grayscale Print Management Meta SOP Class includes the Basic Film Session SOP Class, the Basic Film Box SOP Class, the Basic Grayscale Image Box SOP Class, and the Printer SOP Class.²¹ Since film sessions may contain many films and films may contain many images, the SOP classes that represent them must support similar relationships. Therefore, a Basic Film Session SOP Instance references one or more Basic Film Box SOP Instances and a Basic Film Box SOP Instance references one or more Basic Grayscale Image Box SOP Instances. Basic Grayscale Image Box SOP Instances convey the actual pixel data. In addition, films may reference text annotation objects and images may be associated with overlays.²¹ N-ACTION services are defined for printing any single film or the entire session.

The Printer SOP Class represents the printer device. Printer status notifications are supported by the N-EVENT_REPORT service.

At the time of this writing, a DICOM PostScript Print Service Class, a revised Print Queue SOP Class, and a Print Storage SOP Class are in the final phases of development. The Print Storage object will enable the storage of print presentation parameters so that duplicate images identical to the originals can be produced later from the soft copies.

Imaging Procedure Management

The study management SOP Class and study component management SOP Class provide comprehensive imaging procedure management capability. Study SOP instances map to requested procedures, and study component SOP instances map to performed procedure steps. They are normalized SOP classes. As such, they support the N-SET and N-EVENT_REPORT services and provide state management and event notification facilities. Supplement 17, Performed procedure step management, is nearing completion at the time of this writing. This draft supplement provides a small number of new attributes for description of imaging procedures and enables better coupling of the study component (performed procedure step) with the new DICOM Modality Worklist SOP Class (see below for further description).

The DICOM composite query-retrieve model (see above) provides a mechanism for building a hierarchical database of patients, studies, series, and images. This image model has been used widely as the basis for imaging procedure management databases, particularly where image acquisition devices are not linked to an external information system (IS). In this non-IS-aware scenario, procedure identifiers may be assigned by the imaging equipment. This leads to a need to reconcile procedure identifiers with another system, post facto.

The DICOM normalized and composite imaging procedure (study) management paradigms intersect in the Study Instance UID data element (DICOM tag: 0020,000D). This is a mandatory data element that is defined in all composite image SOP classes and in the normalized study management SOP Class. Thus, it is possible to map between the composite and normalized perspectives via the Study Instance UID.

The basic modality worklist SOP Class utilizes a new query-retrieve model that is designed to improve access to demographic and scheduling information residing on non-DICOM information systems. DICOM does not have a procedure scheduling facility. However, a DICOM scheduling system is not necessary in environments where a scheduling system already exists. An imaging device can obtain the necessary information by querying the external system. The external system can either implement a DICOM service-class-provider process for modality worklist, or it can communicate with the imaging system through a gateway. The modality worklist SOP class includes only a query model. Therefore, there it does not provide a way to notify the information system of state changes in the scheduled procedure (such as “canceled” or “completed”). This capability being added performed procedure step (revised study component) SOP Class (Fig. 6).

Figure 6.

Obtain a worklist. The modality worklist is an itemized list of imaging procedures that are scheduled to be performed on a particular scanner or on any scanner of the specified imaging modality type. The original requests for imaging procedures are first received and processed by an information system. The order entry and/or scheduling application of the information system schedules procedures and prepares worklists for the appropriate imaging equipment. At periodic intervals (determined by department policy) the scanner polls the information system for an updated worklist. Upon receiving a worklist request, the information system sends the current worklist to the scanner. The DICOM Worklist Management service class does not specify how the information system is notified that a worklist item is complete. This is done by another DICOM service that manages Performed Procedure Steps.

Joint work with Health Level Seven (HL7), Inc., on a standard mapping of the DICOM modality worklist information object definition to the HL7 Standard is underway at the time of this writing. The goals of this work are to achieve a good mapping of common attributes to facilitate gateway design in the short term and to work toward a common HL7 and DICOM understanding of the Information System-Imaging System interface. In spite of the usefulness of the new modality worklist query model, there is still need for improvement in DICOM query facilities. A structured query language (SQL) approach is desirable, but consensus on the messaging protocol for “DICOM SQL” has not been reached.

Off-line Storage Media Management

DICOM Off-line Storage Media Management enables users to manually exchange DICOM files on removable storage media. There is a DICOM file format for 3.5-inch diskettes, compact disk read-only memory (CD-ROM) disks, and optical disks. A DICOM file can include not only images but also the related information that distinguishes one image from another (e.g., pertinent details of the performed procedure, interpretation text, or the format settings for printing). The possibility of sending image-related information is one of the most important features that distinguish DICOM from the many image file standards that are limited to image data alone. DICOM defines a file format and a file directory for images and related information. Users can specify preferred types of physical media to transport DICOM files for a particular clinical imaging context (e.g., coronary angiography, general diagnostic ultrasonography, gastrointestinal endoscopy). For example, the Cardiology community in the United States has specified the storage of Coronary angiograms and cardiac catheterization images on compact disk read-only media using Joint Photographic Experts Group lossless compression. Other possible applications of DICOM Off-line Storage Media Management are transport of diagnostic images from a portable imaging unit to a consulting department or from a diagnostic workstation to a clinical conference room.

Clinical Scope of DICOM

The immediate predecessor of the DICOM Standard was the ACR-NEMA Digital Imaging and Communications Standard.⁵ The basic principles of this Standard have been refined and generalized in DICOM to be capable of handling diagnostic and therapeutic images of any type. The multimodality and multispecialty capability of DICOM has attracted interest from all specialties that perform biomedical diagnostic or therapeutic imaging (including dentistry and veterinary medicine).^13,19 In 1996, the DICOM Standard supported the following diagnostic imaging modalities: x-ray angiography, computed radiography, computed tomography, magnetic resonance imaging, nuclear medicine, radiofluoroscopy, and ultrasonography. The x-ray angiography specification also fully supports angiography (general arteriography, lymphography, and venography; cardiac catheterization and coronary angiography; carotid and cerebral angiography); fluoroscopy (such as arthrography, gastrointestinal barium examinations, myelography); and interventional procedures. At the time of this writing, major new supplements to the DICOM Standard are being prepared for ballot, including positron emission tomography, radiation oncology, visible light imaging, and structured reporting. The Visible Light Image Supplement has been introduced to support diagnostic imaging devices (endoscopes, microscopes, and cameras) that produce reflection or transmission color photographic images. The Visible Light Supplement also specifies a new anatomic frame of reference for imaging modalities that do not use a patient-based coordinate system, but describe orientation in terms of anatomic landmarks.¹⁷ The imaging procedures supported by the DICOM Visible Light specification include:

• Fiber-optic and rigid-scope endoscopy (e.g., angioscopy, arthroscopy, bronchoscopy, colposcopy, cystoscopy, fetoscopy, hysteroscopy, gastrointestinal endoscopy, laparoscopy, nasopharyngoscopy, sinoscopy)

• Light microscopy for anatomic pathology (e.g., transmission light microscopy and reflection light microscopy for cytology and histology)

• Surgical microscopy (e.g., images produced by operating microscopes used in cardiothoracic surgery, general surgery, neurologic surgery, obstetrics and gynecology, ophthalmologic surgery, oral and maxillofacial surgery, orthopedic surgery, otorhinolaryngology, pediatric surgery, plastic surgery, urologic surgery and vascular surgery)

• General anatomic photography (e.g., anatomic pathology, biostructure, dermatology, dentistry, forensic pathology, ophthalmology, and general medical and surgical applications)

How Does DICOM Affect Daily Work?

Strategy for Filmless Image Management

Since the 1970s, there has been a growing expectation that all medical images soon would be managed neatly and efficiently in digital form. The term “Picture Archiving and Communications System” was coined in the Radiology literature to describe a departmental digital image management system. In the 1990s, great strides have been made toward achieving a filmless Radiology department.^{6,7,8,9,10,11} The DICOM Standard and the earlier versions of the American College of Radiology, National Electrical Manufacturers' Association Standards have contributed substantially to this progress. While filmless Radiology departments are being tested in a few major hospitals, the typical hospital or imaging center first uses DICOM to support various subsets of imaging instead of linking up a complete department at once. This is a practical approach. DICOM provides the user with the flexibility to develop an image management system in manageable steps. Designing a system around DICOM can prevent a department from being “trapped” by a single vendor and limited to a proprietary family of products. Naive implementation of DICOM does not guarantee this flexibility, however. It is necessary to understand precisely what can be expected from the Standard.

Realistic Expectations

Grouping images having similar properties into various different types of manageable “information objects” allows software to manage diverse things in a sensible manner. “Management” of information over computer networks implies the coordination of work across multiple computers. As is typical in the general computing industry today, DICOM uses the concept of “client-server computing” as the organizational model for specifying what functions devices and software agents must perform. DICOM was written in terms of service-class-users (clients) and service-class-providers (servers). Options for the composition of a DICOM message are specified explicitly right down to the lowest levels, such as determining whether, for example, data is represented with the most significant byte first or last.

One of the reasons that DICOM has been successful in a wide variety of clinical imaging contexts is that the Standard specifies a Conformance Statement that improves the communication of software specifications for imaging equipment. The Conformance Statement includes all of the details introduced in the preceding paragraph and many more (see Specifying DICOM, below). The DICOM Conformance Statement provides a means by which a customer can evaluate in detail whether a certain product provides the image management functions that are desired and a vendor can specify the precise description of the DICOM image management functions provided by equipment offered for sale. With all of the material that manufacturers must provide to support their claims of conformance to DICOM, it would seem that the specification of DICOM would ensure a “plug and play” image management system. As much as those who worked on DICOM would like this to be true, there are very few applications for which this will be the case.

Here is an important caveat for the reader. One must keep in mind that a simple advertisement stating that a piece of equipment “conforms to DICOM” does not alone guarantee the manufacturer has adhered to the Standard. One must ensure that the manufacturer provides equipment that operates precisely in the manner specified in the Conformance Statement. This means that, for many of us, expert consultation may be required for proper specification of a purchase contract for imaging equipment. A health care professional with no expertise in digital imaging systems should not expect to find the complete guide to “plug and play” image network specifications in the DICOM Standard. While this may be seen by some as a shortcoming of DICOM, it is actually a reflection of the complexity of diagnostic imaging per se. The many modules and user-configurable options provided by DICOM support an enormous variety of clinical imaging practice contexts. The Standard provides a means for a knowledgeable expert to specify systematically the image management features of a particular system.

DICOM and the User

The user of DICOM-based systems can reasonably expect to gain a much simplified way of interfacing imaging equipment and having it interoperate. In some instances, interfacing can be very nearly a “plug and play” experience. At the hardware levels, connection is straightforward. Things like setting the network addresses and some of the DICOM options that are set at installation must be configured by an engineer. The end result is a reliable communications interface.

At the level of image display, the user can expect that images will be displayable at the spatial and contrast resolution values at which they were acquired. Also, the patient demographic information and information about the manner in which the image was acquired will be accessible. For imaging that uses sequences of images (ultrasound, nuclear medicine, angiography, endoscopy, and microscopy) cine-type displays can be supported. If the display systems support it, color images (pseudo-color for ultrasound or nuclear medicine and direct visualization color for photographic applications such as endoscopy and microscopy) are also displayable.

At the level of data entry, DICOM influences the task of the user. The information associated with each image has been prioritized into three categories. Very few mandatory elements are specified. These are typically identification numbers of images and similar units of information that are automatically entered by the computer (without disturbing the user's train of thought). A second class of information is that which is judged to be of special clinical importance. Fields such as Patient Name and Patient Identification Number are of clinical significance; however, if the information in unknown, a null entry may be given. Such “clinical priority” fields are created parsimoniously, since they do place a burden on the user. The final category of DICOM information elements are the user-optional fields. Ideally, upon the advice and approval of the users at each site, a manufacturer may implement any number of the optional DICOM data entry fields. A wide variety of optional descriptive fields is available. One must settle on a reasonable compromise and select a user interface according to well-known design principles and individual preferences.

For a number of data fields, DICOM provides either “Enumerated Values” or “Defined Terms.” For example, for a few attributes, such as “laterality of a paired body part,” DICOM defines a mandatory set of enumerated values. Enumerated values are defined by the standards committee and may be changed only by re-balloting the Standard. For example, the following choice is mandatory for laterality: “right” and “left.” In order to conform to DICOM, a system must present these and only these two options to the user. However, for other attributes, the standards committee offers a set of typical selections that can be refined by the users to carry out local requirements. For example, the DICOM field for “film cassette size” offers a series of typical dimensions. This list can be extended or replaced by a list that suits the local environment.

The trend in computer-based record systems is to increase the proportion of clinical information that is recorded in a structured format rather than in freetext format. Since structured data entry places an additional burden on the user, DICOM provides both free-text and coded-entry options. Where structured encoding is needed, the fields are available. Where simple free text may suffice, the option is present. For complex concepts, such as anatomy, morphology, and physiologic function, DICOM simplifies the task of structured encoding by offering subsets of terms that are appropriate for data entry. For example, the anatomic reference points that identify the location of direct visualization color images may be selected by the user from a short pick-list rather than from an unabridged list comprising literally thousands of anatomic sites. Appropriate pick-lists of anatomic structures and spaces can be specified for any clinical context.

Multi-specialty imaging terminology for DICOM coded entry data elements is available in the SNOMED DICOM Microglossary.^18,20 Terminology covers a variety of concepts, such as anatomic structures, spaces, and regions; morphology; function; physical agents; chemical and biologic products; living organisms; and geometric and spatial terms. With technical assistance from the College of American Pathologists, medical professional specialty societies are jointly developing content for the SNOMED DICOM Microglossary. As of January 1997, basic term lists have been completed for the coded entry data fields of the DICOM X-ray Angiography, Nuclear Medicine, and Ultrasound Standards. The American and European Societies for Gastrointestinal Endoscopy, the American Academy of Ophthalmology, the American College of Chest Physicians, the American Urological Association, the American College of Cardiology, the American Society for Echocardiography, and other organizations have provided terminology that adapts the trial-use DICOM Visible Light and Structured Reporting standards to their clinical contexts. In summary, the structured encoding of complex information is an area where DICOM can have a major impact on the working environment of the user. DICOM is designed to allow users to benefit immediately from technologic advances that increase the efficiency and precision of structured encoding and enhance information retrieval.

Connecting Imaging Equipment to Existing Information Systems

DICOM allows imaging modality equipment operators to receive worklists (lists of imaging procedures that are scheduled to be done on their equipment). This worklist capability reduces duplicate data entry at the modality console. The DICOM modality worklist interface also allows the user to query another information system about additional details of a requested procedure or about a patient. Development of this modality worklist component of the DICOM Standard was initiated by a working group of the European Standardization Committee. This portion of DICOM is now a Standard or Pre-Standard in Europe, Japan, and the United States. In June 1996, products implementing the DICOM Modality Worklist standard were demonstrated at the Computer Applications in Radiology (CAR) Congress in Paris. The DICOM modality worklist specifications are being mapped to the Health Level Seven (HL7) general information system Standard (Health Level Seven, Inc., Ann Arbor, MI). Users of DICOM systems will benefit from this HL7-DICOM mapping work, since the majority of hospital information system vendors already provide HL7 interfaces for their scheduling and patient demographics management systems.

A joint committee of HL7 and DICOM, the HL7-DICOM Image Management Group, is developing a standard approach to HL7-DICOM interconnection that will simplify installations and may reduce interface development cost for individual sites. The interface is known as the “HL7-DICOM Information system-Imaging System interface.” (This name is abbreviated variously as the “HL7-DICOM ISIS interface,” the “HL7-DICOM interface,” or the “ISIS interface” between HL7 and DICOM.) Since work on the HL7-DICOM interface is progressing rapidly at the time of this writing, we suggest that interested persons obtain the latest information via the WWW. All documents are available on a server provided by Duke University Medical Center. The Universal Resource Locator address of the HL7-DICOM Image Management Group is http://dumccss.mc.duke.edu/standards/HL7/committees/image-management/im-home.html.

It is important for the user to understand that DICOM enables these capabilities to users but that the implementation is still dependent on manufacturers and institutions. The standardized nature of these services and information, though, means that the development time and availability of such capability will be much improved. It should also mean a wider availability of such functions.

DICOM Evolution

The expansion of DICOM into more complex image management scenarios, information system interfacing and structured encoding of interpretations are areas where DICOM will have a direct impact on users. The refinements that are constantly being introduced in the “back-end” mechanisms of DICOM in terms of hardware interfacing, image communications, concept representation and image display will enable steady improvements in the “front-end” application software that is visible to the user. DICOM development has already extended across multiple specialties and national boundaries, and the expansion into the information management environment is rapidly progressing.¹³ For users, this will mean that their DICOM-supported image management systems can be integrated into healthcare enterprise information systems.

How Can One Take Advantage of the Benefits of DICOM?

Specifying DICOM

The DICOM Standard exists primarily to address the long-standing requirement for communication interoperability among medical imaging devices. Equipment vendors are required by the Standard to provide Conformance Statements that accurately describe their DICOM implementation. Conformance in this context means compliance to the requirements of the Standard. More concretely, the capabilities and behaviors of an implementation must match both the conformance requirements of the Standard and a vendor's conformance claims.

A Conformance Statement is a document that a vendor must provide to customers in order to clearly describe what parts of the DICOM Standard are supported by a particular piece of equipment. DICOM includes a broad selection of services (e.g., storage, query/retrieve, print) and a variety of options within each. Any implementation will logically include only a subset of functions and optional elements. In order to know whether system A can communicate with system B, it is necessary to have a complete and precise description of the capabilities of each system. The purpose of a Conformance Statement is to provide a meaningful and comparable list of capabilities of each system.

The goal set forth by the drafters of the DICOM Standard is to allow a knowledgeable user to determine if interoperability between two implementations is possible by comparing their Conformance Statements.¹⁴ It is important to note that, if the Conformance Statements are complementary and the vendor's implementations are adequately and accurately described by these statements, the probability of interoperability is greatly increased, but it is not ensured. It is not possible to prove interoperability by examining Conformance Statements alone. It is possible, however, to prove the impossibility of interoperability.

What is perhaps more important, however, the Conformance Statement may be viewed as a set of testable claims that the vendor makes concerning the behavior of a specific system. Vendors are required to conduct thorough conformance testing to ensure that their implementation correctly and fully matches the claims made in the Conformance Statement. Thus, the Conformance Statement serves as a testing guideline for the vendor long before it is distributed to users.

A Conformance Statement is a highly structured document designed to make the key attributes on an implementation readily apparent. A DICOM Conformance Statement comprises four main sections: Problem Statement, Application Entity Specifications, Communication Profiles, and Specializations. The initial segment of a Conformance Statement must identify the domain of application of the implementation: e.g., “transferring images from an MR scanner to a storage device.” The Conformance Statement must indicate how this implementation is designed to interact with the real-world. This initial Problem Statement sets the scope of the document.

It is assumed that a DICOM implementation will consist of one or more packages of hardware and software. These packages or Application Entities are identified in the second section of the Conformance Statement and given names. The bulk of a Conformance Statement is given over to completely specifying the functionality and constituent components of these packages. Each software process will implement one or more DICOM services and will be defined either as a user or a provider of that service. Each software process will encode information in at least one but possibly several different ways. Finally, each software process will have rules governing when it will accept or initiate connections to other DICOM systems. Taken together this information yields the section of the Conformance Statement known as the “Application Entity Specification.”

DICOM is a communication standard. Logically, one would expect that a detailed engineering specification of the communication software or protocol to be a part of a Conformance Statement.¹⁵ A description of these components is required in section three of the DICOM Conformance Statement. The Conformance Statement must identify which of the available communication protocol options is used. It also must provide necessary implementation details such as which Media Access protocols (e.g., FDDI, Ethernet, ISDN) and which physical media (e.g., fiber, coaxial cable, twisted pair) are supported.

The DICOM Standard is defined to be extensible. An implementer may include additional optional attributes in a standard object, such as an image, and really not impact another implementation's ability to utilize that object. If, however, a vendor chooses to add attributes that are essential for the interpretation of the object, or to define totally new objects not currently covered by DICOM, it is important that this fact be clearly communicated in the Conformance Statement. The goal of DICOM as implemented in Conformance Statements is to eliminate surprises when two systems are interconnected. The use of private attributes and objects should be discouraged by the user community since this greatly limits the possibilities for interoperability. However, if private attributes and objects are utilized the final section of the Conformance Statement must contain a complete description so that other vendors might have a possibility of adapting to them.

The first requirement that a vendor must meet when claiming DICOM conformance is the availability of a proper Conformance Statement. Given that the vendor meets this requirement, what is the next step? What does a user or system integrator do with these statements? Let us assume two hypothetical systems: A and B that we wish to interconnect via DICOM, If we examine the Conformance Statement for these systems there are several obvious areas where incompatibility may arise. For example, if both systems support DICOM storage but A only supports MR images and B only CT images, then the two systems will not be able to communicate. Similarly, if A uses DICOM over TCP/IP on an Ethernet and B uses DICOM over an ISO protocol stack on an FDDI, communication is impossible. More subtle differences are equally significant. For example, if both systems support CT image storage using the same communication stack, it would seem that they could talk; however, if both indicate that they can only play the role of service user (both are clients), communication is in fact impossible.

By analyzing the DICOM Conformance Statements of potentially interconnected equipment is is possible to rule out some configurations without going to the expense of actually buying the systems and connecting them. If two systems seem compatible based on Conformance Statement analysis, it is still necessary, unfortunately, to test whether or not they can actually communicate. Experience has shown, however, that the probability of communication is high if the Conformance Statements match.

Caveat Emptor

Because DICOM supports a broad range of options in the categories of communications, structure of the data, and functions to be performed by image management devices, simply calling for “DICOM conformance” may not be enough to ensure that devices will work together appropriately. If a system that supports DICOM is already in place and a user is seeking equipment that can interface to it, the user should review the Conformance Statement of the existing equipment to determine what it supports. These choices can then be included as requirements for DICOM conformance on the part of new equipment.

If a completely new environment is being developed, and DICOM is anticipated as the interface standard to use, the specification problem is more difficult because the user does not have an established base from which to work. If there is sufficient in-house experience, local engineering personnel can review the Conformance Statements of various vendors and determine with some degree of certainty whether or not two devices will work together. Without such engineering expertise, the user may have to rely on manufacturers or a consulting engineer. One way to help avoid problems is to require all equipment vendors to review their Conformance Statements together in a meeting with the user (and any necessary technical consultants). This puts the burden of determining and guaranteeing interoperability on the manufacturers supplying the equipment.

Summary

DICOM provides a well-tested and widely accepted foundation for Network Image Management, Network Image Interpretation Management, Network Print Management, Imaging Procedure Management, and Off-line Storage Media Management. While the main focus of DICOM is diagnostic imaging, the Standard was developed with the capability to be extended and expanded in modular fashion to support new applications and incorporate new technology. An interface to other Information Systems provides for “shared” management of patient, procedure, and results information related to images. A Conformance Statement template is defined, consisting of four main sections: Problem Statement, Application Entity Specifications, Communication Profiles, and Specializations. A knowledgeable user can determine if interoperability between two implementations is possible by comparing their Conformance Statements. DICOM gives vendors the option to build imaging devices that will function properly with those made by others and gives users the ability to plan a new system or to extend an old system without proprietary barriers. Knowledge of DICOM's benefits and realistic understanding of its limitations enable one to use the Standard effectively as the basis for a long-term implementation strategy for image management and communications systems.