Why did HL7 Version 3 fail?

With the adoption of HL7 FHIR taking baby steps across the NHS, it is worth pondering why the new standard exists in the first place.

Successful interoperability can be defined as knowing what information is to be sent and received by two systems, when the transaction occurred and why the information was exchanged in the first place. This 'what', 'when' and 'why' represents a complete end to end package; defined and re-usable. HL7 V3 was designed to be this package but it is generally seen to be a failure.

Where HL7 V2 was exceptionally flexible, it could not be relied upon to carry standardised information and carried risk that each message needed to be re-engineered at some point in the transmission. There are several ways of doing a single thing in V2, largely due to a lack of agreement on the underlying definition of the data itself.

Version 3 fixed this problem, but inadvertently created another one. Benson and Grieve point out that in providing consistency, V3 lacked flexibility required for coal face operations. That's not to say that v3 could not be adapted, but rather that its' voluminous specifications required experts to understand the Reference Information Model (RIM) and use the supported tools.
It got expensive. Very expensive. Which is the exact opposite of the intentions of HL7 who tried to design a solution that was cheap and easy to implement. The pool of v3 experts was small and implementations needed significant resources behind them to drive success.

FHIR represents a key change in ideology in the way that the intellectual property is now handled. It's free to use and no longer precludes non-HL7 members using it (which is a sea change from the historical position). An unfortunate disease of NHS informatics is the chronic lack of funding and subsequent dearth of productivity. That's not to say there aren't a lot of good people working very hard, but the under funding means we have a tendency to do things on the cheap (and subsequently fail because we don't have the resources to do it right in the first place).

Trying to implement something as large as V3 and CDA is only within the gift of a national IT programme at the best of times and requires an exceptional amount of training and knowledge building for coal face informatics teams (our outsourcing that knowledge from third parties). Tooling needed to be custom built, and extending it was difficult. It was theoretically abstract and difficult to implement.

It also forced us down the dark alleyways of defining everything that there is to define up front. I am a supporter of doing the grunt work in clinical modeling as part of the business analysis process. It greatly simplifies the extracting the data for secondary uses, and greatly simplifies developemnt because the coder can get on with making great applications and not fiddle about with data standards/terminology/asking questions about fields. That's why I think OpenEHR has great potential and subscribe to the Norweigan 'do-ocracy' approach of only modeling what comes down the development pipeline. But there is a limit, and breaking a clinical model into more manageable chunks is the only way of making progress.

Grahame Grieve, the doyen of FHIR, posted both an indictment and praise of V3 in 2011 and it makes for very interesting reading. A key win that comes through is the use of CDA, an idea that has borne fruit with the developing CDA on FHIR standard being championed in England. CDA, as the name suggests represents a Clinical Document Architecture; the structure of how clinical documents can be represented to support interoperability for both computers and humans alike. Structured XML based and designed to support an array of clinical documents such as discharge notifications.

With my current work looking at how to best structure documents sourced from both OpenEHR Clinical Data Repositories and FHIR Resources CDA still makes a lot of sense with it's generic schema. And sometimes you just need a well structured document to convey the clinical story.

Despite the mistakes made with V3, there are lessons to be learned. And just because the great interoperability puzzle took a stumble does not mean it will ultimately it will remain unsolved. So step up FHIR.

Further reading and references:
Lessons From the Putative Failure of HL7 V3
HL7 needs a fresh look because V3 has failed
In the beginning…