Stream: openehr
Topic: FHIR and openEHR
Peter Jordan (Apr 04 2019 at 22:42):
Any views on this paper published by INTEROPen in the UK...
https://www.interopen.org/2019/03/23/digital-health-rewired-panel-paper-fhir-and-openehr/
Grahame Grieve (Apr 04 2019 at 22:51):
@Ian McNicoll @Amir Mehrkar
Grahame Grieve (Apr 04 2019 at 22:52):
I reviewed and made comments and they did alter it based on my comments, but I was still not entirely happy with it. i still think it takes too rosy a view of the usefulness of a common definitional framework across systems. (or the likelihood it will be widely adopted)
René Spronk (Apr 05 2019 at 06:11):
I've read it / "scanned it" and it seems to be a good attempt to 'play nice' and show the differences and opportunities for cooperation. IMHO te OpenEHR approach is like the concept of "world peace", very desirable (and thus worth our while to look at), but yet also very elusive to achieve. In that sense FHIR takes a more pessimistic/realistic view (peace is a goal, but facts on the ground require certain approaches), reflective of the current state of shared data usage.
Diego Bosca (Apr 18 2019 at 10:36):
FYI openEHR acknowledges that nothing is perfect, that's why templating (constraining) for local usage is such a key part of openEHR
Florian Briand (Nov 20 2019 at 21:27):
Is anyone having more precise thoughts about this paper and the "relation" between OpenEHR and FHIR ?
For me, how I understand the subject, despite of what this paper try to say is : "OpenEHR is useful as a data model, using FHIR for data exchange" ; but if I look into using FHIR as a datamodel, which I think we should do, OpenEHR become absolutely useless from an architecture point of view
The only point for which I find OpenEHR really useful is the governance and publication methodology, involving a lot the practitioners and allowing "templates" (profiles) to "bubble up" easily to the "archetypes" (resource def) level, allowing things like "blood pressure" to be available as an archetype ; instead of FHIR having hundreds of profiles for it ^^
Kevin Mayfield (Nov 21 2019 at 08:59):
I beginning to think the actual issue is more like 'relationship between modelers and developers'.
The push back against profiles (e.g. profile explosion) and archetypes is very similar,many issues are common.
The developer is not seeing how to turn the model into a technical solution, the model ISN'T the technical solution. My version of the play nice is: FHIR is the technical solution and the model can be done via openEHR or some FHIR resource (but not profiles).
My current thinking: is FHIR GraphDefinition the glue between the model and technical solution? Can a GraphDefinition represent an openEHR archetype?
Kevin Mayfield (Nov 21 2019 at 11:12):
I've done some exploring.
Starting with NEWS Archetype (https://ckm.openehr.org/ckm/archetypes/1013.1.3342) and UK NEWS2 Spec+Profiles (https://nhsconnect.github.io/FHIR-NEWS2/index.html).
I've built a GraphDefinition https://project-wildfyre.github.io/conformance/graph/5
This seems to show:
Kevin Mayfield (Nov 21 2019 at 11:18):
- You can convert a Archetype into a GraphDefinition
- It shows what should be in the Bundle for a developer (the FHIR spec and profiles don't show this)
- I think it would be possible to use GraphDefinition to define what resources are needed to convert from FHIR to openEHR.
-
Archetype != FHIR Profile.
-
Potential of removal of profiles, the graph can show the narrative and it may be better to describe what Observation is needed via a query and/or ObservationDefinition.
Florian Briand (Nov 21 2019 at 11:35):
I'm not sure to understand what's the "push back against profiles" and so, why you are considering GraphDefinition instead of just using profiling to cover what OpenEHR is doing ; especially since we have slicing
Florian Briand (Nov 21 2019 at 11:49):
Is it what @Diego Bosca is talking about a bit earlier ?
Diego Bosca (Nov 21 2019 at 12:21):
Is anyone having more precise thoughts about this paper and the "relation" between OpenEHR and FHIR ?
For me, how I understand the subject, despite of what this paper try to say is : "OpenEHR is useful as a data model, using FHIR for data exchange" ; but if I look into using FHIR as a datamodel, which I think we should do, OpenEHR become absolutely useless from an architecture point of view
The only point for which I find OpenEHR really useful is the governance and publication methodology, involving a lot the practitioners and allowing "templates" (profiles) to "bubble up" easily to the "archetypes" (resource def) level, allowing things like "blood pressure" to be available as an archetype ; instead of FHIR having hundreds of profiles for it ^^
maybe this is useful as a summary https://medium.com/@alastairallen/fhir-openehr-bef21694f76b
You can surely use FHIR as a datamodel, but it can be dangerous, specially while some resources are not mature enough. See above link for examples. Being always compliant with a underlying Reference Model is what eases systems evolution. Data compliant with archetype A can coexist with data compliant with archetype A' (or B) without having to change anything about persistence. Templates for local (with further constraint use) are compliant with parent archetypes, so querying/validation can be safely done over the parent archetype. Technically templates are just specialized archetypes. On another thing, I also think that the more FHIR provides "curated" profiles to ease reuse, the less profile "explosion" will be, as there seems to be a lot of "not invented here" syndrome.
About slicing: IMHO is far more complicated than defining the same as an archetype constraint. I'm pretty sure main issue with profiling is to want the definition "format" itself be a (flat) Resource, which is a cool geeky thing to do but makes simple constraints to become too verbose.
BTW, I've generated archetypes based on FHIR RM. No type hierarchy makes the underlying reference model overcomplicated, but it can be done.
Kevin Mayfield (Nov 21 2019 at 12:39):
I'm not sure to understand what's the "push back against profiles" and so, why you are considering GraphDefinition instead of just using profiling to cover what OpenEHR is doing ; especially since we have slicing
In the UK we are getting push back. The links above all describe the same problem but I feel the openEHR description is a lot easier to understand.
The FHIR spec uses profiles, here is where the push back starts. For example the heart rate profile says use SNOMED Concept 364075005 and units /min, I knew what to look for, but many developers will take longer. I've described how this profile differs from UK core in a sentence - this is where push back starts, the profile is obscuring the requirement.
As @Diego Bosca mentions FHIR doesn't have hierarchy like openEHR, using GraphDefinition shows how resources reference together and as the image shows this is like a heirarchy.
Kevin Mayfield (Nov 21 2019 at 12:41):
Screenshot-2019-11-21-at-12.39.07.png
The GraphDefinition is defining a Bundle response that is compatible with an Archetype.
Kevin Mayfield (Nov 21 2019 at 12:46):
@Ian McNicoll what do you think, I think I'm seeing a sweet spot?
Thomas Beale (Nov 21 2019 at 12:47):
For me, how I understand the subject, despite of what this paper try to say is : "OpenEHR is useful as a data model, using FHIR for data exchange" ; but if I look into using FHIR as a datamodel, which I think we should do, OpenEHR become absolutely useless from an architecture point of view
You might want to consider some real basics and common misunderstandings about architecture: the role of FHIR and openEHR: https://wolandscat.net/2019/05/24/fhir-versus-the-ehr/
Then you might want to consider some of the issues with FHIR semantic design: https://wolandscat.net/2019/05/05/a-fhir-experience-consistently-inconsistent/ and following posts.
An openEHR primer for FHIR people might also help here: https://wolandscat.net/2016/04/10/openehr-technical-basics-for-hl7-and-fhir-users/
Thomas Beale (Nov 21 2019 at 12:55):
The real ultimate problem with each new message standard, FHIR included, is that they continue to try to encode clinical semantics right into the technical message (=Resource) definitions, rather than being driven off a common base of models that recognises HIT entities like 'clinical statement' and so on. This will just always create endless unnecessary data transformation, carrying clinical risk. If you don't believe this, just consider a very basic concrete fact: with each HL7 standard, from HL7v2, CDA, HL7v3 and FHIR, the models of clinical entities are rebuilt from scratch each time, directly in the formalism of the messages. There's no longitudinal re-use of blood pressure, microbiology result, or any of the O(10,000) other clinical models. Many of us had hoped that CIMI + openEHR would help solve this problem in HL7, but it was not to be. It does appear that we will be looking at dozens of competing profiles for every one of those models now.
Grahame Grieve (Nov 21 2019 at 12:57):
As if delegating to a common reference model would actually solve that. It's not a social problem, not a technical problem
Thomas Beale (Nov 21 2019 at 13:11):
As if delegating to a common reference model would actually solve that. It's not a social problem, not a technical problem
Did you mean to say 'it is a social problem'? Anyway, it is both. There really is no argument for having more than one shared definition of the data groups/points of 'systemic arterial BP', nor nearly all other clinical data. There are a few exceptions, e.g. microbiology result, for which there are various kinds of representation. But the vast majority are non-controversial.
René Spronk (Nov 22 2019 at 07:24):
@Kevin Mayfield I think it would be useful for a FHIR instance graph to claim conformance to the 'business model/DCM/Archetype/ZIB/HCIM' (or whatever you want to call it) instead of (just) the FHIR version thereof. Somehow there's an automagic mapping from that business model to a graph of resource instances, but ultimately it's not about the instance graph, but about the business model. If there's a computable automagic mapping somwhere then the basis for validation could be the business model. The technical artefact used by a validation engine would be a StrucDec and/or a GraphDef.
Kevin Mayfield (Nov 22 2019 at 07:56):
@René Spronk https://chat.fhir.org/#narrow/stream/179177-conformance/topic/Push-back.20against.20Profiles
Not disagreeing, I realise now I'm after something like a 'ModelDefinition' which can be used to build a graph.
Diego Bosca (Nov 22 2019 at 08:39):
@Kevin Mayfield do you generate graphdefinitions automatically from the archetypes? if not, it would be something useful to have or it's just a one time thing?
Also, are 'colors' from the graph nodes predefined somewhere and specific to each Resource? :joy:
Kevin Mayfield (Nov 22 2019 at 09:22):
I'm researching at the moment, looking at ways of representing models in FHIR and linking them to resources. One idea is that models are collections of FHIR Resources. The models being datasets, openEHR, HL7v3, etc.
Thomas Beale (Nov 22 2019 at 10:37):
I'm researching at the moment, looking at ways of representing models in FHIR and linking them to resources. One idea is that models are collections of FHIR Resources. The models being datasets, openEHR, HL7v3, etc.
One way to do that is to represent the FHIR Resources as a BMM (the meta-model format we use in openEHR, that drives the archetype tools; also used by CIMI) and build archetypes - which will then be 'native FHIR archetypes'. I started down this path and created the FHIR DSTU4 BMM, but gave up going further because the inconsistency, lack of re-use and no abstract typing prevents the Resources from being useful from a 'modelling' point of view. Anyway, you can see these files here: https://github.com/openEHR/reference-models/tree/master/models/FHIR/DSTU/BMM ; they will work with ADL workbench and also I think LinkEHR. There is a second BMM there, that contains proposed changes for adding some abstract types to the Admin Resources and a few others.
Kevin Mayfield (Nov 22 2019 at 11:45):
My suspicion is the map needs to be done by hand. The model will tend to be idealistic and need will need amending so it's implementable. <<< This is not a dig at openEHR or other models.
Technical implementation will have other constraints most importantly requirements of different types of carers, patients and clinicals who are invariably going to want to use/see the data (and model) in different ways.
Thomas Beale (Nov 24 2019 at 15:58):
@Kevin Mayfield can you elaborate a bit? Do you mean something like mapping from e.g. openEHR or other DCM for e.g. Allergic Reaction, Diagnosis etc to some FHIR structure? That is needed to implement the model in a FHIR environment, but I am sure you know all those archetypes are directly implemented around the world for years in real systems, no 'mapping' needed (other than for legacy system integration). I don't see any such models as 'idealistic' - they are just what clinical professionals decide, so I'd say they are extremely pragmatic.
Maybe you meant something else?
Kevin Mayfield (Nov 24 2019 at 16:06):
Not related to FHIR, it's what users ask to be displayed on their screens. It's not the same as what they ask to be in the model.
Users are different types of clinical, carers or patients.
Kevin Mayfield (Nov 24 2019 at 16:08):
E.g. NEWS2 works for some but others will want heart rates in a chart.
Thomas Beale (Nov 24 2019 at 16:08):
Aha - so we are talking about the UI/UX view. Agree there; that's a whole different question. It doesn't obviate the need for proper models, but it does impose other requirements. However, ultimately, what is seen in the UI can't violate the information models; if it does, someone is wrong / not up to date.
Thomas Beale (Nov 24 2019 at 16:09):
Yes, good example - that's why we build so much flex into archetypes - giving the ability to add locally-specific elements to a model via specialisation (just like in OO programming), with the resulting data still be an instance of the more general model.
Kevin Mayfield (Nov 25 2019 at 07:01):
It highly influences FHIR, I know fhir can do other things but to me this is its core focus.
Yes I agree it shouldn't violate the model but it's going to lean towards a model being populated in a piecemeal fashion.
Last updated: Apr 12 2022 at 19:14 UTC
