FHIR Security Labels: Feingranulare Zugriffskontrolle

Das Kernproblem

Medizinische Akten sind keine einheitliche, monolithische Datei – sie sind ein Mosaik aus Laborbefunden, Abrechnungskennzeichen, psychiatrischen Notizen, demografischen Daten und vielem mehr. Die Herausforderung besteht darin, medizinischem Fachpersonal ausschließlich die Daten bereitzustellen, die es für eine effektive Arbeit benötigt. Das Ziel ist es, nicht mehr Informationen als nötig offenzulegen. Dieses „Need-to-know"-Prinzip ist es, das Security Labels durchsetzen sollen.

Betrachten wir ein konkretes Beispiel. Ein Psychiater, der einen Patienten behandelt, benötigt Zugang zu hochsensiblen psychiatrischen Informationen sowie zu allgemeinen medizinischen Daten. Eine Pflegekraft, die mit dem Psychiater zusammenarbeitet, sollte ebenfalls Zugang zu psychiatrischen Notizen haben. Aber sollen wirklich alle Pflegekräfte Ihre psychiatrischen Notizen lesen können? Das wohl kaum. Ein Allgemeinmediziner wiederum muss möglicherweise die Vitalwerte eines Patienten einsehen, sollte aber aus verschiedenen Gründen keinen Zugang zu psychiatrischen Informationen haben. Diese Liste lässt sich beliebig fortsetzen und hängt stets von den jeweiligen institutionellen Richtlinien ab.

Tabelle der Rollenberechtigungen

Perspektive der FHIR-Implementierung

Beobachtungen spielen im Gesundheitswesen eine zentrale Rolle, und in FHIR ist die Observation-Ressource bewusst breit angelegt. Sie kann alles darstellen – von einer Herzfrequenzmessung über eine Blutdruckkontrolle bis hin zu einem Depressions-Screening. All das fällt unter denselben Ressourcentyp.

Doch nicht alle sollten dieselben Daten sehen. Wenn Ihre Anwendung eine GET-Anfrage für Observations sendet, sollte die Antwort des FHIR-Servers davon abhängen, wer die Anwendung nutzt. Allgemeinmediziner sollten beispielsweise keine Depressionsbewertungen sehen, während Psychiater auf diese angewiesen sind. Es handelt sich um dieselbe Anfrage und dasselbe Bundle – aber verschiedene Benutzer sollten unterschiedliche Ergebnisse erhalten.

Betrachten wir eine weitere FHIR-Ressource: den Patient. Diese enthält viele Informationen, und Patienten haben häufig verschiedene Adressen – für die Privatwohnung, die Abrechnung oder die Postkorrespondenz. Sie möchten möglicherweise nicht, dass ihre Privatadresse für alle sichtbar ist. Dasselbe gilt für ihre Sozialversicherungsnummer – eine Abrechnungsfachkraft benötigt sie möglicherweise, andere Personen in der Klinik jedoch nicht.

All diese Daten befinden sich innerhalb derselben Patient-Ressource. Wir benötigen daher eine Möglichkeit, bestimmte Felder auszublenden und gleichzeitig die Ressource selbst zugänglich zu lassen. Mit anderen Worten: Die Zugriffskontrolle muss nicht nur auf Ressourcenebene, sondern auch auf der Ebene einzelner Elemente oder Eigenschaften konfigurierbar sein.

Lässt sich eine solche Granularität bei der Zugriffskontrolle erreichen?

Die Antwort von FHIR lautet: Security Label – ein kleines, aber wirkungsvolles Konzept, das an Ressourcen angehängt wird.

FHIR Security Labels

Stellen Sie sich dieses Bild als unsere FHIR-Datenbank vor. Wir können Tags oder Labels direkt in der Datenbank an jede Ressource oder sogar an bestimmte Eigenschaften innerhalb einer Ressource anhängen. Diese Tags teilen dem FHIR-Server mit, wer welche Informationen sehen darf.

FHIR Security Labels arbeiten auf zwei verschiedenen Granularitätsebenen:

1. Labels auf Ressourcenebene sind der einfachere Ansatz. Diese Labels werden mithilfe der Eigenschaft meta.security an eine gesamte FHIR-Ressource angehängt. Stellen Sie sich diese als Tags vor, die aussagen: „Dieser gesamte Patientendatensatz ist vertraulich" oder „Diese gesamte Observation enthält sensible Informationen." Da meta.security ein Array ist, können Sie mehrere Labels an eine einzelne Ressource anhängen – beispielsweise einen Datensatz gleichzeitig als „vertraulich" und „psychiatriebezogen" kennzeichnen.

{
  "meta": {
    "security": [
      {
        "code": "R",
        "system": "http://terminology.hl7.org/CodeSystem/v3-Confidentiality"
      },
      {
        "code": "PSY",
        "system": "http://terminology.hl7.org/CodeSystem/v3-ActCode"
      }
    ]
  },
  "resourceType": "Patient",
  ... rest of the resource
}

2. Labels auf Eigenschaftsebene (auch als Inline-Labels bezeichnet) bieten eine wesentlich feinere Kontrolle. Sie ermöglichen den Schutz bestimmter Eigenschaften innerhalb einer Ressource, während andere Eigenschaften weiterhin zugänglich bleiben. Um Labels auf Eigenschaftsebene zu verwenden, müssen Sie zunächst ein spezielles PROCESSINLINELABEL-Flag zur Eigenschaft meta.security der Ressource hinzufügen. Anschließend können Sie mithilfe von FHIR-Extensions Security Labels an einzelne Eigenschaften anhängen. So können Sie beispielsweise nur die Privatadresse in einer Patient-Ressource schützen, während die Rechnungsadresse sichtbar bleibt.

{
  "meta": {
    "security": [
      {
        "code": "PROCESSINLINELABEL",
        "system": "http://terminology.hl7.org/CodeSystem/v3-ActCode"
      }
    ]
  },
  "resourceType": "Patient",
  "address": [
    {
      "use": "home",
      "city": "Metropolis",
      "line": [
        "123 Confidential Ave"
      ],
      "state": "MA",
      "country": "US",
      "extension": [
        {
          "url": "http://hl7.org/fhir/uv/security-label-ds4p/StructureDefinition/extension-inline-sec-label",
          "valueCoding": {
            "code": "LOCIS",
            "system": "http://terminology.hl7.org/CodeSystem/v3-ActCode"
          }
        }
      ]
    },
    {
      "use": "billing",
      "city": "Metropolis",
      "line": [
        "123 Non-Confidential Ave"
      ],
      "state": "MA",
      "country": "US"
    }
  ]
  ... rest of the resource
}

Aufbau eines FHIR Security Labels

FHIR Security Labels verwenden standardisierte HL7-Codesysteme.

Die v3 Confidentiality funktioniert hierarchisch – ähnlich wie Sicherheitsfreigabestufen. Wenn Sie Zugang der Stufe „Restricted" haben, sehen Sie automatisch auch Daten niedrigerer Stufen wie „Normal" und „Low".

Die Codesysteme ActCode und Purpose of Use sind flach – Sie haben entweder den exakt passenden Code oder nicht. Der Zugang zu einem Code gewährt keinen Zugang zu anderen.

Das Vokabular zu kennen ist jedoch nur die halbe Miete. Schauen wir uns an, wie ein FHIR-Server diese Labels zur Anfragezeit tatsächlich verwendet – von der Datenkennzeichnung bis zur Maskierung von Eigenschaften.

Funktionsweise von Security Labels

Der Security-Label-Workflow folgt drei Hauptschritten:

1. Daten und Benutzer kennzeichnen. Jede FHIR-Ressource erhält Security Labels, und Benutzern werden Freigabestufen zugewiesen, die festlegen, auf welche Informationen sie zugreifen dürfen.

2. Benutzerberechtigungen mit Ressourcen-Labels abgleichen. Wenn ein Benutzer Daten anfordert, vergleicht die Zugriffskontroll-Engine die Freigabestufe des Benutzers mit den Security Labels der Ressource anhand der konfigurierten Label-Abgleichsregeln (z. B. Dominanzstufen, alle vs. beliebige erforderliche Tags, Zweckbeschränkungen). Der Zugang wird nur gewährt, wenn diese Regeln auf Ressourcenebene erfüllt sind.

3. Einschränkungen auf Eigenschaftsebene prüfen. Enthält eine Ressource das PROCESSINLINELABEL-Flag, untersucht der Server einzelne Eigenschaften innerhalb dieser Ressource. Eigenschaften, auf die der Benutzer keinen Zugriff hat, werden mithilfe der FHIR-Standard-Extension data-absent-reason mit dem Wert „masked" maskiert.

Implementierungsdetails

So haben wir diesen Workflow in unserem FHIR-Server Aidbox implementiert:

1. Benutzerberechtigungen ermitteln. Wenn eine Anfrage eingeht, stellt Aidbox zunächst die Zugangsstufe des Benutzers fest, indem es dessen Security Labels an zwei Stellen prüft: im Claim „scope" des JWT-Zugangs-Tokens und in der optionalen Eigenschaft User.securityLabel im Benutzerdatensatz.

2. Hierarchische Labels erweitern. Bei Vertraulichkeitscodes erweitert das System die Hierarchie automatisch. Hat ein Benutzer Zugang der Stufe „Restricted", fügt Aidbox allen untergeordneten Labels („Normal", „Low", „Unrestricted") dessen Berechtigungen hinzu.

3. Filterung auf Ressourcenebene anwenden. Im Hintergrund fügt Aidbox die Security Labels des Benutzers in den FHIR-Suchparameter _security ein, um Ressourcen zu filtern. Hat ein Benutzer beispielsweise die Vertraulichkeitsfreigabe „R" (Restricted) und das Label „PSY" (psychiatrische Störungsinformationen), wird eine einfache Anfrage wie GET /fhir/Observation wie folgt umgewandelt:

GET 
/fhir/Observation?_security=http://terminology.hl7.org/CodeSystem/v3-Confidentiality|R,
http://terminology.hl7.org/CodeSystem/v3-Confidentiality|N,
http://terminology.hl7.org/CodeSystem/v3-Confidentiality|L,
http://terminology.hl7.org/CodeSystem/v3-Confidentiality|U,
http://terminology.hl7.org/CodeSystem/v3-ActCode|PSY

Da Aidbox PostgreSQL als Datenbank verwendet, wird diese FHIR-Anfrage in eine SQL-Abfrage umgewandelt. An diesem Punkt wendet Aidbox die Zugriffskontrolle auf Ressourcenebene an, da die SQL-Abfrage ausschließlich Ressourcen mit übereinstimmenden Security Labels zurückgibt. Ressourcen ohne Labels oder mit nicht übereinstimmenden Labels werden automatisch aus den Ergebnissen ausgeschlossen.

4. Zugriffskontrolle auf Eigenschaftsebene verarbeiten. Bei Ressourcen mit dem PROCESSINLINELABEL-Flag untersucht Aidbox jede Eigenschaft mit Inline-Security-Labels. Zugängliche Eigenschaften werden unverändert zurückgegeben, während eingeschränkte Eigenschaften mit der Extension data-absent-reason maskiert werden.

Vorteile

Fassen wir die Vorteile von Security Labels zusammen:

1. Interoperabilität. Security Labels verwenden native HL7-Codesysteme.

2. Granularität auf Ressourcenebene. Sie können einzelne Ressourcen mit mehreren Labels versehen, anstatt die Zugriffskontrolle auf Basis von Ressourcentypen aufzubauen. So können Sie alle Observations bedenkenlos abfragen, ohne befürchten zu müssen, dass sensible psychiatrische Daten Benutzern zugänglich werden, die keinen Zugang dazu haben sollten.

3. Granularität auf Eigenschaftsebene. Inline Security Labels ermöglichen es, eine einzelne Ressourceneigenschaft zu maskieren, während der Rest der Ressource zugänglich bleibt.

Kompromisse

Security Labels bringen wichtige Kompromisse mit sich, die es zu berücksichtigen gilt:

1. Label-Sichtbarkeit kann Informationen preisgeben

Wenn Benutzer data-absent-reason-Extensions zusammen mit Security Labels sehen, kann ein möglicherweise böswilliger Benutzer sofort erkennen, welche Zugangsstufe erforderlich ist, um die verborgenen Daten einzusehen. Dies könnte zu einem Zugriffskontrollproblem führen. Aidbox bietet ein Flag zum Entfernen von Labels an, um Security Labels aus der Antwort zu entfernen.

2. Medizinische Sicherheit vs. Datenleck

Die Offenlegung des Fehlens von Daten kann selbst ein Datenleck darstellen. Wenn sensible Eigenschaften mithilfe von data-absent-reason="masked" maskiert werden, teilt man dem Benutzer mit: „Hier gibt es etwas, das Sie nicht sehen dürfen." Bei stigmatisierenden Informationen wie psychiatrischen Erkrankungen oder Substanzmissbrauch kann bereits das Wissen, dass Daten existieren, problematisch sein.

Man könnte argumentieren, statt Maskierung die Eigenschaft einfach vollständig aus der Ressource zu entfernen, als würde sie gar nicht existieren. Dies führt jedoch zu einem anderen Problem: Wenn Datenzugriffsverweigerungen nicht kommuniziert werden, könnte dies als Nichtvorhandensein der Daten interpretiert werden, was zu falschen medizinischen Entscheidungen führen könnte.

Hierfür gibt es keine einfache Lösung. Es muss eine sorgfältige Einzelfallentscheidung sein.

3. Datenschutz vs. Konformität

Die FHIR-Spezifikation verlangt, dass bestimmte Ressourceneigenschaften vorhanden sein müssen, aber Datenschutzanforderungen können erzwingen, dass diese maskiert werden. Was geschieht, wenn wir eine erforderliche FHIR-Eigenschaft modifizieren? Das bedeutet, dass wir eine nicht konforme Ressource als Antwort zurückgeben.

status ist beispielsweise eine erforderliche Eigenschaft in Observation. Wenn Sie diese jedoch maskieren möchten, geben Sie eine nicht valide Ressource zurück.

{
  "id": "bp-001",
  "resourceType": "Observation",
  "meta": {
    "security": [ ...labels... ]
  },
  "_status": {
    "extension": [
      {
        "url": "http://terminology.hl7.org/CodeSystem/data-absent-reason",
        "valueCode": "masked"
      }
    ]
  },
  "code": {
    "coding": [
      {
        "extension": [
          {
            "url": "http://terminology.hl7.org/CodeSystem/data-absent-reason",
            "valueCode": "masked"
          }
        ]
      }
    ]
  }
}

Obwohl „Konformität um der Konformität willen" ein akzeptabler Kompromiss sein kann, wird es zum echten Problem, wenn Client-Anwendungen darauf angewiesen sind, dass diese erforderlichen Eigenschaften vorhanden sind. „Es ist Datenschutz gegen Konformität – und manchmal muss der Datenschutz gewinnen."

4. Leistungsaufwand

Wie Sie bemerkt haben werden, erzeugt die Durchsetzung von Security Labels an mehreren Stellen zusätzlichen Verarbeitungsaufwand.

Wir haben Leistungstests durchgeführt und drei Aidbox-Konfigurationen verglichen: Ohne labelbasierte Zugriffskontrolle

• Mit Labels auf Ressourcenebene
• Mit Inline-Labels

Wir haben FHIR-Leseoperationen gemessen und dabei GET /fhir/Patient/id-Anfragen ausgeführt. Die Ergebnisse zeigten eine Verlangsamung von 6,2 % bei Labels auf Ressourcenebene und 7,4 % bei Labels auf Eigenschaftsebene. Sofern Ihre Anwendung nicht auf jede Millisekunde Leistung angewiesen ist, stellt dies kein wesentliches Problem dar.

Erstell- und Aktualisierungsoperationen

Unsere Implementierung von FHIR Security Labels deckt derzeit nur Lese- und Suchoperationen ab. Erstell- und Aktualisierungsoperationen erfordern eine zusätzliche Behandlung.

Das Problem

Betrachten Sie folgendes Szenario: Ein Client fordert eine Patient-Ressource an, bei der die Privatadresse aufgrund unzureichender Berechtigungen maskiert ist. Der Client sieht die Rechnungsadresse und andere Eigenschaften und möchte nun die Telefonnummer des Patienten aktualisieren. Wie soll der FHIR-Server diese Aktualisierung verarbeiten, ohne die verborgene Privatadresse zu verlieren?

Empfohlene Vorgehensweise

• PUT-Operationen vollständig vermeiden – PUT ersetzt die gesamte Ressource, wodurch alle maskierten Eigenschaften, die der Client nicht sehen konnte, verloren gehen würden.
• Stattdessen PATCH-Operationen verwenden – PATCH ermöglicht die gezielte Aktualisierung bestimmter Eigenschaften, ohne die gesamte Ressource zu beeinflussen.
• Clientseitige Validierung – Implementieren Sie eine Logik, die nur das Patchen von Eigenschaften zulässt, die in der ursprünglichen Antwort nicht maskiert waren.

Labels auf Ressourcenebene vs. Labels auf Eigenschaftsebene

• Labels auf Ressourcenebene (in meta.security): FHIR empfiehlt, die Labels in meta bei Erstell-Operationen beizubehalten, bei Aktualisierungen ist jedoch weiterhin Sorgfalt geboten.
• Labels auf Eigenschaftsebene (Inline-Extensions) sind komplizierter, da sie innerhalb der Ressourcendaten selbst existieren.

Dies bleibt ein sich entwickelnder Bereich, in dem FHIR-Server eine benutzerdefinierte Logik benötigen, um Aktualisierungen sicher zu verarbeiten und dabei Sicherheitsgrenzen zu wahren.

Kein Allheilmittel

Die wichtigste Erkenntnis aus diesem Artikel ist: Labels sind ein scharfes Werkzeug, aber sie bringen viele Kompromisse mit sich, die Sie sorgfältig abwägen müssen.

Postman-Demo

Probieren Sie die FHIR-Security-Label-Implementierung von Aidbox in Postman aus. Bitte lesen Sie die Beschreibung in der Postman-Collection, bevor Sie Anfragen ausführen.

Mit der bereitgestellten Postman-Collection können Sie verschiedene Szenarien rund um feingranulare Zugriffskontrolle mit FHIR Security Labels erkunden. Die Collection enthält Beispielanfragen und eine Anleitung dazu, wie Sie die Maskierung und Filterung sensibler Dateneigenschaften basierend auf Benutzerberechtigungen testen können.

In Postman ausführen

Der Aidbox FHIR-Server ist für Entwicklungs- und Testzwecke kostenlos verfügbar. Sie können also eine eigene Instanz einrichten und mit Security Labels in einer realen Umgebung experimentieren. So können Sie leicht evaluieren, wie Security Labels in der Praxis funktionieren, bevor Sie einen Produktivbetrieb in Betracht ziehen.

Siehe auch: RBAC mit Keycloak und SMART on FHIR V2.