Converting from an HL7 Version 2 Message to CDA

This post was originally written for and published on the HL7 Standards blog, here: http://www.hl7standards.com/blog/2010/11/16/converting-from-an-hl7-version-2-message-to-cda

One of the most common ways to integrate the HL7 CDA Standard into existing solutions is to create a CDA document from an HL7 Version 2 message. Three HL7 Version 2 messages are commonly used to do this: MDM_T02, ORU_R01, and ADT_* messages. The way that I like to do this is by converting the HL7 Version 2 message from the EDIFACT (pipe and hat) form into an XML format, and then transform that via XSLT to a CDA document.

There are HL7 Schemas for most Version 2 releases that members can obtain from the HL7 Web site. Most interface engines I’ve worked with provide some way to convert from HL7 V2 to XML, but few make it easy to use the Standard HL7 schemas for these messages. The existence of these must not be well known to interface developers. A couple of interface engines do make it pretty easy to convert to an XML format that is close enough to work with. Pragmatically, I often choose the easiest way to get the messages into XML, and not necessarily the most standards compliant way. It would be nice if interface engine vendors supported the standards.

Of course, there is quite a bit more involved in these mappings, and I describe some of these details in “The CDA Book”, which I expect to be available in the first half of 2011. There is an entire chapter that describes the mappings field by field for each of the above segments, and also provides details on how to map from HL7 Version 2 data types to the data types used in CDA and other HL7 Version 3 standards. But if you cannot wait for the book, at least you know that A) it can be done, and B) where to start.

Having created the XML, the next step is to map the contents into the CDA standard. The HL7 message segments map very well to the CDA standard, as you can see from the table below.

Segment	CDA Element
MSH/EVN	‹ClinicalDocument›
NK1	‹participant›
NTE	‹text›
OBR	‹section› ‹observation›
OBX	‹observation› ‹section› ‹nonXMLBody›
ORC	‹infulfillmentOf›
PID	‹recordTarget›
PV1	‹encompassingEncounter›
SPM	‹specimen› ‹procedure›
TXA	‹ClinicalDocument›

The MSH/EVN segments contain information about when the message was created and its identifier. This can be used to help fill in details about the CDA document that was created.

The NK1 segment contains information about next of kin and emergency contacts. Most CDA implementation guides put these in as ‹participant› elements in the CDA header, where the typeCode XML attribute is set to IND.

The OBR segment represents ordered tests in an order message, and completed tests in a result message. These are often panels, and would appear in their own section of a CDA document. The order information itself can be recorded as ‹observation classCode=’OBS’ moodCode=’RQO’› to describe the order and participants (e.g., the ordering physician would be the author of an observation in request mood).

The ORC segment represents order details, usually the order number. That would most commonly be mapped to the place in the CDA header meant to store these details.

The PID segment describes the patient. In fact, just about every field in the PID segment has a home in the ‹recordTarget› element of the CDA header.

The PV1 segment describes the visit. That too has a place in the CDA header that describes the visit for which the document is written.

The SPM segment describes the specimen and procedure for obtaining it. Parts of that segment should map to a ‹specimen› participant, and other parts to a specimen taking ‹procedure› act in a clinical statement in the CDA document.

The TXA segment unfortunately only appears in MDM messages. I say unfortunately because the TXA segment is what the CDA header is modeled upon, and contains many document specific details that other messages such as the ORU and ADT just don’t address.

Finally, we come to the all important OBX. The OBX segment is the workhorse in HL7 Version 2 messages. Because it follows the name/value pattern, it can be used to record just about anything. But, because it does that, it can also be mapped to just about anything else.

In MDM messages, the OBX segment actually contains the contents of a clinical document. Some systems already send CDA documents in the OBX segment of an MDM message, but for this post, I’m assuming you aren’t working with one of those. If you are working with an MDM message, the contents of the OBX segment will typically wind up in the ‹nonXMLBody› element of the CDA document.

In ORU messages, the OBX segment usually describes a test result and value associated with that result. Depending upon the feed, this could be an ‹observation› within a section (e.g., a lab message), or the ‹text› associated an entire ‹section› described by the OBX (e.g., part of an imaging report).

Keith W. Boone has been very active in the development of the CDA Standard and CDA implementation guides for the last 7 years. He works as a Standards Architech for GE Healthcare and in that role participates in the development of standards through a number of SDO organizations including HL7, IHE, ISO, ASTM and Continua. He is presently cochair of committees in HL7 and Integrating the Healthcare Enterprise that develop CDA implementation guides, and will take a position on the HL7 board in January of 2011. He was the cochair in ANSI/HITSP of the Care Management and Health Records Technical Committee, and editor of the HITSP C32 Summary Documents using the CCD specification develped by that organization. He has authored or edited more than a score of CDA implementation guides and related specifications. His most recent work “The CDA Book” is a textbook on the HL7 Clinical Document Architecture standard that will be published by Springer in the first half of 2011.