Hope eventualy snomed will cover all terminologies 
The key is in the āfor whatā they are trying to model, goals are very different. As said before, FHIR is for exchange mainly, and itās actually (ab)used for storage, which wasnāt itās purpose. Those in FHIR there is no concept of EHR. In openEHR, the objective of modeling is mainly for information recording, not for exchange, exchange in openEHR is simply a technical thing needed to enable distributed information recording, but itās not the focus of openEHR. So when different communities are creating their models, the key difference is not the domain, is āfor whatā they are creating their models, basically about the requirements.
1 Like
We built dozen of working ehr and phr native in fhir, and a lot are in progress - i donāt think fhir is abused by persistence - itās just another mantra.
What i see that fhir and openehr are really donāt know a lot about each other and live in parallel universes (where fhir one is little bit bigger and faster growing - to be honest )
Where in the FHIR specs does it says itās purpose is for data storage?
If you used the specs for something that wasnāt designed for is not a mantra, is abusing the specs if the storage is FHIR. An EHR can be built in any way and have a FHIR API, which would be using the specs for their purpose. If you check the history of HL7 there were many groups abusing the specs in many points in time. Just check for RIM/CDA and the RIMBAA initiative which is another example of using the specs for a use that was not designed for. Iām taking about the objective of the specs, not about what is technically possible. Technically you can do whatever you want, that might work, but that doesnāt mean the specs were designed for that use. Two different subjects.
On a side note, it would be nice to consider the content of what I write, or do a little research on the HL7 side, instead of answering that everything I say is a mantra, which is kind of your mantra now 
(I have been studying and implementing HL7, DICOM and openEHR specs for 17 years, so I try to justify what I say based on my experience on each standard not on mantras)
2 Likes
Again, you canāt compare specs that are focused on doing different things in different ways. Implementation facts are 1. there are projects in production that make use of both standards, 2. are totally complementary, 3. we tend to use FHIR as downstream artifacts (openEHR models are the core definitions of data and profiles or simple resources are derived from them to be used as the definition of the data exchange), 4. some openEHR implementations use FHIR for accessing terminology services.
In that context, it doesnāt matter of which is bigger or faster growing. The specs are out there and are tools to solve problems, one could use one, the other or both, and both will keep their respective goals, will be updated and improved, new specs will emerge, etc. HL7 has more than 30 years and has 3 different families of specs for data exchange (v2.x, v3 and FHIR), 2 of which are widely in use (HL7v3 was a failure). openEHR is younger, has a different focus, tries to solve a different set of problems, came from research projects, etc.
About adoption, if you check HL7 as an organization, it is managed as a company, and it has a huge marketing/lobby machine behind it, openEHR doesnāt have that but might have it in the future. Marketing makes a lot for adoption, and I think we have many things in that area to learn from HL7 in terms of selling the idea of the specs in different markets to increase adoption.
1 Like
Partly true. But the design intent of FHIR isnāt domain knowledge representation, so even if they had a single CKM, they wouldnāt be able to create definitive models for most content anyway, because the FHIR formalism as a) missing various needed semantics, b) mixes in a ton of technical semantics that mean nothing to clinical modelers, and c) is full of technical anti-patterns. Itās not just not that good semantically, although there are exceptions (some of the fully designed resources), and there are lots of useful detail definitions; terminology is also reasonably well done. Whatās lacking is a coherent semantic framework.
Semantic web doesnāt address the other levels. RDF models have nothing to say about data representation, only knowledge representation. Hereās a blog post on why RDF is not the silver bullet some think.
See here.
Iāll just summarise by saying that the major metrics via which we can judge the HIT sector are all about the same as 30 years ago. Interoperability standards continue to add more band-aids (and more work), but no systemic solution.
2 Likes
If we use ālanguageā metaphor for fhir and openehr , which i personally like, language phenomenon is used for both communication and thinking (mental or semantic model). As i said for me itās hard to distinguish. I dont see big differences between ātoo technical, not for persistenceā fhir and āso semantic, not for communicationā openehr.
Thomas i read all your posts twice
Still trying unmix essential from āmarketingā on both sides.
What i see, that fhir involves engineers more into modeling, openehr less. And that is Grahameās point in zulip. fhir is trying to make it āimplementableā from the beginning, openehr separate concerns - modelers from implementers.
I have trauma after āoverengineeredā and āletās
be honest failed because of thisā RIM/V3 and see a lot of similarly of openehr and v3. Iāve heard a lot of similar arguments about semantic from v3 people
1 Like
Even though Iād refrain from interpreting Grahameās opinions when I hear them out of context and from a third party, there is some truth to a high level description resembling what you wrote, regardless of where it comes from.
openEHR is very strongly focused on putting the cliniciansā view of the world and their information requirements into the centre and the implementers are then asked to deliver what the clinician asked for. It is their task to make it work.
FHIR makes the technical job of a software developer somewhat easier, which is implementing the view of a clinical concept that comes from a group of engineers who base their view on the infrormation and technical contents of their systems, which in turn comes from another group of engineers/requirements analysts who spoke to clinicians in the first place, and kept talking to them for decades as they updated their systems.
These are both powerful approaches, but different ones. I refuse to attach an absolute superiority to either of them. I suggest you consider doing the same.
5 Likes
To be fair, a mention suddenly appeared in the specifications in R4, as a method for data exchange. In previous versions, there was no mention to persistence.
http://hl7.org/fhir/R4/exchange-module.html
And they admit that:
Applicability of storing resources natively
In principle, resources are designed for exchange between systems, rather than as a database storage format. One practical consequence of this is that in some way, resources are highly denormalised, so that granular exchanges are fairly stand alone. (Note that in some ways, resources are also highly normalised; e.g. Patient demographic details are only found in the Patient resource).
[ā¦]
Resources, on the other hand, are designed for robustness and stability over efficiency.
2 Likes
Persistency of OpenEHR can be variable too. Needs consideration re the performance and optimisation of the āengineā re analytics etc. Itās a great ādocumentā format and gives dynamism over versioning which relational databases struggle with. Would be good to see an implementation in a Hybrid Dbā¦
1 Like
@gary.mcallister EHRbase is based on a relational database with (now) very minimal use of JSONb. Hence, I think this ticks the boxes of a hybrid DB
1 Like
How does it cope with change?
@Nikolai_Ryzhikov I think you forgot the 4th difference, that relates to an earlier post from @Seref :
"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 it is an important aspect to consider if you really want to understand the difference and use-cases.
Furthermore, although youāve got here some reactions to your questions, I think quite a lot of people here are not that concerned with this gap between the two standards. We already learned that these two standards can cohabit out there in reality. If you feal like FHIR suits your needs in a better way, then you probably donāt need openEHR - and thatās also fine.
2 Likes
Hi Garry.
I didnāt have time to check the code since @birger.haarbrandt announced the new aql engine in Arnhem but assuming youāre referring to db schema changes, it is possible to come up with a db schema heavily favouring the RM, if not directly modelling it in a relational way, then keep the (almost) zero changes to db schema advantage of most CDRs. This would be my guess on how theyād probably tackle it.
EHR centric performance becomes really tricky then. Iām curious to see how Vita engineers dealt with that. My cheezy way of explaining the design dilemma is: āitās relatively easy to turn a tree to a table, but good luck getting the tree back after you place a table in the middle of your kitchenā
3 Likes
Thx, i donāt think FHIR sticks too much to REST, it claims to support multiple paradigms - messages, documents and even databases. Im trying to figure out the ārealā diff of this two standards and probably make hybrid
Hi @Nikolai_Ryzhikov !
An interesting thread.
Is Grahame an advisor at your company?
It would be interesting to invite him into this thread
p.s. You have built some nice products at your company (form builder, workflow engine).
2 Likes
Hereās an example of over-engineering. In openEHR you can a) specialise an archetype from another one and b) make an archetype part of another one (two methods: slots and direct refs). These are 2 essential re-use capabilities used in model-based technologies for about 40 years, including your favourite modern programming language. FHIR cannot do either. This is just an objective fact, itās not ideology or me being difficult.
In FHIR, you canāt do specialisation (inheritance) at all. The only kind of referencing you can do is runtime refs, e.g. Reference(typeA, typeB, ...). This does nothing in the modelling domain.
These are just two fundamental limitations of FHIR that make it much harder to precisely model common domain semantics, or to have a sustainable library of common definitions.
So. If you think your favourite programming language (Java 19?) is āover-engineeredā, then I assume youād be happy to go back to Java 1.5 or K&R C.
1 Like
In FHIR, you can define ComplexType and use it in Resources.
Resources and ComplexTypes are technically described the same way. So it is just an administrative decision not to compose resources of resources. Also, inheritance is possible in FHIR - look at Resource ā DomainResource ā Patient or Quantity ā Duration chains. FHIR Logical Models do not have these limitations.
I agree it is not a very clean solution.
As well, multiple inheritance (mixins) is potentially possible for interfaces. (Grahame informally introduced Patterns - aka Mixins after your blog post about modeling consistency).
Is there multiple inheritance in OpenEHR?
BTW: my favorite language is Clojure