The European Health Data Space rolls out in phases through 2029 and 2031. Here’s what each phase actually requires from product teams building digital health software in the DACH region and where we’ve seen teams already make decisions they’ll regret.
Most healthtech CTOs we talk to in DACH treat EHDS as „GDPR for medical data”. It isn’t. GDPR tells you what you can’t do with personal data; EHDS tells you what you must do with health data, on a fixed schedule, with technical conformity requirements that touch your product architecture. We unpack the broader picture in our overview of healthcare software development in the DACH region, but EHDS deserves its own deep-dive.
Table of Contents
What EHDS actually is
The European Health Data Space (Regulation (EU) 2025/327) entered into force on 26 March 2025. It creates a single legal and technical framework for two things: giving patients real control over their electronic health records (primary use), and making anonymised or pseudonymised health data available for research, policy and innovation (secondary use).
For a digital health product team, EHDS introduces three new realities. Patients gain a legal right to access, share and port their health data across EU borders through an infrastructure called MyHealth@EU. EHR systems and certain wellness apps will need conformity assessment against a common European interoperability standard – a topic adjacent to the system integration challenges we covered earlier this year. And health data access bodies in each member state will mediate secondary access to your data, including, in some scenarios, data your product generates.
Switzerland is not in the EU, so EHDS does not apply directly. Swiss healthtech serving German or Austrian patients, however, will hit it the moment data crosses the border. We’ve already had two Zurich-based teams ask us to retrofit FHIR conformity into products they shipped 18 months ago.
The 4 deadlines that matter
EHDS does not switch on in one day. The Commission staged it deliberately, partly because the underlying technical specifications were not finished when the regulation passed. Here is the structure your roadmap needs to reflect:
| Date | What goes live | Who is affected |
|---|---|---|
| March 2027 | Secondary use framework, Health Data Access Bodies operational | Anyone holding health data the HDAB can request |
| March 2029 | Primary use for priority categories: patient summaries, ePrescriptions, ePrescription dispensations | EHR systems, prescribing/dispensing software |
| March 2031 | Primary use for remaining categories: lab results, medical images, discharge reports | Lab systems, imaging platforms, hospital EHRs |
| March 2031 | Mandatory conformity for high-risk wellness apps interoperating with EHRs | mHealth and wellness app vendors |
The 2027 deadline is the one teams most often miss. Secondary use does not require your software to do anything new it requires you to be ready to respond when an HDAB asks for data. If your architecture cannot pseudonymise, segment by purpose, and export in the European Electronic Health Record Exchange Format, that request becomes a six-month engineering project under regulatory pressure.
EHDS vs GDPR vs MDR: where they overlap and where they collide
These three regulations are often discussed as if they layer cleanly. They don’t. Here’s how they relate for a typical digital health product:
| Dimension | GDPR | MDR | EHDS |
|---|---|---|---|
| Scope | All personal data | Software with medical purpose | Electronic health data, EHR systems, certain wellness apps |
| Legal basis for processing | Consent or other Art. 6/9 basis | Not relevant – about safety | Adds purpose-specific access regime, partial opt-out for secondary use |
| Technical requirements | Privacy by design (vague) | Risk management, clinical evaluation | Concrete: FHIR-based EEHRxF, conformity assessment of EHR systems |
| Cross-border | Same rules across EU | CE mark = EU-wide | MyHealth@EU infrastructure for actual data exchange |
| Enforcement | Data protection authorities | Notified bodies + competent authorities | Health Data Access Bodies + market surveillance |
The collision point that hurts: GDPR’s „right to be forgotten” and EHDS’s secondary use regime sit in tension when health data is already in a research dataset. The regulation handles this with pseudonymisation and access controls, but your product needs to know the difference between primary-use data (where deletion applies) and secondary-use exports (where it generally does not). Building that separation in retrospectively is painful.
Mapping your EHDS roadmap?
Most teams discover the gaps when their next compliance audit lands, not before. We help DACH healthtech teams identify EHDS exposure across their existing architecture and prioritise what to fix first.
3 product scenarios from our DACH work
Working with teams behind products like mySugr and Selfapy – part of our healthcare and medtech practice – we’ve watched the same architectural decisions surface across very different product categories. Three scenarios show what EHDS readiness actually looks like in practice.
A diabetes management mHealth app sitting outside the strict EHR definition still touches EHDS in two places. If it offers an export feature into a German ePA (elektronische Patientenakte), the export format must align with EEHRxF from 2029. And if the app is classified as a high-risk wellness app under EHDS Annex II, it will need conformity assessment from 2031. We are currently advising one team to begin FHIR R4 alignment now, even though their formal deadline is six years out, because the rebuild cost grows exponentially with feature count.
A B2B mental health platform serving German employers as a covered benefit hits EHDS through its secondary use obligations. Anonymised symptom data, treatment outcomes and engagement metrics are exactly what health data access bodies will request for population health research. The team we worked with discovered that their analytics warehouse, built three years ago, mixed primary identifiable data and secondary research data in ways that made compliant export practically impossible. Six months of refactoring, mostly avoidable.
A clinical decision support system for hospitals, classified as MDR Class IIa, overlaps EHDS most directly. From 2029 it will need to read and write priority EHR categories in EEHRxF, and its conformity assessment will need to demonstrate this capability. For Polish nearshore teams supporting DACH hospital vendors, this is the deadline to plan against – and the one most under-staffed in current 2026 roadmaps.
Where most teams will get stuck
3 technical decisions determine whether EHDS lands as a six-week task or a six-month project.
HL7 FHIR readiness, specifically R4 or R5 with European profiles. EEHRxF is built on FHIR. Teams still using HL7 v2, proprietary JSON or older FHIR versions face migration work that compounds with every new feature shipped before the rebuild. If you are starting a new module today, start it on FHIR R4 with the European base profiles and if you’re carrying legacy HL7 v2 or proprietary formats, this is exactly where our system integration services come in.
A consent and purpose layer separate from your auth system. EHDS distinguishes primary use (treatment, patient access) from secondary use (research, policy) and lets patients opt out of certain secondary use categories. If your data model treats access as a single boolean – authenticated or not, you will rebuild it. The teams that handled this cleanly modelled purpose as a first-class attribute on every data record from the start. For products already in production, this often means a refactoring engagement rather than a rewrite.
Cross-border identity and patient summary support. MyHealth@EU assumes patients can be identified across member states and their summaries rendered in any EU language. For products operating only in Germany today but planning Austrian or Swiss expansion, the patient summary structure and the language layer are decisions worth making before the customer base forces them.
What we’d do if we were starting today
If we were building a new digital health product for DACH in 2026 with a 2029 horizon, we would commit to FHIR R4 from day one, model purpose as a first-class concept in the data layer, and budget two engineering quarters in 2027 for EEHRxF conformity. None of these are exotic – they are just expensive to retrofit. We’ve documented how this plays out in real product timelines across our case studies.
The teams that will struggle in 2029 are not the ones building today. They are the ones who shipped in 2023 and 2024 on architectures that made sense for the regulatory landscape that existed then. EHDS readiness is, at its core, an architectural conversation — not a checklist.
Let’s pressure-test your roadmap together
If you are scoping EHDS readiness for a product already in market, or designing a new one with the 2029 horizon in mind, we’d be glad to compare notes. We’ve been working through these decisions with healthtech teams in Germany, Austria and Switzerland since before the regulation was finalised — including with clients like mySugr/Roche, Selfapy and 9amHealth.
Book a 30-minute consultation → · See how we work →
Or if you’d rather start with the bigger picture, our healthcare and medtech practice page covers our methodology and tech stack.
