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

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.

PERSISTENT OBJECTS

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 VALUE OF CONFORMANCE

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.

NETWORKING

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 main method of data communication.

Other improvements of the last decade that segued into the implementation of DICOM:

RIS interface: The initial DICOM standard had (and still has) "Visit," "Patient," and "Study Management" services that were intended to exchange patient demographic and ordering information between radiology scheduling systems, in particular, radiology information systems (RIS). Early implementations, in particular from the Department of Veterans Affairs (VA) hospitals, identified several shortcomings with these DICOM services and extended these services with VA-specific features. These services were replaced with a new service, modality worklist (MWL), which since has become a basic requirement for any digital acquisition modality. The MWL allows a modality to query a RIS for exam scheduling information, including patient demographics and order specifics. Starting an exam has become as simple as 1,2,3: 1.) retrieve exam list; 2.) select patient, which copies demographics and translates the ordered procedure into the proper technique; and 3.) start exam. The MWL implementation has given a major push to successful PACS implementations because of its impact on the efficient information exchange between RIS and modalities and the overall data integrity preservation it provides.

Profile definitions: Even though this activity took place as part of the Integrating the Healthcare Enterprise (IHE) effort, profile definition development was created from a DICOM perspective by the same group of people involved with the DICOM standardization effort. Profile definitions allow for a new level of interoperability. Even though a fairly good mechanism exists to define the DICOM features of different devices using conformance statements, there is still a chance that menu items picked by one device won't correspond with the choices made by the device it wants to communicate with. Hence, the creation of defined sets of transactions, their contents and sequencing, not only within the imaging domain using DICOM, but also spanning the IT domain using the HL7 standard. One can view these sets of transactions as if they were the "value meals" at a fast-food restaurant, which are so specific as to define the menu choices, and even sizes (e.g. large drink). This group profile effort has been very successful. Close to 50 percent of the user community has started to request, not only DICOM compliance in their request-for-proposals (RFPs), but also compliance with certain IHE profiles. The scheduled workflow profile is probably the most successful, specifying how a RIS interacts with a modality and PACS to exchange patient demographics and order information, the number of images and related information as well as status updates.

There is still a lot of work to do. Other specialties, such as ophthalmology, dental and endoscopy are just starting to come on board. There is a proposal for attaching DICOM images to e-mails in discussion. In addition, the definition of measurements and other clinical-relevant information in the form of Structured Report templates is under way. It is hard to look ahead another 20 years, but it is certain that for the next five to 10 years, there still will be a lot of work to do.

There is no question that the DICOM standard has made a major impact and facilitated successful PACS implementations resulting in increased productivity, efficiency, availability of images and related information - which is a good reason to congratulate DICOM and wish it many more healthy and successful years to come!

Herman Oosterwijk is president of OTech Inc., a healthcare technology consulting and e-learning company. He is also part of the adjunct faculty of the Health Informatics program at the University of North Texas. He participates in both the DICOM and HL7 standards activities. Question and/concerns as well as information on books and e-learning resources about PACS and connectivity can be addressed via his website: www.otechimg.com