Over a period of several years our customers have been in need of an near realtime integration with data from our openEHR based hospital information system with an ICU system.
There are some architectural guidelines to adopt. HL7 Fhir is on top of the recommendations. The problem is that the use-case is clinical use within highly specialized hospitals. To make data definitions specific enough we use many of the attributes defined in the reviewed archetypes for vital signs. When we look for Fhir profiles they only cover a subset. So what to do?
I know we have some initiatives within openEHR to create FHIR profile more or less automatically (?) from archetypes and templates. Will this work end up as some de-facto standard for maximal dataset definitions within FHIR? I think we would be more than happy to suggest one of these as the base for integration/interoperability in Norway.
Or maybe it is better to leave FHIR as the specification for this kind of interoperability? As mentioned above the need is far more than the regular 80-20 rule we find in the international profile we come across. It could be that this is the right use-case to build interoperability directly on openEHR?
I assume there are others around the world who has been in the same situation. What was your experiences?
Hi @bna I’m trying to understand the problem, is your question mainly about the model mismatches between openEHR and FHIR for vital signs?
Because when I started to read, I thought the problem was more about the near realtime data and it’s architectural approach.
Just out of curiosity, which spec are you referring to as “FHIR architectural guideline”? I would like to read it and check the GAP between that and openEHR (RM/API/ADL/OPTs).
The problem is:
After a few years of investigations and work there seems to be no existing FHIR profile/resources to cover the level of details for vital signs the same way as openEHR archetype does. Even worse, as far as I understand, there seems to be different ways of modelling the same thing for each project in HL7 FHIR.
For openEHR we have been able to agree in a lot of clinical concepts. The openEHR CKM is a fantastic library of precise clinical data definitions. We all know this.
Based on these models openEHR has a good position to develop great FHIR profiles/resources for more advanced use-cases.
My question was: Does anyone have experience with such an approach?
If yes: What experiences were made?
Regarding the guidelines
They are just high-level statements like “SNOMED-CT” should be used as terminology. HL7 FHIR should be used for interoperability. Nothing more.
I guess it depends on the FHIR capabilities of the source systems. I guess easiest for DIPS is to generate FHIR resources using Online openEHR2FHIR transformer
And ask the ICU verdor to work with those
But this works for specific resources only. So if you have other data like medications it will not be considered proper FHIR.
Also if the ICU already support specific FHIR profiles, very likely, they will want you to use those. Since conforming to new FHIR profiles is costly, especially for non openEHR vendors.
For this use case FHIR connect is recommended. For this to work you define mappings between openEHR archetypes/templates and FHIR resources (conforming to profiles). More mapping work for you. But more flexible to map new datapoints from archetypes in FHIR. And you will need a data transformation engine to work on the mappings. E.g. open-FHIR.com.
But I do not think it’s a way to create profiles if they are not there now, so you may need to do this manually. @jake.smolka do you know?
Doing full openEHR integration will be hard for the ICU vendor I guess. You could use generic entries to accept their source data with little validation. Still serious work for them. And then the challenge is mapping and transforming to your vital signs template. You need both a mapping spec and a transformation engine, no one ever build afaik.
Now utopia for openEHR in my view would be the ability to create APIs for specific templates. So e.g. a /vital signs endpoint. Where the model (templates + archetypes + RM) is expressed as OpenAPI. This may theoretically be doable to generate with little manual work. And there are tools for many programming languages to work with models in OpenAPI, which would make it easy (but still laborious) to map the ICU data to the OpenAPI model and post that to the vital signs endpoint. Then you still have to build a transformer from the OpenAPI model to the regular template. But this would be doable.
And this would be very valuable for openEHR front end apps as well, especially template specific ones.
I assume there are others around. Which one is the preferred to be used with openEHR systems? Are there any or do you pick the ones given by customers or projects?
@bna the problem is that there is no preferred model. This is why we spend considerable amount of resources to develop a configurable facade (CDR Bridge) which allows bi-directional communication based on different needs. Even in Germany, there are different FHIR profiles for identical concepts and we need to be flexible to cater for that. In this sense, it is not very different from what we know with HL7 v2.
The other issue we have encountered is how to deal with pre-coordinated terms like ‘sitting blood pressure’.
We approached this in a recent project by creating specific target clones in the template e.g a clone for sitting BP, for invasive BP etc, with the appropriate attributes defaulted in the template.
We then created snippets of json which could be injected into the composition from a lookup table, based on the incoming term.
That could be made a lot more sophisticated and setup as a proper look up service.
As others have said, we are largely at the mercy of how different orgs construct their FHIR extension structures, but we probably can share an approach to mapping the ‘Observation.code’ based on LOINC/SNOMED if those are used.
I would like to find the preferred model for new use-cases. One that could be the preferred from openEHR vendors/systems to be used.
I know there is a history out there and you might not be lucky to enter greenfield areas. A common use-case would be to integrate with an existing system with their profiles and standards. HL7 v2 is still used on the wire. I find no problem with this kind of use-case. We will always make it work somehow.
But given that you owned an openEHR CDR and wanted other applications to integrate with it using FHIR for Vital Signs. Then there could be some preferred model which we use.
I might be dreaming…
And I will wake up implementing some custom FHIR profile for the use-case we currently are working on
Ah, now I understand where you are coming from. This might be a nice idea. Of course it will only contribute to yet another set of FHIR profiles, but at least they would be the same for all openEHR systems. Need to think about it if I like it
Or maybe it is better to leave FHIR as the specification for this kind of interoperability? As mentioned above the need is far more than the regular 80-20 rule we find in the international profile we come across. It could be that this is the right use-case to build interoperability directly on openEHR?
I think specifically for cross institution interoperability, beyond specific projects, + region/nation-wide etc. openEHR excels. I wouldn’t use FHIR for anything thats more specific then 65/35 (its sadly not 80/20 https://www.medrxiv.org/content/10.1101/2022.03.09.22272163v1), we have problems now in Germany with ISIK, MIO, KDS (with 2 different versions) etc. doing it like that. Basing them on archetype would improve that, be be aware that there are other problems like reference dependency hell etc. So in general i would prefer openEHR for that, yet archetypes definitely improve the quality of FHIR models
The intent is honourable but I think the only hope we have of having some influence/alignment is to stay close to, and help influence EHDS work in this area.
There is definitely a place for having a set of ‘playbooks’ of common requirements with templates and FHIR mappings but there can only ever be exemplars as local jurisdiction FHIR/ terminology requirements will always win over anything more coherent internationally.
Given vital signs are used in such a wide variety of clinical contexts (and hence in many different systems, and in a wide variety of healthcare organisations), they are an obvious common need for exchange (integration). Right now I observe that nearly every effort to exchange them end up extending the base HL7 FHIR profiles for vital signs with large (but different) subsets of the extra information elements that are present in the openEHR archetypes, but in slightly different ways. This includes a national initiative in the UK (under NHS Digital), a national initiative in Norway, efforts (of whose scope I am less sure) in Germany, Sweden, and the US (two, I think, one of them by HL7 CIMI).
To my mind that makes them the perfect case to use to trial a practical collaboration between the HL7 and openEHR communities under the new collaboration agreement.
Because if we could make sure the information model expressed in the FHIR profiles and in the openEHR archetypes was virtually identical it would make life a lot easier not only for every integration scenario involving one openEHR-based system, but also for every integration scenario using FHIR: most of them seem to be remodelling what the archetype already contains, in FHIR and on an ad hoc per-project basis.
What might come closest is the AUCDI sparked project. @heather.leslie is heavily involved in that. They create FHIR profiles based on CKM archetypes in a semi automated way. Focus is on core of the core though. So probably lots missing for icu. But it’s a start.
Vital signs and measurements were part of AUCDI release 1. Core for ICU as well !
openEHR archetypes heavily inform the AUCDI, which in turn will provide the clinical context/governance for AU Core FHIR IG development and hopefully simplify the mapping between openEHR, AUCDI and FHIR. Early days yet, the first iteration of AU Core is just completing ballot here, if I remember rightly.
When I was working for the German project HiGHmed what they did was take the FHIR profiles and model them as archetypes and templates. Though for me it should be the other way around, since IMHO the definition of what should be shared shouldn’t determine the requirements for the information that should be managed in the EHR, it should be the definition of the EHR information that guides the exchange models (thinking of openEHR as the data management model and FHIR as the exchange model).
I also know that 80% of the time we don’t use all the information defined in openEHR archetypes, and, if we focus on the information that is used most of the time, there is a good percentage that would be already in a FHIR profile, and for the GAP between models there could be extensions to FHIR that can be added to a profile.
For something at a regional or national level that could be designed from scratch (not adopting something done by other countries but creating their own standard), I think the right approach is to define which archetypes to use and then define the FHIR profiles and extensions based on the archetypes.
(though I’m still intrigued about the real time openEHR data )
)