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 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 ein Art von FHIR-Ressource das die Entscheidungen von Verbrauchern im Gesundheitswesen erfasst. Sie erlaubt oder lehnt eine Reihe von Akteure, um Aktionen auszuführen, die den Nutzer für einen bestimmten Zweck betreffen aus einer angegebenen Umgebung über einen bestimmten Zeitraum. 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 Consent-Ressource hat eine 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. Administratorrichtlinie legt die Standardeinstellung fest für alle Bindungsressourcen im Speicher.

• Abfolge von Verwaltungsrichtlinien: Eine Art von Verwaltungsrichtlinie, für die die Erweiterungs-URL https://g.co/fhir/medicalrecords/CascadingPolicy und die Erweiterungs-URL der Verwaltungsrichtlinie erforderlich sind. Sie können diesen Richtlinientyp an ein Abteil von Ressourcen, 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 abzulehnen. 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 Berechtigung(en), 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:

• Actor: steht für eine Einzelperson, Gruppe oder Zugriffsrolle, die oder ein Merkmal der Zugriffsfunktion.

• Zweck: Stellt die Absicht der Verwendung der Daten dar.

• Environment: Stellt eine abstrakte Kennung dar, die die unter denen die zugreifende Person handelt.

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 werden als Teil des FHIR-Standards definiert, während die Umgebung https://g.co/fhir/medicalrecords/Environment 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 im Rahmen 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: Stellt den Ursprung der Ressource dar, wie vom Ressource meta.source (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 betroffene Ressourcen definieren wie im Feld meta.security angegeben (STU3, R4. Die folgenden Codesysteme werden unterstützt:

  • Vertraulichkeit: Hierarchische Werte von uneingeschränkt bis am stärksten geordnet: 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 exakter Stringabgleich 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 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.

Einwilligungsbereich

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 Groß- und Kleinschreibungsempfindlich 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 können mehrere purposes- oder environments, die für einen 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}: ein actor-Attribut, bei dem die Ressource type ist zusammen mit der ID bereitgestellt. 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}: 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 sind. benutzerdefinierte Strings ohne vordefinierte Taxonomie. Beispiele für type und value:

  • App/my_app_1
  • Net/VPN

Darüber hinaus können FHIR-HTTP-Anfrageheader auch spezielle Bereiche empfangen, z. B. btg und bypass definiert sind:

• btg: Mit der Funktion „Break the glass“ (BTG) können Sie als Nutzer in Notfällen die Einwilligungsbestätigung ü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. Zur Vereinfachung der Data Governance sollten diese beiden besonderen Berechtigungen nur für den jeweils vorgesehenen Zweck verwendet werden. zu erfüllen.

Zugriffserzwingung und Zugriffsbestimmung

In einer komplexen Gesundheitsumgebung mit mehreren Richtlinien und Einwilligungen Zugriff zu erzwingen und Zugriffsberechtigungen festzulegen, kann eine Herausforderung sein, für die Aufgabe. 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, ist es wichtig, genau zu verstehen, 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 kann eine Mischung aus permit und deny enthalten provision.type Anweisungen. Standardmäßig kann ein Nutzer beliebig viele Einwilligungsressourcen haben auf 200 active Einwilligungsressourcen werden 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 Einwilligungsrichtlinie

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:

• Auf alle Ressourcen wird standardmäßig der Zugriff verweigert, wenn keine entsprechende Anweisung vorhanden ist.

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

  • Wenn der Ressourcentyp zum Patientenfach gehört oder Begegnung-Fach: Der Zugriff wird verweigert.

  • Andernfalls:

    • Wenn es eine Administratorrichtlinie gibt, die die Kriterien der Zugriffsfunktion ablehnt der anderen Ressourcenkriterien entspricht, 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 verweigert.

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

• Ressourcen, die keinem Patienten gehören, werden nur vom Administrator festgelegt Richtlinien.

• Ressourcen, die sich im Patientenfach befinden (STU3, R4) oder in einem entsprechenden Fach (STU3, R4) mindestens eine Einwilligungserklärung pro Patient erforderlich oder Administratorrichtlinie oder Administratorrichtlinie und keine Richtlinie zum Ablehnen der Einwilligung von Patienten-und Admin-Richtlinien und Admin-Kaskadierungsrichtlinien. Dieses -Krankheit von allen in den Ressourcen genannten Patienten auf die der Anfragende zugreift.

  • Einige Ressourcen unterstützen möglicherweise mehrere Teilnehmer. Beispiel: Termin enthält eine Liste Personen, bei denen es sich um Erkrankte handelt. Alle hier genannten Patienten Ressourcen müssen der zugreifenden Person mithilfe von Einwilligungsanweisungen Zugriff gewähren. sonst werden die Ressourcen nicht zurückgegeben. Wenn eine Ressource eine Berechtigung hat aus einer Richtlinie, bei der auf eine Patient über das subject-Feld (STU3, R4), wird die Ressource vom geduldig zu sein.

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 Einwilligungsberechtigung auf der Ebene der einzelnen Ressourcen. Alle Referenzen in einer Ressource werden nicht aufgelöst und kaskadiert, um den Zugriff auf die Einwilligung zu prüfen. Angenommen, ein mit Patient/f001 identifizierter Patient, der eine Der Praxisexperte kann auf die gesamte MedicationRequest-Ressource zugreifen, aber nicht auf die Patient/f001-Ressource selbst, um den Datenschutz für Patienten zu gewährleisten. In diesem Szenario Er kann die gesamte MedicationRequest-Ressource sehen, einschließlich subject-Feld, das auf die Ressource Patient/f001 verweist, kann aber nicht sehen, der Patient/f001-Ressource selbst, z. B. bei der Durchführung eine FHIR-Suche mit _include.

Konfliktlösung

Zwischen verschiedenen permit- und deny-Richtlinien sind Konflikte möglich. Wenn zwei wenn eine Ressource mit einer Ressource übereinstimmt, wird der Konflikt mit der Methode Modell deny gewinnt gegen permit.

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 in der Google Cloud Dienstkonto (oder das Hauptkonto), das im Proxy konfiguriert ist. Wenn der Dienst Konto hat die erforderlichen IAM-Berechtigungen zum Ausführen der angeforderten FHIR-Methode im FHIR-Speicher, 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 Richtlinien für den Einwilligungsmodus basiert auf für die in der Anfrage angegebenen Einwilligungsumfänge Anweisungen, die bei der letzten Ausführung von ApplyConsents erfasst wurden, und ApplyAdminConsents.

   Hinweis: Wenn die Konfiguration des FHIR-Speichers den Parameter Verarbeitung des Einwilligungsheaders als REQUIRED_ON_READ, Zugriffssteuerung für Einwilligungen wird auch ohne Header mit Berücksichtigung der Einwilligung 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. die fhir.Patient-everything, fhir.Encounter-everything, fhir.executeBundle, oder fhir.search Methode), gilt die Erzwingung der Einwilligung 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.

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. 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 Einwilligungsumfang wird auch mit Einwilligungsanweisungen abgeglichen, 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