Healthcare-PHI/PII-Compliance-Muster
Muster zum Schutz von Patientendaten, Klinikdaten und Finanzdaten in Gesundheitsanwendungen. Gültig für HIPAA (USA), DISHA (Indien), GDPR (EU) und allgemeinen Datenschutz im Gesundheitswesen.
Verwendung
- Erstellen von Funktionen, die auf Patientenakten zugreifen
- Implementieren von Zugriffskontrollen oder Authentifizierung für klinische Systeme
- Entwerfen von Datenbankschemata für Gesundheitsdaten
- Entwickeln von APIs, die Patienten- oder Klinikdaten zurückgeben
- Implementieren von Audit-Trails oder Logging
- Überprüfen von Code auf Datenexpositions-Schwachstellen
- Einrichten von Row-Level Security (RLS) für mehrinstanzenfähige Gesundheitssysteme
Funktionsweise
Der Schutz von Gesundheitsdaten erfolgt auf drei Ebenen: Klassifizierung (was ist sensibel), Zugriffskontrolle (wer darf es sehen) und Prüfung (wer hat es gesehen).
Datenklassifizierung
PHI (geschützte Gesundheitsdaten) – alle Daten, die einen Patienten identifizieren UND mit seiner Gesundheit in Zusammenhang stehen: Patientenname, Geburtsdatum, Adresse, Telefon, E-Mail, nationale Ausweisnummern (SSN, Aadhaar, NHS-Nummer), Krankenaktennummern, Diagnosen, Medikationen, Laborergebnisse, Bildgebung, Versicherungspolicen und Abrechnungsdetails, Termin- und Aufnahmedaten oder jede Kombination der genannten.
PII (nicht patientenbezogene sensible Daten) in Gesundheitssystemen: persönliche Daten von Klinikmitarbeitern, Arzt-Honorarstrukturen und Auszahlungsbeträge, Gehalts- und Bankdaten von Angestellten, Zahlungsinformationen von Lieferanten.
Zugriffskontrolle: Row-Level Security
ALTER TABLE patients ENABLE ROW LEVEL SECURITY;
-- Zugriff auf die eigene Einrichtung beschränken
CREATE POLICY "staff_read_own_facility"
ON patients FOR SELECT TO authenticated
USING (facility_id IN (
SELECT facility_id FROM staff_assignments
WHERE user_id = auth.uid() AND role IN ('doctor','nurse','lab_tech','admin')
));
-- Audit-Log: nur Einfügen (manipulationssicher)
CREATE POLICY "audit_insert_only" ON audit_log FOR INSERT
TO authenticated WITH CHECK (user_id = auth.uid());
CREATE POLICY "audit_no_modify" ON audit_log FOR UPDATE USING (false);
CREATE POLICY "audit_no_delete" ON audit_log FOR DELETE USING (false);
Audit-Trail
Jeder PHI-Zugriff oder jede PHI-Änderung muss protokolliert werden:
interface AuditEntry {
timestamp: string;
user_id: string;
patient_id: string;
action: 'create' | 'read' | 'update' | 'delete' | 'print' | 'export';
resource_type: string;
resource_id: string;
changes?: { before: object; after: object };
ip_address: string;
session_id: string;
}
Häufige Leckpfade
Fehlermeldungen: Nie patientenidentifizierende Daten in Fehlermeldungen an den Client aufnehmen. Details nur serverseitig protokollieren.
Konsolenausgabe: Nie vollständige Patientenobjekte protokollieren. Stattdessen undurchsichtige interne Datensatz-IDs (UUIDs) verwenden – keine Krankenaktennummern, nationalen IDs oder Namen.
URL-Parameter: Nie patientenidentifizierende Daten in Query-Strings oder Pfadsegmenten ablegen, die in Logs oder im Browserverlauf auftauchen könnten. Ausschließlich undurchsichtige UUIDs verwenden.
Browser-Speicher: Nie PHI in localStorage oder sessionStorage speichern. PHI nur im Arbeitsspeicher halten und bei Bedarf abrufen.
Service-Role-Schlüssel: Nie den service_role-Schlüssel im Client-Code verwenden. Immer den anon/public-Schlüssel nutzen und RLS die Zugriffskontrolle überlassen.
Logs und Monitoring: Nie vollständige Patientenakten protokollieren. Nur undurchsichtige Datensatz-IDs verwenden (keine Krankenaktennummern). Stacktraces bereinigen, bevor sie an Fehlerverfolgungsdienste gesendet werden.
Schema-Kennzeichnung von Datenbankspalten
PHI/PII-Spalten auf Schemaebene markieren:
COMMENT ON COLUMN patients.name IS 'PHI: patient_name';
COMMENT ON COLUMN patients.dob IS 'PHI: date_of_birth';
COMMENT ON COLUMN patients.aadhaar IS 'PHI: national_id';
COMMENT ON COLUMN doctor_payouts.amount IS 'PII: financial';
Checkliste vor der Bereitstellung
Vor jeder Bereitstellung:
- Keine PHI in Fehlermeldungen oder Stacktraces
- Keine PHI in console.log/console.error
- Keine PHI in URL-Parametern
- Keine PHI im Browser-Speicher
- Kein service_role-Schlüssel im Client-Code
- RLS auf allen PHI/PII-Tabellen aktiviert
- Audit-Trail für alle Datenänderungen
- Sitzungs-Timeout konfiguriert
- API-Authentifizierung auf allen PHI-Endpunkten
- Datenisolation zwischen Einrichtungen verifiziert
Beispiele
Beispiel 1: Sichere vs. unsichere Fehlerbehandlung
// SCHLECHT – gibt PHI in Fehler aus
throw new Error(`Patient ${patient.name} nicht in ${patient.facility} gefunden`);
// GUT – allgemeiner Fehler, Details serverseitig mit undurchsichtigen IDs protokolliert
logger.error('Patientensuche fehlgeschlagen', { recordId: patient.id, facilityId });
throw new Error('Datensatz nicht gefunden');
Beispiel 2: RLS-Richtlinie für Isolation zwischen Einrichtungen
-- Arzt in Einrichtung A kann Patienten von Einrichtung B nicht sehen
CREATE POLICY "facility_isolation"
ON patients FOR SELECT TO authenticated
USING (facility_id IN (
SELECT facility_id FROM staff_assignments WHERE user_id = auth.uid()
));
-- Test: Einloggen als doctor-facility-a, Patienten von facility-b abfragen
-- Erwartet: 0 Zeilen zurückgegeben
Beispiel 3: Sicheres Logging
// SCHLECHT – protokolliert identifizierbare Patientendaten
console.log('Verarbeite Patient:', patient);
// GUT – protokolliert nur undurchsichtige interne Datensatz-ID
console.log('Verarbeite Datensatz:', patient.id);
// Hinweis: Auch patient.id sollte eine undurchsichtige UUID sein, keine Krankenaktennummer