Relationship between FHIR and openEHR

I am new to openEHR ( and Health informatics in general ) space but find myself stuck with this question.

How do HL7 FHIR and openEHR relate ? I understand that HL7 v2 etc is basic messaging for interoperability. But FHIR seems to add some Clinical Data Modeling to this in the form of resources - A Visit with a Patient with an Observation is to my mind a Clinical Model no ? And when you add in a FHIR server concept are we not verging on the CDR ?

So then openEHR models the same Clinical concept through Archetypes, aggregated within a Template. - fantastic ( this I think I get and see where it fits in openEHR )

Next - where is the cross over in interoperability?

Is openEHR designed to - provide Archetypes as direct map to the model on the screen? My understanding is yes.( Datasource and UI interoperbility if you will )… i.e. (In its simplest form) - Client calls Server - Server runs AQL on the data and returns XML result, client runs XSL over that to generate HTML -

But isnt FHIR more about interoperability and openEHR about data modelling? - so now are we suggesting an openEHR server serves the result as an openEHR standard - and we try Map it to FHIR resources and serve it to the front end or any interoperable system.

Should we be looking at picking one and forgetting the other ?

There is a lot in this - but as I said I am very confused.

Thanks.

5 Likes

Yep, openEHR and FHIR can cooperate, see this blog post about it by Alastair Allen. I would also encourage you to read the excellent Thomas’ post about it

BTW, openEHR also defines a REST API and simplified formats that provide easy interoperability with little effort (as every known provider implements it)

2 Likes

You might also find this INTEROPen document helpful - it gives more a of a high-end view of the relationship.

https://ripple.foundation/2019/03/interopen-paper-on-fhir-openehr/

I wouldn’t say that openEHR is intended to map data to the screen as such, more that it is designed to create and persist the data as it is acquired (perhaps via UI) , which tends to be considerably more complex than models of data for exchange.

And the answer is not that we should be picking one and forgetting the other. Both will be required for some time - FHIR to move data between disparate systems and proprietary data models, and openEHR to model, persist and query the data in tightly integrated platforms which share the same information model. I expect the latter to grow and the former to shrink.

4 Likes

Here is a resource that may be useful to help orient people coming from FHIR… in a fun way…

pancakes_n_openEHR

1 Like

I read your blog post on using an openEHR partition on FHIR to represent the openEHR RM. Has anyone worked on this? Getting FHIR resources that are based on openEHR clinical archetypes and templates would be a godsend. Big companies like Google and Microsoft offer FHIR as a fully managed service and using their respective data analytics platform to execute AQL on FHIR would be an extremely cheap and scalable way to deploy a CDR.

3 Likes

Well firstly, it has proved nearly impossible to get HL7 to be involved in anything like that, so it is something we would have to do in our community. FHIR as a target is not easy - like HL7 CDA and HL7v3, it is an ad hoc design. There are some well-known resources (e.g. to do with medication) that map not too badly, but many others that don’t, and there is no coverage at all of a vast amount of the clinical data space.

It is worth keeping one key thing in mind: the design of FHIR is for data retrieval, not data commit. It is thus factored to obtain one or a few data items on an ad hoc query basis, not to specify full data sets as you would for committing. That’s why the Observation resource, for example has one logical ‘value’ in it in FHIR, while for models designed for persisting data, it allows for much more complexity. This is a perfectly correct design aim by the way, I’m just pointing out that it arrives at significantly different results than a commit / persistence design.

Another complicating factor is the lack of inheritance. This is particularly acute with the Admin resources, and indeed companies like Mitre have created a whole new layer on top of FHIR to compensate for this (standardhealthrecord.org).

Practically what this means is that there is no straight path to providing a high-fidelity FHIR layer over the top of data created the 11,000 or so clinical data points in the 600 archetypes in CKM, at least not without a) new resources and b) refactoring to correct the model issues in FHIR (many examples documented here).

This does not mean that specific data-sets for FHIR-based apps cannot be extracted from openEHR systems, in fact it’s not hard, using AQL and the rich data underneath. It’s just that every such application is a new piece of manual development work. Right now, I don’t see any machine-based way to simply generate FHIR profiles from archetypes, unless they are all profiles of some generic structure like FHIR Questionnaire. But that would just be supplying data trees, using FHIR data types and a few other bits of meta-data - they don’t really help do any semantic computing.

Anyway, @yampeku may have other things to say on this topic, as they have done a lot of work at UPV / Veratech.

3 Likes

Not much more to add. I think there are some possibilities worth exploring regarding the (semi)automatic translation of Composition-based templates into FHIR composition profiles (in a similar way of what it’s done with CDA->FHIR).
Having some kind of explicit correspondences between archetypes/templates and profiles would also allow the automatic AQL generation (what data you need to populate what profiles). Seems something that could be interesting to explore.

This is a bit old but likely still useful regarding relations openEHR-FHIR:

https://drive.google.com/file/d/0BwdHmPbK5e3SN3pQX0RzRV8xRHM/view

3 Likes

This is rather good!

1 Like

The openEHR Board has been working on a short White Paper on the relationship between openEHR and FHIR, which we see as very large complementary.

The paper is now published via openehr.org, reproduced in the text below and attached as PDF.

There is fair bit of interest in this area as a result of some Twitter posts in the aftermath of the UK Rewired healthIT conference when ‘Separate the data from the apps’ was announced as a strategic direction for England, in line with existing policy for NHS Scotland and NHS Wales.

It would be good if we can point people here for a more in-depth discussion than is possible in 250 chars!!

openEHR and FHIR

The openEHR community is often asked about the relationship between openEHR and HL7 FHIR, often around, ‘Should we choose openEHR or FHIR’.

Like any community, there are a range of views inside openEHR but from both industry and clinical perspectives, the following opinions emerged…

So …‘should we choose openEHR or FHIR?’

In fact, we believe that the question(s) should really be…

where should we use FHIR

and,

where should we use openEHR,

We regard openEHR and FHIR as complementary approaches to ensuring the maximum sharing of patient information between digital health applications.

FHIR has had a significant positive global impact in helping existing systems exchange high-value clinical information, in a modern developer-friendly way along with other helpful innovations such as vendor-neutral terminology service interfaces.

The openEHR development community is actively adopting FHIR standards, over openEHR-based datastores and tooling, in line with other more traditionally engineered systems, using FHIR ‘as intended’, to support information exchange between applications…

In contrast, openEHR supports a world where applications increasingly coalesce around communal, vendor-neutral structured clinical data repositories (CDRs).

The ‘controller’ of the CDR (not the vendor) can upload new openEHR clinical model definitions without further engineering or recourse to the vendor and patient records can then immediately be created and fully-queried using those new definitions -

essentially a ‘no-code’ vendor-neutral data management environment.

The ‘clinical model’ archetype and template definitions e.g. for Allergy or Pulse oximetry, are created by care professionals using dedicated tooling, and shared under open-source licenses. Several hundred such resources are curated by openEHR, all free to use, and in use by many systems around the world.

openEHR, differently to FHIR, is purpose-designed and proven to support this new breed of enterprise-grade, vendor-neutral structured data repository, where new content can be developed and implemented in an evolutionary way by care professionals themselves, at the level of detail required to support applications fully, not just for more limited data exchange.

There are a number of areas where FHIR and openEHR data models overlap, but we see steady convergence, whether by pro-active joint development or natural alignment.

We believe that together openEHR and FHIR will expedite the convergence of standards which will reduce the friction and improve safety and efficiency for health and care systems.

openEHR and FHIR, not openEHR or FHIR!!

openEHR AND FHIR.pdf (64.5 KB)

5 Likes

I have been exploring this a little more. And I figured that there should be an easy way forward for people trying to build an “app ecosystem” for healthcare. In fact, I’m working on bundling open-source projects like EHRBase, HAPI, Keycloak, Hermes, medblocks-ui and ORY to implement a base layer of microservices on top of which unified, interoperable healthcare apps can be built upon. It’s definitely FHIR and openEHR.

:warning: Long post ahead :warning:

Here is how I think everything might fit together:

1. Clinical Content

Data capture:

OpenEHR is excellent for clinical data capture. There are hundreds of archetypes to choose from and putting them together is easy. Automated generation of forms from these templates is also easy.

FHIR on the other hand has the Questionnaire resource for data capture and along with the Structured Data Capture IG. A QuestionnaireResponse, however, cannot be directly mapped to FHIR resources, since they don’t have a 2 level modelling layer. They are trying to fix this in FHIR R5 with Modular Forms, by extracting out reusable chunks into modules - they’re basically reinventing archetypes and the multi-level modelling approach. Even after that, querying data from resources with value[x] polymorphism is not easy.

openEHR has a huge advantage because of the mature RM and all the archetypes that took years of modelling work. There is also a CKM with tooling for open collaborative modelling. FHIR does not have this.

Querying

Unified querying across CDRs is possible using AQL and it meets the need for building any complex view in an EHR. Although queries as complex can’t be executed on a FHIR server, it is much easier to get started with. As a result, developers will be more familiar with querying a server using the FHIR search API as compared to using AQL for which they need to learn more about openEHR archetypes and templates.

Almost everything in FHIR is represented as a resource and there is not much nesting involved. So figuring out the context of an Observation for example might be hard.

So FHIR querying is good for: Displaying a graph of blood pressure or pulse readings in a graph on a patient-facing app. Any data with a simple, non-hierarchical structure.

AQL is good for: Rendering a print-out for a patient discharge summary with sections like History of Presenting Illness and Examination compiled across multiple departments. Note that doing the above with AQL is also trivial.

2. Demographics, Terminology and Business Logic

openEHR limits itself to doing one thing, and does it well. FHIR is extremely versatile and can handle most of the business logic of a hospital. This includes demographics, billing, employee management, insurance claims and appointments. Most of these data models are not as complicated as clinical data, and FHIR does a decent job here. Resources can be extended and contained using profiles to model the business requirements of the hospital.

Most terminology servers also provide a FHIR interface, and multiple CodeSystems like SNOMED, LOINC, ICDx, RxNorm can be deployed as separate services, using the same FHIR interface.

So openEHR for clinical data and a FHIR server for everything business-related, including demographics and terminology.

3. Mapping openEHR ↔ FHIR

FHIR Facade

Represent all clinical data in an openEHR CDR and create a FHIR API that will map between these compositions and convert them into FHIR resources. Similarly, FHIR resources posted, should be converted to an openEHR composition and persisted. There is only one source of truth for clinical data and that’s the openEHR CDR. This is how EHRBase FHIR Bridge does it (although the FHIR resources might be persisted in the logs).

Synchronised Servers

Run and configure an openEHR CDR and a FHIR service separately. Have a subscription mechanism running on both services, that trigger when a change is made.

openEHR → FHIR: Whenever compositions of importance are posted or changed, it executes an AQL that is used to generate a set of FHIR resources. The ids of the FHIR resources can be generated based on deterministic hashes from the compositions so that the FHIR version can be updated properly when the composition updates. Most of the time, the FHIR resources will have less information than the openEHR composition.

FHIR → openEHR: Ideally, the FHIR server should be used to write only the business and demographic data, and clinical data reflected from openEHR must be read-only. However, there might be times when a patient-facing app and other apps (using SMART on FHIR) want to write clinical content of importance to the FHIR server. For these resources, openEHR templates needs to be made in advance and can be committed to the openEHR CDR using a similar hash-based uuid generated from the FHIR resource so that the composition can be updated when the FHIR resource changes. If some FHIR resources are deemed not important enough to show the physician, but an app still wants to write and read to the FHIR server, templates are just not created and no mapping is done. The data still lives in the FHIR server.

4. Unified Platform

The apps deployed on the platform must be able to securely and uniformly log in and access the resources they need for the “app ecosystem” to take off.

Authentication: Oauth2

When developing an array of apps that will be used for different purposes, they all need to have a Single-Sign-On (SSO) mechanism. SMART on FHIR seems to be the most well developed in this regard, and there are 100s of apps already built on this. However, some of the specifications in SMART on FHIR like launch_context do not follow the Oauth2 protocol properly. This requires that SMART on FHIR be implemented by extending an Oauth2 implementation like Keycloak/Ory Hydra or implement it from scratch. This unconventional use of Oauth2 also means that client apps need to use the smart-on-fhir client libraries to make these flows.

Sticking to just Oauth2, without any deviation might be better in the long run since it can be used to directly solve most of the requirements for healthcare applications. Solutions like ORY Hydra or Keycloak can be used to implement the Oauth2 flow directly on top of an openEHR and FHIR stack, with Bearer tokens provided that contains the scope and the identity of the user. The scope can be used to represent most things in the SMART-on-FHIR non-standard parameters. The same token can be used by other microservices like terminology etc too.

For apps that depend on SMART-on-FHIR, migrating to just Oauth2 will be easy and will in fact mean removing code from their app. There are client libraries for Oauth2 in almost every language.

Authorization: Centralized Policy Enforcement

Fine-grained access control is essential to healthcare applications.

Both the FHIR and the openEHR server have to figure out “Can this user do this action on this resource?”
Although on the surface it seems simple, this is very tricky in some cases. A lot of things need to be taken into consideration and the requirements keep changing. Therefore, the question: “Can this user do this action on this resource?” should NOT be answered by either the openEHR or FHIR server. It should be deligated to a Policy Enforcement endpoint.

Projects like ORY Oathkeeper and ORY Keto when used together can provide extremely scalable and configurable authorization options. Keycloak’s Authorization Service also provides very good coverage with a lot of nice to have features.
Both the FHIR serve and openEHR server must implement an API for the following:

  • Policy Enforcer Endpoint: When a user X tries to do an action Y on a resource Z, make an API call to a policy enforcement endpoint with the details of X, Y and Z. The user can be allowed or denied permission based on the response from the endpoint.
  • Protection API/Relationship Tuple Write endpoint: An API call to write new policy/permission tuples (X can do Y on Z) after creation or modification of new resources. For eg: After every composition, the openEHR server must make an API call to this endpoint stating that the practitioner who created the composition has permissions to read, modify and delete on the composition. This can easily be configured in a HAPI FHIR server using the Authorization Hook. Still doubtful if EHRBase can be extended in any way to get this functionality. @birger.haarbrandt

Sometimes, the authorization process can be done at the level of the reverse proxy server/Ingress controller directly by using the URL and the HTTP verb along with other information. However, at other times, it’s really complex. Consider executing an AQL on compositions that the user does not have permission to for example, or a Conditional update on a FHIR server. These are complex operations and need integration at the level of the application to provide uniform authorization.

The advantage of this approach is that the administrative work of policy enforcement can be managed using a simple GUI in one place and applications and users can be given the permissions that they need. Sharing resources among users is also possible using Keycloak’s UMA-compliant endpoint. More advanced authorization mechanisms like Zero Trust / BeyondCorp can also be implemented easily.

13 Likes

Thank you @Sidharth_Ramesh! This is extremely helpful.

If FHIR is better at day-to-day hospital operations, do you know how OpenEHR-based organizations like Karolinska University Hospital handle business logic such as demographics and terminology?

Have they solved this problem of FHIR and OpenEHR integration?

Would love to see examples of the HL7 FHIR and OpenEHR solution you propose :slight_smile: or if there are updates to the whitepaper or inter- and intra-operability presentation Erik gave.

FHIR is a retrieval mechanism for apps to get data from EMR, PAS and other systems. openEHR is an architecture for creating data in the first place, and also getting it back. To implement a hospital EMR, FHIR isn’t going to help, other than if you want to put a FHIR extract layer over the top of openEHR to feed FHIR-flavoured applications. This is almost always a downgrade in information quality, but might be acceptable in some circumstances (e.g. pulling single blood glucose or similar).

3 Likes

There’s been a great presentation by dr. @patrikgh about the Karolinska approach recorded at the highmed symposium. Events HiGHmed Symposium 2021
Especially slide 9 is helpful https://f.hubspotusercontent30.net/hubfs/19954885/HiGHmed_Symposium_2021_slides_Patrik_Georgii-Hemming-1.pdf

And there’s a paper published IOS Press Ebooks - Configuration of Input Forms in EHR Systems Using Spreadsheets, openEHR Archetypes and Templates

3 Likes

Hi @jaan!

I work as an information architect at Karolinska Univerity Hospital. We’ll be using both FHIR and openEHR depending on parts of use cases etc.

Right not we are for example developing an import pipeline for live legacy EDI/Edifact messages with (clinical chemistry) lab data updates that will go into openEHR Lab result reports in our openEHR CDR. Adding FHIR to the mix for the core lab content conversion process would only confuse things even more and add unneccesary mapping and conversion steps. On the other hand we’ll likely use a FHIR facade to our current demographics & organisation registry services and call those as a part of the conversion flow where we enrich the EDI data. A terminology server with a FHIR terminology API will likely also be used in that enrichment process.

Also we will likely later provide a FHIR facade for reading clinical chemistry lab values from our openEHR-based CDR e.g. when integrating with a new Philips product that has started using FHIR.

On the other hand, when making our own patient overview apps/screens we plan to use openEHR directly to access rich data (including clinical chemistry) this reduces unneccesary work (and openEHR’s AQL is very handy).

Regarding UI-forms for EHR data we’ll mainly be using openEHR-based tools all the way.

If openEHR would have had REST APIs for it’s demographic/registry models already now, then we could have considered that too, but that is not yet specified and not supported by our current openEHR CDR partner. (But a FHIR facade would likely be interesting to add anyway then for providing data to systems with FHIR support.)

7 Likes

Thanks Erik,

That is a very clear explanation, and pretty well the same ‘sweet-spot’ of use of the two technologies that most of my clients/partners have arrived at.

2 Likes

Hi Ian, Any good clinical domain examples where FIHR and opeEHR models overlap or clinical examples rich enough to try and exhibit the mapping between the two.

Hi Archana - Some examples of overlap and mappings here GitHub - Code4Health-Platform/openehr-care-connect-adaptor

Also check out Rath Panyowat on LinkedIn: My team and I are designing an information model for the medication order… | 24 comments
By @rathpanyowat

Thanks for that … I’ve just responded to @rathpanyowat identified ‘gaps’ on LinkedIn.