Within a few months in 2026, health authorities in Wales and Australia, expert bodies in Switzerland and Austria, an expert panel commissioned by the Spanish Ministry of Health, 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”.
The newest of these determinations reaches furthest, and it points the other way. A Delphi consensus commissioned by the Spanish Ministry of Health recommends openEHR in 2026 as the most suitable standard for the national digital medical record, with FHIR at the exchange layer and a mapping to be defined together with the clinical knowledge model. It is the weightiest institutional backing the openEHR side holds to date. Its limits travel with it: the paper calls its own recommendations not evidence-based, its authorship overlaps openly with the leadership of openEHR International, and it is a recommendation to the ministry rather than an adopted strategy.
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.
Six 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 for the data exchanges examined here is clear. The European Health Data Space implementation work and the cross-border exchange infrastructure use FHIR, and in Germany section 355 of the Social Code Book V points the same way. There is no comparable European regulatory anchor for openEHR. This says nothing about the technical quality of either standard, and it does not prescribe the internal persistence model. It does, however, shape the political and procurement environment.
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 exchange standard for the data exchanges they address. The remaining disagreement turns on a narrower question: whether openEHR is the necessary, the recommended or merely an 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 is answered by naming a standard alone. Where is the clinical record written, and which model holds it authoritatively? Crossing these questions yields five useful architectural ideal types rather than three. They cover the principal combinations, not every possible system design.
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 and held natively in FHIR needs no governed conversion only where its authoritative representation is compatible with the required exchange profile. 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 last arrangements have the same minimum conversion count and can produce indistinguishable conformant payloads at the exchange boundary. They are not otherwise economically or architecturally equivalent. The case for openEHR therefore has to be made where it actually lives: in modelling depth, archetype governance and the stability of models over time.
The second point runs the other way. Where the required exchange representation is FHIR, a record held in openEHR must cross at least one governed cross-standard boundary. A record held in FHIR can avoid that boundary where its representation is compatible with the required exchange profile. FHIR profile differences and source-system mappings may still require transformation and validation. The asymmetry follows from the specified exchange target, not from the intrinsic technical merit of either standard.
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 one supplier of nursing documentation states, on enquiry, that its products write clinical content directly as FHIR resources through the FHIR client, that the repository is interchangeable wherever FHIR R4 is supported, and that eight hospitals run on a third-party repository on that basis. That is the vendor's own account of its own architecture, it concerns a point-of-care documentation system rather than a complete primary clinical record, and it has not been independently verified.
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.
The old division of labour is no longer the only option
For years the convenient formula was “openEHR stores, FHIR exchanges”. It remains a viable architecture, but it is no longer the only standards-based option because persistent FHIR repositories can now occupy the storage role as well. 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.
Independent studies of effectiveness are still missing, 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.
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 the risk of losing 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.
Coding.system carries an absolute URI and points directly at a named code system, while not itself being mandatory.A third qualification cuts towards FHIR, and it 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.
The evidence is thin on both sides
Choosing a standard does not by itself guarantee interoperability, because conformance and interoperability are separate properties. Two systems can follow the same base standard and still fail to work together because their profiles, versions, terminology bindings or process assumptions differ. The question is therefore not which standard delivers interoperability by itself, but which architecture, profiling regime and governance arrangement makes a defined exchange work reliably. On comparative outcomes and lifecycle cost, the evidence remains 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 these three FHIR-focused reviews includes openEHR as a comparator, none measures effectiveness, and the authors of the strongest concede publication bias.
A fourth review published in 2026 considers FHIR, OMOP-CDM and openEHR together. It includes 99 studies, only eight of them using openEHR, and 90 of the 99 concern secondary rather than primary use. It compares published applications, not lifecycle costs, clinical outcomes or installed products. Its own finding that source-data coverage is rarely reported prevents a comparison of how much meaning the standards preserve in transformation.
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.
Regulation changes the architectural calculation
The comparative evidence does not establish that either standard produces better outcomes. Regulation nevertheless changes the architectural calculation. For the data exchanges examined here, FHIR is anchored in the European framework, the cross-border infrastructure and section 355 of the Social Code Book V. An openEHR persistence layer must therefore cross an additional standards boundary before those FHIR exchanges, whereas a compatible FHIR persistence model can avoid it. This direction creates scale, market pressure and planning certainty. It is not proof of effectiveness, and it does not prescribe the internal storage model.
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.
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.
Across 2,996 StructureDefinitions, the German profile families declare 2,399 bindings of their own. Of these, 79.4 percent are required and 1.9 percent example. Where they bind, they generally bind strictly.
The safety-relevant subset contains 94 Medication and AllergyIntolerance resource profiles. Among the bindings declared directly in those profiles, the required share is 53.7 percent. That does not establish weaker overall constraint or clinical consequence: 38 of the 50 profiles without an explicit binding fix values instead, 46 use slicing, and inherited bindings were not resolved. Only an element-by-element clinical assessment could support a safety conclusion.
The German conflict is not unique to Germany. A published method applied to US Core and the International Patient Summary found that the examined Patient, Condition and medication examples were not unconditionally compatible, even though sender and receiver could each conform to their own implementation guide. That constraints can contradict each other belongs to profiling. Detecting them is a compatibility question, and because FHIR states its constraints formally, it can be computed rather than read. Deciding whether a conflict is prevented, accepted, mapped or resolved is a governance question.
The same principle applies on the openEHR side. A peer-reviewed survey received responses for eleven production-capable repositories and found different combinations of AQL, REST API support, serialisation formats, reference-model versions and EHR Extract support. The authors concluded that these differences impede straightforward interoperability and called for a conformance-testing framework. The survey records vendor declarations rather than independent test results, but it is enough to show that implementation of one open specification does not itself ensure portability between products.
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.
Transparency note. The author is CEO of HL7 Deutschland, a Senior Expert and Community Event Manager at HL7 Europe, and a member of the ART-DECOR Expert Group. The assessment presented here is his personal professional view as an interoperability expert and does not represent an official position of HL7 Deutschland or HL7 Europe. HL7® and FHIR® are registered trademarks of Health Level Seven International. It aims at even-handedness and states the limits of the evidence explicitly on both sides. It is the condensed version of a full, source-based analysis of the relationship between openEHR and HL7 FHIR in Europe. The full analysis is published here as a set of six documents with a guide in front of them, from a one-page decision note to the evidence annex, with all references and case material.
A note on method. This piece and the analysis behind it were prepared with the assistance of a large language model, used for literature search, source collation, drafting, and machine-run consistency and readability checking across versions. The editorial pass was made after the findings were fixed and did not change them. Not all of the cited literature was read in full. For part of it a model-produced summary extract was the working basis. That extract accompanies the document set, whose source ledger records source by source which basis applies. The assessment, the weighting of the evidence and the conclusions are the author's own, as is responsibility for any error.
Dr Kai U. Heitmann has more than 30 years of experience in communication, standardisation and integration in healthcare. From May 2019 to the end of 2021 he contributed that experience as Director Interoperability at the Health Innovation Hub, the think tank for digitalisation in healthcare founded by the German Federal Ministry of Health.