Building Compliant Healthcare Software in Europe: MDR, GDPR and the Engineering Reality

Healthcare software in Europe operates at the intersection of three regulatory frameworks: the EU Medical Device Regulation (MDR) for anything that touches clinical decisions, the General Data Protection Regulation (GDPR) for all personal health data, and a patchwork of national standards — Germany's DiGA framework, the Netherlands' NEN 7510, the UK's DCB 0129. We have built platforms across all three and the lesson is always the same: compliance is an architecture decision, not a paperwork exercise.

When your software becomes a medical device

Under MDR, if your software is intended to provide information used to make a clinical decision — diagnosis, monitoring, treatment suggestion — it is a medical device and must be certified. This applies even to purely software-based products (Software as a Medical Device, SaMD). The classification is based on intended purpose, not on what the code actually does. A symptom checker that suggests 'see a doctor' may be Class I. A triage tool that prioritises patients is likely Class IIa. An algorithm that recommends dosage changes is Class IIb or III.

GDPR for health data: beyond consent

Health data is a 'special category' under GDPR Article 9. The lawful basis for processing is rarely simple consent — for clinical systems it is more often 'necessary for reasons of public health' (Art. 9(2)(i)) or 'necessary for the provision of healthcare' (Art. 9(2)(h)). This distinction matters because consent can be withdrawn at any time, potentially breaking your data pipeline mid-treatment. We design systems to support multiple lawful bases and document the legal rationale per data flow, not per application.

Data residency and infrastructure

EU patient data must remain in EU data centres. This is not optional and it is not satisfied by a US cloud provider's 'EU region' toggle if the parent company is subject to US CLOUD Act jurisdiction. Our default healthcare stack uses either a European cloud provider or a contractually firewalled EU region with explicit Data Processing Agreements. Database encryption at rest and in transit is baseline, not a feature.

Automated compliance evidence

The most expensive part of healthcare software is not building it — it is proving to regulators that you built it correctly. Design History Files, risk management records, traceability matrices, test evidence. We automate as much of this as possible: CI pipelines that generate test-coverage reports, deployment logs that map to requirement IDs, and audit trails that export in the format your Notified Body expects. This is not glamorous work but it is the difference between a three-month certification process and a twelve-month one.

National frameworks to watch

• Germany DiGA: Digital Health Applications that want reimbursement through statutory health insurance must pass BfArM evaluation. The bar includes interoperability (FHIR), data security, and clinical evidence.
• Netherlands NEN 7510: The Dutch information security standard for healthcare. Essentially ISO 27001 with healthcare-specific controls. Mandatory for any organisation processing Dutch health data.
• UK DCB 0129 / 0160: Clinical risk management standards for health IT systems. Required for NHS suppliers.
• Belgium eHealth: The Belgian eHealth platform requires specific authentication (eID/itsme) and interoperability standards for healthcare software.

How we approach healthcare projects

We start every healthcare engagement with a regulatory triage: what classification does this product fall under, what data categories are involved, and what national frameworks apply. This shapes architecture decisions before a single line of product code is written. The result is a system that generates compliance evidence as a by-product of normal development, not as a separate workstream bolted on at the end.