Get Ahead of the EHDS Deadline with Federated Computing

The European Health Data Space (EHDS) imposes a firm deadline on a problem every hospital and health system already has: Their data is not harmonised, not catalogued, and not governed for reuse beyond the system it was created in.

Any organisation holding health data becomes a Data Holder by operation of the regulation — no threshold to cross, no application to file. That status carries real obligation. Data Holders must be able to describe what the institution holds in a machine-readable catalogue and prepare a compliant extract whenever an approved permit requires it. Those duties phase in from March 2029, extending to imaging, lab results, and discharge reports from March 2031. That window is shorter than it looks.

As hospitals and health systems race to meet the 2029 deadline, the architecture they choose to help them get there is a top priority. Federated computing is a natural to fulfill these needs, and the institutions that deploy it now will be doing more than just preparing for 2029. By starting now, you can spend the next three years putting that infrastructure to work on internal analytics, AI development, and research partnerships and be completely ready when EHDS comes into force.

Understanding the 2029 Deadline

The EHDS separates two regimes. Primary use covers care delivery for a patient's own record, reachable by them and their treating clinicians. Secondary use covers every other external use, including research, public health, policymaking, and AI training. Every organisation holding health data is an obligatory participant in the secondary-use framework as a Data Holder, regardless of whether it aspires to participate in research.

That status carries four concrete obligations, organised around the functions EHDS places on a Data Holder, or, in the case of Contain and Control, a Trusted Data Holder:

• Describe: Maintain a machine-readable catalogue of what the institution holds, per variable, with source and derivation recorded.
• Prepare: Translate an approved permit into a compliant extract: strip opted-out individuals, remove protected fields, pull across source systems, and reshape the result into the required format.
• Contain: Run a secure processing environment that keeps data inside the institution's own boundary, with named-identity access and per-permit isolation. (Trusted Data Holders only)
• Control: Review every egress request and assess incoming permit applications within the two-month window the regulation allows. (Trusted Data Holders only)

Every Data Holder must meet Describe and Prepare. Trusted Data Holder status goes further: institutions that earn the designation keep data inside their own environment rather than transferring it to the national access body (more on that later). 

Both Describe and Prepare require a data inventory most institutions do not have, and harmonisation infrastructure most do not yet run. The current staffing reality highlights the gap: a 2025 cross-sectional survey of 64 organisations across 18 European countries found that 68.8 percent had no dedicated data quality manager or team, and only 15.6 percent had clearly defined data quality roles. With a deadline now less than three years away, the compliance problem is both organisational and technical.

The Risks of Centralization

The default approach to readying hospital data for secondary use is to copy it out of multiple source systems into a central data lake or warehouse, normalise it there, filter the data to be shared, de-identify it, translate it into the destination data format, and then transfer to the external party. A unified data store is easier to query, but the copy creates a second full store of protected health information that has to be secured, governed, and kept in sync with the sources it came from.

The security tradeoff is significant. A breach of the shared store exposes the full aggregated patient record across every source system at once. For EHDS compliance specifically, the synchronisation problem compounds with every new permit: the copy may not reflect the current state of the source, and harmonisation performed for one request doesn't carry forward to the next.

An Architecture Built for Regulated Data

The core principle of federated computing is that code runs where the data lives, inside the institution’s own environment. Only governed data or aggregated outputs ever leave. There is no second PHI copy to secure, no synchronisation problem between a copy and the source, and no separate governance model to maintain alongside the first.

For an EHDS Data Holder, the infrastructure this produces provides ongoing value. Harmonisation built once to answer a permit serves the next request too, whether it comes from an internal analytics team, an external research partner, or a different national access body entirely.

Rhino Data Activation is built around this model. The Data Harmonization Engine maps and prepares data inside the institution's own environment. Interactive Containers provide the secure processing environment the Contain function requires, running at the data's location. Project-based governance and permissions carry the identity, audit, and per-permit isolation requirements Contain and Control both depend on.

For institutions pursuing Trusted Data Holder status, Rhino Data Activation makes that path significantly shorter. An institution already running Rhino Data Activation for Describe and Prepare has built the harder half of what designation requires. Contain and Control extend that infrastructure rather than starting a new project. Trusted Data Holder status also lets institutions charge a fee for access rather than receiving a one-time reimbursement and retains audit and revocation rights for the life of the permit.

The Case for Building Now

Several EHDS technical requirements are still being finalised, such as the Article 73(5) implementing act for Trusted Data Holders, the EEHRxF exchange format specification, and the Article 78 data quality label. 

None of those open items touch the core obligation. Harmonising local data to a shared vocabulary, building the variable-level inventory a minimisation assessment requires, and establishing governed access all have to happen under any plausible final version of the rules. Starting now means finalised requirements land on infrastructure that already exists, rather than being built from zero against a fixed deadline. 

In the meantime, that same infrastructure is already earning its keep by powering internal analytics, supporting research collaborations, and readying data for uses that have nothing to do with EHDS. By the time the regulation is enforced, institutions that started early will have a tested, production-hardened system. On the other hand, those that waited will be building under pressure.

For an even deeper dive into EHDS compliance requirements and how Rhino Data Activation can help your organisation meet and exceed them, check out our white paper, Rhino Data Activation for EHDS Data Holders.

‍

FAQs

1. How Does a Federated Approach Help Meet the “Describe” Obligation Without Moving Data?

The harmonization engine builds a machine‑readable catalog inside the local environment, capturing metadata about each dataset while the raw records stay on their source systems. This supports the requirement for a searchable, standardized inventory without any data export.

2. What Steps Are Needed to Generate a Compliant Data Extract for a Specific EHDS Permit?

First, the permit defines the exact variables needed. The interactive container then runs the prepare pipeline, which pulls only those variables from the source systems, applies the harmonization mappings and returns a minimal, audit‑ready extract. Because the pipeline runs in‑place, the extract reflects the most recent data state.

3. Can the Same Federated Infrastructure Support Internal Analytics and AI Model Training?

Yes. Once the data is described and harmonized, the same pipelines can feed internal dashboards, quality‑control reports and AI training jobs. The compute still occurs where the data resides, preserving privacy while avoiding duplicate copies.

4. What Governance Controls Are Required for the “Contain” and “Control” Functions?

A secure processing environment isolates each workload, enforces role-based access, and logs every operation. An egress review layer checks each data release against the permit scope and retains audit records for the duration required by the applicable regulation, providing the evidence needed for regulators and ethics committees.

5. How Does Differential Privacy Fit Into the EHDS Workflow?

After a data extract is prepared, differential privacy mechanisms can add controlled statistical noise before the data is shared with external researchers. This reduces re‑identification risk while preserving the utility of the dataset for analysis.