Standards Watch | DICOM Turns 20: A Retrospective and a Look Forward

Twitter icon
Facebook icon
LinkedIn icon
e-mail icon
Google icon

A large group of DICOM geeks, gurus and other interested parties gathered in September in Baltimore to celebrate the DICOM (digital imaging and communications in medicine) 20-year anniversary. The event provided a good opportunity to reflect on the accomplishments of the past two decades, and how we arrived at where we are today.

The DICOM standard was an initiative of the American College of Radiology (ACR), whose members were frustrated at the lack of technology available to connect their workstations for 3D processing, radiation therapy or any other application that required image data as input. Actually, connectivity was possible, providing each workstation was from the same vendor. The connectivity issues surfaced when using equipment from multiple vendors. The ACR found a forum of listeners at the National Electrical Manufacturers Association, (NEMA), and voila, the ACR-NEMA standard effort began in 1983.

DICOM's first decade was rather uneventful. Two versions of the ACR-NEMA standard were issued; a couple of manufacturers developed hardware and software and implemented it. The greatest learning gleaned in the first 10 years was more from how NOT to connect it than how to solve the problem. This learning process resulted in a completely new communication version; i.e. the DICOM standard, which was issued in 1992. It was called DICOM 3.0 to differentiate it from the two earlier ACR-NEMA versions.


The early standard versions emphasized more the protocol, i.e. how to exchange images than the actual image encoding itself. The notion of persistent objects is that each image is unique by itself and should be identified by a unique identifier (a.k.a. UID) to differentiate itself from other images. In addition, it also is identified as part of a unique group of related images (Series), belonging to a unique examination (Study). The word "persistent" suggests that it survives beyond a particular transaction - e.g. if sent from a CT scanner to a PACS archive - and it can be identified at the destination as uniquely different from other images that belong to that study. If a physician wants to change the image in a manner that could impact the clinical interpretation, such as applying different image processing, he should generate a new version of this image, which is again uniquely identified. Through these identifiers, or UIDs, a receiver can determine where to store the image in the database and how to update its tables with respect to the number of images in a Series and Study. The identifier also allows queries from other devices needing to retrieve that information.

With regard to the encoding, a DICOM image has several components. It contains the pixel values, representing the actual image data, and also information on how to interpret the image pixels (such as whether it is black/white, color, the number of bits, etc.). In addition, it has information in the header about the image context, such as whose image it is (e.g. from a 37-year-old female with a particular name, ID, etc.).


The many available features within the DICOM standard can be compared with a "menu" where different manufacturers may select various items. A device that supports the DICOM protocol is required to have DICOM conformance statements available. This notion was revolutionary for a healthcare standard. It wasn't until many years later that other standards, such as HL7, were
started, including conformance sections as well. Conformance statement documents have proven invaluable in determining compatibility between imaging systems upfront, instead of finding out particular communication issues during installation. Currently, there is a major rewrite activity taking place that will improve the generation of these documents by providing more detailed guidelines with several examples available that potential implementers can use. The section of the standard (part 2), which includes these guidelines, will be completely replaced, and will be available before the end of the year.


The original ACR-NEMA standards were based on a point-to-point protocol, which required a so-called network interface unit (NIU). The NIU was used in lieu of a clear candidate for network standards. As a matter of fact, even the initial DICOM standard had two networking options: using TCP/IP as the transport protocol or OSI (open systems interconnection). Since then, TCP/IP clearly evolved as the standard, and is now the