Standards Watch | What DICOM? Why Not Simply Use HL7?

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

I get this question about every other month, sometimes in the forms of: "When will DICOM be replaced by HL7?", "Wouldn't HL7 version 3 make DICOM obsolete?", "Why not use one standard?"

Unfortunately, the DICOM standard and its specifics are still somewhat unknown outside the imaging domain, otherwise these questions would not be asked.

The short answer to the above question is: "No way." First, one should realize that the main purpose of the DICOM standard is to exchange so-called "persistent" objects, which is not quite possible (yet) using HL7. An example of a persistent object could be a digital image from a CT, MR, ultrasound or other digital acquisition device.

It is called persistent because we expect to archive the image, similar to x-ray film of today. These images go into a patient folder and stay there until the required legal time to keep these images expires, which could be five years, 21 years for minors or a lifetime for certain examinations.

Additionally, persistent objects are not to be changed and/or modified in any form that impacts its clinical meaning; for example, changing the image processing of a digital image. If so, the software would generate another (modified) version of that image and store the image in the same patient folder, possibly identified as part of a new series that is part of the study for the patient.

The HL7 standard, in contrast, is much more of a transaction-based protocol, whose messages are generated based on certain events, such as a patient arrival, placing an order for an examination, etc. These different applications and uses have resulted in a different approach and protocol, which is optimized for either domain.

Another difference is that the information in HL7 messages is encoded in ASCII text format, which is intended to be "human interpretable." Compare that with a pixel value of an image as part of a DICOM message, which is a binary value. This value represents, for example, the x-ray attenuation in the case of a CT image, frequency response for an MRI image, or is a measure for velocity for a Doppler ultrasound image. Representing these binary values in ASCII text does not only make any sense, but is very inefficient.

There is an activity within HL7 standards as part of the version 3.0 that defines a persistent object as well. It contains basically the complete patient folder with all measurements, images, results of tests, etc. This so-called clinical document architecture (CDA) has great promise to be used as the kernel for the electronic health record (EHR).

The road to implementing an EHR has been somewhat bumpy over the past 20 years. There were a couple of attempts and a few implementations worldwide, particularly in the United Kingdom, Finland, Taiwan, New Zealand, Germany and some in the United States. The good news is that there will be a major push toward implementing this further in the coming years.

Knowing that an EHR saves money, time and is more efficient, the U.S. government, in particular the Center for Medicare and Medicaid Services, is sponsoring an effort to define the functional requirements for the EHR. The clinical document architecture, however, still has as a requirement that the information encoded inside this object should be "human-readable" and/or easily interpretable. If it is required to include a diagnostic image, it makes sense to include a reference pointer to where the image can be retrieved, rather than duplicating the image itself.

Another argument for not duplicating all the images outside the imaging department is the steady increase of the amount of data that is generated. The latest and greatest CT scanners generate 16 slices in a single rotation, which takes about 1/2 second, and there are systems in the vendor's respective laboratories that have multiples of the number of current detectors. The same applies for cine runs for cardiology or angiography. Why export multiple runs of several seconds of digital data? As long as one knows where and how to find this information encoded as DICOM objects, it is OK.

There could be potentially some overlap in the usage of DICOM and HL7; specifically in the area of reports, as well as some of the patient and study management applications. First of all, reports: In DICOM, there is a construct called structured report (SR), which is generally used when there is contextual information to be exchanged that is related to one or more images. A good example is a measurement that is done