The Times, They Are a-Changin’…

Channelling Bob Dylan? Not quite! But it is interesting to see some emerging HL7 and openEHR activity, at least in this little part of the world – Australia and New Zealand 🙂

Maybe this is a model for the rest of the world – at least food for thought!

For too many long years there appears to have been a palpable barrier between the HL7 and openEHR communities. Some individuals have managed to bridge it, but there has definitely been a reluctance to engage at organisational level. It stems from before my time; I suspect vocal personalities with strong, diverging opinions were at the root. To some, it is a little like a religious argument – where “only my way is the right way”!

Be that as it may – the barrier appears to be softening and became evident to me for the first time back in January last year as I attended the HL7 meeting in Sydney. A full day openEHR workshop was presented by a diverse group of Australian companies plus NEHTA experts; Bob Dolin in attendance, amongst others. Keith Boone tweeted his initial impression of the openEHR approach after I demonstrated our tooling and then blogged about it. My thoughts were captured in my Adventures of a clinician in HL7 post.

Fast forward to 2012…

You may have seen some announcements from New Zealand. Firstly, publication in April of the Health Information Exchange Architecture Building Blocks where they specified “2.3.2 The data definitions of the Content Model shall be formulated as openEHR archetypes” within the “10040.2 HIE Content Model, a framework for the creation of a common set of logical data definitions” document.

And secondly: HL7 New Zealand and the openEHR Foundation signed a Statement of Collaboration – also announced April 2012. Now there’s a headline that might have been a surprise to many – HL7 NZ & openEHR clearly intending to work closely together!

Keynote: EHR – the Killer App?

Only last Thursday Hugh Leslie & I participated in a seminar, “Bringing the Electronic Health Record to Life,” organised by HL7 NZ, Health Informatics New Zealand (HINZ) and the University of Auckland. Prof Ed Hammond, ‘the father of HL7’, keynoted the meeting: “EHR – The Killer App”. In the afternoon mini-tutorials, David Hay presented on FHIR, and Hugh, I and Koray Atalag presented a little about our openEHR work, including clinical knowledge governance and clinician engagement. Koray (a HL7 NZ member and openEHR localisation program coordinator) announced within the meeting that HL7 NZ is the likely organisation to auspice a NZ chapter of openEHR. Now that definitely has to start to change the openEHR/HL7 dynamic somewhat, even if HL7 NZ is a relatively small international affiliate 🙂. The HL7 NZ leadership, to their absolute credit, are certainly not being constrained by any traditional ‘turf wars’.

The following day, last Friday, Hugh and I presented a full day workshop on openEHR, again sponsored by HL7 NZ, HINZ and the University of Auckland. As I understand it, this was the first opportunity for the openEHR approach to be socialised with the broader healthIT community in NZ; about 25 in attendance including members of the HL7 NZ Board, vendors, and regional and HealthIT Board reps. The focus was on how openEHR could support the creation of a range of technical artefacts to meet NZ’s requirements for CDA messaging (and beyond), generated from a cohesive and governed pool of clinical content models.

Interestingly we had a surprise attendee for the workshop – Ed Hammond joined us for the whole day. I won’t presume to guess what Ed has taken away from the day, although he did offer up a comment to the group about the value of exploring use of archetype content directly within CDA.

Post workshop one of the attendees tweeted:

“At #HINZ #openEHR talks last 2 days. openEHR is a fantastic foundation for practical action. Left knowing steps I will take. How cools that!”

And of course, there is an HL7 AU meeting in Sydney early next week entitled “FHIR?  CIMI? openEHR? What’s the Future of eHealth & mHealth Standards?” The agenda:

  • Keynote: Ed Hammond (again) – “FHIR, CIMI and openEHR – What’s the Future for eHealth Standards?”. [It will be very interesting to hear his opinion after last week’s openEHR exposure.]
  • Grahame Grieve: “FHIR – What is it? Why has it suddenly become so popular?”
  • Hugh Leslie: “Recent developments in openEHR and CDA”, and
  • I’ll be reporting on the CIMI project.

It would be an interesting day to be a fly on the wall! 2 HL7-ers and 2 openEHR-ers addressing an HL7 meeting – all exploring alternatives to the current approaches!

So, keep your eye on the space where HL7 intersects with openEHR – might be some interesting developments.


Within the openEHR community, and definitely within Ocean Informatics where I work, we are certainly finding that significant interest is being certainly generated from many sources about the process of using standardised and governed openEHR clinical content as a means to generate range of technical artefacts, including CDA. The New Zealand national interest and activity is evident, as outlined above. And in addition:

  • In Australia, NEHTA has piloted the use of clinician-reviewed archetypes from the NEHTA Clinical Knowledge Manager as the start point for generating a number of the PCEHR technical specifications. This work is ongoing and being extended.
  • CIMI, the initiative that grew out of HL7 but is now independent, is seeking to develop an internationally agreed approach to clinical modelling and generation of multiple technical outputs. It has already agreed to utilise openEHR ADL 1.5 as its modelling formalism and is using the openEHR Reference Model as the starting point for developing a CIMI Reference Model. We watch this progress with interest.
  • And Brazil’s national program has recently reconfirmed its intention to commence using openEHR.

Whether the final solution is openEHR or CIMI or even something else, I think that the advent of standardised clinical models as the common starting point for generation of a range of technical outputs is upon us. Ignore it at your peril. And specifically, I would suggest that HL7 International should be considering very seriously how to embrace this new approach.

Sticking with the quasi-gospel theme, maybe it is now a bit more like Curtis Mayfield’s “People Get Ready“:

People get ready
There’s a train a-coming
You don’t need no baggage
Just a-get on board

Let’s leave our baggage behind, get on the ‘train’ together to collaborate and create something that transcends any health IT domain turf war! Don’t get left behind…

4 thoughts on “The Times, They Are a-Changin’…

  1. Why didn’t OpenEHR follow the HL7 standard rather than invent something new? Isn’t this OpenEHR vs HL7 problem a self-inflicted problem by OpenEHR? Why then should HL7 reconcile with OpenEHR? I am not asking these because I object to what is happening or what has happened. I just want to understand why the fundimental difference exists in the first place. Not that knowing the root cause will make the future easier, but being ignorant of it will surely not help.

    • Hi John,

      openEHR has been in development for more than 20 years and the two initial authors of the openEHR specifications, Sam Heard and Thomas Beale, were intimately involved in HL7 for many years, with Sam being Chair of the EHR Working Group for some time. I suspect he may have mentioned his openEHR work once or twice within the HL7 community during that time 🙂 With hindsight it is pretty safe to assume that for whatever reasons HL7 was not deemed to be a good home for openEHR at the time – subsequently the openEHR Foundation was formed in conjunction with University College London to manage the specifications. I don’t know the details, nor particularly care – it was a long time ago and people and attitudes are changing.
      The openEHR spec have always been focused on a full EHR architecture and was not in any way trying to replicate HL7’s work on messaging standards. They predate the v3 work by years, so it is clearly not a simple matter of openEHR following HL7 or not.
      The openEHR approach to standardising and governing clinical content – whether for EHR persistence, exchange, aggregation, integration, analysis or as a basis for decision support – is arguably world leading and could be leveraged within HL7, with advantage to all. From my point of view there is not a HL7 vs openEHR problem – they are not competitors, but we do have an enormous opportunity to collaborate and bring together the best of both.

    • Since I was involved at the start, I will try to provide an answer of some kind. HL7 in 1999 (when I first went) was getting started with HL7v3 and the RIM. Over the period of the next 2 years, it became clear that the aim was still to define messages (RMIMs, HMDs etc), but with the new abstract RIM, and to ignore the semantics of ‘data inside systems’. Our view is that this was anachronistic – there were emerging good models for health data in systems, where health data are created in the first place, and having a fixed message structure dictating the payload isn’t compatible with that. Instead, we wanted to a) build single-source models of content for all uses – UI, messages, APIs, persistence and b) generate message definitions from these models, and use modern transport methods, i.e. web services, REST etc to move the same. Pre-defined message models – especially as complicated as HL7v3 – just gets in the way of that.

      So openEHR went a different direction: it defined an information model of EHR and other health data, and a framework for creating archetypes (content models), templates (defining logical data sets), terminology bindings and portable queries (AQL) from which concrete implementation artefacts could be generated, including message XSDs, APIs and so on. Two particular differences stand out: 1) all openEHR systems in the world use the same canonical information schema, so the data are guaranteed interoperable everywhere and 2) the archetype & template modelling is clinician-led, completely out of the hands of IT people. Tools enable content modellers to generate the appropriate technical artefacts.

      If HL7 had provided what was needed, we would have gladly used it, since the real game is what goes on top of the data – intelligent services – and it would have saved time. We are only now starting to address these challenges, based on a very strong and flexible technical platform.

      In the meantime, HL7 seems to have progressed beyond the original idea of RIM-based messages to more flexible uses of CDA (including archetype-based), and FHIR, a content micro-format approach. I see many opportunities for collaboration today.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your 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