HL7V2.x - HL7V3.0 Transformation / Translation

The adoption of any new messaging standard will be faster only if there exists a clear and defined transformation and migration strategy between the new standards and existing standards. It is always preferred to handle such a strategy in a middleware so as not to modify the core clinical applications to cater to the standard which is very expensive in the shorter run. However till now there is no clearly defined guidance to facilitate such a transformation of messages between Version 2 and Version 3.

These differences in methodology make the transformation from one version to another difficult. Technically it is possible to map the segments in V2 messages to XML sub-tree in XML schema with defined conversion mapping rules. However site specific interpretations of V2.x with user defined segments and fields make the transformation to V3.0 based on a common reference model appear like a mapping from a proprietary standard to a universal standard.

There are several instances where HL7 V2-V3 mapping has been attempted and tools are made available for specific projects like caBIG (Cancer Biomedical Informatics Grid) and commercial tools like Oracle HTB. Figure below shows a generic architecture used in these different initiatives. The mapping in these tools is manual and there is no pre-defined intelligent mapping or guidance provided with the tool sets. Exceptional domain expertise is required to perform the mapping in these tools.

The message structures used by HL7 v2 and V3 are different and the initial step involves converting the messages to a common canonical format before the mapping can be done. The V3.0 XML format is not compatible with the string delimited non-XML V2.x format. The V2.x XML encoding will enable it to be compatible with V3.0 XML format. The canonical transformation component will enable both these XML messages to be converted into an intermediate format to enable the mapping. The mapping between V2 and V3 is relatively straight forward in some cases of demographic data and clinical data where HL7V2.x segments directly map onto HL7 V3 classes. In other areas it has been not possible to map the different versions. A summary of some of the the difficulties faced during the mapping are [ Full details in my to be shortly published white Paper ]

Data Types

• Formats of Character Strings to Semantic data values
• Context and Content driven mapping issues leading to information loss

Conformance Patterns

• Clear definition of roles for Senders and Receivers in HL7V3.0
• No Clear guidance on application behaviour using HL7V2.x

Vocabulary

• V3.0 has strong semantic foundation and V2.x has no formal binding to Voc
• No one to one data types exist

Cardinality Constraints

V2.x messages shallower and less expressive than HL7V3.0 messages


Wrappers

Insufficient information in HL7V2.x-MLLP compared to HL7V3.0-ebXML/SOAP