EHDS Is Phasing In: What Do Health Data Holders Actually Have to Operate?

The European Health Data Space is not a future regulation you can park.

Regulation (EU) 2025/327 was adopted on 11 February 2025 and is already in force. The application dates are fixed. And most health organisations still cannot answer the one question that decides their next two years: what do we actually have to operate, and by when.

EHDS compliance is not a single switch. It is a phased build across primary use, secondary use, and the software that moves health records between systems. Each stream has its own duties, its own deadline, and its own owner inside your organisation.

This is the practitioner view. Not why health data matters. Which obligations bind you, traced to the regulation, and how to sequence them before the first application date lands.

What does the EHDS phased application timeline actually commit health organisations to, and by when?

Article 105 sets the schedule, and it is not one date.

The general rule is that the Regulation applies from 26 March 2027. But the operational chapters phase in later, by category of health data.

Under Article 105, the primary-use and EHR-system rules covering Articles 3 to 15 and Articles 25, 26 and 27 among others apply from 26 March 2029 for the first priority categories, and from 26 March 2031 for the next set. The priority categories are defined in Article 14: patient summaries, electronic prescriptions and electronic dispensations in the first band; medical imaging studies and reports, medical test results, and discharge reports in the second.

Chapter IV, the secondary-use regime, also applies from 26 March 2029 under Article 105, with individual provisions arriving earlier or later, and Article 75(5) only from 26 March 2035.

Several earlier deadlines already bite. Article 99 required Member States to notify their penalty rules to the Commission by 26 March 2027. Article 15 requires the Commission to specify the European electronic health record exchange format by 26 March 2027. Article 36 sets the same date for the common specifications on essential requirements. And Article 70 requires the Commission to issue the templates for access applications, data permits and health data requests by 26 March 2027.

So the honest answer to "when" is a staircase, not a cliff. The work to be ready for 2029 is scoping work you do in 2027.

Who counts as a health data holder under EHDS, and does the duty apply to you?

The definition in Article 2 is deliberately wide.

A health data holder is any natural or legal person, public authority, agency or other body in the healthcare or care sectors, including reimbursement services, as well as any person developing products or services for the health sector, developing or manufacturing wellness applications, performing research related to healthcare or care, or acting as a mortality registry.

To fall inside the definition you also need one of two things: the right or obligation, as controller or joint controller, to process personal electronic health data for healthcare, public health, reimbursement, research, policymaking, statistics, patient safety or regulatory purposes; or the ability to make non-personal electronic health data available through control of the technical design of a product and its services.

Read that carefully. It is not only hospitals and clinics. It reaches medtech vendors, wellness app makers, research institutions, and reimbursement bodies.

Article 50 carves out exemptions from the Chapter IV data-holder obligations. Natural persons, including individual researchers, are exempt. So are legal persons that qualify as microenterprises. But Member States may extend the obligations to those parties in national law, and they may also decide that certain data holders fulfil their duties through health data intermediation entities. Do not assume the exemption is permanent in your jurisdiction. Article 50 requires Member States to notify that national law by 26 March 2029.

If you process or technically control priority-category health data, assume the duty applies and confirm the exemption, rather than the reverse.

What are the secondary-use obligations: how do data permits and the health data access bodies change your release process?

This is the part that changes your operating model most.

Under Article 57, each Member State operates one or more health data access bodies. These are the public authorities that decide on access applications, authorise and issue data permits, provide health data users with access inside a secure processing environment, and request data from health data holders. Where the holders are Union institutions, Article 56 puts the Commission in that role.

You do not hand data to researchers directly. The access body requests the relevant data from you, and you compile and prepare it for release. A data permit, defined in Article 2, is the administrative decision that authorises a health data user to process specified data for a specified secondary-use purpose.

The route in is an application. Article 67 sets out the health data access application, which must state the purpose, the data requested, the safeguards, and the retention period. A parallel route exists in Article 69: a health data request that returns only an anonymised statistical result, where the user never touches the underlying records.

Then there is the clock. Article 69 requires the access body to assess a health data request within three months of receipt and, where possible, to provide the response within a further three months. That 3 plus 3 window is the tempo the whole system runs at. It implies you, as a holder, can locate and prepare a governed dataset on demand rather than as a project.

Cost is addressed too. Article 62 lets access bodies and trusted holders charge fees in proportion to the cost of making data available, and those fees may compensate you for compiling and preparing the data. Under Article 57, every issued permit and refusal is published within 30 working days, so the process is a matter of record.

You are not the one judging purpose. The access body does that. Your job is to make the right data available, described and labelled, within the tempo the Regulation assumes.

What must an EEHRS meet: which interoperability and European exchange-format requirements bind electronic health record systems?

If you build, place on the market or put into service EHR systems, a separate regime applies.

Article 15 establishes the European electronic health record exchange format. The Commission sets its technical specifications by 26 March 2027. The format must be commonly used and machine-readable, and must allow transmission of the priority categories between different applications, devices and healthcare providers. Member States must ensure priority-category data is issued in that format, and where it is transmitted by automated means, the receiving provider must accept and be able to read it.

That is EEHRS interoperability stated as a hard requirement, not a recommendation.

Article 2 defines two harmonised software components that sit at the centre of this: the European interoperability software component, which sends and receives priority-category data in the European exchange format, and the European logging software component, which records access to that data. Article 36 requires the Commission to adopt common specifications for the essential requirements in Annex II by 26 March 2027, taking into account medical devices and high-risk AI systems.

The conformity surface is real and provable. Article 28 prohibits misleading claims about an EHR system's interoperability or security. Article 44 gives market surveillance authorities the power to evaluate and require corrective action, recall or withdrawal where an EHR system poses a risk to health, safety, rights or data protection, and to escalate serious incidents across borders.

Wellness applications get their own hook. Article 47 requires an interoperability label where a manufacturer claims compatibility with an EHR system, and Article 48 prohibits automatic data sharing without the natural person's consent under Article 5.

Chapter III timing is longer than the data chapters, but the format and common specifications land in 2027, so design decisions cannot wait for the application date.

What primary-use duties does EHDS add on top of GDPR for patient access and cross-border MyHealth@EU exchange?

Primary use is where EHDS specifies and complements existing GDPR rights rather than replacing them.

Article 5 gives natural persons the right to insert information into their own EHR, clearly distinguished from clinician-entered data. Article 6 requires electronic health data access services to let people request rectification online, in line with Article 16 of the GDPR. Article 12 requires Member States to ensure health professionals can access the priority categories free of charge, including for cross-border care, through health professional access services secured by recognised electronic identification.

Article 10 lets Member States provide a right for natural persons to opt out of access to their data in primary use. Where that right exists, it must be reversible, and access can still be allowed to protect vital interests.

The cross-border layer runs on MyHealth@EU. Article 24 builds supplementary services on that infrastructure, such as telemedicine, health-certificate exchange and translations, and governs how a third country's national contact point can connect, subject to Commission compliance checks and equivalent legal, organisational and cybersecurity measures. The practical duty for a provider is to be connectable and to issue data in the European exchange format under Article 15.

Article 17 leaves the technical implementation of these primary-use rights to Commission implementing acts, so the interface obligations will sharpen before 2029.

How does a health organisation operationalise EHDS: from data inventory to permit workflows to interoperability evidence?

Turn the articles into a sequence.

Start with a data inventory. You cannot meet the 3 plus 3 tempo the access body works to under Article 69 if you do not know where your health data lives, in which systems, and under what controllership. This is the same discovery gap we see in field reviews across regulated sectors: no clear visibility into where sensitive data actually resides.

→ Map your holdings so you can respond when the access body requests data under Article 57, and maintain the dataset descriptions and quality labels that feed the national dataset catalogue referenced in Articles 57 and 78.

→ Build the permit-response workflow. Define who receives the request, who assembles the dataset, who applies pseudonymisation or anonymisation, and who prices the compilation cost you may recover under Article 62.

→ Wire the primary-use paths. Rectification under Article 6, insertion under Article 5, professional access under Article 12, and issuance in the exchange format under Article 15 are system capabilities, not policies.

→ Treat interoperability as evidence. The exchange format, the common specifications under Article 36, and the labelling regime under Article 47 are all provable artefacts.

Ownership is the failure point. Obligations that route into a single compliance inbox stall. EHDS duties belong to distinct owners: clinical systems, data governance, product conformity, and privacy. Route them by domain and timestamp every action.

Where does EHDS overlap with GDPR, NIS2, and the EU AI Act, and how do you avoid mapping the same obligation three times?

EHDS does not stand alone, and Article 1 says so.

Article 1 states the Regulation specifies and complements the GDPR rights of natural persons over their health data, and applies without prejudice to instruments including the Data Governance Act and the Data Act. Article 2 borrows core definitions directly from the GDPR and the Data Governance Act. Article 6 ties rectification to Article 16 of the GDPR, Article 67 requires access applications to demonstrate compliance with Article 6(1) of the GDPR, and Article 65 makes GDPR supervisory authorities competent to enforce the secondary-use opt-out. The same access request touches EHDS release duties and GDPR lawfulness at once.

The AI Act overlap is in the text. Article 1 preserves the AI Act for AI systems that interact with EHR systems, and Article 36 requires the common specifications to take into account high-risk AI systems. An AI developer sourcing health data for training sits inside both regimes.

NIS2 sits underneath as sector security. Health is an essential sector, and EHDS assumes secure processing environments and, under Article 24, cybersecurity measures equivalent to those that apply to Member States for cross-border exchange. The security posture you build for NIS2 is the same posture EHDS depends on.

The trap is mapping the same obligation three times, in three tools, with three owners, and three answers. The fix is structural. One organisational profile, deterministic mapping against every applicable regulation, every obligation traced to a verbatim quote from the source legal text. Answer once, satisfy many. Cross-regulation overlap resolved automatically, not re-implemented per framework.

Map your EHDS, GDPR and NIS2 obligations from a single health-data profile at agrc.ai. Inside 60 minutes you will see your exposure mapped to the obligations that actually apply to you. No AI hallucinations. Source-grounded.

FAQ: EHDS penalties, opt-out handling, data-holder registration, and what to do before the first application date

What penalties apply under EHDS? Article 99 requires Member States to lay down penalty rules for infringements, effective, proportionate and dissuasive, and to notify them to the Commission by 26 March 2027. Health data access bodies also impose administrative fines, which they must report in the biennial activity report required by Article 59. Separately, Article 65 empowers GDPR supervisory authorities to impose fines up to the amount in Article 83 of the GDPR for breaches of the secondary-use opt-out.

How does the opt-out work? There are two. In primary use, Article 10 lets Member States give natural persons a reversible right to opt out of access to their data through the access services. In secondary use, Article 65 confirms a right to opt out from the processing of personal electronic health data, enforced by GDPR supervisory authorities. Confirm your Member State's implementing mechanism for each.

Do health data holders have to register? The Chapter IV duty is to describe your datasets to the health data access body and keep those descriptions and quality labels current, feeding the national dataset catalogue referenced in Articles 57 and 78. That is distinct from the product-conformity regime for EHR systems, whose market surveillance and serious-incident duties sit in Article 44.

What should we do before the first application date? Treat 2027 as the scoping year for the 2029 obligations. Inventory your health data, confirm whether you are a health data holder or exempt under Article 50, design your response workflow against the 3 plus 3 assessment tempo in Article 69, and align your EHR systems with the European exchange format the Commission specifies under Article 15 by 26 March 2027. Regulatory exposure should not be discovered during an incident.