Hi All,
You may have seen my piece on Digital Health Intelligence It’s generated quite a few comments. Including one from Richard Kavanagh which describes openEHR as futile. I will respond in due course, but would be good if others from our community added their thoughts.
Ewan
Great article. Congrats.
Ed Hammond & I co-presented on clinical modelling at the Feb HL7 ‘Clinicians on FHIR’ meeting in Sydney. One of his best one liners: “If you’re solving today’s problems, you’re out of date!” is food for thought.
The first thought I have on the subject is : “If you’re opposing FHIR and OpenEHR, you’re out of date!” 
It’s two different approach, which are complementary.
Move an existing system to OpenEHR is not “easy”, as the “magic universal healthcare model” doesn’t exists in practice. So an existing system have to spend a lot of time modelizing how they will put their current model into the OpenEHR one.
So for existing ones, FHIR is “lightweight” : you don’t change your system, you just deploy a facade. And if you need 5 different representation of your model, you deploy 5 different profiles. And maybe 2 or 3 facades.
But if you are able to “take back” your closed & private vendor’s models to convert them to OpenEHR, let’s do it. But anyway, you will have to maintain interoperability with other systems, all the ones with FHIR facades. (FHIR Interoperability VS OpenEHR Intraoperability)
I don’t know if this subject move a lot these last months, but I think OpenEHR community & companies should work on that : build good “true” FHIR facade for OpenEHR. (I mean by “true” taht we need a real full mapping, not just CDA encapsulation, with OpenEHR bundles injected as documents …)
Generally agree @florianbriand but for one point; “true FHIR facade” depends not just on an openEHR representation but also the FHIR is ised effectivly by the interop community. I don’t think it is, and I hear a lot of “FHIR-like”. We could take the moral high ground and say, within the openEHr community we are going to do this “right”. But unfortunatly I don’t think that would neessarily make things easier when the light weight nature of FHIR is its major selling point.
Unfortuntly Richard’s comment speaks of the tail wagging the dog. Not in the suppliers interests, ongoing threat to business model yadda yadda. There is a responsibility on institutions at a high level to state that this is not “nice to have” but a hard requirement for procurement and development.
Hi Florian,
Completely agree. There are some openly available openEHR-FHIR mappings and the community is building some more.
Ian
I think that this quote (originally from @erik.sundvall?) has been quite misunderstood, to the point that I don’t think it’s useful anymore: openEHR ‘intraoperability’ contains the ‘interoperability’ part, which probably isn’t obvious at first glance of the ‘VS’.
In other words, you can do interoperability with openEHR.
We actually do not want interoperability!!
I am starting to say that openEHR is all about trying to avoid the need for ‘interoperability’ at all.
Interoperability is a sticking- plaster to a problem which need not be there in the first place, it is not an end-goal in itself.
We cannot ‘bake-in’ interoperability, what we need is to gradually bake-out the need for interoperabillity. This will take time and face oppositon but no reason not to make a start
One thing is that we despise and want to get rid of the term and another saying that you cannot achieve that with openEHR, which I think it’s the message being transmitted
Just the latest in concrete, technical problems with FHIR: https://wolandscat.net/2020/03/09/fhir-fixes-the-choice-construct-part-i/
I have mail from senior experts in ontology, modelling, CDS, and … FHIR … agreeing with this, and the other stuff I have posted. I can’t repost their private responses here unfortunately, but there is a growing consensus that FHIR won’t work for CDS (at all), won’t be scalable in terms of models, will cause all kinds of problems in software (due to things like choice), and may make interoperability worse, due to a proliferation of local / private models of common things like vital signs.
FHIR doesn’t even represent a systolic BP if collected on its own versus collected with diastolic, pat position etc, in the same way (the first is Observation.value, the second it Observation.component.xyz).
There really are so many basic problems that are not being addressed in the headlong rush for going normative, that it’s hard to see how it’s going to work.
It’s a pity, because a modicum of change to process and methodology now could save it.
haha good quote, I’m stealing that one…
sorry if I repeat myself, but I think we should stick to the mantra that ‘interoperability is an emergent property (i.e. output variable) of a coherently engineered open platform, not something you can impose with random pipes (i.e. input variables) connecting existing systems’.
Ian’s baked-in / baked-out metaphor captures this even more succinctly.
ha ha @thomas.beale … @ian.mcnicoll does have some flour-ey language. Let’s hope the analogy proves over time.
Sure, but lets not throw stones over our own roof by dismissing how everyone else understands the term. I understand what you mean, but someone (i.e. decision makers) who come across this kind of quote would say: “I don’t want intraoperability, I demand interoperability!” without going deeper into the implications of each word meaning.
LS,
OpenEHR/En13606 can be used both for: an interoperability solution between proprietary systems, and for a true interpretability solution.
OpenEHR is designed to define meta-information that can represent ALL possible health data used in a system.
Systems that conform to inside to a standard such as OpenEHR/EN13606 do not have a serious interoperability problem.
Systems that are proprietary inside can conform to any exchange standard such as: Edifact, HL7v2, HL7v3 (CDA) and FHIR or one Template based on OpenEHR/EN13606.
And since there are many varieties of dialects in these message standards, interoperability is a serious message deployment problem.
Gerard Freriks
+31 620 34 70 88
+31 182 22 59 46
gfrer@luna.nl
Kattensingel 20
2801 CA Gouda
the Netherlands
In case you missed it , though most of those on this thread are already aware… we have come up with a simple yet pragmatic approach to addressing the challenge of working with both FHIR and openEHR in our open source Ripple stack, thanks to the work of @rtweed QewdJS and his JSON transformation work.
I won’t get into the merits of openEHR v FHIR etc etc as dont have the time for that discussion today/imho its not worth having as the reality for now is there is merit in being able to work with both…
Can highly recommend this brief but instructive 7 minute video from 2017 on how its done
Also to bring things up to date, ICYMI link to slides from Robs recent related presentation at Rewired last week.
If someone finds a better way of working with openEHR & FHIR I’d like to see it…
All open sourced as the idea is to encourage collaboration in this space… the barrier to entry being a knowledge of JSON… ie about as low as it can be …
Hope this helps the discussion
Tony
Sorry - not sorry -, but as startuper, I don’t care about “intra-operability”. I don’t care about the X% of systems having moved to OpenEHR.
I only care about being able to plug my tool on most of the systems, by providing profiles you should follow.
And I don’t want to wait 1 year, 5 year, 15 year to have that. Because I don’t have the money to wait. And patient are dying because we are not using data we could use to save them.
So the ideal solution, with the ideal model, even with a government building an ideal model and making it mandatory … I don’t believe in it. I would, because it would be wonderful and save so many people.
But I have to fight with the reality : some hospitals will not change their system before many years. So they will not build anything on OpenEHR. So they have to deal with FHIR.
But indeed, as Thomas said, as Australian are doing : you can build profiles using CKM, because it’s a wonderful tool. And FHIR have a lot to learn from OpenEHR, sometimes about the models, sometimes about the governance.
But please, stop the fight, it’s not the good way to save people life.
I don’t see anyone really disagreeing with your position Florian. Everyone I know who is developing openEHR-based systems recognises that FHIR is a reality , and if nothing else a far better means of exchanging data between systems than we have had before. Every one of the se companies has or is building FHIR adaptors around their systems but these are by definiton quite local and often quite limited in specific countries , atl least in terms of actual deployment. That’s not a criticism, just a fact. It is hard to build good quality profiles - I know as I was closely involved in the UK work.
Any more heated discussion with the FHIR community tends to come when some people claim that FHIR can and should do everything - clinical data modelling, CDRs. That is pushing FHIR outside its original comfort zone and into unproven territory with a fair amount of real-world experience which says that it has and is not likely to work well.
It does sometimes get a bit frustrating when sensible conversations about the best use of each technology turn on 1) Well you should try to build CDRs since the legacy vendors will not like it and then in the same phrase but FHIR data models and processes are perfectly good for CDRs.
Standards like FHIR, or the v3 RIM, or DICOM were never meant to be used as persistence models, but somehow some people have found it convenient to use them as the foundation for a CDR. That’s fine, but use at your own risk, as (besides the pros) there are many cons to such an approach as well (as many on this forum will be well aware of).
At least a discussion like this causes a flurry of messages to be exchanged on this board, whereas it is usually pretty quiet. We do have to take however not to rehash the same old party lines too much. Having long term goals is the name of the game, as a trainer I usually ask trainees ‘how does one ensure that clinical data will still be interpretable 100 years from now’ ? (after 10 database/system migrations). But that’s a data life span that’s seldom envisioned even by those who create standards.