EHDS

EHDS-Ready FHIR Backend

EHDS puts FHIR at the center of European EHR exchange and adds a secondary-use regime that operates on top of it. Backends that already speak FHIR R4 are a profile-mapping exercise away from EHDS-readiness; backends that store data in proprietary schemas face a migration under deadline pressure.

Read the authorization docs Book an EHDS architecture review

What you can build

EEHRxF alignment without schema migration
Standard FHIR R4 storage maps to the European Electronic Health Record Exchange Format through profile validation, not through ETL into a new database.
Secondary-use scoping inside the access boundary
Roles for secondary-use consumers (researchers, public health bodies, market authorization holders) sit alongside primary-use roles in the same access model.
Cross-border integration without parallel infrastructure
MyHealth@EU traffic and bilateral integrations run against the same backend through scoped service accounts.

What you get out of the box

Capability With Fire Arrow Building it yourself

EEHRxF profile alignment Standard FHIR R4 storage with profile validation. EEHRxF and IPS (International Patient Summary) projections are configuration rather than schema migration. Custom mapping layer from internal schema to EEHRxF, maintained as the format evolves.

Primary use access model Identity-resolved access for patients, clinicians, and treatment-purpose service accounts. Audit covers each access. Custom access layer per integration partner.

Secondary use access model Separate roles for secondary-use consumers with property filters and search-parameter blocklists. Same access model, different validators. Parallel data warehouse with its own access model and its own audit pipeline.

Cross-border identity OIDC integration with national IdPs supported. Identity mapping resolves the cross-border subject to a FHIR identity in the local deployment. Custom identity resolution per country, plus token translation logic.

Audit for cross-border access Same audit log covers domestic and cross-border access. Each entry includes the resolved identity and the originating country where applicable. Audit reconciliation across multiple integration points.

Operational scope changes over time Adding a new EHDS-integration role is a rule-set change. The data layer does not move. Schema or pipeline changes per new integration scope.

Who this is for

European digital health teams whose products will exchange data with national EHRs, interact with health-data access bodies, or integrate cross-border under the EHDS regime.

Clinical applicability

A telemedicine platform serving multiple EU countries needs to expose patient summaries to the EEHRxF, accept data from national EHRs, and respond to secondary-use access requests routed through national health-data access bodies.

What EHDS introduces

EHDS (Regulation 2025/327, applying in stages from 2025 onward) sets up two regimes on top of national health systems. The primary-use regime obliges member states to make health data accessible to the patient and to authorized treating professionals across borders, in the European Electronic Health Record Exchange Format. The secondary-use regime sets up health-data access bodies in each member state that route research, public-health, and policy access requests through a defined process.

For backend operators the practical question is whether the data layer can serve both regimes from the same deployment. EHDS does not require a new database; it requires that the data the deployment holds can be expressed in the EEHRxF and accessed under the access rules each regime defines.

Why FHIR-native deployments have a head start

EEHRxF is built on FHIR R4 with European profiles layered on top. Backends that already store data as FHIR R4 only have to validate against the right profiles when projecting into EEHRxF; they do not have to translate from a relational schema or a custom document model.

Fire Arrow stores FHIR R4 with profile validation, so EEHRxF projections, IPS exports, and national-format exchanges become configuration. Adding a new export shape is a profile-validation configuration plus a rule for the consumer that needs it.

Secondary use without parallel infrastructure

The classic answer to secondary-use access is to copy the data into a separate warehouse with its own access model. This works but doubles the surface area and complicates the auditability story (which copy is authoritative, what gets retained where).

An alternative that works on a FHIR-native backend is to give secondary-use consumers their own roles, with property filters that strip identifiers, search-parameter blocklists that prevent reverse-engineering, and rate limits that align with the access body's own policies. Same database, same audit, different access model. The secondary-use traffic stays inside the boundary the primary-use access already defends.

Related docs

FAQ

Is Fire Arrow EHDS certified?

EHDS does not certify components; it sets obligations on member states and on data-holders inside them. Fire Arrow gives the data-holder the architectural primitives that make EEHRxF projections, secondary-use access, and cross-border integration tractable. The certification regime under EHDS targets MyHealth@EU nodes and health-data access bodies, not backend components.

When does EHDS take effect?

EHDS applies in stages from 2025 onward, with priority categories of data (patient summaries, prescriptions, lab results) coming first and additional categories phased in through 2031. The technical-architecture work that EHDS requires is best done before the deadline rather than in response to it.

Does EHDS change my GDPR obligations?

EHDS sits on top of GDPR rather than replacing it. Lawful basis, purpose, and data-subject rights remain GDPR obligations. EHDS adds the cross-border-exchange obligations and the secondary-use access regime.

Can secondary-use consumers see identifiable data?

Only if the access body's process and the data-holder's policy permit it. Property filters strip identifying fields by default for secondary-use roles. Linkability across resources is controlled with the same rule set.

Where does cross-border data live?

In the data-holder's deployment, exposed to MyHealth@EU traffic through scoped service accounts. Fire Arrow does not route cross-border data through a vendor backplane.