Home > Development > HL7 – Is NEHTA Short-sighted?

HL7 – Is NEHTA Short-sighted?


Health Level Seven (HL7)[1] is an electronic application-level medical data interchange standard that has been around since the late 1980s. Originally designed for use as a means for one hospital system to interopetate with another, generally within the same facility or geographic location. Later this was expanded to other sites but again was limited to hospitals only.  The types of information that was transmitted included patient demographics, procedures, observations, clinical record amongst others.

In the decades that followed, HL7 went from a closed specification in a closed market to external IT markets where the ecosystem, unlike in hospitals, is not as controlled, as predictable or quite simply just subject to varying levels of additional political pressures. Not only that, but in my experience HL7 is one of the most poorly documented, vague and abstract specifications.  God forbid if the makers of HL7 formulated any other IT standard for the world would perhaps be much worse of.  Take Observation Results (ORU) messages for example.  This message based on the HL7 2.3.1 USA original and the inherited AS 4700.2 specification are a logical design at best. Places where say test name codes, test result codes, measurements and so on are present in the message sadly have an ambiguous placeholder for data to be inserted with-ought thought as to what the data contract should actually be.  What point is it to have a placeholder for a test code if Standards Australia or NEHTA do not enforce, recommend or suggest the form for the contractual type.  We may as well all put in non-type safe unverifiable strings.  In reality this is exactly what we and labs do.  Needless to say such activities play havok with trying to determine whether two atomic measurements belong to the same group.

Reality Check

The truth of the matter is is that may labs are running software that is perhaps old, made overseas or simply that do not have the ability or legal right to modify the software to bring it more in-line with its domestic cousins.  HL7 comes in many versions, with HL7 2.3.1 being the most popular (at least in observational reporting) here in Australia.  HL7 2.4 is a newer version generally used in Referrals, Status and Discharge Summaries and a HL7 V3 which is rather unique and takes on a XML form.  HL7 is one of the more promising for it is the arguably more contemporary technologies for it is more in line with other aspects of software development. i.e.. because HL7 V3 is XML developers are more likely to understand it  in this current generation of developers which are incapable (at least in the .NET world) of understanding or implementing their own persistence or parsing algorithm.  But I am perhaps a little too cruel here for these very same developers have done marvellous things like TDD as I have blogged before. Alas I digress.

So enter organisations such as NEHTA and the not-for-profit IHE. I applaud their passion to unify the structure of the data being transmitted to formualte a national canonical schema and for outlining a single messaging framework via their canonical protocol.  All health vendors in Australia wishing to participate are expected to adhere to these new standards. Certification by the Standards body is required prior to participation.  On paper this sounds like a splendid plan, not only will there be a single standard endpoint into the ‘cloud’ but all data will be normalised.

Doomed to Fail?

Sadly, I feel such an endeavour is doomed to failure. Why? As I mentioned, everyone must upgrade all their software, yes even that lab running the bucket of bolts 1990s software on that Sun IV before the cut off time.  With that done, all labs are now in agreement not only which version of HL7 to use (lets call it V1.0), but also what coding system too. Surely that’s not so bad is it?

History has shown that Standards Australia has released amendments to previously published standards changing things such as field lengths to even the data type for a particular field.  What would be the impact I wonder of a V1.1 Amendment on a now nationwide-enforced standard.  Does that mean that everyone now has to rush and adopt the change within a matter of days or is a larger grace period allowed.  For a interop design that has made it quite clear that there will only ever be one accepted format it would follow that upon publishing the new amendment logic would imply that anyone not using it must be invalid.

In addition what happens to the early adopters of V1.1 Amdt?  Some labs unaware of the new schema would be quick to point out that upon the receipt of this new type of message that is “invalid”.  From their point of view they would be arguably correct.  Though the senders are also arguably correct for their message follows the V1.1 canonical schema.

While NEHTA’s dream of a nationwide canonical schema is a honourable goal it is perhaps utopian and a little naive with a dash of arrogance. Why I think some aspects of e-health standards are valuable – code domain standards such as LOINC and SNOMED, overall message standards are not.  This is because messages will and do vary greatly whereas smaller nuggets of information such as measurements and their corresponding LOINC are arguably less likely to undergo schema transformation because the recipient schema is more than likely going to agree.

Why on earth NEHTA does not treat e-health like any other form of EDI problem is beyond me.  The big players of EDI, ETL and EDIFACT such as Sonic and Tivoli have been solving these sorts of problems for decades.  To think of a metaphor for a moment – do you think there is a nationwide or worldwide standard for purchase orders. Of course not. Everyone has their own variety and they make do via schema transformation.

e-Health should arguably be treated with the same practice – no pun intended.


[1] The ‘7’ in HL7 refers to the 7th or ‘Application’ layer as defined by OSI.

Categories: Development Tags: , , , ,
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: