# FHIR vs openEHR **Category:** [HL7 FHIR](https://discourse.openehr.org/c/fhir/101) **Created:** 2022-07-21 10:38 UTC **Views:** 8139 **Replies:** 67 **URL:** https://discourse.openehr.org/t/fhir-vs-openehr/2854 --- ## Post #1 by @mc1995 Hello all, I am just reading into FHIR and openEHR technology and have read several times that FHIR is commonly used as a communication protocol and openEHR for data persistency. Now I had a FHIR workshop and also here data can be stored with FHIR. Now I have not understood exactly what really justifies the effort of FHIR to openEHR mappings, if you could do everything with FHIR? Does anyone here have a concrete example where I see why you should rather do the storage with openEHR and not with FHIR? Thanks! --- ## Post #2 by @jstclairLFPH Hi Micha, you're correct. The emphasis on FHIR development is interoperability of health IT systems in sharing data. I don't think I could suggest storing data in FHIR formats is most advantageous for how you need to use the data in OpenEHR and a clinical setting. --- ## Post #3 by @vanessap Hi Micha, I hope this comparator I adapted few years ago from an example from Eneimi can help: ![compare_fhir_openehr|690x384](upload://f4vVxOGwZp55PumvaBsAoeeFpE5.png) You can use both to store data, but openEHR is way more detailed than FHIR when defining the data points of a concept. And -in my experience- is way easier to query openEHR data comparing with FHIR queries. But end of the day, it depends on what do you want to do in the long term and the context and scope of your project, really. --- ## Post #4 by @pablo Hi, there are two things to consider, what is standard specification and what is technology implementation. Specification wise, it's strange that you find anything to do with storage or persistence in the FHIR spec http://hl7.org/fhir/index.html Though, in the openEHR spec there is indeed a service layer spec https://specifications.openehr.org/releases/SM/latest/openehr_platform.html and service implementation spec https://specifications.openehr.org/releases/ITS-REST/latest/overview.html The key point of openEHR having such service interface layer is to be able to access the EHR management from external systems. Now, the openEHR scope by the specs is to manage EHR information and provide a data access mechanism that is standardized and based on the same semantic components as the EHR information definition: archetypes and templates. This implies persistence/storage of data. By the specs FHIR is to operate over data in a standardized REST way (operations, URLs and resources), that is create and retrieve information. This doesn't imply persistence/storage of data. Then you have difference technology implementations, based on the specs, but that might extend or go beyond the scope of the standard specs. Like having FHIR storage solutions. In openEHR the EHR storage solution is the core component of an openEHR architecture, and it is mentioned in the specs https://specifications.openehr.org/releases/BASE/latest/architecture_overview.html#_information_architecture Even if you have a FHIR storage solution, I would argue the role of such repository is to manage EHRs, while in openEHR that is exactly the role of the storage solution. A FHIR repository can help as a cache, as a secondary analysis database, as a test platform, etc. but it's not an EHR. That is why many architectures choose to use an openEHR IMPLEMENTATION TECHNOLOGY PLATFORM to store clinical information, even to access the information using the SERVICE LAYER, and maybe integrate with FHIR by using those openEHR-native services, and use a FHIR IMPLEMENTATION TECHNOLOGY SERVER to receive FHIR requests. I use uppercase here to mark the difference between what is implementation technology and what is standardized in the specifications, so the main thing is: implementation technology can go beyond what is strictly specified in the specs. So don't be confused, spec is one thing and technology is another thing. --- ## Post #5 by @SevKohler Since other people already pointed out the theoretical part i will state it practically. To put it simple the tooling is way worse and currently scales badly (also due to the model being not designed to persist data), there was even an google dev blog article about how badly the fhir server [are](https://vneilley.medium.com/most-fhir-servers-are-unusable-in-production-8833cb1480b1). Also the openEHR model is way more matured and consistent due to its enormous international archetype library. In FHIR, as long as they dont change their model or standardise the profiles way more, people create zillions of profiles for the same thing. In my 5 years now working with FHIR i have seen more blood pressures then i can count. This then requires that you map internally the blood pressures to leverage consistency lol. A problem that you dont have in openEHR where you have one international archetype for [that](https://ckm.openehr.org/ckm/archetypes/1013.1.3574). Stuff you dont need is just canceled out by the templates meanwhile in FHIR its the other way around. You need to add fields to a very basic e.g. observation. As a result everyone adds its blood pressure values in a different way. So why on earth would somebody want to persist FHIR (in its current state) for something that is to be stored and maintained for decades like Patient data (if we talk about e.g. representing a comprehensive EHR, for sure there are scopes where its not an bad idea). Besides that openEHR alos has a very nice query language. In the end FHIR provides flexibility to its models which is nice for companies developing fast some solutions , but also opens the door for redundant and inconsistent data. openEHR is on the other hand better maintainable etc. with its stable model which makes it way better for longtime use and persisting data. There also many other arguments and problems in both directions. So you see thats why many projects use both ;) --- ## Post #6 by @birger.haarbrandt Hi, I like to raise another issue. Despite being advertised as an API technology, FHIR is surprisingly bad for frontend development once things are getting a bit more complicated (=need to create multiple resources, internally referencing these resources and then putting them in a transaction bundle). Typically (to my experience), instead of using "proper" resources for sending data from client app to server, people use FHIR Questionnaire Responses instead and then map the data to proper resources in the backend. So you basically start developing apps by defining mappings and working around the intended use of the FHIR REST API. With openEHR, you can use different API formats (because the API and "payload/network formats" are not the core of the spec) and then use complementing formats as WebTemplates with FLAT and STRUCTURED formats which are automatically converted into the database format on the standardized Reference Model. While not perfect, this allows way more powerful WYSIWYG/low-code editors and also way more efficient manual app development. --- ## Post #7 by @ian.mcnicoll It is great question because as you say it is possible to store some clinical data in FHIR and in some simpler use cases, this may make sense. As others have pointed out though, the FHIR ecosystem was never designed for this purpose, and as your infomation gets more complex, it struggles with a lack of concrete definitions, limited querying and a modelling methodology/ tooling to support a data platform approach. You should definitely look at [this article](https://medium.com/@alastairallen/fhir-openehr-bef21694f76b) by Alistair Allan, who started as something of an openEHR sceptic but now sees things differently As a concrete example, we have been working on several End of life care datasets, where only a tiny proportion can be carried in FHIR concrete resources e.g meds, allergies, problems but everything else would need to be carried in large bundles of heavily profiled FHIR Observations or QuestionnaireResponses. As others have said , this gets really tricky to model, standardise with a clinical community and keep coherent over time in FHIR. That is not a criticism of FHIR - it was simply never intended for that purpose. --- ## Post #8 by @ian.mcnicoll THis is a very interesting paper. https://www.techrxiv.org/articles/preprint/Can_OpenEHR_ISO_13606_and_HL7_FHIR_work_together_An_agnostic_perspective_for_the_selection_and_application_of_EHR_standards_from_Spain/19746484/1 --- ## Post #9 by @Nikolai_Ryzhikov I would appreciate the opportunity to revisit a topic of interest. While exploring both FHIR CRUD & Search API and OpenEHR, I've observed that FHIR seems to offer a more persistent approach, particularly due to its more user-friendly JSON representation and a standardized API, which appears less prevalent in OpenEHR. In light of this, could you kindly elaborate on the distinctive features that OpenEHR offers? 1. I'm intrigued by the hierarchical EHR structure (EHR, SECTION, ENTRY) in OpenEHR. This approach seems quite unique, especially when contrasted with the more familiar REST API structure of FHIR. Could you please provide more insight into the advantages or reasoning behind this design choice? 2. OpenEHR encompasses a variety of concepts like RM, Archetypes, Templates, and Compositions. This complexity appears quite extensive, especially when compared to FHIR's more streamlined StructureDefinition / Resource core model, which aligns with the Domain Aggregates concept from Domain-Driven Design. Could you explain the benefits of this comprehensive approach in OpenEHR? 3. From a web development perspective, the JSON representation in OpenEHR seems to present some challenges in terms of intuitiveness and ease of use. Could you share your perspective on how this design choice enhances the functionality or usability of OpenEHR? 4. As someone with 15 years of experience in Health IT, I find the initial learning curve for OpenEHR somewhat challenging. Could you offer any guidance or resources that might simplify the process of understanding and implementing OpenEHR? --- ## Post #10 by @Nikolai_Ryzhikov To be honest, FHIR appears to be an interop standard, whereas OpenEHR looks like someone's sophisticated system docs, with many "opinionated" design desicions. --- ## Post #11 by @SevKohler Watch the youtube videos of @Sidharth_Ramesh they will shed some light into this https://youtu.be/Zn4Muj2IOlM The spec can be overwhelming, openEHR aims to represent an entire EHR. It also has a standardized REST API, archetypes and templates similar to FHIRs resources and profiles etc. Otherwise i would just recommend setting up ehrbase and playing around with it. The blog of Thomas Beale is also very good: https://wolandscat.net/2016/04/10/openehr-technical-basics-for-hl7-and-fhir-users/ --- ## Post #12 by @Nikolai_Ryzhikov I'm more interested in key differences between FHIR and OpenEHR, than in learning OpenEHR basics --- ## Post #13 by @thomas.beale [quote="Nikolai_Ryzhikov, post:12, topic:2854, full:true"] I’m more interested in key differences between FHIR and OpenEHR, than in learning OpenEHR basics [/quote] Some resources: * [FHIR versus the EHR](https://wolandscat.net/2019/05/24/fhir-versus-the-ehr/) * [Numerous posts](https://wolandscat.net/category/fhir-2/page/2/) on FHIR technical problems. In response to some earlier questions you had: [quote="Nikolai_Ryzhikov, post:9, topic:2854"] While exploring both FHIR CRUD & Search API and OpenEHR, I’ve observed that FHIR seems to offer a more persistent approach, particularly due to its more user-friendly JSON representation and a standardized API, which appears less prevalent in OpenEHR [/quote] openEHR implementers would be amused by this comment - since openEHR is about persistence, and FHIR is not. See [here for REST APIs](https://specifications.openehr.org/releases/ITS-REST/latest/overview.html). [quote="Nikolai_Ryzhikov, post:9, topic:2854"] I’m intrigued by the hierarchical EHR structure (EHR, SECTION, ENTRY) in OpenEHR. This approach seems quite unique, especially when contrasted with the more familiar REST API structure of FHIR. Could you please provide more insight into the advantages or reasoning behind this design choice? [/quote] Well unique, except for ISO 13606, and HL7 CDA, which also have the same general structure. But if you want the short description of what that structure does, it provides layers of context + clinical headings. See [here for a bit more detail on the context model](https://specifications.openehr.org/releases/RM/latest/ehr.html#_context_model_of_recording). And a more general description here. FHIR doesn't have any of that, it's a framework for defining models (although they don't use that word) of data retrieves, not data committal. openEHR achieves data retrieve via AQL, the archetype query language. [quote="Nikolai_Ryzhikov, post:9, topic:2854"] OpenEHR encompasses a variety of concepts like RM, Archetypes, Templates, and Compositions. This complexity appears quite extensive, especially when compared to FHIR’s more streamlined StructureDefinition / Resource core model, which aligns with the Domain Aggregates concept from Domain-Driven Design. Could you explain the benefits of this comprehensive approach in OpenEHR? [/quote] I'll just say one thing: with no distinction between archetypes and templates, you can't do anything. FHIR sort of uses Implementation Guides (IGs) to do the work of templates. The [Archetype Technology document](https://specifications.openehr.org/releases/AM/latest/Overview.html) might provide some high-level understanding on the openEHR framework. [quote="Nikolai_Ryzhikov, post:9, topic:2854"] From a web development perspective, the JSON representation in OpenEHR seems to present some challenges in terms of intuitiveness and ease of use. Could you share your perspective on how this design choice enhances the functionality or usability of OpenEHR? [/quote] Others could probably answer better (e.g. @sebastian.iancu ) but there is nothing special about openEHR w.r.t. JSON - JSON is a weak formalism anyway, but it can be made to do most things with a bit of work. There's a lot of work going on in JSON-schema for openEHR right now. [quote="Nikolai_Ryzhikov, post:9, topic:2854"] As someone with 15 years of experience in Health IT, I find the initial learning curve for OpenEHR somewhat challenging [/quote] It is, especially if you are used to HL7v2 or CDA or ... FHIR! But it should be easier anyway. The community is working on a better educational approach (there is a dedicated [Education Program Board](https://www.openehr.org/programs/education/) now) and also on easier to use developer resources. If you stick around on this site a bit, and ask questions (best is to use the specific categories) you'll usually get very good responses. Everything in FHIR looks easy because FHIR doesn't try to do anything challenging. It has rigid Resource definitions for some common clinical data, and then generic Resources like Observation and Questionnaire as well, which are hard work to use for realistic structures. There's no systematic semantic approach - it's an ad hoc framework. Every model is its own thing. Then there's the (now huge) problem of private profiling, creating non-interoperable competing versions of the same thing - just go to simplifier.net and look for e.g. vital signs profiles. --- ## Post #14 by @Seref [quote="Nikolai_Ryzhikov, post:9, topic:2854"] I’m intrigued by the hierarchical EHR structure (EHR, SECTION, ENTRY) in OpenEHR. This approach seems quite unique, especially when contrasted with the more familiar REST API structure of FHIR. Could you please provide more insight into the advantages or reasoning behind this design choice? [/quote] For someone with your background, the answer would be: FHIR is an interface specification strongly coupled to REST over HTTP. openEHR is a system specification for what may potentially sit behind the interfaces. [quote="Nikolai_Ryzhikov, post:9, topic:2854"] OpenEHR encompasses a variety of concepts like RM, Archetypes, Templates, and Compositions. This complexity appears quite extensive, especially when compared to FHIR’s more streamlined StructureDefinition / Resource core model, which aligns with the Domain Aggregates concept from Domain-Driven Design. Could you explain the benefits of this comprehensive approach in OpenEHR? [/quote] I think we have different views of DDD. FHIR would sit even outside of Application Services, let alone Aggregates in a DDD design if I was the one doing it. As I indicated, it is an interface spec, not a system spec. openEHR is not bound to a specific technology, it is mostly a heavily Object Oriented shared kernel if you want to map these two concepts to DDD. If you disagree, let's just agree to disagree please because I have no time to discuss angels on pinheads when it comes to DDD. [quote="Nikolai_Ryzhikov, post:9, topic:2854"] From a web development perspective, the JSON representation in OpenEHR seems to present some challenges in terms of intuitiveness and ease of use. Could you share your perspective on how this design choice enhances the functionality or usability of OpenEHR? [/quote] You'll have N people and N + M perspectives as a response with a question like that: too subjective. I can see from your questions you're expecting openEHR as a technology just to "fit" into your comfort zone, which appears to be JSON and REST. That's OK, nothing wrong with that. Except it would not. In fact, neither does FHIR. You say you have 15 yrs of experience in healthcare, then you won't find it difficult to agree that healthcare breaks everything when it comes to mainstream tech. Both FHIR and openEHR specification groups and implementers find it challenging to use mainstream data serialisation formats and architectures challenging. You have a more compartmentalised view of a domain in a REST interface, so data representation is a problem with a smaller scope with FHIR, which helps a bit more compared to openEHR, but there are still some issues. openEHR is heavily OO and especially implementation inheritance centric, so that leads to challenges when it comes to representing it with an interface data format such as json. You should assess openEHR's design choices in a system design context, not in an interface design context. In order to understand the problem with your question, ask yourself "can you share your perspective on how FHIR's design choices enhances the functionality and usability of FHIR when you implement a whole hospital information system with FHIR, using it to process every type of data in the system" [quote="Nikolai_Ryzhikov, post:9, topic:2854"] As someone with 15 years of experience in Health IT, I find the initial learning curve for OpenEHR somewhat challenging. Could you offer any guidance or resources that might simplify the process of understanding and implementing OpenEHR? [/quote] You need to start with a requirement. Don't try to grasp as a whole. Take your requirement, try to implement it with openEHR and ask questions related to that task and approach. You'll almost certainly get lost and frustrated if you try to learn it otherwise. Certainly possible, but much harder. [quote="Nikolai_Ryzhikov, post:10, topic:2854, full:true"] To be honest, FHIR appears to be an interop standard, whereas OpenEHR looks like someone’s sophisticated system docs, with many “opinionated” design desicions. [/quote] I'm assuming you don't intend to do it but that sounds like trolling. Is there an unopinionated spec out there? FHIR says "you shall do REST". It is in the name of the thing (R). I'd say that's on opinion. I'd rather have opinionated design decisions in health specs tbh, because in this space I'd see unopinionated as clueless. Once again: personal view. A late edit: it is possible to 'swap' these two specs for pretty much all the tasks. You "can" implement a HIS with FHIR. You "can" exchange messages with openEHR between systems. It is a matter of choice, which always depends on the context. You can see from my responses above that I'm trying to put your questions into context in my answers. That's the crux of decision making when it comes to choosing standards: context. --- ## Post #15 by @birger.haarbrandt From a platform backend developer perspective, openEHR is a quite elaborated and sophisticated thing to build. For developers "using" openEHR, it only takes maybe 90 minutes on a rainy Sunday afternoon to have a "hello world" running. See https://github.com/ehrbase/ehrbase for setting up an openEHR Server. Try things using a postman collection: https://github.com/ehrbase/documentation/tree/master/examples --- ## Post #16 by @Sidharth_Ramesh I was trying to understand this exact question when I first entered the openEHR space. And here is my question thread: https://discourse.openehr.org/t/relationship-between-fhir-and-openehr/236/5?u=sidharth_ramesh And a follow up answer after some more research: https://discourse.openehr.org/t/relationship-between-fhir-and-openehr/236/19?u=sidharth_ramesh And here's a video delving into this topic further: https://youtu.be/OFC6V9537tg?si=4AqNSUgUhGQYbpvM&t=81 (my latest take) You can also check out https://www.youtube.com/watch?v=kOU2HGqK23o&pp=ygUPZmhpciB2cyBvcGVuZWhy --- ## Post #17 by @pablo It's difficult to list differences when the whole specs are designed for different purposes. All HL7 standards are designed for black box data exchange (dinner care about the internal models, just the exchange models), openEHR is white box (cares about internal models and architecture) EHR management, which includes data exchange but it's not the main focus. --- ## Post #18 by @Nikolai_Ryzhikov This sounds little bit like a mantra. Gan you show me "good examples" where fhir is blackbox and openehr is white? --- ## Post #19 by @yampeku I think blood pressure is a good example. What is a blood pressure for openEHR and what is a blood pressure for FHIR? What is a blood pressure for openEHR is the CKM definition. That's it. You will always be able to query where is a systolic and where the diastolic are, because shared models are the basis. For FHIR completely depends on the use case, i.e. the needs of the two points of the communication (which could also be national requirements, but again could be different than any other project). --- ## Post #20 by @birger.haarbrandt The "blackbox" approach has officially been part of the design paradigm of HL7 ("We don't care about your system internals as long as you implement the interface"). Grahame has mentioned this multiple times in his talks: ![image|690x400, 50%](upload://1IWFtYrjVvZyCveS6XBdQaJVxQk.jpeg) In contrast, by design, you cannot build an openEHR system as blackbox --- ## Post #21 by @Seref [quote="Nikolai_Ryzhikov, post:18, topic:2854"] Gan you show me “good examples” where fhir is blackbox and openehr is white? [/quote] An interface, by definition exists to sit between what is behind it , effectively making it a "black box" (opaque is a better term) for what is using the interface. openEHR, by definition exists to providing the whole logical structure for what sits behind any applications built on it. It guarantees that you have the implementation of a logical model for what powers the applications or APIS, which may include a FHIR API as well. Therefore it provides by design a "white box" (translucent is a better term). Once again: it is simply system design vs interface design specs being what they're designed to be. Once again: you can do whatever you want with them, but their nature is different. --- ## Post #22 by @thomas.beale [quote="Nikolai_Ryzhikov, post:18, topic:2854"] This sounds little bit like a mantra [/quote] I've been to about 12 years of HL7 meetings, from 2000 onward, and most recently 2019 and 2022 Baltimore. 'HL7 is for black box data exchange' is indeed the stable mantra of HL7. It's in the DNA. It's why they take no account of modern systems that have externally defined models, ontologies etc. and continue to define their own payload - which is always a headache to map to. The HL7 payload definitions will never be the semantic models of anything; they are just definitions of specific payloads. They're not systematically designed, and create unending work to map to. HL7v3, CDA and now FHIR all do the same thing. [quote="yampeku, post:19, topic:2854"] For FHIR completely depends on the use case, i.e. the needs of the two points of the communication (which could also be national requirements, but again could be different than any other project). [/quote] Exactly. Trying searching for blood pressure and other simple things in simplifier.net. --- ## Post #23 by @Nikolai_Ryzhikov Blood pressure can be straightforward expressed with Observation.component, as well as many multi-component observations. --- ## Post #24 by @Nikolai_Ryzhikov May be I'm not too smart, but i don't see big difference between model for communication and model for persistence. --- ## Post #25 by @yampeku https://simplifier.net/search?q=blood+pressure Here you have: tens of observation profiles, a few questionnaires, a few bundles, and even an image profile and a device. You have systolic and diastolic as their own observation profiles, all the BP as an observation and as said above, as part of bundle profiles Each one of that profile answers to a single information exchange need --- ## Post #26 by @Nikolai_Ryzhikov What I see, that both are trying to model healthcare domain, both provides framework to potentially describe any possible model - it's just to different communities, frameworks, consensus processes and organizations. The question is where exactly the difference? Let's say archetypes kinda resources, templates like profiles. Can we model openehr in fhir or vice versa? That would be nice experiment! --- ## Post #27 by @Nikolai_Ryzhikov I just see two alternative modeling approaches - more generalised and less --- ## Post #28 by @Nikolai_Ryzhikov If i would create archetypes for all fhir resources, and templates for profiles did i get something equal to FHIR? --- ## Post #29 by @yampeku [quote="Nikolai_Ryzhikov, post:26, topic:2854"] . Can we model openehr in fhir or vice versa? That would be nice experiment! [/quote] openEHR into FHIR has already been explored :slight_smile: http://standardsmania.blogspot.com/search/label/FHIR --- ## Post #30 by @Nikolai_Ryzhikov Or i can create structure defs for CKM archetypes and profiles for templates - would i get openehr? --- ## Post #31 by @Nikolai_Ryzhikov Let's compare core meta frameworks first - not content --- ## Post #32 by @thomas.beale You may see N competing versions of that idea in http://simplifier.net. Along with all the other competing copies of such things. Each such model mixes in technical / protocol attributes, while (usually) missing semantic elements necessary for hi-fidelity expression of the original model. [quote="Nikolai_Ryzhikov, post:26, topic:2854"] Let’s say archetypes kinda resources, templates like profiles. Can we model openehr in fhir or vice versa? That would be nice experiment! [/quote] No, Resources are 'kinda like' the openEHR Reference Model. Archetypes are like profiles, except that a) profiles are an uncontrolled wild west and b) archetypes are technology and standard-agnostic - they just express pure domain semantics. [quote="Nikolai_Ryzhikov, post:26, topic:2854"] What I see, that both are trying to model healthcare domain, both provides framework to potentially describe any possible model - it’s just to different communities, frameworks, consensus processes and organizations. The question is where exactly the difference? [/quote] In FHIR (same as previous HL7 standards) profile creation (i.e. creation of domain semantics) is essentially understood as a software development activity, undertaken by separate companies, countries and so on. There is no independent pure knowledge representation formalism, and no independent domain knowledge representation, only representation of specific domain elements, as (mis)understood by IT people, into specific standards, within all those organisations. That's why we have the mess we have today. --- ## Post #33 by @Nikolai_Ryzhikov Many competing profiles is an organizational decision, not a design consequence. HL7 could organize all profiles into one huge IG like CKM. --- ## Post #34 by @pablo [quote="Nikolai_Ryzhikov, post:18, topic:2854, full:true"] This sounds little bit like a mantra. Gan you show me “good examples” where fhir is blackbox and openehr is white? [/quote] Is just a definition. HL7 works in a black box mode since HL7v2.x and openEHR was always a spec for the EHR internals, so by definition white box. Not sure how to give good examples of something that is that way. Black box means it's not concerned about the internal models, just the exchange (external) ones, and white box is that you can actually see the internals. Please let me know if that is not clear enough, though you can search through HL7 documentation, they talk about this in the specs, many presentations of HL7 experts also mention this, etc. best, Pablo. --- ## Post #35 by @pablo You will end up with tens of definitions for blood pressure and for R1 to R5, R6, etc. :) --- ## Post #36 by @Nikolai_Ryzhikov So we have first "real" difference: * openehr is trying to standartize as much as possible as CKM * fhir standardize 20 of 80, and allows many potentially intersecting/conflicting IGs ??? --- ## Post #37 by @Nikolai_Ryzhikov Second "real" difference: * FHIR has two layer architecture - resources and profiles * OpenEHR has three layer - RM, AT & templates RM in openehr is more generic than FHIR resources, where ATs are more specific. To be honest i don't like multi-layer at all, semantic web rdf does it much more elegant than oop, fhir and openehr --- ## Post #38 by @Nikolai_Ryzhikov Oh, third ideological difference - openehr believes in "universal model" more than fhir ;) --- ## Post #39 by @birger.haarbrandt Not really, semantic web is nice for ontology but not really for epistemology. This is the same reason why SNOMED alone is not sufficient to establish interoperability. --- ## Post #40 by @Nikolai_Ryzhikov Please elaborate. Descriptive logic has small clear core, strong theoretical background and can cover everything what oopish models (like fhir and openehr) can do plus what they can't --- ## Post #41 by @Nikolai_Ryzhikov Hope eventualy snomed will cover all terminologies ;) --- ## Post #42 by @pablo [quote="Nikolai_Ryzhikov, post:26, topic:2854"] both are trying to model healthcare domain [/quote] 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. --- ## Post #43 by @Nikolai_Ryzhikov 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. --- ## Post #44 by @Nikolai_Ryzhikov 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 ) --- ## Post #45 by @pablo [quote="Nikolai_Ryzhikov, post:43, topic:2854, full:true"] 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. [/quote] 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) --- ## Post #46 by @pablo [quote="Nikolai_Ryzhikov, post:44, topic:2854, full:true"] 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 ) [/quote] 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. --- ## Post #47 by @thomas.beale [quote="Nikolai_Ryzhikov, post:33, topic:2854, full:true"] Many competing profiles is an organizational decision, not a design consequence. HL7 could organize all profiles into one huge IG like CKM. [/quote] 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](https://wolandscat.net/category/fhir-2/). 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. [quote="Nikolai_Ryzhikov, post:37, topic:2854"] To be honest i don’t like multi-layer at all, semantic web rdf does it much more elegant than oop, fhir and openehr [/quote] 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](https://wolandscat.net/2014/08/08/rdf-for-universal-health-data-exchange-correcting-some-basic-misconceptions/). [quote="Nikolai_Ryzhikov, post:44, topic:2854, full:true"] 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 ) [/quote] See [here](https://wolandscat.net/2017/01/29/fhir-compared-to-openehr/). 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. --- ## Post #48 by @Nikolai_Ryzhikov 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. --- ## Post #49 by @Nikolai_Ryzhikov 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 --- ## Post #50 by @Seref [quote="Nikolai_Ryzhikov, post:49, topic:2854"] And that is Grahame’s point in zulip. fhir is trying to make it “implementable” from the beginning, openehr separate concerns - modelers from implementers. [/quote] 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. --- ## Post #51 by @damoca [quote="pablo, post:45, topic:2854"] Where in the FHIR specs does it says it’s purpose is for data storage? [/quote] 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. http://hl7.org/fhir/storage.html --- ## Post #52 by @gary.mcallister 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... --- ## Post #53 by @birger.haarbrandt @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 --- ## Post #54 by @gary.mcallister How does it cope with change? --- ## Post #55 by @sebastian.iancu @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. --- ## Post #56 by @Seref Hi Garry. [quote="gary.mcallister, post:54, topic:2854, full:true"] How does it cope with change? [/quote] 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" --- ## Post #57 by @Nikolai_Ryzhikov 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 ;) --- ## Post #58 by @borut.jures Hi @Nikolai_Ryzhikov ! An interesting thread. Is Grahame an advisor at [your company](https://www.health-samurai.io/company)? It would be interesting to invite him into this thread :wink: p.s. You have built some nice products at your company (form builder, workflow engine). --- ## Post #59 by @thomas.beale 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. --- ## Post #60 by @Nikolai_Ryzhikov 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 :) --- ## Post #61 by @Nikolai_Ryzhikov Here is a long thread in zulip - https://chat.fhir.org/#narrow/stream/179174-openehr/topic/Working.20together --- ## Post #62 by @thomas.beale [quote="Nikolai_Ryzhikov, post:60, topic:2854"] Also, inheritance is possible in FHIR - look at Resource → DomainResource → Patient or Quantity → Duration chains [/quote] It does exist. I've modelled out the entirety of FHIR R4 in the past, in openEHR BMM format, so I have built all that. But it isn't flexible inheritance in the usual sense. The experience of expressing the Resources in a normal OO/FP meta-model by the way shows how painful the Resources are - it's why various orgs added a layer right over the top to create the needed generalisation relationships, so that CDS above that could actually reason correctly with both general and specific categories (kinds of Order for example). As for 'ComplexTypes', 'Logical Models', 'Patterns' and so on - it seems these are various attempts to compensate for underlying limitations. Things like `DomainResource.containted`will not lead to the kinds of flexible modelling capability we need. But what I don't see is a clean, comprehensive, single-source of truth domain modelling framework from which the technical products can be derived. That's part of the reason for the mess in simplifier.net. [quote="Nikolai_Ryzhikov, post:60, topic:2854"] Is there multiple inheritance in OpenEHR? [/quote] We limit in the Reference Model to the capabilities of the mainstream languages (extends/implements) by common consent, since the MI present in earlier versions of the model made some people unhappy ;) Similarly, we don't use it in the archetype framework, which operates on a single hierarchy taxonomic basis. I think MI in archetypes would bring more pain than benefit, especially as data structures tend to follow a frame-logic (part-of) structure rather than a taxonomic one (like ontologies). [quote="Nikolai_Ryzhikov, post:60, topic:2854"] BTW: my favorite language is Clojure :slight_smile: [/quote] Sign of a sharp thinker ;) --- ## Post #63 by @sebastian.iancu 18 posts were split to a new topic: [(re)moved troll discussion on "FHIR vs openEHR"](/t/re-moved-troll-discussion-on-fhir-vs-openehr/6147) --- ## Post #79 by @xabiermichelena Hi Albert! Welcome to the openEHR community! I can consider myself a newbie as well as I've been working with openEHR only for a few years. I will tell you what I consider openEHR: a group of practising clinicians, medical informaticists, healthcare professionals who code, clinical data nerds... that want to improve EHR development to enhance healthcare. We even work together with HL7, snomed CT to name a few to get there... If you feel your mission is aligned with that, join the community, write code in whatever programming language you wish,... there is ton of ways you can contribute... The rest, is nonsense! --- ## Post #82 by @Koray_Atalag May I suggest that we restart this conversation from the right end this time? I'm pretty sure no one has bad intentions here - sometimes we all have strong opinions and, I for one, may express myself in a way that doesn't sound very positive or even kind. I've been in both HL7 and openEHR community pretty much same time since 2001 and all I can say is my experience with both communities has been amazing - like a family. I had many many instances where I came across people from HL7 saying negative things about openEHR and equally vice versa. But, most of those conversations and unease disappears when one side listens to the other party with an open mind and with respect. In many cases I actually got their point and started having decent conversations so much so that I call many of them as friends! Anyway, neither openEHR nor HL7 is perfect and there's a lot to learn from each other - especially these days with a climate of collaboration and appreciation. IMHO, in openEHR we could have done better if we focused on implementation and supported developers and probably same with FHIR in terms of more and meaningful engagement with the clinical and informatics community. For example, the idea of a FHIR server was brilliant -anyone could start interacting with an API that is perfectly documented. But I believe it's also dependent on resourcing and priorities - we, in openEHR, spent quite a bit of time to mature the specifications and modelling process and tooling before starting to support the developers etc. Also, FHIR had a huge advantage by having massive HL7 enterprise behind it while in openEHR we survived on grants and contributions from a much smaller vendor community. In the end, I'm personally very happy where both organisations and communities are at right now. And I would encourage everyone from both communities to be open minded, kind and non-judgmental. At the end of the day, what both FHIR & openEHR are doing really matters and already saving many many lives and helping organisations to do better with less resources etc. So, the cause if bigger than us! Let's not forget that. If you have any particular questions or viewpoints, I would personally be very interested to continue this thread (or maybe create another - called FHIR and openEHR because this is really the point. Neither could deny the other - we will co-exist, that's for sure. Thanks --- ## Post #83 by @linforest ## User's Question Translated by Bing (Microsoft Translator) For the HL7 FHIR specification of black box thinking and the openEHR specification of white box thinking, and the actual adoption, implementation and application of both, how do you think the two parties should collaborate to promote activities throughout the lifecycle of healthcare data in order to better achieve the overall goals of leveraging healthcare information technology and data to improve health, reduce costs, and improve experience? --- ## From DeepSeek Translated by Bing (Microsoft Translator) HL7 FHIR (Fast Healthcare Interoperability Resources) and open Electronic Health Record (openEHR) represent two different paradigms for modeling and exchanging healthcare data, with the former emphasizing standardized interfaces and fast interoperability with a "black box" mindset, and the latter emphasizing open data modeling and clinical semantic expression with a "white box" mindset. Enabling both to work together requires leveraging their strengths and working together at different stages of the data lifecycle. The following is a path to collaboration at the technical, architectural, and implementation levels: --- ### **I. Hierarchical Collaboration Architecture Design** 1. **Data Modeling Layer (openEHR-led)** - Use the Archetype/Template mechanism of openEHR to construct clinical ontologies and define fine-grained clinical concepts (e.g., blood pressure observations include contextual information such as body position and measurement site) - Ensure the medical accuracy of the data model through Clinical Governance, such as the ISO 13606 standard - Generate scalable, persistent data storage structures (e.g., EHR Extract) to support clinical decision support and long-term data traceability 2. **Interface Interaction Layer (FHIR-led)** - Map openEHR models to FHIR resources, such as Observation and Composition, and use the StructureMap tool to convert the models - Build standardized service interfaces based on FHIR RESTful APIs (e.g., $document to generate CDA-compliant clinical documents) - Use FHIR Subscriptions to push real-time data to meet the needs of emergency and critical care scenarios 3. **Hybrid Persistence Layer Design** - Dual storage engines: openEHR stores Event-Centric, FHIR stores Resource Snapshots - Continuous monitoring data (e.g., ICU equipment data) is processed through a time series database and then synchronized to the two systems - Use GraphQL to build a unified query layer that supports cross-model federated queries --- ### **Second, the whole life cycle coordination mechanism** 1. **Data Creation Phase** - Clinicians use openEHR templates to enter structured data (e.g., surgical record templates contain fields such as surgical steps, complications, etc.) - IoT devices transmit real-time monitoring data through FHIR DeviceMetric resources - Use FHIR Questionnaire to link with openEHR templates to achieve dynamic form generation 2. **Data Exchange Phase** - FHIR-based CDS Hooks trigger the openEHR rules engine (e.g. drug contraindication check) - Regional Health Information Exchange (HIE) is transmitted using FHIR Bundles, which are internally converted to openEHR Composition - Use the FHIR Bulk Data API to interconnect with the openEHR data warehouse to support scientific research data analysis 3. **Data Analysis Phase** - openEHR AQL (Archetype Query Language) for in-depth clinical analysis (e.g. postoperative infection risk prediction) - The Measure resource of FHIR interconnects with the analysis results of openEHR to generate a quality indicator report - The machine learning model accesses the openEHR signature database through the FHIR operation --- ### **III. Implementation Strategy Recommendations** 1. **Toolchain Integration** - Develop bidirectional conversion tools (e.g., openEHR-FHIR Transformer) that support: - Automatic generation of Template to StructureDefinition - AQL to FHIR SearchParameter mapping - Build a hybrid FHIR server (e.g. HAPI FHIR integrated with EhrBase) 2. **Implementation Roadmap** - Phase 1: Adopt openEHR modeling inside the EMR system and expose the FHIR API to the outside world - Phase 2: Establishment of a library of clinical models (e.g. NHS's Discovery project model) - Phase 3: Develop an intelligent agent to automatically handle model version migration 3. **Governance Framework** - Establishment of a joint working group to develop the FHIR-openEHR Interoperability Technical Specification - Establish a model registry (e.g., HL7 FHIR Registry is connected to openEHR Clinical Knowledge Manager) - Blockchain technology is used to record model changes and mappings --- ### **Fourth, typical application scenarios** 1. **Inter-agency referral** - The outgoing organization generates a summary via FHIR Composition - The receiving organization converts the FHIR Bundle to openEHR EHR Extract - Automatically trigger the onboarding process in the openEHR guide 2. **Real World Research** - FHIR ResearchStudy defines the study protocol - openEHR AQL extracts eligible cases - FHIR EvidenceResource publishes the results of the study 3. **Chronic Disease Management** - Home sensors upload data via FHIR Observation - openEHR Guideline Engine generates personalized recommendations - FHIR CarePlan dynamically adjusts management plans --- ### **V. Challenges and Countermeasures** 1. **Semantic Alignment Issues** - Establish a joint binding mechanism between SNOMED CT and openEHR Archetype - Development of ML-based automatic coding mapping tools 2. **Performance Optimization** - Use columnar storage optimizations for openEHR queries (e.g. Apache Parquet format) - FHIR batch operations use asynchronous task mode 3. **Business Model** - Cloud service providers offer hybrid managed services (e.g., Azure Health Data Services) - Establish a dual-track ecosystem of open source and commercialization (similar to the RedHat model) --- Through this hierarchical collaboration model, it is possible to maintain the advantages of openEHR in clinical in-depth modeling while leveraging the advantages of FHIR in terms of ecosystem breadth. It is suggested that medical institutions should adopt the architecture strategy of "internal openEHR+ external FHIR", implement hybrid interoperability gateways in the construction of regional health platforms, and finally form a smart medical system driven by clinical knowledge and smooth data flow. --- ## Post #84 by @linforest [quote="thomas.beale, post:47, topic:2854"] What’s lacking is a coherent semantic framework. [/quote] An example from [chat.fhir.org](https://chat.fhir.org/#narrow/channel/179256-Orders-and-Observation-WG/topic/Vital.20signs.20-.20Expressing.20Body.20Temperature.20Measurement.20Site): ![image|690x481](upload://cnFelVpPvFoaOwrEbjtMpWUARy.png) --- ## Post #85 by @shawnt Hello everyone! First off, I just wanted to say hi and mention how much I enjoyed all the comments . It certainly takes some time to go through them all :slight_smile: Being on the FHIR-side of things (https://iEHR.ai), I’ve found this thread to be incredibly insightful and engaging. I really appreciate it. Recently I came across this - seems like a promising step toward building bridges: https://build.fhir.org/ig/FHIR/openehr-base-ig/artifacts.html. --- **Canonical:** https://discourse.openehr.org/t/fhir-vs-openehr/2854 **Original content:** https://discourse.openehr.org/t/fhir-vs-openehr/2854