HealthData@EU: 10 Recommendations to Strengthen Legal Certainty and Data Protection

Our contribution to the European Commission’s draft Implementing Regulation under the European Health Data Space (EHDS)

Introduction

The European Health Data Space (EHDS), established under Regulation (EU) 2025/327, provides the framework for HealthData@EU, a centrally coordinated infrastructure connecting national contact points for secondary use, the Union health data access service, and authorized participants.

The European Commission has prepared a draft Implementing Regulation under Articles 63(7) and 75(12) of the EHDS Regulation to establish provisions governing this infrastructure.

At MyData-TRUST, we welcome the draft Implementing Regulation and its objective of establishing a secure, interoperable cross-border infrastructure for the secondary use of electronic health data, which is essential to health research in the Life Sciences sector.

Drawing on our experience providing Data Protection services to organizations that will engage with HealthData@EU primarily as health data users and, in certain cases, as health data holders, we have submitted comments identifying 10 areas where the proposed framework would benefit from further clarification.

Our contribution is guided by the principles of the GDPR, particularly Recital 6, which addresses the free flow of personal data within the Union and to third countries while ensuring a high level of protection, and Recital 4, which recognizes that the right to Data Protection is not absolute and must be balanced, in accordance with proportionality, against other interests, including public health and Scientific Research.

We particularly welcome the distinction established under Article 4(2) of the draft Regulation between the technical role of the central platform, limited to submission, routing and exchange, and the substantive decisions reserved to health data access bodies and authorized participants.

This distinction should be preserved.

At the same time, organizations planning multi-year research and clinical programs need a predictable, transparent and legally certain framework.

The following 10 recommendations aim to strengthen these aspects of HealthData@EU.

⚖️ 1. Legal certainty and the role of technical documentation

A significant part of the substantive requirements governing HealthData@EU, including interfaces, security controls, logging, retention and semantic assets, is deferred to technical documentation developed and maintained by the European Commission, as provided under Recital 4 and Articles 4(3), 5 and 7.

While this flexibility is understandable, it creates potential legal and operational uncertainty.

Under Article 7(4), minor releases may be deployed without an individual Steering Group decision. However, the distinction between major and minor releases is functional rather than substantive.

A release classified as minor may nevertheless have significant consequences for regulated users.

For example, changes to logging or data-retention specifications could require modifications to compliance processes and record-keeping. Similarly, changes to an API interface or authentication mechanism could require users to modify validated IT systems, update security controls, re-test interfaces or revise internal procedures.

Conversely, a major release may introduce substantial technical changes with limited practical consequences for certain categories of users.

The distinction between major and minor releases should therefore consider not only their technical scope but also their potential substantive and operational impact.

Furthermore, technical documentation should not be capable of materially changing Data Protection safeguards or the allocation of legal responsibilities established under Chapter V of the draft Regulation.

Our recommendations

We suggest that technical documentation and its change log be published and maintained at the single access point already provided for under Article 5(1).

Relevant stakeholders should have an appropriate opportunity to provide input before major releases are adopted, particularly where these may materially affect compliance obligations or operational requirements.

Adequate and proportionate transition periods should also be guaranteed for changes requiring technical, organizational or contractual adjustments.

Finally, the Regulation should confirm that no release, whether major or minor, may materially alter the Data Protection obligations or the allocation of controller and processor responsibilities established under Chapter V.

🗣️ 2. Further specifications on observer participation

Article 95 of the EHDS Regulation provides for the participation of observers in the HealthData@EU Steering Group, including industry representatives.

However, the detailed organization and functioning of the Steering Group are left to its rules of procedure.

Greater clarity would be beneficial regarding how observers are selected and invited, their access to relevant information and their opportunities to provide input.

Our recommendations

We recommend that the Implementing Regulation establish minimum principles for a transparent and inclusive observer participation framework, while leaving the detailed arrangements to the Steering Group’s rules of procedure.

This would balance clarity and inclusiveness at the regulatory level with flexibility in the Steering Group’s future organization and functioning.

Industry should be explicitly considered within this framework, including pharmaceutical, medical device and biotechnology companies.

These organizations are expected to constitute an important part of the health data user community under the EHDS, particularly in relation to research, innovation, the development of medicinal products and medical devices, and other permitted uses of electronic health data.

Their participation could provide practical and technical input into the development and operation of HealthData@EU.

Such participation would not affect the Steering Group’s decision-making powers, as observers do not have voting rights.

🛡️ 3. The position and safeguards of Health Data users

The draft Regulation appropriately limits the central platform to technical submission and routing functions under Articles 4(1)(b) and 4(2).

Article 4(1)(a) and (b) also provides for the exchange of applications, updates, withdrawals, notifications of decisions and, where applicable, information on results or outputs.

However, the draft provides less detail on how these functions will operate from the applicant’s perspective.

Several practical questions remain, including timely acknowledgement of receipt, traceability of application status, the handling of applications addressed to several Member States and visibility of withdrawals.

The confidentiality of application content is another important consideration.

Applications may contain commercially sensitive information, including research protocols, proprietary methodologies, confidential information and know-how.

Our recommendations

We suggest that the Implementing Regulation establish minimum applicant-facing procedural safeguards, including:

• Acknowledgement of receipt.
• A transparent application-status and traceability channel accessible to applicants.
• Clear procedures for multi-country applications and withdrawals.
• Explicit safeguards protecting the confidentiality and integrity of application content.

The technical documentation could then specify how these requirements should be implemented.

The Regulation should also clarify that the central platform’s technical routing function does not alter the substantive responsibilities of the authorities or other actors responsible for assessing applications and making decisions.

🤝 4. Joint controllership and the exercise of data subject rights

Under Articles 18 and 22 of the draft Regulation, the relevant national contact points for secondary use and, where applicable, other authorized participants act as joint controllers for the processing operations covered by those provisions, with the European Commission acting as processor.

This creates a complex, decentralized and cross-border joint-controllership structure.

A data subject may face multiple joint controllers across different Member States, with requests potentially forwarded between them under Articles 18(1)(e) and 22(1)(e).

Although the draft establishes certain elements governing interactions between controllers, it does not sufficiently specify how Article 26 GDPR should be implemented in this context.

In particular, it does not translate the legal requirements into sufficiently clear and practical arrangements for day-to-day implementation.

We previously highlighted the importance of clearly allocating responsibilities among joint controllers in our comments on EDPB Data Breach Guidelines 01/2021.

The same concern applies to HealthData@EU, amplified by the number of parties involved and the cross-border setting.

Our recommendations

We suggest that the Implementing Regulation require a standard joint-controllership arrangement for the processing operations covered by Articles 18 and 22.

This arrangement should be based on a template developed at EU level and endorsed through the HealthData@EU governance arrangements.

It should clearly allocate roles and responsibilities, including those relating to Articles 13 and 14 GDPR, the receipt and handling of data subject requests, forwarding and follow-up of requests, cooperation between joint controllers, and relevant security and breach-management obligations.

Completed arrangements should be maintained and published on the HealthData@EU website.

This would provide a stable and transparent means of making the essence of the Article 26 GDPR arrangement available to data subjects without requiring the same information to be reproduced separately for each request.

We also suggest that the Regulation provide for the designation of a lead joint controller for each relevant processing operation or category of processing, based on objective criteria.

The lead joint controller should normally be the entity with the closest operational relationship to the processing activity and the best position to fulfill the relevant data subject obligations.

For example, where a National Contact Point (NCP) is responsible for providing or making available the relevant personal electronic health data, that NCP could normally act as the lead joint controller and primary point of contact for data subjects.

An NCP acting only as the requesting or receiving participant would not normally assume that role.

The lead joint controller’s obligations should include maintaining transparency information, receiving and coordinating data subject requests, forwarding notifications where necessary, monitoring applicable response timelines and coordinating responses among joint controllers.

These obligations should be supported by appropriate operational means, including access to the information necessary to handle requests, timely input from other joint controllers and defined cooperation obligations.

Importantly, designating a lead joint controller should not affect the substantive responsibilities of other joint controllers or the right of data subjects to exercise their rights against each controller.

To facilitate the exercise of these rights, we also suggest that the lead joint controller’s contact point be clearly identified.

In addition, the Regulation should establish a simple and accessible platform or dedicated email address through which data subjects can submit requests without having to identify or contact the responsible joint controller themselves.

The system should automatically notify and route requests to the relevant joint controllers, including the lead joint controller where applicable, while allowing requests to be tracked internally.

Finally, the HealthData@EU website should provide a searchable overview of relevant joint-controllership arrangements, identifying the lead controller, data subject contact point, allocation of responsibilities and processing operations concerned.

This would support consistent implementation of Articles 13, 14 and 26 GDPR across Member States.

🚨 5. Personal Data Breach notification in a cross-border, multi-controller setting

Articles 18(1)(g) and (h) of the draft Regulation organize mutual assistance and breach notification.

However, information sharing between joint controllers relies on a “best efforts” standard under Article 18(2).

The Commission’s obligation as processor to inform controllers under Article 19(1)(h)(vi) is also not linked to a defined timeline.

Against the 72-hour notification deadline under Article 33 GDPR, and with potentially several supervisory authorities concerned, this creates a risk of late, divergent or duplicative notifications.

More broadly, the draft does not sufficiently specify the coordination mechanisms through which joint controllers should develop a common understanding of an incident, allocate responsibilities and ensure a consistent and timely response.

Our recommendations

We suggest that a coordinated breach-notification procedure be established in the technical documentation.

This procedure should address roles, coordination responsibilities between joint controllers, the definition of high risk, indicative timelines allowing the 72-hour deadline to be met, coordination with the relevant supervisory authorities and a common template.

Where appropriate, the procedure should identify a lead joint controller for incident coordination, in principle the same lead joint controller designated under the joint-controllership arrangements.

This controller should have defined responsibilities and the operational means to collect information from other joint controllers and coordinate the response and notifications where relevant.

Information sharing between joint controllers and the Commission should also be governed by defined service levels rather than a “best efforts” standard, in line with EDPB Guidelines 09/2022 on breach notification.

🔄 6. The interplay between NIS2 incidents and GDPR Personal Data Breaches

The draft Regulation defines “incident” and “significant incident” by reference to Directive (EU) 2022/2555 (NIS2) under Article 2(g) and (h).

Article 12 requires significant incidents to be notified to the Commission, while personal data breaches follow a separate GDPR-related notification process under Article 18.

However, a single event may qualify as both a significant incident and a personal data breach.

Where the interaction between these two regimes is not sufficiently defined, organizations may face confusion, duplicate reporting or gaps in their notification processes.

Our recommendations

We suggest that the Regulation clarify how the two notification processes should interact when an incident also constitutes a personal data breach.

Ideally, this would involve a single internal trigger, aligned notification content and non-contradictory timelines.

This would help ensure that connected entities are not left to reconcile parallel notification obligations under time pressure.

🌐 7. International transfers, chapter V GDPR and equivalent access

Recital 10 and Articles 10(4) and 15(4) of the draft Regulation require authorized participants from third countries and international organizations to comply with Chapter V GDPR.

They also require these participants to provide health data users located in the Union with access on “equivalent terms and conditions.”

However, the draft does not explain how Chapter V applies where a third-country participant is granted access to personal data through a secure processing environment.

In particular, it does not clarify how the safeguards provided by that environment should be taken into account in the transfer assessment.

The draft also does not specify the criteria against which equivalent access should be assessed, including where access is provided through a secure processing environment.

These concerns build on our previous comments on EDPB Guidelines 05/2021 regarding the interplay between Article 3 and Chapter V GDPR.

Our recommendations

We suggest that the Regulation clarify, through the provisions governing secure processing environments and/or the compliance-check framework under Article 10(4), how access by third-country and international-organization participants should be assessed under Chapter V GDPR.

In particular, it should clarify whether, and under which circumstances, remote access to personal data through a secure processing environment constitutes a transfer.

It should also explain how the technical and organizational safeguards provided by the environment should be considered in that assessment, including where they may constitute relevant supplementary measures.

The compliance-check framework under Article 10(4) should establish clear and objective criteria for assessing equivalent access.

These criteria should address conditions, scope, safeguards and the mitigating role of secure processing environments as technical and organizational measures.

The approach should also be aligned with EDPB guidance to avoid duplication and uncertainty regarding the applicable tools.

🔐 8. Secure processing environments and the allocation of responsibilities

Articles 21 to 23 of the draft Regulation usefully limit the personal data processed in the Commission-provided secure processing environment and confirm the division between joint controllers and the Commission as processor.

However, the draft focuses primarily on the Commission-provided environment without sufficiently addressing situations in which processing also takes place in secure environments provided or operated by national authorities or other authorized participants.

Where a processing activity involves several such environments, the allocation of responsibilities remains insufficiently clear.

This includes responsibilities for access control, security incidents, compliance monitoring and audit information at the interfaces between environments.

Additional uncertainty concerns the erasure and return obligation under Article 23(1)(c).

Where data or processing outputs move between, or are generated across, different secure processing environments, it is unclear how the Commission’s obligation to delete or return personal data interacts with the responsibilities of other controllers or processors operating those environments.

This includes the handling of copies, intermediate datasets and jointly generated research outputs.

Our recommendations

We suggest clarifying the operational allocation of responsibilities where data move between national infrastructures or other secure processing environments and the Commission-provided environment.

Appropriate access to audit and logging information for controllers should also be confirmed.

The Regulation should clarify how deletion and return obligations apply across multiple secure processing environments, including how deletion or return should be coordinated where personal data, copies or intermediate datasets are held in different environments.

The rules should also distinguish personal data subject to the obligation from outputs that no longer constitute personal data.

Finally, responsibilities for deletion, return and confirmation of completion should be clearly established, while ensuring that the obligations remain workable for legitimate, jointly generated research outputs.

📋 9. The enforcement information exchange tool: transparency and proportionality

Chapter VI of the draft Regulation, covering Articles 24 and 25, establishes an Enforcement Information Exchange Tool.

In effect, this creates an EU-wide register of enforcement measures, including measures against health data users, recorded and shared across health data access bodies under Article 25(4)(f).

Because these records may be accessed by multiple health data access bodies, they may have significant practical and reputational consequences for the health data users concerned.

One concern is the risk of de facto EU-wide blacklisting, including where a measure is under administrative or judicial review under Article 25(5)(b).

Other concerns include the processing of identifiers relating to natural persons under Articles 25(4)(f) and 17(b), and the allocation of responsibility for the accuracy and subsequent correction of records.

Under the draft, the recording body is responsible for accuracy under Article 25(6), while the Commission is not responsible for accuracy under Article 25(7).

However, the draft does not establish a clear mechanism for concerned health data holders or users to be informed when a record is created about them, challenge its accuracy or ensure that corrections or erasures are communicated to other bodies with access to the record.

Retention is also left entirely to technical documentation under Article 24(4), without regulatory-level criteria or limits governing how long records should remain available.

Our recommendations

We suggest that the Regulation ensure that concerned health data holders or users are informed of records concerning them and provided with a clear mechanism to request rectification or completion.

The legal-status field should prominently reflect the suspensive effect of any pending review, with the visibility of contested measures limited accordingly, so that other health data access bodies do not treat a contested or suspended measure as an operative enforcement measure.

The Regulation should also establish clear responsibilities and procedures for correcting and updating records.

This should include ensuring that corrections, changes in legal status or deletions are communicated to the health data access bodies that have received or have access to the records.

Clear and proportionate retention criteria and safeguards should be established in the Regulation itself.

Specific retention periods and operational arrangements should be defined in the technical documentation and subject to periodic review.

Finally, the Data Protection risks associated with the register should be assessed before its deployment, including through a Data Protection Impact Assessment under Article 35 GDPR where required.

📅 10. Timing and Preparedness

The draft Regulation provides for application from March 26, 2029, under Article 26.

Article 5(4) requires the parts of the technical documentation necessary for compliance checks to be made available sufficiently in advance.

We welcome this provision.

However, the same principle should also benefit health data users, who cannot prepare their applications and processes without a stable understanding of the complete application journey.

Our recommendations

We suggest that the Commission commit to publishing the compliance-check framework under Article 10 and a stable version of the technical documentation sufficiently ahead of the application date.

This should be accompanied by practical guidance for health data users covering the end-to-end application journey.

🎯 Conclusion

We welcome the draft Implementing Regulation as a sound foundation for a secure and interoperable HealthData@EU.

Our contribution pursues two overarching objectives.

The first is to strengthen legal certainty and the position of health data users, particularly through predictable procedures, transparent requirements and appropriate safeguards.

The second is to refine the Data Protection architecture, including joint controllership, breach notification, international transfers under Chapter V GDPR and the Enforcement Information Exchange Tool.

Through these recommendations, we aim to support the development of a framework that combines strong Data Protection safeguards with the operational needs of the Life Sciences sector.

We remain willing to contribute concrete use cases drawn from Life Sciences and Clinical Trials to support the finalization of this initiative.

Authors: Victoria Derumier & Michelle Ayora