Round 1: FHIR vs OpenEHR...FIGHT!
Published by John Meredith on September 29th, 2017
Following the recent OpenEHR event held at Ziferblat Media City in Manchester by Salford Royal NHS Foundation Trust, the debate on OpenEHR seemed to heat up quite considerably. It led to an interesting bit of tit-for-tat trolling discussion on Digital Health (which I of course took part in) with the announcement that Plymouth would be rolling out the Marand Open-Ep solution. The knives seemed to be out for OpenEHR for unclear reasons, but on the fringes I got involved with some conversations on how OpenEHR fits into the FHIR world.
While at the event at the Ziferblat, during one of the break-out sessions we raised the somewhat naive question "how do you get OpenEHR repositories to communicate via FHIR?". This was met with near unanimous guffaws and howls of pain: "Why would you want to do that?!". The primary use case I wheel out is about Welsh patients needing tertiary referrals to England, and the requirement to send documentation electronically with that patient. "Oh that...yeah. Fine" is the response. So what's the problem then?
The problem is that I was guilty of conflating two different things together. Apples and oranges as it were, which was reflected by the voice of the OpenEHR community. There was no partisan "don't use FHIR" response at all. It was a clear and unequivocal guidance to use the tools as they are intended to be used. And I think this is a potential banana skin for the interoperability community (and I would say Interopen in general) that can be described in this tweet:
Uhoh, This content has sprouted legs and trotted off.
There is nothing inherently wrong with this message of vendor neutral archives and Open Platforms - that is the ultimate goal. But it is presenting FHIR as a substantial component to solve the interoperability puzzle and I think that is disingenuous if you are expecting anything more than a document bound health record or only the elements described in the FHIR resource list. There is a significant amount of detail in the two boxes labeled "Web services" and "Cloud based PHR" which should not be underestimated.
The HL7 tooling resources might certainly get you going but unfortunately in health we like to consider ourselves to be a special case at local, national and international levels. We just cannot leave a well defined model as it is. We have to....tinker. We have to....mess. It was recently described to me by a GP that when I had three clinicians in a room to discuss a design, I ended up with seven opinions*. And so we customise something and ultimately create a unique vision of our bit of data. But this is the fundamental enemy of interoperability and we have to agree to common data standards on some level.
How easily FHIR resources can be customised remains to be seen - I simply don't know and won't comment either way until I learn more. But my hunch is that FHIR's perceived 80% coverage of the EHR is a fallicy when we take into account the breadth of the potential health record as a whole. I am neck deep in a clinical model for the Welsh Diabetes solution, and our data dictionary has thousands of fields in it. Some are common to other specialties and models, but some are not.
The way FHIR describes something like Smoking Status or Blood Pressure is as an Observation resource. The structure of the resource is fairly generic containing elements such as status, codes identifiers and categories. Individual discrete components can also be defined (such as systolic and diastolic blood pressures). This flexible structure can easily describe an almost infinite array of clinical data, but this will also get complex. There is the potential to end up with a health data repository filled with perfectly well defined information but describing things in slightly different ways, either at different levels of the Snomed CT hierarchy, or using LOINC (or God forbid "local" reference data). The shadow of 12 different version of Sodium and 5 different blood pressure definitions could be a reality in a poorly corralled repository.
One of my go to articles on OpenEHR vs FHIR is written by Thomas Beale who describes the relevant differences clearly but the brief conclusion is that FHIR offers benefits for the messaging, while OpenEHR is the backbone of the scalable EHR model. But importantly OpenEHR comes before FHIR: it is the definition of the content of the message. FHIR on the other hand dictates the structure of the message itself. No one is (yet) describing a FHIR equivalent Clinical Data Repository. And that's because without the reference model, the structures could become a horrific mess and there has to be some equivalent of a Clinical Knowledge Manager. Every OpenEHR CDR conforms to the same reference model underneath.
There's also another Elephant in the room which is best described as parochial nay-saying by the development community who see HL7 as their domain and clinicians need to stay away because they over complicate things and make a mess. That clinicians impede implementation of standards. And if that sounds overly confrontational then good. It is very easy to describe OpenEHR as a proxy for this kind of modeling but that is fundamentally missing the point. Any tool in the wrong hands can be abused even with good intentions.
FHIR will only succeed if it can be the conduit for meaningful clinical data (and that meaning can only be defined by clinicians). But there also needs to be policing of clinical modeling decisions by the development community, and the cultivation of a symbiotic relationship to ensure progression in solving The Great Interoperability Problem. The good news is that the OpenEHR community realises that it has to break down these barriers, and more clearly describe what it is trying to do. Over time the message should get out and the industry will realise that FHIR and OpenEHR are not there as competing standards, but simply standardised ways of doing different things. Proponents of FHIR need not feel threatened by the rise of OpenEHR as I strongly believe we need them both.
*I think the maths works out like this: Clinician A agrees on Point A. Clinician B agrees point B. Clinician C argues Point A is invalid. Clinician B disavows their point and Adopts Point A. And so on...
BOOTNOTE: Despite my slightly tabloid headline, I am not intending to write "Round 2 to n" along similar lines. It was more or less click-bait given that the "fight" is largely a misunderstanding in the first place and does not really exist.
While at the event at the Ziferblat, during one of the break-out sessions we raised the somewhat naive question "how do you get OpenEHR repositories to communicate via FHIR?". This was met with near unanimous guffaws and howls of pain: "Why would you want to do that?!". The primary use case I wheel out is about Welsh patients needing tertiary referrals to England, and the requirement to send documentation electronically with that patient. "Oh that...yeah. Fine" is the response. So what's the problem then?
The problem is that I was guilty of conflating two different things together. Apples and oranges as it were, which was reflected by the voice of the OpenEHR community. There was no partisan "don't use FHIR" response at all. It was a clear and unequivocal guidance to use the tools as they are intended to be used. And I think this is a potential banana skin for the interoperability community (and I would say Interopen in general) that can be described in this tweet:
Uhoh, This content has sprouted legs and trotted off.
There is nothing inherently wrong with this message of vendor neutral archives and Open Platforms - that is the ultimate goal. But it is presenting FHIR as a substantial component to solve the interoperability puzzle and I think that is disingenuous if you are expecting anything more than a document bound health record or only the elements described in the FHIR resource list. There is a significant amount of detail in the two boxes labeled "Web services" and "Cloud based PHR" which should not be underestimated.
The HL7 tooling resources might certainly get you going but unfortunately in health we like to consider ourselves to be a special case at local, national and international levels. We just cannot leave a well defined model as it is. We have to....tinker. We have to....mess. It was recently described to me by a GP that when I had three clinicians in a room to discuss a design, I ended up with seven opinions*. And so we customise something and ultimately create a unique vision of our bit of data. But this is the fundamental enemy of interoperability and we have to agree to common data standards on some level.
How easily FHIR resources can be customised remains to be seen - I simply don't know and won't comment either way until I learn more. But my hunch is that FHIR's perceived 80% coverage of the EHR is a fallicy when we take into account the breadth of the potential health record as a whole. I am neck deep in a clinical model for the Welsh Diabetes solution, and our data dictionary has thousands of fields in it. Some are common to other specialties and models, but some are not.
The way FHIR describes something like Smoking Status or Blood Pressure is as an Observation resource. The structure of the resource is fairly generic containing elements such as status, codes identifiers and categories. Individual discrete components can also be defined (such as systolic and diastolic blood pressures). This flexible structure can easily describe an almost infinite array of clinical data, but this will also get complex. There is the potential to end up with a health data repository filled with perfectly well defined information but describing things in slightly different ways, either at different levels of the Snomed CT hierarchy, or using LOINC (or God forbid "local" reference data). The shadow of 12 different version of Sodium and 5 different blood pressure definitions could be a reality in a poorly corralled repository.
One of my go to articles on OpenEHR vs FHIR is written by Thomas Beale who describes the relevant differences clearly but the brief conclusion is that FHIR offers benefits for the messaging, while OpenEHR is the backbone of the scalable EHR model. But importantly OpenEHR comes before FHIR: it is the definition of the content of the message. FHIR on the other hand dictates the structure of the message itself. No one is (yet) describing a FHIR equivalent Clinical Data Repository. And that's because without the reference model, the structures could become a horrific mess and there has to be some equivalent of a Clinical Knowledge Manager. Every OpenEHR CDR conforms to the same reference model underneath.
There's also another Elephant in the room which is best described as parochial nay-saying by the development community who see HL7 as their domain and clinicians need to stay away because they over complicate things and make a mess. That clinicians impede implementation of standards. And if that sounds overly confrontational then good. It is very easy to describe OpenEHR as a proxy for this kind of modeling but that is fundamentally missing the point. Any tool in the wrong hands can be abused even with good intentions.
FHIR will only succeed if it can be the conduit for meaningful clinical data (and that meaning can only be defined by clinicians). But there also needs to be policing of clinical modeling decisions by the development community, and the cultivation of a symbiotic relationship to ensure progression in solving The Great Interoperability Problem. The good news is that the OpenEHR community realises that it has to break down these barriers, and more clearly describe what it is trying to do. Over time the message should get out and the industry will realise that FHIR and OpenEHR are not there as competing standards, but simply standardised ways of doing different things. Proponents of FHIR need not feel threatened by the rise of OpenEHR as I strongly believe we need them both.
*I think the maths works out like this: Clinician A agrees on Point A. Clinician B agrees point B. Clinician C argues Point A is invalid. Clinician B disavows their point and Adopts Point A. And so on...
BOOTNOTE: Despite my slightly tabloid headline, I am not intending to write "Round 2 to n" along similar lines. It was more or less click-bait given that the "fight" is largely a misunderstanding in the first place and does not really exist.
Posted on September 29th, 2017