HIPAA Safe Harbor De-Identifikation in Aidbox: Von FHIR zu Analytics ohne Offenlegung von Patientendaten

Das Problem mit Healthcare-Analytics

Gesundheitsorganisationen verfügen über wertvolle Daten, doch deren Weitergabe ist ein Minenfeld. Ein Krankenhaus möchte die Raten akuter Nierenschäden in seiner ICU-Population untersuchen. Ein externes Forschungsteam verfügt über die statistische Expertise. Die Daten sind vorhanden – Hunderttausende von Laborbefunden, die als FHIR-Ressourcen in Aidbox gespeichert sind. Die Weitergabe von Roh-Patientendatensätzen verstößt jedoch gegen HIPAA.

Der übliche Workaround ist eine maßgeschneiderte ETL-Pipeline: Daten exportieren, ein Skript ausführen, um Identifikatoren zu entfernen, hoffen, dass nichts durchrutscht, und die bereinigten Daten an anderer Stelle laden. Dies ist langsam, fehleranfällig und schwer zu auditieren. Jede neue Forschungsfrage erfordert eine weitere Pipeline.

Was wäre, wenn die De-Identifikation innerhalb der Datenbank stattfände, deklariert zusammen mit der View, die die Daten strukturiert?

De-Identifikation als ViewDefinition-Funktion

Aidbox unterstützt jetzt spaltenweise De-Identifikation in ViewDefinitions. Sie versehen Spalten mit einer FHIR-Extension, die angibt, welche Transformation angewendet werden soll. Der SQL-Compiler umschließt jeden Spaltenausdruck mit einer PostgreSQL-Funktion – sensible Daten werden transformiert, bevor sie die Ausgabe erreichen.

{
  "resourceType": "ViewDefinition",
  "name": "deident_observations",
  "status": "active",
  "resource": "Observation",
  "select": [{
    "column": [
      {
        "name": "patient_id",
        "path": "subject.getReferenceKey(Patient)",
        "extension": [{
          "url": "http://health-samurai.io/fhir/core/StructureDefinition/de-identification",
          "extension": [
            {"url": "method", "valueCode": "cryptoHash"},
            {"url": "cryptoHashKey", "valueString": "my-secret-key"}
          ]
        }]
      },
      {
        "name": "status",
        "path": "status"
      }
    ]
  }]
}

Die Spalte patient_id trägt eine De-Identifikations-Extension. Sie gibt anstelle der echten Patientenreferenz einen HMAC-SHA256-Hash aus – deterministisch (derselbe Patient erhält immer denselben Hash) und nicht umkehrbar (der Originalwert lässt sich nicht aus dem Hash wiederherstellen). Die Spalte status besitzt keine Extension und wird unverändert durchgegeben.

Der ViewDefinition Builder in der Aidbox-Benutzeroberfläche macht dies visuell nachvollziehbar – klicken Sie auf das Schildsymbol bei einer beliebigen Spalte, um eine Methode auszuwählen und Parameter festzulegen:

Verfügbare Methoden

Zwei Methoden sind für das Muster, das wir gleich erkunden werden, besonders relevant:

cryptoHash erzeugt für dieselbe Eingabe dieselbe Ausgabe – was bedeutet, dass Sie sie zum Verknüpfen von Tabellen nutzen können. Hashen Sie die Patienten-ID in zwei verschiedenen ViewDefinitions mit demselben Schlüssel, und die Hashes stimmen überein. Dies ist die Grundlage für die Re-Identifikation.

dateshift verschiebt alle Daten innerhalb derselben Ressource um denselben Offset und bewahrt so zeitliche Beziehungen. Ein Abstand von 3 Tagen zwischen zwei Ereignissen bleibt ein Abstand von 3 Tagen. Der Offset wird aus HMAC(dateShiftKey, resource.id) abgeleitet und ist daher pro Ressource deterministisch, ohne den Schlüssel jedoch nicht vorhersehbar.

Praktisches Beispiel: Outsourcing der AKI-Forschung

Lassen Sie uns ein realistisches Szenario mit MIMIC-IV-Daten durchgehen, die in Aidbox geladen wurden – 100 ICU-Patienten, über 800.000 Beobachtungen.

Das Ziel: Ein Krankenhaus möchte, dass ein externes Forschungsteam die Raten akuter Nierenschäden (AKI) in seiner ICU-Population analysiert. Die Forscher benötigen Kreatinin-Laborbefunde, dürfen jedoch keine echten Patientenidentifikatoren oder genauen Daten einsehen.

Der Ansatz: Erstellen Sie zwei materialisierte Tabellen – einen de-identifizierten Datensatz für die Forscher und eine interne Zuordnungstabelle, die gehashte IDs mit echten Patienten verknüpft.

Entwurf der de-identifizierten View

Wir beginnen mit einer ViewDefinition auf der Observation-Ressource, gefiltert nach Kreatinin-Laborbefunden. Vier Spalten, jede mit einer anderen De-Identifikationsstrategie:

Patienten-ID – die Spalte mit dem größten Schutzbedarf. Wir wenden cryptoHash an, um die echte UUID in eine nicht umkehrbare HMAC-SHA256-Hex-Zeichenkette umzuwandeln:

// ---8<--- snip
{
  "name": "patient_id",
  "path": "subject.getReferenceKey(Patient)",
  "extension": [{
    "url": "..de-identification",
    "extension": [
      {"url": "method", "valueCode": "cryptoHash"},
      {"url": "cryptoHashKey", "valueString": "aki-study-2026"}
    ]
  }]
}
// ---8<--- snap

Kreatininwert und Einheit – die klinischen Daten, die der Forscher tatsächlich benötigt. Keine De-Identifikation – Laborwerte sind keine Identifikatoren:

// ---8<--- snip
{
  "name": "creatinine",
  "path": "value.ofType(Quantity).value",
  "type": "decimal"
},
{
  "name": "unit",
  "path": "value.ofType(Quantity).unit"
}
// ---8<--- snap

Effektivdatum – verschoben durch einen deterministischen ressourcenspezifischen Offset mittels dateshift. Ein Abstand von 3 Tagen zwischen zwei Laborbefunden bleibt erhalten, das echte Kalenderdatum wird jedoch verborgen:

// ---8<--- snip
{
  "name": "effective_date",
  "path": "effective.ofType(dateTime)",
  "extension": [{
    "url": "..de-identification",
    "extension": [
      {"url": "method", "valueCode": "dateshift"},
      {"url": "dateShiftKey", "valueString": "aki-study-2026"}
    ]
  }]
}
// ---8<--- snap

Die Zuordnungstabelle

Die zweite ViewDefinition dient der Re-Identifikation – sie verbleibt intern. Zwei Spalten auf der Patient-Ressource, beide auf id zeigend: eine unverändert, eine gehasht mit demselben Schlüssel wie oben. Da cryptoHash deterministisch ist, stimmen die gehashten IDs in beiden Tabellen überein.

Erstellung in der Benutzeroberfläche

Der ViewDefinition Builder macht dies visuell nachvollziehbar. Klicken Sie auf das Schildsymbol bei einer beliebigen Spalte, um eine De-Identifikationsmethode auszuwählen und deren Parameter festzulegen:

Nach dem Speichern als Tabelle materialisieren:

Was der Forscher sieht

Der Forscher fragt die de-identifizierte Tabelle ab. Keine echten Patienten-IDs, keine echten Daten:

SELECT * FROM sof.deident_creatinine LIMIT 5;

Die patient_id ist eine Hex-Zeichenkette – der Forscher kann danach gruppieren, eindeutige Patienten zählen und Trends im Zeitverlauf verfolgen. Der Originalwert lässt sich jedoch nicht rekonstruieren.

Berechnung der Kennzahl

AKI wird häufig durch erhöhtes Kreatinin identifiziert. Ein vereinfachtes Screening-Kriterium: Kreatinin über 1,5 mg/dL weist auf eine mögliche Nierenschädigung hin. Der Forscher führt folgende Abfrage aus:

SELECT
  CASE
    WHEN creatinine <= 1.1 THEN 'Normal (≤1.1)'
    WHEN creatinine <= 1.5 THEN 'Elevated (1.1–1.5)'
    WHEN creatinine <= 3.0 THEN 'High (1.5–3.0)'
    ELSE 'Critical (>3.0)'
  END AS risk_category,
  count(*) AS observation_count,
  count(DISTINCT patient_id) AS patient_count,
  round(avg(creatinine)::numeric, 2) AS avg_creatinine
FROM sof.deident_creatinine
GROUP BY 1
ORDER BY 1;

Bei 19 Patienten wurden Kreatininwerte über 3,0 mg/dL gemessen – ein kritischer Schwellenwert, der auf eine schwere Nierenschädigung hindeutet. Der Forscher identifiziert diese Patienten anhand ihrer gehashten IDs und sendet die Ergebnisse an das Krankenhaus zurück.

Re-Identifikation für die klinische Nachverfolgung

Das Krankenhaus verknüpft die Forschungsergebnisse mit der internen Zuordnungstabelle – indem gehashte IDs den echten Patienten-UUIDs zugeordnet werden:

SELECT
  m.real_id,
  max(o.creatinine) AS peak_creatinine,
  count(*) AS high_readings
FROM sof.deident_creatinine o
JOIN sof.patient_id_map m ON o.patient_id = m.hashed_id
WHERE o.creatinine > 3.0
GROUP BY m.real_id
ORDER BY peak_creatinine DESC
LIMIT 20;

Das Krankenhaus weiß nun genau, welche Patienten klinische Aufmerksamkeit benötigen – ohne deren Identitäten jemals dem Forschungsteam offengelegt zu haben.

Das Gesamtbild

Die zentrale Erkenntnis: Derselbe cryptoHashKey verbindet alles miteinander. Der Forscher arbeitet ausschließlich mit gehashten Identifikatoren. Das Krankenhaus besitzt die Zuordnungstabelle und den Schlüssel. Die Re-Identifikation erfolgt ausschließlich intern und nur bei Bedarf.

Vorgefertigte Safe Harbor-ViewDefinitions

Das Schreiben von De-Identifikationsregeln für jeden Ressourcentyp ist mühsam. Wir stellen io.health-samurai.de-identification.r4 bereit – ein FHIR-Paket, das über die Artifact-Registry von Aidbox verfügbar ist, mit vorgefertigten ViewDefinitions für 17 gängige R4-Ressourcentypen: Patient, Encounter, Observation, Condition, Claim, ExplanationOfBenefit, AllergyIntolerance, DiagnosticReport, MedicationRequest, MedicationDispense, MedicationAdministration, Immunization, Procedure, Specimen, DocumentReference, Practitioner und Location.

Jede ViewDefinition wendet Safe Harbor-Regeln an:

• cryptoHash auf Identifikatoren und Referenzen – tabellenübergreifend konsistent für Joins
• dateshift auf klinische Daten – bewahrt zeitliche Beziehungen
• birthDateSafeHarbor auf Patient.birthDate – Datumsverschiebung plus automatische Schwärzung bei Patienten über 89 Jahren, wie von 45 CFR 164.514(b)(2)(i)(C) gefordert
• redact auf Namen, Adressen und andere direkte Identifikatoren

Alle kryptografischen Schlüsselparameter sind standardmäßig leer – legen Sie Ihre eigenen Schlüssel fest, bevor Sie materialisieren. Installieren Sie das Paket über FAR, konfigurieren Sie die Schlüssel, materialisieren Sie als Tabellen und beginnen Sie mit Abfragen.

Erste Schritte

1. FHIR-Schema-Modus aktivieren – setzen Sie fhir.validation.fhir-schema-validation=true (erforderlich seit Aidbox 2604)
2. io.health-samurai.de-identification.r4 über FAR installieren oder eigene ViewDefinitions schreiben
3. Kryptografische Schlüssel in jeder ViewDefinition festlegen – leere Schlüssel werden abgelehnt
4. Als Tabellen materialisieren – $materialize mit type=table oder über den ViewDefinition Builder
5. Mit SQL abfragen über die Aidbox SQL-Konsole, Grafana oder ein beliebiges BI-Tool

Die vollständige Methodenreferenz und Parameterdetails finden Sie in der De-Identifikationsdokumentation. Um das vollständige Szenario aus diesem Beitrag mit einem einzigen docker compose up auszuprobieren, besuchen Sie das De-Identifikationsbeispiel.