What is the European Health Data Space (EHDS)?

The European Health Data Space Regulation (EHDS) is an EU initiative that:

The articles of EHDS define what data is covered by the regulation, the obligations of data holders, high level definitions of network components (e.g. SPEs), and details the functions of national Health Data Access Bodies (HDABs).

SPEs are the controlled, auditable environments in which secondary use of health data must take place. HDABs are the national bodies responsible for receiving data permit applications, coordinating access with data holders, and managing cross-border requests through the HealthData@EU infrastructure. Each EU member state is required to establish an HDAB, and both components have direct implications for any organisation that holds health data or provides research infrastructure in the EU.

EHDS was formally adopted in 2024 and represents the most comprehensive legislative framework for health data in the EU since GDPR. Implementation is phased, with primary use provisions coming into force from 2027 and secondary use provisions fully applicable from 2029.

The EHDS Timeline

Towards European Health Data Space 2 (TEHDAS2), the goal of TEHDAS2 is:

TEHDAS2 is structured around a series of working groups and public consultations covering the practical implementation of EHDS secondary use provisions. Its outputs directly inform the implementing acts and delegated regulations being developed through 2025 to 2027 - the technical instruments that will give EHDS its operational shape.

Key workstreams include the technical requirements for Secure Processing Environments, the standards for data permits and their assessment by Health Data Access Bodies, pseudonymisation and data quality requirements for health data released for secondary use, and the interoperability standards that will govern how data flows through the cross-border HealthData@EU infrastructure.

For data owners, research hospitals, and TRE providers operating in or alongside the EU, TEHDAS2 outputs are the most direct signal of what EHDS compliance will look like in practice. The guidelines are not yet final — consultations are running through 2026 — but the direction is clear, and organisations that engage with the process now will be significantly better positioned when the implementing acts are confirmed.

Standard Vs Trusted Health Data Holders

Health Data Holders

Article 60 of the EHDS details the obligations of Health Data Holders to their HDAB. The Health Data Holder is required to make their data available to the HDAB, which has responsibility for reviewing and approving access requests and issuing approval permits. The HDAB is also responsible for approving the SPE to be used for analysis of the data. 

Trusted Health Data Holders

Article 72 details the status of Trusted Health Data Holders. Member states may designate organisations Trusted Health Data Holders. These designated organisations retain more control over their own data, they are permitted to assess data access applications and provide approval or rejection recommendations to their HDAB, though the HDAB remains legally responsible for issuing data permits. More importantly, trusted organisations can provision data access in their own SPE, rather than one provided by the HDAB or a trusted third party. 

EU central services comprise three components: the EU connector, which links central services to the eDelivery network; the EU dataset catalogue, a central metadata catalogue that aggregates metadata syndicated upward from national catalogues rather than holding data directly; and the data access application form, a centralised submission point for data access applications that routes requests to the relevant national HDABs.

National level services mirror this structure at a member state level. Each participating nation operates a national contact point hosting the national connector, a national dataset catalogue managed by its designated HDAB, and a national data permit management system handling the full lifecycle of data access applications and permits.

Integration flexibility and its limits

TEHDAS2 envisages that national services will want to connect with existing local infrastructure. D5.3 identifies standardised API-based metadata submission as a functional requirement for national catalogues, and D6.4 acknowledges that the DAAMS may support Trusted Health Data Holder involvement in the assessment phase via a user interface or external API integration.

Neither deliverable specifies how these integrations should be implemented. The approach is left to each national HDAB's discretion, creating flexibility for member states whilst leaving data holders and TRE providers with limited certainty on integration requirements until the implementing acts are confirmed.

A more detailed description of these services can be found in the EHDS2 Pilot technical documentation.

A data permit is the formal authorisation issued by a Health Data Access Body (HDAB) upon approval of a data access application. It is the legal instrument that entitles a health data user to access specified datasets for a defined purpose, within a defined timeframe, and within a Secure Processing Environment. Without a valid data permit, secondary use of health data under EHDS is not permitted.

Data permits must be stored in the HDAB's Data Access and Application Management System (DAAMS) as a signed, timestamped document — for example a PDF — and linked directly to the corresponding application record. This creates an auditable chain from application to approval to use that both the HDAB and the data holder can reference.

These documents must conform to a template that will be provided by the European Commission. This template will be available from 2027, when the secondary use provisions of EHDS become fully applicable.

At present there is no legal obligation for the data permit to be represented in a structured machine-readable format such as JSON or XML, though this may evolve as the implementing acts are confirmed and cross-border interoperability requirements become more specific.

What a data permit specifies

A data permit typically covers the identity and accreditation of the data user, the datasets being accessed, the purpose for which access is granted, the Secure Processing Environment in which the data will be processed, the permitted outputs and any restrictions on their publication or sharing, and the duration of access. Permits are not open-ended, they are granted for a specific project and expire when that project concludes or the defined timeframe elapses.

Cross-border permits

Where a data user requires access to health data held across multiple EU member states, EHDS provides for cross-border data permit applications coordinated through the HealthData@EU infrastructure. In this scenario the applicant submits to their national HDAB, which coordinates with the HDABs of the relevant member states. Each participating HDAB retains responsibility for the data under its jurisdiction, but the permit framework allows a single application to govern access across multiple national datasets.

Across the EU, health data is held by hundreds of different institutions such as hospitals, registries, public health agencies, biobanks, with each describing their datasets in different ways, using different terminology, different structures, and different levels of detail.

Health DCAT-AP is TEHDAS2's answer to that problem. It is a standardised metadata model  developed specifically to ensure that data descriptions are consistent, comparable, and machine-readable across the entire EHDS network. Built as a domain-specific extension of DCAT-AP, the established Data Catalogue Application Profile used widely across European open data infrastructure, Health DCAT-AP adapts that foundation for the specific requirements of health data.

In practice, this means that a dataset held by a hospital registry in Denmark and a dataset held by a public health agency in Portugal can both be described using the same metadata elements, in the same structure, in a way that allows the EU central catalogue to aggregate, index, and surface them coherently to researchers searching across the network. A researcher looking for longitudinal cardiovascular data across multiple member states does not need to know how each national catalogue works, they search once, and the standardised metadata does the work of making the relevant datasets findable and comparable.

The full Health DCAT-AP specification is available here. As of 2026 it remains under active development through the TEHDAS2 process, and the final specification is expected to evolve as implementing acts are confirmed through 2027.

Under EHDS, an SPE can be provided by the HDAB itself, by a Trusted Health Data Holder, or by a trusted third-party supplier. Health data users are also permitted to suggest an appropriate SPE for their specific use case, subject to HDAB approval. This means that existing Trusted Research Environment infrastructure, where it meets the required technical and organisational standards, can serve as the SPE for a permitted research project.

What EHDS requires of an SPE

Article 73 of EHDS provides the high-level security specification that all SPEs must meet. Health Data Access Bodies may only provide access to health data through a secure processing environment subject to the following measures:

• Access restricted to the authorised individuals named in the data permit, in line with Article 68
• State-of-the-art technical and organisational measures minimising the risk of unauthorised reading, copying, modification, or removal of data.
• Input of data, and inspection, modification, or deletion of data within the environment, limited to a small number of authorised, identifiable individuals.
• Individual and unique user identities with confidential access modes, ensuring each user accesses only the data covered by their specific permit.
• Identifiable access logs maintained for the period necessary to verify and audit all processing operations for a minimum of one year.
• Active monitoring and compliance measures to mitigate potential security threats.

Additional considerations for SPE selection

The full TEHDAS2 technical specification for SPEs is not expected until March 2027. However, the TEHDAS2 deliverable D7.1 - Guideline on how to use data in a secure processing environment, identifies a number of practical factors that a Health Data User or HDAB may wish to consider when evaluating whether a given SPE is appropriate for a specific research project:

• The computational power required for the intended analysis. This includes RAM, CPU cores, and GPU access where machine learning workloads are involved.
• The volume of data to be processed and the storage capacity the environment must support.
• The software tools, programming languages, or statistical packages the research team needs access to within the secure boundary.
• The nature of the data being analysed. Genomic data, medical imaging, electronic health records, and other data types may each carry specific technical or governance requirements that influence SPE suitability.

These factors matter because an SPE that meets the Article 73 baseline requirements may still be unsuitable for a particular project if it cannot support the analytical workload or the tooling the research team depends on. Choosing an appropriate SPE is therefore both a governance decision and a technical one.

As detailed above Trusted Health Data Holders retain more control of their data. Article 72 of the legislation provides the high level criteria for ‘trusted’ status:

1. they are able to provide access to health data through a secure processing environment that complies with Article 73;
2. they have the necessary expertise to assess health data access applications and health data requests;
3. they provide the necessary guarantees to ensure compliance with this Regulation.

Given these criteria, we believe that organisations with an enterprise Aridhia DRE will be well placed to act as Trusted Health Data Holders. Looking at the three points above in turn will explain why.

Providing data access via an SPE

The full EHDS SPE specification will not be available until 2027. However, as detailed in the previous EHDS blog DRE Workspaces are a close match for the current specifications provided in the EHDS legislation and TEHDAS2 project documents.

For example:

• Individual users access their workspace using multi-factor authentication
• All data ingress and egress is managed via a secure airlock
• Each workspace has its own audit trail which captures all research activity
• Researchers have access to wide range of tooling as standard (R, Python, Jupyter Lab, etc.)

Reviewing and approving datas permit applications

Our metadata catalogue FAIR Data Services has a native fully configurable data approval process that allows data owners to review and approve data access requests. FAIR’s open API allows this approval flow to be integrated with third party systems, meaning that FAIR can receive requests from external platforms and return approval decisions.

Proving Capability

The final presently known requirement is that the HDH be able to prove they have the above capabilities.

With the Aridhia DRE this is straightforward, our platform is independently audited on a recurring basis, with ISO 27001, ISO 27701, HITRUST, and Cyber Essentials Plus certifications all publicly available. Additionally we evaluate our platform against the emerging open standards for TRE/SPE provision, like SATRE and EOSC-ENTRUST.