This blog post is based on a presentation I made to The Australian Medical Software Industry Association (MSIA) at a recent meeting. The focus of this presentation was a CEO level summary of where HL7 is at, as context for how to understand the use of HL7 standards in Australia. Note that interoperability is a major piece of the landscape here in Australia, and most CEOs are somewhat (through to intimately) involved in it, and therefore at least familiar with the innards of a v2 message.
Use of HL7 in Australia
HL7 v2 was first used for exchanging patient management information in single-campus hospitals. Over the last 20 years, the use of HL7 v2 has grown from that to be used for diagnostic reports in hospitals and then between clinical providers, and also referrals and discharge summaries within and between providers. There is also some use for pharmacy messaging, though I am only aware of this internally to an institution.This use has been aided and fostered by a series of Australian standards known by AS 4700.x where x indicates the intended use of the standard.
Recently, the National e-Health Transition Authority (NEHTA) has been introducing a new set of exchange specifications based on a more recent HL7 specification called CDA (“Clinical Document Architecture”) and the first round of implementation is in high gear at the moment.
HL7 v2 is a messaging based standards – the content is exchanged in messages that have codes that indicate what real world events they relate to. The messages are divided into segments, segments into fields, fields into components, and components into sub-components – 5 levels of nesting. The syntax is based on delimiter characters for each level. HL7 v2 messages are backwards compatible – what you see in the message will never move to a new “place”, or be re-used for something else. Here’s an example:
V2 has lasted amazingly well – it’s still getting a lot of use, new adoption, and has a serious fan club. What’s good about v2?
- It’s a real simple syntax – you can roll your own parser pretty quickly (though a caveat: we consistently have problems in Australia with characters not being escaped or un-escaped properly)
- The v2 concept is simple – it takes about 5 minutes to explain the various parts, and the implementation stack is shallow (programmer, analyst, support people – everyone looks at it the same way)
- There’s a heck of lot of v2 adoption out there- toolkits are mature, libraries thoroughly debugged
- it’s easy (relatively) to find experienced people – there’s lots of them
- the strictly enforced backwards compatibility preserves investment (in fact, it’s actually at least an order of magnitude easier to switch between versions than to deal with the variation between implementations, though this doesn’t stop large vendors charging $100,000+ for changing versions – shame on them)
On the other hand, there’s some real problems with v2:
- It really is old tech – you have to roll your own parser, it’s not xml or json, and you just can’t leverage it; it’s not a good fit to any coherent architecture
- The definitions and approach were never rigorous – the definitions are inconsistent and also – worse – incomplete. Much is left to two implementers coming to joint agreement about, and the messages can’t be understood outside that agreement
- The described syntax is very focused on admin/support
- The 5 level hierarchy, and the fact that things are defined at a particular level of the hierarchy, means that it’s very difficult to describe sophisticated clinical information well in v2. Clinical information is delegated to a tree of name-value pairs with no good way to control them
- Formatted text support is still based on a grid of fixed font characters and console features such as moving the cursor around
- The strict backwards compatibility rule ensures that old decisions seriously limit new ideas, and any kind of fix for these other issues
- And “if you’ve seen one v2 interface, you’ve seen one v2 interface” – every interface is different
A long time ago HL7 looked at that list and decided to do something better.
The next version of HL7 would be different:
- Based on rigorous and complete definitions – no more needing to consult local agreements to understand the content
- Consistency would be enforced by deriving all instances from a common reference model that also imposed thorough and reliable modeling
- The base would be constrained to useable artifacts for particular business requirements
- which would produce generated artifacts and a specified XML format for exchange
- the whole stack would be computable to aid with implementation
- There would be notional backwards compatibility – it would be understood how to migrate from old to new formats, but changes would be possible
HL7 has spent 15+ years developing v3 now. It’s had an immense amount of work, but adoption is disappointing. But it’s not that there’s nothing good about v3:
- It does have rigorous definitions
- There is a computable base, and there’s a number of software tools and applications out there that use the RIM as a computable base (including Oracle’s HTB at the core of the Australian pcEHR)
- There was an absolutely massive requirements gathering effort that provides a very comprehensive international view of the healthcare landscape.
- And it’s XML, so you can use and leverage the XML tool stack
But that just hasn’t been enough to overcome the rather evident problems with v3:
- There’s a really deep implementation stack; it takes months to build it, and different participants have radically different perspectives on it once it’s built.
- V3 has complex concepts and syntax – everything must be understood at multiple levels and is documented in multiple long documents
- The core concept – constraint on a common model – fails to deliver on it’s basic goals (mostly because it’s just too hard not to introduce new semantics by stealth in the derived models)
- Common semantics doesn’t produce common engineering
- “if you’ve seen one v3 interface, you’ve seen one v3 interface”
So after 15+ years, there’s a few implementations by large national programs that cost lots of dollars, and require lots of implementation support and tooling. Realistically, there’s not going to be any more implementations, and v3 development is tailing off….
But all is not lost: enter v3 lite: CDA.
If you’ve seen one interface
But before we talk about CDA, a diversion about interfaces. They say “if you’ve seen one v2 interface, you’ve seen one v2 interface” – and it’s true. But I think that if I’ve seen one set of interface requirements, I’ve seen one set of interface requirements. The question we need to ask is “how much of the variation between interfaces is due to things internal to v2, and how much is external – because you won’t be able to get rid of the external variation.
There’s no question that some of the variation is due to v2′s incomplete and inconsistent definitions. But I think it turns that this is a small proportion of the total. With v3, we consciously delivered a standard that pushed back against variation between interfaces – and we discovered that it didn’t present a coherent way of dealing with that variation – in fact, it made the problem worse. With v3, you could actually joke that if you’ve seen one interface, you already seen lots of interfaces…
CDA is a clinical document. It has a header that identifies the document, who it is about, who wrote it and/or signed it, and a few other useful context things, some document narrative (formatted text with images), and some supporting structured data. The header and the structured data are based on the V3 RIM with constraint (which means that CDA is a v3 thing, though not “v3 messaging”). Compared to v3, CDA is easy to adopt. But CDA is a very different idea from a v2 message indeed.
It’s important to understand that CDA is a document – and it should be thought of like a word document. Word documents have properties, and you can make comments on them. Wouldn’t it be good if you the properties included some medically useful things, and you could add structured data in the comments?
That’s just what CDA is – a format for doing that. Because CDA is the bit of v3 that actually worked, a lot of people are using it for data exchange, rather than as a document but it’s not really a good fit for that use.
So what’s good about CDA?
- Its’ (relatively) easy to adopt – at least compared to some alternatives including v3
- It’s very flexible and adaptable, and all CDA documents have the same basic XML structure
- It’s got wide adoption across the world, and there’s a lot of implementation guides published
- The document semantics suit large EHR’s (i.e. national ones) where there is poor clinical governance across the scope of the EHR
(Aside: That last point is very definitely the context here in Australia. We are implementing a national EHR (the pcEHR – it is a national EHR, though carefully limited in functionality for political reasons), and we are doing so in the context of poor clinical governance. Now making that statement at the MSIA meeting seems to have caused some waves for me, because some thought I was criticizing NEHTA’s clinical leadership and governance (which I contribute to, btw). But no – that’s not my point. My point is, NEHTA and/or DOHA or anyone else can’t simply decide how a certain clinical fact (an allergy, say) should be represented, and then have everyone in Australia agree (let alone actually implement the agrement – hell we’re lucky if they even comment). Given that there’s no prospect of getting the clinical users to agree with each other, we have poor clinical governance, and we have to live that. In that context, a document based EHR – the EHR you can have – is better than a data based EHR – the one you can’t have.)
But there are also problems with CDA:
- A document is not a good fit with transactions
- We still have ongoing concern and confusion about narrative vs text
- Limping along with v2 transactions and CDA data sets (and I have a Standards Australia task against my name to somehow do something about that)
- The constraint methodology is time consuming and resource intensive – both to produce and implement the CDA Implementation Guides
- The structured data part of CDA is both too complex and too simple
- It’s too simple because it’s difficult to represent the agreed Australian clinical models (such as they are) cleanly in the CDA data
- It’s too complex because I work with the implementers every day at the moment, and I feel their pain
CDA is the near term future for Australia, but I hear rumbles across the community: there has to be a better way…
Where does that leave HL7?
Well, v2 is widely implemented, and we’ve used it harder than anyone else (so far as I can see), but it’s self limiting. There won’t be any more v3 implementations, and the national programs that used v3 will have to figure out what to do. CDA is a good for clinical documents, though I suspect there has to be an easier way, and it’s not a good fit for exchanging data. So what should HL7 do?
Few people at HL7 are happy with the current situation. They’ll support change – a fresh look – but what would you do. Well, there’s two ideas around: CIMI and FHIR. I’ve commented on them at length elsewhere (though my blog posts are a bit dated now – I’ll have to update them). But both CIMI and FHIR are still very early in their process. We’ll have to see what develops.