FHIR-Zugriffsdatenmodell und -Kontrollsystem

Vorschau

Auf dieser Seite werden die Vorschaufunktionen beschrieben. die sich ändern können und möglicherweise nur begrenzten Support bieten. Änderungen an pre-GA-Produkten und -Funktionen sind möglicherweise nicht mit anderen pre-GA-Versionen kompatibel. Weitere Informationen finden Sie unter Vorbedingungen des Angebots für die Cloud Healthcare API und in den Beschreibungen der Startphase.

Datenmodell – Übersicht

Das Datenmodell für die Zugriffssteuerung wird durch Ressourcen für Einwilligungen dargestellt. Sie definieren die Regeln, die gelten, und die Daten, auf die sie angewendet werden.

FHIR-Einwilligung

Die Zugriffsregeln werden über FHIR-Einwilligungsressourcen ausgedrückt. FHIR-Einwilligung ist eine Art von FHIR-Ressource, die die Auswahlmöglichkeiten eines Gesundheitsbereich-Nutzers erfasst. Damit wird einer Reihe von Akteuren das ausführen von Aktionen erlaubt oder verwehrt, die Auswirkungen auf den Nutzer für einen bestimmten Zweck aus einer angegebenen Umgebung heraus und in einem bestimmten Zeitraum haben. 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 erfassten Aktionen können weit gefasst sein und sich nicht nur auf die EHR-Daten (Electronic Health Record) des Nutzers beziehen. Im Rahmen der Einwilligung in der Cloud Healthcare API liegt der Schwerpunkt jedoch auf Aktionen im Zusammenhang mit dem Datenzugriff. Die Durchsetzung 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. Ein FHIR-Speicher kann viele Einwilligungen in verschiedenen Status enthalten. Die Cloud Healthcare API erzwingt jedoch nur Einwilligungen, die den Status aktiv haben. 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 Einwilligungsrichtlinientypen:

• Einwilligung des Patienten: wird einem Patienten mithilfe von Consent.patient (STU3, R4) zugeordnet und bindet so viele Daten wie vom Patientenbereich (STU3, R4) definiert.

• Administratorrichtlinie: Ist mit keinem Patienten verknüpft und muss eine Erweiterungs-URL https://g.co/fhir/medicalrecords/ConsentAdminPolicy haben. Dieser Richtlinientyp kann an eine Teilmenge oder alle Ressourcen im Speicher gebunden werden, die durch die Ressourcenkriterien angegeben sind. Die Administratorrichtlinie legt die Standardrichtlinie für alle Bindungsressourcen im Store fest.

• Abfolgerichtlinie für Administratoren: Eine Art von Administratorrichtlinie, für die die Erweiterungs-URL https://g.co/fhir/medicalrecords/CascadingPolicy und die Erweiterungs-URL der Administratorrichtlinie erforderlich sind. Sie können diesen Richtlinientyp an einen Bereich von Ressourcen binden, die den Ressourcenkriterien entsprechen. Es gelten die folgenden Einschränkungen:

  • Unterstützt nur „Patient“ (STU3, R4) oder „Encounter“ (STU3, R4) als Bereichsbasis.
  • Für den FHIR-Speicher, in dem die Richtlinie erzwungen wird, muss disableReferentialIntegrity auf false gesetzt sein.

Sie können Richtlinientypen auf derselben Ressourcenebene kombinieren, um den Zugriff auf eine Ressource zuzulassen oder zu verweigern. Wenn die Einwilligung eines Patienten fehlt, kann die Administratorrichtlinie den Zugriff auf eine Ressource genehmigen.

Einwilligungsanweisung

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 Richtlinie enthält Folgendes:

• Erzwingungstyp: eine permit- oder deny-Anweisung.

• „Action“ (Aktion): Die Berechtigungen, die von dieser Richtlinie abgedeckt sind. Nur access wird für den schreibgeschützten Zugriff unterstützt.

• kriterien für zugreifende Person: Eine Reihe von Attributen, die den von der Anweisung abgedeckten API-Anforderer angeben.

• Ressourcenkriterien: Eine Reihe von Attributen, die die von der Richtlinie abgedeckten Ressourcen angeben.

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:

• Akteur: Stellt eine Person, Gruppe oder Zugriffsrolle dar, die den Zugriffsberechtigten oder eine Eigenschaft des Zugriffsberechtigten 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 der Zugriff erfolgt.

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

• Akteur: Practitioner/123

• Zweck: ETREAT oder Zugriff zu Zwecken der Notfallbehandlung

• 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 die Umgebung https://g.co/fhir/medicalrecords/Environment ist. Hinweis: 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): steht für die ID, an die die Einwilligungsrichtlinie gebunden wird.

• Datenquelle: Der Ursprung der Ressource, wie in der Ressource meta.source angegeben (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: steht für Sicherheitslabels, die die betroffenen Ressourcen definieren, wie im Feld meta.security angegeben (STU3, R4). Die folgenden Codesysteme werden unterstützt:

  • Vertraulichkeit: Hierarchische Werte, sortiert von uneingeschränkt bis am stärksten eingeschränkt: U, L, M, N, R, V. Wenn eine Einwilligung ein Sicherheitslabel von R zulässt, gilt sie für alle Ressourcen mit dem Label R oder niedriger. Wenn in einer Einwilligung ein Sicherheitslabel R abgelehnt wird, gilt dies für alle Ressourcen, die mindestens so sensibel sind wie R.

  • ActCode: Exakte Stringübereinstimmung mit dem Sicherheitscode.

Hinweis :Beispiele dafür, wie verschiedene Richtlinien über die Ressource für Einwilligungen dargestellt werden können, finden Sie in den Anleitungen.

Auf Workflow zugreifen

Diese Abbildung veranschaulicht den End-to-End-Vorgang einer Anfrage an einen Speicher mit aktivierter FHIR-Zugriffssteuerung. Ein externes Token mit dem Einwilligungsumfang (links) wird von der Anwendung 3 verwendet, wenn eine Anfrage an den FHIR-Speicher mit aktivierter Zugriffssteuerung gesendet wird (rechts).

Umfang der Einwilligung

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. Die Werte für diese Properties müssen in Groß- und Kleinschreibung mit den in einer Einwilligung angegebenen Werten übereinstimmen, damit sie sich auf die Zugriffsentscheidung der Erzwingung auswirken.

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

Der Einwilligungsbereich 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 Bereich der Einwilligung anfordern im Rahmen der Datenanfrage eines Nutzers 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 Geltungsbereich der Einwilligung sind so definiert:

• actor/{type}/{ID}: Eine actor-Property, in der die Ressource type zusammen mit dem ID angegeben wird. Beispiele für type:

  • Practitioner
  • Group
  • Patient

  Wenn beispielsweise ein Geschäft im Format projects/PROJECT_ID/locations/us-central1/datasets/DATASET_ID/fhirStores/STORE_ID die API aufruft, wird eine lokale Referenz 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}: Ein purpose-Attribut, bei dem value Mitglied des Wertsatzes von FHIR-Verwendungs-Zweck (v3) oder dessen Erweiterung ist. Beispiele für value:

  • TREAT
  • ETREAT
  • HRESCH

• env/{type}/{value}: Eine environment-Property, bei der 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 erhalten, z. B. btg und bypass, die so definiert sind:

• btg: Mit der Funktion „Break the glass“ (BTG) können Sie als Nutzer in Notfällen die Einwilligungsabfragen überspringen. Sie sollte nur in Notfällen verwendet werden und unterliegt einer anschließenden Überprüfung. Daher ist für btg mindestens eine actor erforderlich.
• bypass: Ermöglicht es vertrauenswürdigen Nutzern (z. B. Administratoren) oder vertrauenswürdigen Anwendungen (z. B. einer ML-Trainingspipeline), ohne Einwilligungsautorisierung auf den FHIR-Speicher zuzugreifen. Daher ist für bypass mindestens ein actor und ein env erforderlich.

Hinweis: Anfragen mit btg oder bypass werden in den Audit-Logs in consentMode unterschiedlich gekennzeichnet. Um Prüfungen der Datenverwaltung zu erleichtern, sollten diese beiden speziellen Berechtigungen nur für den vorgesehenen Zweck verwendet werden.

Zugriffserzwingung und Zugriffsermittlung

In einer komplexen Gesundheitsumgebung, in der mehrere Richtlinien und Einwilligungen nebeneinander existieren, kann es schwierig sein, den Zugriff zu erzwingen und Zugriffsberechtigungen zu bestimmen. Unterschiedliche Stakeholder können unterschiedliche Erwartungen und Anforderungen an die Verwendung und Offenlegung von Patientendaten haben. Um sich in dieser komplexen Landschaft zurechtzufinden, ist ein klares Verständnis dafür erforderlich, wie der Zugriff erzwungen wird und welche Logik der Zugriffsbestimmung zugrunde liegt.

Richtlinie zur kumulierten Einwilligung

Ein Gesundheitsbereichsnutzer, z. B. ein Patient oder ein Administrator, kann mehrere Einwilligungsanweisungen haben, die in einer einzelnen Einwilligungs-Ressource enthalten sind. Einwilligungsressourcen können eine Kombination aus den provision.type-Anweisungen permit und deny enthalten. Standardmäßig kann ein Nutzer eine beliebige Anzahl von Einwilligungs-Ressourcen haben. Es werden jedoch bis zu 200 active-Einwilligungs-Ressourcen gleichzeitig erzwungen. Weitere Informationen finden Sie unter 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 Einwilligungsanweisung

Die Einwilligungsaufforderung ist auf höchstens einen Zweck und höchstens eine Umgebung pro Bestimmung-Eintrag beschränkt.

In den folgenden Regeln werden die Grundsätze für die gemeinsame Zugriffssteuerung der Patienteneinwilligung, der Administratorrichtlinie und der abgeleiteten Administratorrichtlinie beschrieben:

• Wenn keine übereinstimmende Richtlinie vorhanden ist, wird allen Ressourcen standardmäßig der Zugriff verweigert.

• Wenn die angeforderte Ressource nicht vorhanden ist, sind nur der Ressourcentyp und die Ressourcen-ID identifizierbar. Wenn alle anderen Ressourcenkriterien und der Ressourceninhaber unbekannt sind, gilt in der Listenreihenfolge die folgende Regel:

  • Wenn der Ressourcentyp zum Patientenbereich oder zum Begegnungsbereich gehört, wird der Zugriff verweigert.

  • Andernfalls:

    • Wenn es eine Administratorrichtlinie gibt, die die Zugriffskriterien unabhängig von den anderen Ressourcenkriterien ablehnt, wird der Zugriff verweigert.

    • Wenn es eine Administratorrichtlinie gibt, die die Zugriffskriterien 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 abgelehnt.

• Administratorrichtlinien sind die Standardrichtlinien, die für die Übereinstimmung von Ressourcen im Play Store verwendet werden.

• Für Ressourcen, die keinem Patienten zugewiesen sind, gelten nur die Administratorrichtlinien.

• Ressourcen im Patientenbereich (STU3, R4) oder im Bereich „Encounter“ (STU3, R4) benötigen mindestens eine Richtlinie zur Einwilligungsvergabe pro Patienten-oder Administratorrichtlinie oder abgeleitete Administratorrichtlinie und keine Richtlinie zur Einwilligungsverweigerung aus der Patienten-und Administratorrichtlinie und abgeleiteten Administratorrichtlinie. Diese Bedingung muss von allen Patienten vorliegen, die in den Ressourcen benannt sind, auf die der Anfragende zugreift.

  • Einige Ressourcen unterstützen möglicherweise mehrere Teilnehmer. Termin enthält beispielsweise eine Liste der Teilnehmer, die Patienten sein können. Alle in solchen Ressourcen genannten Patienten müssen den Zugriff durch die zugreifende Person über Einwilligungsanweisungen gewähren. Andernfalls werden die Ressourcen nicht zurückgegeben. Wenn eine Ressource eine Berechtigung aus einer abfolgebasierten Richtlinie für den Besuch hat, bei der dieser Besuch über das Feld subject (STU3, R4) auf einen Patienten verweist, gilt die Ressource als vom Patienten erlaubt.

Die beschriebenen Regeln werden im 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 Berechtigung zur Einwilligung auf Ressourcenebene. Alle Referenzen in einer Ressource werden nicht aufgelöst und kaskadiert, um den Zugriff auf die Einwilligung zu prüfen. Angenommen, ein Patient, der durch Patient/f001 identifiziert wird, ermöglicht einer Fachkraft auf seine gesamte MedicationRequest-Ressource, aber nicht auf die Patient/f001-Ressource selbst zuzugreifen aufgrund der Privatsphäre des Patienten. In diesem Szenario kann die Fachkraft, die die Einwilligung bekommen hat, die gesamte MedicationRequest-Ressource sehen, was ein subject-Feld umfasst, das auf die Patient/f001-Ressource verweist, aber kann nicht den Inhalt von Patient/f001 Ressource sehen, auch wenn sie beispielsweise eine FHIR-Suche mit _include ausführt.

Konfliktlösung

Zwischen verschiedenen permit- und deny-Richtlinien sind Konflikte möglich. Wenn zwei widersprüchliche Anweisungen auf eine Ressource zutreffen, wird der Konflikt mithilfe des Modells deny gewinnt vor 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:

1. Die Cloud Healthcare API prüft die Berechtigungen des Google Cloud-Dienstkontos (oder des Hauptkontos), das im Proxy konfiguriert ist. Wenn das Dienstkonto die richtigen IAM-Berechtigungen zum Ausführen der angeforderten FHIR-Methode im FHIR-Speicher hat, wird die Anfrage fortgesetzt.

2. 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 Erzwingung von Einwilligungs-Zugriffsrichtlinien basiert auf den in der Anfrage angegebenen Einwilligungsbereichen gemäß der Einwilligungsanweisungen, die von der letzten Ausführung von ApplyConsents und ApplyAdminConsents erfasst wurden.

   Hinweis: Wenn in der FHIR-Speicherkonfiguration die Verarbeitung des Einwilligungsheaders als REQUIRED_ON_READ definiert ist, wird die Zugriffssteuerung für die Einwilligung auch ohne die Einwilligungssensitiven Header 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. fhir.Patient-everything, fhir.Encounter-everything, fhir.executeBundle oder fhir.search), gilt die Einwilligungserzwingung für jede einzelne Ressource. Es gibt jedoch einen kleinen Unterschied zwischen diesen Methoden für den Zugriff auf mehrere Ressourcen:

  • 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 und fhir.Encounter-everything verhalten sich ähnlich wie fhir.search, mit dem Unterschied, dass sie zurückgeben „Einwilligungszugriff abgelehnt oder die Ressource, auf die zugegriffen wird, ist nicht vorhanden“, wenn der Aufrufer keine Einwilligungsberechtigung für die angeforderte Patienten- oder Begegnungsressource hat.

Zugriffsermittlung für Einwilligung

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. Einige Einwilligungsanweisungen geben nicht alle drei zugreifende Person-Attribute an. In diesem Fall kann jeder Einwilligungsbereich-Attributwert abhängig von den Konfliktlösungsregeln ü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. Einige Einwilligungsanweisungen geben keine purpose oder environment an. Daher muss der Einwilligungsbereich auch mit Einwilligungsanweisungen abgeglichen werden, in denen diese Gültigkeitstypen 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