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

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 on an image, e.g. of a certain mass or a detection of a certain pathology based on certain criteria as part of a computer-aided diagnosis (CAD) software package. It is possible to specify exactly where this observation was done in the image, and encode the type of observation, and/or measurement. Traditionally, diagnostic reports have always been the domain of the HL7 standard, and exchanged, archived and managed by a radiology information system (RIS).

So, shall we encode this in DICOM or HL7? The answer is both. The idea is to maintain the DICOM structure within the imaging department, so it can be managed and archived transparently by the PACS (an archive does not necessarily need to know whether a "patient folder" has images stored in it or a structured report).

As soon as it leaves the imaging domain, and is incorporated, e.g. as part of the CDA, a conversion can be made into an HL7 object. To define this conversion or translation requires people that know both domains. This is the reason that there is a special joint-working group as part of the DICOM and HL7 standards committee that has been tasked to do this.

With regard to other overlaps, such as for patient and study management, (e.g. updates in patient demographics and/or study status), the Integrating the Healthcare Enterprise (IHE) activity plays an important role. This activity specifies so-called "profiles." In order to explain their function, I often use in our training classes the analogy of the menu of a fast-food restaurant. Both DICOM and HL7 have many services as well as options, ranging from appetizers to main meals ending with a dessert.

The profiles as defined by the IHE are a great tool, because they are basically "Value Meals," whereby the contents are guaranteed to follow the specification in the IHE technical specification. There is no question that this is a major help and contributes greatly to interoperability between systems from different vendors.

Concluding with our original question; the more concise answer is that there always be a specific domain, i.e. within the imaging department, that will be using DICOM and that outside the department, images will most likely be preserved in their DICOM format. Additionally, other DICOM objects such as structured reports very likely will be converted into HL7 objects. One could argue, however, that a DICOM presentation of images in standard web-based applications is not widely supported. The solution to this is subject for a future "standards update" column.

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.

Questions/concerns as well as information on books and e-learning resources about PACS and connectivity can be addressed to: herman@otechimg.com