HL7 messages are the lifeblood of electronic health communication in many settings in many countries. In the healthcare sector in Australia, for example, they are ubiquitous in hospital settings for notification of patient Admissions, Discharges and Transfers and they are ubiquitous in both hospital and primary care settings for reporting pathology results to the ordering clinician’s or her organisation’s clinical system. Millions of HL7 messages flow between systems  every day in Australia. The vast majority are based on HL7 version 2.3, 2.3.1 or 2.4. These standards are the lingua franca for healthcare messaging.

However, their quality is often less than desirable. There is diversity in the way they are structured and represented from one system to another. The system interfaces that construct, route or process these messages are difficult and expensive to build and maintain. They are intended for point to point communication within a relatively confined and stable eco-system, rather than as components of a national infrastructure to support patient-centred care. Many of their well-known idiosyncrasies embody and epitomise the profound difficulty faced in trying to share information amongst heterogenious systems in healthcare – often dubbed “lack of interoperability”. Some of this “lack of interoperability” is due to shortcomings of, or ambiguity in the HL7 v2 standards. Some is due to ambiguity in implementation guides, or more often, conflict between various implementation guides and between implementation guides and their referenced standards. Some is due to developers’ and implementers’ ignorance or misapplication of the “standards”. Some is due to the lack of standardisation of infrastructure upon which the messages depend – e.g. lack of standardised patient and provider identification infrastructure, or the lack of adequate value set infrastructure to describe clinical concepts.

Such was the dismay at this lack of interoperability within the HL7 community that at the turn of the century a completely new version – version 3 was developed, based loosely ( and poorly ) on object-oriented methodologies. HL7 version 3 messaging, although adopted in some countries, emphatically failed to displace HL7 v2 as a preferred standard for healthcare messaging. I am not aware of any successful attempts to use it in Australia. Later, but still early this century, some HL7 members developed yet another health information communication standard – based on a document paradigm – CDA. HL7 CDA has had some take up in many countries, often lubricated by vast amounts of government money, such as via the Meaningful Use program in the USA or the national PCEHR in Australia. One of the major reasons for its adoption in those examples was  the hype created or swallowed by semi-literate, but influential technocrats who seriously believe(d) that the “industry-standard” XML was an essential prerequisite for every piece of national health information infrastructure.

In the intervening decade or more, millions of HL7 v2 messages continued to flow each day, through the arteries and veins of the Australian health system. Yes there are toxins in the blood, but very little government money has gone into analysing those toxins or into improving the quality in any way whatsoever.

And now we have FHIR thrown into the ring – HL7’s 3rd attempt at “improving” upon the v2 messaging standard. But with FHIR, the hype has reached super-hype, possibly even ultra-hype levels. It has infected not only the semi-literate technocrats, but the technology-illiterate bureaucrats and money will pour in to support it’s further development and adoption. Perhaps, eventually the investment might be worth it. But it will be at the expense of improving the existing messaging infrastructure and improving the quality of data so needed for clinical decision support and interoperability.

Meanwhile, HL7 v2 messages probably still constitute today close to 100% of electronic messages in those areas cited in the opening paragraph of this article. They will do so for many years to come. So it was with much interest and some trepidation that I headed up to Brisbane earlier this week to attend the first “reboot” of HL7 Australia standards activities with an all day workshop that established 3 working groups to cover to-be-determined topics related to Medications, Patient Administration, and Orders and Observations. Despite the inevitable cohort of FHIR evangelists there were still a few agnostics in the room and a very welcome commitment from the organisers and Board for open, collaborative and technically supported processes. I came away cautiously optimistic. But not before declaring my concerns about a prior and current lack of a commitment to quality amongst many health informatics professionals both in Australia and overseas as embodied in the “Ringholm Effect”. I should explain.

The Ringholm Effect

For much of HL7 v2’s life, copies of standards have been difficult to obtain. Membership of HL7 International or a country Affiliate organisation was necessary. Documentation was scant. Some vendors produced interface specifications with perhaps an occasional sample message cited within a PDF or word document. To fill a void in understanding of HL7, some individuals and organisations have provided free explanatory material. For over a decade, the Netherlands-based HL7 consulting company Ringholm has contributed a substantial corpus of material to help a variety of people understand and adopt various HL7 standards. Much of this material has been made freely available on the internet with no strings attached, including a remarkable collection of recent videos of interviews and conference/workshop sessions. Ringholm is to be applauded for this service to the health informatics community. But…

Some published material contains errors. e.g. http://www.ringholm.com/docs/04300_en.htm contains the following description and sample HL7 v2.4 laboratory report message fragment.

The V2.4 representation of the use-case is a ORU^R01 message. 

The syntax encoding is based on the classic HL7 v2 syntax,

commonly referred to as the vertical-bar syntax.

The MSH (Message Header) segment contains the message type,

in this case, ORU^R01, which identifies the message type and the trigger event.

The sender is the GHH Lab in ELAB-3. The receiving application is the GHH OE system located in BLDG4.

The message was sent on 2002-02-15 at 09:30. The MSH segment is the initial segment of the message structure.

MSH|^~\&|GHH LAB|ELAB-3|GHH OE|BLDG4|200202150930||ORU^R01|CNTRL-3456|P|2.4<cr> 

PID|||555-44-4444||EVERYWOMAN^EVE^E^^^^L|JONES|19620320|F|||153 FERNWOOD DR.^

 ^STATESVILLE^OH^35292||(206)3345232|(206)752-121||||AC555444444||67-A4335^OH^20030520<cr> 

OBR|1|845439^GHH OE|1045813^GHH LAB|15545^GLUCOSE|||200202150730|||||||||

 555-55-5555^PRIMARY^PATRICIA P^^^^MD^^|||||||||F||||||444-44-4444^HIPPOCRATES^HOWARD H^^^^MD<cr> 

OBX|1|SN|1554-5^GLUCOSE^POST 12H CFST:MCNC:PT:SER/PLAS:QN||^182|mg/dl|70_105|H|||F<cr>

The PID (Patient Identification) segment contains the demographic information of the patient.

Eve E. Everywoman was born on 1962-03-20 and lives in Statesville OH.

Her patient ID number (presumably assigned to her by the Good Health Hospital)

is 555-44-4444.The OBR (Observation Request) segment identifies the observation

as it was orignally ordered: 15545^GLUCOSE. The observation was ordered by

Particia Primary MD and performed by Howard Hippocrates MD.
The OBX (Observation) segment contains the results of the observation: 182 mg/dl.

 

There are, in fact, significant errors in the above message. Quite possibly, this was copied from a real system. I would not be surprised. Either way, a quick check by an HL7 v2 expert should have uncovered some of the errors and led the author to either correct or comment on them. Not only has it not been corrected after 9 or more years, but the author has repasted this faulty message into another paper  describing how HL7 v2 messages could be mapped to FHIR. I’ve seem similar suggestions by other bloggers such as David Hay, who originally cited the same faulty message.

Readers at this stage probably think I am over-reacting to what, in many circles would be considered just an authoring oversight. No-one would complain if a blogger posted some faulty code C# or Javascript code on a web-site. But this is much different. Firstly, there aren’t many alternative sites where sample messages are available. Secondly, in this case  it is symptomatic of a culture that has long pervaded the cottage industry of health informatics. One where most of the focus is on technology development rather than clinical meaning or implementation concerns. One where standards development stops and implementation is someone else’s concern. One where nowadays XML or JSON or Java or C# or the meaning of “Health Concern” dominate rather than a concern for better patient care. One where greenfields take precedence over brownfields. One where the abstract is more palatable than the real world.

This one example of HL7 v2 has been repeated ad nauseum in books on health informatics; in university lecture notes; on the HL7 Intl wiki; and many other places. The faulty message itself has  been used for testing various HL7 code libraries and floats around on blogs and github with ne’er a comment about it’s faults. Nobody seems to notice or care. This one v2 message, and probably its CDA counterpart and its FHIR counterpart would make an excellent subject for discussing the obstacles  to interoperability. It is not just this message that is faulty. Faults exist in many of the examples I look at. Those same faults translate to faults in real messages. Some of these faults last for years. Often the more severe ones are detected in implementations and slowly  resolved, often by expensive or fragile work-arounds and hacks. There is not the money nor the proper understanding nor proper leadership/governance to do otherwise. The pain is often born by vendors or system support personnel for the receiving systems or by the burgeoning integration teams needed to monitor and map defective fields or values for each and every participating system. Interoperability by manual intervention.

When I look at sample CDA messages I often see symptoms of the same culture. Because you can’t meaningfully view the computable entries of CDA documents we end up with faulty samples scattered around the web. Even the ONC, who professes to care about interoperability posts faulty CDA samples. I looked at the first one in over 6 months and saw a number of faults at https://github.com/jddamore/HL7-Task-Force-Examples/blob/master/RESULT_BMP_with_Tropinin.xml referenced as the approved CDA Example Task Force sample.

In the past the official FHIR site had the same problem. Whilst Grahame Grieve has tried very hard to detect errors in the examples cited on the standards site, the snippets of sample resources scattered around the web often contain errors. This problem is likely to balloon as more and more budding innovators incubate their own local resources.

Yet as much as the proponents of CDA or FHIR may wish otherwise, the bulk of health information in the real world is carried in HL7 messages. Those people who suggest that these messages could be readily mapped to CDA or FHIR in many cases simply do not understand the nature of the problem. If you can’t see the issues in the above message you cannot understand the nature, nor scale of the interoperability problem.

We cannot clean the toxins out of the blood by giving everyone a blood transfusion. We have to understand the physiology of the health information ecosystem. We have to have appropriate tools and standards to analyse and diagnose. We cannot do that just with faulty text book samples or by hand knitted cadavers.

Appendix

Here is the list I have garnered of the Health Informatics books citing the Ringholm sample message, some with attributions thereto. I’m happy to add to this if readers know of others.

• Braunstein: Practioner’s Guide to Health Informatics Pg 58
• Hutton: Pediatric Biomeidical Informatics: Computer Applications in Pediatric Research P 29
• Hovenga: Health Informatics: An Overview Pg 139
• Duplaga et al Transformation of Healthcare with Information Technologies Pg 327
• Trotter & Uhlman Meaningful Use and Beyond: A Guide for IT Staff in Health Care Pg 174
• Trotter & Uhlman Hacking Healthcare: A Guide to Standards, Workflows, and Pg 174
• Borko Furht, ‎Ankur Agarwal Handbook of Medical and Healthcare Technologies Pg 511
• Borko Furht, ‎Armando Escalante Handbook of Cloud Computing – Pg 559
• Taktak et al – 2013 – Clinical Engineering: A Handbook for Clinical and ..

Tags: HL7 | safety | semantic interoperability | standards