The Verbose HL7V3- Part 1

In Mid-2006 Gartner in a note on HL7V3 stated that HL7V3.0 messages are quite verbose and applications require considerable effect to understand and process the message. Gartner suggested that HL7V3 messages need a critical midcourse correction and suggested to HL7 Inc to act vigorously to make HL7V3 messages easier to use and more compact.

In the next couple of posts I would look into the reasons and complications behind the verbose nature of HL7V3 and conclude by presenting the solutions on offer to overcome the problems associated with this verbose nature of HL7V3. This post will also help you to some extent to understand how to browse through an R-MIM.

Why are HL7V3 Messages Verbose?

HL7V3 messages are XML messages which are model driven and model driven XML are usually verbose in nature compared to custom written bespoke XML messages designed to convey the same information.

Why do we need Model driven messages?

Currently in the healthcare industry point-to-point messaging is common and non-standardised data exchange is the norm leading to data quality issues, confusions and processing errors sometimes with grave consequences affecting patient care. So it’s absolutely necessary to have a common understanding of the data that is being exchanged to eliminate the misinterpretations. To facilitate this, a level of semantic interoperability is required.

Semantic interoperability can be achieved using a common information exchange reference model so that data is shared and defined unambiguously. XML schema models are derived from this reference model and used to generate run time schemas which cannot be modified directly unless the model itself is modified. As different applications build XML messages sourced from the reference model they end up having the same content and construct facilitating meaningful data exchange. HL7 Inc produced a global semantic model for healthcare called Reference Information Model (RIM) which is the basis for HL7V3 messages [Refer to the HL7V3 Primer post dated January 2008 at

http://healthcareinformatics3000feet.blogspot.com/2008/01/hl7v30-primer.html].

So what’s the issue?



Well, let’s take a sample example and see what exactly the issue is. The following is an extract from XML instance to represent author of a clinical document based on the discharge summary CDA schema taken from CFH-MIM6.3 available on HL7-UK Website

Now let’s look in detail at the representation of the author. The R-MIM representation of the first part is shown below

The author representation starts with the author as participant. It contains the following attributes

1. “typecode” with a fixed value of “AUT” – Indicating this class is that of author

2. “functioncode" to indicate the function of document author from a pre-defined vocabulary. In this case it has a fixed value of “OA” indicating originating author.

3. “contextControlCode” - Specifies how the author contributes to the context of the discharge report and whether it may be propagated to descendent acts whose association allows such propagation.

4. “contentId” - An identifier for a template which constrains the classes and attributes which follow. This is more of a structural navigational aid and not an indicator of semantic meaning. In this case it is the AssignedAuthorSDS template.

5. “time” - The time at which the author authored the clinical document.

The XML representation of the above is shown below

The AuthorChoice leads to template for the author who is in a directory called SDS-Spine Directory of Services. The R-MIM representation of author in SDS is shown below

The AssignedAuthorSDS identifies a person playing the role of author. The role information includes the user identifier and role profile information of the author along with the job role.The AssignedAuthorSDS contains the following attributes.

1.“classCode” - A fixed value of “Assigned” indicating that this role is assigned

2.“id” – it has a cardinality of [1..2] with two identifiers one to identify the user id and one to identify the role profile of the person to whom the role is assigned

3.“code” - A code from a vocabulary which defines the person’s job role and with displayname associated with code

4.“templateId” - fixed value of this attribute provides a unique identifier for the template and the class name within that template. In this case that of the AssignedAuthor template.

The XML representation of the above is shown below

The role AssignedAuthorSDS has links to person entity which is playing the role of the author. The attributes within the person entity are given below

1. “classCode” - A fixed value of “PSN” indicating that this entity is a person

2. “determinerCode” – A fixed value of “INSTANCE” to indicate this is a instance of person
Name – Name of the person

3. “templateId” - fixed value of this attribute provides a unique identifier for the template and the class name within that template. In this case that of the AssignedPerson template.

The XML representation of the above is shown below

The role AssignedAuthorSDS has links to the represented organisation to which the author belongs to. The attributes within the organisation entity are given below.

1. “classCode” - A fixed value of “ORG” indicating that this entity is a organisation

2.“determinerCode” – A fixed value of “INSTANCE” to indicate this is a instance of an organisation

3.“id” – A unique identifier which identifies the organisation nationally

4.“name” – name of the organisation

5.“templateId” - fixed value of this attribute provides a unique identifier for the template and the class name within that template. In this case that of the representedOrganisation template.

The XML representation of the above is shown below

Still not clear on what’s the issue here?

Well a simple XML representation of the author as described above would have probably looked something like this

Hmm…

But is it that not the price you pay for using a model to provide semantic interoperability?

Yes it is but the verbose nature of the HL7V3 problems are creating huge problems as mentioned above regarding the effect to understand and process the message correctly apart from hogging the network bandwidth and destroying one of the unique the advantage of XML messages- “Readability” which is critical for developers and testers.

So what can we do?

There is a huge debate going on if we can take an alternative path to provide semantic interoperability with simpler XML messages. We will discuss those options in our next post.

Acknowledgements and Copyrights

1. HL7-UK / CFH - MIM 6.3 - Copyrights for R-MIM

2. Acknowledgements - Is it Possible to be Simple Without being Stupid?

Exploring the Semantics of Model-driven XML - Ann Wrightson

Healthcare ESB Approach

This post defines an approach which can be used for development of Enterprise Service Bus to enable communication using both HL7V2.x and HL7V3.0. The approach is based on Service-Oriented Architecture (SOA) to better align the solution with the business. Enterprise Service Bus (ESB) has emerged as the best proven, fastest and simplest way to implement SOA and offers dramatic productivity and ROI improvements over traditional integration technologies. Figure below a schematic representation of proposed ESB involving applications communicating using both HL7V2.x and HL7V3.0.

ESB Model


SOA simplifies the complexity in integration by the provision of a common infrastructure for service communication, mediation, transformation, and integration. ESB serves as the backbone for an SOA implementation. The ESB will provide the following services

Transport Services: The transport services need to support multiple communication protocols to support both local and national communication. The relevant communication protocols for the current scenario that will be supported are TCP-IP/MLLP, HTTP(S) and JMS.

Message Type: The solution need to support multiple messaging models such as synchronous, asynchronous, publish, subscribe and store and forward. The message types supported with these messaging models are JMS with headers, XML, SOAP and ebXML.

Validation Services: The messages come in different formats varying from string delimited for HL7 v2.x, XML for V3.0 and proprietary formats for existing systems. The validation components will vary from using standard XSD’s to custom XSD’s.

Transformation Services: The transformation service is required to transform currently one version of HL7v2.X to other versions of HL7V2.x and some custom format. The functionality supported by transformation service is
Ø Transforms messages based on the target service
Ø Transforms messages based on XQuery or XSLT
Ø Supports transformations on both XML and string delimited messages

Routing Services: The routing services need toallow routing of messages to existing systems and national applications based on the message content or message headers. The routing services will be based on XQuery-based policies or callouts to external Web services. The routing policies apply to both point-to-point and one-to-many routing scenarios.

Service Management: The service management services need to help handle logging, monitoring and error handling variety of message errors. The logging and monitoring will support logging messages for both systems operations and business auditing purposes, search capabilities, and others. Both business services and ESB services are monitored, as are response times, message counts, and error counts. The error handling components allows configuring of systems to format and send error messages, and return messages for consumers of services who expect a synchronous response.

Common Wrapper: The differences in transport mechanisms used by HL7V2.x and HL7V3.0 will hinder the ESB. The development of a common wrapper with elements of MLLP wrapper and SOAP/ebXML wrapper is crucial for successful deployment of this model.