Über SMART on FHIR eine Verbindung zu Anwendungen herstellen

Auf dieser Seite wird beschrieben, wie Sie mit dem Standard SMART (Substitable Medical Applications, Reusable Technologies) on FHIR v1.1.0 auf Daten in FHIR-Speichern in der Cloud Healthcare API zugreifen.

Übersicht

SMART on FHIR ist ein Datenstandard, mit dem Anwendungen auf Informationen in EHR-Systemen (elektronischer Krankenaktensysteme) zugreifen können. Ein Anwendungsentwickler kann eine einzelne Anwendung erstellen, die mit jedem EHR-System verbunden werden kann, das den Standard übernommen hat.

Wenn Sie beispielsweise Patientendaten in einem FHIR-Speicher in der Cloud Healthcare API gespeichert haben, können Sie eine Anwendung entwickeln, die Folgendes ermöglicht:

  1. Er authentifiziert sich beim FHIR-Speicher.
  2. Ruft die Daten des Patienten ab.
  3. Zeigt die Daten des Patienten in einer Benutzeroberfläche an.

SMART on FHIR unterstützt die OpenID- und OAuth 2.0-Autorisierungsmodelle für die Autorisierung und Authentifizierung.

SMART App Launch Framework, Bereiche und Startkontext

Die Cloud Healthcare API unterstützt das SMART App Launch Framework, Bereiche und Startkontext wie unten beschrieben:

SMART App Launch Framework

Die Cloud Healthcare API unterstützt die eigenständige Startsequenz aus dem SMART App Launch Framework.

Eine Anwendung kann aus einer existierenden EHR-System- oder Patientenportalsitzung gestartet werden. Diese werden beide als „EHR-Start“ bezeichnet. Sie kann auch als eigenständige App gestartet werden.

Bereiche

Bereiche für klinische Daten definieren Lese- und Schreibberechtigungen für den patientenspezifischen und den Nutzerzugriff. Die Cloud Healthcare API unterstützt die folgenden Datenbereiche, die unter Bereiche zum Anfordern von klinischen Daten definiert sind:

  • patient
  • user
  • system
Startkontext

Beschreibt den aktuellen Patienten, die Begegnung oder einen anderen Kontext, in dem die Anfrage gestellt wird. Die Cloud Healthcare API unterstützt den Patientenstartkontext aus Bereiche zum Anfordern von Kontextdaten.

Autorisierungsserver für SMART on FHIR konfigurieren

Die Cloud Healthcare API bietet integrierte Unterstützung für die Erzwingung von SMART on FHIR-Zugriff, basierend auf den Eingabe-SMART-Autorisierungsbereichen und dem Patientenkontext. FHIR-Speicheradministratoren erstellen und konfigurieren einen Autorisierungsserver außerhalb der Cloud Healthcare API, der SMART-Autorisierungsbereiche und Patientenkontext gewährt.

Wenn eine Clientanwendung ein Zugriffstoken erhält, das die gewährten SMART-Autorisierungsbereiche und den Patientenkontext darstellt, gibt die Cloud Healthcare API nicht an, welchen Startworkflow die Clientanwendung mit dem externen Autorisierungsserver verwenden muss.

SMART-Autorisierungsbereiche festlegen und überprüfen

Wenn Sie SMARTProxy verwenden, können Sie diesen Abschnitt überspringen. SMARTProxy legt SMART-Autorisierungsbereiche automatisch fest und validiert sie.

SMART-Autorisierungsbereiche haben das folgende Format:

( 'patient' | 'user' | 'system') '/' ( resourceType | '*' ) '.' ( 'read' | 'write' | '*' )

SMART-Autorisierungsbereiche und Patientenkontexte werden über X-Authorization--HTTP-Header an die Cloud Healthcare API übergeben. Die Cloud Healthcare API verwendet diese Header, um die Zugriffssteuerung für Daten in FHIR-Speichern zu erzwingen.

Ihr Autorisierungsserver gewährt die SMART-Autorisierungsbereiche und den Patientenkontext und codiert sie in einem Zugriffstoken. Der Proxy liest dann die Informationen im Zugriffstoken und gibt sie in die FHIR-Anfrageheader ein.

Wenn Sie keinen Autorisierungsserver haben, können Sie den Apigee-basierten Interoperabilitätsbeschleuniger HealthAPIx in Apigee verwenden.

Verwenden Sie die folgenden SMART on FHIR-HTTP-Header, wenn Sie Anfragen vom Proxy senden. Die Clientanwendung muss diese Header nicht festlegen, da sie nur vom Proxy an die Cloud Healthcare API übergeben werden.

  • X-Authorization-Scope: Eine oder mehrere Autorisierungsbereiche, die die standardmäßigen SMART-Autorisierungsformate verwenden. Wenn Sie beispielsweise den Autorisierungsbereich auf user/Observation.read festlegen, kann eine Anfrage nur eine Beobachtungsressource lesen. Die Cloud Healthcare API erzwingt diese Zugriffssteuerung.
  • X-Authorization-Patient: Der Patientenkontext der Anfrage. Wenn Sie diesen Header festlegen, müssen alle Ressourcentypen in der Anfrage, die in einem Patientenbereich sein können, zum Patientenbereich der angegebenen Patienten-ID gehören. Die Cloud Healthcare API erzwingt diese Zugriffssteuerung.
  • X-Authorization-Subject: Eine ID für den Endnutzer, der auf die SMART-on-FHIR-Client-Anwendung zugreift. Die Cloud Healthcare API protokolliert das Subjekt in Audit-Logs.
  • X-Authorization-Issuer: Der Aussteller des SMART-Zugriffstokens. Die Cloud Healthcare API protokolliert den Aussteller in Audit-Logs.

Zugriffstokens für den Autorisierungsserver konfigurieren

Um ein JWT-Token auszustellen, müssen Sie einen Autorisierungsserver konfigurieren. Das JWT-Token enthält die SMART-Autorisierungsbereiche und optional den Patientenkontext. Die Cloud Healthcare API stellt keine spezifischen Anforderungen an die Erstellung des SMART-JWT-Tokens durch den Autorisierungsserver. Ihre Anwendung kann beispielsweise für eine Teilmenge von Bereichen registriert sein oder die Anwendung könnte ein Widget zur Patientenauswahl zur Festlegung des Patientenkontexts präsentieren.

Wenn Sie keinen Autorisierungsserver haben, der SMART-JWT-Tokens konfiguriert, können Sie den Apigee-basierten Interoperabilitätsbeschleuniger HealthAPIx in Apigee verwenden, um einen Authentifizierungsserver einzurichten, der JWT-Tokens signiert.

Beispiel für ein Zugriffstoken

Das folgende Beispiel zeigt ein base64-codiertes Zugriffstoken:

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzM4NCJ9.eyJpc3MiOiJzbWFydC50b2tlbi5vcmciLCJpYXQiOjE2MTI4ODQwODUsImV4cCI6MTY0NDQyMDA4NSwiYXVkIjoid3d3LmV4YW1wbGUuY29tIiwic3ViIjoiZG9jdG9yLmpvZUBleGFtcGxlLmNvbSIsInNjb3BlIjoidXNlci9QcmFjdGl0aW9uZXIucmVhZCBwYXRpZW50LyouKiIsInBhdGllbnQiOiJwYXRpZW50MTIzIn0.lC0ouNuXNcj7FxQ83NU_MInULWo0wvyiNuaMt2RbFzBOnnMP_IXJdCeNnw3SQzUV

Nach der Decodierung des Zugriffstokens enthält es die folgende Nutzlast:

{
  "iss": "smart.token.org",
  "iat": 1612884085,
  "exp": 1644420085,
  "aud": "www.example.com",
  "sub": "doctor.gabriela@example.com",
  "scope": "user/Practitioner.read patient/*.*",
  "patient": "patient123"
}

SMART on FHIR in der Cloud Healthcare API konfigurieren

In diesem Abschnitt werden die Schritte beschrieben, die erforderlich sind, um SMART on FHIR mit Daten in der Cloud Healthcare API zu verwenden.

SMARTProxy konfigurieren

Wenn Sie anstelle von SMARTProxy Ihren eigenen Autorisierungsserver verwenden, überspringen Sie diesen Abschnitt und fahren Sie mit Google Cloud-Dienstkonto konfigurieren fort.

SMARTProxy ist ein Open-Source-Proxy von Google mit den folgenden Funktionen:

  • Ermöglicht der Cloud Healthcare API, SMART-Zugriffstokens zu akzeptieren und zu validieren.
  • Ermöglicht der FHIR-Implementierung in der Cloud Healthcare API, SMART-Zugriffstokens als Teil des Verwaltungs- und Berechtigungsmodells der API zu inkludieren.

Wenn Sie eine Anfrage zum Abrufen von Daten aus der Cloud Healthcare API über SMARTProxy stellen, gehen Sie so vor:

  1. SMARTProxy akzeptiert eine Anfrage von einem Client, die ein SMART-Token enthält.
  2. SMARTProxy validiert das SMART-Token über Ihren JWT-Autorisierungsserver.
  3. SMARTProxy liest die Bereiche und den Patientenkontext aus dem SMART-Token und leitet sie über vier HTTP-Header an die Cloud Healthcare API weiter.
  4. Die Cloud Healthcare API empfängt die Header und validiert sie, um die Zugriffssteuerung für die Anfrage durchzusetzen. Die Cloud Healthcare API gibt dann eine Antwort über SMARTProxy an den Client zurück.

Google Cloud-Dienstkonto konfigurieren

Ein Proxy kann nur ein Google Cloud-Dienstkonto haben. Wenn mehrere Clients denselben Proxy verwenden, müssen sie dasselbe Dienstkonto verwenden. Die gemeinsame Nutzung eines Dienstkontos mit mehreren Kunden ist aus folgenden Gründen mit Vorsicht zu genießen:

  • Zum Lesen der FHIR-Daten in der Cloud Healthcare API hat das Dienstkonto weitreichende Lese- und Schreibberechtigungen.

  • Die Hauptkonto-E-Mail-Adresse von Cloud-Audit-Logs ist an das Dienstkonto gebunden.

    Wenn Sie beispielsweise die Cloud Healthcare API aufrufen und Ihr Google-Konto zur Authentifizierung nutzen, protokolliert Cloud-Audit-Logs Ihre E-Mail-Adresse als Hauptkonto-E-Mail-Adresse. Wenn Sie einen Proxy zum Aufrufen der Cloud Healthcare API verwenden, verwendet der Proxy sein eigenes Dienstkonto und die E-Mail-Adresse des Dienstkontos ist die Hauptkonto-E-Mail-Adresse. Der ursprüngliche Aufrufer wird also ausgeblendet. Wenn Sie den Endnutzer in den Metadaten des Audit-Logs speichern möchten, geben Sie die E-Mail-Adresse des Endnutzers in das Feld sub des JWT-Tokens ein.

FHIR-Speicher konfigurieren

Sie müssen den FHIR-Speicher, der die FHIR-Daten enthält, auf die Sie zugreifen, nicht konfigurieren.

SMART on FHIR-Anfragen stellen

Dieser Abschnitt bietet einen Überblick über die unterstützten SMART on FHIR-Methoden in der Cloud Healthcare API und wie der Ressourcenzugriff erzwungen wird, wenn Sie eine SMART on FHIR-Anfrage stellen.

Bei Stellen einer Anfrage ist Ihr Autorisierungsserver für die Generierung von Zugriffstokens mit dem entsprechenden SMART-Autorisierungsbereich und dem Launch-Kontext verantwortlich.

Unterstützte Methoden

Die Cloud Healthcare API unterstützt SMART on FHIR für alle projects.locations.datasets.fhirStores.fhir-Methoden mit folgenden Ausnahmen:

Erzwingung des Ressourcenzugriffs

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

  1. Die Cloud Healthcare API prüft die Berechtigungen des Google Cloud-Dienstkonto, das im Proxy konfiguriert ist. Wenn das Dienstkonto die richtigen IAM-Berechtigungen für den FHIR-Speicher hat, wird die Anfrage fortgesetzt.
  2. Die Cloud Healthcare API prüft, ob das SMART-Token die entsprechenden Berechtigungen für den Zugriff auf jede FHIR-Ressource hat, die in der Anfrage angefordert wird.

Der Patientenbereich ist für die Logik der Zugriffserzwingung in der Cloud Healthcare API von entscheidender Bedeutung. SMART on FHIR enthält eine Liste der FHIR-Ressourcentypen, die in einem Patientenbereich enthalten sein können. Die Ressourcentypen haben auch eigene Aufnahmekriterien. Im weiteren Verlauf dieses Abschnitts werden die zulässigen Ressourcentypen als "Ressourcentypen erlaubt für Patientenbereiche" bezeichnet. Unzulässige Ressourcentypen werden als "nicht für den Patientenbereich erlaubte Ressourcentypen“ bezeichnet.

SMART on FHIR-Anfragen an einen FHIR-Speicher müssen die folgenden Anforderungen erfüllen:

  • Geben Sie die Rolle patient, user oder system in den SMART-Autorisierungsbereichen an. Wenn Sie die Rolle patient angeben, müssen Sie einen Patientenkontext angeben. Der Patientenkontext ist die logische ID einer Patientenressource. Die Patientenressource muss bereits im FHIR-Speicher vorhanden sein oder vorhanden sein, nachdem die Anfrage gesendet wurde. Andernfalls lehnt die Cloud Healthcare API die Anfrage ab.

  • Beim Erstellen, Lesen, Aktualisieren oder Löschen einer Ressource müssen der resourceType und der Vorgangstyp (read oder write) übereinstimmen. Andernfalls lehnt die Cloud Healthcare API die Anfrage ab.

  • Wenn Sie den Bereich patient angeben, der für Patientenbereiche nicht zulässige Ressourcentypen enthält, z. B. patient/Practitioner.*, schlägt die Überprüfung des Bereichs fehl und die Cloud Healthcare API lehnt den Bereich ab.

  • Sie können alle Ressourcentypen mit dem Umfang user festlegen. Wenn ein Patientenkontext mit dem Bereich user vorhanden ist, werden die Ressourcentypen, die für den Patientenbereich zulässig sind, auf den Patientenkontext beschränkt. Bei den übrigen Ressourcentypen wird der Patientenkontext ignoriert.

  • Das Vorhandensein eines Patientenkontexts schränkt die Ressourcentypen erlaubt für den Patientenbereich ein und zwar auf den angegebenen Patienten. Beispiel: Bei einer Beobachtungsressource muss das Feld subject auf die angegebene Patientenressource verweisen, damit auf die Beobachtung zugegriffen werden kann. Eine Liste der Felder, die in jedem Ressourcentyp für den Patientenbereich auf den angegebenen Patienten verweisen müssen, damit die Ressource als im Patientenbereich betrachtet wird, finden Sie in den Zugriffstypen für den Patientenbereich unter Ressourcenbereichsdefinition – Inhalt.

  • Anfragen können sowohl patient- als auch user-Bereiche enthalten.

  • Verwenden Sie den Umfang system nicht mit dem Patientenkontext, da die Anfrage sonst fehlschlägt.

  • Verwenden Sie den Bereich system nicht mit dem Bereich patient oder user.

  • Wenn Sie eine Methode aufrufen, die auf mehrere Ressourcen zugreift (z. B. fhir.Patient-everything, fhir.executeBundle oder fhir.search), gilt die Zugriffssteuerung für jede einzelne Ressource.