openEHR or HL7 FHIR? The Wrong Question — Don't Get Lost in Translation

Within a few months in 2026, health authorities in Wales and Australia, expert bodies in Switzerland and Austria, and a major industry vendor have all answered the same architectural question, and answered it differently. The familiar contest of “openEHR versus FHIR” frames the problem badly. The decisions that determine whether clinical data becomes interoperable lie elsewhere, and this piece tries to name them.

Hardly a month passes without a fundamental decision somewhere in Europe about how clinical data should be stored and exchanged. A few examples from this year alone. In May 2026 the Swiss data-management group in healthcare (FDMG) recommended HL7® FHIR® as the binding standard for interfaces and transactions in the Swiss Health Data Space, while deliberately leaving internal storage open. Wales made FHIR binding as early as 2023 and today operates its national data repository as a persistent, native FHIR store. Austria's telemedicine society (ÖGTelemed) calls for a vendor-neutral persistence layer and names both openEHR and FHIR as candidates for it. A technical white paper from Siemens Healthineers treats FHIR as the mandatory baseline and openEHR as an optional additional layer for research-intensive settings. And outside Europe, Australia's digital-health agency recognises both standards, assigns them separate roles, and in the same document describes the modernisation of its national record as “FHIR-native”. Alongside these determinations, clinical data repositories are being built in several places in both forms: FHIR-based, as in the Lombardy regional repository, which on the implementers' own account covers around ten million patients, and as openEHR repositories, as in Slovenia and Sweden.

Five determinations, one question, different answers. The debate as it is usually conducted obscures the decisions that carry the real weight.

At EU level the direction is already set. The European Health Data Space regulation and the cross-border exchange infrastructure refer to FHIR in regulatory and practical terms alike, and in Germany section 355 of the Social Code Book V points the same way. There is no comparable anchor for openEHR at European level. That says nothing about the technical quality of the standard, but it says a great deal about the political reality.

Germany's newest instrument shows how easily an anchor of that kind is over-read. The Act on Data and Digital Innovation in Health Care was approved by the Federal Cabinet on 15 July 2026. The departmental draft had carried a paragraph in section 386 of the Social Code Book V requiring care providers to hold and exchange health data in an interoperable format. No operative provision of the cabinet draft carries that duty, and section 386 is not amended by the draft at all. The paragraph has left a trace, though. The summary sheet and the general part of the explanatory memorandum both still say that care providers must in future hold health data in an interoperable format, and that manufacturers must make that data holding possible in the systems in use, so a reader who opens the summary first will take away an obligation the statute does not impose. What the operative text carries is an interoperability obligation in a new section 386a, addressed to the manufacturers of information-technology systems and requiring them to release a provider's patient data and grant access to it in an interoperable format, with the binding format left to a ministerial ordinance rather than named in the statute. For the architecture question, this yields less than is commonly read into it. An obligation to release data in a prescribed exchange format binds the exposure layer, not the storage model. A tender that cites such an obligation as grounds for fixing the persistence model draws a conclusion the instrument does not supply. The same objection would meet a tender that cited it the other way, for openEHR. That is how the operative provisions read here, and it is a reading rather than legal advice. The cabinet draft runs to 265 pages and names no standard anywhere in them.

A word on the frame. All of this describes Europe. That is where the regulation discussed here applies, and it is also where openEHR is most strongly represented, so the playing field is not a neutral one. On a global sample the balance would look different: the sources reviewed for this piece document openEHR deployments essentially in Europe, with Australia present at the level of policy rather than of running systems. The findings on transformation layers, and on the costs that follow from them, carry beyond Europe. Nothing here says how the two standards are distributed in markets not examined.

The consensus is larger than it looks, the disagreement smaller

Read these documents side by side and a double pattern appears. All of them treat FHIR as the standard for data exchange. On that point there is no dispute. The remaining disagreement turns on a single, narrower question: whether openEHR is the necessary, the recommended or merely the optional layer for internal storage, or whether it is dispensable altogether. The variant that used to be discussed seriously, openEHR alone for both storage and exchange, is effectively off the table.

The central question, then: if FHIR is used, is it also the store, or does openEHR sit underneath it as a persistence layer? Even that framing is too narrow. Two facts decide the shape of a system, and neither of them is the choice of a standard. Where is the clinical record written, and which model is it kept in? Cross those two and five arrangements appear rather than three.

What separates them is how often clinical content has to be translated on its way from capture to use, and it is worth being exact about what counts. Every system maps a data-entry form onto a storage structure, and every vendor answers for that mapping today. That is not the count. The count is how many separately governed clinical models the same content has to be true in at the same time, because that is where a mapping has to be written, validated by clinicians, and kept correct as both sides move. A cache or an index rebuilt from the record is not a second model. Nothing outside the system governs whether it is clinically right.

Written out, the five look like this. A record written and kept in the vendor's own model, with FHIR produced on request, crosses one boundary and keeps nothing afterwards. The same record written in the vendor's system but kept as well in a FHIR store crosses one too, and this time the result is retained, validated and reusable. That is the arrangement running at national scale in Wales and across the German data integration centres, and it can now be bought as a product in the German market. A record written natively in FHIR crosses nothing at all. A record written in the vendor's system and kept in an openEHR store, with FHIR produced from that store, crosses two. And a record written natively in openEHR crosses one, exactly as the first case does.

Two things in that list carry the argument, and they pull in different directions. The first and the last cost the same. A proprietary system with a FHIR interface in front of it and an openEHR system with a FHIR interface in front of it are indistinguishable at the boundary: same shape, same conversion, same maintenance. The case for openEHR therefore cannot be made on the exchange side at all. It has to be made where it actually lives, in modelling depth, in archetype governance, in the stability of models across decades. The second point runs the other way. Because exchange is FHIR, a record kept in openEHR must always be converted at least once, however well everything else is done, while a record kept in FHIR need not be converted at all. Only one side has room beneath a single conversion. That asymmetry follows from the regulation and not from any technical merit, and if the exchange requirement changed, the floors would swap.

The zero is worth pausing on, because it sounds like a fantasy and is not one. It does not mean a system with no internal structures, since nothing works that way. It means the clinical record of reference is FHIR, and the vendor's own structures are confined to application state, workflow, screen performance and derived indices that can be rebuilt from it. Put that way it is ordinary engineering, it can be tested at acceptance, and it is something a tender can ask of a vendor building new. No comprehensive product demonstrably meets it today. A German ministry has funded a project whose stated aim is precisely that, and at least one supplier of nursing documentation is a candidate whose published material does not settle the question either way. The other end of the table is just as bounded. A primary system capturing natively in openEHR is documented for one vendor in one national market, DIPS Arena in Norway, examined in a long-term study of a regional health authority where that vendor holds 82 percent of the market, and no comparable, generally procurable offering turned up in the German, Austrian or Swiss markets in the material examined for this piece.

Building something new is a narrower category than it sounds. It means a persistence layer for which no storage model is yet committed in production for the data in question. A project that is new in procurement terms but writes into an established repository does not qualify, and a replacement counts only for as long as its storage model is genuinely open at the point of award. The distinction carries weight for the whole argument. Where data are replicated rather than written at the point of capture, counting transformation layers discriminates less: in a secondary-use platform, and in a repository placed beside a running primary system, at least one transformation is fixed before any choice is made. Only the smaller difference in the layers that follow is still in play.

Five observations follow from that reframing, and they belong in planning documents and tenders.

1 The old division of labour is obsolete

For years the convenient formula was “openEHR stores, FHIR exchanges”. It is conceptually clear, but it has lost its force, because native FHIR repositories have closed the very gap the division of labour was built to fill. At the storage level, what separates the two standards is modelling philosophy. FHIR describes clinical content deliberately for exchange and applications. openEHR aims to capture it as completely and durably as possible. Neither is thereby unsuited to storage.

The feasibility of the FHIR-native approach is a matter of record. Wales runs a national, persistent FHIR store. The data integration centres of the German Medical Informatics Initiative structure their care data according to a shared FHIR-based core dataset, at national scale. Further cases have since been documented at comparable scale. Turkey operates a national FHIR repository, reported at some 38 billion FHIR resources for around 32 million patients. The Italian region of Lombardy runs a FHIR-based clinical data repository for roughly 10 million inhabitants. Both figures come from presentations by the implementing parties themselves, which is the weight they carry, and neither is an independent measurement. Whether any of this works better in outcome terms is not yet proven by independent studies. And feasibility is settled only as far as the documented cases reach. The cases examined for the analysis behind this piece, Wales included, run on data extracted from primary systems and transformed into FHIR, rather than on care documented natively in FHIR from the point of capture. Turkey and Lombardy are not among them. The second translation, between persistence model and exchange model, falls away. The first, between source system and target model, remains. What is demonstrated is the operation of large FHIR-native stores at national scale. What is not yet demonstrated is a primary system that writes its clinical documentation directly as FHIR resources.

2 The mapping layers are the price too rarely named

Separating persistence and exchange, by placing an openEHR store beneath a FHIR bridge for instance, carries a permanent mapping burden. It includes giving every clinical concept that crosses the boundary an adequate representation on both sides, and keeping the relation between those two representations governed as both move, plus transformation logic with terminology binding and unit conversion for each use case. Add to that loss of meaning on the round trip, changing versions on both sides, and continuous testing and validation effort. These costs rise with the number of use cases, are described as set too low in the project reports examined here, and do not disappear with better technology, because they are inherent in operating two modelling worlds side by side. Mapping is not a one-off project. It is a durable architectural decision.

Mapping is not a one-off project. It is a durable architectural decision.

Money is only part of it. Every translation of clinical data between models, terminologies or systems creates new sources of error whose consequences can reach patients directly. Interface and migration errors are among the most frequent categories of IT-related safety incident, and terminology mapping loses granularity and nuance, which is especially dangerous for medication- and allergy-relevant information. A first-order indicator, therefore, is the number of separately governed model transformations between capture and use. The more translations lie in between, the more places there are where meaning can be lost, distorted, or where a warning fails to fire. It is an indicator and not a risk score: what a given transformation actually risks depends as well on its content, direction, frequency, validation and monitoring. The GeDIG draft takes up exactly that. Section 386c forbids a manufacturer to release data in a format that prevents complete semantic reconstruction by another admitted system, and to withhold data elements that the binding requirements do not cover but that a provider needs for its documentation and archiving duties. That second prohibition reaches past the prescribed exchange format, so the answer that the profile has no field for it will not serve. The prohibition is model-neutral and binds an openEHR store exactly as it binds a FHIR one.

This is expressly not an argument against a single standard. It applies to any multi-stage architecture, including the proprietary hospital system with a FHIR layer in front. But for procurement it has clear consequences. The number of transformation layers belongs among the evaluation criteria of a tender. One question makes that criterion answerable rather than rhetorical: which structures hold the clinical content authoritatively, and can everything else be rebuilt from them? Two suppliers can look identical at the interface and answer that very differently. Every mapping, in turn, needs clinical validation by appropriately trained professionals, not merely a technical conformance run. For medication and allergy data this can be made testable: a versioned, clinically agreed test set of safety-critical cases, no unresolved loss of specified safety-critical meaning, documented handling of concepts that cannot be mapped or that remain ambiguous, clinical acceptance criteria with regression testing at every release, and monitoring after go-live. A zero error rate cannot be demonstrated, and a tender that demands one is asking for something no supplier can evidence. openEHR can bring its semantic depth to bear exactly where it counts, in primary capture. But once that data is transformed onward, the clinical validation and the responsibility for its correctness remain.

Vendor-neutral is not the same as model-independent

A promise often made for openEHR is that the data outlive the application. Store your clinical information in an open, vendor-neutral form, so the argument goes, and you are no longer hostage to a single supplier. That promise is real, but it carries a condition that is rarely spelled out.

openEHR archetypes identify each element with an internal code, an “at-code” of the form at0006. These codes do more than label structure. They can also serve as the stored value. An instance may record simply “at0007”, while the fact that at0007 means, say, “mild impairment” lives not in the data but in the archetype's ontology section. An at-code is meaningless outside its archetype. A FHIR coded value normally travels with a globally resolvable system identifier. The specification does not compel that: the system is optional, and a coded element may carry free text alone. Where it is given, the pointer to the meaning points outward, into an addressable space, rather than inward into a local model.

The consequence for procurement is concrete. Where local at-codes are used as values, the machine-processable meaning of the stored data is resolvable only against the archetype or the operational template. The data are vendor-neutral, but not model-independent. The dependency has not disappeared. It has moved from the software vendor to the model governance. And because clinical data must be retained for decades, this is not academic: the operational template in the exact version with which a record was written must still be available, and interpretable, many years later. A responsible tender therefore regulates who keeps the operational templates, in which versions, for how long, and how their availability is secured after the contract ends or a vendor fails.

Two qualifications belong here. First, the point is gradual, not categorical. FHIR is not model-free either: profiles and locally defined code systems raise the same resolution question, the difference being the reach of the pointer. Second, it is remediable. An archetype consistently bound to an external terminology such as SNOMED CT or LOINC makes the clinical meaning of a coded value resolvable without the model, which is precisely the deficit the at-code creates. It does not make the instance self-describing as a whole: structure, cardinalities, permissible-value sets and the version context still resolve only against the archetype or the operational template, so the retention duty on the template is not lifted by terminology binding. Whether the binding happens at all is a governance decision for the modelling organisation, not a property of the standard. And there is a third qualification, which cuts towards FHIR and is the sharper one. On both sides the outward pointer is optional, so what decides is not which standard was chosen but whether the binding was specified and whether anything checks it. FHIR makes that degree of obligation explicit, and it does so in four graded steps. Required allows only codes from the named value set. Extensible requires one whenever that set holds a suitable representation of the concept, and permits another code where it does not. Preferred and example oblige nothing at all, and an element left at example is fully conformant FHIR that enforces nothing. Strictness is not a virtue in itself, though: where a concept space is deliberately open, extensible is the fitting setting and required would be the wrong one. openEHR has the mechanism, an optional term-binding section in the archetype, but no strength to go with it, so a template cannot say whether a consumer must honour a binding. That gap is recognised inside openEHR: in 2020 its specifications committee proposed adopting the same four strengths for archetypes, naming the FHIR model as the template, and the thread has not visibly closed since. None of this makes openEHR a closed standard. It does mean that “vendor-neutral persistence” has to be examined for what it guarantees.

3 The evidence is thin on both sides

Choosing a standard does not by itself guarantee interoperability, because conformance and interoperability are two different things. Two systems can follow the same standard and still fail to work together. The question that matters is which standard delivers interoperability at scale, and on that the evidence is weak on both sides.

For openEHR there are only a few robust studies, and the proof of FHIR's effectiveness at national level is likewise insufficient. This symmetry holds, with one qualification. For the breadth of FHIR use in research, three systematic reviews now exist. They document FHIR in fields such as oncology, genomics and infectious disease, used for standardisation, primary data capture, analysis and cohort recruitment as well as for exchange. As a blanket statement, then, a claim frequently advanced in the debate is no longer tenable: that FHIR is structurally too shallow for research-grade clinical modelling. That body of evidence has its limits. The three reviews differ in method, and only one of them was registered in advance, which makes it the methodologically strongest. None of them includes openEHR as a comparator, none measures effectiveness, and the authors of that strongest review concede publication bias. Comparable systematic reviews for openEHR are absent.

A count of the scholarly literature points the same way. Publications naming FHIR overtook those naming openEHR around 2016 and reached roughly ten times the annual figure by 2024, while openEHR's output stayed on a plateau. This measures research attention and momentum, not effectiveness, and it partly reflects the regulatory mandate rather than any clinical superiority. But taken together with the reviews, it gives FHIR a real, decision-relevant lead in adoption, implementation density and ecosystem maturity. None of this makes openEHR technically inferior. The decisive differences today lie less in the capabilities of the standards than in their regulatory environment, their spread, and the architectural costs that follow.

A word on Catalonia

No discussion of openEHR in Europe gets far without Catalonia, the most-cited regional platform built on the standard. The procurement history is well documented and shows that this path is organisationally and legally viable. A medium-sized European region can choose openEHR strategically, run the tenders and apply the boundary principle in practice. That result stands, and it should not be waved away.

What Catalonia does not yet demonstrate is effectiveness. No independently verified or peer-reviewed source documents the concrete outcome data: active institutions, records processed, measured interoperability gains. The most substantial account is a book chapter written by the responsible actors themselves, and its first author is now CEO of openEHR International. That does not devalue the facts it reports, but it moves the source from independent evidence into institutional self-presentation, and any argument that cites Catalonia as proof of superiority should say so. Catalonia shows that the openEHR route is passable. Whether it arrives is a question the available evidence cannot yet answer.

4 What decides is the regulation, not the evidence

If the evidence does not separate the two standards, what does? The answer is uncomfortable for anyone waiting for a better proof: the regulatory mandate. FHIR is anchored in the European Health Data Space, in the cross-border infrastructure and in section 355 of the Social Code Book V, whereas openEHR infrastructures require additional transformation layers that are neither certified nor standardised Europe-wide. This mandate creates scale, market pressure and planning certainty. It is not, however, proof of effectiveness. Architecture decisions today are therefore not taken on technical grounds alone. They are pre-shaped by regulation.

The distinction cuts both ways. A mandate is not evidence. It is also not a side issue. Connectivity to the European framework and national requirements, planning certainty and broad, increasingly mandated market adoption are legitimate grounds that favour FHIR, independent of the effectiveness question. A procurement decision may rest on them, as long as it does not present regulatory certainty as clinical proof.

5 The real brake is market inertia

Even the right, prescribed standard achieves little on its own, because the actual work begins only after the standard has been chosen: with the consistent application of profiles, with terminology binding, and with conformance testing. Without binding profile depth, meaning the fields, terminologies and value ranges fixed precisely in the profiles, the pattern of the past four decades of HL7 v2 repeats itself: standard-conformant and still not reliably interoperable. A German instance shows how concrete that gets. The core-profile working group of the Interop Council recorded in 2025 that Patient.gender is mandatory in the binding hospital-interface profiles and prohibited in the e-prescription profiles, on data-protection grounds, although both are conformant FHIR and both rest nominally on the same national base layer. A count made for the analysis behind this piece qualifies that picture, and it does so in the German work's favour: of 2,159 terminology bindings the German profile families set themselves, 78.5 percent carry the strength required and under 2 percent example. Where they bind, they bind strictly. The weaker case is the one that would need it most, because across the profiles for medication and allergy data the required share is 53.6 percent. Part of that group fixes its codes outright rather than binding them: twenty-two of the thirty-seven profiles that declare no binding at all fix values instead, and only four carry neither a binding nor a fixed value nor a slice. Where such a constraint sits on a coded element it is stricter than a binding, because it admits one code rather than a set, and how many of them do is not something this count establishes. What the count does not establish is whether the weaker distribution is clinically consequential in any individual profile. That would take an element-by-element reading of the bindings and of the constraints inherited from the base profiles, and it was not done.

The deeper obstacle is structural. Established system vendors have no incentive to give up their proprietary data models as long as customers do not contractually enforce data portability. One lever would be a profiled FHIR exposure obligation for all vendors, of the kind the European framework and section 355 already set in motion, but only if profile depth, terminology binding and conformance tests support it. This inertia is not neutral. It hits openEHR even harder, because introducing openEHR as an internal storage core demands deeper intervention in existing systems, presupposes a rare double qualification, and meets a smaller vendor market.

The models are converging, and the tooling should follow

A quieter development is changing the tone of the debate. openEHR International and HL7 have begun to work together, most visibly at their joint meetings in Amsterdam in 2025 and Dublin in 2026. A concrete, testable result already exists. In a recent HL7 FHIR implementation guide, an openEHR archetype appears alongside a FHIR Logical Model, as an informative, additional source of clinical guidance, with the Logical Model retaining the authoritative status. A recurring fear in the FHIR community, that archetypes would be declared the official route for domain models and displace FHIR's own Logical Models, is not borne out by that artefact. The convergence sits at the level of model publication, and nothing in the artefact points to displacement.

A corollary from the FHIR-leaning community points in the same direction. It is an informal position rather than a documented finding, and it should be read as such. On that reading, FHIR Logical Models are functionally adequate for domain analysis, and the gap relative to openEHR archetypes lies in tooling rather than in modelling depth. The corollary names two instances: no graphical rendering of Logical Models in common use, and no diagram-based authoring tool. Checked against the published artefacts, both overstate the case. The EHDS Logical Information Models guide renders every model through the ordinary FHIR publication toolchain as a structured table carrying cardinalities, data types and bindings, so a rendering in common use does exist. And ART-DECOR already serves clinically authored datasets and use-case transactions as FHIR logical models through its FHIR endpoints, which is the conversion the corollary asks for, arriving from a different source notation. What remains open is narrower: authoring by drawing, and a route back from models built outside the tool. Part of the greater visible appeal of archetypes still rests on presentation and tooling rather than on substance, and the remedy is in FHIR's own hands.

The next step

The question “openEHR or FHIR?” therefore falls short. Other questions lead further. Which architecture fits which purpose, care delivery or research-driven secondary use? Can one still afford separate capture for secondary use at all? And how does one get to what matters: portability, profile depth and tested conformance? The standard is the necessary condition. It is never the sufficient one.

Movement is already under way at exactly these points. With section 355, the telematics infrastructure, and the profiling and conformance work of the national digital-health agency, Germany has already laid many of the important building blocks, and the legislator continues to extend them. The task is to deepen what has been achieved, not to start over: binding profiles, clean terminology binding, and robust testing regimes. Those three are not a separate wish list. They are the enforcement mechanism for the self-description problem set out above. A required binding, in a published and versioned profile, resolved against a terminology server and exercised by a validator at every release, is what turns “the pointer leads outward” from a property of a standard into a property of a running system. That is demanding work, and it is the work that turns a shared standard into interoperability in practice. Those who pursue it consistently need no longer worry about the choice of an acronym.