EHDS standards explained: what interoperability actually requires

There is a question that almost never gets asked in interoperability discussions, even when the people in the room know better. What happens to the data after it is exchanged? This is the gap at the heart of current EHDS standards discussions, and one of the most overlooked requirements for true interoperability.

Although FHIR profiles were validated, bundles exchanged, and transactions completed successfully, what happens next is rarely examined. And somewhere on the receiving end, a clinical data model absorbed that bundle, flattened it into a proprietary schema, and the semantic richness that took a clinical informaticist weeks to encode quietly disappeared.

The gap nobody has named 

The EHDS regulation is clear on two dimensions: governance and technical. The regulation itself defines access rights, data categories, governance frameworks, and the boundary between primary and secondary use. 

From the technical point of view, it is clear (yet still not mandated via implementation acts) to be based on exchange standards like FHIR and exchange protocols like IHE profiles defining how systems should talk to each other. They specify the transport, the syntax, and the minimum data set that must travel across the wire.

EHDS is not moving EMR data 

Before we can talk about what fills the gap, we need to be precise about what EHDS is designed to move, because a significant amount of implementation confusion starts here.

EMR data is operational in nature and serving specific clinicians, within specific systems, at specific encounters, and supporting workflows like scheduling, prescribing, ward rounds, and billing. This data is therefore typically kept local, and the European Health Data Space does not aim to replicate it across borders.

What EHDS is designed to move is something different: the clinical picture any provider needs to safely continue a patient’s care, regardless of where that care last took place. This means active and recent diagnoses, including acute conditions that a new treating clinician must know about immediately, as well as chronic conditions that define the long-term clinical context: diabetes, heart failure, dementia, frailty, and sickle cell disease. It means medications that follow a patient through transitions of care, allergies and adverse reactions that cannot safely be assumed, and procedures that change what treatment is appropriate, and care plans that define how a chronic condition is being managed across multiple providers and settings as a shared clinical foundation that makes safe, coordinated care possible across system boundaries.

The federation answer and why it doesn’t hold 

If EHDS is about moving shared care data across system boundaries, the architectural question follows immediately: where does that data live, and how does it get to whoever needs it? The most architecturally appealing answer is federation. Leave the data where it lives, in each source system, under local governance, expose a standard FHIR endpoint on every EHR, and let consuming systems query on demand. It sounds clean, sovereignty-preserving, and well-aligned with data minimisation principles.

Federation is not a naive idea. It is the rational first response to a difficult problem. And it continues to play a role in any realistic EHDS architecture. But as the primary model for EHDS delivery, it carries five structural limitations that compound at the national scale and are rarely stated plainly.

1. The patient location problem. A federated query only works if the querying system knows which endpoints to ask. That requires a patient index that maps individuals to the systems that hold their data. In most European countries, that index either doesn’t exist at the required scope, isn’t current, or covers only part of the care continuum. Without it, federation degrades into best-effort querying against a known subset, with no way to detect the gaps.
2. Exchange without persistence is structurally episodic. A FHIR bundle can be requested and acted upon, but if nothing persists it into longitudinal form, the record remains disconnected snapshots. Each encounter triggers a new query, and each query returns a point-in-time view. The medication list that evolved, the allergy that changed severity, or the chronic condition that accumulated across five years, none of it is ever assembled unless something holds it together between encounters. Patient Summary is a point-in-time snapshot, while EHDS requires longitudinal data reuse and research access that a summary document alone cannot support.
3. No shared semantic baseline. Each FHIR endpoint reflects its vendor’s internal mapping, not a shared clinical definition. Two endpoints returning data about the same patient may use different LOINC codes for the same lab test, different units, different allergy severity classifications, and both are technically valid against the profile. Data quality differences accumulate invisibly, and secondary use analytics become unreliable whenever semantics diverge.
4. Consent cannot scale without a shared layer. Every endpoint independently enforces access control, maintains audit logs, and handles opt-outs. There is no single point to apply a national consent policy, and no reliable way to enforce granular patient preferences (tied to specific data elements rather than entire documents) across hundreds of independent endpoints. As EHDS opt-out rights become operational, this is no longer theoretical.
5. Latency and availability are a clinical reality. Hundreds of live endpoints with variable uptime cannot reliably support clinical decision support. Emergency access to a patient’s medication list cannot depend on twelve upstream systems being simultaneously available, so critical data must be locally available and resilient to upstream failures.

Why FHIR alone does not solve EHDS semantic interoperability

The absence of a shared semantic baseline is a consequence of where clinical data lives and what it takes to get it out, which is what the mapping challenge makes plain. Most clinical data in Europe lives inside proprietary models, built by the EHR vendors who dominate each national market, each with their own structure, semantics, and assumptions about what a blood pressure reading or a medication order looks like in a database. Hundreds of these models exist across the EU, but none of them were designed to talk to each other.

When any of these systems expose a FHIR endpoint, they are not natively serving FHIR. They are running a custom mapping layer on top, all written by their own engineers, not standardised, not auditable by the receiving system, and almost certainly inconsistent with the mapping another vendor wrote for the same profile. There are fifty major systems across EHDS scope, they each have six exchange profiles, inbound and outbound. This means over six hundred individual mapping implementations, which are all independently maintained and, all semantically divergent. In this case, FHIR solved the syntax problem, but it did not solve the meaning problem.

The obvious objection follows: doesn’t mapping to a shared semantic layer have the same problem? Someone still needs to write those mappings. The answer is yes and that is the exact point. The question is not whether mappings exist, it is how many there are, where the effort lands, and what it produces.

Without a shared layer, every system maps to every profile it needs to support. Each mapping produces a transaction with data that crosses a boundary and is absorbed into another proprietary model on the other side. The work is repeated, fragmented, invisible, and nothing durable is created.

With a national or regional shared semantic layer, each source system maps once. That mapping is centrally governed and reused for every downstream use case: cross-border exchange, clinical decision support, research, or patient access. The N×M matrix collapses to N×1. What is produced is not a transaction but a persistent, longitudinal, semantically governed record, the shared clinical foundation EHDS requires.

What the semantic layer needs to do and what the architecture looks like 

The semantic layer must persist full clinical detail, not just the exchange minimum, captured once and available to every downstream use case. It needs to normalise semantics on the way in, so every consumer sees the same meaning regardless of origin. It must generate any exchange format on demand from the same semantic store, without separate mapping per profile. It should support longitudinal coherence across years and care settings, and attach consent to specific data elements, not document blobs. And it must enable secondary use directly, without having to reconstruct meaning from scratch for every new study.

In a well-designed national health data architecture, the interoperability layer is not a passive pipe. It is an active hub: collecting data from source systems, normalising it into a shared semantic form, persisting it as a longitudinal record, and serving it back out in whatever format a consuming system requires. Inbound collection and outbound exchange are two faces of the same function.

Every inbound FHIR transaction a medication update, a lab result, a discharge summary, is simultaneously a collection event. The hub absorbs it, normalises it, and makes it available to every downstream consumer without anyone querying the original source again.

EHDS exchange profiles are more useful than typically credited. Usually discussed as output formats, they are also a clinically significant content specification. The Patient Summary defines active problems, medications, allergies, and significant procedures, The mandatory datasets extend this across labs, imaging, prescriptions, and discharge data. When the hub uses these profiles as its inbound collection specification as well as its outbound exchange format, a structured FHIR exchange doesn’t just move data it progressively constructs the longitudinal record. Each transaction deposits a governed data element into the semantic layer. The record builds as care happens.

The same governed store that absorbed a medication event from a GP system can serve it back as an EHDS PS bundle, a FHIR resource for clinical decision support, an anonymised research extract, or a patient-readable summary without separate mapping work for each consumer.

The four-layer pattern that emerges: 

1. Source systems: hospital EHRs, GP systems, labs, pharmacies, wearables that connect via native FHIR endpoints without changing their internal data models. 
2. The interoperability hub: collects, normalises, persists, and serves systems inbound and outbound at both ends. Source systems read from and write to it, consuming applications contribute as well as query, and all of it operates on the same governed semantic store. 
3. The semantic normalisation layer: an openEHR-based shared care record at national or regional level as the persistent core. Archetypes, longitudinal compositions, consent tied to specific data elements, and full provenance. Every consumer sees the same clinical definition regardless of which source system sent the data. 
4. Consuming applications: cross-border endpoints, clinical portals, research platforms, AI systems, patient-facing tools, all fetching the data from the hub directly, receiving governed, semantically consistent data on demand.

FHIR or openEHR — the right question is what goes where 

The practical consequence of the hub architecture is significant. Instead of every system maintaining a separate mapping to every profile it needs to support (the N×M matrix) you have one mapping per clinical concept at the archetype level. Cross-border exchange, national profiles, and research extracts are all generated from the same governed semantic store. With this, the mapping matrix collapses to a hub, and profile proliferation stops being a scaling problem because the semantic foundation underneath all the profiles is stable.

This is also where the architectural difference between FHIR profiles and openEHR archetypes becomes practically important rather than theoretically interesting.

• A FHIR profile defines a minimum data set of what must be present for a valid exchange transaction. An EHDS Patient Summary or IPS profile for cross-border exchange does not need to carry every detail of a patient’s medication history; it needs to carry enough for a treating clinician in another country to act safely. Meaning is resolved at exchange time, through runtime mappings, producing a point-in-time snapshot scoped to that specific use case. FHIR’s right role is exchange, and at that job it is excellent. 

• An openEHR archetype defines a maximum data set, the full clinical definition of a concept, structured to accommodate everything that concept might need to express across every use case it serves. One archetype for blood pressure, one for a medication order, one for an allergy, each is governed by an international clinical community, independently of any vendor or implementation. The archetype is longitudinal by design, built for a patient’s lifetime, not a single transaction. When inbound FHIR data is normalised into an archetype on arrival, the exchange minimum is preserved within a structure ready to receive richer clinical detail from other sources or from direct clinical documentation. Nothing is discarded at ingestion, and nothing needs to be reconstructed later when a richer downstream use case demands it. openEHR’s right role is persistence and semantic governance. 

What EHDS standards mean for implementation across Europe

The EHDS regulation is in force and member states are making infrastructure decisions that will define the architecture of national and cross-border health data for the next decade. Those decisions will either build on a stable semantic foundation or attempt to coordinate at the exchange layer alone, relying on a mapping web that becomes less maintainable with every new profile, system, and use case added to the scope.

Evidence from national programmes across Europe is consistent: countries that already operate shared care records (where data aggregation, semantic harmonisation, and patient access are already solved problems) are the fastest to deliver EHDS compliance. Not because they are building something new, but because EHDS is the next logical extension of the infrastructure they already have. The interoperability hub pattern, it turns out, is not a future architecture. It is the architecture that has been working quietly in the most advanced national deployments for years.

The semantic normalisation layer is the foundation that makes the rest of the EHDS stack function at scale. It is the layer between exchange standards that define transport and regulation that defines access, where meaning is finally stabilised.

To understand how healthcare leaders across Europe are translating EHDS requirements into real implementation decisions, explore our stakeholder perspectives report. Built on in-depth interviews with national officials, programme leads, and technical architects, it highlights readiness gaps, key risks, and no-regret investments already shaping national strategies.