Diese Seite wurde von der Cloud Translation API übersetzt.

FHIR-Zugriffsdatenmodell und -steuerungssystem

Datenmodell – Übersicht

Das Datenmodell für die Zugriffssteuerung wird durch Einwilligungsressourcen dargestellt. Sie definieren, welche Regeln gelten und für welche Daten sie gelten.

FHIR-Einwilligung

Die Zugriffsregeln werden über FHIR-Einwilligungsressourcen ausgedrückt. FHIR-Einwilligung ist eine Art von FHIR-Ressource, die die Entscheidungen eines Nutzers im Gesundheitswesen erfasst. Sie erlaubt oder lehnt eine Gruppe von Akteuren ab, Aktionen auszuführen, die den Nutzer für einen bestimmten Zweck über einen bestimmten Zeitraum in einer bestimmten Umgebung betreffen. Ein Nutzer kann beispielsweise ein medizinischer Patient, eine Person, die im Namen eines medizinischen Patienten agiert, oder eine andere Person, die eine Einwilligungsvereinbarung abschließt.

Die in einer FHIR-Einwilligung aufgezeichneten Aktionen können weit gefasst sein und es geht nicht nur um die elektronischen Patientenaktendaten (EHR) des Verbrauchers. Zum Zweck der Einwilligung in der Cloud Healthcare API liegt der Fokus jedoch auf Aktionen im Zusammenhang mit dem Datenzugriff und die Erzwingung dieser Aktionen ist auf das Lesen von FHIR-Daten aus einem FHIR-Speicher beschränkt.

Eine Einwilligungsressource hat einen Status, der den aktuellen Status der Einwilligung angibt. Obwohl ein FHIR-Speicher viele Einwilligungen in verschiedenen Status enthalten kann, erzwingt die Cloud Healthcare API nur Einwilligungen im Status Aktiv. Einwilligungen in anderen Bundesstaaten haben keine Auswirkungen auf die Durchsetzung. Wenn eine Einwilligung im Namen eines Patienten gegeben wird, wird sie so aufgezeichnet, als wäre sie von einem performer erteilt worden.

Richtlinientyp

Die Cloud Healthcare API unterstützt die folgenden Arten von Einwilligungsrichtlinien:

Einwilligung des Patienten: Wird einem Patienten mithilfe von Consent.patient (STU3, R4) zugeordnet und bindet so viele Daten, wie vom Patientenfach definiert (STU3, R4).
Administratorrichtlinie: Ist mit keinem Patienten verknüpft und muss die Erweiterungs-URL https://g.co/fhir/medicalrecords/ConsentAdminPolicy haben. Dieser Richtlinientyp kann an eine Teilmenge oder an alle Ressourcen im Speicher gebunden werden, die durch die Ressourcenkriterien angegeben werden. Die Administratorrichtlinie legt die Standardrichtlinie für alle Bindungsressourcen im Speicher fest.
Kaskadierende Richtlinie für Administratoren: Eine Art von Administratorrichtlinie, für die die Erweiterungs-URL https://g.co/fhir/medicalrecords/CascadingPolicy und die URL der Erweiterung für die Administratorrichtlinien erforderlich sind. Sie können diesen Richtlinientyp an einen Ressourcenbereich binden, der den Ressourcenkriterien entspricht. Es gelten die folgenden Einschränkungen:
- Unterstützt nur Patienten (STU3, R4) oder Encounter (STU3, R4) als Fachbasis.
- Für den FHIR-Speicher, in dem die Richtlinie erzwungen wird, muss disableReferentialIntegrity auf false festgelegt sein.

Sie können Richtlinientypen auf derselben Ressourcenebene kombinieren, um den Zugriff auf eine Ressource zuzulassen oder abzulehnen. Wenn die Einwilligung eines Patienten fehlt, kann der Zugriff auf eine Ressource über die Administratorrichtlinie genehmigt werden.

Einwilligungsanweisungen sind Anweisungen, die in einer FHIR-Einwilligung codiert sind, die den Datenzugriff auf eine autorisierte Entität wie einen Empfänger oder eine zugreifende Person zulassen oder verweigern. Eine einzelne FHIR-Einwilligung kann mehrere Einwilligungsanweisungen codieren. Jede Anweisung enthält Folgendes:

Erzwingungstyp: eine permit- oder deny-Anweisung.
Aktion: die Berechtigung(en), auf die sich diese Anweisung bezieht. Nur access wird unterstützt, um Lesezugriff bereitzustellen.
kriterien für zugreifende Person: Eine Reihe von Attributen, die den von der Anweisung abgedeckten API-Anforderer angeben.
Ressourcenkriterien: Eine Reihe von Attributen zur Identifizierung der von der Anweisung abgedeckten Ressourcen.

Kriterien zugreifender Person

Die Cloud Healthcare API unterstützt drei Attribute einer Zugreifenden Person für die Verwendung innerhalb einer Einwilligungsanweisung und zum Abgleich mit einer Zugreifenden Person, die eine Datenzugriffsanfrage stellt. Es muss eine genaue Übereinstimmung unter Beachtung der Groß- und Kleinschreibung vorliegen, damit eine Anweisung für die zugreifende Person als Teil der Zugriffsermittlung, die vom FHIR-Server angeboten wird, erzwungen wird.

Diese Attribute sind so codiert:

Actor: Stellt eine Einzelperson, Gruppe oder Zugriffsrolle dar, die die zugreifende Person oder ein Merkmal der zugreifenden Person identifiziert.
Zweck: Stellt die Absicht der Verwendung der Daten dar.
Umgebung: Stellt eine abstrakte Kennung dar, die die Umgebung oder die Bedingungen beschreibt, unter denen die zugreifende Person agiert.

Zum Beispiel kann eine Zugreifende Person durch die folgenden Attribute dargestellt werden:

Akteur: Practitioner/123
Zweck: ETREAT oder Zugang zu Notfallbehandlungszwecken
Umgebung: Application/abc

In diesem Beispiel stellen diese Attribute einen Arzt dar, der auf Daten zugreift, wenn er eine Notfallbehandlung mit einer Softwareanwendung namens abc ausführt.

provision.actor und provision.purpose sind als Teil des FHIR-Standards definiert, während für die Umgebung https://g.co/fhir/medicalrecords/Environment gilt. Dieser Link kann nicht aufgelöst werden.

Alle Einwilligungsanweisungen müssen eine actor angeben, die erzwungen werden soll, müssen aber nicht immer eine purpose oder environment angeben. Wenn beispielsweise in der Einwilligungsanweisung keine environment angegeben ist, stimmt die Anweisung mit jedem environment überein, der nicht bereits durch andere Einwilligungsanweisungen abgedeckt ist.

Ressourcenkriterien

Die Cloud Healthcare API unterstützt die folgenden Elemente als Teil der Einwilligungsressource:

Ressourcentyp (STU3, R4): steht für den Typ, an den die Einwilligungsrichtlinie gebunden wird, z. B. Encounter, Observation oder Immunization.
Ressourcen-ID (STU3, R4): stellt die ID dar, an die die Einwilligungsrichtlinie gebunden wird.
Datenquelle: Stellt den Ursprung der Ressource dar, wie von der Ressource meta.source identifiziert (nur in R4 verfügbar).
Daten-Tag : steht für das benutzerdefinierte Label der Ressource, wie in der Ressource meta.tag beschrieben (STU3 ,R4).
Sicherheitslabel: stellt Sicherheitslabels dar, die betroffene Ressourcen definieren, wie im Feld meta.security angegeben (STU3, R4). Die folgenden Codesysteme werden unterstützt:
- Confidentiality (Vertraulichkeit): Hierarchische Werte werden von „Uneingeschränkt“ bis „Am stärksten eingeschränkt“ sortiert: U, L, M, N, R, V. Wenn eine Einwilligung das Sicherheitslabel R zulässt, gilt sie für alle Ressourcen mit dem Label R oder niedriger. Wenn ein Sicherheitslabel R durch eine Einwilligung abgelehnt wird, gilt es auf alle Ressourcen, die mindestens so vertraulich wie R sind.
- ActCode: exakter Stringabgleich mit dem Sicherheitscode

Auf Workflow zugreifen

authorization_flow

Diese Abbildung zeigt den gesamten Prozess einer Anfrage an einen Speicher mit aktivierter FHIR-Zugriffssteuerung. Die Anwendung (Nr. 3) verwendet ein externes Token mit dem Einwilligungsbereich (links), wenn eine Anfrage an den FHIR-Speicher mit aktivierter Zugriffssteuerung (rechts) gestellt wird.

Wenn Sie eine Datenzugriffsanfrage senden, arbeitet ein zugreifende Person innerhalb eines bestimmten Einwilligungsbereichs, der seine Attribute actor, purpose und environment darstellt, die sich auf jede beliebige FHIR-HTTP-Anfrage beziehen. Bei den Werten für diese Attribute muss die Groß- und Kleinschreibung mit denen übereinstimmen, die in einer Einwilligung bereitgestellt wurden, damit sie sich auf die Zugriffsbestimmung der Erzwingung auswirken.

Eine zugreifende Person kann mehrere actor-Kennungen haben, die für die Zugriffsbesrimmung relevant sind. Ebenso können mehrere purposes- oder environments-Werte für einen bestimmten Einwilligungskontext relevant sein. Daher sollten alle relevanten zugreifende Person-Attribute als Teil einer FHIR-HTTP-Anfrage bereitgestellt werden, um die zugreifende Person zu Einwilligungszwecken ordnungsgemäß darzustellen.

Der Einwilligungsumfang für eine bestimmte Datenanfrage kann beispielsweise so aussehen:

actor/Practitioner/444 actor/Group/999 purp/v3/TREAT purp/v3/ETREAT env/App/abc

Dies repräsentiert eine Krankenpflegerin oder Ärztin, die als Fachkraft 444 bekannt ist und Mitglied der Gruppe 999 ist, die Fachkräfte aus einer Abteilung in einem bestimmten Krankenhaus repräsentiert. Die Fachkraft ist da, um eine reguläre Behandlung anzubieten, kann aber auch Notfallbehandlung als Teil dieser Aktionen vornehmen. Die Fachkraft verwendet eine Softwareanwendung namens abc.

Der Einwilligungsbereich wird als Einwilligungsbereich anfordern im Rahmen der Datenanfrage einer zugreifenden Person angegeben.

Bereich der Einwilligung anfordern

FHIR-Anfragen verwenden FHIR-HTTP-Anfrageheader, um den Einwilligungsbereich der zugreifenden Person zu empfangen. Dieser Einwilligungsbereich enthält eine Reihe von actor-, purpose- und environment-Werten, die die aktuelle Identität, die Qualifikationen, die geplante Verwendung und die Umgebungsbeschränkungen der Zugreifenden Person widerspiegeln, innerhalb derer die zugreifende Person arbeitet. Es kann von jedem dieser Attribute mehrere geben, die den Einwilligungsbereich eines zugreifenden Person zu einem beliebigen Zeitpunkt darstellen.

Einträge für den Einwilligungsbereich der Einwilligung sind so definiert:

actor/{type}/{ID}: Ein actor-Attribut, bei dem die Ressource type zusammen mit ID angegeben wird. Beispiele für type:
- Practitioner
- Group
- Patient
Wenn beispielsweise ein Speicher des Formats projects/PROJECT_ID/locations/us-central1/datasets/DATASET_ID/fhirStores/STORE_ID die API aufruft, wird ein lokaler Verweis auf einen Practitioner/123-Akteur in projects/PROJECT_ID/locations/us-central1/datasets/DATASET_ID/fhirStores/STORE_ID/fhir/Practitioner/123 aufgelöst.
purp/v3/{value}: Eine purpose-Property, bei der value Mitglied des Wertesatzes für den FHIR-Zweck (v3) oder seiner Erweiterung ist. Beispiele für value:
- TREAT
- ETREAT
- HRESCH
env/{type}/{value}: Ein environment-Attribut, wobei type und value benutzerdefinierte Strings ohne vordefinierte Taxonomie sind. Beispiele für type und value:
- App/my_app_1
- Net/VPN

Darüber hinaus können FHIR-HTTP-Anfrageheader auch spezielle Bereiche wie btg und bypass empfangen, die wie folgt definiert sind:

btg: Mit Break the Glass (oder BTG) kannst du als menschlicher Nutzer die Einwilligungsprüfung im Notfall überspringen. Es sollte nur in Notfällen verwendet werden und muss nach der Prüfung geprüft werden. Daher ist für btg mindestens eine actor erforderlich.
bypass: Ermöglicht vertrauenswürdigen Nutzern (z. B. einem Administrator) oder vertrauenswürdigen Anwendungen (z. B. einer ML-Trainingspipeline) die Ausführung im FHIR-Speicher ohne Einwilligungsautorisierung. Daher sind für bypass mindestens eine actor und eine env erforderlich.

Zugriffserzwingung und Zugriffsbestimmung

In einer komplexen Gesundheitsumgebung mit mehreren Richtlinien und Einwilligungen kann es schwierig sein, den Zugriff zu erzwingen und die Zugriffsberechtigungen festzulegen. Verschiedene Stakeholder haben möglicherweise unterschiedliche Erwartungen und Anforderungen in Bezug auf die Verwendung und Offenlegung von Patienteninformationen. Um sich in dieser komplexen Landschaft zurechtzufinden, müssen Sie genau wissen, wie der Zugriff erzwungen wird und welche Logik der Zugriffsbestimmung zugrunde liegt.

Richtlinie zur zusammengefassten Einwilligung

Nutzer im Gesundheitswesen, z. B. Patienten oder Administratoren, können in einer einzelnen Consent-Ressource mehrere Einwilligungsanweisungen haben. Einwilligungsressourcen können eine Kombination aus den provision.type-Anweisungen permit und deny enthalten. Standardmäßig kann ein Nutzer beliebig viele Einwilligungsressourcen haben, aber es werden bis zu 200 active-Einwilligungsressourcen gleichzeitig erzwungen. Weitere Informationen finden Sie unter Einschränkungen und Einschränkungen.

Alle Einwilligungsanweisungen werden aus active-Einwilligungs-Ressourcen für einen bestimmten Nutzer extrahiert, um eine Reihe von aggregierten Einwilligungsregeln zu erstellen.

Eigenschaften der Einwilligungsrichtlinie

Die Durchsetzung von Einwilligungen ist auf höchstens einen Zweck und höchstens eine Umgebung pro Bereitstellungseintrag beschränkt.

In den folgenden Regeln werden die Prinzipien für die gemeinsame Zugriffssteuerung der Patienteneinwilligung, die Administratorrichtlinien und die kaskadierenden Richtlinien für Administratoren beschrieben:

Auf alle Ressourcen wird standardmäßig der Zugriff verweigert, wenn keine entsprechende Anweisung vorhanden ist.
Wenn die angeforderte Ressource nicht vorhanden ist, sind nur der Ressourcentyp und die Ressourcen-ID identifizierbar. Alle anderen Ressourcenkriterien und der Ressourceninhaber sind unbekannt. In der Reihenfolge der Auflistung gilt die folgende Regel:
- Wenn der Ressourcentyp zum Patienten- oder Gegenfach gehört, wird der Zugriff verweigert.
- Andernfalls:
  - Wenn eine Administratorrichtlinie die Kriterien der Zugriffsfunktion ungeachtet der anderen Ressourcenkriterien ablehnt, wird der Zugriff verweigert.
  - Wenn es eine Administratorrichtlinie gibt, die die Kriterien der Zugriffsfunktion für die identifizierbaren Ressourcenkriterien (d.h. Ressourcentyp und Ressourcen-ID) zulässt, wird der Fehler „Ressource nicht gefunden“ zurückgegeben.
  - In allen anderen Fällen wird der Zugriff verweigert.
Administratorrichtlinien sind die Standardrichtlinien, die für übereinstimmende Ressourcen im Store verwendet werden.
Ressourcen, die keinem Patienten gehören, werden nur durch die Administratorrichtlinien festgelegt.
Ressourcen, die sich im Patientenfach (STU3, R4) oder im Begegnungsfach (STU3, R4) befinden, benötigen mindestens eine Richtlinie zur Zulassung der Einwilligung pro Patient oder einer kaskadierenden Richtlinie zur Zulassung oder einer Administratorrichtlinie und einer Richtlinie zum Ablehnen der Einwilligung der Patienten und der Administratorrichtlinie und der kaskadierenden Administratorrichtlinie. Dieser Zustand wird von allen Patienten benötigt, die in den Ressourcen genannt werden, damit der Anfragende auf sie zugreifen kann.
- Einige Ressourcen unterstützen möglicherweise mehrere Patienten Teilnehmende. Mit Appointment wird beispielsweise eine Liste der Teilnehmer bereitgestellt, bei denen es sich um Patienten handeln kann. Alle auf diesen Ressourcen genannten Patienten müssen den Zugriff auf die zugreifende Person mithilfe von Einwilligungsanweisungen erlauben. Andernfalls werden die Ressourcen nicht zurückgegeben. Wenn eine Ressource eine Berechtigung aus einer Richtlinie zur kaskadierenden Begegnung hat, bei der über das Feld subject (STU3, R4) auf einen Patienten verwiesen wird, wird die Ressource als vom Patienten zugelassen angesehen.

Die beschriebenen Regeln werden durch folgenden Pseudocode zusammengefasst:

Gemeinsame Zugriffssteuerung

if resource does not exist
  if resource is a patient-compartment or encounter-compartment resource:
    return "deny"
  else:
    if there is any admin policy denies access for accessor criteria regardless of resource criteria other than resource type and resource ID:
      return "deny"
    else if there is any admin policy permits access for accessor criteria based on the identifiable resource criteria:
      return "resource not found"
    else:
      return "deny"
else:
  let patients = list of patient references named in the patient compartment eligible fields of the requested resource
  if there is any matching deny from either patients's consents or admin policy or admin cascading policy:
    return "deny"
  if there is matching admin policy permits access:
    return "permit"
  if all patients have matching patient consents or admin cascading consent that permit access or are subject of encounters which permit the access through encounter cascading policy:
    return "permit"
  else:
    return "deny"
end

Der FHIR-Speicher prüft die Einwilligungsberechtigung auf der Ebene der einzelnen Ressourcen. Referenzen in einer Ressource werden nicht aufgelöst und zur Prüfung des Einwilligungszugriffs kaskadiert. Angenommen, ein von Patient/f001 identifizierter Patienten, der es einem Arzt ermöglicht, aus Datenschutzgründen auf seine gesamte MedicationRequest-Ressource, jedoch nicht auf die Patient/f001-Ressource selbst zuzugreifen. In diesem Szenario kann der Prüfer die gesamte MedicationRequest-Ressource sehen, die ein subject-Feld enthält, das auf die Patient/f001-Ressource verweist. Sie kann jedoch nicht den Inhalt der Patient/f001-Ressource sehen, selbst z. B. bei einer FHIR-Suche mit _include.

Konfliktlösung

Zwischen verschiedenen permit- und deny-Anweisungen können Konflikte auftreten. Wenn zwei in Konflikt stehende Anweisungen mit einer Ressource übereinstimmen, wird der Konflikt mit dem Modell deny gewinnt gegenüber permit gelöst.

Für die Erzwingung der Einwilligung sind nur active-Einwilligungen enthalten.

Logik für die Erzwingung des Ressourcenzugriffs

Wenn Sie eine Einwilligungssensitive Anfrage an einen FHIR-Speicher senden, erfolgt die Zugriffssteuerung in folgender Reihenfolge:

Die Cloud Healthcare API prüft die Berechtigungen für das im Proxy konfigurierte Google Cloud-Dienstkonto (oder das Hauptkonto). Wenn das Dienstkonto die erforderlichen IAM-Berechtigungen zum Ausführen der angeforderten FHIR-Methode im FHIR-Speicher hat, wird die Anfrage fortgesetzt.
Wenn die Durchsetzung von Einwilligungen in der FHIR-Speicherkonfiguration aktiviert ist und die Einwilligungssensitiven HTTP-Header vorhanden sind, erzwingt die Cloud Healthcare API Richtlinien für den Einwilligungszugriff für Patientenbereichs-Ressourcen. Die Durchsetzung der Richtlinien für den Einwilligungszugriff basiert auf den in der Anfrage angegebenen Einwilligungsumfängen, gemäß den Einwilligungsrichtlinien, die bei der letzten Ausführung von ApplyConsents und ApplyAdminConsents erfasst wurden.

Hinweis: Wenn die Verarbeitung des Einwilligungsheaders in der FHIR-Speicherkonfiguration als REQUIRED_ON_READ definiert ist, wird die Zugriffssteuerung für die Einwilligung auch ohne die Header mit Einwilligungserkennung erzwungen (und abgelehnt).

Die folgenden Regeln gelten, wenn Sie eine Einwilligungssensitive Anfrage an einen FHIR-Speicher stellen:

Geben Sie mindestens einen actor-Einwilligungsbereich an, der für die ausgeführten Einwilligungsaktionen relevant ist.
Geben Sie beliebige zusätzliche Bereiche purpose und environment an, die für die ergriffenen Einwilligungs-Aktionen relevant sind.
Wenn die Anzahl der Einträge für Einwilligungsbereiche die unterstützten Limits überschreitet, wird ein Fehler zurückgegeben.
Wenn Sie eine Methode aufrufen, die auf mehrere Ressourcen zugreift (z. B. Methode fhir.Patient-everything, fhir.executeBundle oder fhir.search), gilt die Einwilligungserzwingung für jede einzelne Ressource. Zwischen diesen Zugriffsmethoden mit mehreren Ressourcen gibt es jedoch einen feinen Unterschied:
- fhir.executeBundle, die mehrere Ressourcen liest, erhält "Einwilligungszugriff abgelehnt oder die Ressource, auf die zugegriffen wird, existiert nicht" für einzelne Ressourcen ohne Einwilligungsberechtigungen. Beispiele finden Sie unter FHIR-Ressourcen mit Einwilligungsbereich abrufen..
- fhir.search überspringt Ressourcen ohne Einwilligungsberechtigungen und gibt keinen Einwilligungszugriff-abgelehnt-Fehler zurück, auch bei der Suche nach _id nicht (siehe Beispiele in den FHIR-Ressourcen mit Einwilligungsbereich suchen.
- fhir.Patient-everything verhält sich ähnlich wie fhir.search, mit dem Unterschied, dass es zurückgibt "Einwilligungszugriff abgelehnt oder die Ressource, auf die zugegriffen wird, ist nicht vorhanden", wenn der Aufrufer keine Einwilligungsberechtigung für die angeforderte Patienten-Ressource hat.

Ermittlung des Einwilligungszugriffs

Eine Einwilligungsanweisung hat höchstens einen actor, höchstens einen purpose und höchstens einen environment, während der Einwilligungsbereich mehrere von jedem enthalten kann. In einigen Einwilligungsanweisungen sind nicht alle drei Attribute der Zugriffsfunktion angegeben. In diesem Fall kann der Wert eines Attributs für den Einwilligungsbereich je nach Regeln für die Konfliktlösung übereinstimmen. Daher kann ein Einwilligungsbereich mit mehr als einer Einwilligungsanweisung übereinstimmen.

Wenn der Einwilligungsbereich einer Anfrage zwei oder mehr Einträge desselben Einwilligungsbereichstyps enthält (actor, purpose oder environment), stimmt der Einwilligungsbereich möglicherweise mit mehreren Einwilligungsanweisungen überein. In einigen Einwilligungsanweisungen ist kein purpose oder environment angegeben. Daher muss der Einwilligungsumfang auch mit Einwilligungsanweisungen abgeglichen werden, in denen diese Bereichstypen nicht angegeben sind.

Wenn Sie beispielsweise den Einwilligungsbereich auf actor/Practitioner/123 actor/Group/999 purp/v3/TREAT env/App/abc setzen, stimmen sämtliche der folgenden permit- oder deny-Einwilligungsanweisungen überein:

actor/Practitioner/123 purp/v3/TREAT env/App/abc
actor/Practitioner/123 purp/v3/TREAT
actor/Practitioner/123 env/App/abc
actor/Practitioner/123
actor/Group/999 purp/v3/TREAT env/App/abc
actor/Group/999 purp/v3/TREAT
actor/Group/999 env/App/abc
actor/Group/999

Nächste Schritte

Weitere Informationen zum Erzwingen des Zugriffs auf einen FHIR-Speicher