.png){kind=logo}
Germany's health-IT specifications expect services processing health data to run in trusted execution environments, where even the platform operator cannot read patient data. That's not a control enclaive approximates — it's the layer enclaive is.
Proven in German digital health: medi:cus and AnoMed.
Gematik is Germany's national digital-health agency: it specifies and governs the Telematikinfrastruktur and the security requirements for services that process health data — from the electronic patient record to health applications and the cloud platforms beneath them. For vendors and operators, gematik requirements are not one framework among many; they're the gate to the German health market. Two roles recur below. The HCC provider (also: infrastructure provider) operates the host and platform layer under Health Cloud Computing. The Fachdienst is the specialist application — your own service — that processes health data on top of it. Approval is granted per stage, to each of those parties separately.
Three features shape what building for this market means:
GDPR compliance is table stakes here. The gematik-specific hurdles are architectural, and they arrive when you build on modern cloud infrastructure.
Where enclaive delivers the layer the specifications describe, and the evidence each control gives your approval file. Indicative, and pending validation against current specification versions.
Health workloads run in hardware trusted execution environments: memory encrypted during processing and sealed from host OS, hypervisor and operator to the extent the specification requires — the VAU pattern as a deployable runtime, not a research project.
Attestation records per workload showing sealed execution, continuously.
The HCC provider's role is held to the minimum the specification defines: with customer-held keys and attestation-based key release there is no routine readable path to patient data. Residual physical vectors are addressed the way gematik requires — host and infrastructure attestation, defined physical and organizational safeguards, and audit — rather than by claiming impossibility.
Access-path inventory and key-release logs bound to verified workload identities.
Remote attestation lets gematik, auditors, hospitals and data-protection officers independently verify that services run genuine, unmodified code in genuine trusted execution environments.
Integrity reports any authorized party can check — at approval and in every deal after.
Confidential databases and confidential RAG keep patient records and health knowledge bases encrypted in use — including for AI workloads on health data.
Encrypted-in-use coverage for the data layer, not just the application layer.
Attested secure compute for data spaces and research: multiple institutions analyze health data together without any party — or the operator — obtaining a routine readable path to raw records.
Per-party attestation and access evidence for the data-space governance file.
The same sealed runtime deploys on hyperscalers, European clouds and on-prem — managed-cloud economics with the minimized-operator architecture the specifications expect.
Deployment evidence across providers; portability as a documented property.
REQUIREMENT AREAS ARE INDICATIVE OF WHERE THE SPECIFICATIONS CONVERGE, NOT A CONFORMITY CLAIM PER DOCUMENT VERSION, AND NOT EVIDENCE OF A HELD ATTESTATION.
What enclaive supplies is the confidential computing layer for that path. Where our layer has been attested as conforming to the relevant gematik specification, it carries that part of the specification for you: the trusted-execution and attestation architecture arrives built and evidenced instead of becoming a multi-year internal project. The stages above and below it — infrastructure certification and your Fachdienst's own conformance — remain with you and your provider. Our current attestation status for this layer is stated in the briefing, not on this page.
What health platform owners ask
Does deploying enclaive get our service gematik-approved?
No — approval is granted per stage: a certified infrastructure provider, a certified platform layer, and your certified application (Fachdienst). Where our confidential computing layer has been attested as conforming to the relevant specification, it carries that part of the requirement set; your service's conformance work, and the stages either side of ours, remain in scope for you. The box above states the boundary plainly.
We're a health software vendor, not a security company. How much TEE expertise do we need?
Little to none for the runtime itself — that's the design. Your applications run inside confidential VMs, Kubernetes or databases, typically without application-level refactoring; attestation, key release and enclave lifecycle are the platform's job. Integration and operational tooling may still need work, but your team keeps building health features rather than a trusted execution environment.
Can we still use managed cloud, or does this force us on-prem?
You keep the cloud. The sealed runtime deploys on hyperscalers, European providers and on-prem alike — the operator's role is minimized and attested at the workload level, so the specification's architecture and managed-cloud economics stop being a trade-off.
So can the platform operator read patient data or not?
Not through any routine path: with customer-held keys and attestation-based release, there is no operational route from operator privileges to readable health data. But HCC deliberately does not treat that as absolute — the specification keeps the HCC provider inside both the trust base and the threat model, assumes physical attack vectors cannot be ruled out, and therefore requires host attestation, physical and organizational safeguards, and gematik's governance and audit framework on top. The honest formulation is a residual risk reduced and continuously evidenced, not a guarantee.
Hospitals and insurers re-audit us in every deal. Does this shorten that?
Materially. Instead of re-explaining your security concept per customer, you hand over attestation evidence they can verify themselves — the question of who can reach patient data, and under which safeguards, becomes a checkable artifact rather than a meeting series.
We're also in scope of NIS2 as a health-sector entity. Double work?
Largely shared work: the same enforcement layer — encryption in use, minimized operator access, attestation evidence — maps onto NIS2's Article 21 measures as well. One architecture, two mappings. See the NIS2 page for that view.
Bring your specification, your submission plan, or your architecture question
Tell us what you're building — the service type, the gematik procedure ahead of you, and where the trusted-execution requirement currently sits on your roadmap. We'll show you what the sealed runtime looks like for your stack and what evidence your submission gets.
