Kurze Antwort: Sicherheit in einer Gesundheits-App beantwortet vier Fragen, und zwar in dieser Reihenfolge. Wer ist das? Identität: ein verifizierter Nutzer (Patient, Arzt, System) über OpenID Connect und für Ärzte die nationale Berufsausweis; die Vertrauensstufe ist wichtiger als die Passwortstärke. Was darf er tun? Autorisierung: OAuth 2.0 (Umstellung auf 2.1) Tokens mit Scopes in SMART on FHIR-Syntax, abgeleitet von der Zustimmung des Patienten für einen Zweck und eine Dauer, durchgesetzt auf Datenebene. Was hat er getan? Rechenschaftspflicht: ein Zugriffsprotokoll, das der Patient lesen kann, und eine FHIR AuditEvent-Spur für die Organisation. Sind die Daten sicher gespeichert, übertragen und in Backups? Schutz: Verschlüsselung, Schlüsselverwaltung, Trennung, getestete Wiederherstellungen. Drumherum: die Basis von ISO 27001 und 27799, NIS2 und HIPAA's Security Rule sowie die spezifischen Bedrohungen von Gesundheitsdaten (Insider-Zugriffe, Fehlzuordnungen, Ransomware).
Die Übersicht
Sicherheit und Identität in einer Gesundheits-App bilden sieben Ebenen: Identität durch OpenID Connect und nationale oder berufliche IDs, Autorisierung durch OAuth 2.0 und SMART on FHIR Scopes, Zustimmung als Quelle jeder Erlaubnis, Rechenschaftspflicht durch Zugriffsprotokolle und FHIR AuditEvent, Schutz durch Verschlüsselung und Backups, eine Basis von ISO 27001, ISO 27799, NIS2 und HIPAA sowie patientengesteuerte Freigabe.
| Ebene | Standard oder Praxis | Was es Ihnen bringt | Seite |
|---|---|---|---|
| Identität | OpenID Connect; nationale IDs (eIDAS, NHS login, GesundheitsID); Berufsausweise (eHBA, CPS, UZI) | Ein verifizierter Subjekt mit einer Vertrauensstufe | SMART App Launch erklärt |
| Autorisierung | OAuth 2.0 und 2.1 (PKCE zwingend, keine impliziten oder Passwort-Grants); SMART on FHIR Scopes (patient/Observation.rs); Backend-Dienste mit asymmetrischer Client-Authentifizierung | Tokens, die an einen Nutzer, einen Patientenkontext und einen Scope gebunden sind | SMART App Launch erklärt, SMART on FHIR Backend |
| Zustimmung | FHIR Consent; zweck- und zeitgebundene Erlaubnisse; Widerruf; "Break-the-glass" mit Begründung und Benachrichtigung | Der Patient als Quelle jeder Autorisierung | Patienten-Zustimmungsplattform, Zugriffsanfragen von Kliniken |
| Rechenschaftspflicht | Zugriffsprotokolle pro Datensatz, die für den Patienten sichtbar sind; FHIR AuditEvent; manipulationssichere Speicherung; Aufbewahrung | Wer was wann warum gesehen hat | Wer hat meine Krankenakte eingesehen? |
| Schutz | TLS 1.2+, Verschlüsselung im Ruhezustand mit verwalteten Schlüsseln, Feldverschlüsselung für Identifikatoren, getrennte Umgebungen, Backups mit getesteter Wiederherstellung | Vertraulichkeit und Verfügbarkeit | ISO 27001 vs. ISO 27799 |
| Basis | ISO 27001 ISMS, 27799 Gesundheitskontrollen, NIS2-Maßnahmen, HIPAA Security Rule, nationale Schemata (HDS, DSPT, C5) | Was Krankenhäuser, Prüfer und Regulierungsbehörden erwarten | NIS2 für Krankenhäuser und Anbieter, HIPAA vs. GDPR |
| Teilen | SMART Health Links und Karten; verifizierbare Anmeldeinformationen | Vom Patienten initiierte Freigabe mit einem Link oder QR-Code, widerrufbar | SMART Health Links erklärt |
Identität: Vertrauen statt Passwörter
Identität in einer Gesundheits-App beruht auf Vertrauenswürdigkeit statt auf Passwortstärke: Identitäts-Vertrauensstufen wie NIST IAL, eIDAS substantial und high oder NHS login P9 beschreiben, wie stark eine Person bei der Registrierung verifiziert wurde, während Multi-Faktor-Authentifizierung und Passkeys jeden Login beschreiben. Kliniker werden durch berufliche Identitäten identifiziert, die bei ihrem Ausscheiden widerrufen werden.
Eine Patienten-App, die einen vollständigen Datensatz anzeigt, muss wissen, dass sie mit diesem Patienten spricht. Identitäts-Vertrauensstufen (NIST's IAL, eIDAS "substantial" und "high", NHS login P9) beschreiben, wie stark die Identität bei der Registrierung verifiziert wurde; die Authentifizierungsstärke (Mehrfaktor, Passkeys) beschreibt jeden Login. Krankenhäuser und nationale Systeme verlangen zunehmend verifizierte Identitäten aus anerkannten Schemata anstelle von selbst deklarierten Anmeldungen, und die EU Digital Identity Wallet wird ein akzeptiertes Mittel werden. Für Ärzte ist die Berufsausweis (und deren Widerruf, wenn jemand ausscheidet) das Aufzeichnungssystem dafür, wer überhaupt als Arzt handeln darf.
Autorisierung: Zustimmung wird zu Scopes
Autorisierung in einem patientengesteuerten Datensatz übersetzt die Zustimmung des Patienten, z. B. die Erlaubnis einer Klinik, Laborergebnisse und Diagnosen für 90 Tage einzusehen, in OAuth Scopes und Patientenkontext auf dem Token, in SMART on FHIR-Syntax wie patient/Observation.rs, erzwungen auf der Datenebene bei jeder Anfrage und widerrufen, wenn der Patient seine Zustimmung zurückzieht. "Break-the-glass" ist ein separater, auditierter Weg.
In einem vom Patienten kontrollierten Datensatz ist die Zustimmung des Patienten die Richtlinie: Diese Klinik darf meine Laborergebnisse und Diagnosen für 90 Tage lesen. Das System übersetzt sie in OAuth Scopes und Kontext (welcher Patient, welche Ressourcen, welche Operationen) auf dem Token, das das System der Klinik erhält, setzt sie bei jeder Anfrage auf Datenebene durch und widerruft sie, wenn der Patient sie zurückzieht. Die Scope-Syntax von SMART on FHIR (patient/Observation.rs, patient/Condition.rs) ist die Lingua Franca dafür; granulare Scopes (nach Kategorie oder Code) gibt es in SMART v2 für feinere Kontrolle. "Break-the-glass" (Notfallzugriff ohne Zustimmung) ist ein separater, geprüfter Weg mit obligatorischer Begründung und einer Benachrichtigung an den Patienten, niemals ein Standard. Siehe Patienten-Zustimmungsplattform.
Rechenschaftspflicht: das Protokoll, das der Patient liest
Rechenschaftspflicht in einer Gesundheits-App bedeutet, dass jeder Zugriff auf einen Datensatz, durch wen, wann, was und unter welcher Zustimmung, in ein unveränderliches Protokoll geschrieben wird, das der Patient in seiner App lesen kann, und in eine organisatorische Audit-Spur in FHIR AuditEvent. ISO 27799 behandelt dies als obligatorisch, und ein sichtbares Protokoll ist die stärkste Abschreckung gegen Insider-Browsing.
Jeder Zugriff auf einen Datensatz, von wem, wann, was, unter welcher Zustimmung, wird in ein nur anhängbares Protokoll geschrieben, das der Patient in seiner App lesen kann, und in eine organisatorische Audit-Spur (FHIR AuditEvent) für Sicherheitsteams. ISO 27799 behandelt dies als obligatorisch für Gesundheitsinformationen; das Transparenzprinzip der DSGVO und die Patientenrechte des EHDS weisen in die gleiche Richtung; die größte reale Abschreckung gegen Insider-Zugriffe ist ein sichtbares Protokoll. Siehe Wer hat meine Krankenakte eingesehen?.
Schutz: die technische Basis
Die technische Grundlage für den Schutz von Gesundheitsdaten ist TLS überall, Verschlüsselung im Ruhezustand mit verwalteten, rotierten Schlüsseln, separate Verschlüsselung oder Tokenisierung für direkte Identifikatoren, getrennte Umgebungen mit synthetischen Daten außerhalb der Produktion, Zugriff nach dem Prinzip der geringsten Rechte mit Multi-Faktor-Authentifizierung für Administratoren, Geheimnis- und Schwachstellenmanagement, verschlüsselte Backups, die durch Wiederherstellung gegen Ransomware getestet werden, und eine Reaktion auf Vorfälle innerhalb der Fristen von GDPR und NIS2.
TLS überall, mit modernen Verschlüsselungen und Certificate Pinning in Apps, wo angebracht; Verschlüsselung im Ruhezustand mit Schlüsseln in einem verwalteten Schlüssel-Service und Rotation; separate Verschlüsselung oder Tokenisierung für direkte Identifikatoren; Trennung von Produktion und Entwicklung, mit synthetischen Daten außerhalb der Produktion; Least-Privilege-Zugriff für Mitarbeiter, keine geteilten Konten, Mehrfaktor-Authentifizierung für alle administrativen Zugriffe; Geheimnisverwaltung; Abhängigkeits- und Schwachstellenmanagement mit Offenlegung; Backups verschlüsselt, durch Wiederherstellung getestet und geschützt gegen Ransomware, die Krankenhäuser und Labore wiederholt getroffen hat (WannaCry 2017, das Düsseldorfer Krankenhaus 2020, Change Healthcare und Synnovis 2024). Vorfallreaktion mit den 72-Stunden-DSGVO- und 24-Stunden-NIS2-Fristen in einem Runbook.
Spezifische Bedrohungen für Gesundheitsdaten
Die spezifischen Bedrohungen für Gesundheitsdaten sind das heimliche Einsehen von Datensätzen Bekannter durch Insider, Fehlzuordnungen zwischen Patienten, zu breit gefasste und zu lange gewährte Freigaben, Werbe-SDKs in Apps, die Gesundheitsdaten verarbeiten, dokumentenbasierte Einschleusungen in KI-Funktionen und lange Aufbewahrungsfristen über Jahrzehnte, während derer Schlüssel, Formate und Zugriffsregeln Personal und Anbieter überdauern müssen.
- Insider-Zugriffe auf Datensätze von Bekannten oder öffentlichen Personen: beziehungsbasierter Zugriff und sichtbare Protokolle.
- Fehlzuordnungen zwischen Patienten: Identitätsabgleich und Herkunftsnachweis, nicht nur Zugriffskontrolle.
- Zu breite Freigaben: eine Klinik, der "alles" für ein Jahr gewährt wurde; Scopes und Dauern mit sinnvollen Standardwerten.
- Apps mit Werbe-SDKs: keine Drittanbieter-Tracker in allem, was Gesundheitsdaten verarbeitet.
- Dokumentenbasierte Injektion in KI-Funktionen: Inhalte sind Daten, niemals Anweisungen (RAG bei Krankenakten).
- Lange Aufbewahrung: Datensätze leben Jahrzehnte; Schlüssel, Formate und Zugriffsregeln müssen Personal und Anbieter überdauern.
In Anpheros
Anpheros wendet die Sicherheitsübersicht auf sich selbst an mit OAuth 2.0 mit PKCE für Apps und asymmetrischer Client-Authentifizierung für Backends, Zustimmung pro Zweck und Dauer als Quelle für den Zugriff jeder Klinik, einem Zugriffsprotokoll pro Datensatz in der App der Person, Verschlüsselung im Ruhezustand und während der Übertragung, EU-Hosting, keine Werbe-SDKs und ein ISMS nach ISO 27001 und 27799.
Anpheros wendet diese Übersicht auf sich selbst an: OAuth 2.0 mit PKCE für Apps und asymmetrische Client-Authentifizierung für Backends; Zustimmung pro Zweck und Dauer als Quelle für den Zugriff jeder Klinik, mit Widerruf und keinem stillen "Break-the-glass"; ein Zugriffsprotokoll pro Datensatz in der App der Person; Verschlüsselung im Ruhezustand und während der Übertragung, EU-Hosting, keine Werbe-SDKs; ein ISMS nach ISO 27001 mit den 27799 Gesundheitskontrollen. Die Entwickler-Website dokumentiert Authentifizierung, Zustimmung und Sicherheit.
Verwandte Seiten
- SMART App Launch erklärt
- Patienten-Zustimmungsplattform
- Wer hat meine Krankenakte eingesehen?
- SMART Health Links erklärt
- ISO 27001 vs. ISO 27799
- NIS2 für Krankenhäuser und Health-Tech-Anbieter
- Plattform-Sicherheit (Entwickler-Website)
- Authentifizierung (Entwickler-Website)
Quellen
- HL7 SMART App Launch
- IETF: OAuth 2.1 (Entwurf)
- OpenID Connect Core 1.0
- HL7 FHIR R4: AuditEvent
- HL7 FHIR R4: Consent
- NIST SP 800-63-4: Digital Identity Guidelines
- ISO 27799:2016
- ENISA: Beschaffungsrichtlinien für Cybersicherheit in Krankenhäusern
Häufige Fragen
Ist OAuth 2.1 anders als 2.0?
OAuth 2.1 fasst 2.0 mit seinen bewährten Sicherheitspraktiken zusammen: PKCE ist für alle Clients erforderlich, die impliziten und Passwort-Grants werden entfernt, Redirect-URIs müssen exakt übereinstimmen, und Refresh-Tokens für öffentliche Clients müssen gebunden oder rotiert werden. SMART on FHIR v2 verlangt bereits die meisten dieser Punkte.
Was ist "Break-the-glass"?
Notfallzugriff auf einen Datensatz ohne vorherige Zustimmung des Patienten durch einen Arzt, der eine Begründung angibt. Dies muss selten sein, protokolliert, überprüft und dem Patienten gemeldet werden; es ist niemals der Standardzugriffsweg.
Warum sollten Patienten das Zugriffsprotokoll sehen?
Weil es die stärkste Abschreckung gegen unangemessene Zugriffe und der klarste Ausdruck von Kontrolle ist: Die Person sieht, welche Klinik was und wann gelesen hat, und kann den Zugriff widerrufen. ISO 27799 und das EHDS weisen in die gleiche Richtung.
Brauche ich ein separates Audit-System?
Sie benötigen eine nur anhängbare Audit-Spur (FHIR AuditEvent oder Äquivalent), die die Anwendung nicht ändern kann, die gemäß Richtlinie aufbewahrt wird, und eine daraus abgeleitete, für den Patienten sichtbare Ansicht. Ob es sich um ein separates System oder einen geschützten Speicher innerhalb der Plattform handelt, ist eine Implementierungsentscheidung.
Kostenlos in der Sandbox testen
Ihr erster FHIR-Aufruf in 5 Minuten. Eine HL7 FHIR R4 API mit der Zustimmung des Patienten: probieren Sie sie in der Sandbox aus und verbinden Sie dann Ihre eigene App oder Ihr Kliniksystem.
Kostenlos · 30 synthetische Patienten · keine Karte
Anpheros entwickelt eine Patientenakte, die der Patient kontrolliert und mit jeder Klinik teilen kann, auf einer HL7 FHIR R4-Plattform mit Sitz in der EU. Diese Anleitungen helfen Ihnen, Ihre Gesundheit zu verstehen und zu organisieren; sie ersetzen nicht Ihren Arzt.
Über Anpheros →