Mit SMART on FHIR eine Verbindung zu Anwendungen herstellen

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

Übersicht

SMART on FHIR ist ein Datenstandard, der Anwendungen den Zugriff Informationen in elektronischen Gesundheitsdatensystemen (EHR) zu sammeln. Eine Anwendung eine einzelne Anwendung schreiben, die mit allen EHR-Systemen das diesen 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 Patientendaten ab.
  3. Zeigt die Patientendaten auf einer Benutzeroberfläche an.

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

SMART-Framework für App-Einführung, Umfang und Einführungskontext

Die Cloud Healthcare API unterstützt das SMART App Launch Framework, und starten Sie den Kontext:

SMART App Launch Framework

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

Eine App kann aus einem vorhandenen EHR-System oder Patientenportal heraus gestartet werden die beide als „EHR-Einführung“ bezeichnet werden, oder als eigenständige App.

Bereiche

Bereiche für klinische Daten definieren Lese- und Schreibberechtigungen für den patientenspezifischen und den Nutzerzugriff. Die Cloud Healthcare API unterstützt Folgendes: die definierten Datenbereiche unter Bereiche für die Anforderung klinischer Daten:

  • patient
  • user
  • system
Startkontext

Beschreibt den aktuellen Patienten, den aktuellen Kontakt oder einen anderen Kontext in dem der Antrag 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 Client-Anwendung ein Zugriffstoken erhält, das die SMART-Autorisierungsbereiche und Patientenkontext gewährt, kann die Cloud Healthcare API geben Sie an, welchen Start-Workflow die Clientanwendung mit der externen Autorisierungsserver.

SMART-Autorisierungsbereiche festlegen und validieren

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

SMART-Autorisierungsbereiche haben das folgende Format:

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

SMART-Autorisierungsbereiche und Patientenkontexte werden an die Cloud Healthcare API übergeben mit X-Authorization--HTTP-Headern. 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 sowie 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 verwenden, HealthAPIx für Apigee.

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

  • X-Authorization-Scope: Einer oder mehrere Autorisierungsbereiche, die die Methode Standardformate für den SMART-Autorisierungsbereich. Wenn Sie z. B. den Autorisierungsbereich auf user/Observation.read festlegen, dass eine Anfrage nur eine Beobachtungsressource lesen kann. Die Die Cloud Healthcare API erzwingt diese Zugriffssteuerung.
  • X-Authorization-Patient: Der Kontext des Patienten der Anfrage. Wenn Sie werden alle Ressourcentypen in der Anfrage, die in einem Patientenfach muss zum Patientenfach gehören der angegebenen Patienten-ID. Die Cloud Healthcare API erzwingt dies 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 Audit-Logs
  • X-Authorization-Issuer: Der Aussteller des SMART-Zugriffstokens. Die Die Cloud Healthcare API protokolliert den Aussteller in Audit-Logs.

Zugriffstokens für den Autorisierungsserver konfigurieren

Wenn Sie ein JWT-Token ausgeben möchten, 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 Art und Weise, wie die Der Autorisierungsserver erstellt das SMART-JWT-Token. 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, SMART JWT-Token konfiguriert, können Sie die Apigee-basierte Interoperabilität verwenden Beschleuniger HealthAPIx auf Apigee zum Einrichten eines Authentifizierungsservers, der JWT-Tokens signiert.

Beispiel für ein Zugriffstoken

Das folgende Beispiel zeigt ein mit 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 einen eigenen Autorisierungsserver 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 Folgendes: SMART-Zugriffstokens als Teil des API-Verwaltungs- und Berechtigungsmodells.

Wenn Sie eine Anfrage zum Abrufen von Daten aus der Cloud Healthcare API stellen über SMARTProxy führt die Anfrage folgendermaßen aus:

  1. SMARTProxy akzeptiert eine Anfrage, die ein SMART-Token von einem Client 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 übergibt sie mithilfe von vier HTTP-Headern an die Cloud Healthcare API.
  4. Die Cloud Healthcare API empfängt die Header und validiert sie, um die Zugriffssteuerung für die Anfrage durchzusetzen. Mit der Cloud Healthcare API gibt eine Antwort über SMARTProxy an den Client zurück.

Google Cloud-Dienstkonto konfigurieren

Ein Proxy kann nur ein Google Cloud-Dienstkonto haben. Wenn Wenn mehrere Clients denselben Proxy verwenden, müssen die Clients denselben Dienst verwenden. Konto. Seien Sie vorsichtig, wenn Sie ein Dienstkonto für mehrere Clients freigeben aus folgenden Gründen:

  • 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 mit Ihrem Google-Konto zur Authentifizierung, dann protokolliert Cloud-Audit-Logs Ihre E-Mail-Adresse als E-Mail-Adresse des Hauptkontos. Wenn Sie die Cloud Healthcare API über einen Proxy aufrufen, Der Proxy verwendet sein eigenes Dienstkonto und die E-Mail-Adresse des Dienstkontos ist die E-Mail-Adresse des Hauptkontos, sodass der ursprüngliche Aufrufer verdeckt wird. Um den Endnutzer in den Metadaten des Audit-Logs zu speichern, übergeben Sie in der E-Mail-Adresse des Endnutzers im 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 auf 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.

Wenn Sie eine Anfrage stellen, ist Ihr Autorisierungsserver für Zugriffstokens mit dem relevanten SMART-Autorisierungsbereich generieren und Kontext für die Markteinführung.

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

Beim Senden einer SMART on FHIR-Anfrage an einen FHIR-Speicher 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 den die richtigen IAM-Berechtigungen für den FHIR-Speicher haben, 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 entscheidend für die Zugangsdurchsetzung Logik in der Cloud Healthcare API. SMART on FHIR enthält eine Liste FHIR-Ressourcentypen die in ein Patientenfach gelegt werden können. Ressourcentypen eigene Einschlusskriterien haben. 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 resourceType und der Typ des Vorgangs (read oder write) übereinstimmen. Andernfalls wird die Anfrage von der Cloud Healthcare API abgelehnt.

  • 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 der Kontext eines Patienten ist mit einem user Bereich vorhanden, Ressourcentypen für Patientenbereiche sind auf den Kontext der Erkrankten beschränkt. Die verbleibenden Ressourcentypen den Kontext der behandelten Person ignorieren.

  • Das Vorhandensein eines Patientenkontexts schränkt die Ressourcentypen erlaubt für den Patientenbereich ein und zwar auf den angegebenen Patienten. Eine Beobachtungsressource muss beispielsweise die Das Feld subject verweist auf die angegebene Patientenressource, damit die Beobachtung zugänglich ist. Unter Resource CompartmentDefinition – Content findest du die Zugriffstypen für die Patientenbereiche. finden Sie eine Liste der Felder für jeden Ressourcentyp des Patientenfachs. muss auf den angegebenen Patienten verwiesen werden, damit die Ressource berücksichtigt wird im Patientenfach befinden.

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

  • Verwenden Sie den Bereich 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.