EHDS Secondary Use: Architecture for Health Data Access in 2026

A Spanish hospital chain asked its EHR vendor in February 2026 a simple question: if a German oncology researcher receives a data permit under the European Health Data Space to study a cohort of 12,000 colorectal cancer patients, can the system honor it? The vendor returned a 14 month roadmap. The regulation gives them until 26 March 2029 for secondary use. Most health software teams have not started.

Regulation (EU) 2025/327, the EHDS Regulation, entered into force on 26 March 2025. It is the single largest reshaping of how health data flows in the EU since GDPR. Primary use obligations (patient access to their own records, cross-border exchange via MyHealth@EU) apply from 26 March 2027. Secondary use obligations (research, public health, policy-making, regulatory) apply from 26 March 2029 for most categories, with extensions to 2031 for certain genomic, wellness, and clinical trial data.

This post is for health software architects, DPOs, and product leads who need to plan a multi-year EHDS roadmap now, without breaking GDPR or patient trust along the way. It builds on (rather than restates) the HIPAA and GDPR compliance baseline already covered elsewhere, and goes deeper on the parts that are EHDS-specific: data holder obligations, the Health Data Access Body (HDAB) interaction model, and the FHIR R5 mapping problem.

What EHDS actually is, and why HIPAA-style thinking fails

EHDS is not a privacy law. GDPR is the privacy law. EHDS sits on top of GDPR and creates two new things: a primary use right (patients can read, control, and port their records across the EU) and a secondary use regime (researchers and authorities can request structured access to anonymized or pseudonymized health data through a formal permit).

The mental model that breaks teams is treating EHDS as HIPAA Security Rule plus consent management. EHDS is closer in spirit to PSD2 open banking: it forces data holders to expose structured, machine-readable health data through standardized interfaces, with access mediated by a regulated authority. There is no equivalent in US health regulation. The closest parallel is the ONC Cures Act information blocking rules combined with TEFCA, but EHDS goes further: it makes data holders affirmatively responsible for serving permitted secondary use requests, not just refraining from blocking access.

The practical consequence: if your platform stores health data above the SME threshold (Article 2(2)(y) of EHDS, with reduced obligations for entities under 10 employees and EUR 2 million turnover), you are a data holder. That includes EHR vendors, hospitals, GPs, registries, biobanks, telehealth platforms, and a growing list of consumer health and wellness products once a delegated act brings them in scope.

The 2027 and 2029 clocks: what to build first

The temptation is to skip primary use and start with secondary because the secondary deadline is two years later. Resist this. Primary use is the harder engineering problem and it underwrites the secondary use model.

Primary use requires:

• Patient access to their own electronic health data in the European Electronic Health Record Exchange Format (EEHRxF) for priority categories: patient summary, ePrescription, ePrescription dispensation, laboratory results, imaging reports, imaging studies, discharge reports.
• Patient ability to add data, restrict access, and obtain a log of accesses.
• Cross-border exchange via the MyHealth@EU infrastructure, with member-state National Contact Points for Health (NCPeH) acting as the bridge.
• Mandatory adoption of the EEHRxF for the priority categories.

This is roughly a 24 to 30 month build for an EHR with an existing FHIR R4 surface, longer if the underlying data model is HL7 v2 or a proprietary schema. The 2027 deadline is real.

Secondary use stacks on top: once data is in EEHRxF for primary use, the same data is the source for HDAB-mediated permits. Teams that build secondary use first end up with two parallel data pipelines, which doubles operational cost.

The build order is:

1. 2026: FHIR R5 facade over the existing data store, with the IPS profile and EU x-IPS extensions for priority categories.
2. Late 2026 to 2027: patient access portal, MyHealth@EU connector, NCPeH integration in your primary member state.
3. 2027 to 2028: consent and opt-out ledger (Article 48a), audit log surfacing to patients.
4. 2028 to 2029: secondary use pipeline: pseudonymization service, secure processing environment integration, HDAB permit handler.

FHIR R5 and the EEHRxF: mapping your existing schema

HL7 FHIR R5 was published in March 2023. The EEHRxF is being defined through implementing acts and is expected to converge on FHIR R5 with mandatory profiles for the six priority categories. The International Patient Summary (IPS) implementation guide, in particular the EU x-IPS profile, is the current closest approximation.

Two practical problems hit every team:

• Legacy data is rarely clean enough. Allergy fields recorded as free text, lab results without LOINC codes, prescriptions referenced by national drug code (BfArM PZN, AIFA AIC, ANSM CIS) without SNOMED CT bridge. The mapping work is 60 to 80% of the effort.
• FHIR R5 broke some R4 patterns. Profiles, references, and search parameters changed in non-trivial ways. Existing FHIR R4 servers do not upgrade in place.

The realistic architecture is a FHIR facade pattern: the source of truth stays in your existing system (EHR database, lab system, PACS), and a FHIR R5 service reads on demand, applies the EEHRxF profile, and serves the response. The facade owns the mapping logic, the terminology bindings (SNOMED CT, LOINC, ICD-10, ATC), and the validation. The underlying source system stays mostly untouched.

Validation is the part most teams underestimate. The EU x-IPS validator (built on HL7 FHIR validator with EU value sets) will reject responses that have, for example, a free-text allergy without a SNOMED CT code, or a medication without an ATC code. Validation must run in CI and at runtime.

Designing for the HDAB: data permits, pseudonymization, secure processing

Each member state designates a Health Data Access Body. A researcher requesting secondary use data submits a permit application to the HDAB. The HDAB evaluates the request, identifies which data holders hold relevant data, and issues a permit listing the dataset, the purpose, the duration, and the safeguards.

Data holders do not send raw data to the researcher. They prepare a pseudonymized dataset and load it into a secure processing environment (SPE) operated by the HDAB or an authorized provider. The researcher works inside the SPE. They can export aggregated results, not row-level data.

The architecture this implies for a data holder:

• A dataset metadata catalogue describing what data is available, in what format, with what coverage. The HDAB consumes this to evaluate permits.
• A pseudonymization service that takes a permit, identifies the cohort, replaces direct identifiers with pseudonyms generated under a permit-scoped key, and packages the result in a structured format (FHIR Bundle, OMOP CDM, Sentinel CDM, or a tabular export per the HDAB spec).
• An SPE delivery channel: typically a regulated SFTP or object store endpoint operated by the HDAB or a national infrastructure (Finnish Findata, French HDH, German FDZ).
• An audit log capturing every permit, every dataset prepared, every export. Retained for at least 10 years under the regulation.

The pseudonymization service is the part where most teams will reinvent the wheel. Off-the-shelf options exist (ARX, Aircloak, Privitar) but most current health data infrastructure uses bespoke pipelines. Building one well, with separation of duties between the pseudonymization key custodian and the data engineer, is a quarter of focused work.

Opt-out plumbing under Article 48a without breaking analytics

Article 48a, added during the trilogue, allows member states to introduce a patient opt-out for secondary use. Several member states (France, the Netherlands, Germany) have signaled they will implement an opt-out by default. Others (Finland, Estonia) will likely default to opt-in for sensitive categories.

For a data holder, this means the cohort selection in the pseudonymization pipeline must respect a per-patient opt-out flag at query time. The opt-out is dynamic: a patient can change their preference, and the change must take effect for future permits within a defined window (typically 30 days).

Two architectural choices to make early:

1. Where the opt-out lives. Member-state central registry (the EU regulation allows this), or each data holder maintains its own. Most member states will operate a central registry. Data holders should fetch the opt-out status at cohort-build time, not store it locally.
2. How opt-out interacts with existing research. If a patient opts out today, must a study already running on their data exclude them retrospectively? The regulation does not require retroactive exclusion, but the contract with the researcher (via the HDAB permit) sets the rule. Build for both possibilities.

Analytics teams worry that an opt-out wave will erode dataset utility. Empirically, the Finnish Findata system has run with an opt-out model since 2019 and reports under 3% opt-out rates. The German GenomDE pilots have seen similar numbers. Build for higher rates (10 to 15%) but the operational impact is unlikely to be catastrophic.

Wellness apps and the data holder trap

Article 2(2)(y) brings wellness apps and medical devices that record relevant health data into scope as data holders when they cross a threshold defined by delegated acts (expected late 2026 to 2027). The threshold is likely to be set by user base size, regulatory classification, or data category sensitivity.

A consumer health app today that stores blood pressure readings, sleep cycles, or menstrual cycle data is on track to become a data holder. The implications:

• FHIR R5 export of stored health data on request.
• Patient access portal supporting log of accesses.
• Cohort access capability for HDAB permits.

Building these for a consumer app retroactively is expensive. The pragmatic move in 2026 is to specify the architecture now (FHIR R5 internal data model, opt-in consent surface, structured logging) even before the delegated act lands. The technical work is the same. The compliance overhead is much smaller if the foundation is in place.

A reference architecture for an EHDS-ready platform

The end-state for a mid-size data holder looks like this:

• Source system (EHR, lab, PACS, registry) remains the operational system of record.
• FHIR R5 facade reads on demand, applies EEHRxF profiles, validates against EU x-IPS.
• Consent and opt-out service stores the patient preferences, fetches member-state opt-out status, exposes a check API to the cohort builder.
• Audit ledger captures every read, every permit, every cohort, every export. Append-only, retained 10 years.
• Pseudonymization service operates under a permit-scoped key, generates cohort exports in the HDAB-required format.
• MyHealth@EU connector for cross-border primary use.
• NCPeH integration for member-state level routing.

This is not a small architecture, but it is composable. Building the FHIR R5 facade and the audit ledger first opens the door to every downstream EHDS capability without committing to the full stack at once.

For a 2026 quarterly plan, the achievable scope is the FHIR R5 facade for at least two priority categories (patient summary, ePrescription is the usual starting pair), plus the audit ledger and the consent service. That foundation makes 2027 to 2029 deadlines reachable. Teams that wait until 2028 to start are not going to make 2029.

A note on terminology because it trips up new teams: EHDS does not mean a single central EU database. There is no warehouse where everyone sends their data. The regulation is federated: each member state and each data holder keeps their own data, the HDAB mediates access, the connectivity is via standardized formats and authorized channels. Build accordingly.