Healthcare Software Development in Europe: GDPR, MDR and the AI Act

Building healthcare software for Europe means meeting several regimes at once. GDPR sets the baseline for health data. The Medical Device Regulation decides whether your software is a regulated device. The AI Act adds a high-risk regime for medical AI. The European Health Data Space sets new requirements for EHR systems. National routes such as Germany's DiGA and England's DTAC decide whether health systems will pay for or adopt your product.

This guide summarises our research into what each of these means for a software team in 2026. We build for clients in Germany, Switzerland and the UK. It is engineering guidance, not legal advice. For the cross-market view, see our healthcare page.

GDPR: special-category data from the first sprint

Under GDPR, health data is special-category data. You need an Article 9 condition on top of an Article 6 lawful basis, a DPIA for large-scale processing (Article 35), and data protection by design and by default (Article 25). In engineering terms:

• Minimise per feature. List the exact fields each feature and model needs, and send nothing more.
• Pseudonymise where the task allows. Pseudonymised data is still personal data under GDPR, but pseudonymisation is a recognised safeguard.
• Host in the EU or Switzerland and keep a register of sub-processors, including model providers and observability tools.
• Make rights self-service where possible: access, export, correction and erasure.

Switzerland runs its own regime. The revised Federal Act on Data Protection, in force since 1 September 2023, treats health, genetic and biometric data as sensitive and introduces privacy by design and impact assessments. It is close to GDPR in approach, but the details differ.

MDR rule 11: is your software a medical device?

Under the Medical Device Regulation (EU) 2017/745, software with a medical intended purpose is a medical device, and Annex VIII Rule 11 sets its class. Software that provides information used to take diagnostic or therapeutic decisions is class IIa at minimum. It is IIb if those decisions could cause serious deterioration or surgical intervention, and III if they could cause death or irreversible deterioration. Class IIa and above need a notified body. MDCG 2019-11 is the main guidance on qualification and classification.

Intended purpose drives everything, so we settle it in discovery. A symptom-tracking diary and a tool that recommends a dose may share most of their code, but they are regulated very differently. Where the product is a device, we use an IEC 62304-style software lifecycle and ISO 14971 risk management from the first sprint.

The EU AI Act: new dates for high-risk medical AI

Under the AI Act, AI that is a medical device, or a safety component of one, and that requires third-party conformity assessment is high-risk. That brings risk management, data governance, technical documentation, automatic logging, transparency, human oversight, accuracy and robustness requirements. Prohibited practices have applied since February 2025.

The timeline has changed. The Digital Omnibus on AI, Regulation (EU) 2026/1744, entered into force on 27 July 2026. It moved high-risk obligations to 2 December 2027 for Annex III systems and 2 August 2028 for AI in products covered by Annex I legislation, which includes medical devices. The extra time is useful, but it doesn't change what needs to be built: dataset provenance, versioned models, evaluation and bias reports, human-in-the-loop interfaces and logs. Teams that build these in now won't have to reconstruct them later. Our post on HIPAA- and GDPR-compliant AI covers the practices in detail.

The European Health Data Space

The European Health Data Space Regulation (EU) 2025/327 entered into force on 26 March 2025 and applies in phases:

• March 2027: deadline for the Commission's key implementing acts.
• March 2029: cross-border exchange of the first priority categories (patient summaries, ePrescriptions/eDispensations), and secondary-use rules for most categories.
• March 2031: the second group (medical images, lab results, hospital discharge reports).
• March 2035: third countries and international organisations can apply to join HealthData@EU for secondary use.

For anyone building EHR systems or modules, the EHDS adds pre- and post-market requirements for interoperability and logging. Choosing HL7 FHIR and structured, coded data now is the cheapest way to prepare.

National routes: Germany's DiGA and England's DTAC

Germany. Under the DiGA procedure, digital health applications can be prescribed and reimbursed under statutory health insurance after BfArM review. Key points from the official description:

• A DiGA must be a medical device in class I, IIa or IIb.
• BfArM usually decides within three months, extendable by up to three more in justified cases.
• Provisional listing gives up to 12 months to prove a positive care effect, extendable by a further 12 in exceptional cases.
• Applicants must show data protection, information security (including ISO 27001 ISMS evidence and remediated penetration-test findings) and interoperability.

England. NHS buyers assess products against the Digital Technology Assessment Criteria, which cover clinical safety, data protection, technical security, interoperability and usability and accessibility. NHS England published a refreshed DTAC form on 4 March 2026 with 25% fewer questions, and full transition was due by 6 April 2026. Clinical safety evidence comes from DCB0129, which requires a clinical safety officer, a hazard log and a safety case from the manufacturer, while deploying organisations follow DCB0160.

Mistakes we see most often

• Classifying late. Teams build a 'wellness' app, add a recommendation feature, and only then find they have a class IIa device needing a notified body.
• Treating the DPIA as paperwork. Its findings should change the design, for example by dropping fields, shortening retention or moving processing in-region.
• Ignoring the observability stack. Error trackers and log platforms can capture full payloads, including health data, outside the agreed region.
• One market at a time. Building for Germany first and then retrofitting NHS or Swiss requirements costs more than designing for the shared core (GDPR, FHIR, clinical risk management) from the start.

How we build healthcare software for Europe

1. Intended purpose and classification first. Decide on MDR Rule 11 and AI Act status in discovery, and record the reasoning.
2. EU or Swiss hosting with a sub-processor register, data-transfer documentation and retention schedules that cover logs.
3. FHIR-first interoperability with national profiles where they exist, so EHDS, DiGA and NHS integrations don't require rewrites.
4. Evidence as a by-product of delivery. The DPIA, hazard log, test reports and penetration-test results are updated with each release.
5. AI with oversight built in: sources and uncertainty shown to the user, overrides recorded, models and prompts versioned and evaluated.

We bring consumer-health product experience from Ealthiness, a mobile fitness and wellbeing app we designed and built, and large-scale platform engineering from our work for A Place For Mom. For DiGA-ready apps or NHS-facing tools, see our AI in healthcare and mobile app development services, or contact us.