EHDS Explained: Article 50 and Secondary Use of Health Data
The European Health Data Space (EHDS) is a European Union regulation — Regulation (EU) 2025/327 — that creates a common legal framework for using electronic health data across all EU Member States. It covers two things: primary use, meaning citizens and clinicians accessing health records across borders, and secondary use, meaning researchers, regulators, and policy makers reusing health data for research and innovation. Article 50 of the regulation requires that all secondary use of personal electronic health data happens inside a secure processing environment — researchers come to the data, and the data never leaves it.
Why the EHDS matters now
The EHDS entered into force on 26 March 2025, after formal adoption in February 2025 and publication in the Official Journal of the European Union. It is not a directive that each country transposes in its own way; it is a regulation, directly applicable in every Member State. Its obligations arrive in stages: the core secondary-use provisions begin applying from March 2029, with remaining data categories — including genomic and certain clinical-trial data — following in 2031.
That timeline sounds distant, but the infrastructure it mandates does not appear overnight. Every Member State must designate a Health Data Access Body (HDAB), a public authority that receives data-access applications, issues data permits, and provides the secure processing environments Article 50 requires. Data holders — hospitals, registries, biobanks, insurers — must be able to make defined categories of electronic health data available to those bodies. Cross-border requests will route through HealthData@EU, the federated infrastructure that connects national access bodies into a single European network. Governments and data custodians that wait until 2029 to think about architecture will be building under deadline pressure what others designed deliberately.
The regulatory direction also has a recent, concrete justification. In May 2026, the UK Biobank incident demonstrated that approved researchers could remove participant-level data from a centralised Trusted Research Environment (TRE) through its normal, policy-compliant workflow. No rules were broken; the architecture simply permitted downloads. Article 50 is the EU legislating against exactly that failure mode, before it happens at continental scale.
What Article 50 actually requires
The secure processing environment
Article 50 obliges Health Data Access Bodies to provide access to personal electronic health data only through a secure processing environment: a controlled technical setting with strict organisational and security measures, where authorised users can analyse data but cannot extract it. In practice this is a Trusted Research Environment — a governed workspace where the analysis happens under supervision, every action is logged, and only checked, non-identifying results are released.
Three consequences follow directly from the text. First, downloading personal electronic health data from the environment is prohibited — the researcher can take out aggregate statistics and models, not records. Second, the environment must enforce access controls that limit each user to the data covered by their permit. Third, the access body must be able to audit what happened inside: who accessed what, when, and what left. These are architectural requirements, not policy aspirations, which is why they cannot be met with a data-sharing agreement and a file-transfer link.
Secondary use, data permits, and opt-outs
The secondary-use chapter of the EHDS defines which categories of data must be made available — electronic health records, registry data, claims data, genomic data, and more — and for which purposes: scientific research, public health, policy making, education, and the development of medical products and artificial intelligence (AI) systems. Certain purposes are explicitly prohibited, including advertising, insurance-premium discrimination, and decisions that harm the individuals whose data is used.
A researcher applies to an HDAB, which assesses the application against those permitted purposes and, if satisfied, issues a data permit specifying the data, the duration, and the conditions. Wherever the research question can be answered with anonymised or aggregate data, the access body must supply that instead of identifiable records — a data-minimisation duty written into the regulation. Citizens, meanwhile, retain an opt-out right for the secondary use of their personal electronic health data, which Member States must implement. Trust in the system is doing real work here: the more visibly secure the processing environment, the fewer people exercise the opt-out, and the more representative the research data remains.
Obligations for data holders
The EHDS is not only a researcher-facing framework; it places direct duties on data holders — the hospitals, registries, laboratories, and companies that generate electronic health data. Holders above a minimum size must describe their datasets in machine-readable catalogues so that HDABs can advertise what exists, respond to access-body requests within defined timeframes, and supply data in the formats and quality the permit requires. The regulation permits fees, but only cost-based ones: access bodies and holders may recover the costs of preparing and providing data, not price access as a commercial product. There are protections in the other direction too — intellectual-property and trade-secret safeguards allow holders to attach conditions where disclosure would compromise protected information, subject to the access body’s oversight rather than the holder’s veto. For most hospital groups and registries, the binding constraint will not be legal interpretation but data readiness: catalogued, quality-assessed, standards-mapped data can be made available within the deadlines; unharmonised data cannot. That is why data harmonisation belongs at the top of any EHDS preparation plan, not the bottom.
The federation angle: why the EHDS is a federated design
The most under-appreciated fact about the EHDS is that it is structurally a federation. There is no plan for a single European health database. Data stays with national access bodies and data holders; HealthData@EU connects them so that a researcher in one Member State can request analysis across several. Federation — moving compute and questions to the data rather than moving the data to a central store — is the only architecture that satisfies twenty-seven sovereignty regimes at once, because each state keeps physical and legal custody of its citizens’ records.
This is the same conclusion national programmes reached independently. A federated TRE places the secure processing environment at the data custodian, so the data never leaves the source, and connects environments into networks where queries travel and results return. Under that model, Article 50 compliance is not a bolt-on control but a property of the architecture: extraction is impossible because no extraction pathway exists, and every output passes through an automated airlock that checks it for disclosure risk before release. Federation also solves the harmonisation problem the EHDS quietly poses — cross-border analysis only works if national datasets are mapped to shared standards, which is why common data models such as the Observational Medical Outcomes Partnership (OMOP) Common Data Model feature so heavily in European research infrastructure.
Centralised extract sharing versus the Article 50 model
| Dimension | Traditional extract sharing | Secure processing environment (federated TRE) |
|---|---|---|
| Where data lives during analysis | Copied to the researcher’s institution or laptop | Stays with the data holder or access body; data never moves |
| What the researcher receives | A dataset they control indefinitely | A governed workspace with permitted data mounted |
| What leaves the environment | Everything, by definition | Only checked aggregate results and models |
| Auditability | Ends at the point of transfer | Continuous — every query and export is logged |
| Cross-border legality under EHDS | Incompatible with Article 50 for personal data | The mandated model |
| Revocability | Practically impossible once copied | Access is switched off; no copies exist |
Real-world precedent: national programmes already run this way
The Article 50 model is not speculative. Genomics England, which holds one of the world’s largest national genomic datasets, has operated on the principle that researchers analyse data inside a governed research environment rather than receiving copies — and works with Lifebit to deliver federated analysis at national scale. Singapore’s Ministry of Health applies the same pattern to precision-medicine data across its health clusters, and the Canadian Partnership for Tomorrow’s Health (CanPath) demonstrates it across a distributed, multi-province cohort. Each of these programmes independently converged on the architecture the EHDS now mandates: custodians keep the data, researchers bring the questions, and outputs are checked before they leave. European access bodies designing their Article 50 environments have working national-scale references to study, not just legal text.
What to do before 2029
For a ministry, access body, or data holder preparing for the EHDS, the practical sequence is clear. First, inventory the electronic health data categories the regulation covers and assess their quality and standardisation — harmonisation to a common data model is the longest-lead-time item on the list. Second, decide the secure processing environment architecture early, and evaluate it against Article 50’s specific tests: can personal data be downloaded (it must not be), can access be scoped per permit, can every action be audited, and can outputs be disclosure-checked before release? Third, treat cross-border participation as a design requirement, not a later phase — HealthData@EU assumes environments that can execute federated queries, so an environment that only works in isolation solves half the problem. The compliance mapping between TRE architecture and HIPAA, GDPR, and EHDS obligations is a useful starting framework: the regimes differ in detail, but a federated TRE with automated output control satisfies the strictest requirement in each, which makes it the safest common denominator.
Frequently asked questions
What is the European Health Data Space in one sentence?
The EHDS is an EU regulation, in force since March 2025, that gives citizens control over their electronic health records across borders and creates a governed system for reusing health data in research through national Health Data Access Bodies and secure processing environments.
What does Article 50 of the EHDS require?
Article 50 requires that access to personal electronic health data for secondary use is provided only through a secure processing environment — a controlled technical setting where researchers can analyse data but cannot download it, with strict access controls, logging, and checks on any results that leave.
What is secondary use of health data under the EHDS?
Secondary use means reusing electronic health data collected during care — records, registries, claims, genomic data — for purposes beyond treatment, including scientific research, public health, policy making, and the development of medicines and AI systems, under a data permit issued by a Health Data Access Body.
When does the EHDS apply?
The regulation entered into force on 26 March 2025 and applies in stages: the core secondary-use provisions begin applying from March 2029, with further data categories, including genomic data, following in 2031.
Can researchers download data under the EHDS?
No. For personal electronic health data, downloading from the secure processing environment is prohibited; researchers may only export non-identifying results — such as aggregate statistics or trained models — after the access body’s disclosure checks.
Is the EHDS a central European health database?
No. The EHDS is a federated system: data remains with national data holders and access bodies, and the HealthData@EU infrastructure connects them so that cross-border research requests can be answered without pooling records centrally.
How does a federated TRE help with EHDS compliance?
A federated Trusted Research Environment implements Article 50’s requirements architecturally: data never leaves the source, access is scoped to the permit, every action is audited, and an automated airlock checks outputs before release — so compliance is a property of the system rather than a set of manual controls.