Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# SMART on FHIR-Unterstützung für AWS HealthLake
Ein auf FHIR basierender HealthLake Datenspeicher mit austauschbaren medizinischen Anwendungen und wiederverwendbaren Technologien (SMART) ermöglicht den Zugriff auf SMART auf FHIR-konformen Anwendungen. HealthLake Der Datenzugriff erfolgt durch Authentifizierung und Autorisierung von Anfragen mithilfe eines Autorisierungsservers eines Drittanbieters. Anstatt die Benutzeranmeldedaten über zu verwalten AWS Identity and Access Management, verwenden Sie einen SMART-On-FHIR-kompatiblen Autorisierungsserver.
**Anmerkung**
HealthLake unterstützt SMART auf den FHIR-Versionen 1.0 und 2.0. Weitere Informationen zu diesen Frameworks finden Sie unter [SMART App Launch](https://www.hl7.org/fhir/smart-app-launch/) in der *FHIR R4-Dokumentation*.
HealthLake Datenspeicher unterstützen die folgenden Authentifizierungs- und Autorisierungs-Frameworks für SMART bei FHIR-Anfragen:
**OpenID (AuthN)**: zur Authentifizierung der Person oder der Client-Anwendung, wer (oder was) sie vorgibt zu sein.
**OAuth 2.0 (AuthZ)**: zur Autorisierung, auf welche FHIR-Ressourcen in Ihrem HealthLake Datenspeicher eine authentifizierte Anfrage lesen oder schreiben kann. Dies wird durch die Bereiche definiert, die auf Ihrem Autorisierungsserver eingerichtet sind.
Mit dem oder können Sie einen SMART on FHIR-fähigen Datenspeicher erstellen. AWS CLI AWS SDKs Weitere Informationen finden Sie unter [Einen HealthLake Datenspeicher erstellen](managing-data-stores-create.md).
**Topics**
+ [Erste Schritte mit SMART auf FHIR](reference-smart-on-fhir-getting-started.md)
+ [HealthLake Authentifizierungsanforderungen für SMART auf FHIR](reference-smart-on-fhir-authentication.md)
+ [SMART auf FHIR OAuth 2.0-Bereichen, unterstützt von HealthLake](reference-smart-on-fhir-oauth-scopes.md)
+ [Token-Validierung mit AWS Lambda](reference-smart-on-fhir-token-validation.md)
+ [Verwendung detaillierter Autorisierung mit einem SMART on FHIR-fähigen Datenspeicher HealthLake](reference-smart-on-fhir-fine-grained-authorization.md)
+ [Das SMART on FHIR Discovery-Dokument wird abgerufen](reference-smart-on-fhir-discovery-document.md)
+ [Eine FHIR-REST-API-Anfrage für einen HealthLake SMART-fähigen Datenspeicher stellen](reference-smart-on-fhir-request-example.md)
# Erste Schritte mit SMART auf FHIR
In den folgenden Themen wird beschrieben, wie Sie mit SMART bei der FHIR-Autorisierung für beginnen. AWS HealthLake Sie beinhalten die Ressourcen, die Sie in Ihrem AWS Konto bereitstellen müssen, die Erstellung eines SMART on FHIR-fähigen HealthLake Datenspeichers und ein Beispiel dafür, wie eine SMART on FHIR-Clientanwendung mit einem Autorisierungsserver und einem Datenspeicher interagiert. HealthLake
**Topics**
+ [Ressourcen für SMART auf FHIR einrichten](#smart-on-fhir-resources)
+ [Arbeitsablauf für Client-Anwendungen für SMART auf FHIR](#smart-on-fhir-client-app-workflow)
## Ressourcen für SMART auf FHIR einrichten
In den folgenden Schritten wird definiert, wie SMART-Anfragen von FHIR bearbeitet werden HealthLake und welche Ressourcen benötigt werden, um erfolgreich zu sein. Die folgenden Elemente arbeiten in einem Workflow zusammen, um eine SMART-on-FHIR-Anfrage zu erstellen:
+ **Der Endbenutzer**: In der Regel ein Patient oder ein Arzt, der eine SMART on FHIR-Anwendung eines Drittanbieters verwendet, um auf Daten in einem Datenspeicher zuzugreifen. HealthLake
+ **Die SMART on FHIR-Anwendung (als Client-Anwendung bezeichnet): Eine Anwendung, die** auf Daten zugreifen möchte, die sich im Datenspeicher befinden. HealthLake
+ **Der Autorisierungsserver**: Ein OpenID Connect-kompatibler Server, der Benutzer authentifizieren und Zugriffstoken ausstellen kann.
+ **Der HealthLake Datenspeicher**: Ein SMART on FHIR-fähiger HealthLake Datenspeicher, der eine Lambda-Funktion verwendet, um auf FHIR-REST-Anfragen zu antworten, die ein Bearer-Token bereitstellen.
Damit diese Elemente zusammenarbeiten können, müssen Sie die folgenden Ressourcen erstellen.
**Anmerkung**
Wir empfehlen, Ihren SMART on FHIR-fähigen HealthLake Datenspeicher zu erstellen, nachdem Sie den Autorisierungsserver eingerichtet, die erforderlichen [Bereiche](reference-smart-on-fhir-oauth-scopes.md) darauf definiert und eine AWS Lambda Funktion zur [Token-Introspektion](reference-smart-on-fhir-token-validation.md) erstellt haben.
**1. Richten Sie einen Autorisierungsserver-Endpunkt ein**
Um das SMART on FHIR-Framework verwenden zu können, müssen Sie einen Autorisierungsserver eines Drittanbieters einrichten, der FHIR-REST-Anfragen validieren kann, die in einem Datenspeicher gestellt wurden. Weitere Informationen finden Sie unter [HealthLake Authentifizierungsanforderungen für SMART auf FHIR](reference-smart-on-fhir-authentication.md).
**2. Definieren Sie Bereiche auf Ihrem Autorisierungsserver, um die Zugriffsebenen für HealthLake Datenspeicher zu kontrollieren**
Das SMART on FHIR-Framework verwendet OAuth Bereiche, um zu bestimmen, auf welche FHIR-Ressourcen eine authentifizierte Anfrage Zugriff hat und in welchem Umfang. Die Definition von Bereichen ist eine Möglichkeit, beim Design die geringsten Rechte zu berücksichtigen. Weitere Informationen finden Sie unter [SMART auf FHIR OAuth 2.0-Bereichen, unterstützt von HealthLake](reference-smart-on-fhir-oauth-scopes.md).
**3. Richten Sie eine AWS Lambda Funktion ein, die eine Token-Introspektion durchführen kann**
Eine FHIR-REST-Anfrage, die von der Client-Anwendung auf einem SMART on FHIR-fähigen Datenspeicher gesendet wird, enthält ein JSON-Web-Token (JWT). Weitere Informationen finden Sie unter Ein JWT [dekodieren](reference-smart-on-fhir-token-validation.md).
**4. Erstellen Sie einen SMART-on-FHIR-fähigen Datenspeicher HealthLake**
Um einen SMART on HealthLake FHIR-Datenspeicher zu erstellen, müssen Sie einen angeben. `IdentityProviderConfiguration` Weitere Informationen finden Sie unter [Einen HealthLake Datenspeicher erstellen](managing-data-stores-create.md).
## Arbeitsablauf für Client-Anwendungen für SMART auf FHIR
Im folgenden Abschnitt wird erklärt, wie Sie im Kontext von SMART auf FHIR eine Client-Anwendung starten und eine erfolgreiche FHIR-REST-Anfrage für einen HealthLake Datenspeicher stellen.
**1. Stellen Sie mithilfe der Client-Anwendung eine `GET` Anfrage an den Known Uniform Resource Identifier**
Eine SMART-fähige Client-Anwendung muss eine `GET` Anfrage stellen, um die Autorisierungsendpunkte Ihres HealthLake Datenspeichers zu finden. Dies erfolgt über eine URI-Anfrage (Known Uniform Resource Identifier). Weitere Informationen finden Sie unter [Das SMART on FHIR Discovery-Dokument wird abgerufen](reference-smart-on-fhir-discovery-document.md).
**2. Zugriff und Geltungsbereiche anfordern**
Die Client-Anwendung verwendet den Autorisierungsendpunkt des Autorisierungsservers, sodass sich der Benutzer anmelden kann. Dieser Prozess authentifiziert den Benutzer. Bereiche werden verwendet, um zu definieren, auf welche FHIR-Ressourcen in Ihrem HealthLake Datenspeicher eine Client-Anwendung zugreifen kann. Weitere Informationen finden Sie unter [SMART auf FHIR OAuth 2.0-Bereichen, unterstützt von HealthLake](reference-smart-on-fhir-oauth-scopes.md).
**3. Zugriffstoken**
Nachdem der Benutzer nun authentifiziert wurde, erhält eine Client-Anwendung ein JWT-Zugriffstoken vom Autorisierungsserver. Dieses Token wird bereitgestellt, wenn die Client-Anwendung eine FHIR-REST-Anfrage an sendet. HealthLake Weitere Informationen finden Sie unter [Token-Validierung](reference-smart-on-fhir-token-validation.md).
**4. Stellen Sie eine FHIR-REST-API-Anfrage auf SMART auf einem FHIR-fähigen Datenspeicher HealthLake**
Die Client-Anwendung kann jetzt mithilfe des vom Autorisierungsserver bereitgestellten Zugriffstokens eine FHIR-REST-API-Anfrage an einen HealthLake Datenspeicher-Endpunkt senden. Weitere Informationen finden Sie unter [Eine FHIR-REST-API-Anfrage für einen HealthLake SMART-fähigen Datenspeicher stellen](reference-smart-on-fhir-request-example.md).
**5. Validieren Sie das JWT-Zugriffstoken**
Verwenden Sie eine Lambda-Funktion, um das in der FHIR-REST-Anfrage gesendete Zugriffstoken zu validieren. Weitere Informationen finden Sie unter [Token-Validierung mit AWS Lambda](reference-smart-on-fhir-token-validation.md).
# HealthLake Authentifizierungsanforderungen für SMART auf FHIR
Um auf FHIR-Ressourcen in einem SMART-on-FHIR-fähigen HealthLake Datenspeicher zuzugreifen, muss eine Client-Anwendung von einem OAuth 2.0-kompatiblen Autorisierungsserver autorisiert werden und ein OAuth Bearer-Token als Teil einer FHIR-REST-API-Anforderung vorlegen. Um den Endpunkt des Autorisierungsservers zu finden, verwenden Sie das HealthLake SMART on FHIR Discovery-Dokument über einen Uniform Resource Identifier. `Well-Known` Weitere Informationen zu diesem Prozess finden Sie unter [Das SMART on FHIR Discovery-Dokument wird abgerufen](reference-smart-on-fhir-discovery-document.md).
Wenn Sie einen HealthLake SMART-on-FHIR-Datenspeicher erstellen, müssen Sie den Endpunkt des Autorisierungsservers und den Token-Endpunkt im `metadata` Element der `CreateFHIRDatastore` Anfrage definieren. Weitere Informationen zur Definition des `metadata` Elements finden Sie unter[Einen HealthLake Datenspeicher erstellen](managing-data-stores-create.md).
Mithilfe der Endpunkte des Autorisierungsservers authentifiziert die Client-Anwendung einen Benutzer beim Autorisierungsdienst. Nach der Autorisierung und Authentifizierung wird ein JSON Web Token (JWT) vom Autorisierungsdienst generiert und an die Client-Anwendung übergeben. Dieses Token enthält FHIR-Ressourcenbereiche, die die Client-Anwendung verwenden darf, was wiederum einschränkt, auf welche Daten der Benutzer zugreifen kann. Wenn der Startbereich angegeben wurde, enthält die Antwort optional diese Details. Weitere Informationen zu den SMART on FHIR-Bereichen, die von unterstützt werden HealthLake, finden Sie unter. [SMART auf FHIR OAuth 2.0-Bereichen, unterstützt von HealthLake](reference-smart-on-fhir-oauth-scopes.md)
Mithilfe des vom Autorisierungsserver gewährten JWT führt eine Client-Anwendung FHIR-REST-API-Aufrufe an einen SMART on FHIR-fähigen Datenspeicher durch. HealthLake Um das JWT zu validieren und zu dekodieren, müssen Sie eine Lambda-Funktion erstellen. HealthLake ruft diese Lambda-Funktion in Ihrem Namen auf, wenn eine FHIR-REST-API-Anfrage empfangen wird. Ein Beispiel für eine Lambda-Starterfunktion finden Sie unter[Token-Validierung mit AWS Lambda](reference-smart-on-fhir-token-validation.md).
## Elemente des Autorisierungsservers, die zum Erstellen eines SMART on FHIR-fähigen HealthLake Datenspeichers erforderlich sind
In der `CreateFHIRDatastore` Anfrage müssen Sie den Autorisierungsendpunkt und den Token-Endpunkt als Teil des `metadata` Elements im `IdentityProviderConfiguration` Objekt angeben. Sowohl der Autorisierungsendpunkt als auch der Token-Endpunkt sind erforderlich. Ein Beispiel dafür, wie dies in einer `CreateFHIRDatastore` Anfrage angegeben wird, finden Sie unter[Einen HealthLake Datenspeicher erstellen](managing-data-stores-create.md).
## Erforderliche Ansprüche, um eine FHIR-REST-API-Anfrage in einem SMART on FHIR-fähigen Datenspeicher abzuschließen HealthLake
Ihre AWS Lambda Funktion muss die folgenden Behauptungen enthalten, damit es sich um eine gültige FHIR-REST-API-Anfrage in einem SMART on FHIR-fähigen Datenspeicher handelt. HealthLake
+ `nbf`: Anspruch [(nicht vorher) — Der Anspruch](https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.5) „nbf“ (nicht vorher) gibt den Zeitpunkt an, bis zu dem das JWT NICHT zur Bearbeitung akzeptiert werden DARF. Die Bearbeitung des Antrags mit der Angabe „Nbf“ setzt voraus, dass der aktuelle Wert hinter dem im date/time Antrag „Nbf“ date/time genannten Wert liegt oder diesem entspricht. Die von uns bereitgestellte Lambda-Beispielfunktion konvertiert `iat` von der Serverantwort in`nbf`.
+ `exp`: [(Ablaufzeit) -Anspruch](https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.4) — Der Anspruch „exp“ (Ablaufzeit) gibt die Ablaufzeit an oder nach der das JWT nicht zur Bearbeitung akzeptiert werden darf.
+ `isAuthorized`: Ein boolescher Wert, der auf gesetzt ist. `True` Zeigt an, dass die Anfrage auf dem Autorisierungsserver autorisiert wurde.
+ `aud`: [(Zielgruppenanspruch)](https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.3) — Der Anspruch „aud“ (Zielgruppe) identifiziert die Empfänger, für die das JWT bestimmt ist. Dies muss ein SMART on FHIR-fähiger HealthLake Datenspeicher-Endpunkt sein.
+ `scope`: Dies muss mindestens ein Bereich sein, der sich auf FHIR-Ressourcen bezieht. Dieser Bereich ist auf Ihrem Autorisierungsserver definiert. Weitere Informationen zu den von akzeptierten Bereichen im Zusammenhang mit FHIR-Ressourcen finden Sie unter HealthLake. [Die Ressourcen von SMART auf FHIR umfassen folgende Bereiche HealthLake](reference-smart-on-fhir-oauth-scopes.md#smart-on-fhir-scopes-rest)
# SMART auf FHIR OAuth 2.0-Bereichen, unterstützt von HealthLake
HealthLake verwendet OAuth 2.0 als Autorisierungsprotokoll. Wenn Sie dieses Protokoll auf Ihrem Autorisierungsserver verwenden, können Sie HealthLake Datenspeicherberechtigungen (Erstellen, Lesen, Aktualisieren, Löschen und Suchen) für FHIR-Ressourcen definieren, auf die eine Client-Anwendung Zugriff hat.
Das SMART on FHIR-Framework definiert eine Reihe von Bereichen, die vom Autorisierungsserver angefordert werden können. Beispielsweise sollte eine Client-Anwendung, die nur darauf ausgelegt ist, dass Patienten ihre Laborergebnisse oder ihre Kontaktdaten einsehen können, nur *berechtigt* sein, Bereiche anzufordern`read`.
**Anmerkung**
HealthLake bietet Unterstützung für SMART auf FHIR V1 und V2, wie unten beschrieben. SMART auf FHIR [https://docs.aws.amazon.com/healthlake/latest/APIReference/API_IdentityProviderConfiguration.html#HealthLake-Type-IdentityProviderConfiguration-AuthorizationStrategy](https://docs.aws.amazon.com/healthlake/latest/APIReference/API_IdentityProviderConfiguration.html#HealthLake-Type-IdentityProviderConfiguration-AuthorizationStrategy)wird bei der Erstellung Ihres Datenspeichers auf einen der folgenden drei Werte gesetzt:
`SMART_ON_FHIR_V1`— Support nur für SMART auf FHIR V1, einschließlich `read` (Lesen/Suchen) und `write` (create/update/delete) Berechtigungen.
`SMART_ON_FHIR`— Support für SMART auf FHIR V1 und V2, einschließlich`create`,`read`, `update``delete`, und `search` Berechtigungen.
`AWS_AUTH`— Die AWS HealthLake Standard-Autorisierungsstrategie; nicht mit SMART auf FHIR verbunden.
## Umfang der eigenständigen Markteinführung
HealthLake unterstützt den Bereich des eigenständigen Startmodus`launch/patient`.
Im eigenständigen Startmodus fordert eine Client-Anwendung Zugriff auf die klinischen Daten des Patienten an, da der Benutzer und der Patient der Client-Anwendung nicht bekannt sind. Daher fordert die Autorisierungsanfrage der Client-Anwendung ausdrücklich die Rückgabe des Patientenbereichs an. Nach erfolgreicher Authentifizierung gibt der Autorisierungsserver ein Zugriffstoken aus, das den angeforderten Patientenstartbereich enthält. Der benötigte Patientenkontext wird zusammen mit dem Zugriffstoken in der Antwort des Autorisierungsservers bereitgestellt.
**Unterstützte Bereiche für den Startmodus**
| Scope | Description |
| --- | --- |
| `launch/patient` | Ein Parameter in einer OAuth 2.0-Autorisierungsanfrage, der anfordert, dass Patientendaten in der Autorisierungsantwort zurückgegeben werden. |
## Die Ressourcen von SMART auf FHIR umfassen folgende Bereiche HealthLake
HealthLake definiert drei Ebenen von SMART für FHIR-Ressourcenbereiche.
+ `patient`Bereiche gewähren Zugriff auf spezifische Daten über einen einzelnen Patienten.
+ `user`Bereiche gewähren Zugriff auf bestimmte Daten, auf die ein Benutzer zugreifen kann.
+ `system`Bereiche gewähren Zugriff auf alle FHIR-Ressourcen, die sich im HealthLake Datenspeicher befinden.
In den folgenden Abschnitten ist die Syntax für die Erstellung von FHIR-Ressourcenbereichen mit SMART auf FHIR V1 oder SMART auf FHIR V2 aufgeführt.
**Anmerkung**
Die Autorisierungsstrategie von SMART auf FHIR wird bei der Erstellung Ihres Datenspeichers festgelegt. Weitere Informationen finden Sie unter [https://docs.aws.amazon.com/healthlake/latest/APIReference/API_IdentityProviderConfiguration.html#HealthLake-Type-IdentityProviderConfiguration-AuthorizationStrategy](https://docs.aws.amazon.com/healthlake/latest/APIReference/API_IdentityProviderConfiguration.html#HealthLake-Type-IdentityProviderConfiguration-AuthorizationStrategy) in der *AWS HealthLake -API-Referenz*.
### SMART auf FHIR V1-Bereichen, unterstützt von HealthLake
Bei der Verwendung von SMART auf FHIR V1 gilt die allgemeine Syntax für die Erstellung von FHIR-Ressourcenbereichen wie folgt. HealthLake **Scrollen Sie über die Schaltfläche Kopieren, um den gesamten URL-Pfad im folgenden Beispiel anzuzeigen.**
```
('patient' | 'user' | 'system') '/' (fhir-resource | '*') '.' ('read' | 'write' | '*')
```
**SMART auf FHIR v1 unterstützte Autorisierungsbereiche**
| Syntax des Geltungsbereichs | Beispiel für einen Geltungsbereich | Ergebnis |
| --- | --- | --- |
| `patient/(fhir-resource \| '*').('read' \| 'write' \| '*')` | patient/AllergyIntolerance.\$1 | Die Client-Anwendung für Patienten hat Lese-/Schreibzugriff auf Instanzebene auf alle aufgezeichneten Allergien. |
| `user/(fhir-resource \| '*').('read' \| 'write' \| '*')` | user/Observation.read | Die Benutzer-Client-Anwendung hat Zugriff auf Instanzebene auf read/write alle aufgezeichneten Beobachtungen. |
| system/('read' \$1 'write' \$1 \$1) | system/\$1.\$1 | Die System-Client-Anwendung hat read/write Zugriff auf alle FHIR-Ressourcendaten. |
### SMART auf FHIR V2-Bereichen, unterstützt von HealthLake
Bei der Verwendung von SMART auf FHIR V2 gilt die allgemeine Syntax für die Erstellung von FHIR-Ressourcenbereichen wie folgt. HealthLake **Scrollen Sie über die Schaltfläche Kopieren, um den gesamten URL-Pfad im folgenden Beispiel anzuzeigen.**
```
('patient' | 'user' | 'system') '/' (fhir-resource | '*') '.' ('c' | 'r' | 'u' | 'd' | 's')
```
**Anmerkung**
Um SMART auf FHIR V2 zu verwenden, müssen Sie den Wert [https://hl7.org/fhir/smart-app-launch/STU2/conformance.html#permissions](https://hl7.org/fhir/smart-app-launch/STU2/conformance.html#permissions)in die `capabilities` Metadatenzeichenfolge übergeben, die ein Mitglied des [https://docs.aws.amazon.com/healthlake/latest/APIReference/API_IdentityProviderConfiguration.html](https://docs.aws.amazon.com/healthlake/latest/APIReference/API_IdentityProviderConfiguration.html)Datentyps ist.
HealthLake unterstützt detaillierte Bereiche. Weitere Informationen finden Sie unter [Unterstützte detaillierte Bereiche](https://hl7.org/fhir/us/core/scopes.html#the-following-granular-scopes-shall-be-supported) im *FHIR* US Core Implementation Guide.
**SMART auf FHIR V2 unterstützte Autorisierungsbereiche**
| Syntax des Geltungsbereichs | Beispiel für einen V1-Bereich | Ergebnis |
| --- | --- | --- |
| `patient/Observation.rs` | user/Observation.read | Erlaubnis zum Lesen und Durchsuchen der Observation Ressource für den aktuellen Patienten. |
| `system/*.cruds` | system/\$1.\$1 | Die System-Client-Anwendung hat vollen create/read/update/delete/search Zugriff auf alle FHIR-Ressourcendaten. |
# Token-Validierung mit AWS Lambda
Wenn Sie einen HealthLake SMART on FHIR-fähigen Datenspeicher erstellen, müssen Sie den ARN der AWS Lambda Funktion in der `CreateFHIRDatastore` Anfrage angeben. Der ARN der Lambda-Funktion wird im `IdentityProviderConfiguration` Objekt mithilfe des `IdpLambdaArn` Parameters angegeben.
Sie müssen die Lambda-Funktion erstellen, bevor Sie Ihren SMART on FHIR-fähigen Datenspeicher erstellen. Sobald Sie den Datenspeicher erstellt haben, kann der Lambda-ARN nicht mehr geändert werden. Verwenden Sie die `DescribeFHIRDatastore` API-Aktion, um den Lambda-ARN zu sehen, den Sie bei der Erstellung des Datenspeichers angegeben haben.
**Damit eine FHIR-REST-Anfrage auf einem SMART on FHIR-fähigen Datenspeicher erfolgreich ist, muss Ihre Lambda-Funktion Folgendes tun:**
+ Gibt in weniger als 1 Sekunde eine Antwort an den HealthLake Datenspeicher-Endpunkt zurück.
+ Dekodieren Sie das Zugriffstoken, das im Autorisierungsheader der von der Client-Anwendung gesendeten REST-API-Anforderung bereitgestellt wird.
+ Weisen Sie eine IAM-Servicerolle zu, die über ausreichende Berechtigungen verfügt, um die FHIR-REST-API-Anfrage auszuführen.
+ Die folgenden Ansprüche sind erforderlich, um eine FHIR-REST-API-Anfrage abzuschließen. Weitere Informationen hierzu finden Sie unter [Erforderliche Ansprüche](reference-smart-on-fhir-authentication.md#server-response).
+ `nbf`
+ `exp`
+ `isAuthorized`
+ `aud`
+ `scope`
Wenn Sie mit Lambda arbeiten, müssen Sie zusätzlich zu Ihrer Lambda-Funktion eine Ausführungsrolle und eine ressourcenbasierte Richtlinie erstellen. Die Ausführungsrolle einer Lambda-Funktion ist eine IAM-Rolle, die der Funktion die Berechtigung erteilt, auf AWS-Services und -Ressourcen zuzugreifen, die zur Laufzeit benötigt werden. Die von Ihnen bereitgestellte ressourcenbasierte Richtlinie muss es ermöglichen HealthLake , Ihre Funktion in Ihrem Namen aufzurufen.
In den Abschnitten dieses Themas werden eine Beispielanforderung von einer Client-Anwendung und eine dekodierte Antwort, die zum Erstellen einer AWS Lambda-Funktion erforderlichen Schritte und das Erstellen einer ressourcenbasierten Richtlinie beschrieben, die Folgendes voraussetzen kann. HealthLake
+ [Teil 1: Eine Lambda-Funktion erstellen](#smart-on-fhir-lambda-create)
+ [Teil 2: Erstellen einer HealthLake Servicerolle, die von der AWS Lambda-Funktion verwendet wird](#smart-on-fhir-lambda-service-role)
+ [Teil 3: Aktualisierung der Ausführungsrolle der Lambda-Funktion](#smart-on-fhir-lambda-service-role-execution-role)
+ [Teil 4: Hinzufügen einer Ressourcenrichtlinie zu Ihrer Lambda-Funktion](#smart-on-fhir-lambda-invoke-healthlake)
+ [Teil 5: Bereitstellung von Parallelität für Ihre Lambda-Funktion](#smart-on-fhir-lambda-function-scaling)
## Eine AWS Lambda-Funktion erstellen
Die in diesem Thema erstellte Lambda-Funktion wird ausgelöst, wenn Anfragen an einen SMART on FHIR-fähigen Datenspeicher HealthLake empfangen werden. Die Anfrage von der Client-Anwendung enthält einen REST-API-Aufruf und einen Autorisierungsheader, der ein Zugriffstoken enthält.
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/
Authorization: Bearer i8hweunweunweofiwweoijewiwe
```
Die Lambda-Beispielfunktion in diesem Thema verwendet AWS Secrets Manager , um Anmeldeinformationen für den Autorisierungsserver zu verschleiern. Wir empfehlen dringend, Anmeldedaten für den Autorisierungsserver nicht direkt in einer Lambda-Funktion anzugeben.
**Example Validierung einer FHIR-REST-Anfrage, die ein Autorisierungsträgertoken enthält**
Die Lambda-Beispielfunktion zeigt Ihnen, wie Sie eine FHIR-REST-Anfrage validieren, die an einen SMART on FHIR-fähigen Datenspeicher gesendet wurde. step-by-stepsAnweisungen zur Implementierung dieser Lambda-Funktion finden Sie unter[Erstellen einer Lambda-Funktion mit dem AWS-Managementkonsole](#create-lambda-console).
Wenn die FHIR-REST-API-Anforderung keinen gültigen Datenspeicher-Endpunkt, kein Zugriffstoken und keinen gültigen REST-Vorgang enthält, schlägt die Lambda-Funktion fehl. Weitere Informationen zu den erforderlichen Autorisierungsserverelementen finden Sie unter. [Erforderliche Ansprüche](reference-smart-on-fhir-authentication.md#server-response)
```
import base64
import boto3
import logging
import json
import os
from urllib import request, parse
logger = logging.getLogger()
logger.setLevel(logging.INFO)
## Uses Secrets manager to gain access to the access key ID and secret access key for the authorization server
client = boto3.client('secretsmanager', region_name="region-of-datastore")
response = client.get_secret_value(SecretId='name-specified-by-customer-in-secretsmanager')
secret = json.loads(response['SecretString'])
client_id = secret['client_id']
client_secret = secret['client_secret']
unencoded_auth = f'{client_id}:{client_secret}'
headers = {
'Authorization': f'Basic {base64.b64encode(unencoded_auth.encode()).decode()}',
'Content-Type': 'application/x-www-form-urlencoded'
}
auth_endpoint = os.environ['auth-server-base-url'] # Base URL of the Authorization server
user_role_arn = os.environ['iam-role-arn'] # The IAM role client application will use to complete the HTTP request on the datastore
def lambda_handler(event, context):
if 'datastoreEndpoint' not in event or 'operationName' not in event or 'bearerToken' not in event:
return {}
datastore_endpoint = event['datastoreEndpoint']
operation_name = event['operationName']
bearer_token = event['bearerToken']
logger.info('Datastore Endpoint [{}], Operation Name: [{}]'.format(datastore_endpoint, operation_name))
## To validate the token
auth_response = auth_with_provider(bearer_token)
logger.info('Auth response: [{}]'.format(auth_response))
auth_payload = json.loads(auth_response)
## Required parameters needed to be sent to the datastore endpoint for the HTTP request to go through
auth_payload["isAuthorized"] = bool(auth_payload["active"])
auth_payload["nbf"] = auth_payload["iat"]
return {"authPayload": auth_payload, "iamRoleARN": user_role_arn}
## access the server
def auth_with_provider(token):
data = {'token': token, 'token_type_hint': 'access_token'}
req = request.Request(url=auth_endpoint + '/v1/introspect', data=parse.urlencode(data).encode(), headers=headers)
with request.urlopen(req) as resp:
return resp.read().decode()
```
### Erstellen einer Lambda-Funktion mit dem AWS-Managementkonsole
Beim folgenden Verfahren wird davon ausgegangen, dass Sie die Servicerolle, die Sie bei der Bearbeitung einer FHIR-REST-API-Anfrage in einem SMART on FHIR-fähigen Datenspeicher übernehmen möchten HealthLake , bereits erstellt haben. Wenn Sie die Servicerolle nicht erstellt haben, können Sie trotzdem die Lambda-Funktion erstellen. Sie müssen den ARN der Servicerolle hinzufügen, damit die Lambda-Funktion funktioniert. Weitere Informationen zum Erstellen einer Servicerolle und deren Angabe in der Lambda-Funktion finden Sie unter [Erstellen einer HealthLake Servicerolle zur Verwendung in der AWS Lambda-Funktion, die zum Dekodieren eines JWT verwendet wird](#smart-on-fhir-lambda-service-role)
**Um eine Lambda-Funktion ()AWS-Managementkonsole zu erstellen**
1. Öffnen Sie die Seite [Funktionen](https://console.aws.amazon.com/lambda/home/functions) der Lambda-Konsole.
1. Wählen Sie **Funktion erstellen**.
1. Wählen Sie **Verfassen von Grund auf** aus.
1. Geben Sie unter **Basisinformationen** einen **Funktionsnamen** ein. Wählen Sie unter **Runtime** eine Python-basierte Runtime aus.
1. Wählen Sie für **Execution role** (Ausführungsrolle) die Option **Create a new role with basic Lambda permissions** (Neue Rolle mit grundlegenden Lambda-Berechtigungen erstellen) aus.
Lambda erstellt eine [Ausführungsrolle](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html), die der Funktion die Berechtigung zum Hochladen von Protokollen auf Amazon CloudWatch erteilt. Die Lambda-Funktion übernimmt die Ausführungsrolle, wenn Sie Ihre Funktion aufrufen, und verwendet die Ausführungsrolle, um Anmeldeinformationen für das AWS SDK zu erstellen.
1. Wählen Sie die Registerkarte **Code** und fügen Sie die Lambda-Beispielfunktion hinzu.
Wenn Sie die Servicerolle für die zu verwendende Lambda-Funktion noch nicht erstellt haben, müssen Sie sie erstellen, bevor die Lambda-Beispielfunktion funktioniert. Weitere Informationen zum Erstellen einer Servicerolle für die Lambda-Funktion finden Sie unter[Erstellen einer HealthLake Servicerolle zur Verwendung in der AWS Lambda-Funktion, die zum Dekodieren eines JWT verwendet wird](#smart-on-fhir-lambda-service-role).
```
import base64
import boto3
import logging
import json
import os
from urllib import request, parse
logger = logging.getLogger()
logger.setLevel(logging.INFO)
## Uses Secrets manager to gain access to the access key ID and secret access key for the authorization server
client = boto3.client('secretsmanager', region_name="region-of-datastore")
response = client.get_secret_value(SecretId='name-specified-by-customer-in-secretsmanager')
secret = json.loads(response['SecretString'])
client_id = secret['client_id']
client_secret = secret['client_secret']
unencoded_auth = f'{client_id}:{client_secret}'
headers = {
'Authorization': f'Basic {base64.b64encode(unencoded_auth.encode()).decode()}',
'Content-Type': 'application/x-www-form-urlencoded'
}
auth_endpoint = os.environ['auth-server-base-url'] # Base URL of the Authorization server
user_role_arn = os.environ['iam-role-arn'] # The IAM role client application will use to complete the HTTP request on the datastore
def lambda_handler(event, context):
if 'datastoreEndpoint' not in event or 'operationName' not in event or 'bearerToken' not in event:
return {}
datastore_endpoint = event['datastoreEndpoint']
operation_name = event['operationName']
bearer_token = event['bearerToken']
logger.info('Datastore Endpoint [{}], Operation Name: [{}]'.format(datastore_endpoint, operation_name))
## To validate the token
auth_response = auth_with_provider(bearer_token)
logger.info('Auth response: [{}]'.format(auth_response))
auth_payload = json.loads(auth_response)
## Required parameters needed to be sent to the datastore endpoint for the HTTP request to go through
auth_payload["isAuthorized"] = bool(auth_payload["active"])
auth_payload["nbf"] = auth_payload["iat"]
return {"authPayload": auth_payload, "iamRoleARN": user_role_arn}
## Access the server
def auth_with_provider(token):
data = {'token': token, 'token_type_hint': 'access_token'}
req = request.Request(url=auth_endpoint + '/v1/introspect', data=parse.urlencode(data).encode(), headers=headers)
with request.urlopen(req) as resp:
return resp.read().decode()
```
### Die Ausführungsrolle einer Lambda-Funktion ändern
Nachdem Sie die Lambda-Funktion erstellt haben, müssen Sie die Ausführungsrolle aktualisieren, sodass sie die erforderlichen Berechtigungen zum Aufrufen von Secrets Manager enthält. In Secrets Manager hat jedes Secret, das Sie erstellen, einen ARN. Um die geringste Berechtigung anzuwenden, sollte die Ausführungsrolle nur Zugriff auf die Ressourcen haben, die für die Ausführung der Lambda-Funktion benötigt werden.
Sie können die Ausführungsrolle einer Lambda-Funktion ändern, indem Sie in der IAM-Konsole danach suchen oder in der Lambda-Konsole **Konfiguration** auswählen. Weitere Informationen zur Verwaltung Ihrer Ausführungsrolle für Lambda-Funktionen finden Sie unter[Lambda-Ausführungsrolle](#smart-on-fhir-lambda-service-role-execution-role).
**Example Lambda-Funktionsausführungsrolle, die Zugriff gewährt auf `GetSecretValue`**
Durch das Hinzufügen der IAM-Aktion `GetSecretValue` zur Ausführungsrolle wird die erforderliche Berechtigung erteilt, damit die Lambda-Beispielfunktion funktioniert.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "secretsmanager:GetSecretValue",
"Resource": "arn:aws:secretsmanager:us-east-1:123456789012:secret:secret-name-DKodTA"
}
]
}
```
Zu diesem Zeitpunkt haben Sie eine Lambda-Funktion erstellt, mit der Sie das Zugriffstoken validieren können, das als Teil der FHIR-REST-Anfrage an Ihren SMART on FHIR-fähigen Datenspeicher gesendet wurde.
## Erstellen einer HealthLake Servicerolle zur Verwendung in der AWS Lambda-Funktion, die zum Dekodieren eines JWT verwendet wird
**Persona: IAM-Administrator**
Ein Benutzer, der IAM-Richtlinien hinzufügen oder entfernen und neue IAM-Identitäten erstellen kann.
**Service – -Rolle**
Eine Servicerolle ist eine [IAM-Rolle](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html), die ein Service annimmt, um Aktionen in Ihrem Namen auszuführen. Ein IAM-Administrator kann eine Servicerolle innerhalb von IAM erstellen, ändern und löschen. Weitere Informationen finden Sie unter [Erstellen einer Rolle zum Delegieren von Berechtigungen an einen AWS-Service](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) im *IAM-Benutzerhandbuch*.
Nachdem das JSON Web Token (JWT) dekodiert wurde, benötigt Lambda die Autorisierung, um auch einen IAM-Rollen-ARN zurückzugeben. Diese Rolle muss über die erforderlichen Berechtigungen verfügen, um die REST-API-Anfrage auszuführen. Andernfalls schlägt sie aufgrund unzureichender Berechtigungen fehl.
Bei der Einrichtung einer benutzerdefinierten Richtlinie mithilfe von IAM empfiehlt es sich, die erforderlichen Mindestberechtigungen zu gewähren. *Weitere Informationen finden Sie unter [Anwenden von Berechtigungen mit den geringsten Rechten im IAM-Benutzerhandbuch](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege).*
Das Erstellen einer HealthLake Servicerolle, die in der Autorisierungs-Lambda-Funktion festgelegt werden soll, erfordert zwei Schritte.
+ Zunächst müssen Sie eine IAM-Richtlinie erstellen. Die Richtlinie muss den Zugriff auf die FHIR-Ressourcen spezifizieren, für die Sie Bereiche auf dem Autorisierungsserver bereitgestellt haben.
+ Zweitens müssen Sie die Servicerolle erstellen. Wenn Sie die Rolle erstellen, legen Sie eine Vertrauensbeziehung fest und fügen die Richtlinie hinzu, die Sie in Schritt eins erstellt haben. Die Vertrauensstellung wird als HealthLake Dienstprinzipal bezeichnet. In diesem Schritt müssen Sie einen HealthLake Datenspeicher-ARN und eine AWS Konto-ID angeben.
### Eine neue IAM-Richtlinie erstellen
Die Bereiche, die Sie auf Ihrem Autorisierungsserver definieren, bestimmen, auf welche FHIR-Ressourcen ein authentifizierter Benutzer in einem Datenspeicher zugreifen kann. HealthLake
Die von Ihnen erstellte IAM-Richtlinie kann an die von Ihnen definierten Bereiche angepasst werden.
Die folgenden Aktionen können im `Action` Element einer IAM-Richtlinienerklärung definiert werden. Für jede `Action` in der Tabelle können Sie eine `Resource types` definieren. In HealthLake einem Datenspeicher befindet sich der einzige unterstützte Ressourcentyp, der im `Resource` Element einer IAM-Berechtigungsrichtlinie definiert werden kann.
Einzelne FHIR-Ressourcen sind keine Ressource, die Sie als Element in einer IAM-Berechtigungsrichtlinie definieren können.
**Aktionen, definiert von HealthLake**
| Aktionen | Beschreibung | Zugriffsebene | Ressourcentyp (erforderlich) |
| --- | --- | --- | --- |
| CreateResource | Erteilt die Erlaubnis, eine Ressource zu erstellen | Schreiben | Datenspeicher-ARN: arn:aws:healthlake: ::datastore/fhir/ your-region 111122223333 your-datastore-id |
| DeleteResource | Gewährt die Berechtigung zum Löschen von Ressourcen | Schreiben | Datenspeicher-ARN: arn:aws:healthlake: ::datastore/fhir/ your-region 111122223333 your-datastore-id |
| ReadResource | Gewährt die Berechtigung zum Lesen von Ressourcen | Lesen | Datenspeicher-ARN: arn:aws:healthlake: ::datastore/fhir/ your-region 111122223333 your-datastore-id |
| SearchWithGet | Gewährt die Berechtigung, Ressourcen mit der GET-Methode zu durchsuchen | Lesen | Datenspeicher-ARN: arn:aws:healthlake: ::datastore/fhir/ your-region 111122223333 your-datastore-id |
| SearchWithPost | Gewährt die Berechtigung, Ressourcen mit der POST-Methode zu durchsuchen | Lesen | Datenspeicher-ARN: arn:aws:healthlake: ::datastore/fhir/ your-region 111122223333 your-datastore-id |
| Starten FHIRExport JobWithPost | Erteilt die Erlaubnis, einen FHIR-Exportauftrag mit GET zu starten | Schreiben | Datenspeicher-ARN: arn:aws:healthlake: ::datastore/fhir/ your-region 111122223333 your-datastore-id |
| UpdateResource | Gewährt die Berechtigung zum Aktualisieren von Ressourcen | Schreiben | Datenspeicher-ARN: arn:aws:healthlake: ::datastore/fhir/ your-region 111122223333 your-datastore-id |
Um zu beginnen, können Sie verwenden. `AmazonHealthLakeFullAccess` Diese Richtlinie würde Lese-, Schreib-, Such- und Exportvorgänge für alle FHIR-Ressourcen in einem Datenspeicher zulassen. Um nur Leseberechtigungen für die Verwendung eines Datenspeichers zu gewähren. `AmazonHealthLakeReadOnlyAccess`
*Weitere Informationen zum Erstellen einer benutzerdefinierten Richtlinie mithilfe von AWS-Managementkonsole AWS CLI, oder IAM SDKs finden Sie unter [Erstellen von IAM-Richtlinien im IAM-Benutzerhandbuch](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html).*
### Eine Servicerolle für HealthLake (IAM-Konsole) erstellen
Gehen Sie wie folgt vor, um eine Servicerolle zu erstellen. Wenn Sie einen Dienst erstellen, müssen Sie auch eine IAM-Richtlinie festlegen.
**Um die Servicerolle für HealthLake (IAM-Konsole) zu erstellen**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die IAM-Konsole unter. [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)
1. Wählen Sie im Navigationsbereich der IAM Console **Roles** (Rollen) aus.
1. Wählen Sie anschließend **Create role** (Rolle erstellen) aus.
1. **Wählen Sie auf der Seite Vertrauensentität** auswählen die Option **Benutzerdefinierte Vertrauensrichtlinie** aus.
1. Aktualisieren Sie anschließend unter **Benutzerdefinierte Vertrauensrichtlinie** die Beispielrichtlinie wie folgt. **your-account-id**Ersetzen Sie es durch Ihre Kontonummer und fügen Sie den ARN des Datenspeichers hinzu, den Sie für Ihre Import- oder Exportaufträge verwenden möchten.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Principal": {
"Service": "healthlake.amazonaws.com"
},
"Condition": {
"StringEquals": {
"aws:SourceAccount": "123456789012"
},
"ArnEquals": {
"aws:SourceArn": "arn:aws:healthlake:us-east-1:123456789012:datastore/fhir/your-datastore-id"
}
}
}
]
}
```
------
1. Wählen Sie anschließend **Weiter**.
1. Wählen Sie auf der Seite „**Berechtigungen hinzufügen**“ die Richtlinie aus, die der HealthLake Dienst annehmen soll. Um Ihre Richtlinie zu finden, suchen Sie unter **Berechtigungsrichtlinien danach**.
1. Wählen Sie dann **Richtlinie anhängen** aus.
1. Geben Sie dann auf der Seite **Name, Überprüfung und Erstellung** unter **Rollenname** einen Namen ein.
1. (Optional) Fügen Sie anschließend unter **Beschreibung** eine kurze Beschreibung für Ihre Rolle hinzu.
1. Geben Sie möglichst einen Rollennamen oder ein Rollennamen-Suffix ein, mit dem der Zweck dieser Rolle einfach zu erkennen ist. Rollennamen müssen innerhalb Ihres AWS-Konto-Kontos eindeutig sein. Sie werden nicht nach Groß- und Kleinschreibung unterschieden. z. B. können Sie keine Rollen erstellen, die **PRODROLE** bzw. **prodrole** heißen. Da möglicherweise verschiedene Entitäten auf die Rolle verweisen, kann der Rollenname nach der Erstellung nicht bearbeitet werden.
1. Überprüfen Sie die Rollendetails und wählen Sie dann **Rolle erstellen** aus.
Informationen zur Angabe der Rolle ARN in der Lambda-Beispielfunktion finden Sie unter[Eine AWS Lambda-Funktion erstellen](#smart-on-fhir-lambda-create).
## Lambda-Ausführungsrolle
Die Ausführungsrolle einer Lambda-Funktion ist eine IAM-Rolle, die der Funktion die Berechtigung zum Zugriff auf AWS Dienste und Ressourcen erteilt. Diese Seite enthält Informationen zum Erstellen, Anzeigen und Verwalten der Ausführungsrolle einer Lambda-Funktion.
Standardmäßig erstellt Lambda eine Ausführungsrolle mit minimalen Berechtigungen, wenn Sie eine neue Lambda-Funktion mit dem erstellen. AWS-Managementkonsole Informationen zur Verwaltung der in der Ausführungsrolle gewährten Berechtigungen finden Sie unter [Erstellen einer Ausführungsrolle in der IAM-Konsole](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html#permissions-executionrole-console) im *Lambda Developer Guide*.
Die in diesem Thema vorgestellte Lambda-Beispielfunktion verwendet Secrets Manager, um die Anmeldeinformationen des Autorisierungsservers zu verschleiern.
Wie bei jeder IAM-Rolle, die Sie erstellen, ist es wichtig, die bewährte Methode mit den geringsten Rechten zu befolgen. Während der Entwicklungsphase können Sie manchmal Berechtigungen gewähren, die über das hinausgehen, was erforderlich ist. Bevor Sie Ihre Funktion in der Produktionsumgebung veröffentlichen, sollten Sie als bewährte Methode die Richtlinie so anpassen, dass sie nur die erforderlichen Berechtigungen enthält. Weitere Informationen finden Sie unter [Anwenden der geringsten Rechte im *IAM-Benutzerhandbuch*](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege).
## Erlaube HealthLake , deine Lambda-Funktion auszulösen
Um die Lambda-Funktion in Ihrem Namen aufrufen zu HealthLake können, müssen Sie Folgendes tun:
+ Sie müssen den ARN der Lambda-Funktion, die Sie in der Anfrage aufrufen HealthLake möchten, `IdpLambdaArn` gleich setzen. `CreateFHIRDatastore`
+ Sie benötigen eine ressourcenbasierte Richtlinie, die es Ihnen ermöglicht HealthLake , die Lambda-Funktion in Ihrem Namen aufzurufen.
Wenn es eine FHIR-REST-API-Anfrage auf einem SMART on FHIR-fähigen Datenspeicher HealthLake empfängt, benötigt es Berechtigungen, um die Lambda-Funktion aufzurufen, die bei der Erstellung des Datenspeichers in Ihrem Namen angegeben wurde. Um HealthLake Zugriff zu gewähren, verwenden Sie eine ressourcenbasierte Richtlinie. *Weitere Informationen zum Erstellen einer ressourcenbasierten Richtlinie für eine Lambda-Funktion finden Sie unter [Zulassen, dass ein AWS Dienst eine Lambda-Funktion aufruft](https://docs.aws.amazon.com/lambda/latest/dg/access-control-resource-based.html#permissions-resource-serviceinvoke) im Entwicklerhandbuch.AWS Lambda *
## Bereitstellung von Parallelität für Ihre Lambda-Funktion
**Wichtig**
HealthLake erfordert, dass die maximale Laufzeit für Ihre Lambda-Funktion weniger als eine Sekunde (1000 Millisekunden) beträgt.
Wenn Ihre Lambda-Funktion das Laufzeitlimit überschreitet, erhalten Sie eine TimeOutAusnahme.
Um zu vermeiden, dass diese Ausnahme auftritt, empfehlen wir, die bereitgestellte Parallelität zu konfigurieren. Wenn Sie Provisioned Concurrency (Bereitgestellte Gleichzeitigkeit) vor einer Erhöhung der Aufrufe zuweisen, können Sie sicherstellen, dass alle Anforderungen von initialisierten Instances mit geringer Latenz verarbeitet werden. *Weitere Informationen zur Konfiguration der bereitgestellten Parallelität finden Sie unter [Konfiguration der bereitgestellten Parallelität](https://docs.aws.amazon.com/ambda/latest/dg/provisioned-concurrency.html) im Lambda Developer Guide*
Um die durchschnittliche Laufzeit Ihrer Lambda-Funktion derzeit zu sehen, verwenden Sie die **Monitoring-Seite** für Ihre Lambda-Funktion in der Lambda-Konsole. Standardmäßig bietet die Lambda-Konsole ein **Dauer-Diagramm**, das Ihnen die durchschnittliche, minimale und maximale Zeit anzeigt, die Ihr Funktionscode mit der Verarbeitung eines Ereignisses verbringt. Weitere Informationen zur Überwachung von Lambda-Funktionen finden Sie unter [Überwachungsfunktionen in der Lambda-Konsole im *Lambda*](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-functions-access-metrics.html#monitoring-console-graph-types) Developer Guide.
*Wenn Sie bereits Parallelität für Ihre Lambda-Funktion bereitgestellt haben und diese überwachen möchten, finden Sie weitere Informationen unter [Überwachung der Parallelität](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-concurrency.html) im Lambda Developer Guide.*
# Verwendung detaillierter Autorisierung mit einem SMART on FHIR-fähigen Datenspeicher HealthLake
[Geltungsbereiche](reference-smart-on-fhir-oauth-scopes.md#smart-on-fhir-scopes-rest) allein bieten Ihnen nicht die nötige Genauigkeit darüber, auf welche Daten ein Anforderer in einem Datenspeicher zugreifen darf. Die Verwendung einer differenzierten Autorisierung ermöglicht ein höheres Maß an Spezifität bei der Gewährung des Zugriffs auf einen SMART-on-FHIR-fähigen Datenspeicher. HealthLake Um eine differenzierte Autorisierung zu verwenden, legen Sie `True` im Parameter Ihrer Anfrage den `FineGrainedAuthorizationEnabled` Wert „gleich“ fest. `IdentityProviderConfiguration` `CreateFHIRDatastore`
Wenn Sie die differenzierte Autorisierung aktiviert haben, gibt Ihr Autorisierungsserver `id_token` zusammen mit dem Zugriffstoken einen `fhirUser` Bereich zurück. Dadurch können Informationen über den Benutzer von der Client-Anwendung abgerufen werden. Die Client-Anwendung sollte den `fhirUser` Anspruch als URI einer FHIR-Ressource behandeln, die den aktuellen Benutzer repräsentiert. Mögliche Werte sind `Patient`, `Practitioner` oder `RelatedPerson`. Die Antwort des Autorisierungsservers beinhaltet auch einen `user/` Bereich, der definiert, auf welche Daten der Benutzer zugreifen kann. Dabei wird die Syntax verwendet, die für Bereiche definiert ist, die sich auf FHIR-ressourcenspezifische Bereiche beziehen:
```
user/(fhir-resource | '*').('read' | 'write' | '*')
```
Im Folgenden finden Sie Beispiele dafür, wie eine differenzierte Autorisierung verwendet werden kann, um FHIR-Ressourcentypen im Zusammenhang mit dem Datenzugriff weiter zu spezifizieren.
+ Wann bestimmt `fhirUser` eine differenzierte Autorisierung`Practitioner`, auf welche Patientengruppe der Benutzer zugreifen kann. Der Zugang `fhirUser` ist nur für Patienten erlaubt, auf die sich der Patient `fhirUser` als Allgemeinmediziner bezieht.
```
Patient.generalPractitioner : [{Reference(Practitioner)}]
```
+ Wann `fhirUser` ist ein `Patient` oder `RelatedPerson` und der Patient, auf den in der Anfrage verwiesen wird, unterscheidet sich von der Autorisierung`fhirUser`, zu der der angefragte Patient Zugang `fhirUser` hat. Der Zugriff ist zulässig, wenn in der angeforderten `Patient` Ressource eine Beziehung angegeben ist.
```
Patient.link.other : {Reference(Patient|RelatedPerson)}
```
# Das SMART on FHIR Discovery-Dokument wird abgerufen
SMART definiert ein Discovery-Dokument, das es Kunden ermöglicht, den Autorisierungsendpunkt zu ermitteln, URLs und bietet Funktionen, die ein HealthLake Datenspeicher unterstützt. Diese Informationen helfen Kunden dabei, Autorisierungsanfragen an den richtigen Endpunkt weiterzuleiten und Autorisierungsanfragen zu erstellen, die der HealthLake Datenspeicher unterstützt.
Damit eine Client-Anwendung erfolgreich eine FHIR-REST-Anfrage stellen kann HealthLake, muss sie die vom HealthLake Datenspeicher definierten Autorisierungsanforderungen erfassen. Ein Bearer-Token (Autorisierung) ist *nicht* erforderlich, damit diese Anfrage erfolgreich ist.
**Um das Discovery-Dokument für einen HealthLake Datenspeicher anzufordern**
1. Sammeln HealthLake `region` und `datastoreId` Werte. Weitere Informationen finden Sie unter [Eigenschaften des Datenspeichers abrufen](managing-data-stores-describe.md).
1. Konstruieren Sie mithilfe der gesammelten Werte für HealthLake `region` und eine URL für die Anfrage`datastoreId`. An `/.well-known/smart-configuration` den Endpunkt der URL anhängen. Scrollen Sie über die Schaltfläche **Kopieren**, um den gesamten URL-Pfad im folgenden Beispiel anzuzeigen.
```
https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/.well-known/smart-configuration
```
1. Senden Sie die Anfrage mithilfe des [AWS Signaturprotokolls `GET` mit Signature Version 4.](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) Scrollen Sie über die Schaltfläche **Kopieren**, um das gesamte Beispiel anzuzeigen.
------
#### [ curl ]
```
curl --request GET \
'https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/.well-known/smart-configuration \
--aws-sigv4 'aws:amz:region:healthlake' \
--user "$AWS_ACCESS_KEY_ID:$AWS_SECRET_ACCESS_KEY" \
--header "x-amz-security-token:$AWS_SESSION_TOKEN" \
--header 'Accept: application/json'
```
------
Das Discovery-Dokument für den HealthLake Datenspeicher wird als JSON-Blob zurückgegeben, in dem Sie das `authorization_endpoint` und das `token_endpoint` sowie die Spezifikationen und definierten Funktionen für den Datenspeicher finden.
```
{
"authorization_endpoint": "https://oidc.example.com/authorize",
"token_endpoint": "https://oidc.example.com/oauth/token",
"capabilities": [
"launch-ehr",
"client-public"
]
}
```
`authorization_endpoint`Sowohl das als auch das `token_endpoint` sind erforderlich, um eine Client-Anwendung zu starten.
+ **Autorisierungsendpunkt** — Die URL, die zur Autorisierung einer Client-Anwendung oder eines Benutzers benötigt wird.
+ **Token-Endpunkt** — Der Endpunkt des Autorisierungsservers, mit dem die Client-Anwendung kommuniziert.
# Eine FHIR-REST-API-Anfrage für einen HealthLake SMART-fähigen Datenspeicher stellen
Sie können FHIR-REST-API-Anfragen in einem HealthLake SMART-on-FHIR-fähigen Datenspeicher stellen. Das folgende Beispiel zeigt eine Anfrage von einer Client-Anwendung, die ein JWT im Autorisierungsheader enthält, und wie Lambda die Antwort dekodieren sollte. Nachdem die Anforderung der Client-Anwendung autorisiert und authentifiziert wurde, muss sie ein Bearer-Token vom Autorisierungsserver erhalten. Verwenden Sie das Bearer-Token im Autorisierungsheader, wenn Sie eine FHIR-REST-API-Anforderung an einen SMART-on-FHIR-fähigen Datenspeicher senden. HealthLake
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient/[ID]
Authorization: Bearer auth-server-provided-bearer-token
```
Da im Autorisierungsheader ein Bearer-Token gefunden wurde und keine AWS IAM-Identität erkannt wurde, wird die Lambda-Funktion HealthLake aufgerufen, die bei der Erstellung des SMART on FHIR-fähigen HealthLake Datenspeichers angegeben wurde. Wenn das Token erfolgreich von Ihrer Lambda-Funktion dekodiert wurde, wird die folgende Beispielantwort an gesendet. HealthLake
```
{
"authPayload": {
"iss": "https://authorization-server-endpoint/oauth2/token", # The issuer identifier of the authorization server
"aud": "https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/", # Required, data store endpoint
"iat": 1677115637, # Identifies the time at which the token was issued
"nbf": 1677115637, # Required, the earliest time the JWT would be valid
"exp": 1997877061, # Required, the time at which the JWT is no longer valid
"isAuthorized": "true", # Required, boolean indicating the request has been authorized
"uid": "100101", # Unique identifier returned by the auth server
"scope": "system/*.*" # Required, the scope of the request
},
"iamRoleARN": "iam-role-arn" #Required, IAM role to complete the request
}
```