Use Case · Gesundheitswesen
Klinische Entscheidungsunterstützung & Diagnostik—ohne KI-Zugriff auf Patientenidentität
The Veil ermöglicht es Gesundheitsorganisationen, KI für klinische Entscheidungsunterstützung, Diagnosehilfe und Populationsgesundheitsanalysen auf pseudonymisierten Patientenakten einzusetzen — das Modell sieht nie Patientennamen, Versichertennummern oder Krankenversicherungskennzeichen. Die Architektur richtet sich an den Privacy-by-Design- und Datenminimierungsanforderungen aus, die DSGVO Artikel 9, MDR Annex VIII Regel 11 und nationale Gesundheitsdatenregelungen stellen — architektonische Ausrichtung, keine vorliegende Zertifizierung.
Die Datenschutzhürde für KI im Gesundheitswesen
Gesundheitsdaten fallen unter DSGVO Artikel 9 als besondere Kategorie, die eine ausdrückliche Einwilligung oder eine spezifische Rechtsgrundlage für die Verarbeitung erfordert. Klinische KI-Systeme benötigen oft umfangreiche Patientenhistorien für nützliche Unterstützung, doch jeder zusätzliche Datenpunkt erhöht die Schwere eines potenziellen Datenlecks. Eine einzige kompromittierte Diagnose-KI könnte Tausende von Patientenakten offenlegen — einschließlich Diagnosen, Medikationen und genetischer Marker.
Die Medizinprodukteverordnung (MDR) fügt eine weitere Ebene hinzu: KI-Systeme, die klinische Entscheidungsunterstützung bieten, können als Medizinprodukte gelten (MDR Anhang VIII, Regel 11), was Post-Market-Surveillance- und Risikomanagement-Pflichten mit sich bringt. The Veil adressiert sowohl Datenschutz als auch Gerätesicherheit, indem die KI-Komponente ausschließlich pseudonymisierte Feature-Sets verarbeitet.
So funktioniert The Veil im Gesundheitswesen
| Phase | Was passiert | Wo |
|---|---|---|
| 1. Erfassung | Klinische Datensätze gelangen in Sandbox A. Patientennamen, Versichertennummern, Geburtsdaten und Adressen werden durch kryptographische Token ersetzt. Klinische Inhalte (Symptome, Laborwerte, Bildgebungsmerkmale) werden durchgeleitet. | Sandbox A (PII) |
| 2. KI-Analyse | Pseudonymisierte Feature-Sets fließen an Sandbox B. Das KI-Modell liefert Diagnoseunterstützung, Therapieempfehlungen oder Populationsanalysen — ausschließlich auf Token-Basis, nie auf Patientenidentitäten. | Sandbox B (KI) |
| 3. Klinischer Output | Die KI liefert Diagnosevorschläge, Risikostratifizierungen oder Kohortenanalysen, zugeordnet zu Token. Zu keinem Zeitpunkt existieren patientenidentifizierbare Daten in Sandbox B. | Sandbox B (KI) |
| 4. Re-Linkage | Für Behandlungsentscheidungen: Token werden in Sandbox A per Break-Glass-Mechanismus zurück mit der Patientenidentität verknüpft. Re-Linkage erfordert Klinikautorisierung und erzeugt einen vollständigen Audit Trail. | Bridge (kontrolliert) |
KI-Use-Cases im Gesundheitswesen
Klinische Entscheidungsunterstützung
Die KI analysiert pseudonymisierte klinische Merkmale — Symptomcluster, Laborwertbereiche, als kodierte Token repräsentierte Medikationshistorien — um Differentialdiagnosen vorzuschlagen oder Medikamenteninteraktionen zu flaggen. Der behandelnde Arzt sieht den KI-Output erst nach Re-Linkage mit seinem Patienten verknüpft.
- Differentialdiagnose-Vorschläge basierend auf kodierten Symptommustern
- Medikamenteninteraktions-Warnungen auf tokenisierten Medikationslisten
- Behandlungsprotokoll-Matching ohne Offenlegung von Patientendemographie gegenüber dem Modell
Diagnosehilfe mit pseudonymisierten Datensätzen
Medizinische Bildgebungsmerkmale, Pathologieergebnisse und genomische Marker werden extrahiert und tokenisiert, bevor das Diagnosemodell sie verarbeitet. Die KI operiert auf abstrakten Feature-Vektoren: „Token-9b2e zeigt Merkmalsmuster konsistent mit Stadium-II-Indikatoren“ — nie: „Frau Müller hat einen Tumor.“
- Bildanalyse auf de-identifizierten DICOM-Daten mit entfernten Patienten-Headern
- Pathologie-Mustererkennung auf tokenisierten Gewebeproben-Daten
- Genomische Risikobewertung, bei der die KI nie die Person hinter dem Genom sieht
Populationsgesundheitsanalysen auf de-identifizierten Kohorten
Aggregierte Analysen über Tausende pseudonymisierter Patientenakten ermöglichen Populationsgesundheits-Insights — Krankheitsprävalenz-Trends, Behandlungsergebnis-Vergleiche, Ressourcenallokations-Modellierung — ohne dass einzelne Patienten in der KI-Umgebung identifizierbar sind.
- Epidemiologische Trendanalyse auf Token-Level-Kohortendaten
- Therapieeffektivitäts-Vergleiche über pseudonymisierte Patientengruppen
- Krankenhaus-Ressourcenplanung auf Basis anonymisierter Bedarfsmuster
Regulatorisches Ausrichtungs-Mapping
| Regulierung | Anforderung | The Veil Antwort |
|---|---|---|
| DSGVO Art. 9(1) | Verbot der Verarbeitung besonderer Kategorien personenbezogener Daten ohne explizite Grundlage | KI-Sandbox verarbeitet pseudonymisierte Feature-Sets, keine identifizierbaren Gesundheitsdaten — reduziert die Rechtsgrundlage-Anforderung für die KI-Verarbeitungsschicht |
| DSGVO Art. 9(2)(h) | Verarbeitung für Zwecke der Gesundheitsvorsorge oder Arbeitsmedizin | Re-Linkage für klinische Maßnahmen fällt unter die Rechtsgrundlage der Gesundheitsversorgung; die KI-Analyse selbst operiert auf nicht-identifizierbaren Token |
| DSGVO Art. 35 | Datenschutz-Folgenabschätzung | Die architektonische Trennung von The Veil reduziert DSFA-Risikobewertungen erheblich, indem Identitätsexposition in der KI-Verarbeitungsumgebung eliminiert wird |
| MDR Anhang VIII, Regel 11 | Klassifizierung von Software, die diagnostische Informationen liefert | The Veil isoliert die KI-Komponente; die Risikomanagement-Dokumentation weist nach, dass Patientenidentität architektonisch von der Medizinproduktegrenze ausgeschlossen ist |
| MDR Art. 10(9) | Post-Market-Surveillance | Audit Trails in der Bridge-Schicht bieten vollständige Rückverfolgbarkeit von KI-Outputs und Re-Linkage-Ereignissen für regulatorisches Reporting |
| Nationale Gesundheitsdatengesetze | Jurisdiktionsspezifische Anforderungen (z. B. BDSG §22, Österr. GTelG, Schweizer DSG) | Die Pseudonymisierungsschicht von The Veil erfüllt die „angemessenen Schutzmaßnahmen“, die in den meisten nationalen Gesundheitsdaten-Frameworks verlangt werden |
Dies sind architektonische und evidenzschichtliche Ausrichtungen, keine gehaltenen Zertifizierungen. Zertifizierungs-Roadmap auf Anfrage verfügbar.
Break-Glass Re-Linkage für klinische Entscheidungen
Das Gesundheitswesen erfordert schnellere Re-Linkage als andere Sektoren. The Veil unterstützt einen Break-Glass-Mechanismus für zeitkritische klinische Szenarien:
- Autorisierter Arzt löst Re-Linkage mit rollenbasierten Zugangsdaten aus
- Jedes Break-Glass-Ereignis wird protokolliert: Zeitstempel, Arzt-ID, Patienten-Token und klinische Begründung
- Post-hoc-Review-Workflow benachrichtigt den Datenschutzbeauftragten für Audit innerhalb von 24 Stunden
- Re-Linkage-Umfang ist auf die spezifischen Token beschränkt, die für die klinische Entscheidung relevant sind — keine Massen-De-Pseudonymisierung
Breach-Szenario: Was ein Angreifer erhält
Wenn ein Angreifer die KI-Sandbox (Sandbox B) kompromittiert, erhält er:
- Klinische Insights und Diagnosevorschläge, zugeordnet zu bedeutungslosen kryptographischen Token
- Populationsgesundheitsstatistiken ohne Pfad zur individuellen Patientenidentifikation
- Therapieempfehlungsmodelle, die Token-IDs referenzieren, keine Personen
Keine Patientennamen. Keine Versichertennummern. Keine Krankenversicherungskennzeichen. Keine Geburtsdaten. Das Token-zu-Patient-Mapping existiert ausschließlich in Sandbox A, hinter einer separaten Sicherheitsgrenze.
Kernaussagen für CISOs im Gesundheitswesen
- DSGVO Artikel 9 Anforderungen an besondere Kategorien werden adressiert, indem die KI-Schicht nie identifizierbare Gesundheitsdaten verarbeitet
- Die MDR-Medizinproduktegrenze-Analyse wird vereinfacht, wenn Patientenidentität architektonisch von der KI-Komponente ausgeschlossen ist
- Break-Glass Re-Linkage bietet die Geschwindigkeit, die Kliniker benötigen, bei vollständigen Audit Trails für Regulierer
- Ein Breach der KI-Umgebung liefert klinische Muster, zugeordnet zu Token — null Risiko der Patientenidentifikation
- Vollständig lokales / Air-Gapped-Deployment ist der empfohlene Standard: Sandbox B läuft mit Ollama oder vLLM im Kubernetes-Cluster des Krankenhauses, ohne Egress zu externen LLM-Anbietern — rohe Identitätsdaten verlassen Ihre Umgebung nie, und in Split-Deployments überschreiten nur bereinigter Text, opake pseudonyme Tokens und Content-Hashes Infrastruktur-Grenzen