Technology Update: DICOM vs. HL7

Jul 4, 2001

As a participant in the DICOM standardization effort and a co-chair of an HL7 special interest group, I still feel somewhat overwhelmed by the sheer size and momentum of the HL7 standardization meetings. The HL7 organization has more than 2,000 members, and hundreds of people, from all over the world, always show up at its quarterly meetings.

But the size of the organization is not the only difference between HL7 and DICOM. For all the efforts to merge DICOM and HL7, the two standards remain very different entities in the area of application, its protocol structure, and information content. This article will explore some of the differences between the two standards, which may affect future efforts to integrate them.

First of all, HL7 is very much event-driven -- i.e. a patient is admitted, discharged, or just transfers from one room to the other. These events result in so-called unsolicited transactions that are exchanged in a process usually initiated by the main patient registration system. DICOM is much more of a client-server protocol, in which modalities such as a CT or MR request a worklist from a server to find out its schedule.

Secondly, the HL7 standard is implemented with much more freedom. Most hospitals use it as a guideline rather than a standard, which leads to vendor-specific implementations and on-site customization. An interface engine, mapping the various fields to accommodate these differences is an accepted part of life.

DICOM, although still not quite plug and play, is much more rigidly specified, and DICOM-to-DICOM conversion boxes are fortunately slowly being eliminated. Lastly, if you understand that HL7 uses character-based encoding, you can grasp that the conversion of pixel data to these characters leads to even larger file sizes.

While HL7 and DICOM have their own domains, they do definitely connect, however. The interface consists from a workflow perspective of two areas, i.e. where the ordering information for the imaging procedure is exchanged, and where the results, in the form of a diagnostic report and/or measurements are sent back to the information system.

There are several other intersections between DICOM and HL7 that are of critical import to department workflow. For example, the DICOM modality performed procedure step communicates from the modality the actual procedure performed, which can be different from the scheduled procedure.

It is not uncommon, for example, to extend a chest CT scan to the abdomen. This would currently require the order to be changed at an IS terminal, which can communicate information directly from the modality back to the IS scheduling application.

Examination status is also important; the completion of a procedure needs to be known at the IS. Even the start of a procedure is useful information when indicated on a scheduling worklist. Lastly, an unscheduled patient might require a HL7 patient update transaction to get the IS database back in sync.

Mapping the HL7 information, e.g. from the order transaction to the DICOM worklist, is not obvious, however. Most of the information can be mapped directly, but HL7 has a more elaborate encoding of the patient ID (it recognizes several), for which a specific mapping to the DICOM equivalent patient ID has to be defined. This is where the IHE (Integrating the Healthcare Enterprise) initiative comes in, delineating in an unambiguous specification (via the technical framework) the intersection of HL7 and DICOM.

How is the integration between HL7 and DICOM working out? The lack of participation by the IS vendors in IHE activities has been a limiting factor, as has been the radiology-centric nature of the initial document.

Early experiences, such as by the U.S. Department of Veterans Affairs, prove that the integration of other specialties such as endoscopy, ophthalmology, and pathology require a different workflow and have their own problems. For example, the IHE framework specifies that a request, identified by a single accession number, can result in multiple procedure steps, which in turn can generate two reports, both with the same accession number. It is my guess that most radiology systems cannot cope with this.

Interfacing issues between DICOM and HL7 cause some workflow problems, several of which have a root cause in the PACS. For example, a single acquisition sometimes requires the technologist to split up the procedure at a QA station. A CT scan might need to be divided into the specific chest and abdomen images, while using some images in either group. Most modalities are not quite ready to handle this task.

Despite these lingering challenges, great progress has been made with interfacing DICOM and HL7. A special joint HL7/DICOM working group is trying to facilitate the reconciliation of these issues. This is a key initiative to bring about tight connection between the two standards and ensure workflow support.

By Herman Oosterwijk
AuntMinnie.com contributing writer
July 5, 2001

Mr. Oosterwijk is president of OTech Inc., a healthcare technology consulting and training company. He will be hosting a weeklong forum July 9-13 in AuntMinnie's discussion groups to answer any questions on DICOM. He can also be reached via www.otechimg.com.