EHDS Sovereign Hosting: Protecting Medical Records Under EU Law

The European Health Data Space (EHDS) Regulation is the EU’s most consequential piece of health data legislation since GDPR. It establishes a binding framework for how electronic health records, genomic data, prescriptions, imaging files and clinical trial results must be stored, shared, accessed and governed across all Member States. For compliance officers, CISOs and data protection officers in hospitals, health insurers and public health bodies, the regulation raises a question that can no longer be deferred: can the infrastructure currently holding patient records actually satisfy what the EHDS demands?

What the EHDS Regulation Actually Requires

The EHDS creates two distinct regimes, primary use and secondary use, each with its own access control obligations and legal basis requirements.

Under the primary-use provisions, healthcare providers must give patients access to their own electronic health records in a structured, portable format across all Member States. This requires a minimum common dataset: patient summaries, ePrescriptions, laboratory results, medical imaging and discharge reports. The infrastructure holding these records must support real-time access by authorised clinicians while enforcing strict role-based controls that prevent unauthorised lateral movement across patient files.

Secondary use, meaning the processing of health data for research, statistics, public health policy or commercial product development, is governed by a new category of national authority: the Health Data Access Body (HDAB). Patients must be granted a right to opt out of secondary use for purposes other than those strictly necessary for public health. Processors applying for secondary-use access must do so through a standardised application process, receive a specific data permit, and process only the minimum dataset required for the declared purpose. Secondary-use data must be de-identified or pseudonymised before release, and the EHDS prohibits re-identification by design.

The US-Cloud Problem: GDPR Article 9, FISA 702 and the CLOUD Act

Storing electronic health records in a US-controlled cloud environment creates a structural legal conflict that contractual safeguards cannot resolve.

Health data is special-category personal data under GDPR Article 9, which prohibits its processing unless an explicit legal basis applies, typically explicit patient consent or a specific statutory obligation for public health. The obligation extends to every party that touches the data, including cloud infrastructure providers. A US-headquartered provider, regardless of where its servers physically sit, remains subject to the Foreign Intelligence Surveillance Act (FISA) Section 702 and the CLOUD Act, both of which permit US government agencies to compel disclosure of data held on non-US servers without notifying the data subject or the relevant EU supervisory authority.

The European Data Protection Supervisor has been explicit on this point. As the EDPS stated in its opinion on the EHDS proposal: “The transfer of personal health data to third countries without adequate safeguards is one of the most serious risks we face in the digital transformation of healthcare. Encryption alone does not resolve the jurisdictional question.” The reason encryption alone is insufficient is that a US-controlled provider holds or can be compelled to produce the decryption keys.

National health data laws compound this exposure. Germany’s Patientendaten-Schutz-Gesetz, France’s Hébergeurs de Données de Santé certification scheme, and the Netherlands’ NEN 7510 standard each impose additional localisation or certification requirements that US hyperscalers cannot satisfy without a specific national certification that few hold.

“Health data is among the most sensitive categories of personal data. Its processing requires not only a lawful basis under Article 9 but also robust technical safeguards that prevent unauthorised access, including access by cloud providers themselves.” Andrea Jelinek, former Chair of the European Data Protection Board, EDPB Guidelines on special-category data.

The average cost of a healthcare data breach globally reached USD 10.93 million in 2023, the highest of any sector for the thirteenth consecutive year (IBM Cost of a Data Breach Report 2023). Healthcare was also the most targeted sector for ransomware attacks in Europe in 2023 according to ENISA’s Threat Landscape 2023. These figures make the cost-benefit calculation for sovereign infrastructure increasingly straightforward.

Technical and Organisational Measures: EHDS Meets NIS-2

Healthcare providers are classified as essential entities under the NIS-2 Directive (Directive (EU) 2022/2555), which means they face the directive’s most demanding tier of obligations. NIS-2 and the EHDS converge on several specific technical requirements.

Encryption at Rest and in Transit

All patient data must be encrypted at rest using algorithms that are current and auditable, meaning AES-256 or equivalent. Encryption in transit requires TLS 1.3 as the minimum, with certificate pinning for API connections. The key question under both EHDS and NIS-2 is who controls the encryption keys: only the healthcare organisation or its designated national trust service should hold master keys. A cloud provider that can access keys on request cannot satisfy this requirement.

Audit Logging and Tamper Evidence

Every access to a patient record, whether read, write, export or deletion, must generate an immutable log entry. Logs must capture the identity of the accessing user, their role, the timestamp, the specific record accessed, and the terminal or application used. Under NIS-2, significant incident notifications must reach the national Computer Security Incident Response Team (CSIRT) within 72 hours. Audit logs must therefore be available and searchable in real time, not archived in a format that requires days to retrieve.

Break-Glass Access Controls

Emergency clinical situations sometimes require a treating clinician to access records they would not normally be permitted to view. The EHDS accommodates this through a “break-glass” mechanism: a structured override that grants temporary access, records the justification provided by the clinician, triggers immediate notification to the data controller, and requires post-hoc review. Implementing break-glass correctly means the override is logged with the same immutability as ordinary access, and the patient must be notified after the fact in accordance with Article 9 transparency requirements.

Swiss FADP Hosting as a Jurisdictional Solution

Switzerland is recognised by the European Commission as providing adequate data protection under GDPR Article 45. The revised Swiss Federal Act on Data Protection (nDSG, commonly referred to as the Swiss FADP), in force since September 2023, classifies health data as sensitive personal data requiring heightened protection, directly paralleling GDPR Article 9. Swiss courts apply a strict dual-criminality test before permitting data disclosure to foreign authorities, and Switzerland is not party to the CLOUD Act framework. A US government agency cannot compel a Swiss-incorporated hosting provider to hand over patient records via a domestic subpoena.

For a German hospital or a Belgian health insurer that needs to demonstrate to its supervisory authority that patient data cannot be accessed by foreign intelligence services, Swiss-incorporated hosting under the nDSG provides a defensible and auditable answer that no US-parent-controlled provider can match.

Interoperability Without Data Leaving the Sovereign Perimeter

A common objection to sovereign hosting is that it will prevent participation in cross-border health data exchanges. The EHDS requires Member States to support HL7 FHIR (Fast Healthcare Interoperability Resources) R4 as the standard API for patient summary exchange, and IHE (Integrating the Healthcare Enterprise) profiles including XDS.b for document sharing and MHD for mobile health document access.

Both can be deployed entirely within a sovereign perimeter. A FHIR R4 server such as HAPI FHIR can be hosted on-premises or in a Swiss data centre, exposed through a dedicated API gateway that enforces mutual TLS authentication, OAuth 2.0 scoped tokens, and per-request audit logging. IHE XDS.b and MHD profiles can run on the same infrastructure to support regional health information exchanges. The FHIR endpoints connect to authorised external systems, including national MyHealth record platforms, using encrypted channels that terminate at the sovereign boundary. Patient data never transits a public cloud intermediary or a US-controlled routing layer.

Building a Regulator-Ready Audit Package

After migrating patient records from a public cloud to a sovereign environment, the organisation must be able to demonstrate compliance to its national data protection authority, its healthcare regulator, and, under NIS-2, to the national CSIRT. A complete audit package contains six categories of evidence.

First, a current and versioned asset inventory covering every system, API endpoint and data store that holds or processes patient data, mapped to the EHDS primary and secondary use categories. Second, documented risk assessments, updated at least annually, that address both technical vulnerabilities and jurisdictional risks. Third, encryption certificates and key management policies that prove the organisation, not any third party, controls decryption. Fourth, tamper-evident audit logs retained for the period required by national transposition law, typically five to seven years, demonstrating every access event including break-glass overrides. Fifth, incident response playbooks with timestamped records of past drills and, where applicable, real incident responses. Sixth, supply-chain security documentation: evidence that every software component and hardware vendor in the sovereign stack has been assessed for integrity, including the FHIR server software, the operating system and the data centre’s physical security certifications.

The Irish Data Protection Commission’s EUR 265 million fine against Meta in 2022 for special-category data exposure (Irish DPC, 2022) illustrates what regulators will do when the audit trail is absent or when the legal basis for processing sensitive data cannot be demonstrated. A sovereign infrastructure that generates its own audit evidence, without dependence on a provider’s proprietary logging system, removes that vulnerability.

FAQ

Does the EHDS Regulation prohibit storing electronic health records in US-controlled cloud services?

The EHDS does not contain an explicit ban, but its requirements for access control, audit logging and the legal basis for secondary use, combined with GDPR Article 9 and the structural reach of the US CLOUD Act and FISA 702, make it very difficult for US-controlled cloud providers to offer compliant storage. Any US-parent-owned service can be compelled to disclose data to US authorities without an EU court order, which is incompatible with the lawful basis requirements for special-category health data.

What is the difference between primary and secondary use of health data under the EHDS?

Primary use covers the direct care relationship: treating clinicians accessing a patient’s record for diagnosis and treatment. Secondary use covers research, statistics, policy-making and commercial analytics. The EHDS requires Member States to establish Health Data Access Bodies to govern secondary use, and patients must be given the right to opt out. Secondary-use datasets must be de-identified or pseudonymised and cannot be processed for purposes incompatible with those declared at the point of access request.

How does Swiss FADP (nDSG) treat health data, and does it offer stronger protection than GDPR alone?

The revised Swiss Federal Act on Data Protection, in force since September 2023, classifies health data as sensitive personal data requiring heightened protection, mirroring GDPR Article 9. Switzerland holds EU adequacy status under Article 45 GDPR. Critically, Swiss hosting places data outside US jurisdiction: Switzerland is not party to the CLOUD Act framework, and Swiss courts apply strict dual-criminality tests before permitting data disclosure to foreign authorities.

Can a sovereign Nextcloud deployment expose HL7 FHIR APIs to regional health information exchanges without losing data control?

Yes. FHIR R4 APIs can be deployed on-premises or in a sovereign Swiss data centre and exposed via a dedicated API gateway that enforces mutual TLS, role-based access tokens and per-request audit logging. Data never transits a third-country intermediary. IHE XDS.b and MHD profiles can be layered on the same infrastructure to support cross-organisational document sharing within the EU without any dependency on public cloud routing.

What should a NIS-2 audit package for a healthcare organisation contain?

A complete NIS-2 audit package should include: a current asset inventory covering all systems that process patient data; documented risk assessments updated at least annually; encryption certificates and key management policies for data at rest and in transit; tamper-evident audit logs retained for at least the period specified by national transposition law, typically five to seven years; incident response playbooks with defined detection, containment and notification timelines (72 hours to the national CSIRT for significant incidents); and evidence of supply-chain security checks on all software and hardware vendors in the sovereign stack.