Two international communities have been working on exactly that problem for the last twenty years, from opposite directions. Their work goes by the acronyms FHIR and openEHR. This is a short tour of both, and of why – after running in parallel for so long – they are finally starting to converge.

The problem, in one picture

A medical record is not a single document. It is thousands of small facts piled up across decades, by different people working in different software, with their own conventions and their own shorthand. Often in different countries, too. When someone asks for “your record,” what actually arrives, if anything, depends on the weakest link in a long chain of software that was never designed to cooperate.

Standards are the agreement that fixes that. They are a set of detailed rules that make a medication entry written in Berlin recognisable on a screen in Boston, and a laboratory result from a research hospital intelligible to a general practitioner’s PC. The two this post focuses on are FHIR and openEHR.

FHIR: the plumbing for moving records around

FHIR – pronounced “fire” – stands for Fast Healthcare Interoperability Resources. It was started in 2011 by an Australian developer named Grahame Grieve, working with HL7, the organisation that has been publishing health data standards since the 1980s. FHIR’s big bet was that health data should be treated the same way the modern web treats everything else.

If you have ever used an app that logged you in with Google, you have used the underlying protocols FHIR relies on. A FHIR server speaks plain HTTP – the protocol your browser uses – with its data shaped as JSON, the format most web APIs use today. A clinic’s system can ask, “give me the patient with this identifier,” and receive back a predictable, machine-readable object: a Patient resource, with a name, a date of birth, and pointers to their Conditions, Medications, and Observations.

This style made FHIR wildly popular. By 2025, 71% of countries surveyed reported FHIR in live use for at least some cases, and 73% of national regulations for electronic health data now either mandate or recommend it. In the United States, certified health record systems are legally required to expose a FHIR API so patients and the apps they choose can read their own data. A closely related specification called SMART on FHIR defines how a patient app can securely “plug in” to a hospital’s record with the patient’s consent.

FHIR’s sweet spot is the moment data moves: between hospitals, from a lab to a GP, from a health system to an app in a patient’s pocket. Its weakness, which its designers are open about, is that it was never designed as the place where a lifelong record actually lives.

openEHR: the grammar for keeping records meaningful

openEHR – pronounced “open-air” – comes at the problem from the opposite direction. Its roots go back to a European research project called the Good European Health Record, which began in 1992 under David Ingram at St Bartholomew’s Medical College in London and formalised as the openEHR Foundation in 2002 around the work of Thomas Beale, Sam Heard, and their community. Where FHIR is preoccupied with moving data, openEHR is preoccupied with keeping it intelligible for decades.

The key idea is that clinical concepts are too rich to be written permanently into software. “Blood pressure” is a deceptively simple phrase – in real medicine it involves cuff size, posture, which arm the reading was taken from, the time of day, whether the patient had just climbed stairs. Baking all of that into the database of a hospital system guarantees that a programmer will be needed every time medicine evolves.

openEHR separates those two layers. Underneath is a small, stable technical model (the Reference Model) that software engineers build once. On top of it sit thousands of clinical models called archetypes: formal, community-reviewed definitions of things like Blood pressure, Medication order, Allergy, authored by working clinicians. Archetypes are curated in a global repository called the Clinical Knowledge Manager and published under a Creative Commons licence. A hospital in Norway and a hospital in New Zealand can use the same archetype for a pain assessment, translated but semantically identical.

The payoff is that an openEHR record outlives the software that wrote it. Vendors and archetypes can both be replaced underneath, and the data they once described carries on being queryable through the change. That property, durability across software churn, is what a lifelong patient record actually needs.

Where they overlap, where they diverge

For newcomers, the two standards can look like competitors. They are both international, they are both open, they both have working groups, annual conferences, and t-shirts. But their centres of gravity are different.

openEHR is strongest as the system of record: the place where clinical data lives, gets versioned, and stays queryable over time. Where its specifications are unusually careful is in how a piece of information keeps its meaning after the clinician who entered it has retired.

FHIR is strongest as the system of exchange – the API that moves a slice of a record between a source and a destination, today, over the web. Its specs put their effort one layer up: turning a clinical fact into something a modern developer can fetch, filter, and render.

The overlap is real: both can describe a medication, a diagnosis, an observation. Where the two diverge is in what the description is for. A FHIR MedicationRequest is built to be handed cleanly between a server and a client today. An openEHR Medication order archetype is built so the record entered today still makes sense when none of the people who wrote it are around to clarify.

Most mature deployments no longer choose. A common pattern, informally called the “dual stack,” is to store data in openEHR for persistence and expose it through FHIR for exchange. An open, vendor-neutral specification called FHIRconnect, with an open-source reference implementation, now defines how to translate between the two in both directions.

The quiet convergence

For a long time the two communities ran in parallel, occasionally in tension. That is changing in public.

In June 2025, HL7 International and openEHR International held a two-day joint workshop in Amsterdam, the first of its kind at that scale. They emerged with five agreed areas for collaboration, dedicated joint working groups underneath them, and a commitment to reconvene each year. The follow-up, billed as “Converge and Collaborate,” is in Dublin on 12–13 May 2026.

Why now? Most of all, regulation – specifically the European Health Data Space Regulation, which entered into force in March 2025 and will require interoperable electronic health record systems across the EU. Patient Summaries and ePrescriptions are singled out as priority categories for cross-border exchange, and several national and regional programmes in Europe already store data in openEHR and expose it through FHIR. When both policy and practice settle on the same dual stack, the people writing the specifications start talking.

Underneath that, plain economics. Every implementer who needs both standards needs the mapping between them. Doing the work once, in public, saves the rest from rebuilding it privately.

Why this is relevant to Plotline

Plotline is an upcoming personal health record, one that belongs to the person it describes and moves with them. The hardest part of building it sits outside Plotline itself: the underlying record format has to be a standard the rest of the world can also read. Every part of making it real depends on work that Plotline does not, and should not, have to do alone.

That is what “standards-driven” means in practice. It does not yet commit Plotline to a specific stack – that implementation is deliberately an open question, and will stay open while the right pieces keep being built. What it commits to is leaning on the work the international communities are already doing: the archetypes clinicians curate in the Clinical Knowledge Manager, the resources HL7 formalises, the converters the joint working groups publish. Each piece, as it lands, shortens the distance between the present (where your record sits fragmented across institutions) and the world Plotline exists to bring about.

The encouraging part is that openEHR and FHIR are no longer moving in different directions; they are converging. A patient-owned record designed today rests on firmer ground than the same project would have five years ago.