FHIR vs openEHR

Integration HL7 FHIR
1

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
2

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.

2 Likes
3

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

compare_fhir_openehr
compare_fhir_openehr977×544 58 KB

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.

9 Likes
4

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
5

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
6

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.

5 Likes
7

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
8

THis is a very interesting paper.

2 Likes
9

I would appreciate the opportunity to revisit a topic of interest. While exploring both FHIR CRUD & Search API and OpenEHR, I’ve observed that FHIR seems to offer a more persistent approach, particularly due to its more user-friendly JSON representation and a standardized API, which appears less prevalent in OpenEHR. In light of this, could you kindly elaborate on the distinctive features that OpenEHR offers?

  1. I’m intrigued by the hierarchical EHR structure (EHR, SECTION, ENTRY) in OpenEHR. This approach seems quite unique, especially when contrasted with the more familiar REST API structure of FHIR. Could you please provide more insight into the advantages or reasoning behind this design choice?
  2. OpenEHR encompasses a variety of concepts like RM, Archetypes, Templates, and Compositions. This complexity appears quite extensive, especially when compared to FHIR’s more streamlined StructureDefinition / Resource core model, which aligns with the Domain Aggregates concept from Domain-Driven Design. Could you explain the benefits of this comprehensive approach in OpenEHR?
  3. From a web development perspective, the JSON representation in OpenEHR seems to present some challenges in terms of intuitiveness and ease of use. Could you share your perspective on how this design choice enhances the functionality or usability of OpenEHR?
  4. As someone with 15 years of experience in Health IT, I find the initial learning curve for OpenEHR somewhat challenging. Could you offer any guidance or resources that might simplify the process of understanding and implementing OpenEHR?
10

To be honest, FHIR appears to be an interop standard, whereas OpenEHR looks like someone’s sophisticated system docs, with many “opinionated” design desicions.

11

Watch the youtube videos of @Sidharth_Ramesh they will shed some light into this

The spec can be overwhelming, openEHR aims to represent an entire EHR.
It also has a standardized REST API, archetypes and templates similar to FHIRs resources and profiles etc.
Otherwise i would just recommend setting up ehrbase and playing around with it.

The blog of Thomas Beale is also very good:

12

I’m more interested in key differences between FHIR and OpenEHR, than in learning OpenEHR basics

13

Some resources:

In response to some earlier questions you had:

openEHR implementers would be amused by this comment - since openEHR is about persistence, and FHIR is not. See here for REST APIs.

Well unique, except for ISO 13606, and HL7 CDA, which also have the same general structure. But if you want the short description of what that structure does, it provides layers of context + clinical headings. See here for a bit more detail on the context model. And a more general description here. FHIR doesn’t have any of that, it’s a framework for defining models (although they don’t use that word) of data retrieves, not data committal. openEHR achieves data retrieve via AQL, the archetype query language.

I’ll just say one thing: with no distinction between archetypes and templates, you can’t do anything. FHIR sort of uses Implementation Guides (IGs) to do the work of templates. The Archetype Technology document might provide some high-level understanding on the openEHR framework.

Others could probably answer better (e.g. @sebastian.iancu ) but there is nothing special about openEHR w.r.t. JSON - JSON is a weak formalism anyway, but it can be made to do most things with a bit of work. There’s a lot of work going on in JSON-schema for openEHR right now.

It is, especially if you are used to HL7v2 or CDA or … FHIR! But it should be easier anyway. The community is working on a better educational approach (there is a dedicated Education Program Board now) and also on easier to use developer resources. If you stick around on this site a bit, and ask questions (best is to use the specific categories) you’ll usually get very good responses.

Everything in FHIR looks easy because FHIR doesn’t try to do anything challenging. It has rigid Resource definitions for some common clinical data, and then generic Resources like Observation and Questionnaire as well, which are hard work to use for realistic structures. There’s no systematic semantic approach - it’s an ad hoc framework. Every model is its own thing. Then there’s the (now huge) problem of private profiling, creating non-interoperable competing versions of the same thing - just go to simplifier.net and look for e.g. vital signs profiles.

2 Likes
14

For someone with your background, the answer would be: FHIR is an interface specification strongly coupled to REST over HTTP. openEHR is a system specification for what may potentially sit behind the interfaces.

I think we have different views of DDD. FHIR would sit even outside of Application Services, let alone Aggregates in a DDD design if I was the one doing it. As I indicated, it is an interface spec, not a system spec. openEHR is not bound to a specific technology, it is mostly a heavily Object Oriented shared kernel if you want to map these two concepts to DDD. If you disagree, let’s just agree to disagree please because I have no time to discuss angels on pinheads when it comes to DDD.

You’ll have N people and N + M perspectives as a response with a question like that: too subjective. I can see from your questions you’re expecting openEHR as a technology just to “fit” into your comfort zone, which appears to be JSON and REST. That’s OK, nothing wrong with that. Except it would not. In fact, neither does FHIR. You say you have 15 yrs of experience in healthcare, then you won’t find it difficult to agree that healthcare breaks everything when it comes to mainstream tech. Both FHIR and openEHR specification groups and implementers find it challenging to use mainstream data serialisation formats and architectures challenging. You have a more compartmentalised view of a domain in a REST interface, so data representation is a problem with a smaller scope with FHIR, which helps a bit more compared to openEHR, but there are still some issues. openEHR is heavily OO and especially implementation inheritance centric, so that leads to challenges when it comes to representing it with an interface data format such as json.
You should assess openEHR’s design choices in a system design context, not in an interface design context. In order to understand the problem with your question, ask yourself “can you share your perspective on how FHIR’s design choices enhances the functionality and usability of FHIR when you implement a whole hospital information system with FHIR, using it to process every type of data in the system”

You need to start with a requirement. Don’t try to grasp as a whole. Take your requirement, try to implement it with openEHR and ask questions related to that task and approach. You’ll almost certainly get lost and frustrated if you try to learn it otherwise. Certainly possible, but much harder.

I’m assuming you don’t intend to do it but that sounds like trolling. Is there an unopinionated spec out there? FHIR says “you shall do REST”. It is in the name of the thing (R). I’d say that’s on opinion. I’d rather have opinionated design decisions in health specs tbh, because in this space I’d see unopinionated as clueless. Once again: personal view.

A late edit: it is possible to ‘swap’ these two specs for pretty much all the tasks. You “can” implement a HIS with FHIR. You “can” exchange messages with openEHR between systems. It is a matter of choice, which always depends on the context. You can see from my responses above that I’m trying to put your questions into context in my answers. That’s the crux of decision making when it comes to choosing standards: context.

4 Likes
15

From a platform backend developer perspective, openEHR is a quite elaborated and sophisticated thing to build. For developers “using” openEHR, it only takes maybe 90 minutes on a rainy Sunday afternoon to have a “hello world” running.

See GitHub - ehrbase/ehrbase: An open source openEHR server for setting up an openEHR Server.

Try things using a postman collection: https://github.com/ehrbase/documentation/tree/master/examples

4 Likes
16

I was trying to understand this exact question when I first entered the openEHR space.
And here is my question thread: Relationship between FHIR and openEHR - #5 by Sidharth_Ramesh

And a follow up answer after some more research: Relationship between FHIR and openEHR - #19 by Sidharth_Ramesh

And here’s a video delving into this topic further: https://youtu.be/OFC6V9537tg?si=4AqNSUgUhGQYbpvM&t=81 (my latest take)

You can also check out https://www.youtube.com/watch?v=kOU2HGqK23o&pp=ygUPZmhpciB2cyBvcGVuZWhy

1 Like
17

It’s difficult to list differences when the whole specs are designed for different purposes. All HL7 standards are designed for black box data exchange (dinner care about the internal models, just the exchange models), openEHR is white box (cares about internal models and architecture) EHR management, which includes data exchange but it’s not the main focus.

1 Like
18

This sounds little bit like a mantra. Gan you show me “good examples” where fhir is blackbox and openehr is white?

19

I think blood pressure is a good example. What is a blood pressure for openEHR and what is a blood pressure for FHIR?
What is a blood pressure for openEHR is the CKM definition. That’s it. You will always be able to query where is a systolic and where the diastolic are, because shared models are the basis.
For FHIR completely depends on the use case, i.e. the needs of the two points of the communication (which could also be national requirements, but again could be different than any other project).

2 Likes
20

The “blackbox” approach has officially been part of the design paradigm of HL7 (“We don’t care about your system internals as long as you implement the interface”). Grahame has mentioned this multiple times in his talks:

image
image1838×1066 147 KB

In contrast, by design, you cannot build an openEHR system as blackbox

5 Likes