Here is a long thread in zulip - https://chat.fhir.org/#narrow/stream/179174-openehr/topic/Working.20together
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.containtedwill 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.
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).
Sign of a sharp thinker
2 Likes
18 posts were split to a new topic: (re)moved troll discussion on âFHIR vs openEHRâ
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!
7 Likes
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
9 Likes
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
- 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
- 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
- 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
- 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
- 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
- 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
- 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)
- 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
- 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
- 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
- Real World Research
- FHIR ResearchStudy defines the study protocol
- openEHR AQL extracts eligible cases
- FHIR EvidenceResource publishes the results of the study
- 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
- Semantic Alignment Issues
- Establish a joint binding mechanism between SNOMED CT and openEHR Archetype
- Development of ML-based automatic coding mapping tools
- Performance Optimization
- Use columnar storage optimizations for openEHR queries (e.g. Apache Parquet format)
- FHIR batch operations use asynchronous task mode
- 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.
An example from chat.fhir.org:
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 
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: Artifacts Summary - OpenEHR Base package v0.1.0.
1 Like