Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Supporto SMART su FHIR per AWS HealthLake
Un archivio HealthLake dati compatibile con SMART (Substitutable Medical Applications and Reusable Technologies) su FHIR consente l'accesso a SMART su applicazioni conformi a FHIR. HealthLake l'accesso ai dati avviene autenticando e autorizzando le richieste utilizzando un server di autorizzazione di terze parti. Quindi, invece di gestire le credenziali degli utenti tramite AWS Identity and Access Management, lo fai utilizzando un server di autorizzazione conforme a SMART on FHIR.
**Nota**
HealthLake supporta SMART nelle versioni 1.0 e 2.0 di FHIR. Per ulteriori informazioni su questi framework, consulta [SMART App Launch](https://www.hl7.org/fhir/smart-app-launch/) nella documentazione di *FHIR* R4.
HealthLake gli archivi di dati supportano i seguenti framework di autenticazione e autorizzazione per SMART su richieste FHIR:
**OpenID (AuthN)**: per autenticare la persona o l'applicazione client indica chi (o cosa) dichiara di essere.
**OAuth 2.0 (AuthZ)**: per autorizzare le risorse FHIR presenti nell'archivio HealthLake dati su cui una richiesta autenticata può leggere o scrivere. Questo è definito dagli ambiti configurati nel server di autorizzazione.
È possibile creare un archivio dati SMART su FHIR abilitato utilizzando o. AWS CLI AWS SDKs Per ulteriori informazioni, consulta [Creazione di un archivio HealthLake dati](managing-data-stores-create.md).
**Topics**
+ [Guida introduttiva a SMART su FHIR](reference-smart-on-fhir-getting-started.md)
+ [HealthLake requisiti di autenticazione per SMART on FHIR](reference-smart-on-fhir-authentication.md)
+ [SMART su ambiti FHIR OAuth 2.0 supportati da HealthLake](reference-smart-on-fhir-oauth-scopes.md)
+ [Validazione dei token utilizzando AWS Lambda](reference-smart-on-fhir-token-validation.md)
+ [Utilizzo di un'autorizzazione granulare con un data store abilitato SMART on FHIR HealthLake](reference-smart-on-fhir-fine-grained-authorization.md)
+ [Recupero del documento SMART su FHIR Discovery](reference-smart-on-fhir-discovery-document.md)
+ [Esecuzione di una richiesta API REST FHIR su un data store abilitato per Smart HealthLake](reference-smart-on-fhir-request-example.md)
# Guida introduttiva a SMART su FHIR
I seguenti argomenti descrivono come iniziare a utilizzare l'autorizzazione SMART on FHIR per. AWS HealthLake Includono le risorse da fornire nel proprio AWS account, la creazione di un HealthLake data store abilitato per SMART on FHIR e un esempio di come un'applicazione client SMART on FHIR interagisce con un server di autorizzazione e un archivio dati. HealthLake
**Topics**
+ [Configurazione delle risorse per SMART su FHIR](#smart-on-fhir-resources)
+ [Flusso di lavoro delle applicazioni client per SMART su FHIR](#smart-on-fhir-client-app-workflow)
## Configurazione delle risorse per SMART su FHIR
I passaggi seguenti definiscono in che modo vengono gestite le richieste SMART on FHIR HealthLake e le risorse necessarie per il loro successo. I seguenti elementi interagiscono in un flusso di lavoro per creare una richiesta SMART on FHIR:
+ **L'utente finale**: in genere, un paziente o un medico che utilizza un'applicazione SMART on FHIR di terze parti per accedere ai dati in un archivio dati. HealthLake
+ **L'applicazione SMART on FHIR (denominata applicazione client): un'applicazione** che desidera accedere ai dati presenti nell'archivio dati. HealthLake
+ **Il server di autorizzazione**: un server conforme a OpenID Connect in grado di autenticare gli utenti ed emettere token di accesso.
+ **L'archivio HealthLake dati: un data store** abilitato HealthLake per SMART on FHIR che utilizza una funzione Lambda per rispondere alle richieste FHIR REST che forniscono un token bearer.
Affinché questi elementi funzionino insieme, è necessario creare le seguenti risorse.
**Nota**
Ti consigliamo di creare il tuo HealthLake data store abilitato per SMART on FHIR dopo aver configurato il server di autorizzazione, definito gli [ambiti](reference-smart-on-fhir-oauth-scopes.md) necessari su di esso e creato una AWS Lambda funzione per gestire l'introspezione dei [token](reference-smart-on-fhir-token-validation.md).
**1. Configura un endpoint del server di autorizzazione**
Per utilizzare il framework SMART on FHIR è necessario configurare un server di autorizzazione di terze parti in grado di convalidare le richieste FHIR REST effettuate su un archivio dati. Per ulteriori informazioni, consulta [HealthLake requisiti di autenticazione per SMART on FHIR](reference-smart-on-fhir-authentication.md).
**2. Definisci gli ambiti sul tuo server di autorizzazione per controllare i livelli di accesso all'archivio dati HealthLake**
Il framework SMART on FHIR utilizza OAuth gli ambiti per determinare a quali risorse FHIR ha accesso una richiesta autenticata e in che misura. La definizione degli ambiti è un modo per progettare con privilegi minimi. Per ulteriori informazioni, consulta [SMART su ambiti FHIR OAuth 2.0 supportati da HealthLake](reference-smart-on-fhir-oauth-scopes.md).
**3. Imposta una funzione in grado di eseguire l' AWS Lambda introspezione dei token**
Una richiesta FHIR REST inviata dall'applicazione client su un data store abilitato per SMART on FHIR contiene un JSON Web Token (JWT). [Per ulteriori informazioni, vedere Decodifica di un JWT.](reference-smart-on-fhir-token-validation.md)
**4. Crea un archivio dati compatibile con SMART su FHIR HealthLake**
Per creare un HealthLake data store SMART su FHIR è necessario fornire un. `IdentityProviderConfiguration` Per ulteriori informazioni, consulta [Creazione di un archivio HealthLake dati](managing-data-stores-create.md).
## Flusso di lavoro delle applicazioni client per SMART su FHIR
La sezione seguente spiega come avviare un'applicazione client ed effettuare con successo una richiesta FHIR REST su un HealthLake data store nel contesto di SMART su FHIR.
**1. Effettua una `GET` richiesta a Wonderful Uniform Resource Identifier utilizzando l'applicazione client**
Un'applicazione client abilitata a SMART deve effettuare una `GET` richiesta per trovare gli endpoint di autorizzazione del HealthLake data store. Questa operazione viene eseguita tramite una richiesta URI (Known Uniform Resource Identifier). Per ulteriori informazioni, consulta [Recupero del documento SMART su FHIR Discovery](reference-smart-on-fhir-discovery-document.md).
**2. Richiesta di accesso e ambiti**
L'applicazione client utilizza l'endpoint di autorizzazione del server di autorizzazione, in modo che l'utente possa accedere. Questo processo autentica l'utente. Gli ambiti vengono utilizzati per definire a quali risorse FHIR nell'archivio HealthLake dati può accedere un'applicazione client. Per ulteriori informazioni, consulta [SMART su ambiti FHIR OAuth 2.0 supportati da HealthLake](reference-smart-on-fhir-oauth-scopes.md).
**3. Token di accesso**
Ora che l'utente è stato autenticato, un'applicazione client riceve un token di accesso JWT dal server di autorizzazione. Questo token viene fornito quando l'applicazione client invia una richiesta FHIR REST a. HealthLake Per ulteriori informazioni, consulta [Convalida del token](reference-smart-on-fhir-token-validation.md).
**4. Effettua una richiesta API REST FHIR su SMART su un data store abilitato a FHIR HealthLake**
L'applicazione client può ora inviare una richiesta API REST FHIR a un endpoint del HealthLake data store utilizzando il token di accesso fornito dal server di autorizzazione. Per ulteriori informazioni, consulta [Esecuzione di una richiesta API REST FHIR su un data store abilitato per Smart HealthLake](reference-smart-on-fhir-request-example.md).
**5. Convalida il token di accesso JWT**
Per convalidare il token di accesso inviato nella richiesta FHIR REST, usa una funzione Lambda. Per ulteriori informazioni, consulta [Validazione dei token utilizzando AWS Lambda](reference-smart-on-fhir-token-validation.md).
# HealthLake requisiti di autenticazione per SMART on FHIR
Per accedere alle risorse FHIR in un HealthLake data store abilitato per SMART on FHIR, un'applicazione client deve essere autorizzata da un server di autorizzazione OAuth conforme alla versione 2.0 e presentare un token OAuth Bearer come parte di una richiesta API REST FHIR. Per trovare l'endpoint del server di autorizzazione, utilizzate lo SMART on FHIR Discovery Document tramite un Uniform Resource Identifier HealthLake . `Well-Known` Per ulteriori informazioni su questo processo, consultare [Recupero del documento SMART su FHIR Discovery](reference-smart-on-fhir-discovery-document.md).
Quando si crea un HealthLake data store SMART on FHIR, è necessario definire l'endpoint del server di autorizzazione e l'endpoint del token nell'elemento della `metadata` richiesta. `CreateFHIRDatastore` Per ulteriori informazioni sulla definizione dell'`metadata`elemento, vedere. [Creazione di un archivio HealthLake dati](managing-data-stores-create.md)
Utilizzando gli endpoint del server di autorizzazione, l'applicazione client autenticherà un utente con il servizio di autorizzazione. Una volta autorizzato e autenticato, un JSON Web Token (JWT) viene generato dal servizio di autorizzazione e passato all'applicazione client. Questo token contiene gli ambiti di risorse FHIR che l'applicazione client può utilizzare, il che a sua volta limita i dati a cui l'utente può accedere. Facoltativamente, se è stato fornito l'ambito di avvio, la risposta conterrà tali dettagli. Per ulteriori informazioni sugli oscilloscopi SMART on FHIR supportati da HealthLake, vedere. [SMART su ambiti FHIR OAuth 2.0 supportati da HealthLake](reference-smart-on-fhir-oauth-scopes.md)
Utilizzando il JWT concesso dal server di autorizzazione, un'applicazione client effettua chiamate API REST FHIR a un archivio dati abilitato per SMART on FHIR. HealthLake Per convalidare e decodificare il JWT, è necessario creare una funzione Lambda. HealthLake richiama questa funzione Lambda per tuo conto quando viene ricevuta una richiesta API REST FHIR. Per vedere un esempio di funzione Lambda di avvio, vedere. [Validazione dei token utilizzando AWS Lambda](reference-smart-on-fhir-token-validation.md)
## Elementi del server di autorizzazione necessari per creare un archivio dati compatibile con SMART on FHIR HealthLake
Nella `CreateFHIRDatastore` richiesta, è necessario fornire l'endpoint di autorizzazione e l'endpoint del token come parte dell'`metadata`elemento nell'`IdentityProviderConfiguration`oggetto. Sono necessari sia l'endpoint di autorizzazione che l'endpoint del token. Per vedere un esempio di come questo viene specificato nella `CreateFHIRDatastore` richiesta, vedere. [Creazione di un archivio HealthLake dati](managing-data-stores-create.md)
## Dichiarazioni obbligatorie per completare una richiesta API REST FHIR su un data store abilitato SMART on FHIR HealthLake
Affinché si tratti di una richiesta API REST FHIR valida su un data store abilitato SMART on FHIR, la AWS Lambda funzione deve contenere le seguenti affermazioni. HealthLake
+ `nbf`: Reclamo [(non prima) - L'attestazione](https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.5) «nbf» (non prima) identifica il momento prima del quale il JWT NON DEVE essere accettato per l'elaborazione. L'elaborazione del reclamo «nbf» richiede che il reclamo corrente date/time DEVE essere successivo o uguale al non precedente date/time elencato nel reclamo «nbf». La funzione Lambda di esempio che forniamo converte `iat` dalla risposta del server in. `nbf`
+ `exp`: Richiesta [(ora di scadenza) - L'attestazione](https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.4) «exp» (ora di scadenza) identifica l'ora di scadenza in cui o dopo la quale il JWT non deve essere accettato per l'elaborazione.
+ `isAuthorized`: Un valore booleano impostato su. `True` Indica che la richiesta è stata autorizzata sul server di autorizzazione.
+ `aud`: Reclamo [(Audience) - L'attestazione](https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.3) «aud» (audience) identifica i destinatari a cui è destinato il JWT. Deve essere un endpoint di archiviazione dati compatibile HealthLake con SMART on FHIR.
+ `scope`: Questo deve essere almeno un ambito relativo alle risorse FHIR. Questo ambito è definito sul server di autorizzazione. Per ulteriori informazioni sugli ambiti relativi alle risorse FHIR accettati da HealthLake, vedere. [SMART sugli ambiti di risorse FHIR per HealthLake](reference-smart-on-fhir-oauth-scopes.md#smart-on-fhir-scopes-rest)
# SMART su ambiti FHIR OAuth 2.0 supportati da HealthLake
HealthLake utilizza OAuth 2.0 come protocollo di autorizzazione. L'utilizzo di questo protocollo sul server di autorizzazione consente di definire le autorizzazioni dell'archivio HealthLake dati (creazione, lettura, aggiornamento, eliminazione e ricerca) per le risorse FHIR a cui ha accesso un'applicazione client.
Il framework SMART on FHIR definisce un set di ambiti che possono essere richiesti al server di autorizzazione. Ad esempio, un'applicazione client progettata esclusivamente per consentire ai pazienti di visualizzare i risultati di laboratorio o visualizzare i propri dati di contatto dovrebbe essere *autorizzata* solo a richiedere `read` gli oscilloscopi.
**Nota**
HealthLake fornisce supporto sia per SMART su FHIR V1 che V2, come descritto di seguito. SMART su 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)è impostato su uno dei tre valori seguenti quando viene creato il data store:
`SMART_ON_FHIR_V1`— Supporto solo per SMART su FHIR V1, che include le autorizzazioni `read` (lettura/ricerca) e `write` (). create/update/delete
`SMART_ON_FHIR`— Supporto per SMART su FIR V1 e V2, che include,`create`, `read` `update``delete`, e autorizzazioni. `search`
`AWS_AUTH`— La strategia di AWS HealthLake autorizzazione predefinita; non affiliata a SMART su FHIR.
## Ambito di lancio autonomo
HealthLake supporta l'ambito della modalità di avvio autonoma. `launch/patient`
In modalità di avvio autonoma, un'applicazione client richiede l'accesso ai dati clinici del paziente perché l'utente e il paziente non sono noti all'applicazione client. Pertanto, la richiesta di autorizzazione dell'applicazione client richiede esplicitamente la restituzione dell'ambito del paziente. Una volta completata con successo l'autenticazione, il server di autorizzazione emette un token di accesso contenente l'ambito del paziente di avvio richiesto. Il contesto paziente necessario viene fornito insieme al token di accesso nella risposta del server di autorizzazione.
**Ambiti della modalità di avvio supportati**
| Scope | Description |
| --- | --- |
| `launch/patient` | Un parametro in una richiesta di autorizzazione OAuth 2.0 che richiede la restituzione dei dati del paziente nella risposta di autorizzazione. |
## SMART sugli ambiti di risorse FHIR per HealthLake
HealthLake definisce tre livelli di SMART sugli ambiti di risorse FHIR.
+ `patient`gli ambiti garantiscono l'accesso a dati specifici su un singolo paziente.
+ `user`gli ambiti garantiscono l'accesso a dati specifici a cui un utente può accedere.
+ `system`gli ambiti concedono l'accesso a tutte le risorse FHIR presenti nell' HealthLake archivio dati.
Le sezioni seguenti elencano la sintassi per la costruzione di ambiti di risorse FHIR utilizzando SMART su FHIR V1 o SMART su FHIR V2.
**Nota**
La strategia di autorizzazione SMART on FHIR viene impostata al momento della creazione dell'archivio dati. Per ulteriori informazioni, consulta [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) nella *documentazione di riferimento dell’API AWS HealthLake *.
### Ambiti SMART su FHIR V1 supportati da HealthLake
Quando si utilizza SMART su FHIR V1, segue la sintassi generale per la costruzione degli ambiti di risorse FHIR. HealthLake **Per visualizzare l'intero percorso dell'URL nell'esempio seguente, scorri il pulsante Copia.**
```
('patient' | 'user' | 'system') '/' (fhir-resource | '*') '.' ('read' | 'write' | '*')
```
**SMART on FHIR v1 supportava gli ambiti di autorizzazione**
| Sintassi dell'ambito | Ambito di esempio | Risultato |
| --- | --- | --- |
| `patient/(fhir-resource \| '*').('read' \| 'write' \| '*')` | patient/AllergyIntolerance.\$1 | L'applicazione client per i pazienti dispone di accesso in lettura/scrittura a livello di istanza a tutte le allergie registrate. |
| `user/(fhir-resource \| '*').('read' \| 'write' \| '*')` | user/Observation.read | L'applicazione client utente ha accesso a livello di istanza read/write a tutte le osservazioni registrate. |
| system/('read' \$1 'write' \$1 \$1) | system/\$1.\$1 | L'applicazione client di sistema ha read/write accesso a tutti i dati delle risorse FHIR. |
### Ambiti SMART su FHIR V2 supportati da HealthLake
Quando si utilizza SMART su FHIR V2, segue la sintassi generale per la costruzione degli ambiti di risorse FHIR. HealthLake **Per visualizzare l'intero percorso dell'URL nell'esempio seguente, scorri il pulsante Copia.**
```
('patient' | 'user' | 'system') '/' (fhir-resource | '*') '.' ('c' | 'r' | 'u' | 'd' | 's')
```
**Nota**
Per utilizzare SMART su FHIR V2, è necessario inserire il valore [https://hl7.org/fhir/smart-app-launch/STU2/conformance.html#permissions](https://hl7.org/fhir/smart-app-launch/STU2/conformance.html#permissions)nella `capabilities` stringa di metadati, che è un membro del [https://docs.aws.amazon.com/healthlake/latest/APIReference/API_IdentityProviderConfiguration.html](https://docs.aws.amazon.com/healthlake/latest/APIReference/API_IdentityProviderConfiguration.html)tipo di dati.
HealthLake supporta cannocchiali granulari. Per ulteriori informazioni, consulta gli [ambiti granulari supportati](https://hl7.org/fhir/us/core/scopes.html#the-following-granular-scopes-shall-be-supported) nella *FHIR* US Core Implementation Guide.
**Ambiti di autorizzazione supportati da SMART on FHIR V2**
| Sintassi dell'ambito | Esempio di ambito V1 | Risultato |
| --- | --- | --- |
| `patient/Observation.rs` | user/Observation.read | Autorizzazione a leggere e cercare Observation risorse per il paziente attuale. |
| `system/*.cruds` | system/\$1.\$1 | L'applicazione client di sistema ha pieno create/read/update/delete/search accesso a tutti i dati delle risorse FHIR. |
# Validazione dei token utilizzando AWS Lambda
Quando si crea un archivio dati HealthLake SMART su FHIR abilitato, è necessario fornire l'ARN della funzione AWS Lambda nella `CreateFHIRDatastore` richiesta. L'ARN della funzione Lambda è specificato nell'`IdentityProviderConfiguration`oggetto utilizzando il parametro. `IdpLambdaArn`
È necessario creare la funzione Lambda prima di creare l'archivio dati abilitato per SMART on FHIR. Una volta creato il data store, l'ARN Lambda non può essere modificato. Per visualizzare l'ARN Lambda specificato al momento della creazione del data store, utilizza l'azione API. `DescribeFHIRDatastore`
**Affinché una richiesta REST FHIR abbia esito positivo su un data store abilitato SMART on FHIR, la funzione Lambda deve eseguire le seguenti operazioni:**
+ Restituisce una risposta in meno di 1 secondo all'endpoint del HealthLake data store.
+ Decodifica il token di accesso fornito nell'intestazione di autorizzazione della richiesta API REST inviata dall'applicazione client.
+ Assegna un ruolo di servizio IAM con autorizzazioni sufficienti per eseguire la richiesta API REST FHIR.
+ Le seguenti affermazioni sono necessarie per completare una richiesta API REST FHIR. Per ulteriori informazioni, consulta [Richieste necessarie](reference-smart-on-fhir-authentication.md#server-response).
+ `nbf`
+ `exp`
+ `isAuthorized`
+ `aud`
+ `scope`
Quando lavori con Lambda, devi creare un ruolo di esecuzione e una policy basata sulle risorse oltre alla funzione Lambda. Il ruolo di esecuzione di una funzione Lambda è un ruolo IAM che concede alla funzione l'autorizzazione ad accedere ai servizi e alle risorse AWS necessari in fase di esecuzione. La policy basata sulle risorse che fornisci deve consentire di richiamare la tua funzione HealthLake per tuo conto.
Le sezioni di questo argomento descrivono una richiesta di esempio da un'applicazione client e una risposta decodificata, i passaggi necessari per creare una funzione AWS Lambda e come creare una politica basata sulle risorse che possa presupporre. HealthLake
+ [Parte 1: creazione di una funzione Lambda](#smart-on-fhir-lambda-create)
+ [Parte 2: creazione di un ruolo HealthLake di servizio utilizzato dalla funzione AWS Lambda](#smart-on-fhir-lambda-service-role)
+ [Parte 3: Aggiornamento del ruolo di esecuzione della funzione Lambda](#smart-on-fhir-lambda-service-role-execution-role)
+ [Parte 4: aggiunta di una politica delle risorse alla funzione Lambda](#smart-on-fhir-lambda-invoke-healthlake)
+ [Parte 5: Fornire la concorrenza per la funzione Lambda](#smart-on-fhir-lambda-function-scaling)
## Creazione di una funzione AWS Lambda
La funzione Lambda creata in questo argomento viene attivata quando HealthLake riceve una richiesta a un data store abilitato SMART on FHIR. La richiesta proveniente dall'applicazione client contiene una chiamata API REST e un'intestazione di autorizzazione contenente un token di accesso.
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/
Authorization: Bearer i8hweunweunweofiwweoijewiwe
```
L'esempio della funzione Lambda in questo argomento utilizza Gestione dei segreti AWS per oscurare le credenziali relative al server di autorizzazione. Consigliamo vivamente di non fornire i dettagli di accesso al server di autorizzazione direttamente in una funzione Lambda.
**Example convalida di una richiesta FHIR REST contenente un token del portatore di autorizzazione**
La funzione Lambda di esempio mostra come convalidare una richiesta FHIR REST inviata a un archivio dati SMART su FHIR abilitato. Per visualizzare step-by-steps le istruzioni su come implementare questa funzione Lambda, vedere. [Creazione di una funzione Lambda utilizzando Console di gestione AWS](#create-lambda-console)
Se la richiesta API REST FHIR non contiene un endpoint di data store, un token di accesso e un'operazione REST validi, la funzione Lambda avrà esito negativo. Per ulteriori informazioni sugli elementi richiesti del server di autorizzazione, consulta. [Richieste necessarie](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()
```
### Creazione di una funzione Lambda utilizzando Console di gestione AWS
La procedura seguente presuppone che tu abbia già creato il ruolo di servizio che desideri assumere quando gestisci una richiesta API REST FHIR su un data store abilitato HealthLake per SMART on FHIR. Se non hai creato il ruolo di servizio, puoi comunque creare la funzione Lambda. È necessario aggiungere l'ARN del ruolo di servizio prima che la funzione Lambda funzioni. Per ulteriori informazioni sulla creazione di un ruolo di servizio e sulla sua specificazione nella funzione Lambda, consulta [Creazione di un ruolo HealthLake di servizio da utilizzare nella funzione AWS Lambda utilizzata per decodificare un JWT](#smart-on-fhir-lambda-service-role)
**Per creare una funzione Lambda ()Console di gestione AWS**
1. Aprire la pagina [Funzioni](https://console.aws.amazon.com/lambda/home/functions) della console Lambda.
1. Scegli **Crea funzione**.
1. Scegli **Crea da zero**.
1. In **Informazioni di base**, inserisci il **nome di una funzione**. In **Runtime scegli un runtime** basato su Python.
1. In **Execution role** (Ruolo di esecuzione), scegli **Create a new role with basic Lambda permissions** (Crea un nuovo ruolo con le autorizzazioni Lambda di base).
Lambda crea un [ruolo di esecuzione](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html) che concede alla funzione l'autorizzazione a caricare i log su Amazon. CloudWatch La funzione Lambda assume il ruolo di esecuzione quando si richiama la funzione e utilizza il ruolo di esecuzione per creare credenziali per l'SDK. AWS
1. Scegliete la scheda **Codice** e aggiungete la funzione Lambda di esempio.
Se non hai ancora creato il ruolo di servizio per la funzione Lambda da utilizzare, dovrai crearlo prima che la funzione Lambda di esempio funzioni. Per ulteriori informazioni sulla creazione di un ruolo di servizio per la funzione Lambda, vedere. [Creazione di un ruolo HealthLake di servizio da utilizzare nella funzione AWS Lambda utilizzata per decodificare 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()
```
### Modifica del ruolo di esecuzione di una funzione Lambda
Dopo aver creato la funzione Lambda, è necessario aggiornare il ruolo di esecuzione per includere le autorizzazioni necessarie per chiamare Secrets Manager. In Secrets Manager, ogni segreto creato ha un ARN. Per applicare il privilegio minimo, il ruolo di esecuzione deve avere accesso solo alle risorse necessarie per l'esecuzione della funzione Lambda.
Puoi modificare il ruolo di esecuzione di una funzione Lambda cercandola nella console IAM o scegliendo **Configurazione** nella console Lambda. Per ulteriori informazioni sulla gestione del ruolo di esecuzione delle funzioni Lambda, consulta. [Ruolo di esecuzione Lambda](#smart-on-fhir-lambda-service-role-execution-role)
**Example Ruolo di esecuzione della funzione Lambda che concede l'accesso a `GetSecretValue`**
L'aggiunta dell'azione IAM `GetSecretValue` al ruolo di esecuzione concede l'autorizzazione necessaria per il funzionamento della funzione Lambda di esempio.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "secretsmanager:GetSecretValue",
"Resource": "arn:aws:secretsmanager:us-east-1:123456789012:secret:secret-name-DKodTA"
}
]
}
```
A questo punto hai creato una funzione Lambda che può essere utilizzata per convalidare il token di accesso fornito come parte della richiesta FHIR REST inviata al tuo data store abilitato SMART on FHIR.
## Creazione di un ruolo HealthLake di servizio da utilizzare nella funzione AWS Lambda utilizzata per decodificare un JWT
**Persona: amministratore IAM**
Un utente che può aggiungere o rimuovere policy IAM e creare nuove identità IAM.
**Ruolo del servizio**
Un ruolo di servizio è un [ruolo IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) che un servizio assume per eseguire operazioni per tuo conto. Un amministratore IAM può creare, modificare ed eliminare un ruolo di servizio dall’interno di IAM. Per ulteriori informazioni, consulta [Create a role to delegate permissions to an Servizio AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) nella *Guida per l’utente IAM*.
Dopo la decodifica del JSON Web Token (JWT), l'autorizzazione necessaria a Lambda deve restituire anche un ruolo IAM ARN. Questo ruolo deve disporre delle autorizzazioni necessarie per eseguire la richiesta API REST o fallirà a causa di autorizzazioni insufficienti.
Quando si configura una policy personalizzata utilizzando IAM, è meglio concedere le autorizzazioni minime richieste. *Per ulteriori informazioni, consulta [Applica le autorizzazioni con privilegi minimi](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) nella Guida per l'utente IAM.*
La creazione di un ruolo di HealthLake servizio da designare nella funzione di autorizzazione Lambda richiede due passaggi.
+ Innanzitutto, è necessario creare una policy IAM. La policy deve specificare l'accesso alle risorse FHIR per le quali sono stati forniti gli ambiti nel server di autorizzazione.
+ In secondo luogo, è necessario creare il ruolo di servizio. Quando si crea il ruolo, si designa una relazione di fiducia e si allega la politica creata nella prima fase. La relazione di fiducia viene designata HealthLake come responsabile del servizio. In questo passaggio è necessario specificare un ARN del HealthLake data store e un ID AWS account.
### Creazione di una nuova policy IAM
Gli ambiti definiti nel server di autorizzazione determinano a quali risorse FHIR un utente autenticato ha accesso in un HealthLake archivio dati.
La policy IAM che crei può essere personalizzata in base agli ambiti che hai definito.
È possibile definire le seguenti azioni nell'`Action`elemento di una dichiarazione di policy IAM. Per ognuno `Action` nella tabella puoi definire un`Resource types`. In HealthLake un data store è l'unico tipo di risorsa supportato che può essere definito nell'`Resource`elemento di una dichiarazione di policy di autorizzazione IAM.
Le singole risorse FHIR non sono una risorsa che è possibile definire come elemento in una politica di autorizzazione IAM.
**Azioni definite da HealthLake**
| Azioni | Descrizione | Livello di accesso | Tipo di risorsa (obbligatorio) |
| --- | --- | --- | --- |
| CreateResource | Concede l'autorizzazione a creare una risorsa | Scrittura | ARN dell'archivio dati: arn:aws:healthlake: ::datastore/fhir/ your-region 111122223333 your-datastore-id |
| DeleteResource | Concede l'autorizzazione per eliminare la risorsa | Scrittura | ARN dell'archivio dati: arn:aws:healthlake: ::datastore/fhir/ your-region 111122223333 your-datastore-id |
| ReadResource | Concede l'autorizzazione per leggere la risorsa | Lettura | ARN dell'archivio dati: arn:aws:healthlake: ::datastore/fhir/ your-region 111122223333 your-datastore-id |
| SearchWithGet | Concede l'autorizzazione per cercare risorse con il metodo GET | Lettura | ARN dell'archivio dati: arn:aws:healthlake: ::datastore/fhir/ your-region 111122223333 your-datastore-id |
| SearchWithPost | Concede l'autorizzazione per cercare risorse con il metodo POST | Lettura | ARN dell'archivio dati: arn:aws:healthlake: ::datastore/fhir/ your-region 111122223333 your-datastore-id |
| Avviare FHIRExport JobWithPost | Concede il permesso di iniziare un lavoro in FHIR Export con GET | Scrittura | ARN dell'archivio dati: arn:aws:healthlake: ::datastore/fhir/ your-region 111122223333 your-datastore-id |
| UpdateResource | Concede l'autorizzazione per aggiornare la risorsa | Scrittura | ARN dell'archivio dati: arn:aws:healthlake: ::datastore/fhir/ your-region 111122223333 your-datastore-id |
Per iniziare, puoi usare. `AmazonHealthLakeFullAccess` Questa politica garantirebbe la lettura, la scrittura, la ricerca e l'esportazione su tutte le risorse FHIR presenti in un archivio dati. Per concedere autorizzazioni di sola lettura su un data store, utilizzare. `AmazonHealthLakeReadOnlyAccess`
*Per ulteriori informazioni sulla creazione di una policy personalizzata utilizzando o IAM Console di gestione AWS AWS CLI SDKs, consulta [Creating IAM policies nella IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) User Guide.*
### Creazione di un ruolo di servizio per HealthLake (console IAM)
Utilizzare questa procedura per creare un ruolo di servizio. Quando crei un servizio, dovrai anche designare una policy IAM.
**Per creare il ruolo di servizio per HealthLake (console IAM)**
1. Accedi Console di gestione AWS e apri la console IAM all'indirizzo [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. Nel pannello di navigazione della console IAM seleziona **Ruoli**.
1. Quindi seleziona **Create role** (Crea ruolo).
1. Nella pagina **Seleziona un'entità fiduciaria**, scegli **Politica di fiducia personalizzata**.
1. Successivamente, in **Politica di fiducia personalizzata**, aggiorna la politica di esempio come segue. Sostituisci **your-account-id** con il tuo numero di account e aggiungi l'ARN del data store che desideri utilizzare nei processi di importazione o esportazione.
------
#### [ 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. Quindi, seleziona **Successivo**.
1. Nella pagina **Aggiungi autorizzazioni**, scegli la politica che desideri che il HealthLake servizio assuma. Per trovare la tua politica, cercala in Politiche di **autorizzazione**.
1. Quindi, scegli **Allega politica**.
1. Quindi nella pagina **Nome, rivedi e crea** in **Nome del ruolo**, inserisci un nome.
1. (Facoltativo) Quindi, in **Descrizione**, aggiungi una breve descrizione del tuo ruolo.
1. Se possibile, specifica un nome del ruolo o un suffisso del nome del ruolo per facilitare l'identificazione dello scopo del ruolo. I nomi dei ruoli devono essere univoci all'interno dell' Account AWS. Non si distinguono per caso. Ad esempio, non è possibile creare ruoli denominati sia **PRODROLE** che **prodrole**. Poiché varie entità possono fare riferimento al ruolo, non è possibile modificare il nome del ruolo dopo averlo creato.
1. Esamina i dettagli del ruolo, quindi scegli **Crea ruolo**.
Per informazioni su come specificare il ruolo ARN nella funzione Lambda di esempio, vedere. [Creazione di una funzione AWS Lambda](#smart-on-fhir-lambda-create)
## Ruolo di esecuzione Lambda
Il ruolo di esecuzione di una funzione Lambda è un ruolo IAM che concede alla funzione il permesso di accedere a AWS servizi e risorse. Questa pagina fornisce informazioni su come creare, visualizzare e gestire il ruolo di esecuzione di una funzione Lambda.
Per impostazione predefinita, Lambda crea un ruolo di esecuzione con autorizzazioni minime quando si crea una nuova funzione Lambda utilizzando. Console di gestione AWS Per gestire le autorizzazioni concesse nel ruolo di esecuzione, consulta [Creazione di un ruolo di esecuzione nella console IAM nella](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html#permissions-executionrole-console) *Lambda* Developer Guide.
La funzione Lambda di esempio fornita in questo argomento utilizza Secrets Manager per oscurare le credenziali del server di autorizzazione.
Come per qualsiasi ruolo IAM creato, è importante seguire le best practice con privilegi minimi. Durante la fase di sviluppo, a volte potresti concedere autorizzazioni oltre a quelle richieste. Prima di pubblicare la funzione nell'ambiente di produzione, una best practice consiste nel modificare la policy in modo da includere solo le autorizzazioni richieste. *Per ulteriori informazioni, consulta [Apply least-privilege](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) nella IAM User Guide.*
## Consenti HealthLake di attivare la funzione Lambda
Quindi HealthLake puoi invocare la funzione Lambda per tuo conto, devi fare quanto segue:
+ È necessario impostare `IdpLambdaArn` uguale all'ARN della funzione Lambda che si desidera HealthLake richiamare nella richiesta. `CreateFHIRDatastore`
+ È necessaria una politica basata sulle risorse che consenta di HealthLake richiamare la funzione Lambda per conto dell'utente.
Quando HealthLake riceve una richiesta API REST FHIR su un data store abilitato SMART on FHIR, ha bisogno delle autorizzazioni per richiamare la funzione Lambda specificata al momento della creazione del data store per conto dell'utente. Per concedere HealthLake l'accesso, utilizzerai una politica basata sulle risorse. *Per ulteriori informazioni sulla creazione di una politica basata sulle risorse per una funzione Lambda, consulta [Consentire AWS a un servizio di chiamare una funzione Lambda](https://docs.aws.amazon.com/lambda/latest/dg/access-control-resource-based.html#permissions-resource-serviceinvoke) nella Developer Guide.AWS Lambda *
## Fornire la concorrenza per la funzione Lambda
**Importante**
HealthLake richiede che il tempo di esecuzione massimo per la funzione Lambda sia inferiore a un secondo (1000 millisecondi).
Se la funzione Lambda supera il limite di tempo di esecuzione, si ottiene un'eccezione. TimeOut
Per evitare che si verifichi questa eccezione, consigliamo di configurare la concorrenza fornita. Allocando la simultaneità fornita prima di un aumento delle chiamate, è possibile assicurarsi che tutte le richieste siano servite da istanze inizializzate con latenza bassa. *Per ulteriori informazioni sulla configurazione della concorrenza predisposta, consulta Configuring provisioned concurrency nella [Lambda Developer Guide](https://docs.aws.amazon.com/ambda/latest/dg/provisioned-concurrency.html)*
Per vedere il tempo di esecuzione medio della tua funzione Lambda, utilizza attualmente la pagina **Monitoraggio** della funzione Lambda sulla console Lambda. Per impostazione predefinita, la console Lambda fornisce un grafico della **durata** che mostra il tempo medio, minimo e massimo impiegato dal codice della funzione per l'elaborazione di un evento. *Per ulteriori informazioni sul monitoraggio delle funzioni Lambda, consulta [Monitoring functions in Lambda console Lambda nella Lambda Developer](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-functions-access-metrics.html#monitoring-console-graph-types) Guide.*
*Se hai già predisposto la concorrenza per la tua funzione Lambda e desideri monitorarla, consulta [Monitoring concurrency](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-concurrency.html) nella Lambda Developer Guide.*
# Utilizzo di un'autorizzazione granulare con un data store abilitato SMART on FHIR HealthLake
[Gli ambiti](reference-smart-on-fhir-oauth-scopes.md#smart-on-fhir-scopes-rest) da soli non forniscono la specificità necessaria sui dati a cui un richiedente è autorizzato ad accedere in un data store. L'utilizzo di un'autorizzazione granulare consente un livello di specificità più elevato quando si concede l'accesso a un data store abilitato per SMART on FHIR. HealthLake Per utilizzare un'autorizzazione granulare, imposta `FineGrainedAuthorizationEnabled` uguale a nel parametro della richiesta. `True` `IdentityProviderConfiguration` `CreateFHIRDatastore`
Se hai abilitato l'autorizzazione granulare, il tuo server di autorizzazione restituisce un `fhirUser` ambito insieme al `id_token` token di accesso. Ciò consente di recuperare le informazioni sull'utente dall'applicazione client. L'applicazione client deve trattare il `fhirUser` claim come l'URI di una risorsa FHIR che rappresenta l'utente corrente. Questo valore può essere `Patient`, `Practitioner` o `RelatedPerson`. La risposta del server di autorizzazione include anche un `user/` ambito che definisce a quali dati l'utente può accedere. Questo utilizza la sintassi definita per gli ambiti relativi agli ambiti specifici delle risorse FHIR:
```
user/(fhir-resource | '*').('read' | 'write' | '*')
```
Di seguito sono riportati alcuni esempi di come l'autorizzazione granulare può essere utilizzata per specificare ulteriormente i tipi di risorse FHIR relativi all'accesso ai dati.
+ Quando `fhirUser` è un'autorizzazione `Practitioner` dettagliata determina l'insieme di pazienti a cui l'utente può accedere. L'accesso `fhirUser` è consentito solo ai pazienti per i quali il Paziente si rivolge a un medico `fhirUser` generico.
```
Patient.generalPractitioner : [{Reference(Practitioner)}]
```
+ Quando `fhirUser` è un `Patient` operatore `RelatedPerson` e il paziente a cui si fa riferimento nella richiesta è diverso dall'autorizzazione `fhirUser` dettagliata a cui il paziente richiesto può accedere. `fhirUser` L'accesso è consentito quando esiste una relazione specificata nella risorsa richiesta. `Patient`
```
Patient.link.other : {Reference(Patient|RelatedPerson)}
```
# Recupero del documento SMART su FHIR Discovery
SMART definisce un Discovery Document che consente ai clienti di conoscere l'endpoint di autorizzazione URLs e le funzionalità supportate da un HealthLake data store. Queste informazioni aiutano i client a indirizzare le richieste di autorizzazione all'endpoint corretto e a creare richieste di autorizzazione supportate dal HealthLake data store.
Affinché un'applicazione client possa inoltrare correttamente una richiesta FHIR REST HealthLake, deve raccogliere i requisiti di autorizzazione definiti dall' HealthLake archivio dati. *Non* è necessario un token al portatore (autorizzazione) per il successo di questa richiesta.
**Per richiedere il Discovery Document per un HealthLake data store**
1. Raccolta HealthLake `region` e `datastoreId` valori. Per ulteriori informazioni, consulta [Ottenere le proprietà dell'archivio dati](managing-data-stores-describe.md).
1. Costruisci un URL per la richiesta utilizzando i valori raccolti per HealthLake `region` e`datastoreId`. Aggiungi `/.well-known/smart-configuration` all'endpoint dell'URL. Per visualizzare l'intero percorso dell'URL nell'esempio seguente, scorri il pulsante **Copia**.
```
https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/.well-known/smart-configuration
```
1. Invia la richiesta utilizzando il protocollo `GET` di [AWS firma Signature Version 4](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html). Per visualizzare l'intero esempio, scorri il pulsante **Copia**.
------
#### [ 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'
```
------
Il Discovery Document per il HealthLake data store viene restituito come un blob JSON, in cui puoi trovare l'`authorization_endpoint`e`token_endpoint`, insieme alle specifiche e alle funzionalità definite per il data store.
```
{
"authorization_endpoint": "https://oidc.example.com/authorize",
"token_endpoint": "https://oidc.example.com/oauth/token",
"capabilities": [
"launch-ehr",
"client-public"
]
}
```
Entrambi `token_endpoint` sono necessari per avviare un'applicazione client. `authorization_endpoint`
+ **Endpoint di autorizzazione**: l'URL necessario per autorizzare un'applicazione o un utente client.
+ **Endpoint token**: l'endpoint del server di autorizzazione utilizzato dall'applicazione client per comunicare.
# Esecuzione di una richiesta API REST FHIR su un data store abilitato per Smart HealthLake
È possibile effettuare richieste API REST FHIR su un data store abilitato per SMART on HealthLake FHIR. L'esempio seguente mostra una richiesta da un'applicazione client contenente un JWT nell'intestazione di autorizzazione e come Lambda deve decodificare la risposta. Dopo che la richiesta dell'applicazione client è stata autorizzata e autenticata, deve ricevere un token portatore dal server di autorizzazione. Utilizza il token bearer nell'intestazione di autorizzazione quando invii una richiesta API REST FHIR su un data store abilitato per SMART on FHIR. HealthLake
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient/[ID]
Authorization: Bearer auth-server-provided-bearer-token
```
Poiché è stato trovato un token bearer nell'intestazione di autorizzazione e non è stata rilevata alcuna identità AWS IAM, HealthLake richiama la funzione Lambda specificata quando è stato creato il data store abilitato SMART on HealthLake FHIR. Quando il token viene decodificato correttamente dalla funzione Lambda, viene inviata la seguente risposta di esempio a. 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
}
```