Introduction to the DICOM Standard
The Beginnings of the Standard
Since the 1970s, when computed tomography was introduced as the first digital modality, the importance of digital medical image processing has been increasing steadily. The emerging idea of a digital image archive (PACS) and electronic image distribution in a hospital created the need to exchange digital images between medical devices of different manufacturers.
In 1983, the American College of Radiology (ACR) and the National Electrical Manufacturers Association (NEMA) formed a working group in order to develop an image exchange standard. The collective work resulted in the ACR-NEMA standard, which was published in 1985 and revised several times until 1988. However, due to certain conceptual weaknesses (no network support, different proprietary “dialects”), the ACR-NEMA standard was not very successful. As a consequence, the DICOM standard (Digital Imaging and Communications in Medicine) was developed on the basis of the experiences with the ACR-NEMA standard.
The main objective of this new standard was to create an open (vendor independent) platform for the communication of medical images and related data. Moreover, the new standard should support PACS networks and guarantee interoperability of arbitrary DICOM devices and programs. DICOM was published in 1993 and has been continuously extended ever since. In 1995, DICOM was accepted as a formal standard in Europe (MEDICOM, ENV 12052).
Overview of DICOM
The contents of the DICOM standard go far beyond the definition of an exchange format for medical image data. DICOM defines:
- data structures (formats) for medical images and related data,
- network oriented services, e. g.
query of an image archive (PACS)
print (hardcopy), and
RIS - PACS - Modality integration
formats for storage media exchange, and
requirements for conforming devices and programs.
DICOM Data Structures
A DICOM image consists of a list of data elements (called attributes) which contain a multitude of image related information:
patient information (name, sex, identification number)
modality and imaging procedure information (device parameters, calibration, radiation dose, contrast media) ,and
image information (resolution, windowing).
For each modality, DICOM precisely defines which data elements are required, which are optional (i. e. may be omitted) and which are required under certain circumstances (e. g. only if contrast media was used).
This provides great flexibility but at the same time leads to one crucial weakness of the DICOM standard because practical experience shows that image objects are frequently incomplete. In such objects, required fields are missing or contain incorrect values. This can lead to subsequent problems when image data is exchanged.
DICOM Network Services
The DICOM network services are based on the client/server concept. In case two DICOM applications want to exchange information, they must establish a connection and agree on the following parameters:
who is client and who is server,
which DICOM services are to be used, and
in what format data are transmitted (e. g. compressed or uncompressed)
Only if both applications agree on a common set of parameters, the connection can and will be established. The Storage Service Class is the basic DICOM service for image transmission:
There are also a number of advanced services, of which only a few can be mentioned here:
The DICOM image archive service (Query/Retrieve Service Class) allows to search images in a PACS archive by certain criteria (patient, time of creation of the images, modality etc.) and to selectively download images from this archive.
The DICOM modality worklist service allows to automatically download up-to-date worklists including a patient's demographic data from an information system (HIS/RIS) to the modality.
In addition to the exchange of medical images over a network, media exchange has become another focus which has been integrated into the DICOM standard in 1996. Fields of application are for example the storage or cardiac angiography films in cardiology or the storage of ultrasound images. In order to make sure that DICOM storage media are really interchangeable, the standard defines Application Profiles which explicitly define:
images created by which modalities may be present on the medium (e. g. only X-Ray Angiography images),
which encoding formats and compression schemes may be used (e. g. only uncompressed or loss-less JPEG),
which storage medium is to be used (e. g. CD-R with ISO file system).
Aside from the image files, each DICOM medium contains a DICOM Directory. This directory contains the most important information (patient name, modality, unique identifiers etc.) for all images which are captured on the medium. Using this information, it is possible to quickly browse or search through all images on the medium without having to read the complete image files - which would for instance take a couple of minutes when reading from a CD.
DICOM requires that a Conformance Statement must be written for each device or program claiming to conform to the standard. The format and content of a Conformance Statement is defined in the standard itself. In general, the statement shall explain which DICOM services and options are supported, which extensions and peculiarities have been implemented by the vendor, and how the device communicates with other DICOM systems. In theory, comparing two conformance statements allows to determine whether two DICOM compliant devices are able to communicate with each other or not.
In practice, conformance statements are only comprehensible by experts and they are frequently inadequate since often only a minimum set of features is documented. Interoperability problems, however, typically tend to occur because some “inconspicuous details” do not go together.
DICOM has become an indispensable component for the integration of digital imaging systems in medicine. DICOM offers solutions for many communication related applications - in a network as well as off-line. The keyword “DICOM” by itself, however, is no guarantee for a “plug and play” integration of all information systems in a hospital. Such a scenario requires a careful combination of all the partial solutions offered by DICOM.