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

HL7V3 and ebXML - Part 3

I apologise for the delay in publishing the Part 3 of the ebXML and HL7V3. I see that a portion of hits to my blog are coming from the links provided by Marc de Graauw in Section 7 of his article Implementing “Web Services in Dutch Healthcare” at http://www.ringholm.de/docs/03030_en.htm. I thank him for considering my blog posts worth the mention.

What is ebXML MSH?

HL7 V3 message triggered from Sender are sent over their integration layer as HL7 Request to sender MSH (Message Service Handler). MSH is a piece of software used to send and receive ebXML messages. Figure below shows the functions of MSH.

The textual description of the services depicted above is given below

Ø MSH Service Interface – This is the abstract interface applications use to interact with MSH to send and receive messages.

Ø Header Processing – the creation of the ebXML Header elements for the messages sent from the applications. It also involves parsing of header elements and interactions with contract properties. [See below for Contract Properties]

Ø Security Services – this includes digital signature creation in the messages (which may be used in headers), verification, encryption, authentication and authorization.

Ø Message Packaging – this will perform the enveloping of an ebXML Message (ebXML header elements and payload) into its SOAP Messages with Attachments container

Ø Reliable Messaging Services – this service handles the delivery and acknowledgment of ebXML Messages. It also deals with persistence of messages, retry, error notification and acknowledgment of messages requiring reliable delivery.

Ø Transport Binding – This is the abstract interface between the MSH and the various protocol stacks.

Ø Error Handling – this handles the logging and reporting of errors encountered during MSH or Application processing of a message.

Contract Properties

To understand the exchange of messages between two MSH’s we need to understand the term “contract properties”

Each MSH processes the messages sent by the other MSH by the contracted interface properties. These properties describe Quality of Service (QoS) from reliability and security point of view. The MSH uses these properties to build the ebXML wrapper. The contract properties are defined during message definition process and agreed between two organizations or two system vendors who will exchange the messages. Contract properties are defined for each HL7 interaction. The contract properties given for each interaction are identified by a CPAId. The sender will use the CPAId that is relevant for that HL7 message interaction and agreed with the receiver.

The relevant contract properties are Service, Action, Persist Duration, RetryInterval, Retries, AckRequested, SyncReplyMode, Actor, EndPoint, IsAuthenticated etc.- See HL7V3 and ebXML – Part 1 for details about these properties.

ebXML Message Exchange :

Figure below shows the sequencing involved in ebXML message exchange

Let me explain the flow in the above sequence diagram

1. In a typical implementation the Sender builds the HL7 message with the HL7 Wrapper and passes it onto the sender MSH

2. The sender MSH looks at the message interaction id and looks up in the database for the contract properties for the message and builds the ebXML wrapper.

3. The ebXML message sent by sender MSH containing the HL7 message payload will get ebXML acknowledgement synchronously on the same connection over HTTP 202. The ebXML Acknowledgements are sent without a payload.

4. If the ebXML acknowledgement from Receiver MSH is not received within a time interval Sender MSH resends the message. The number of retries and retry time interval are dependant upon the contract properties attached with that message.

5. If the number of retries expires depending upon the message business functionality Sender MSH will report the error back to application which sent the message or enter into a HL7 slow retry method.

6. In case of ebXML errors Receiver MSH sends a message with the same end-point binding associated with ebXML acknowledgement service except that a Message Error will be sent.

7. The business responses or application acknowledgements from Receiver MSH in response to the message sent are received and processed by the Sender MSH exactly in the same fashion as Receiver MSH does on receiving a request from Sender MSH.

The above description is only for direct reliable message exchange between two MSH's ; we can have intermediary exchange with two MSH's communicating to each other using anothe MSH or we can also have direct unreliable message exchange. I have not discussed them here not i do intend to discuss them here.