Thursday, 24 July 2008

Business Case for HL7V3.0

My previous posts clearly indicate that HL7 V3.0 represents a quite radical departure from the HL7V2.x standards in its development methodology. Most of the early adopters believed that the HL7V3.0 would replace HL7V2.x in its entirety, but the reality of the substantial investments in HL7V2.x systems by different organizations and vendors soon became apparent. The recent versions of HL7V2.x notably HLV2.6/HL7V2.7 added new features e.g. EHR messages which enhanced the capabilities of V2.x standards matching the features of Version 3.0. The areas area’s where V3 was supposed to solve V2.x problems e.g. Clinical Messages were found to be very work-intensive with issues pending around these domains.

The last released normative edition HL7V2006 as shown in the Figure below indicate that some of the domains have not yet been approved for example Specimen domain( Informative).The final standards of some domains are in a trial form ( - DSTU = Draft Standard for Trial Use)only for example Patient Administration which maps onto ADT in HL7V2.x.






2006 Normative Edition Domains [Copyright: HL7]

Currently one Normative Edition is coming out per year and this is increasing the uncertainty around this version.Figure below shows the world wide usage of different HL7 versions. The figure indicates that HL7 V3 is not in wide use and V2 would need to be supported for a long time








HL7 Version Usage Statistics [Copyright : Neotool]

The business case for using HL7V3.0 for sites which already has HL7 v2.x deployed is different from that sites of which do any have any variant of HL7V2.x implemented is also different. Another important factor that needs to be considered for building a business case for deploying version 3.0 in an organization is the extent of usage of department specific systems rather than an integrated system.

HL7 Sites: Large numbers of organizations around the world have made huge investments and effort in developing and maintaining HL7 V2.x interfaces. Most of these deployments have taken place in the last few years and it will take huge effort in convincing these sites to give up HL7V2.x and adapt HL7V3.0. If the requirements and need of the organizations are met by the existing v 2.x implementations then it would make little sense in replacing them with expensive V3.0 implementations not withstanding the thought the long term infrastructure and support costs for V2.x depending on the volumetric increase. However for new domains which are not yet deployed in that clinical setting it would be advantageous to start with V3.0.

Non-HL7 Sites: For Non-HL7 sites the factors that needed to be considered for V3.0 implementation are the capabilities of the existing applications in that clinical setting and the consideration of features and needs of the clinical setting that cannot be provided by version 2.x such as semantic interoperability, support for research, genomics, web services and integrating with nation wide or region wide EHR systems. But the semantic richness and the transport protocols of V3.0 does make it a better alternative to V2.x to take advantage of the COTS products features to quicken development. It has been observed that early adopters of V3 are typically "green field” sites with no HL7 complaint systems. Other implementation sites are academic and research oriented deployments and a few others are sites which implemented HL7 V3 to adhere with regulatory agency compliance specifications.


The complexity in understanding HL7 v3.0 is a major challenge for a clinical enterprise to implement HL7V3.0. The organization which wishes to implement HL7V3.0 needs to get involved the activities of HL7 organization and educate the stakeholders before impacting the effort involved in making their environment HL7 V3.0 compliant. The effort involved in making applications in an organization conform to V3.0 is proportionate to the application functionality required by the defined role of the application. The vendors of the application might not modify their applications to suit to the specific organization needs hence an organization should carefully tread the HL7 V3.0 path only after studying the market trends associated with HL7 V3. The market trend does indicate HL7 V2.x and V3.0 coexisting together for the next few years.

Tuesday, 15 July 2008

HL7V2.x and Non-MLLP/ HL7V2.x and CDA

After working for 10 years for a company i resigned my job last month and joined a new job last week.Iam not in a position to post anything new due to lack of time and lack of space(shifting to a new home as well). I will do so from August when i hope to get some decent time and space in my new home.But i could not resist posting two quick comments for those who came to my my blog with two search words and terms

The first one is for the person who came to my blog with the long search query term “is there any other way of transporting hl7 message apart from mllp”. Yes there are , there are two alternative options to sending HL7V2.xmessages over MLLP one is sending it over HLLLP; For details see my post on HL7V2.x and Low layer protocols
http://healthcareinformatics3000feet.blogspot.com/2007/12/hl7v2x-and-low-layer-protocols.html

The other option is to use ebXML; use the normal ebxml header and put the hl7v2.x message in the MIME part; for discussions on ebXML structure see my ebXML and HL7V3 posts.

The second comment is for the guys who came with the term HL7V2.x and CDA , I just want to mention that From the perspective of a V2.x CDA document is a multimedia object, to be exchanged as a Multipurpose Internet Mail Extensions (MIME, RFC 2046) package, encoded as an encapsulated data type (ED).In V2.x, CDA documents are to be exchanged in the OBX segment, in any message that can exchange documents (such as MDM). Within the OBX segment, the MIME package is placed in OBX.5 (Field 00573 Observation value), encoded as a V2.x encapsulated data type.

I will write in detail later on the above two in my next posts.