Watch the youtube videos of @Sidharth_Ramesh they will shed some light into this
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:
I’m more interested in key differences between FHIR and OpenEHR, than in learning OpenEHR basics
Some resources:
In response to some earlier questions you had:
openEHR implementers would be amused by this comment - since openEHR is about persistence, and FHIR is not. See here for REST APIs.
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. 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.
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 might provide some high-level understanding on the openEHR framework.
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.
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 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.
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.
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.
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”
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.
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.
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 GitHub - ehrbase/ehrbase: An open source openEHR server for setting up an openEHR Server.
Try things using a postman collection: https://github.com/ehrbase/documentation/tree/master/examples
I was trying to understand this exact question when I first entered the openEHR space.
And here is my question thread: Relationship between FHIR and openEHR - #5 by Sidharth_Ramesh
And a follow up answer after some more research: Relationship between FHIR and openEHR - #19 by 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
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.
This sounds little bit like a mantra. Gan you show me “good examples” where fhir is blackbox and openehr is white?
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).
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:
In contrast, by design, you cannot build an openEHR system as blackbox
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.
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.
Exactly. Trying searching for blood pressure and other simple things in simplifier.net.
Blood pressure can be straightforward expressed with Observation.component, as well as many multi-component observations.
May be I’m not too smart, but i don’t see big difference between model for communication and model for persistence.
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
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!
I just see two alternative modeling approaches - more generalised and less
If i would create archetypes for all fhir resources, and templates for profiles did i get something equal to FHIR?
openEHR into FHIR has already been explored 
http://standardsmania.blogspot.com/search/label/FHIR
Or i can create structure defs for CKM archetypes and profiles for templates - would i get openehr?
