FHIR vs openEHR

Hello all,

I am just reading into FHIR and openEHR technology and have read several times that FHIR is commonly used as a communication protocol and openEHR for data persistency.

Now I had a FHIR workshop and also here data can be stored with FHIR. Now I have not understood exactly what really justifies the effort of FHIR to openEHR mappings, if you could do everything with FHIR?

Does anyone here have a concrete example where I see why you should rather do the storage with openEHR and not with FHIR?
Thanks!

1 Like

Hi Micha, you’re correct. The emphasis on FHIR development is interoperability of health IT systems in sharing data. I don’t think I could suggest storing data in FHIR formats is most advantageous for how you need to use the data in OpenEHR and a clinical setting.

1 Like

Hi Micha, I hope this comparator I adapted few years ago from an example from Eneimi can help:

You can use both to store data, but openEHR is way more detailed than FHIR when defining the data points of a concept. And -in my experience- is way easier to query openEHR data comparing with FHIR queries. But end of the day, it depends on what do you want to do in the long term and the context and scope of your project, really.

8 Likes

Hi, there are two things to consider, what is standard specification and what is technology implementation.

Specification wise, it’s strange that you find anything to do with storage or persistence in the FHIR spec Index - FHIR v4.3.0

Though, in the openEHR spec there is indeed a service layer spec openEHR Platform Service Model and service implementation spec API Overview

The key point of openEHR having such service interface layer is to be able to access the EHR management from external systems.

Now, the openEHR scope by the specs is to manage EHR information and provide a data access mechanism that is standardized and based on the same semantic components as the EHR information definition: archetypes and templates. This implies persistence/storage of data.

By the specs FHIR is to operate over data in a standardized REST way (operations, URLs and resources), that is create and retrieve information. This doesn’t imply persistence/storage of data.

Then you have difference technology implementations, based on the specs, but that might extend or go beyond the scope of the standard specs. Like having FHIR storage solutions.

In openEHR the EHR storage solution is the core component of an openEHR architecture, and it is mentioned in the specs Architecture Overview

Even if you have a FHIR storage solution, I would argue the role of such repository is to manage EHRs, while in openEHR that is exactly the role of the storage solution. A FHIR repository can help as a cache, as a secondary analysis database, as a test platform, etc. but it’s not an EHR.

That is why many architectures choose to use an openEHR IMPLEMENTATION TECHNOLOGY PLATFORM to store clinical information, even to access the information using the SERVICE LAYER, and maybe integrate with FHIR by using those openEHR-native services, and use a FHIR IMPLEMENTATION TECHNOLOGY SERVER to receive FHIR requests. I use uppercase here to mark the difference between what is implementation technology and what is standardized in the specifications, so the main thing is: implementation technology can go beyond what is strictly specified in the specs.

So don’t be confused, spec is one thing and technology is another thing.

3 Likes

Since other people already pointed out the theoretical part i will state it practically.
To put it simple the tooling is way worse and currently scales badly (also due to the model being not designed to persist data), there was even an google dev blog article about how badly the fhir server are.
Also the openEHR model is way more matured and consistent due to its enormous international archetype library. In FHIR, as long as they dont change their model or standardise the profiles way more, people create zillions of profiles for the same thing. In my 5 years now working with FHIR i have seen more blood pressures then i can count. This then requires that you map internally the blood pressures to leverage consistency lol. A problem that you dont have in openEHR where you have one international archetype for that. Stuff you dont need is just canceled out by the templates meanwhile in FHIR its the other way around. You need to add fields to a very basic e.g. observation. As a result everyone adds its blood pressure values in a different way. So why on earth would somebody want to persist FHIR (in its current state) for something that is to be stored and maintained for decades like Patient data (if we talk about e.g. representing a comprehensive EHR, for sure there are scopes where its not an bad idea).
Besides that openEHR alos has a very nice query language.

In the end FHIR provides flexibility to its models which is nice for companies developing fast some solutions , but also opens the door for redundant and inconsistent data. openEHR is on the other hand better maintainable etc. with its stable model which makes it way better for longtime use and persisting data. There also many other arguments and problems in both directions.
So you see thats why many projects use both :wink:

10 Likes

Hi,

I like to raise another issue. Despite being advertised as an API technology, FHIR is surprisingly bad for frontend development once things are getting a bit more complicated (=need to create multiple resources, internally referencing these resources and then putting them in a transaction bundle). Typically (to my experience), instead of using “proper” resources for sending data from client app to server, people use FHIR Questionnaire Responses instead and then map the data to proper resources in the backend. So you basically start developing apps by defining mappings and working around the intended use of the FHIR REST API.

With openEHR, you can use different API formats (because the API and “payload/network formats” are not the core of the spec) and then use complementing formats as WebTemplates with FLAT and STRUCTURED formats which are automatically converted into the database format on the standardized Reference Model. While not perfect, this allows way more powerful WYSIWYG/low-code editors and also way more efficient manual app development.

4 Likes

It is great question because as you say it is possible to store some clinical data in FHIR and in some simpler use cases, this may make sense.

As others have pointed out though, the FHIR ecosystem was never designed for this purpose, and as your infomation gets more complex, it struggles with a lack of concrete definitions, limited querying and a modelling methodology/ tooling to support a data platform approach.

You should definitely look at this article by Alistair Allan, who started as something of an openEHR sceptic but now sees things differently

As a concrete example, we have been working on several End of life care datasets, where only a tiny proportion can be carried in FHIR concrete resources e.g meds, allergies, problems but everything else would need to be carried in large bundles of heavily profiled FHIR Observations or QuestionnaireResponses. As others have said , this gets really tricky to model, standardise with a clinical community and keep coherent over time in FHIR. That is not a criticism of FHIR - it was simply never intended for that purpose.

5 Likes

THis is a very interesting paper.

1 Like