# Navigating EU Healthcare Compliance: EHDS, NIS2, MDR, and the Regulatory Stack Every Health IT Team Must Understand

> A scope-led engineering guide to GDPR, NIS2, MDR/IVDR and phased EHDS requirements, with primary sources and practical evidence for health IT teams.

Author: Ala Ben Aicha

Canonical page: https://alabenaicha.me/insights/eu-healthcare-compliance-landscape

Updated: 2026-09-19

## Direct answer

For a health IT team, “EU healthcare compliance” is four stacked regimes, not one certificate: GDPR for personal data (including Art. 9 health data), NIS2 for cybersecurity of essential/important entities, MDR/IVDR if the software is a medical device, and EHDS for cross-border record exchange on a phased 2027–2031 timetable. Scope the product against each regime with primary-law links before writing controls.

## Start with scope, not a technology checklist

European healthcare software can fall under several different regimes. GDPR concerns personal-data processing; NIS2 concerns covered entities and cybersecurity; MDR and IVDR concern qualifying medical devices; EHDS introduces phased health-data and EHR-system requirements. None of these labels alone establishes that every obligation applies to a particular application.

For a practical review, record the organisation, countries, intended use, data flows and contractual role first. Then assign each applicable obligation an owner, supporting evidence and a review date. A generic “EU compliant” claim is less useful than a traceable scope decision.

## GDPR: separate purpose, permission and safeguards

Identify the Article 6 basis and, for health data, the relevant Article 9 condition. Also assess recipients, retention, access and transfer arrangements. Neither patient consent nor EU hosting is a universal shortcut to compliance. Use the [GDPR text](https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng) as the starting point.

Two engineering workstreams help keep this concrete:

* [Patient-rights workflows](https://alabenaicha.me/insights/gdpr-health-data-rights-integration): verify a request, determine its scope, execute it across systems and reconcile failures.
* [Health-data architecture](https://alabenaicha.me/insights/gdpr-compliant-healthcare-data-architecture): document data lineage, access boundaries, retention jobs and restore behaviour.

For example, a correction request and a record-retention requirement should not compete through undocumented deletion logic. Record the decision and propagate the approved correction without silently rewriting clinical history.

## NIS2: check entity scope and national implementation

Healthcare and public administration are among the sectors addressed by NIS2. That does not make every healthcare supplier or public body an essential entity. Entity type, size, specific inclusion rules and national implementation matter. Start with the Commission’s [NIS2 overview](https://digital-strategy.ec.europa.eu/en/policies/nis2-directive) and the relevant national authority.

For a potentially covered organisation, prepare an operational evidence pack: system ownership, supplier dependencies, access reviews, incident escalation, backup recovery exercises and vulnerability handling. Set reporting deadlines from the applicable rules and incident classification; do not use a generic checklist as the reporting policy. The [English NIS2 IT-team playbook](https://alabenaicha.me/insights/nis2-healthcare-it-teams) isolates Article 23 clocks; the [French sibling](https://alabenaicha.me/insights/nis2-healthcare-instrumentation) covers ANSSI and CERT-FR.

A useful integration exercise is to disable one downstream system in a test environment. Verify detection, escalation, queue growth, recovery and reconciliation. This reveals gaps that a policy document alone cannot show.

## MDR and IVDR: establish the intended medical purpose

A clinical application is not automatically a medical device, and an AI label does not assign a risk class. Assess the intended purpose and each relevant module before applying classification rules. Software acting on in-vitro diagnostic data may need an IVDR assessment rather than an MDR-only review. Consult [MDCG software guidance](https://health.ec.europa.eu/latest-updates/update-mdcg-2019-11-rev1-qualification-and-classification-software-regulation-eu-2017745-and-2025-06-17_en).

The [MDR software guide](https://alabenaicha.me/insights/eu-mdr-software-medical-device-guide) explains the Rule 11 decision branches. Keep product claims, hazard analysis, requirements and validation evidence aligned. Changes to the intended use need regulatory review even when the code change looks small.

## EHDS: distinguish entry into force from application

EHDS entered into force in March 2025. The Commission identifies March 2029 and March 2031 as major phased application milestones for different priority data categories. Detailed technical requirements depend on the applicable specifications and implementing acts. This is not a blanket instruction to deploy a FHIR R4 API today. Check the [official EHDS timeline](https://health.ec.europa.eu/ehealth-digital-health-and-care/european-health-data-space-regulation-ehds_en).

Maintain a versioned dependency register for exchange formats, terminology, national connections and onboarding requirements. The [cross-border exchange guide](https://alabenaicha.me/insights/cross-border-patient-data-exchange-europe) separates the exchange mechanism from identity and access decisions.

## Turn the assessment into a delivery backlog

| Workstream                    | Concrete engineering evidence                                    | Review trigger                            |
| ----------------------------- | ---------------------------------------------------------------- | ----------------------------------------- |
| Data protection               | Data-flow map, access matrix, retention and rights-request tests | New purpose, recipient or data category   |
| Cybersecurity                 | Incident runbook, supplier inventory, recovery exercise          | Infrastructure or supplier change         |
| Medical-device assessment     | Intended-use statement, risk analysis, validation traceability   | Changed medical purpose or decision logic |
| Cross-border interoperability | Profile versions, terminology mappings, conformance results      | New service or national connection        |

These rows are an engineering planning aid, not a determination of legal applicability. For AI functionality or country-specific health-system rules, add a separate assessment before implementation rather than assuming the four rows cover everything.

## A practical next step

Choose one critical workflow—such as an order becoming a corrected diagnostic report—and follow it end to end. Identify every system, responsible team, access decision and failure path. Connect the result to the relevant legal assessment and acceptance tests. If you need implementation support, review [digital health interoperability services](https://alabenaicha.me/services/digital-health-interoperability).