Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# SMART sur le support FHIR pour AWS HealthLake
Un magasin de HealthLake données compatible avec les applications médicales substituables et les technologies réutilisables (SMART) sur FHIR permet d'accéder aux applications compatibles SMART sur FHIR. HealthLake les données sont accessibles en authentifiant et en autorisant les demandes à l'aide d'un serveur d'autorisation tiers. Ainsi, au lieu de gérer les informations d'identification des utilisateurs via Gestion des identités et des accès AWS, vous le faites à l'aide d'un serveur d'autorisation compatible SMART on FHIR.
**Note**
HealthLake supporte SMART sur les versions 1.0 et 2.0 de FHIR. Pour en savoir plus sur ces frameworks, consultez [SMART App Launch](https://www.hl7.org/fhir/smart-app-launch/) dans la documentation *FHIR R4*.
HealthLake les magasins de données prennent en charge les cadres d'authentification et d'autorisation suivants pour les demandes SMART on FHIR :
**OpenID (AuthN)** : pour authentifier la personne ou l'application cliente, c'est la personne (ou ce que) elle prétend être.
**OAuth 2.0 (AuthZ)** : pour autoriser les ressources FHIR de votre magasin de HealthLake données sur lesquelles une demande authentifiée peut lire ou écrire. Ceci est défini par les étendues configurées sur votre serveur d'autorisation.
Vous pouvez créer un magasin de données compatible SMART sur FHIR à l'aide du AWS CLI ou AWS SDKs. Pour de plus amples informations, veuillez consulter [Création d'un magasin HealthLake de données](managing-data-stores-create.md).
**Topics**
+ [Commencer à utiliser SMART sur FHIR](reference-smart-on-fhir-getting-started.md)
+ [HealthLake exigences d'authentification pour SMART sur FHIR](reference-smart-on-fhir-authentication.md)
+ [SMART sur les oscilloscopes FHIR OAuth 2.0 pris en charge par HealthLake](reference-smart-on-fhir-oauth-scopes.md)
+ [Validation des jetons en utilisant AWS Lambda](reference-smart-on-fhir-token-validation.md)
+ [Utilisation d'une autorisation précise avec un magasin de données compatible SMART on FHIR HealthLake](reference-smart-on-fhir-fine-grained-authorization.md)
+ [Récupération du document SMART sur FHIR Discovery](reference-smart-on-fhir-discovery-document.md)
+ [Effectuer une demande d'API REST FHIR sur un magasin de données compatible SMART HealthLake](reference-smart-on-fhir-request-example.md)
# Commencer à utiliser SMART sur FHIR
Les rubriques suivantes décrivent comment démarrer avec SMART sur l'autorisation FHIR pour AWS HealthLake. Ils incluent les ressources que vous devez fournir sur votre AWS compte, la création d'un magasin de HealthLake données compatible SMART on FHIR et un exemple de la façon dont une application client SMART on FHIR interagit avec un serveur d'autorisation et un HealthLake magasin de données.
**Topics**
+ [Configuration des ressources pour SMART sur FHIR](#smart-on-fhir-resources)
+ [Flux de travail des applications clientes pour SMART sur FHIR](#smart-on-fhir-client-app-workflow)
## Configuration des ressources pour SMART sur FHIR
Les étapes suivantes définissent la manière dont les demandes SMART on FHIR sont traitées HealthLake et les ressources nécessaires pour qu'elles aboutissent. Les éléments suivants fonctionnent ensemble dans un flux de travail pour effectuer une demande SMART on FHIR :
+ **L'utilisateur final** : en général, un patient ou un clinicien utilisant une application SMART on FHIR tierce pour accéder aux données d'un HealthLake magasin de données.
+ **L'application SMART on FHIR (appelée application client) : application** qui souhaite accéder aux données présentes dans le magasin de HealthLake données.
+ **Le serveur d'autorisation** : un serveur compatible OpenID Connect capable d'authentifier les utilisateurs et d'émettre des jetons d'accès.
+ **Le magasin de HealthLake données** : un magasin de HealthLake données compatible SMART on FHIR qui utilise une fonction Lambda pour répondre aux requêtes REST FHIR qui fournissent un jeton porteur.
Pour que ces éléments fonctionnent ensemble, vous devez créer les ressources suivantes.
**Note**
Nous vous recommandons de créer votre banque de HealthLake données compatible SMART on FHIR après avoir configuré le serveur d'autorisation, défini les [étendues](reference-smart-on-fhir-oauth-scopes.md) nécessaires et créé une AWS Lambda fonction pour gérer l'introspection des [jetons](reference-smart-on-fhir-token-validation.md).
**1. Configuration d'un point de terminaison de serveur d'autorisation**
Pour utiliser le framework SMART on FHIR, vous devez configurer un serveur d'autorisation tiers capable de valider les requêtes REST FHIR effectuées sur un magasin de données. Pour de plus amples informations, veuillez consulter [HealthLake exigences d'authentification pour SMART sur FHIR](reference-smart-on-fhir-authentication.md).
**2. Définissez des étendues sur votre serveur d'autorisation pour contrôler les niveaux d'accès au magasin de HealthLake données**
Le framework SMART on FHIR utilise des OAuth portées pour déterminer à quelles ressources FHIR une demande authentifiée a accès et dans quelle mesure. La définition des étendues est un moyen de concevoir avec le moindre privilège. Pour de plus amples informations, veuillez consulter [SMART sur les oscilloscopes FHIR OAuth 2.0 pris en charge par HealthLake](reference-smart-on-fhir-oauth-scopes.md).
**3. Configurer une AWS Lambda fonction capable d'effectuer une introspection symbolique**
Une demande REST FHIR envoyée par l'application cliente sur un magasin de données compatible SMART on FHIR contient un jeton Web JSON (JWT). Pour plus d'informations, consultez la section [Décodage d'un JWT](reference-smart-on-fhir-token-validation.md).
**4. Créez un magasin de HealthLake données compatible SMART on FHIR**
Pour créer un magasin de HealthLake données SMART sur FHIR, vous devez fournir un`IdentityProviderConfiguration`. Pour de plus amples informations, veuillez consulter [Création d'un magasin HealthLake de données](managing-data-stores-create.md).
## Flux de travail des applications clientes pour SMART sur FHIR
La section suivante explique comment lancer une application cliente et effectuer une requête REST FHIR réussie sur un magasin de HealthLake données dans le contexte de SMART on FHIR.
**1. Faire une `GET` demande à Known Uniform Resource Identifier à l'aide de l'application cliente**
Une application cliente compatible SMART doit effectuer une `GET` demande pour trouver les points de terminaison d'autorisation de votre magasin de HealthLake données. Cela se fait via une demande d'identifiant de ressource uniforme (URI) bien connu. Pour de plus amples informations, veuillez consulter [Récupération du document SMART sur FHIR Discovery](reference-smart-on-fhir-discovery-document.md).
**2. Demande d'accès et champs d'application**
L'application cliente utilise le point de terminaison d'autorisation du serveur d'autorisation afin que l'utilisateur puisse se connecter. Ce processus authentifie l'utilisateur. Les étendues sont utilisées pour définir les ressources FHIR de votre magasin de HealthLake données auxquelles une application cliente peut accéder. Pour de plus amples informations, veuillez consulter [SMART sur les oscilloscopes FHIR OAuth 2.0 pris en charge par HealthLake](reference-smart-on-fhir-oauth-scopes.md).
**3. Jetons d'accès**
Maintenant que l'utilisateur est authentifié, une application cliente reçoit un jeton d'accès JWT du serveur d'autorisation. Ce jeton est fourni lorsque l'application cliente envoie une demande FHIR REST à HealthLake. Pour de plus amples informations, veuillez consulter [Validation des jetons](reference-smart-on-fhir-token-validation.md).
**4. Effectuer une demande d'API REST FHIR sur SMART sur un magasin de données activé HealthLake par FHIR**
L'application cliente peut désormais envoyer une demande d'API REST FHIR à un point de terminaison du magasin de HealthLake données à l'aide du jeton d'accès fourni par le serveur d'autorisation. Pour de plus amples informations, veuillez consulter [Effectuer une demande d'API REST FHIR sur un magasin de données compatible SMART HealthLake](reference-smart-on-fhir-request-example.md).
**5. Validez le jeton d'accès JWT**
Pour valider le jeton d'accès envoyé dans la requête REST FHIR, utilisez une fonction Lambda. Pour de plus amples informations, veuillez consulter [Validation des jetons en utilisant AWS Lambda](reference-smart-on-fhir-token-validation.md).
# HealthLake exigences d'authentification pour SMART sur FHIR
Pour accéder aux ressources FHIR dans un magasin de HealthLake données compatible SMART sur FHIR, une application cliente doit être autorisée par un serveur d'autorisation OAuth compatible 2.0 et présenter un jeton OAuth Bearer dans le cadre d'une demande d'API REST FHIR. Pour trouver le point de terminaison du serveur d'autorisation, utilisez le document HealthLake SMART on FHIR Discovery via un identifiant de ressource `Well-Known` uniforme. Pour en savoir plus sur ce processus, consultez [Récupération du document SMART sur FHIR Discovery](reference-smart-on-fhir-discovery-document.md).
Lorsque vous créez un magasin de HealthLake données SMART on FHIR, vous devez définir le point de terminaison du serveur d'autorisation et le point de terminaison du jeton dans l'`metadata`élément de la `CreateFHIRDatastore` demande. Pour en savoir plus sur la définition de l'`metadata`élément, voir[Création d'un magasin HealthLake de données](managing-data-stores-create.md).
À l'aide des points de terminaison du serveur d'autorisation, l'application cliente authentifie un utilisateur auprès du service d'autorisation. Une fois autorisé et authentifié, un jeton Web JSON (JWT) est généré par le service d'autorisation et transmis à l'application cliente. Ce jeton contient des étendues de ressources FHIR que l'application cliente est autorisée à utiliser, ce qui limite les données auxquelles l'utilisateur peut accéder. Facultativement, si le périmètre de lancement a été fourni, la réponse contiendra ces détails. Pour en savoir plus sur les oscilloscopes SMART on FHIR pris en charge par HealthLake, voir. [SMART sur les oscilloscopes FHIR OAuth 2.0 pris en charge par HealthLake](reference-smart-on-fhir-oauth-scopes.md)
À l'aide du JWT accordé par le serveur d'autorisation, une application cliente effectue des appels d'API REST FHIR à un magasin de données compatible HealthLake SMART sur FHIR. Pour valider et décoder le JWT, vous devez créer une fonction Lambda. HealthLake invoque cette fonction Lambda en votre nom lorsqu'une demande d'API REST FHIR est reçue. Pour voir un exemple de fonction Lambda de démarrage, reportez-vous à. [Validation des jetons en utilisant AWS Lambda](reference-smart-on-fhir-token-validation.md)
## Éléments du serveur d'autorisation requis pour créer un magasin de HealthLake données compatible SMART on FHIR
Dans la `CreateFHIRDatastore` demande, vous devez fournir le point de terminaison d'autorisation et le point de terminaison du jeton dans le cadre de l'`metadata`élément de l'`IdentityProviderConfiguration`objet. Le point de terminaison d'autorisation et le point de terminaison jeton sont tous deux requis. Pour voir un exemple de la manière dont cela est spécifié dans la `CreateFHIRDatastore` demande, voir[Création d'un magasin HealthLake de données](managing-data-stores-create.md).
## Réclamations requises pour compléter une demande d'API REST FHIR sur un magasin de données compatible HealthLake SMART on FHIR
Votre AWS Lambda fonction doit contenir les affirmations suivantes pour qu'il s'agisse d'une demande d'API REST FHIR valide sur un magasin de HealthLake données compatible SMART on FHIR.
+ `nbf`: [(Pas avant) Réclamation — La réclamation](https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.5) « nbf » (pas avant) indique le délai avant lequel le JWT NE DOIT PAS être accepté pour traitement. Le traitement de la réclamation « nbf » nécessite que le courant date/time DOIT être supérieur ou égal à celui date/time indiqué dans la réclamation « nbf ». L'exemple de fonction Lambda que nous fournissons convertit la réponse `iat` du serveur en. `nbf`
+ `exp`: [(Date d'expiration) Réclamation](https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.4) — La demande « exp » (délai d'expiration) identifie le délai d'expiration à partir duquel ou après lequel le JWT ne doit pas être accepté pour traitement.
+ `isAuthorized`: un booléen défini sur. `True` Indique que la demande a été autorisée sur le serveur d'autorisation.
+ `aud`: Réclamation [(audience) — La réclamation](https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.3) « aud » (audience) identifie les destinataires auxquels le JWT est destiné. Il doit s'agir d'un point de terminaison de banque de HealthLake données compatible SMART on FHIR.
+ `scope`: Il doit s'agir d'au moins une étendue liée à une ressource FHIR. Cette étendue est définie sur votre serveur d'autorisation. Pour en savoir plus sur les champs d'application liés aux ressources FHIR acceptés par HealthLake, voir. [SMART sur les champs de ressources FHIR pour HealthLake](reference-smart-on-fhir-oauth-scopes.md#smart-on-fhir-scopes-rest)
# SMART sur les oscilloscopes FHIR OAuth 2.0 pris en charge par HealthLake
HealthLake utilise le OAuth 2.0 comme protocole d'autorisation. L'utilisation de ce protocole sur votre serveur d'autorisation vous permet de définir HealthLake des autorisations de stockage de données (création, lecture, mise à jour, suppression et recherche) pour les ressources FHIR auxquelles une application cliente a accès.
Le framework SMART on FHIR définit un ensemble de champs d'application qui peuvent être demandés au serveur d'autorisation. Par exemple, une application client conçue uniquement pour permettre aux patients de consulter leurs résultats de laboratoire ou de consulter leurs coordonnées ne doit être *autorisée* qu'à demander `read` des scopes.
**Note**
HealthLake fournit un support pour SMART sur FHIR V1 et V2, comme décrit ci-dessous. Le SMART on 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)est défini sur l'une des trois valeurs suivantes lors de la création de votre magasin de données :
`SMART_ON_FHIR_V1`— Support uniquement pour SMART sur FHIR V1, qui inclut les autorisations `read` (lecture/recherche) et `write` (create/update/delete).
`SMART_ON_FHIR`— Support de SMART sur FHIR V1 et V2, qui inclut`create`,`read`, `update``delete`, et `search` les autorisations.
`AWS_AUTH`— La stratégie AWS HealthLake d'autorisation par défaut ; non affiliée à SMART on FHIR.
## Périmètre de lancement autonome
HealthLake prend en charge le champ `launch/patient` d'application du mode de lancement autonome.
En mode de lancement autonome, une application client demande l'accès aux données cliniques du patient car l'utilisateur et le patient ne sont pas connus de l'application cliente. Ainsi, la demande d'autorisation de l'application cliente demande explicitement que le dossier du patient soit renvoyé. Une fois l'authentification réussie, le serveur d'autorisation émet un jeton d'accès contenant le champ d'application du patient de lancement demandé. Le contexte patient nécessaire est fourni avec le jeton d'accès dans la réponse du serveur d'autorisation.
**Champs d'application du mode de lancement pris en charge**
| Scope | Description |
| --- | --- |
| `launch/patient` | Paramètre d'une demande d'autorisation OAuth 2.0 demandant que les données du patient soient renvoyées dans la réponse d'autorisation. |
## SMART sur les champs de ressources FHIR pour HealthLake
HealthLake définit trois niveaux de SMART sur les étendues de ressources FHIR.
+ `patient`les scopes donnent accès à des données spécifiques concernant un seul patient.
+ `user`les étendues donnent accès à des données spécifiques auxquelles un utilisateur peut accéder.
+ `system`les étendues donnent accès à toutes les ressources FHIR présentes dans le magasin de HealthLake données.
Les sections suivantes répertorient la syntaxe permettant de créer des étendues de ressources FHIR à l'aide de SMART sur FHIR V1 ou SMART sur FHIR V2.
**Note**
La stratégie d'autorisation SMART on FHIR est définie lors de la création de votre magasin de données. Pour plus d’informations, consultez [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) dans la *Référence d’API AWS HealthLake *.
### SMART sur les oscilloscopes FHIR V1 pris en charge par HealthLake
Lorsque vous utilisez SMART sur FHIR V1, la syntaxe générale pour la construction des étendues de ressources FHIR est la suivante. HealthLake Pour afficher le chemin complet de l'URL dans l'exemple suivant, faites défiler le curseur sur le bouton **Copier**.
```
('patient' | 'user' | 'system') '/' (fhir-resource | '*') '.' ('read' | 'write' | '*')
```
**Champs d'autorisation pris en charge par SMART on FHIR v1**
| Syntaxe Scope | Exemple de champ d'application | Résultat |
| --- | --- | --- |
| `patient/(fhir-resource \| '*').('read' \| 'write' \| '*')` | patient/AllergyIntolerance.\$1 | L'application client du patient dispose d'un accès en lecture/écriture au niveau de l'instance à toutes les allergies enregistrées. |
| `user/(fhir-resource \| '*').('read' \| 'write' \| '*')` | user/Observation.read | L'application cliente utilisateur dispose d'un read/write accès au niveau de l'instance à toutes les observations enregistrées. |
| system/('read' \$1 'write' \$1 \$1) | system/\$1.\$1 | L'application cliente du système a read/write accès à toutes les données des ressources FHIR. |
### SMART sur les oscilloscopes FHIR V2 pris en charge par HealthLake
Lorsque vous utilisez SMART sur FHIR V2, la syntaxe générale pour la construction des étendues de ressources FHIR est la suivante. HealthLake Pour afficher le chemin complet de l'URL dans l'exemple suivant, faites défiler le curseur sur le bouton **Copier**.
```
('patient' | 'user' | 'system') '/' (fhir-resource | '*') '.' ('c' | 'r' | 'u' | 'd' | 's')
```
**Note**
Pour utiliser SMART sur FHIR V2, vous devez transmettre la valeur [https://hl7.org/fhir/smart-app-launch/STU2/conformance.html#permissions](https://hl7.org/fhir/smart-app-launch/STU2/conformance.html#permissions)dans la `capabilities` chaîne de métadonnées, qui est membre du type de [https://docs.aws.amazon.com/healthlake/latest/APIReference/API_IdentityProviderConfiguration.html](https://docs.aws.amazon.com/healthlake/latest/APIReference/API_IdentityProviderConfiguration.html)données.
HealthLake prend en charge les oscilloscopes granulaires. Pour plus d'informations, voir les [étendues granulaires prises en charge](https://hl7.org/fhir/us/core/scopes.html#the-following-granular-scopes-shall-be-supported) dans le guide de mise en œuvre de *FHIR US Core*.
**Étendue d'autorisation compatible avec SMART on FHIR V2**
| Syntaxe Scope | Exemple de scope V1 | Résultat |
| --- | --- | --- |
| `patient/Observation.rs` | user/Observation.read | Autorisation de lire et de rechercher Observation une ressource pour le patient actuel. |
| `system/*.cruds` | system/\$1.\$1 | L'application cliente du système dispose d'un create/read/update/delete/search accès complet à toutes les données de ressources FHIR. |
# Validation des jetons en utilisant AWS Lambda
Lorsque vous créez un magasin de données compatible HealthLake SMART sur FHIR, vous devez fournir l'ARN de la AWS Lambda fonction dans la `CreateFHIRDatastore` demande. L'ARN de la fonction Lambda est spécifié dans l'`IdentityProviderConfiguration`objet à l'aide du `IdpLambdaArn` paramètre.
Vous devez créer la fonction Lambda avant de créer votre magasin de données compatible SMART on FHIR. Une fois que vous avez créé le magasin de données, l'ARN Lambda ne peut pas être modifié. Pour voir l'ARN Lambda que vous avez spécifié lors de la création du magasin de données, utilisez l'action `DescribeFHIRDatastore` API.
**Pour qu'une demande REST FHIR aboutisse sur un magasin de données compatible SMART on FHIR, votre fonction Lambda doit effectuer les opérations suivantes :**
+ Renvoie une réponse en moins d'une seconde au point de terminaison du magasin de HealthLake données.
+ Décodez le jeton d'accès fourni dans l'en-tête d'autorisation de la demande d'API REST envoyée par l'application cliente.
+ Attribuez un rôle de service IAM doté d'autorisations suffisantes pour exécuter la demande d'API REST FHIR.
+ Les demandes suivantes sont requises pour compléter une demande d'API REST FHIR. Pour en savoir plus, veuillez consulter la section [Demandes requises](reference-smart-on-fhir-authentication.md#server-response).
+ `nbf`
+ `exp`
+ `isAuthorized`
+ `aud`
+ `scope`
Lorsque vous travaillez avec Lambda, vous devez créer un rôle d'exécution et une politique basée sur les ressources en plus de votre fonction Lambda. Le rôle d'exécution d'une fonction Lambda est un rôle IAM qui accorde à la fonction l'autorisation d'accéder aux services et aux ressources AWS nécessaires au moment de l'exécution. La politique basée sur les ressources que vous fournissez doit HealthLake permettre d'invoquer votre fonction en votre nom.
Les sections de cette rubrique décrivent un exemple de demande provenant d'une application cliente et une réponse décodée, les étapes nécessaires à la création d'une fonction AWS Lambda et la manière de créer une politique basée sur les ressources qui peut être assumée. HealthLake
+ [Partie 1 : Création d'une fonction Lambda](#smart-on-fhir-lambda-create)
+ [Partie 2 : Création d'un rôle HealthLake de service utilisé par la fonction AWS Lambda](#smart-on-fhir-lambda-service-role)
+ [Partie 3 : Mise à jour du rôle d'exécution de la fonction Lambda](#smart-on-fhir-lambda-service-role-execution-role)
+ [Partie 4 : Ajouter une politique de ressources à votre fonction Lambda](#smart-on-fhir-lambda-invoke-healthlake)
+ [Partie 5 : Configuration de la simultanéité pour votre fonction Lambda](#smart-on-fhir-lambda-function-scaling)
## Création d'une fonction AWS Lambda
La fonction Lambda créée dans cette rubrique est déclenchée lors de la HealthLake réception d'une demande à un magasin de données compatible SMART on FHIR. La demande de l'application cliente contient un appel d'API REST et un en-tête d'autorisation contenant un jeton d'accès.
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/
Authorization: Bearer i8hweunweunweofiwweoijewiwe
```
L'exemple de fonction Lambda présenté dans cette rubrique permet de masquer AWS Secrets Manager les informations d'identification liées au serveur d'autorisation. Nous vous recommandons vivement de ne pas fournir les informations de connexion au serveur d'autorisation directement dans une fonction Lambda.
**Example validation d'une requête REST FHIR contenant un jeton porteur d'autorisation**
L'exemple de fonction Lambda vous montre comment valider une demande REST FHIR envoyée à un magasin de données compatible SMART on FHIR. Pour savoir step-by-steps comment implémenter cette fonction Lambda, consultez. [Création d'une fonction Lambda à l'aide du AWS Management Console](#create-lambda-console)
Si la demande d'API REST FHIR ne contient pas de point de terminaison de stockage de données, de jeton d'accès et d'opération REST valides, la fonction Lambda échouera. Pour en savoir plus sur les éléments du serveur d'autorisation requis, consultez[Demandes requises](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()
```
### Création d'une fonction Lambda à l'aide du AWS Management Console
La procédure suivante suppose que vous avez déjà créé le rôle de service que vous HealthLake souhaitez assumer lors du traitement d'une demande d'API REST FHIR sur un magasin de données compatible SMART sur FHIR. Si vous n'avez pas créé le rôle de service, vous pouvez toujours créer la fonction Lambda. Vous devez ajouter l'ARN du rôle de service pour que la fonction Lambda fonctionne. Pour en savoir plus sur la création d'un rôle de service et sa spécification dans la fonction Lambda, voir [Création d'un rôle HealthLake de service à utiliser dans la fonction AWS Lambda utilisée pour décoder un JWT](#smart-on-fhir-lambda-service-role)
**Pour créer une fonction Lambda ()AWS Management Console**
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home/functions) (Fonctions) de la console Lambda.
1. Choisissez **Créer une fonction**.
1. Sélectionnez **Créer à partir de zéro**.
1. Dans **Informations de base**, entrez le **nom de la fonction**. Sous **Runtime**, choisissez un environnement d'exécution basé sur Python.
1. Pour **Execution role** (Rôle d'exécution), choisissez **Create a new role with basic Lambda permissions** (Créer un nouveau rôle avec les autorisations Lambda de base).
Lambda crée un [rôle d'exécution](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html) qui accorde à la fonction l'autorisation de télécharger des journaux sur Amazon. CloudWatch La fonction Lambda assume le rôle d'exécution lorsque vous appelez votre fonction et utilise le rôle d'exécution pour créer des informations d'identification pour le AWS SDK.
1. Choisissez l'onglet **Code** et ajoutez l'exemple de fonction Lambda.
Si vous n'avez pas encore créé le rôle de service que la fonction Lambda doit utiliser, vous devez le créer pour que l'exemple de fonction Lambda fonctionne. Pour en savoir plus sur la création d'un rôle de service pour la fonction Lambda, consultez. [Création d'un rôle HealthLake de service à utiliser dans la fonction AWS Lambda utilisée pour décoder un JWT](#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()
```
### Modifier le rôle d'exécution d'une fonction Lambda
Après avoir créé la fonction Lambda, vous devez mettre à jour le rôle d'exécution afin d'inclure les autorisations nécessaires pour appeler Secrets Manager. Dans Secrets Manager, chaque secret que vous créez possède un ARN. Pour appliquer le moindre privilège, le rôle d'exécution ne doit avoir accès qu'aux ressources nécessaires à l'exécution de la fonction Lambda.
Vous pouvez modifier le rôle d'exécution d'une fonction Lambda en la recherchant dans la console IAM ou en choisissant **Configuration** dans la console Lambda. Pour en savoir plus sur la gestion de votre rôle d'exécution des fonctions Lambda, consultez. [Rôle d’exécution Lambda](#smart-on-fhir-lambda-service-role-execution-role)
**Example Rôle d'exécution de la fonction Lambda qui donne accès à `GetSecretValue`**
L'ajout de l'action IAM `GetSecretValue` au rôle d'exécution accorde l'autorisation nécessaire au fonctionnement de l'exemple de fonction Lambda.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "secretsmanager:GetSecretValue",
"Resource": "arn:aws:secretsmanager:us-east-1:123456789012:secret:secret-name-DKodTA"
}
]
}
```
À ce stade, vous avez créé une fonction Lambda qui peut être utilisée pour valider le jeton d'accès fourni dans le cadre de la demande REST FHIR envoyée à votre banque de données compatible SMART on FHIR.
## Création d'un rôle HealthLake de service à utiliser dans la fonction AWS Lambda utilisée pour décoder un JWT
**Persona : administrateur IAM**
Utilisateur qui peut ajouter ou supprimer des politiques IAM et créer de nouvelles identités IAM.
**Rôle de service **
Un rôle de service est un [rôle IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) qu’un service endosse pour accomplir des actions en votre nom. Un administrateur IAM peut créer, modifier et supprimer un rôle de service à partir d’IAM. Pour plus d’informations, consultez [Création d’un rôle pour la délégation d’autorisations à un Service AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) dans le *Guide de l’utilisateur IAM*.
Une fois le jeton Web JSON (JWT) décodé, l'autorisation dont Lambda a besoin doit également renvoyer un ARN de rôle IAM. Ce rôle doit disposer des autorisations nécessaires pour exécuter la demande d'API REST, sinon il échouera en raison d'autorisations insuffisantes.
Lorsque vous configurez une politique personnalisée à l'aide d'IAM, il est préférable d'accorder les autorisations minimales requises. Pour en savoir plus, consultez la section [Appliquer les autorisations de moindre privilège](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) dans le Guide de l'utilisateur *IAM*.
La création d'un rôle de HealthLake service à désigner dans la fonction Lambda d'autorisation nécessite deux étapes.
+ Tout d'abord, vous devez créer une politique IAM. La politique doit spécifier l'accès aux ressources FHIR pour lesquelles vous avez fourni des étendues sur le serveur d'autorisation.
+ Ensuite, vous devez créer le rôle de service. Lorsque vous créez le rôle, vous désignez une relation de confiance et vous y associez la politique que vous avez créée à la première étape. La relation de confiance désigne HealthLake le principal du service. Vous devez spécifier un ARN de stockage de HealthLake données et un ID de AWS compte au cours de cette étape.
### Création d'une nouvelle politique IAM
Les étendues que vous définissez dans votre serveur d'autorisation déterminent les ressources FHIR auxquelles un utilisateur authentifié a accès dans un HealthLake magasin de données.
La politique IAM que vous créez peut être adaptée aux étendues que vous avez définies.
Les actions suivantes peuvent être définies dans l'`Action`élément d'une déclaration de politique IAM. Pour chacun `Action` des éléments du tableau, vous pouvez définir un`Resource types`. Dans HealthLake un magasin de données, le seul type de ressource pris en charge peut être défini dans l'`Resource`élément d'une déclaration de politique d'autorisation IAM.
Les ressources FHIR individuelles ne sont pas des ressources que vous pouvez définir en tant qu'élément d'une politique d'autorisation IAM.
**Actions définies par HealthLake**
| Actions | Description | Niveau d’accès | Type de ressource (obligatoire) |
| --- | --- | --- | --- |
| CreateResource | Accorde l'autorisation de créer une ressource | Écrire | ARN de la banque de données : arn:aws:healthlake : ::datastore/fhir/ your-region 111122223333 your-datastore-id |
| DeleteResource | Accorde l'autorisation de supprimer une ressource | Écrire | ARN de la banque de données : arn:aws:healthlake : ::datastore/fhir/ your-region 111122223333 your-datastore-id |
| ReadResource | Accorde l'autorisation de lire une ressource | Lecture | ARN de la banque de données : arn:aws:healthlake : ::datastore/fhir/ your-region 111122223333 your-datastore-id |
| SearchWithGet | Accorde l'autorisation de rechercher des ressources avec la méthode GET | Lecture | ARN de la banque de données : arn:aws:healthlake : ::datastore/fhir/ your-region 111122223333 your-datastore-id |
| SearchWithPost | Accorde l'autorisation de rechercher des ressources avec la méthode POST | Lecture | ARN de la banque de données : arn:aws:healthlake : ::datastore/fhir/ your-region 111122223333 your-datastore-id |
| Démarrer FHIRExport JobWithPost | Donne l'autorisation de commencer un travail d'exportation FHIR avec GET | Écrire | ARN de la banque de données : arn:aws:healthlake : ::datastore/fhir/ your-region 111122223333 your-datastore-id |
| UpdateResource | Accorde l'autorisation de mettre à jour des ressources | Écrire | ARN de la banque de données : arn:aws:healthlake : ::datastore/fhir/ your-region 111122223333 your-datastore-id |
Pour commencer, vous pouvez utiliser`AmazonHealthLakeFullAccess`. Cette politique autoriserait la lecture, l'écriture, la recherche et l'exportation de toutes les ressources FHIR présentes dans un magasin de données. Pour accorder des autorisations de lecture seule sur un magasin de données, utilisez. `AmazonHealthLakeReadOnlyAccess`
Pour en savoir plus sur la création d'une politique personnalisée à l'aide de AWS Management Console AWS CLI, ou IAM SDKs, consultez la section [Création de politiques IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) dans le guide de l'utilisateur *IAM*.
### Création d'un rôle de service pour HealthLake (console IAM)
Utilisez cette procédure pour créer un rôle de service. Lorsque vous créez un service, vous devez également définir une politique IAM.
**Pour créer le rôle de service pour HealthLake (console IAM)**
1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.
1. Dans le panneau de navigation de la console IAM, choisissez **Rôles**.
1. Puis, choisissez **Create role** (Créer un rôle).
1. Sur la page **Sélectionner une entité de confiance**, choisissez **Politique de confiance personnalisée**.
1. Ensuite, sous **Politique de confiance personnalisée**, mettez à jour l'exemple de politique comme suit. Remplacez-le **your-account-id** par votre numéro de compte et ajoutez l'ARN du magasin de données que vous souhaitez utiliser dans vos tâches d'importation ou d'exportation.
------
#### [ 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. Ensuite, choisissez **Suivant**.
1. Sur la page **Ajouter des autorisations**, choisissez la politique que vous souhaitez que le HealthLake service adopte. Pour trouver votre politique, recherchez-la dans **Politiques d'autorisations**.
1. Choisissez ensuite **Attach policy**.
1. Ensuite, sur la page **Nom, révision et création** sous **Nom du rôle**, entrez un nom.
1. (Facultatif) Ensuite, sous **Description**, ajoutez une brève description de votre rôle.
1. Si possible, saisissez un nom de rôle ou le suffixe d'un nom de rôle vous permettant d'identifier l'objectif du rôle. Les noms de rôle doivent être uniques dans votre Compte AWS. Ils ne sont pas distingués au cas par cas. Par exemple, vous ne pouvez pas créer deux rôles nommés **PRODROLE** et **prodrole**. Différentes entités peuvent référencer le rôle et il n'est donc pas possible de modifier son nom après sa création.
1. Passez en revue les détails du rôle, puis choisissez **Créer un rôle**.
Pour savoir comment spécifier l'ARN du rôle dans l'exemple de fonction Lambda, consultez. [Création d'une fonction AWS Lambda](#smart-on-fhir-lambda-create)
## Rôle d’exécution Lambda
Le rôle d'exécution d'une fonction Lambda est un rôle IAM qui accorde à la fonction l'autorisation d'accéder aux AWS services et aux ressources. Cette page fournit des informations sur la façon de créer, d’afficher et de gérer le rôle d’exécution d’une fonction Lambda.
Par défaut, Lambda crée un rôle d'exécution avec des autorisations minimales lorsque vous créez une nouvelle fonction Lambda à l'aide du. AWS Management Console Pour gérer les autorisations accordées dans le rôle d'exécution, consultez la section [Création d'un rôle d'exécution dans la console IAM](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html#permissions-executionrole-console) du guide du développeur *Lambda*.
L'exemple de fonction Lambda fourni dans cette rubrique utilise Secrets Manager pour masquer les informations d'identification du serveur d'autorisation.
Comme pour tout rôle IAM que vous créez, il est important de suivre les meilleures pratiques du moindre privilège. Au cours de la phase de développement, vous pouvez parfois accorder des autorisations au-delà de ce qui est requis. Avant de publier votre fonction dans l’environnement de production, une bonne pratique consiste à ajuster la stratégie de manière à inclure uniquement les autorisations requises. Pour plus d'informations, consultez la section [Appliquer le moindre privilège dans](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) le guide de l'utilisateur *IAM*.
## HealthLake Autoriser le déclenchement de votre fonction Lambda
HealthLake Vous pouvez donc invoquer la fonction Lambda en votre nom, vous devez procéder comme suit :
+ Vous devez définir une `IdpLambdaArn` valeur égale à l'ARN de la fonction Lambda que vous HealthLake souhaitez invoquer dans la `CreateFHIRDatastore` demande.
+ Vous avez besoin d'une politique basée sur les ressources permettant HealthLake d'appeler la fonction Lambda en votre nom.
Lorsqu'il HealthLake reçoit une demande d'API REST FHIR sur un magasin de données compatible SMART on FHIR, il a besoin d'autorisations pour appeler la fonction Lambda spécifiée lors de la création du magasin de données en votre nom. Pour accorder HealthLake l'accès, vous allez utiliser une politique basée sur les ressources. *Pour en savoir plus sur la création d'une politique basée sur les ressources pour une fonction Lambda, voir [Autoriser un AWS service à appeler une fonction Lambda](https://docs.aws.amazon.com/lambda/latest/dg/access-control-resource-based.html#permissions-resource-serviceinvoke) dans le Guide du développeur.AWS Lambda *
## Provisionnement de la simultanéité pour votre fonction Lambda
**Important**
HealthLake exige que la durée d'exécution maximale de votre fonction Lambda soit inférieure à une seconde (1 000 millisecondes).
Si votre fonction Lambda dépasse la limite de temps d'exécution, vous obtenez une TimeOutexception.
Pour éviter cette exception, nous vous recommandons de configurer la simultanéité provisionnée. En allouant la simultanéité provisionnée avant une augmentation des appels, vous pouvez vous assurer que toutes les demandes sont servies par des instances initialisées avec une faible latence. *Pour en savoir plus sur la configuration de la simultanéité provisionnée, voir [Configuration de la simultanéité provisionnée dans le Guide du développeur](https://docs.aws.amazon.com/ambda/latest/dg/provisioned-concurrency.html) Lambda*
Pour connaître la durée d'exécution moyenne de votre fonction Lambda, utilisez actuellement la page de **surveillance** de votre fonction Lambda sur la console Lambda. Par défaut, la console Lambda fournit un graphique de **durée** qui indique le temps moyen, minimum et maximum consacré par votre code de fonction au traitement d'un événement. *Pour en savoir plus sur la surveillance des fonctions Lambda, consultez la section [Surveillance des fonctions dans la console Lambda dans le guide du développeur Lambda](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-functions-access-metrics.html#monitoring-console-graph-types).*
*Si vous avez déjà configuré la simultanéité pour votre fonction Lambda et que vous souhaitez la surveiller, consultez la section [Surveillance de la simultanéité](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-concurrency.html) dans le guide du développeur Lambda.*
# Utilisation d'une autorisation précise avec un magasin de données compatible SMART on FHIR HealthLake
[Les champs](reference-smart-on-fhir-oauth-scopes.md#smart-on-fhir-scopes-rest) d'application à eux seuls ne vous fournissent pas les précisions nécessaires quant aux données auxquelles un demandeur est autorisé à accéder dans un magasin de données. L'utilisation d'une autorisation précise permet d'obtenir un niveau de spécificité plus élevé lors de l'octroi de l'accès à un magasin de données compatible HealthLake SMART on FHIR. Pour utiliser une autorisation précise, définissez la `FineGrainedAuthorizationEnabled` valeur égale à `True` dans le `IdentityProviderConfiguration` paramètre de votre `CreateFHIRDatastore` demande.
Si vous avez activé l'autorisation détaillée, votre serveur d'autorisation renvoie une `fhirUser` étendue en `id_token` même temps que le jeton d'accès. Cela permet de récupérer des informations sur l'utilisateur par l'application cliente. L'application cliente doit traiter la `fhirUser` demande comme l'URI d'une ressource FHIR représentant l'utilisateur actuel. Cette valeur peut être `Patient`, `Practitioner` ou `RelatedPerson`. La réponse du serveur d'autorisation inclut également une `user/` étendue qui définit les données auxquelles l'utilisateur peut accéder. Cela utilise la syntaxe définie pour les portées liées aux portées spécifiques aux ressources FHIR :
```
user/(fhir-resource | '*').('read' | 'write' | '*')
```
Vous trouverez ci-dessous des exemples de la manière dont une autorisation précise peut être utilisée pour spécifier davantage les types de ressources FHIR liés à l'accès aux données.
+ Quand `fhirUser` une `Practitioner` autorisation précise détermine-t-elle le nombre de patients auxquels l'utilisateur peut accéder. L'accès à n'`fhirUser`est autorisé qu'aux patients auxquels le patient fait référence en `fhirUser` tant que médecin généraliste.
```
Patient.generalPractitioner : [{Reference(Practitioner)}]
```
+ Quand `fhirUser` un `Patient` ou `RelatedPerson` le patient référencé dans la demande est différent de `fhirUser` l'autorisation précise détermine l'accès `fhirUser` du patient demandé. L'accès est autorisé lorsqu'une relation est spécifiée dans la `Patient` ressource demandée.
```
Patient.link.other : {Reference(Patient|RelatedPerson)}
```
# Récupération du document SMART sur FHIR Discovery
SMART définit un document de découverte qui permet aux clients de connaître le point de terminaison d'autorisation URLs et propose des fonctionnalités prises en charge par un magasin de HealthLake données. Ces informations aident les clients à diriger les demandes d'autorisation vers le point de terminaison approprié et à créer des demandes d'autorisation prises en charge par le magasin de HealthLake données.
Pour qu'une application cliente puisse envoyer une demande FHIR REST réussie HealthLake, elle doit rassembler les exigences d'autorisation définies par le magasin de HealthLake données. Aucun jeton porteur (autorisation) *n'*est requis pour que cette demande aboutisse.
**Pour demander le document de découverte pour un magasin HealthLake de données**
1. Collectez HealthLake `region` et `datastoreId` valorisez. Pour de plus amples informations, veuillez consulter [Obtenir les propriétés du magasin de données](managing-data-stores-describe.md).
1. Construisez une URL pour la demande en utilisant les valeurs collectées pour HealthLake `region` et`datastoreId`. Ajouter au point `/.well-known/smart-configuration` de terminaison de l'URL. Pour afficher le chemin complet de l'URL dans l'exemple suivant, faites défiler le curseur sur le bouton **Copier**.
```
https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/.well-known/smart-configuration
```
1. Envoyez la demande en utilisant `GET` le protocole de [AWS signature Signature Version 4](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html). Pour afficher l'exemple dans son intégralité, faites défiler la souris sur le bouton **Copier**.
------
#### [ 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'
```
------
Le document de découverte du magasin de HealthLake données est renvoyé sous la forme d'un blob JSON, dans lequel vous pouvez trouver le `authorization_endpoint` et le`token_endpoint`, ainsi que les spécifications et les fonctionnalités définies pour le magasin de données.
```
{
"authorization_endpoint": "https://oidc.example.com/authorize",
"token_endpoint": "https://oidc.example.com/oauth/token",
"capabilities": [
"launch-ehr",
"client-public"
]
}
```
Le `authorization_endpoint` et le `token_endpoint` sont tous deux nécessaires pour lancer une application client.
+ Point de **terminaison d'autorisation** : URL nécessaire pour autoriser une application cliente ou un utilisateur.
+ Point de **terminaison du jeton** : point de terminaison du serveur d'autorisation avec lequel l'application cliente communique.
# Effectuer une demande d'API REST FHIR sur un magasin de données compatible SMART HealthLake
Vous pouvez effectuer des demandes d'API REST FHIR sur un magasin de données compatible SMART sur FHIR. HealthLake L'exemple suivant montre une demande d'une application cliente contenant un JWT dans l'en-tête d'autorisation et montre comment Lambda doit décoder la réponse. Une fois que la demande d'application cliente est autorisée et authentifiée, elle doit recevoir un jeton porteur du serveur d'autorisation. Utilisez le jeton porteur dans l'en-tête d'autorisation lorsque vous envoyez une demande d'API REST FHIR sur un magasin de données compatible SMART on HealthLake FHIR.
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient/[ID]
Authorization: Bearer auth-server-provided-bearer-token
```
Comme un jeton porteur a été trouvé dans l'en-tête d'autorisation et qu'aucune identité AWS IAM n'a été détectée, la fonction Lambda spécifiée lors de HealthLake la création du magasin de données compatible SMART on FHIR a été créé. HealthLake Lorsque le jeton est correctement décodé par votre fonction Lambda, l'exemple de réponse suivant est envoyé à. 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
}
```