Über SMART mit FHIR Verbindungen zu Anwendungen herstellen

Auf dieser Seite wird beschrieben, wie Sie den Standard SMART (Substitutable Medical Applications, Reusable Technologies) des FHIR v1.1.0-Standards verwenden, um auf Daten in FHIR-Speichern in der Cloud Healthcare API zuzugreifen.

Überblick

SMART on FHIR ist ein Datenstandard, der Anwendungen den Zugriff auf Informationen in elektronischen Patientenaktensystemen (EHR) ermöglicht. Ein Anwendungsentwickler kann eine einzelne Anwendung schreiben, die eine Verbindung zu einem beliebigen EHR-System nach dem Standard herstellt.

Wenn Sie beispielsweise Patientendaten in einem FHIR-Speicher in der Cloud Healthcare API gespeichert haben, können Sie eine Anwendung entwickeln, die folgende Aufgaben erfüllt:

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

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

SMART App Launch Framework, Umfang und Einführungskontext

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

SMART App Launch Framework

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

Eine Anwendung kann aus einem vorhandenen EHR-System oder einer Patientenportal-Sitzung heraus gestartet werden. Beide werden als „EHR-Start“ bezeichnet oder als eigenständige App.

Bereiche

In klinischen Datenbereichen sind Lese- und Schreibberechtigungen für den patientenspezifischen Zugriff und den Zugriff auf Nutzerebene definiert. Die Cloud Healthcare API unterstützt die folgenden Datenbereiche, die unter Bereiche für das Anfordern klinischer Daten definiert sind:

  • patient
  • user
  • system
Kontext der Einführung

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.

Konfigurieren Sie Ihren Autorisierungsserver für SMART auf FHIR

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 validieren

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

SMART-Autorisierungsbereiche verwenden das folgende Format:

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

SMART-Autorisierungsbereiche und Patientenkontexte werden mithilfe von X-Authorization--HTTP-Headern 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 übergibt sie an die FHIR-Anfrageheader.

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: Ein oder mehrere Autorisierungsbereiche, die die Standardformate für SMART-Autorisierungsbereiche 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: Kontext des Patienten in 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 Thema in Audit-Logs.
  • X-Authorization-Issuer: Der SMART-Zugriffstoken-Aussteller. Die Cloud Healthcare API protokolliert den Aussteller in Audit-Logs.

Zugriffstokens für den Autorisierungsserver konfigurieren

Zum Ausgeben eines JWT-Tokens müssen Sie einen Autorisierungsserver konfigurieren. Das JWT-Token enthält die SMART-Autorisierungsbereiche und optional den Patientenkontext. Die Cloud Healthcare API hat keine spezifischen Anforderungen dafür, wie der Autorisierungsserver das SMART-JWT-Token erstellt. 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 mit dem Apigee-basierten Interoperabilitätsbeschleuniger HealthAPIx in Apigee einen Authentifizierungsserver einrichten, der JWT-Tokens signiert.

Beispiel für ein Zugriffstoken

Das folgende Beispiel zeigt ein Zugriffstoken, das in base64 codiert ist:

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 Ihren eigenen Autorisierungsserver anstelle von SMARTProxy verwenden, überspringen Sie diesen Abschnitt und fahren Sie mit Google Cloud-Dienstkonto konfigurieren fort.

SMARTProxy ist ein Open-Source-Proxy von Google, der die folgenden Funktionen bietet:

  • 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 API-Verwaltungs- und Berechtigungsmodells einzubeziehen.

Wenn Sie eine Anfrage zum Abrufen von Daten aus der Cloud Healthcare API über SMARTProxy stellen, führt die Anfrage die folgenden Schritte aus:

  1. SMARTProxy akzeptiert eine Anfrage, die ein SMART-Token von einem Client enthält.
  2. SMARTProxy validiert das SMART-Token über deinen JWT-Autorisierungsserver.
  3. SMARTProxy liest die Bereiche und den Patientenkontext aus dem SMART-Token und leitet sie mithilfe von vier HTTP-Headern an die Cloud Healthcare API weiter.
  4. Die Cloud Healthcare API empfängt die Header und validiert sie, um eine Zugriffssteuerung für die Anfrage zu erzwingen. Die Cloud Healthcare API gibt dann über SMARTProxy eine Antwort 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 die Clients dasselbe Dienstkonto verwenden. Seien Sie aus den folgenden Gründen vorsichtig, wenn Sie ein Dienstkonto für mehrere Clients freigeben:

  • 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 zur Authentifizierung mit Ihrem Google-Konto aufrufen, protokolliert Cloud-Audit-Logs Ihre E-Mail-Adresse als Haupt-E-Mail-Adresse. Wenn Sie einen Proxy zum Aufrufen der Cloud Healthcare API verwenden, verwendet der Proxy sein eigenes Dienstkonto. Die E-Mail-Adresse des Dienstkontos ist die Haupt-E-Mail-Adresse, sodass der ursprüngliche Aufrufer nicht sichtbar ist. Um den Endnutzer in den Metadaten des Audit-Logs zu speichern, übergeben Sie die E-Mail-Adresse des Endnutzers im Feld sub des JWT-Tokens.

FHIR-Speicher konfigurieren

Sie müssen den FHIR-Speicher mit den FHIR-Daten, auf die Sie zugreifen, nicht konfigurieren.

SMART für FHIR-Anfragen stellen

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

Wenn Sie eine Anfrage stellen, ist Ihr Autorisierungsserver für das Generieren von Zugriffstokens mit dem relevanten SMART-Autorisierungsbereich und dem Startkontext verantwortlich.

Unterstützte Methoden

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

Erzwingung des Ressourcenzugriffs

Wenn Sie eine SMART-on-FHIR-Anfrage an einen FHIR-Speicher stellen, erfolgt die Zugriffssteuerung in der folgenden 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 Zugriffslogik in der Cloud Healthcare API von entscheidender Bedeutung. SMART zu FHIR hat eine Liste von FHIR-Ressourcentypen, die in einen Patientenbereich aufgenommen werden können. Für die Ressourcentypen gelten außerdem 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 bei FHIR-Anfragen an einen FHIR-Speicher muss 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 Informationen zu den Patienten angeben. Der Patientenkontext ist eine logische ID der Patientenressource. Die Patientenressource muss bereits im FHIR-Speicher oder nach der Anfrage vorhanden sein. Andernfalls lehnt die Cloud Healthcare API die Anfrage ab.

  • Beim Erstellen, Lesen, Aktualisieren oder Löschen einer Ressource müssen die 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 Bereich user festlegen. Wenn ein Patientenkontext mit einem user-Bereich vorhanden ist, sind die für Patientenbereiche zulässigen Ressourcentypen auf den Patientenkontext beschränkt. Die verbleibenden Ressourcentypen ignorieren den Patientenkontext.

  • Das Vorhandensein eines Patientenkontexts schränkt die Ressourcentypen erlaubt für den Patientenbereich ein und zwar auf den angegebenen Patienten. Beispielsweise muss das Feld subject bei einer Beobachtungsressource auf die angegebene Patientenressource verweisen, damit die Beobachtung zugänglich ist. Unter Resource CompartmentDefinition – Content finden Sie unter Resource CompartmentDefinition – Content die Zugriffstypen für den Patientenbereich. Dort finden Sie eine Liste der Felder, die in jedem Ressourcentyp des Patientenfachs auf den jeweiligen Patienten verweisen müssen, damit die Ressource im Patientenbereich berücksichtigt wird.

  • Anfragen können die Bereiche patient und user enthalten.

  • Verwenden Sie den Bereich system nicht für den Patienten. Andernfalls schlägt die Anfrage fehl.

  • 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.