openEHR and HL7 Joint Announcement

HL7 International and openEHR International are pleased to inform our collective communities that we are jointly considering aligning some of our standards and specifications for the global good.

We believe that this will be beneficial for:

  • The digital health ecosystem: in the long term, having some aspects of openEHR co-published as HL7 standards will deliver clarity and harmony. This will increase the choices and power of software as an inevitable outcome is demonstrating how the specifications work together more completely than has been done previously.
  • The openEHR community: by gaining additional community, alignment of formal adoption processes, and availability of shared conformance, compliance, publication tools and processes
  • The HL7 community: by leveraging openEHR’s open collaborative culture, platforms, and people - particularly the clinical community - an extensive clinical model library, clinical modelling methodology, elements of the specifications and the value provided by better integration of tooling and modelling between the communities

We appreciate that this news may surprise some of you, and we recognise that there will be questions on how we can best work together. The questions we have already posed ourselves include:

  • Which openEHR specifications are appropriate to benefit from an HL7 driven standardisation process? Initial potential candidates include IPS and EHDS.
  • Can we create a path through HL7 that meets openEHR’s standardisation needs, but works for an already existing community with a different geographical distribution and a different core requirement than HL7’s existing community?
  • Can HL7 create a path that meets its standards obligations, and works for the existing openEHR community that has a different geographical distribution and different core needs?
  • Where we believe mutual value can be achieved in the alignment or reconciliation of openEHR and HL7 standards and specifications, how can we achieve that? How do we describe the process? How does the ecosystem benefit?
  • Can (and should) we introduce more formal standardisation for some parts of openEHR and is this possible without harming the proven openEHR culture of open innovation?
  • Can (and should) we introduce some aspects of openEHR methodology to HL7 without compromising a well-established standards process?
  • Given the effort and commitment that this will take, and a need for ongoing activities such as standards maintenance, is there a lasting benefit for both our communities?

We do not have any formal agreement at this time, or even any certainty that we can overcome these challenges. We are announcing our intention to explore a closer collaboration.

Both openEHR and HL7 are open communities; our true value is that openness and having a transparent dialogue. We must not consider these matters without involving you, which is why we’re letting you know that we’re looking at this, and asking you for your input.

If we together decide to move forward, whatever we do will take time to build trust, develop approaches, and deliver outcomes.

Please do provide your honest feedback - in the spirit of working together towards our shared vision of an enhanced digital health ecosystem. Indeed, we anticipate and look forward to getting many comments!

Thank you for your time, and considering this next step in the future of both our organisations.

Best wishes

Rachel and Chuck


I like the idea.

As I’ve been working on FHIR and openEHR harmonization pretty much my entire career, here are my 5 practical cents for the short term.
Maybe in the future we manage to merge the best of both standards, who knows:

I think something like a publicly available FHIR to openEHR mapping library would really help us all. For that, I proposed adding a mapping tab for archetypes to the CKM, so we can provide these mappings as part of the model. The next step is that we need a transformation language for FHIR ↔ openEHR, and we are actively working on that. If we manage to establish this human-readable and machine-actionable language between the standards, it would significantly lower the barriers.

The resulting mapping files would then be attached to the model using the mapping section in the CKM. There are many more details to it, but having, for example, a common set of interoperable models for the EHDS would be beneficial. An IPS representation in openEHR that comes with a transformation description into FHIR (and the other way around) is an example. These transformations will also reveal specific subjects we need to work on to better harmonize the standards.


Thanks Rachel and other openEHR leaders for your leadership in this matter!


The next step is that we need a transformation language for FHIR ↔ openEHR, and we are actively working on that

Have you looked at the FML language in the FHIR Spec?

The resulting mapping files would then be attached to the model using the mapping section in the CKM.

+1. This is what I proposed in my openEHR masterclass presentation.


Good news! having worked on this issue in the past there seem to be a lot of room for alignment.
Also the proposed ISO 24305 aligning ISO 13606, HL7 FHIR, and Contsys becomes quite relevant now (as was lead by people involved in both communities)


Sure but we need more logic and also two layers of mappings.
resource ↔ archetype
template ↔ profile

Awesome :slight_smile:


We’ll have mapping tabs for both archetypes and templates in the forthcoming CKM release; this announcement and discussion is very timely I think.
The mapping tab will be an initial version also intended to spark some discussion - a lot more can be done in that direction in the future.


Very exciting news, lot’s of opportunities for win-win


Great news!! Only by combining the standards, each one for its purpose, we will have the best health data spaces :star_struck:


A great step forward towards better data availability!
Thank you to everyone who contributed to this .
Special thanks and congratulations to Grahame Grieve for his historic outreach!
Let’s learn, work and transform together!


Great news! There are challenges to everything, but we can find some synergies for the greater good of clinicians, patients and healthcare. After all, we both share the same goals!


This is wonderful news but I think it needs a clear framework between the two communities that ensure anything published from either community will “auto translate” to the other community. This shouldn’t be too difficult but requires some sound, agreed principles for ensuring appropriate and correct representation across the standard sets…


The Asia eHealth Information Network ( is excited to see this development. Do let us know when the trainings and tools will be available and we will organize our community for adoption.

Standards and Interoperability Labs (SILabs) are emerging from Asian countries. We look forward to SDOs providing free access to open standards for use by countries.


Hi Alvin

That was an announcement that we’re going to have an announcement. Then we get to do actual work… I expect it’ll be 18mojths before anything solid happens



Best news ever! It’ll be 1+1>2


An announcement to the announcement is good enough @grahamegrieve !

Long journey yes but best done together…

I would expect that generating some derived reference materials from CKM archetypes could be one of the first steps, such as having the internal archetype subsets expressed as FHIR valuesets for their consumption
Some first steps as deciding the base namespace of the openEHR artifacts for reference by FHIR logical models could help quite a bit in the homogenization of implementations


Thank you Grahame and the HL7 team for the great discussions and setting off on such a positive footing. Looking forward to making open standards easier to deploy in health systems with you.


I am so happy and proud this is becoming reality!

I look very much forward to collaboration.

Remko Schats, MD PhD MBA

1 Like

This is great news. The community welcomes this. Looking forward to the unified future or standards. As an implementor, we’ve felt the pain over the years of trying to bridge the knowledge gap amongst our teams.

1 Like