How Do HL7 and XML Co-Exist in Clinical Interfacing?

August 10th, 2007 by Mike Stockemer

Votes | Average: 0 out of 5 (No Ratings Yet)

Loading ...

Posted in CCR, CCD, CDA, Healthcare Integration

There are a number of ‘new’ healthcare standards that are beginning to be implemented in clinical interfacing today. Acronyms such as CCR, CDA, and CCD are becoming common words in everyday interfacing discussions. While most interfaces today are using the HL7 2.x encoded format, these new standards are choosing to use XML as their message format.

The healthcare integration standards are new, but the idea of using XML to transmit clinical information has been around for a long time. In fact, the HL7 organization actually publishes a set of XML schemas for rendering HL7 version 2 messages in an XML format. This format is more commonly known as HL7 2.XML.

While this HL7 2.XML format is not widely used, these other XML based standards are beginning to be implemented by vendors and asked for by providers. As the new standards become more prevalent, we are beginning to get some interesting questions about how they can work together with the current HL7 2.x encoded interfaces that are deployed today.

Question: Do tools exist to help me map a HL7 version 2.4 ORU message into an XML formatted CCR document?

This question really should be broken into 2 separate questions:

1) Do tools exist to help me map from HL7 encoded messages to XML based formats?
The answer to this question is “yes.” There are a number of interface solutions available that can map between HL7 and XML. Healthcare integration engines today can typically map between a number of different file formats including HL7 2.x, XML (including CDA, CCR, CCD), CSV, fixed length record files, or even custom file formats.

2) Does it make sense to take an HL7 2.4 ORU message and convert it to an XML formatted CCR document?
HL7 2.x messages are really focused on the real-time delivery of patient data. An ORU message typically contains the result of a single order, or possibly the results of multiple orders that were performed at the same time. This single message is in no way a summary of all procedures that may have been performed on the patient.

The purpose of a CCR is to create a summary document for a patient that contains all of the information that a provider would need to continue caring for a patient. Things such as allergies, current medications, recent diagnosis or notes from recent office visits would typically be included in a CCR.

So while it is technically possible to take data out of an HL7 message and map it into an XML format, the resulting document would not contain the required patient data to make it useful for its purpose as a CCR.

Question: If I cannot do a real time conversion of the data, how do HL7 2.x interfaces help me create the XML based CCR documents that I need to export from my EMR system?

An EMR application will usually have the ability to receive HL7 2.x information from other systems. This information will be imported into the system, and the patient’s record will be continuously updated.

When a user of the application chooses to create a CCR export, the data stored in the database can be queried, and the relevant information copied into the XML document. This document can then be delivered to the remote system for import.

As new healthcare integration standards emerge it is important to gain a thorough understanding of their intended purpose, and focus not just on the format of these new standards, but also on the workflow and business rules that need to be applied when creating or processing these new XML based documents.

Review the recorded webinar on this topic presented August 7, 2007.