Monthly Archives: June 2017

Report from joint #openEHR / #FHIR meeting

Last month, the openEHR and FHIR communities met for a day in Norway. From the openEHR community, Ian McNicoll and Silje Ljosland Bakke were present, and from the FHIR community, Ewout Kramer and myself were present, along with a group of Norwegians who are involved in FHIR and/or openEHR. My thanks to HL7 Norway, DIPS (en) and the Direktoratet for e-helse for collaborating to bring the meeting together.

The overall agenda for the day:

  • Welcome, introductions / complaints about the weather (de rigueur, but Norway was lovely, there was even some sun one day)
  • Opening presentations from Ian and myself
  • Discussion on specific model mapping HL7 FHIR – openEHR
  • Discussion on a general form solutions
  • Some general questions on HL7 FHIR – openEHR: Mapping, query, Workflow, Pub/Sub, Terminologies, Modeling

And then drinks afterwards, where we solved all the worlds problems (except for a few big ones).

I enjoyed the day greatly – there was a real positive spirit, based on a recognition that both communities are vibrant productive communities that have much to offer each other. Technically, the FHIR and openEHR communities have different scopes, with some overlap, and there’s plenty of real world problems that FHIR is not attempting to solve that openEHR has invested in – and vice versa. Given good will, and a focus on pragmatic outcomes, we can work well together and both derive benefit from that collaboration.

Given that, most of the day focused on immediate challenges faced by Norwegian implementers today. The most obvious question is ‘I have content described by an archetype, and I want to exchange that using FHIR. How do I go about that?’  Right now, there’s no clean simple answer. There’s several different paths, which work variably well. We discussed some of the issues with a focus on mapping between openEHR and HL7 FHIR of observations like body temperature. The outcome of the discussion is that the place to focus is mapping openEHR templates to/from FHIR Profiles. We’ve created a joint workspace in the openEHR Github repository so we can work together on that (as of today, it’s empty. It’s work in progress and will gradually start to fill up, and hopefully with useful stuff).

The plan is that we’ll automatically convert openEHR archetypes and templates to FHIR Logical models, and then map to FHIR resources using the FHIR Mapping language, and generate profiles and implementation guides from that. If that works well (not yet known), this would establish a single demonstrated path to interoperability. Note that I didn’t say a simple path – to make it simple will require further content reconciliation between the communities – perhaps this will provide the impetus for more investment in that (we’ve done some, but it’s hard work).

Then we discussed the different and similarities of the FHIR and openEHR approaches to forms/questionnaires, and what would be involved to interconvert between the different formats. We agreed to work on this further, including a set of activities on Form Mapping at the FHIR DevDays meeting in Amsterdam in November.

One idea that has been floating around recently is for openEHR to use the FHIR binding syntax and terminology services – we discussed this a little, and hopefully we can work towards a concrete proposal for this in the next few months to see how it flies in the wider openEHR community.

Overall, the meeting created a lot of prospects about what we can do together, but now we actually have to follow up and do them.

p.s. Thanks to Sigurd From from DIPS for keeping notes from the meeting which I used for this report

p.s. Also, thanks to the Norwegians for being great hosts. In addition to Norwegian national day, I enjoyed the fjords greatly. Now I just have to find the right supplier of Fjord Cider here in Australia, and all will be good.

Interconversion between #FHIR and HL7 v2

Question

What advice do you give for introducing FHIR in new software, while continuing to maintain HL7v2 interoperability with client applications that do not speak FHIR?

For example, are FHIR resources the way to go as an internal representation of an application’s health care data?

If yes, is it practical to convert HL7 messages into FHIR resources (e.g. Patient, Practitioner, ProcedureRequest, ReferralRequest, Appointment…)? What open source software do you recommend for converting HL7 messages into FHIR resources (and vice-versa)?

Or is it better to use FHIR for external information exchange only (with outside FHIR clients)?

Answer

I’ve worked with several projects rebuilding their products around FHIR resources. Like all development methodologies, this has pros and  cons. What you get out of the box is a highly interoperable system, and you get a lot of stuff for free. But when your requirements go beyond what’s in the specification, it starts to get hard – FHIR is an interoperability standard, that focuses on the lowest common denominator: what everyone agrees with. Whether that’s a net benefit depends on how far beyond common agreement your going to go. (This, btw, is a demonstration of my 3rd law of interoperability).

It is practical to convert HL7 messages to FHIR resources and vice versa, yes. We’ve seen plenty of that going on. But there’s no canned solution, because to do the conversion, you have to do two things:

  • Figure out all the arcane business logic and information variants and code this into the conversion
  • Figure out how to integrate your conversion logic into your application framework

The upshot of this is that you have a programming problem, and most people solve this by taking a open source libraries for v2 and FHIR in the language of their choice (most languages have one of those) and writing the business logic and application integration in their development language of choice. Hence, there’s no particular open source library to do the job other than the parsers etc. There are some commercial middleware engines that include FHIR as one of the formats that can be supported.

In the FHIR spec, we’ve defined a mapping language that tries to abstract this – so you can separate the business logic from the application integration, and a platform independent business logic that has libraries for whatever platform. That’s an idea that is gradually starting to gather some interest, but is still a long way from maturity.

With regard to using FHIR for external exchange only… what I usually say about this that is that it makes sense to implement FHIR for new things first, and then to replace old things only when they become a problem. And most new stuff is on the periphery, where the architectural advantages to FHIR are really big. But internally, v2 will increasingly become a major service limitation in time, and will have to be replaced. The open question is how long that timeline is. We don’t know yet.