Diese Seite wurde von der Cloud Translation API übersetzt.

FHIR-Zugriffsdatenmodell und -Kontrollsystem

Auf dieser Seite wird beschrieben, wie Sie das FHIR-Zugriffssteuerungssystem der Cloud Healthcare API verwenden, um Ihre Gesundheitsdaten zu verwalten und zu schützen. Mit der FHIR-Zugriffssteuerung können Sie Einwilligungsrichtlinien definieren, den Datenzugriff basierend auf Nutzerrollen und Kontext steuern und diese Richtlinien in einem FHIR-Speicher erzwingen.

Übersicht über das Datenmodell

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

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 aufgezeichneten Aktionen können umfassend sein und sich auf mehr als nur die Daten der elektronischen Gesundheitsakte (EHR) des Nutzers beziehen. Für die Einwilligung in der Cloud Healthcare API liegt der Fokus jedoch auf Aktionen im Zusammenhang mit dem Datenzugriff. Die Durchsetzung dieser Aktionen beschränkt sich auf das Lesen von FHIR-Daten aus einem FHIR-Speicher.

Eine Consent-Ressource hat einen status, der den aktuellen Status der Einwilligung angibt. Ein FHIR-Speicher kann zwar viele Einwilligungen in verschiedenen Status enthalten, die Cloud Healthcare API erzwingt jedoch nur Einwilligungen, die den Status active haben. Einwilligungen in einem anderen Bundesstaat 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:

Patienteneinwilligung: ist einem Patienten mit Consent.patient (STU3, R4) zugeordnet und bindet so viele Daten wie durch den Patientenbereich (STU3, R4) definiert.
Administratorrichtlinie: Sie ist keinem Patienten zugeordnet 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 werden. Mit der Administratorrichtlinie wird die Standardrichtlinie für alle Bindungsressourcen im Store festgelegt.
Kaskadierende Administratorrichtlinie: 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 ein Compartment mit Ressourcen binden, die den Ressourcenkriterien entsprechen. Es gelten folgende Einschränkungen:
- Unterstützt nur „Patient“ (STU3, R4) oder „Encounter“ (STU3, R4) als Compartment-Basis.
- Für den FHIR-Speicher, in dem die Richtlinie erzwungen wird, muss disableReferentialIntegrity auf false gesetzt sein. Wenden Sie sich an den Cloud-Support, um diese Funktion für FHIR-Speicher ohne Referenzintegrität zu verwenden.

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 der Zugriff auf eine Ressource durch 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 Direktive bietet Folgendes:

Erzwingungstyp: eine permit- oder deny-Anweisung.
Aktion: Die Berechtigungen, die von dieser Richtlinie abgedeckt werden. Nur access wird für 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 Anweisung 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 Einzelperson, Gruppe oder Zugriffsrolle dar, die den Zugriffenden oder eine Eigenschaft des Zugriffenden identifiziert.
Zweck: Stellt die Absicht der Verwendung der Daten dar.
Umgebung: Ein abstrakter Bezeichner, der die Umgebung oder die Bedingungen beschreibt, unter denen der Accessor agiert.

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

Akteur: Practitioner/123
Zweck: ETREAT oder Zugriff für Notfallbehandlungen
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. 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: steht für den Ursprung der Ressource, wie durch die 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: steht für Sicherheitslabels, die betroffene Ressourcen definieren, wie im Feld meta.security (STU3, R4) angegeben. 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, die mit R oder niedriger gekennzeichnet sind. Wenn eine Einwilligung ein Sicherheitslabel R ablehnt, gilt dies für alle Ressourcen, die mindestens so vertraulich wie R sind.
- ActCode: Exakte String-Übereinstimmung für den Sicherheitscode.

Auf Workflow zugreifen

authorization_flow

In dieser Abbildung wird der End-to-End-Ablauf einer Anfrage an einen FHIR-Speicher mit aktivierter Zugriffssteuerung dargestellt. Ein externes Token mit dem Einwilligungsbereich (links) wird von Anwendung 3 verwendet, wenn eine Anfrage an den FHIR-Speicher mit aktivierter Zugriffssteuerung (rechts) gesendet 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. Die Werte für diese Eigenschaften müssen mit den in einer Einwilligung angegebenen Werten übereinstimmen (Groß-/Kleinschreibung beachten), 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 Einwilligungszusammenhang 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 Accessors 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 werden so definiert:

actor/{type}/{ID}: Eine actor-Property, in der die Ressource type zusammen mit dem ID bereitgestellt 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 zu 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

Außerdem können FHIR-HTTP-Anfrageheader auch spezielle Bereiche empfangen, z. B. btg und bypass, die so definiert sind:

btg: Mit „Break the Glass“ (BTG) können Sie als menschlicher Nutzer im Notfall die Einwilligungspflicht umgehen. Sie sollte nur in Notfällen verwendet werden und unterliegt einer nachträglichen Überprüfung. Daher ist für btg mindestens ein actor erforderlich.
bypass: Ermöglicht vertrauenswürdigen Nutzern (z. B. einem Administrator) oder vertrauenswürdigen Anwendungen (z. B. einer ML-Trainingspipeline), den FHIR-Speicher ohne Einwilligung zu verwenden. Daher sind für bypass mindestens ein actor und ein env erforderlich.

Zugriffserzwingung und Zugriffsermittlung

In einer komplexen Gesundheitsumgebung, in der mehrere Richtlinien und Einwilligungen nebeneinander bestehen, kann die Durchsetzung des Zugriffs und die Bestimmung von Zugriffsberechtigungen eine schwierige Aufgabe sein. Verschiedene Stakeholder können unterschiedliche Erwartungen und Anforderungen hinsichtlich der Verwendung und Offenlegung von Patienteninformationen haben. Um sich in dieser komplexen Umgebung zurechtzufinden, ist ein klares Verständnis davon erforderlich, wie der Zugriff erzwungen wird und welche zugrunde liegende Logik die Zugriffsbestimmung regelt.

Richtlinie zur zusammengefassten 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.

Attribute der Einwilligungsanweisung

Die Erzwingung der Einwilligung ist auf höchstens einen Zweck und höchstens eine Umgebung pro Bereitstellung-Eintrag beschränkt.

Die folgenden Regeln beschreiben die Grundsätze für die gemeinsame Zugriffssteuerung von Einwilligung des Patienten, Administratorrichtlinie und kaskadierender Administratorrichtlinie:

Der Zugriff auf alle Ressourcen wird standardmäßig verweigert, wenn keine passende Anweisung vorhanden ist.
Wenn die angeforderte Ressource nicht vorhanden ist, sind nur Ressourcentyp und Ressourcen-ID erkennbar. Wenn alle anderen Ressourcenkriterien und der Ressourceninhaber unbekannt sind, gilt in der Reihenfolge der Auflistung 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 Zugriffsmerkmal-Kriterien unabhängig von den anderen Ressourcenkriterien ablehnt, wird der Zugriff verweigert.
  - Wenn es eine Administratorrichtlinie gibt, die die Kriterien für den Zugriff auf 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 den Abgleich von Ressourcen im Store verwendet werden.
Ressourcen, die keinem Patienten gehören, werden nur durch die Administratorrichtlinien bestimmt.
Für Ressourcen, die sich im Patientenbereich (STU3, R4) oder im Encounter-Bereich (STU3, R4) befinden, ist mindestens eine „permit“-Einwilligungsanweisung pro Patient oder Administratorrichtlinie oder Administrator-Kaskadierungsrichtlinie und keine „deny“-Einwilligungsanweisung vom Patienten und Administratorrichtlinie und Administrator-Kaskadierungsrichtlinie erforderlich. 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 Patienten. Termin enthält beispielsweise eine Liste von Teilnehmern, bei denen es sich um Patienten handeln kann. Alle in solchen Ressourcen benannten 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 kaskadierenden Richtlinie für Begegnungen hat, wobei sich diese Begegnung über das Feld subject (STU3, R4) auf einen Patienten bezieht, gilt die Ressource als vom Patienten genehmigt.

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. Verweise in einer Ressource werden nicht aufgelöst und für die Prüfung des Einwilligungszugriffs kaskadiert. Ein Patient, der durch Patient/f001 identifiziert wird, ermöglicht einer Fachkraft beispielsweise den Zugriff auf seine gesamte MedicationRequest-Ressource, aber nicht auf die Patient/f001-Ressource selbst, da die Privatsphäre des Patienten geschützt werden muss. In diesem Szenario kann die Fachkraft 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 durchführt.

Konfliktlösung

Es kann zu Konflikten zwischen verschiedenen permit- und deny-Direktiven kommen. Wenn zwei widersprüchliche Anweisungen mit einer Ressource übereinstimmen, wird der Konflikt mithilfe des Modells 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 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 für den 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 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 von Einwilligungsheadern als REQUIRED_ON_READ definiert ist, wird die Einwilligungssensitiv-Zugriffssteuerung auch ohne die Einwilligungssensitiv-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. Methode fhir.Patient-everything, fhir.Encounter-everything, fhir.executeBundle oder fhir.search), gilt die Einwilligungserzwingung für jede einzelne Ressource. Es gibt jedoch einen geringfügigen 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 „Einwilligungszugriff abgelehnt oder die Ressource, auf die zugegriffen wird, ist nicht vorhanden“ zurückgeben, wenn der Aufrufer keine Einwilligungsberechtigung für die angeforderte Patienten- bzw. Begegnungsressource hat.

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. In einigen Einwilligungsanweisungen wird keine purpose oder environment angegeben. Daher muss der Einwilligungsbereich 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

Informationen zum Erzwingen des Zugriffs auf einen FHIR-Speicher