Standards Watch | DICOM & HL7: Friend or Foe?

The cooperation between the DICOM and HL7 standardization organization has been significantly improved over the past several years. There is a joint DICOM/HL7 working group, a.k.a. WG 20 for DICOM or for HL7, the Imaging and Integration Special Interest Group, that meets at every HL7 event (which is typically three times a year) to work on interfacing issues between both communication standards. The good news is that each of the standards has its own, distinct domain and therefore, there is relatively little, if any, overlap between both of them so that the coordination activity in this working group is focused on the boundary between the imaging (DICOM) and IT (HL7) domain.

When teaching, I get the question often, "why couldn't this be done with a single standard?" The reason? Each one is specialized to meet specific needs for its domain. For example, it would be an unnecessary burden to add the DICOM standard with the extensive number of different data types that are defined in HL7 to facilitate the variety of messages. In addition, burdening HL7 with artifacts that are defined, for example, to manage image quality, or to facilitate the representation of multi-dimensional datasets such as those used when acquiring 4D ultrasound, would be a gross overkill as well for the HL7 standard. There also is the issue that the encoding used in the current HL7 standard would cause a very inefficient encoding of the image pixel data. However, for the new version 3.0, this should be less of an issue.

From an input to imaging perspective, the HL7 to DICOM interface is defined by the so-called DICOM Modality Work List (MWL), which communicates the patent demographics, radiology scheduling and order details to the modalities in the radiology department. This interface is well defined, and is implemented by almost every new imaging modality today. Mapping between the corresponding HL7 transactions that contain the admission information and orders and this work list, is defined as part of the Integrating the Healthcare Enterprise (IHE) Scheduled Workflow Profile. (See www.rsna.org/ihe for more details on these profiles.) The joint DICOM/HL7 working group is defining the corresponding interface and mapping between the new version 3.0 of HL7 and the DICOM MWL to allow early 3.0 implementations (version 3.0 is about to be implemented in a couple of clinical sites).

From the imaging output perspective, i.e. considering the information that typically flows from the PACS to the RIS, there is status information exchanged about the examinations, as well as reports, measurements, observations, identification of key images and/or presentation states of those images, as well as images themselves, that need to be provided to a wider distribution within the healthcare enterprise. The support of status information by a RIS such as completion/canceling of the procedure, number of images generated and procedure details, in the form of the DICOM Modality Performed Procedure Step (MPPS), is unfortunately not keeping up to par with the availability of this relatively new service by the new digital modalities.

I sometimes compare the HL7 world with an elephant, which takes its time to move in a certain direction, versus the DICOM jaguar, that is agile and even maybe somewhat more aggressive. It seems that the same comparison can be made for the imaging industry and IT; changes in standardization are readily adopted, or at least within a few years for acquisition modalities and PACS, while the IT world definitely takes its time. Some of that is due to the sheer size of the installed base; however, I believe there is no real good excuse to not implementing the MPPS more rapidly by RIS vendors. The impact on the user when the MPPS is implemented is rather significant: if implemented, a radiologic technologist, does not have to go to a RIS terminal to change an order, for example if the decision is made to append the procedure based on what is observed during the first part of the procedure, or just merely cancel it in case a patient feels unwell. The information will be automatically communicated from the modality via the so-called MPPS manager back to the RIS. Support of MPPS at the RIS definitely has a positive impact on the workflow of the technologist allowing him or her to be more efficient.

Another important interface issue has to do with the distribution of images outside the radiology department for the physicians. Vendors are mostly using web-based systems for physician image distribution. Their web servers, however, are typically very tightly coupled with the web-clients at the physician's desktop because they use proprietary protocols and/or compression schemes applying, for example, their own wavelet compression and streaming algorithms. The impact is that one needs to use the vendor-specific plug-in, applet, or application on the desktop. To allow potentially multi-vendor compatibility for this purpose, the DICOM working group has defined Web Access to DICOM Objects (WADO), in conjunction with the International ISO standards organization. This basically allows an image to be retrieved using a standard web protocol command, also allowing these to be exchanged in a web-friendly format, such as JPEG or TIFF. This standard also is intended to be used for images to be included in an Electronic Health Record (EHR), which is in the process of being defined as part of HL7. The EHR is still merely a functional standard, defined as a draft for early implementations, but it might be expected that the patient record itself will be using the so-called Clinical Document Architecture (CDA) proposal. This CDA contains the longitudinal patient record which might include reports, lab tests and medication information, as well as the pointers to significant images using the WADO mechanism. One might imagine that with the ever-increasing image data overload, which can include in excess to 1,000 images per study coming from a multislice CT scanner or using a new MRI technique, sharing the complete exam with a physician is not very effective. These image pointers, i.e. WADO, will be a good mechanism for that.

How do we deal with the fact that we sometimes might need access to this HL7 CDA within the imaging department? For example, when querying relevant patient information to be used by a radiologist when reporting on a new study, or when providing a work list to a radiologist on a workstation, the presence of the CDA might be critical. In addition, when storing a set of images in a standard format on media, one might want to store the CDA as well. To address these applications, the DICOM standard is being extended to include references to these HL7 objects and also to extend the media specification so they can be stored on a CD, for example, together with the images.

Certain non-imaging DICOM objects, such as measurements taken during an ultrasound examination, or calculations after the exam such as those used to determine heart ejection fraction using sophisticated algorithms (QCA and QVA), are encoded as so-called DICOM Structured reports. One can imagine these objects to be similar to the images, with the same patient, study, equipment and information encoded in the DICOM header, so they fit nicely within the overall imaging architecture. They can be archived, retrieved and displayed on diagnostic workstations within the PACS; however, there might be a need to convert these objects into HL7 persistent objects as well to allow them to "travel" outside the imaging department. That is why we also need a definition on how to convert these from the DICOM to the HL7 domain (not necessary exactly reproducible), and to have a link between these two. This is currently in the process of being defined.

As is obvious from the above, the question on whether HL7 and DICOM standards are friend or foe can easily be answered: they co-exist peacefully, as do the people who specify these standards. HL7 allows for references to the important DICOM objects, and DICOM will soon allow referencing the CDA objects as well. Each domain has its own specific strengths to provide for the functions necessary to provide high-quality patient care, DICOM primarily inside the imaging department, and HL7 typically when the information leaves the department.

Herman Oosterwijk is president of OTech Inc. (www.otechimg.com), a healthcare training and consulting firm, specializing in training and e-learning about these digital technologies.