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à.
# AWS HealthLake riferimento
Il seguente materiale di riferimento di supporto è disponibile per SMART su FHIR, FHIR e. AWS HealthLake
**Nota**
Tutte le HealthLake azioni e i tipi di dati nativi sono descritti in un riferimento separato. Per ulteriori informazioni, consulta la [documentazione di riferimento dell’API di *AWS HealthLake *](https://docs.aws.amazon.com/healthlake/latest/APIReference/).
**Topics**
+ [SMART su FHIR](reference-smart-on-fhir.md)
+ [FHIR R4](reference-fhir.md)
+ [Conformità](reference-compliance.md)
+ [HealthLake](reference-healthlake.md)
# 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
}
```
# Supporto FHIR R4 per AWS HealthLake
AWS HealthLake supporta la specifica FHIR R4 per lo scambio di dati sanitari. Le sezioni seguenti forniscono informazioni di supporto su come HealthLake utilizza la specifica FHIR R4 per aiutarti a [gestire](managing-fhir-resources.md) e [cercare](searching-fhir-resources.md) le risorse FHIR nel tuo HealthLake archivio dati utilizzando FHIR R4. RESTful APIs
**Topics**
+ [Dichiarazione di capacità](reference-fhir-capability-statement.md)
+ [Convalide dei profili](reference-fhir-profile-validations.md)
+ [Tipi di risorse](reference-fhir-resource-types.md)
+ [Parametri di ricerca](reference-fhir-search-parameters.md)
+ [\$1 Operazioni](reference-fhir-operations.md)
# Dichiarazione di capacità FHIR R4 per AWS HealthLake
Per trovare le funzionalità (comportamenti) relative al FHIR di un archivio HealthLake dati attivo, è necessario recuperarne la dichiarazione di capacità. La Capability Statement viene utilizzata come dichiarazione della funzionalità effettiva del server o come dichiarazione dell'implementazione del server richiesta o desiderata. L'[https://hl7.org/fhir/R4/http.html#capabilities](https://hl7.org/fhir/R4/http.html#capabilities)interazione FHIR recupera informazioni sulle funzionalità dell'archivio HealthLake dati e sulle parti della specifica FHIR supportate. HealthLake convalida i tipi di risorse FHIR in base alla risorsa FHIR R4. [https://hl7.org/fhir/R4/structuredefinition.html](https://hl7.org/fhir/R4/structuredefinition.html)
**Per ottenere la dichiarazione di capacità per un archivio dati HealthLake**
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`. Includi anche l'`metadata`elemento FHIR nell'URL. Per visualizzare l'intero percorso dell'URL nell'esempio seguente, scorri il pulsante **Copia**.
```
https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/metadata
```
1. Inviare la richiesta . L'`capabilities`interazione FHIR utilizza una `GET` richiesta con il protocollo di [AWS firma Signature Version 4](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html). L'`curl`esempio seguente ottiene la dichiarazione di capacità per l'archivio HealthLake dati specificato da. `datastoreId` Per visualizzare l'intero esempio, scorri il pulsante **Copia**.
------
#### [ curl ]
```
curl --request GET \
'https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/metadata \
--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'
```
------
Riceverai un codice di risposta `200` HTTP e la dichiarazione di capacità per il tuo HealthLake data store. Per ulteriori informazioni, vedere la [https://hl7.org/fhir/R4/capabilitystatement.html](https://hl7.org/fhir/R4/capabilitystatement.html)documentazione di **FHIR R4**.
# Validazioni del profilo FHIR per HealthLake
AWS HealthLake supporta la specifica [FHIR R4 di](https://hl7.org/fhir/R4) base. Nella specifica FHIR R4 di base sono inclusi i profili FHIR. I profili vengono utilizzati su un tipo di risorsa FHIR per definire una definizione di tipo di risorsa più specifica utilizzando le and/or estensioni dei vincoli sul tipo di risorsa di base. Ad esempio, un profilo FHIR può identificare campi obbligatori come estensioni e set di valori. Una risorsa può supportare più profili. Tutti gli archivi HealthLake dati supportano l'utilizzo dei profili FHIR.
**Nota**
L'aggiunta di un profilo FHIR *non* è necessaria quando si aggiungono dati a un archivio HealthLake dati. Se non viene specificato un profilo FHIR quando una risorsa viene aggiunta o aggiornata, la risorsa viene convalidata solo rispetto allo schema FHIR R4 di base.
I profili FHIR, a cui si conformano le risorse FHIR, vengono inclusi nelle risorse prima di essere importati. HealthLake Pertanto, i profili FHIR vengono convalidati durante l'importazione. HealthLake
I profili FHIR sono specificati in una guida all'implementazione. Una guida all'implementazione FHIR (IG) è un insieme di istruzioni che descrivono come utilizzare lo standard FHIR per uno scopo specifico. HealthLake convalida i profili FHIR definiti nelle seguenti guide di implementazione.
**profili FHIR supportati da AWS HealthLake**
| Name | Versione | Guida all'implementazione | Funzionalità | Stati Uniti orientali (Ohio) | Stati Uniti orientali (Virginia settentrionale) | Stati Uniti occidentali (Oregon) | Asia Pacifico (Mumbai) | Asia Pacifico (Sydney) | Canada (Central) | Europa (Irlanda) | Europa (Londra) |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| US Core | 3.1.1 | [http://hl7.org/fhir/us/core/STU3.1.1/](http://hl7.org/fhir/us/core/STU3.1.1/) | Predefinita | X | X | X | X | X | X | X | X |
| US Core | 4.0.0 | [https://hl7.org/fhir/us/core/STU4/index.html](https://hl7.org/fhir/us/core/STU4/index.html) | Supportata | X | X | X | X | X | X | X | X |
| US Core | 5.0.1 | [https://hl7.org/fhir/us/core/STU5.0.1/index.html](https://hl7.org/fhir/us/core/STU5.0.1/index.html) | Supportata | X | X | X | X | X | X | X | X |
| U.S. Core | 6.1.0 | [https://hl7.org/fhir/us/core/STU6.1/index.html](https://hl7.org/fhir/us/core/STU6.1/index.html) | Supportata | X | X | X | X | X | X | X | X |
| U.S. Core | 7.0.0 | [https://hl7.org/fhir/us/core/STU7/](https://hl7.org/fhir/us/core/STU7/) | Supportata | X | X | X | X | X | X | X | X |
| UK Core | 2.0.1 | [https://simplifier.net/guide/uk-core-implementation-guide-stu2/Home/ProfilesandExtensions/ProfilesIndex?version=2.0.1](https://simplifier.net/guide/uk-core-implementation-guide-stu2/Home/ProfilesandExtensions/ProfilesIndex?version=2.0.1) | Supportata | X | X | X | X | | | X | X |
| Bottone blu CARIN | 1.1.0 | [http://hl7.org/fhir/us/carin-bb/STU1.1/](http://hl7.org/fhir/us/carin-bb/STU1.1/) | Predefinita | X | X | X | X | X | X | X | X |
| Bottone blu CARIN | 1.0.0, 2.0.0, 2.1.0 | [https://hl7.org/fhir/us/carin-bb/history.html](https://hl7.org/fhir/us/carin-bb/history.html) | Supportata | X | X | X | X | X | X | X | X |
| Da Vinci Payer Data Exchange | 1.0.0 | [https://hl7.org/fhir/us/davinci-pdex/](https://hl7.org/fhir/us/davinci-pdex/) | Predefinita | X | X | X | X | X | X | X | X |
| Da Vinci Payer Data Exchange | 2.0.0, 2.1.0 | [https://hl7.org/fhir/us/davinci-pdex/history.html](https://hl7.org/fhir/us/davinci-pdex/history.html) | Supportata | X | X | X | X | X | X | X | X |
| Da Vinci Health Record Exchange () HRex | 0.2.0 | [https://hl7.org/fhir/us/davinci-hrex/2020Sep/](https://hl7.org/fhir/us/davinci-hrex/2020Sep/) | Predefinita | X | X | X | X | X | X | X | X |
| DaVinci Piano PDEX Net | 1.1.0 | [https://hl7.org/fhir/us/davinci-pdex-plan-net/STU1.1/](https://hl7.org/fhir/us/davinci-pdex-plan-net/STU1.1/) | Predefinita | X | X | X | X | X | X | X | X |
| DaVinci Piano PDEX Net | 1.0.0 | [https://hl7.org/fhir/us/davinci-pdex-plan-net/STU1/](https://hl7.org/fhir/us/davinci-pdex-plan-net/STU1/) | Supportata | X | X | X | X | X | X | X | X |
| DaVinci Payer Data Exchange (PDex) US Drug Formulary | 1.1.0 | [https://hl7.org/fhir/us/davinci-drug-formulary/STU1.1/](https://hl7.org/fhir/us/davinci-drug-formulary/STU1.1/) | Predefinita | X | X | X | X | X | X | X | X |
| DaVinci Payer Data Exchange (PDex) US Drug Formulary | 1.0.1, 2.0.1, 2.1.0 | [https://hl7.org/fhir/us/davinci-drug-formulary/history.html](https://hl7.org/fhir/us/davinci-drug-formulary/history.html) | Supportata | X | X | X | X | X | X | X | X |
| Da Vinci Clinical Data Exchange () CDex | 2.1.0 | [https://build.fhir.org/ig/HL7/davinci-ecdx/index.html](https://build.fhir.org/ig/HL7/davinci-ecdx/index.html) | Predefinita | X | X | X | X | X | X | X | X |
| Da Vinci Prior Authorization Support (PAS) FHIR IG | 2.1.0 | [https://hl7.org/fhir/us/davinci-pas/](https://hl7.org/fhir/us/davinci-pas/) | Predefinita | X | X | X | X | X | X | X | X |
| Guida all'implementazione di NCA HEDIS® | 0.3.1 | [https://www.ncqa.org/resources/hedis-ig-resource-page/](https://www.ncqa.org/resources/hedis-ig-resource-page/) | Predefinita | X | X | X | X | | | X | X |
| Riepilogo internazionale dei pazienti (IPS) | 2.0.0-ballottaggio | [https://hl7.org/fhir/uv/ips/2024Sep/](https://hl7.org/fhir/uv/ips/2024Sep/) | Predefinita | X | X | X | X | X | X | X | X |
| Misura di qualità | 5.0.0 | [https://registry.fhir.org/package/hl7.fhir.us.cqfmeasures%7C5.0.0](https://registry.fhir.org/package/hl7.fhir.us.cqfmeasures%7C5.0.0) | Predefinita | X | X | X | X | | | X | X |
| Rapporti genomici | 3.0.0 | [https://build.fhir.org/ig/HL7/genomics-reporting/index.html](https://build.fhir.org/ig/HL7/genomics-reporting/index.html) | Predefinita | X | X | X | X | | | X | X |
| Ayushman Bharat Digital Mission (ABDM) della National Health Authority | 2.0 | [https://www.nrces.in/ndhm/fhir/r4/index.html](https://www.nrces.in/ndhm/fhir/r4/index.html) | Predefinita | X | X | X | X | | | X | X |
| CA Core\$1 | 1.1.0 | [https://simplifier.net/ca-core](https://simplifier.net/ca-core) | Supportata | | | | | | X | | |
| CA:EREC Pan-Canadian Referral-eConsult | 1.1.0 | [https://simplifier.net/CA-eReC/~introduction](https://simplifier.net/CA-eReC/~introduction) | Supportata | | | | | | X | | |
| Sintesi del paziente, edizione canadese - (PS-CA) | 2.11 | [https://simplifier.net/PS-CA-R1/~introduction](https://simplifier.net/PS-CA-R1/~introduction) | Supportata | | | | | | X | | |
| Ontario Digital Health Drug Repository | 4.0.3 | [https://simplifier.net/ca-on-dhdr-r4/~introduction](https://simplifier.net/ca-on-dhdr-r4/~introduction) | Supportata | | | | | | X | | |
| Codice AU | 1.0.0 | [https://hl7.org.au/fhir/core/](https://hl7.org.au/fhir/core/) | Supportata | | | | | X | | | |
| Gestione pratica Magentus | 1.2.16 | [https://fhir-versions.dev.geniesolutions.io/1.2.16/downloads.html](https://fhir-versions.dev.geniesolutions.io/1.2.16/downloads.html) | Supportata | | | | | X | | | |
## Convalida dei profili FHIR specificati in una risorsa
Per convalidare un profilo FHIR, aggiungilo all'`profile`elemento delle singole risorse utilizzando l'URL del profilo indicato nella guida all'implementazione.
I profili FHIR vengono convalidati quando aggiungi una nuova risorsa al tuo archivio dati. Per aggiungere una nuova risorsa, puoi utilizzare l'operazione `StartFHIRImportJob` API, fare una `POST` richiesta per aggiungere una nuova risorsa o ` PUT ` aggiornare una risorsa esistente.
**Example — Per vedere a quale profilo FHIR viene fatto riferimento in una risorsa**
L'URL del profilo viene aggiunto all'`profile`elemento nella coppia `"meta" : "profile"` chiave-valore. Questa risorsa è stata troncata per motivi di chiarezza.
```
{
"resourceType": "Patient",
"id": "abcd1234efgh5678hijk9012",
"meta": {
"lastUpdated": "2023-05-30T00:48:07.8443764-07:00",
"profile": [
"http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient"
]
}
}
```
**Example — Come fare riferimento a un profilo FHIR supportato non predefinito**
Per eseguire la convalida rispetto a un profilo non predefinito supportato (ad esempio CarinBB 1.0.0), aggiungi l'URL del profilo con la versione (separato da '\$1') e l'URL del profilo di base nell'elemento. `meta.profile` Questa risorsa di esempio è stata troncata per motivi di chiarezza.
```
{
"resourceType": "ExplanationOfBenefit",
"id": "sample-EOB",
"meta": {
"lastUpdated": "2024-02-02T05:56:09.4+00:00",
"profile": [
"http://hl7.org/fhir/us/carin-bb/StructureDefinition/C4BB-ExplanationOfBenefit-Pharmacy|1.0.0",
"http://hl7.org/fhir/us/carin-bb/StructureDefinition/C4BB-ExplanationOfBenefit-Pharmacy“
]
}
}
```
# Tipi di risorse supportati da FHIR R4 per HealthLake
La tabella seguente elenca i tipi di risorse FHIR R4 supportati da. AWS HealthLake Per ulteriori informazioni, vedere [Resource Index nella documentazione](https://hl7.org/fhir/R4/resourcelist.html) **FHIR R4**.
**Tipi di risorse FHIR R4 supportati da HealthLake**
| | | | |
| --- |--- |--- |--- |
| Account | DetectedIssue | Fattura | Professionista |
| ActivityDefinition | Dispositivo | Libreria | PractitionerRole |
| AdverseEvent | DeviceDefinition | Collegamento | Procedura |
| AllergyIntolerance | DeviceMetric | List | Provenienza |
| Appuntamento | DeviceUseStatement | Location (Ubicazione) | Questionario |
| AppointmentResponse | DeviceRequest | Misura | QuestionnaireResponse |
| AuditEvent - Vedi nota | DiagnosticReport | MeasureReport | RelatedPerson |
| Binario | DocumentManifest | Media | RequestGroup |
| BodyStructure | DocumentReference | Farmaco | ResearchStudy |
| Pacchetto - Vedi nota | EffectEvidenceSynthesis | MedicationAdministration | ResearchSubject |
| CapabilityStatement | Incontro | MedicationDispense | RiskAssessment |
| CarePlan | Endpoint | MedicationKnowledge | RiskEvidenceSynthesis |
| CareTeam | EpisodeOfCare | MedicationRequest | Schedule |
| ChargeItem | EnrollmentRequest | MedicationStatement | ServiceRequest |
| ChargeItemDefinition | EnrollmentResponse | MessageHeader | Slot |
| Richiedi | ExplanationOfBenefit | MolecularSequence | Esemplare |
| ClaimResponse | FamilyMemberHistory | NutritionOrder | StructureDefinition |
| Communication | Flag | Osservazione | StructureMap |
| CommunicationRequest | Obiettivo | OperationOutcome - Vedi nota | Sostanza |
| Composizione | Gruppo | Organizzazione | SupplyDelivery |
| ConceptMap | GuidanceResponse | OrganizationAffiliation | SupplyRequest |
| Condizione | HealthcareService | Parametri - Vedi nota | Operazione |
| Consenso | ImagingStudy | Paziente | ValueSet |
| Contratto | Immunizzazione | PaymentNotice | VisionPrescription |
| Copertura | ImmunizationEvaluation | PaymentReconciliation | VerificationResult - Vedi nota |
| CoverageEligibilityRequest | ImmunizationRecommendation | Person | |
| CoverageEligibilityResponse | InsurancePlan | PlanDefinition | |
**Specifiche FHIR e HealthLake**
Non è possibile effettuare `GET` o `POST` richiedere con FHIR `OperationOutcome` e tipi di `Parameters` risorse.
**AuditEvent**— Una AuditEvent risorsa può essere creata o letta, ma non può essere aggiornata o eliminata.
**Bundle**: esistono diversi modi per HealthLake gestire le richieste Bundle. Per ulteriori dettagli, consultare [Raggruppamento di risorse FHIR](managing-fhir-resources-bundle.md).
**VerificationResult**— Questo tipo di risorsa è supportato solo per gli archivi dati creati dopo il 09 dicembre 2023.
# Parametri di ricerca FHIR R4 per HealthLake
Usa l'[https://hl7.org/fhir/R4/http.html#search](https://hl7.org/fhir/R4/http.html#search)interazione FHIR per cercare un set di risorse FHIR in un archivio HealthLake dati in base ad alcuni criteri di filtro. L'`search`interazione può essere eseguita utilizzando una richiesta `GET` or`POST`. Per le ricerche che coinvolgono informazioni di identificazione personale (PII) o informazioni sanitarie protette (PHI), si consiglia di utilizzare `POST` le richieste, poiché PII e PHI vengono aggiunti come parte del corpo della richiesta e vengono crittografati durante il transito.
**Nota**
L'`search`interazione FHIR descritta in questo capitolo è costruita in conformità allo standard FHIR R4 per lo HL7 scambio di dati sanitari. Poiché è una rappresentazione di un servizio HL7 FHIR, non viene offerto tramite e. AWS CLI AWS SDKs Per ulteriori informazioni, consulta la [https://hl7.org/fhir/R4/http.html#search](https://hl7.org/fhir/R4/http.html#search)documentazione dell'API **FHIR R4 RESTful **.
Puoi anche interrogare gli archivi HealthLake dati con SQL utilizzando Amazon Athena. Per ulteriori informazioni, consulta Integrazione.
HealthLake supporta il seguente sottoinsieme di parametri di ricerca FHIR R4. Per ulteriori informazioni, consulta [Parametri di ricerca FHIR R4 per HealthLake](#reference-fhir-search-parameters).
## Tipi di parametri di ricerca supportati
La tabella seguente mostra i tipi di parametri di ricerca supportati in HealthLake.
**Tipi di parametri di ricerca supportati**
| Parametro di ricerca | Description |
| --- | --- |
| \$1id | ID della risorsa (non un URL completo) |
| \$1Ultimo aggiornamento | Data ultimo aggiornamento. Il server ha discrezione sulla precisione dei limiti. |
| \$1etichetta | Cerca in base a un tag di risorsa. |
| \$1profilo | Cerca tutte le risorse contrassegnate con un profilo. |
| \$1sicurezza | Cerca sulle etichette di sicurezza applicate a questa risorsa. |
| \$1fonte | Cerca da dove proviene la risorsa. |
| \$1testo | Cerca nella narrazione della risorsa. |
| createdAt | Cerca sull'estensione personalizzata CreateDat. |
**Nota**
I seguenti parametri di ricerca sono supportati solo per i datastore creati dopo il 09 dicembre 2023: \$1security, \$1source, \$1text, CreateDat.
La tabella seguente mostra esempi di come modificare le stringhe di query in base a tipi di dati specificati per un determinato tipo di risorsa. Per maggiore chiarezza, i caratteri speciali nella colonna degli esempi non sono stati codificati. Per eseguire correttamente una query, assicuratevi che la stringa di query sia stata codificata correttamente.
**Esempi di parametri di ricerca**
| Tipi di parametri di ricerca | Informazioni | Esempi |
| --- | --- | --- |
| Numero | Cerca un valore numerico in una risorsa specificata. Si osservano cifre significative. Il numero di cifre significative è specifico in base al valore del parametro di ricerca, esclusi gli zeri iniziali. I prefissi di confronto sono consentiti. | `[parameter]=100` `[parameter]=1e2` `[parameter]=lt100` |
| Data/ DateTime | Cerca una data o un'ora specifica. Il formato previsto è `yyyy-mm-ddThh:mm:ss[Z\|(+\|-)hh:mm]` ma può variare. Accetta i seguenti tipi di dati: `date``dateTime`,`instant`,`Period`, e`Timing`. Per maggiori dettagli sull'utilizzo di questi tipi di dati nelle ricerche, consulta la [data nella documentazione](https://www.hl7.org/fhir/search.html#date) dell'API **FHIR R4 RESTful **. I prefissi di confronto sono consentiti. | `[parameter]=eq2013-01-14` `[parameter]=gt2013-01-14T10:00` `[parameter]=ne2013-01-14` |
| Stringa | Cerca una sequenza di caratteri con distinzione tra maiuscole e minuscole. Supporta entrambi i tipi`HumanName`. `Address` Per ulteriori dettagli, vedere la voce relativa al [tipo di HumanName dati](https://www.hl7.org/fhir/datatypes.html#HumanName) e le voci relative al [tipo di `Address` dati](https://www.hl7.org/fhir/datatypes.html#Address) nella documentazione **FHIR R4**. La ricerca avanzata è supportata tramite `:text` modificatori. | `[base]/Patient?given=eve` `[base]/Patient?given:contains=eve` |
| Token | Cerca una close-to-exact corrispondenza in base a una stringa di caratteri, spesso confrontata con un paio di valori di codice medico. La distinzione tra maiuscole e minuscole è collegata al sistema di codice utilizzato durante la creazione di una query.Le query basate su Subsumption possono aiutare a ridurre i problemi legati alla distinzione tra maiuscole e minuscole. Per chiarezza non è stato codificato. `\|` | `[parameter]=[system]\|[code]`: Qui `[system]` si riferisce a un sistema di codifica e si `[code]` riferisce al valore di codice trovato all'interno di quel sistema specifico. `[parameter]=[code]`: Qui il tuo input corrisponderà a un codice o a un sistema. `[parameter]=\|[code]`: Qui il tuo input corrisponderà a un codice e la proprietà del sistema non ha un identificatore. |
| Composita | Cerca più parametri all'interno di un singolo tipo di risorsa, utilizzando i modificatori e l'operazione`$`. `,` I prefissi di confronto sono consentiti. | `/Patient?language=FR,NL&language=EN` `Observation?component-code-value-quantity=http://loinc.org\|8480-6$lt60` `[base]/Group?characteristic-value=gender$mixed` |
| Quantità | Cerca un numero, un sistema e un codice come valori. È richiesto un numero, ma il sistema e il codice sono facoltativi. In base al tipo di dati sulla quantità. Per ulteriori dettagli, vedere [Quantity](https://www.hl7.org/fhir/datatypes.html#Quantity) nella documentazione **FHIR R4**. Utilizza la seguente sintassi presunta `[parameter]=[prefix][number]\|[system]\|[code]` | `[base]/Observation?value-quantity=5.4\|http://unitsofmeasure.org\|mg` `[base]/Observation?value-quantity=5.4\|http://unitsofmeasure.org\|mg` `[base]/Observation?value-quantity=5.4\|http://unitsofmeasure.org\|mg` `[base]/Observation?value-quantity=le5.4\|http://unitsofmeasure.org\|mg` |
| Documentazione di riferimento | Cerca riferimenti ad altre risorse. | `[base]/Observation?subject=Patient/23` `test` |
| URI | Cerca una stringa di caratteri che identifichi in modo inequivocabile una particolare risorsa. | `[base]/ValueSet?url=http://acme.org/fhir/ValueSet/123` |
| Speciale | Ricerche basate su estensioni NLP mediche integrate. |
## Parametri di ricerca avanzati supportati da HealthLake
HealthLake supporta i seguenti parametri di ricerca avanzata.
| Nome | Descrizione | Esempio | Funzionalità |
| --- | --- | --- | --- |
| \$1include | Utilizzato per richiedere la restituzione di risorse aggiuntive in una richiesta di ricerca. Restituisce risorse a cui fa riferimento l'istanza della risorsa di destinazione. | Encounter?\$1include=Encounter:subject | |
| \$1revinclude | Utilizzato per richiedere la restituzione di risorse aggiuntive in una richiesta di ricerca. Restituisce risorse che fanno riferimento all'istanza della risorsa principale. | Patient?\$1id=patient-identifier&\$1revinclude=Encounter:patient | |
| \$1summary | Il riepilogo può essere utilizzato per richiedere un sottoinsieme della risorsa. | Patient?\$1summary=text | Sono supportati i seguenti parametri di riepilogo:\$1summary=true,\$1summary=false,\$1summary=text,\$1summary=data. |
| \$1elements | Richiedi la restituzione di un set specifico di elementi come parte di una risorsa nei risultati della ricerca. | Patient?\$1elements=identifier,active,link | |
| \$1total | Restituisce il numero di risorse che corrispondono ai parametri di ricerca. | Patient?\$1total=accurate | Support\$1total=accurate,\$1total=none. |
| \$1sort | Indica l'ordinamento dei risultati di ricerca restituiti utilizzando un elenco separato da virgole. Il - prefisso può essere utilizzato per qualsiasi regola di ordinamento nell'elenco separato da virgole per indicare l'ordine decrescente. | Observation?\$1sort=status,-date | Supporta l'ordinamento per campi con tipiNumber, String, Quantity, Token, URI, Reference. L'ordinamento per Date è supportato solo per gli archivi dati creati dopo il 09 dicembre 2023. Supporta fino a 5 regole di ordinamento. |
| \$1count | Controlla quante risorse vengono restituite per pagina del pacchetto di ricerca. | Patient?\$1count=100 | La dimensione massima della pagina è 100. |
| chaining | Elementi di ricerca delle risorse referenziate. .Indirizza la ricerca concatenata all'elemento all'interno della risorsa referenziata. | DiagnosticReport?subject:Patient.name=peter | |
| reverse chaining (\$1has) | Cerca una risorsa in base agli elementi delle risorse che le fanno riferimento. | Patient?\$1has:Observation:patient:code=1234-5 | |
`_include`
L'utilizzo `_include` in una query di ricerca consente di restituire anche risorse FHIR aggiuntive specificate. `_include`Da utilizzare per includere risorse collegate in avanti.
**Example — Da utilizzare `_include` per trovare i pazienti o il gruppo di pazienti a cui è stata diagnosticata la tosse**
È possibile eseguire la ricerca in base al tipo di `Condition` risorsa specificando il codice diagnostico per la tosse e quindi utilizzando `_include` specificare che si desidera che venga restituita anche la `subject` diagnosi. Nel tipo di `Condition` risorsa `subject` si riferisce al tipo di risorsa per il paziente o al tipo di risorsa del gruppo.
Per maggiore chiarezza, i caratteri speciali dell'esempio non sono stati codificati. Per eseguire correttamente una query, assicuratevi che la stringa di query sia stata codificata correttamente.
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/
Condition?code=49727002&_include=Condition:subject
```
`_include:iterate`Modificatore
Il `_include:iterate` modificatore consente l'inclusione ricorsiva delle risorse referenziate su due livelli. Ad esempio,
```
GET /ServiceRequest?identifier=025C0931195&_include=ServiceRequest:requester&_include:iterate=PractitionerRole:practitioner
```
restituirà il ServiceRequest, è associato PractitionerRole (tramite il riferimento del richiedente) e quindi includerà in modo ricorsivo il Practitioner a cui fa riferimento. PractitionerRole Questo modificatore è disponibile per tutti i tipi di risorse in. HealthLake
`_include=*`Modificatore
Il `_include=*` modificatore è un jolly che include automaticamente tutte le risorse a cui fanno riferimento direttamente i risultati della ricerca. Ad esempio,
```
GET /ServiceRequest?specimen.accession=12345&_include=*
```
restituirà la corrispondenza ServiceRequest insieme a tutte le risorse a cui fa riferimento (come Patient, Practitioner, Specimen, ecc.) senza dover specificare ogni percorso di riferimento singolarmente. Questo modificatore è disponibile per tutti i tipi di risorse in. HealthLake
`_revinclude`
L'utilizzo `_revinclude` in una query di ricerca consente di restituire anche risorse FHIR aggiuntive specificate. `_revinclude`Da utilizzare per includere risorse collegate all'indietro.
**Example — Da utilizzare `_revinclude` per includere tipi di risorse correlate all'incontro e all'osservazione collegate a un paziente specifico**
Per effettuare questa ricerca, è necessario innanzitutto definire la persona `Patient` specificando il suo identificatore nel parametro di `_id` ricerca. Quindi è necessario specificare risorse FHIR aggiuntive utilizzando la struttura e. `Encounter:patient` `Observation:patient`
Per maggiore chiarezza, i caratteri speciali dell'esempio non sono stati codificati. Per eseguire correttamente una query, assicuratevi che la stringa di query sia stata codificata correttamente.
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/
Patient?_id=patient-identifier&_revinclude=Encounter:patient&_revinclude=Observation:patient
```
`_summary`
L'utilizzo `_summary` in una query di ricerca consente all'utente di richiedere un sottoinsieme della risorsa FHIR. Può contenere uno dei seguenti valori:. `true, text, data, false` Qualsiasi altro valore verrà considerato non valido. Le risorse restituite verranno contrassegnate con `'SUBSETTED'` meta.tag, per indicare che le risorse sono incomplete.
+ `true`: Restituisce tutti gli elementi supportati contrassegnati come «riepilogo» nella definizione di base delle risorse.
+ `text`: restituisce solo gli elementi 'text', 'id', 'meta' e solo gli elementi obbligatori di primo livello.
+ `data`: restituisce tutte le parti tranne l'elemento 'text'.
+ `false`: restituisce tutte le parti delle risorse
In una singola richiesta di ricerca, `_summary=text` non può essere combinato con i `_include` nostri parametri `_revinclude` di ricerca.
**Example — Ottieni l'elemento «testuale» delle risorse per i pazienti in un archivio dati.**
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient?_summary=text
```
`_elements`
L'utilizzo `_elements` in una query di ricerca consente di richiedere elementi di risorse FHIR specifici. Le risorse restituite verranno contrassegnate con `'SUBSETTED'` meta.tag, per indicare che le risorse sono incomplete.
Il `_elements` parametro è costituito da un elenco separato da virgole di nomi di elementi di base, come gli elementi definiti al livello principale della risorsa. Devono essere restituiti solo gli elementi elencati. Se i valori dei `_elements` parametri contengono elementi non validi, il server li ignorerà e restituirà elementi obbligatori e elementi validi.
`_elements`non sarà applicabile alle risorse incluse (risorse restituite la cui modalità di ricerca è`include`).
In una singola richiesta di ricerca, `_elements` non può essere combinato con i parametri `_summary` di ricerca.
**Example — Ottieni elementi «identificativi», «attivi» e «link» delle risorse per i pazienti nel tuo archivio HealthLake dati.**
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient?_elements=identifier,active,link
```
`_total`
L'utilizzo `_total` in una query di ricerca restituirà il numero di risorse che corrispondono ai parametri di ricerca richiesti. HealthLake restituirà il numero totale di risorse corrispondenti (risorse restituite la cui modalità di ricerca è`match`) nella risposta `Bundle.total` di ricerca.
`_total`supporta i valori dei `none` parametri`accurate`,. `_total=estimate`non è supportato. Tutti gli altri valori verranno considerati non validi. `_total`non è applicabile alle risorse incluse (risorse restituite la cui modalità di ricerca è`include`).
**Example — Ottieni il numero totale di risorse per i pazienti in un archivio dati:**
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient?_total=accurate
```
`_sort`
L'utilizzo `_sort` nella query di ricerca ordina i risultati in un ordine specifico. I risultati vengono ordinati in base all'elenco di regole di ordinamento separate da virgole in ordine di priorità. Le regole di ordinamento devono essere parametri di ricerca validi. Tutti gli altri valori verranno considerati non validi.
In una singola richiesta di ricerca, puoi utilizzare fino a 5 parametri di ricerca di ordinamento. Facoltativamente, puoi utilizzare un `-` prefisso per indicare l'ordine decrescente. Per impostazione predefinita, il server ordinerà in ordine crescente.
I tipi di parametri di ricerca di ordinamento supportati sono:`Number, String, Date, Quantity, Token, URI, Reference`. Se un parametro di ricerca si riferisce a un elemento annidato, questo parametro di ricerca non è supportato per l'ordinamento. Ad esempio, la ricerca in base al «nome» del tipo di risorsa Patient si riferisce a Patient.name. L'elemento con tipo di HumanName dati è considerato annidato. Pertanto, l'ordinamento delle risorse del paziente per «nome» non è supportato.
**Example — Ottieni le risorse per i pazienti in un archivio dati e ordinale per data di nascita in ordine crescente:**
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient?_sort=birthdate
```
`_count`
Il parametro `_count` è definito come un'istruzione al server relativa a quante risorse devono essere restituite in una singola pagina.
La dimensione massima della pagina è 100. Qualsiasi valore superiore a 100 non è valido. `_count=0`non è supportato.
**Example — Cerca la risorsa Patient e imposta la dimensione della pagina di ricerca su 25:**
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient?_count=25
```
`Chaining and Reverse Chaining(_has)`
Il concatenamento e il concatenamento inverso in FHIR offrono un modo più efficiente e compatto per ottenere dati interconnessi, riducendo la necessità di più query separate e rendendo il recupero dei dati più comodo per sviluppatori e utenti.
Se un livello di ricorsione restituisce più di 100 risultati, HealthLake restituirà 4xx per proteggere l'archivio dati dal sovraccarico e dalla causa di più impaginazioni.
**Example — Concatenamento: ottiene tutto ciò DiagnosticReport che si riferisce a un paziente il cui nome del paziente è peter.**
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/DiagnosticReport?subject:Patient.name=peter
```
**Example — Reverse Chaining - Get Patient Resources, dove la risorsa relativa al paziente viene indicata da almeno un'osservazione, dove l'osservazione ha il codice 1234 e dove l'osservazione si riferisce alla risorsa del paziente nel parametro di ricerca del paziente.**
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient?_has:Observation:patient:code=1234
```
## Modificatori di ricerca supportati
I modificatori di ricerca vengono utilizzati con i campi basati su stringhe. Tutti i modificatori di ricerca utilizzano una logica basata su booleani. HealthLake Ad esempio, è possibile specificare di `:contains` specificare che il campo stringa più grande deve includere una stringa piccola per poterla includere nei risultati della ricerca.
**Modificatori di ricerca supportati**
| Modificatore di ricerca | Tipo |
| --- | --- |
| : mancante | Tutti i parametri tranne Composite |
| : esatto | Stringa |
| :contiene | Stringa |
| :non | Token |
| :testo | Token |
| :identificatore | Documentazione di riferimento |
| : sotto | URI |
## Comparatori di ricerca supportati
È possibile utilizzare i comparatori di ricerca per controllare la natura della corrispondenza in una ricerca. È possibile utilizzare i comparatori durante la ricerca nei campi relativi a numeri, date e quantità. La tabella seguente elenca i comparatori di ricerca e le relative definizioni supportati da. HealthLake
**Comparatori di ricerca supportati**
| Comparatore di ricerca | Description |
| --- | --- |
| eq | Il valore del parametro nella risorsa è uguale al valore fornito. |
| uno | Il valore del parametro nella risorsa non è uguale al valore fornito. |
| gt | Il valore del parametro nella risorsa è maggiore del valore fornito. |
| lt | Il valore del parametro nella risorsa è inferiore al valore fornito. |
| età | Il valore del parametro nella risorsa è maggiore o uguale al valore fornito. |
| le | Il valore del parametro nella risorsa è inferiore o uguale al valore fornito. |
| come | Il valore del parametro nella risorsa inizia dopo il valore fornito. |
| eb | Il valore del parametro nella risorsa termina prima del valore fornito. |
## Parametri di ricerca FHIR non supportati da HealthLake
HealthLake supporta tutti i parametri di ricerca FHIR ad eccezione di quelli elencati nella tabella seguente. Per un elenco completo dei parametri di ricerca FHIR, consultate il registro dei parametri di [ricerca FHIR](https://hl7.org/fhir/R4/searchparameter-registry.html).
**Parametri di ricerca non supportati**
| | |
| --- |--- |
| Composizione del pacchetto | Ubicazione: vicino |
| Identificatore del pacchetto | C onsent-source-reference |
| Messaggio del pacchetto | Paziente a contratto |
| Tipo di pacchetto | Contenuto delle risorse |
| Timestamp del pacchetto | Interrogazione delle risorse |
# FHIR R4 per `$operations` HealthLake
Le operazioni FHIR \$1 (chiamate anche «operazioni in dollari») sono funzioni speciali lato server che vanno oltre le operazioni CRUD standard (`Create`,, `Read``Update`,`Delete`) previste dalle specifiche FHIR. Queste operazioni sono identificate dal prefisso «\$1» e consentono l'elaborazione complessa, la trasformazione dei dati e operazioni di massa che sarebbero difficili o inefficienti da eseguire utilizzando chiamate API REST standard. \$1 Le operazioni possono essere richiamate a livello di sistema, a livello di tipo di risorsa o su istanze di risorse specifiche, fornendo modi flessibili per interagire con i dati FHIR. AWS HealthLake supporta più FHIR. `$operations` Si prega di fare riferimento a ogni singola pagina di seguito per ulteriori dettagli.
**Topics**
+ [Funzionamento FHIR R4 `$attribution-status` per HealthLake](reference-fhir-operations-attribution-status.md)
+ [Eliminazione dei tipi di risorse con `$bulk-delete`](reference-fhir-operations-bulk-delete.md)
+ [`$bulk-member-match`operazione per HealthLake](reference-fhir-operations-bulk-member-match.md)
+ [Funzionamento FHIR R4 `$confirm-attribution-list` per HealthLake](reference-fhir-operations-confirm-attribution-list.md)
+ [Funzionamento FHIR R4 `$davinci-data-export` per HealthLake](reference-fhir-operations-davinci-data-export.md)
+ [Generazione di documenti clinici con `$document`](reference-fhir-operations-document.md)
+ [Rimozione permanente di risorse con `$erase`](reference-fhir-operations-erase.md)
+ [Acquisizione dei dati dei pazienti con `Patient/$everything`](reference-fhir-operations-everything.md)
+ [Recupero dei codici con ValueSet `$expand`](reference-fhir-operations-expand.md)
+ [Esportazione di HealthLake dati con FHIR `$export`](reference-fhir-operations-export.md)
+ [`$inquire`Operazione FHIR per HealthLake](reference-fhir-operations-inquire.md)
+ [Recupero dei dettagli concettuali con `$lookup`](reference-fhir-operations-lookup.md)
+ [`$member-add`operazione per HealthLake](reference-fhir-operations-member-add.md)
+ [`$member-match`operazione per HealthLake](reference-fhir-operations-member-match.md)
+ [`$member-remove`operazione per HealthLake](reference-fhir-operations-member-remove.md)
+ [Eliminazione delle risorse del comparto paziente con `$purge`](reference-fhir-operations-purge.md)
+ [`$questionnaire-package`Operazione FHIR per HealthLake](reference-fhir-operations-questionnaire-package.md)
+ [`$submit`Operazione FHIR per HealthLake](reference-fhir-operations-submit.md)
+ [Convalida delle risorse FHIR con `$validate`](reference-fhir-operations-validate.md)
# Funzionamento FHIR R4 `$attribution-status` per HealthLake
Recupera lo stato di attribuzione di un membro specifico, restituendo un pacchetto contenente tutte le risorse di attribuzione relative al paziente. Questa operazione fa parte dell'implementazione [FHIR Member Attribution (ATR](https://build.fhir.org/ig/HL7/davinci-atr/spec.html)) List IG 2.1.0.
## Endpoint
```
POST [base]/Group/[id]/$attribution-status
```
## Parametri della richiesta
L'operazione accetta i seguenti parametri opzionali:
| Parametro | Tipo | Description |
| --- | --- | --- |
| memberId | Identificatore | Il MemberId membro per il quale è richiesto lo stato di attribuzione |
| Riferimento per il paziente | Documentazione di riferimento | Riferimento alla risorsa per i pazienti nel sistema del produttore |
**Nota**
`memberId`O `patientReference` può essere fornito, o entrambi a scopo di convalida.
## Richiesta di esempio
```
{
"resourceType": "Parameters",
"parameter": [
{
"name": "memberId",
"valueIdentifier": {
"system": "http://example.org",
"value": "MBR123456789"
}
},
{
"name": "patientReference",
"valueReference": {
"reference": "Patient/patient-123",
"display": "John Doe"
}
}
]
}
```
## Risposta
Restituisce un pacchetto contenente risorse di attribuzione relative al paziente:
| Risorsa | Cardinalità | Location (Ubicazione) |
| --- | --- | --- |
| Paziente | 1..1 | Group.Member.Entity |
| Copertura | 0.1.. | group.member.extension: CoverageReference |
| Organization/Practitioner/PractitionerRole | 0.1.. | group.member.extension: AttributedProvider |
| Qualsiasi risorsa | 0.1.. | group.member.extension: dati associati |
### Risposta di esempio
```
{
"resourceType": "Bundle",
"id": "bundle-response",
"meta": {
"lastUpdated": "2014-08-18T01:43:33Z"
},
"type": "collection",
"entry": [
{
"fullUrl": "http://example.org/fhir/Patient/12423",
"resource": {
"resourceType": "Patient",
"id": "12423",
"meta": {
"versionId": "1",
"lastUpdated": "2014-08-18T01:43:31Z"
},
"active": true,
"name": [
{
"use": "official",
"family": "Chalmers",
"given": ["Peter", "James"]
}
],
"gender": "male",
"birthDate": "1974-12-25"
}
},
{
"fullUrl": "http://example.org/fhir/Coverage/123456",
"resource": {
"resourceType": "Coverage",
"id": "1"
// ... additional Coverage resource details
}
},
{
"fullUrl": "http://example.org/fhir/Organization/666666",
"resource": {
"resourceType": "Organization",
"id": "2"
// ... additional Organization resource details
}
}
]
}
```
## Gestione errori
L'operazione gestisce le seguenti condizioni di errore:
| Errore | Stato HTTP | Description |
| --- | --- | --- |
| Richiesta di operazione non valida | 400 | Parametri o struttura della richiesta non conformi |
| Risorsa di gruppo non trovata | 404 | L'ID di gruppo specificato non esiste |
| Risorsa per il paziente non trovata | 404 | Il riferimento del paziente specificato non esiste |
## Autorizzazione e sicurezza
Requisiti di SMART
I clienti devono disporre dei privilegi appropriati per leggere le risorse del Gruppo e le relative risorse di attribuzione
I meccanismi di autorizzazione FHIR standard si applicano a tutte le operazioni
# Eliminazione dei tipi di risorse con `$bulk-delete`
AWS HealthLake supporta l'`$bulk-delete`operazione, abilitando l'eliminazione di tutte le risorse di un tipo specifico all'interno di un datastore. Questa operazione è particolarmente utile quando è necessario:
+ Effettuare verifiche e pulizie stagionali
+ Gestisci il ciclo di vita dei dati su larga scala
+ Rimuovi tipi di risorse specifici
+ Rispetta le politiche di conservazione dei dati
## Utilizzo
L'`$bulk-delete`operazione può essere richiamata utilizzando i metodi POST:
```
POST [base]/[ResourceType]/$bulk-delete?isHardDelete=false&deleteAuditEvent=true
```
## Parameters
| Parametro | Tipo | Obbligatorio | Predefinita | Description |
| --- | --- | --- | --- | --- |
| isHardDelete | booleano | No | false | Se impostato su true, rimuove definitivamente le risorse dallo storage |
| deleteAuditEvent | booleano | No | true | Se impostato su true, elimina gli eventi di controllo associati |
| \$1since | stringa | No | Ora di creazione del datastore | Una volta inserito, seleziona l'orario limite iniziale per trovare le risorse in base all'ora dell'ultima modifica. Non può essere utilizzato con start o end |
| start | stringa | No | Ora di creazione del datastore | Una volta inserito, seleziona l'orario limite per la ricerca delle risorse in base all'ora dell'ultima modifica. Può essere usato con fine |
| end | stringa | No | Ora di invio del lavoro | Una volta inserito, seleziona l'orario limite finale per trovare le risorse in base all'ora dell'ultima modifica |
## Esempi
**Richiesta di esempio**
```
POST [base]/Observation/$bulk-delete?isHardDelete=false
```
**Risposta di esempio**
```
{
"jobId": "jobId",
"jobStatus": "SUBMITTED"
}
```
## Stato di un processo
Per verificare lo stato di un processo di eliminazione in blocco:
```
GET [base]/$bulk-delete/[jobId]
```
L'operazione restituisce informazioni sullo stato del lavoro:
```
{
"datastoreId": "datastoreId",
"jobId": "jobId",
"status": "COMPLETED",
"submittedTime": "2025-10-09T15:09:51.336Z"
}
```
## Comportamento
L'`$bulk-delete`operazione:
1. Processi in modo asincrono per gestire grandi volumi di risorse
1. Mantiene le transazioni ACID per l'integrità dei dati
1. Fornisce il monitoraggio dello stato del lavoro con il conteggio delle eliminazioni delle risorse
1. Supporta sia la modalità di cancellazione temporanea che quella definitiva
1. Include una registrazione di controllo completa delle attività di eliminazione
1. Consente l'eliminazione selettiva delle versioni storiche e degli eventi di controllo
## Registrazione di audit
Le `$bulk-delete` operazioni vengono registrate come Start FHIRBulk DeleteJob e Descrivi FHIRBulk DeleteJob con informazioni dettagliate sull'operazione.
## Limitazioni
+ Se `isHardDelete` è impostata su true, le risorse eliminate definitivamente non verranno visualizzate nei risultati di ricerca o nelle query. `_history`
+ Le risorse eliminate tramite questa operazione potrebbero essere temporaneamente inaccessibili durante l'elaborazione
+ La misurazione dello storage viene regolata solo in base alle versioni storiche: deleteVersionHistory =false non aggiusterà lo storage del datastore
# `$bulk-member-match`operazione per HealthLake
AWS HealthLake supporta l'`$bulk-member-match`operazione per l'elaborazione asincrona delle richieste di abbinamento di più membri. Questa operazione consente alle organizzazioni sanitarie di abbinare in modo efficiente gli identificatori univoci di centinaia di membri di diversi sistemi sanitari utilizzando informazioni demografiche e di copertura in un'unica richiesta di massa. [Questa funzionalità è essenziale per lo scambio di payer-to-payer dati su larga scala, le transizioni tra i membri e i requisiti di conformità CMS e segue le specifiche FHIR.](https://build.fhir.org/ig/HL7/davinci-epdx/OperationDefinition-BulkMemberMatch.html)
**Nota**
L'`$bulk-member-match`operazione si basa su una specifica FHIR sottostante che è attualmente sperimentale e soggetta a modifiche. Man mano che le specifiche si evolvono, il comportamento e l'interfaccia di questa API verranno aggiornati di conseguenza. Si consiglia agli sviluppatori di monitorare le note di HealthLake rilascio di AWS e gli aggiornamenti delle specifiche FHIR pertinenti per rimanere informati su eventuali modifiche che potrebbero influire sulle loro integrazioni.
Questa operazione è particolarmente utile quando è necessario:
+ Elaborare l'abbinamento dei membri su larga scala durante i periodi di iscrizione aperti
+ Facilita le transizioni di massa dei membri tra i paganti
+ Supporta i requisiti di scambio di dati di conformità CMS su larga scala
+ Abbina in modo efficiente le coorti di membri attraverso le reti sanitarie
+ Riduci al minimo le chiamate API e migliora l'efficienza operativa per scenari di abbinamento ad alto volume
## Utilizzo
L'`$bulk-member-match`operazione è un'operazione asincrona richiamata sulle risorse del gruppo utilizzando il metodo POST:
```
POST [base]/Group/$bulk-member-match
```
Dopo aver inviato una richiesta di corrispondenza in blocco, puoi verificare lo stato del lavoro utilizzando:
```
GET [base]/$bulk-member-match-status/{jobId}
```
## Parametri supportati
HealthLake supporta i seguenti parametri FHIR: `$bulk-member-match`
| Parametro | Tipo | Campo obbligatorio | Description |
| --- | --- | --- | --- |
| `MemberPatient` | Paziente | Sì | Risorsa per il paziente contenente informazioni demografiche relative al membro da abbinare. |
| `CoverageToMatch` | Copertura | Sì | Risorsa di copertura che verrà utilizzata per il confronto con i record esistenti. |
| `CoverageToLink` | Copertura | No | Risorsa di copertura da collegare durante il processo di abbinamento. |
| `Consent` | Consenso | Sì | Viene inoltre memorizzata la risorsa di consenso a fini di autorizzazione. Questa operazione è diversa dalla singola `$member-match` operazione in cui *non* è richiesto il consenso. |
## Richiesta POST per inviare in blocco un'offerta di lavoro abbinata a un membro
L'esempio seguente mostra una richiesta POST per inviare un lavoro collettivo riservato ai membri. Ogni membro è racchiuso in un `MemberBundle` parametro contenente le risorse obbligatorie e `Consent` le risorse `MemberPatient``CoverageToMatch`, oltre a un parametro opzionale. `CoverageToLink`
```
POST [base]/Group/$bulk-member-match
Content-Type: application/fhir+json
{
"resourceType": "Parameters",
"parameter": [
{
"name": "MemberBundle",
"part": [
{
"name": "MemberPatient",
"resource": {
"resourceType": "Patient",
"identifier": [
{
"system": "http://example.org/patient-id",
"value": "patient-0"
}
],
"name": [
{
"family": "Smith",
"given": ["James"]
}
],
"gender": "male",
"birthDate": "1950-01-01"
}
},
{
"name": "CoverageToMatch",
"resource": {
"resourceType": "Coverage",
"status": "active",
"identifier": [
{
"system": "http://example.org/coverage-id",
"value": "cov-0"
}
],
"subscriberId": "sub-0",
"beneficiary": {
"reference": "Patient/patient123"
},
"relationship": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/subscriber-relationship",
"code": "self"
}
]
},
"payor": [
{
"reference": "Organization/org123"
}
]
}
},
{
"name": "Consent",
"resource": {
"resourceType": "Consent",
"status": "active",
"scope": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/consentscope",
"code": "patient-privacy"
}
]
},
"category": [
{
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/v3-ActCode",
"code": "IDSCL"
}
]
}
],
"patient": {
"reference": "Patient/patient123"
},
"performer": [
{
"reference": "Patient/patient123"
}
],
"sourceReference": {
"reference": "http://example.org/DocumentReference/consent-source"
},
"policy": [
{
"uri": "http://hl7.org/fhir/us/davinci-hrex/StructureDefinition-hrex-consent.html#regular"
}
],
"provision": {
"type": "permit",
"period": {
"start": "2024-01-01",
"end": "2025-12-31"
},
"actor": [
{
"role": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/provenance-participant-type",
"code": "performer"
}
]
},
"reference": {
"identifier": {
"system": "http://hl7.org/fhir/sid/us-npi",
"value": "9876543210"
},
"display": "Old Health Plan"
}
},
{
"role": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/v3-ParticipationType",
"code": "IRCP"
}
]
},
"reference": {
"identifier": {
"system": "http://hl7.org/fhir/sid/us-npi",
"value": "0123456789"
},
"display": "New Health Plan"
}
}
],
"action": [
{
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/consentaction",
"code": "disclose"
}
]
}
]
}
}
},
{
"name": "CoverageToLink",
"resource": {
"resourceType": "Coverage",
"status": "active",
"identifier": [
{
"system": "http://example.org/coverage-link-id",
"value": "cov-link-0"
}
],
"subscriberId": "new-sub-0",
"beneficiary": {
"reference": "Patient/patient123"
},
"relationship": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/subscriber-relationship",
"code": "self"
}
]
},
"payor": [
{
"identifier": {
"system": "http://hl7.org/fhir/sid/us-npi",
"value": "0123456789"
},
"display": "New Health Plan"
}
]
}
}
]
}
]
}
```
## Risposta al lavoro completata con output
Una volta completato il lavoro, la risposta include i metadati del lavoro e una risorsa FHIR Parameters contenente tre risorse di gruppo che classificano i risultati delle partite.
```
{
"datastoreId": "datastoreId",
"jobId": "jobId",
"status": "COMPLETED",
"submittedTime": "2026-03-20T18:45:26.321Z",
"numberOfMembers": 3,
"numberOfMembersProcessedSuccessfully": 3,
"numberOfMembersWithCustomerError": 0,
"numberOfMembersWithServerError": 0,
"output": {
"resourceType": "Parameters",
"meta": {
"profile": [
"http://hl7.org/fhir/us/davinci-pdex/StructureDefinition/pdex-parameters-multi-member-match-bundle-out"
]
},
"parameter": [
{
"name": "MatchedMembers",
"resource": {
"resourceType": "Group",
"id": "group1",
"text": {
"status": "generated",
"div": "Matched members group
"
},
"contained": [
{
"resourceType": "Patient",
"id": "1",
"identifier": [
{
"system": "http://example.org/patient-id",
"value": "patient-0"
}
],
"name": [
{
"family": "Smith",
"given": ["James"]
}
],
"gender": "male",
"birthDate": "1950-01-01"
}
],
"type": "person",
"actual": true,
"code": {
"coding": [
{
"system": "http://hl7.org/fhir/us/davinci-pdex/CodeSystem/PdexMultiMemberMatchResultCS",
"code": "match",
"display": "Matched"
}
]
},
"quantity": 1,
"member": [
{
"entity": {
"extension": [
{
"url": "http://hl7.org/fhir/us/davinci-pdex/StructureDefinition/base-ext-match-parameters",
"valueReference": {
"reference": "#1"
}
}
],
"reference": "Patient/patient123"
}
}
]
}
},
{
"name": "NonMatchedMembers",
"resource": {
"resourceType": "Group",
"id": "Group2",
"text": {
"status": "generated",
"div": "Non-matched members group
"
},
"contained": [
{
"resourceType": "Patient",
"id": "1",
"identifier": [
{
"system": "http://example.org/patient-id",
"value": "patient-501"
}
],
"name": [
{
"family": "Carter",
"given": ["Emily"]
}
],
"gender": "female",
"birthDate": "1985-06-15"
}
],
"type": "person",
"actual": true,
"code": {
"coding": [
{
"system": "http://hl7.org/fhir/us/davinci-pdex/CodeSystem/PdexMultiMemberMatchResultCS",
"code": "nomatch",
"display": "Not Matched"
}
]
},
"quantity": 1,
"member": [
{
"entity": {
"extension": [
{
"url": "http://hl7.org/fhir/us/davinci-pdex/StructureDefinition/base-ext-match-parameters",
"valueReference": {
"reference": "#1"
}
}
],
"reference": "Patient/patient123"
}
}
]
}
},
{
"name": "ConsentConstrainedMembers",
"resource": {
"resourceType": "Group",
"id": "group3",
"text": {
"status": "generated",
"div": "Consent constrained members group
"
},
"contained": [
{
"resourceType": "Patient",
"id": "1",
"identifier": [
{
"system": "http://example.org/patient-id",
"value": "patient-502"
}
],
"name": [
{
"family": "Nguyen",
"given": ["David"]
}
],
"gender": "male",
"birthDate": "1972-11-22"
}
],
"type": "person",
"actual": true,
"code": {
"coding": [
{
"system": "http://hl7.org/fhir/us/davinci-pdex/CodeSystem/PdexMultiMemberMatchResultCS",
"code": "consentconstraint",
"display": "Consent Constraint"
}
]
},
"quantity": 1,
"member": [
{
"entity": {
"extension": [
{
"url": "http://hl7.org/fhir/us/davinci-pdex/StructureDefinition/base-ext-match-parameters",
"valueReference": {
"reference": "#1"
}
}
],
"reference": "Patient/123"
}
}
]
}
}
]
}
}
```
## Risorse di Output Group
Il lavoro completato restituisce una risorsa Parameters contenente tre risorse di gruppo:
**MatchedMembers Group** (Gruppo)
Contiene i riferimenti dei pazienti per tutti i membri abbinati correttamente e non è classificato come vincolo di consenso.
Il `Group.quantity` campo contiene il numero totale di membri in ciascuno dei rispettivi gruppi.
**NonMatchedMembers Group** (Gruppo)
Contiene riferimenti ai membri per i quali non è stata trovata alcuna corrispondenza o sono state identificate più corrispondenze.
**ConsentConstrainedMembers Group** (Gruppo)
Contiene i riferimenti dei pazienti per tutti i membri abbinati correttamente, laddove i vincoli di consenso impediscano la condivisione dei dati. Una risorsa di consenso è considerata limitata quando sono presenti entrambe le seguenti condizioni:
+ **L'URI della policy termina con `#sensitive`**: questo è il segnale più chiaro e diretto. Il pagante richiedente dice esplicitamente: «I dati di questo utente sono sensibili, trattali con cura».
```
"policy": [{ "uri": "...hrex-consent.html#sensitive" }]
```
+ **Il tipo di fornitura di primo livello è `deny`**: il membro ha ampiamente rifiutato la condivisione dei dati.
```
"provision": { "type": "deny" }
```
## Integrazione con \$1 davinci-data-export
La risorsa di MatchedMembers gruppo restituita da `$bulk-member-match` può essere utilizzata direttamente con l'`$davinci-data-export`operazione per recuperare i dati di massa dei membri:
```
POST [base]/Group/{matched-group-id}/$davinci-data-export
GET [base]/Group/{matched-group-id}
```
Questa integrazione consente flussi di lavoro efficienti in cui si identificano innanzitutto i membri corrispondenti in blocco, quindi si esportano le relative cartelle cliniche complete utilizzando la risorsa di Gruppo risultante.
## Caratteristiche prestazionali
L'`$bulk-member-match`operazione è progettata per l'elaborazione di grandi volumi e viene eseguita in modo asincrono:
+ **Concorrenza**: massimo 5 operazioni simultanee per archivio dati.
+ **Scalabilità**: gestisce fino a 500 membri per richiesta (limite di payload di 5 MB).
+ **Operazioni parallele**: compatibile con operazioni simultanee di importazione, esportazione o eliminazione in blocco.
## Autorizzazione
L'API utilizza il protocollo di autorizzazione SMART on FHIR con i seguenti ambiti richiesti:
+ `system/Patient.read`— Necessario per cercare e abbinare le risorse dei pazienti.
+ `system/Coverage.read`— Necessario per convalidare le informazioni sulla copertura.
+ `system/Group.write`— Necessario per creare risorse del Gruppo di risultati.
+ `system/Organization.read`— Condizionale, obbligatorio se la copertura si riferisce alle organizzazioni.
+ `system/Practitioner.read`— Condizionale, obbligatorio se la copertura si riferisce ai professionisti.
+ `system/PractitionerRole.read`— Condizionale, obbligatorio se la copertura si riferisce ai ruoli dei professionisti.
+ `system/Consent.write`— Condizionale, obbligatorio se vengono fornite risorse per il consenso.
L'operazione supporta anche l'autorizzazione AWS IAM Signature Version 4 (SigV4) per l'accesso programmatico.
## Gestione degli errori
L'operazione gestisce le seguenti condizioni di errore:
+ **400 Richiesta errata**: formato di richiesta non valido, parametri obbligatori mancanti o il payload supera i limiti di dimensione (500 membri o 5 MB).
+ **422 Entità non processabile**: errori di elaborazione durante l'esecuzione del lavoro.
+ **Errori individuali dei membri**: quando un membro specifico non viene elaborato, l'operazione continua con i membri rimanenti e include i dettagli dell'errore nel NonMatchedMembers Gruppo con i codici motivo appropriati. Ad esempio, se `MemberBundle` a un paziente manca il `birthDate` parametro, verrà restituito il seguente errore:
```
"errors": [
{
"memberIndex": 1,
"jsonBlob": {
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "invalid",
"diagnostics": "MemberPatient.birthDate is required"
}
],
"statusCode": 400
}
}
]
```
I dettagli sull'errore sono disponibili tramite l'endpoint di polling dello stato e includono:
+ `numberOfMembersWithCustomerError`: Numero di membri con errori di convalida o di input.
+ `numberOfMembersWithServerError`: Numero di membri con errori di elaborazione sul lato server.
## Operazioni correlate
+ [`$member-match`operazione per HealthLake](reference-fhir-operations-member-match.md)— Operazione di abbinamento dei singoli membri.
+ [Funzionamento FHIR R4 `$davinci-data-export` per HealthLake](reference-fhir-operations-davinci-data-export.md)— Esportazione di dati in blocco utilizzando le risorse del Gruppo.
+ [FHIR R4 per `$operations` HealthLake](reference-fhir-operations.md)— Elenco completo delle operazioni supportate.
# Funzionamento FHIR R4 `$confirm-attribution-list` per HealthLake
Indica a un produttore che il consumatore non ha più modifiche da apportare all'elenco di attribuzione. Questa operazione finalizza l'elenco di attribuzione rimuovendo i membri inattivi dall'elenco, modificando lo stato in «finale» e confermando l'operazione. Questa operazione fa parte dell'implementazione [FHIR Member Attribution (](https://build.fhir.org/ig/HL7/davinci-atr/spec.html)ATR) List IG 2.1.0.
## Endpoint
```
POST [base]/Group/[id]/$confirm-attribution-list
```
## Richiesta
Nessun parametro richiesto.
```
POST [base]/Group/[id]/$confirm-attribution-list
```
## Risposta
Restituisce HTTP 201 con un messaggio di conferma.
### Risposta di esempio
```
HTTP Status Code: 201
{
"resourceType": "Parameters",
"parameter": [
{
"name": "message",
"valueString": "Accepted."
}
]
}
```
## Stato del gruppo dopo la conferma
Dopo la conferma avvenuta con successo, lo stato della lista di attribuzione della risorsa del Gruppo sarà impostato su «finale»:
```
{
"resourceType": "Group",
"id": "fullexample",
"extension": [
{
"url": "http://hl7.org/fhir/us/davinci-atr/StructureDefinition/ext-attributionListStatus",
"valueCode": "final"
}
]
// ... other Group properties
}
```
## Gestione errori
L'operazione gestisce le seguenti condizioni di errore:
| Errore | Stato HTTP | Description |
| --- | --- | --- |
| Richiesta di operazione non valida | 400 | Parametri o struttura della richiesta non conformi |
| Risorsa di gruppo non trovata | 404 | L'ID di gruppo specificato non esiste |
## Autorizzazione e sicurezza
Requisiti di SMART
I clienti devono disporre dei privilegi appropriati per leggere le risorse del Gruppo e le relative risorse di attribuzione
Infatti`$confirm-attribution-list`, i client devono disporre anche dei privilegi di scrittura per modificare le risorse del Gruppo
I meccanismi di autorizzazione FHIR standard si applicano a tutte le operazioni
# Funzionamento FHIR R4 `$davinci-data-export` per HealthLake
L'`$davinci-data-export`operazione è un'operazione FHIR asincrona da cui è possibile esportare dati sanitari. AWS HealthLake Questa operazione supporta diversi tipi di esportazione, tra cui Member Attribution (ATR), PDex Provider Access e Member Access. Payer-to-Payer APIs È una versione specializzata del `$export` funzionamento standard FHIR, progettata per soddisfare i requisiti delle guide all'implementazione. DaVinci
## Caratteristiche chiave
+ *Elaborazione asincrona*: segue lo schema di richiesta asincrona FHIR standard
+ Esportazione a *livello di gruppo: esporta* i dati per i membri all'interno di una specifica risorsa del gruppo
+ *Diversi tipi di esportazione*: supporta ATR (Member Attribution), PDex Provider Access e Member Access Payer-to-Payer APIs
+ *Profile Support completo*: include US Core, CARIN Blue Button e PDex profili
+ *Filtraggio flessibile*: supporta il filtraggio per pazienti, tipi di risorse e intervalli di tempo
+ *Output NDJSON*: fornisce dati in formato JSON delimitato da nuove righe
## Operazione Endpoint
```
GET [base]/Group/[id]/$davinci-data-export
POST [base]/Group/[id]/$davinci-data-export
```
## Parametri della richiesta
| Parametro | Cardinalità | Description |
| --- | --- | --- |
| patient | 0.. \$1 | Membri specifici di cui esportare i dati. Se omesso, tutti i membri del Gruppo vengono esportati. |
| \$1type | 0.1. | Elenco delimitato da virgole di tipi di risorse FHIR da esportare. |
| \$1since | 0.1.. | Includi solo le risorse aggiornate dopo questa data e ora. |
| \$1until | 0.1.. | Includi solo le risorse aggiornate prima di questa data e ora. |
| exportType | 0.1.. | Tipo di esportazione da eseguire. Valori validi: hl7.fhir.us.davinci-atr, hl7.fhir.us.davinci-pdex, hl7.fhir.us.davinci-pdex.p2p, hl7.fhir.us.davinci-pdex.member. Default: hl7.fhir.us.davinci-atr. |
| \$1includeEOB2xWoFinancial | 0.1. | Specifica se includere le ExplanationOfBenefit risorse CARIN BB 2.x con i dati finanziari rimossi. Default: false. |
### Tipi di risorsa supportati
I tipi di risorse supportati dipendono dal tipo di esportazione specificato. Per le esportazioni ATR, sono supportati i seguenti tipi di risorse:
+ `Group`
+ `Patient`
+ `Coverage`
+ `RelatedPerson`
+ `Practitioner`
+ `PractitionerRole`
+ `Organization`
+ `Location`
Per PDex le esportazioni (Provider Access e Member Access), oltre ai tipi precedenti, sono supportati tutti i tipi di risorse cliniche e relative ai reclami. Payer-to-Payer Per un elenco completo dei tipi di risorse supportati, consulta la [US Core Implementation Guide (STU 6.1)](https://hl7.org/fhir/us/core/STU6.1/), la [CARIN Blue Button Implementation Guide](https://hl7.org/fhir/us/carin-bb/) e la [Da Vinci Prior Authorization Support](https://hl7.org/fhir/us/davinci-pas/) Implementation Guide.
## Tipi di esportazione
L'`$davinci-data-export`operazione supporta i seguenti tipi di esportazione. È possibile specificare il tipo di esportazione utilizzando il `exportType` parametro.
| Tipo di esportazione | Scopo | Ambito dei dati | Limite temporale |
| --- | --- | --- | --- |
| hl7.fhir.us.davinci-atr | Elenco di attribuzione dei membri | Risorse relative all'attribuzione | Nessuno |
| hl7.fhir.us.davinci-pdex | API Provider Access | Dati clinici e relativi ai reclami relativi ai pazienti attribuiti | 5 anni |
| hl7.fhir.us.davinci-pdex.p2p | Payer-to-Payer Scambio | Dati storici dei membri per le transizioni assicurative | 5 anni |
| hl7.fhir.us.davinci-pdex.member | API di accesso ai membri | Dati sanitari propri del socio | 5 anni |
**Nota**
Per PDex le esportazioni, il limite temporale di 5 anni non si applica ai tipi di risorse ATR (`Group`,,`Patient`,`Coverage`,`RelatedPerson`, `Practitioner``PractitionerRole`,`Organization`). `Location` Queste risorse sono sempre incluse indipendentemente dall'età.
### ATR (hl7.fhir.us.davinci-atr)
Con il tipo di esportazione ATR, puoi esportare i dati della Member Attribution List. Utilizzate questo tipo di esportazione per recuperare risorse relative all'attribuzione per i membri di un gruppo. Per ulteriori informazioni, consulta l'operazione di esportazione ATR [Da Vinci](https://build.fhir.org/ig/HL7/davinci-atr/OperationDefinition-davinci-data-export.html).
Tipi di risorsa supportati
`Group`, `Patient`, `Coverage`, `RelatedPerson`, `Practitioner`, `PractitionerRole`, `Organization`, `Location`
Filtraggio temporale
Non viene applicato alcun filtro temporale. Tutte le risorse corrispondenti vengono esportate indipendentemente dalla data.
### PDex Tipi di esportazione
Tutti i tipi di PDex esportazione condividono gli stessi profili e la stessa logica di filtraggio supportati. Per ulteriori informazioni, consulta l'API [Da Vinci PDex Provider Access](https://build.fhir.org/ig/HL7/davinci-epdx/provider-access-api.html). Sono supportati i seguenti profili:
+ US Core 3.1.1, 6.1.0 e 7.0.0
+ PDex Autorizzazione preventiva (non supportata per l'accesso ai membri)
+ CARIN BB 2.x Profili di base: ospedaliero istituzionale, ambulatoriale istituzionale, professionale NonClinician, orale, farmaceutico
Accesso al fornitore () `hl7.fhir.us.davinci-pdex`
Consente ai provider in rete di recuperare i dati dei pazienti per i pazienti attribuiti.
Payer-to-Payer (`hl7.fhir.us.davinci-pdex.p2p`)
Consente lo scambio di dati tra i pagatori quando un paziente cambia assicurazione.
Accesso per i membri () `hl7.fhir.us.davinci-pdex.member`
Consente ai membri di accedere ai propri dati sanitari. Questo tipo di esportazione può includere dati finanziari nelle risorse relative ai reclami.
## Logica di supporto e inclusione del profilo
Per PDex le esportazioni, l'`$davinci-data-export`operazione utilizza le dichiarazioni di profilo nell'`meta.profile`elemento per determinare quali risorse includere nell'esportazione.
### ExplanationOfBenefit Gestione delle risorse
`ExplanationOfBenefit`Le risorse (EOB) sono incluse o escluse dalle PDex esportazioni in base alle loro `meta.profile` dichiarazioni:
+ ExplanationOfBenefit le risorse con un profilo CARIN BB 1.x sono escluse dall'esportazione.
+ ExplanationOfBenefit le risorse senza `meta.profile` set sono escluse dall'esportazione.
+ ExplanationOfBenefit le risorse con un profilo CARIN BB 2.x Basis sono sempre incluse.
+ ExplanationOfBenefit le risorse con un profilo CARIN BB 2.x che contiene dati finanziari sono escluse per impostazione predefinita. Quando `_includeEOB2xWoFinancial=true` è impostato, vengono incluse con i dati finanziari rimossi e la risorsa viene trasformata nel profilo Basis corrispondente.
+ ExplanationOfBenefit le risorse con un profilo di autorizzazione PDex preventiva sono sempre incluse.
### Trasformazione dei dati finanziari
Una volta impostata`_includeEOB2xWoFinancial=true`, l'operazione trasforma le ExplanationOfBenefit risorse [CARIN BB 2.x](https://hl7.org/fhir/us/carin-bb/) nei profili Basis corrispondenti rimuovendo i dati finanziari. Ad esempio, una `C4BB ExplanationOfBenefit Oral` risorsa viene trasformata in`C4BB ExplanationOfBenefit Oral Basis`, il che rimuove i dati finanziari dal record in base alla specifica FHIR.
I seguenti elementi di dati finanziari vengono rimossi durante la trasformazione:
+ Tutte le suddivisioni sugli elementi `total`
+ Tutti gli `adjudication` elementi con slice `amounttype`
+ Tutti gli `item.adjudication` elementi con informazioni sulla quantità
L'operazione aggiorna anche i metadati del profilo durante la trasformazione:
+ `meta.profile`viene aggiornato all'URL canonico del profilo Basis
+ La versione è aggiornata alla versione CARIN BB 2.x Basis
+ Le risorse esistenti nell'archivio dati non vengono modificate
+ Le risorse esportate non vengono salvate in modo persistente nell'archivio dati
### Regole di rilevamento del profilo
L'operazione utilizza le seguenti regole per rilevare e convalidare i profili:
+ Il rilevamento della versione si basa sul codice canonico `meta.profile` URLs
+ Una risorsa viene inclusa se UNO QUALSIASI dei suoi profili dichiarati soddisfa i criteri di esportazione
+ La convalida del profilo avviene durante l'elaborazione dell'esportazione
## Filtraggio temporale quinquennale per le esportazioni PDex
Per tutti i tipi di PDex esportazione, HealthLake applica un filtro temporale di 5 anni basato sull'ultimo aggiornamento della risorsa. Il filtro temporale si applica a tutte le risorse ad eccezione dei seguenti tipi di risorse di attribuzione principali, che vengono sempre esportati indipendentemente dall'età:
+ `Patient`
+ `Coverage`
+ `Organization`
+ `Practitioner`
+ `PractitionerRole`
+ `RelatedPerson`
+ `Location`
+ `Group`
Queste risorse amministrative e demografiche sono esenti perché forniscono un contesto essenziale per i dati esportati. Le esportazioni ATR non sono soggette ad alcun filtro temporale.
## Richieste di esempio
Gli esempi seguenti mostrano come avviare processi di esportazione per diversi tipi di esportazione.
*Esportazione ATR*
```
GET https://healthlake.{region}.amazonaws.com/datastore/{datastoreId}/r4/Group/example-group/$davinci-data-export?_type=Group,Patient,Coverage,Practitioner,Organization&exportType=hl7.fhir.us.davinci-atr
POST https://healthlake.{region}.amazonaws.com/datastore/{datastoreId}/r4/Group/example-group/$davinci-data-export?_type=Group,Patient,Coverage,Practitioner,Organization&exportType=hl7.fhir.us.davinci-atr
Content-Type: application/json
{
"DataAccessRoleArn": "arn:aws:iam::444455556666:role/your-healthlake-service-role",
"JobName": "attribution-export-job",
"OutputDataConfig": {
"S3Configuration": {
"S3Uri": "s3://your-export-bucket/EXPORT-JOB",
"KmsKeyId": "arn:aws:kms:region:444455556666:key/1234abcd-12ab-34cd-56ef-1234567890ab"
}
}
}
```
*Esportazione di Provider Access con ExplanationOfBenefit rimozione dei dati finanziari*
```
GET https://healthlake.{region}.amazonaws.com/datastore/{datastoreId}/r4/Group/example-group/$davinci-data-export?_type=Patient,Observation,Condition,MedicationRequest,ExplanationOfBenefit&exportType=hl7.fhir.us.davinci-pdex&_includeEOB2xWoFinancial=true
```
*Payer-to-Payer esportazione*
```
GET https://healthlake.{region}.amazonaws.com/datastore/{datastoreId}/r4/Group/example-group/$davinci-data-export?_type=Patient,Coverage,ExplanationOfBenefit,Condition,Procedure&exportType=hl7.fhir.us.davinci-pdex.p2p&_includeEOB2xWoFinancial=true
```
*Esportazione di Member Access per un paziente specifico*
```
GET https://healthlake.{region}.amazonaws.com/datastore/{datastoreId}/r4/Group/example-group/$davinci-data-export?_type=Patient,Observation,Condition,ExplanationOfBenefit,MedicationRequest&exportType=hl7.fhir.us.davinci-pdex.member&patient=Patient/example-patient-id
```
## Risposta di esempio
```
{
"datastoreId": "eaee622d8406b41eb86c0f4741201ff9",
"jobStatus": "SUBMITTED",
"jobId": "48d7b91dae4a64d00d54b70862f33f61"
}
```
## Relazioni con le risorse
L'operazione esporta le risorse in base alle loro relazioni all'interno dell'Elenco di attribuzione dei membri:
```
Group (Attribution List)
├── Patient (Members)
├── Coverage → RelatedPerson (Subscribers)
├── Practitioner (Attributed Providers)
├── PractitionerRole → Location
└── Organization (Attributed Providers)
```
### Fonti di risorse
| Risorsa | Ubicazione della fonte | Description |
| --- | --- | --- |
| Patient | Group.member.entity | I pazienti che sono membri della lista di attribuzione |
| Coverage | Group.member.extension:coverageReference | Copertura che ha portato all'iscrizione dei pazienti |
| Organization | Group.member.extension:attributedProvider | Organizzazioni a cui vengono attribuiti i pazienti |
| Practitioner | Group.member.extension:attributedProvider | Professionisti individuali a cui vengono attribuiti i pazienti |
| PractitionerRole | Group.member.extension:attributedProvider | Ruoli professionali a cui vengono attribuiti i pazienti |
| RelatedPerson | Coverage.subscriber | Abbonati alla copertura |
| Location | PractitionerRole.location | Sedi associate ai ruoli professionali |
| Group | Endpoint di input | La lista di attribuzione stessa |
## Gestione del Job
Verifica lo stato del lavoro
`GET [base]/export/[job-id]`
Annullamento di un processo
`DELETE [base]/export/[job-id]`
### Ciclo di vita del processo
+ `SUBMITTED`- Il lavoro è stato ricevuto e messo in coda
+ `IN_PROGRESS`- Job è in fase di elaborazione attiva
+ `COMPLETED`- Job terminato con successo, file disponibili per il download
+ `FAILED`- Job ha riscontrato un errore
## Formato di output
+ *Formato di file*: NDJSON (Newline Delimited JSON)
+ *Organizzazione dei file*: file separati per ogni tipo di risorsa
+ *Estensione del file*: .ndjson
+ *Posizione: bucket* e percorso S3 specificati
## Gestione errori
L'operazione restituisce HTTP 400 Bad Request con un OperationOutcome per le seguenti condizioni:
Errori di autorizzazione
Il ruolo IAM specificato in `DataAccessRoleArn` non dispone di autorizzazioni sufficienti per eseguire l'operazione di esportazione. Per l'elenco completo delle autorizzazioni S3 e KMS richieste, consulta [Configurazione](getting-started-setting-up.md#setting-up-export-permissions) delle autorizzazioni per i lavori di esportazione.
Errori di convalida dei parametri
+ Il `patient` parametro non è formattato come `Patient/id,Patient/id,...`
+ Uno o più riferimenti ai pazienti non sono validi o non appartengono al gruppo specificato
+ Il valore del `exportType` parametro non è un tipo di esportazione supportato
+ Il `_type` parametro contiene tipi di risorse che non sono supportati per il tipo di esportazione specificato
+ Nel `_type` parametro mancano i tipi di risorse richiesti (`Group`,`Patient`,`Coverage`) per il tipo di `hl7.fhir.us.davinci-atr` esportazione
+ Il valore del `_includeEOB2xWoFinancial` parametro non è un valore booleano valido
Errori di convalida delle risorse
+ La risorsa di gruppo specificata non esiste nell'archivio dati
+ La risorsa di gruppo specificata non ha membri
+ Uno o più membri del gruppo fanno riferimento a risorse per i pazienti che non esistono nell'archivio dati
## Sicurezza e autorizzazione
+ Si applicano i meccanismi di autorizzazione FHIR standard
+ Il ruolo di accesso ai dati deve disporre delle autorizzazioni IAM richieste per le operazioni S3 e KMS. Per l'elenco completo delle autorizzazioni richieste, consulta [Configurazione](getting-started-setting-up.md#setting-up-export-permissions) delle autorizzazioni per i lavori di esportazione.
## Best practice
+ *Selezione del tipo di risorsa*: richiedete solo i tipi di risorse necessari per ridurre al minimo le dimensioni di esportazione e i tempi di elaborazione
+ *Filtraggio basato sul tempo*: utilizza il `_since` parametro per le esportazioni incrementali
+ *Filtraggio dei pazienti*: utilizza il `patient` parametro quando sono necessari solo i dati per membri specifici
+ *Job Monitoring*: controlla regolarmente lo stato del lavoro per esportazioni di grandi dimensioni
+ *Gestione degli errori*: Implementa una logica di ripetizione corretta per i lavori non riusciti
+ *Consapevolezza del filtro temporale*: per PDex le esportazioni, considera il filtro temporale quinquennale quando selezioni i tipi di risorse
+ *Rimozione dei dati finanziari*: da utilizzare `_includeEOB2xWoFinancial=true` quando sono necessari i dati relativi ai reclami senza informazioni finanziarie
+ *Gestione dei* profili: assicurati che le risorse dispongano di dichiarazioni di profilo appropriate, esegui la convalida rispetto ai profili di destinazione prima dell'ingestione e utilizza il controllo delle versioni dei profili per controllare il comportamento di esportazione
## Limitazioni
+ Nel parametro è possibile specificare un massimo di 500 pazienti `patient`
+ L'esportazione è limitata alle sole operazioni a livello di gruppo
+ Supporta solo il set predefinito di tipi di risorse per ogni tipo di esportazione
+ L'output è sempre in formato NDJSON
+ PDex le esportazioni sono limitate a 5 anni di dati clinici e relativi ai reclami
+ La trasformazione dei dati finanziari si applica solo ai profili CARIN BB 2.x ExplanationOfBenefit
## Risorse aggiuntive
+ [Elenco di attribuzione dei soci Da Vinci IG](https://build.fhir.org/ig/HL7/davinci-atr/)
+ [Da Vinci Payer Data Exchange IG](https://hl7.org/fhir/us/davinci-pdex/)
+ [IG CARIN Consumer Directed Payer Data Exchange](https://build.fhir.org/ig/HL7/carin-bb/)
+ [Guida all'implementazione di base negli Stati Uniti](https://www.hl7.org/fhir/us/core/)
+ [Specifiche FHIR Bulk Data Access](https://hl7.org/fhir/uv/bulkdata/)
# Generazione di documenti clinici con `$document`
AWS HealthLake ora supporta il `$document` funzionamento delle risorse di Composizione, consentendovi di generare un documento clinico completo raggruppando la Composizione con tutte le sue risorse di riferimento in un unico pacchetto coeso. Questa operazione è essenziale per le applicazioni sanitarie che devono:
+ Creare documenti clinici standardizzati
+ Scambia le cartelle cliniche complete dei pazienti
+ Archivia una documentazione clinica completa
+ Genera report che includano tutto il contesto pertinente
## Utilizzo
L'`$document`operazione può essere richiamata sulle risorse di composizione utilizzando i metodi GET e POST:
**Operazioni supportate**
```
GET/POST [base]/Composition/[id]/$document
```
## Parametri supportati
HealthLake supporta il seguente parametro FHIR`$document`:
| Parametro | Tipo | Obbligatorio | Predefinita | Description |
| --- | --- | --- | --- | --- |
| persist | booleano | No | false | Booleano che indica se il server deve archiviare il pacchetto di documenti generato |
## Esempi
**Richiesta GET**
```
GET [base]/Composition/180f219f-97a8-486d-99d9-ed631fe4fc57/$document?persist=true
```
**Richiesta POST con parametri**
```
POST [base]/Composition/180f219f-97a8-486d-99d9-ed631fe4fc57/$document
Content-Type: application/fhir+json
{
"resourceType": "Parameters",
"parameter": [
{
"name": "persist",
"valueBoolean": true
}
]
}
```
**Risposta di esempio**
L'operazione restituisce una risorsa Bundle di tipo «documento» contenente la composizione e tutte le risorse di riferimento:
```
{
"resourceType": "Bundle",
"id": "180f219f-97a8-486d-99d9-ed631fe4fc57",
"type": "document",
"identifier": {
"system": "urn:ietf:rfc:3986",
"value": "urn:uuid:0c3151bd-1cbf-4d64-b04d-cd9187a4c6e0"
},
"timestamp": "2024-06-21T15:30:00Z",
"entry": [
{
"fullUrl": "http://example.org/fhir/Composition/180f219f-97a8-486d-99d9-ed631fe4fc57",
"resource": {
"resourceType": "Composition",
"id": "180f219f-97a8-486d-99d9-ed631fe4fc57",
"status": "final",
"type": {
"coding": [
{
"system": "http://loinc.org",
"code": "34133-9",
"display": "Summary of Episode Note"
}
]
},
"subject": {
"reference": "Patient/example"
},
"section": [
{
"title": "Allergies",
"entry": [
{
"reference": "AllergyIntolerance/123"
}
]
}
]
}
},
{
"fullUrl": "http://example.org/fhir/Patient/example",
"resource": {
"resourceType": "Patient",
"id": "example",
"name": [
{
"family": "Smith",
"given": ["John"]
}
]
}
},
{
"fullUrl": "http://example.org/fhir/AllergyIntolerance/123",
"resource": {
"resourceType": "AllergyIntolerance",
"id": "123",
"patient": {
"reference": "Patient/example"
},
"code": {
"coding": [
{
"system": "http://snomed.info/sct",
"code": "418689008",
"display": "Allergy to penicillin"
}
]
}
}
}
]
}
```
## Comportamento
L'`$document`operazione:
1. Prende la risorsa Composition specificata come base per il documento
1. Identifica e recupera tutte le risorse a cui fa riferimento direttamente la composizione
1. Raggruppa la composizione e tutte le risorse referenziate in un pacchetto di tipo «documento»
1. Memorizza il pacchetto di documenti generato nel datastore quando il parametro persist è impostato su true
1. Identifica e recupera le risorse a cui fa riferimento indirettamente la Composizione per una generazione completa di documenti
L'`$document`operazione attualmente supporta il recupero dei riferimenti alle risorse nel seguente formato:
1.
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Resource/id
```
1. Risorsa/ID
I riferimenti alle risorse non supportati all'interno della risorsa Composition verranno filtrati dal documento generato.
## Gestione errori
L'operazione gestisce le seguenti condizioni di errore:
+ 400 Richiesta non valida: `$document` operazione non valida (richiesta non conforme) o se il documento risultante non supera la convalida FHIR a causa di riferimenti filtrati quando persist è impostato su true
+ 404 Not Found: Risorsa di composizione non trovata
Per ulteriori informazioni sulle specifiche `$document` operative, consultate la documentazione sulla [composizione `$document` FHIR R4](https://www.hl7.org/fhir/R4/composition-operation-document.html).
# Rimozione permanente di risorse con `$erase`
AWS HealthLake supporta l'`$erase`operazione, abilitando l'eliminazione permanente di una risorsa specifica e delle relative versioni storiche. Questa operazione è particolarmente utile quando è necessario:
+ Rimuovere definitivamente le singole risorse
+ Eliminare cronologie di versioni specifiche
+ Gestisci i cicli di vita delle singole risorse
+ Rispetta i requisiti specifici di rimozione dei dati
## Utilizzo
L'`$erase`operazione può essere richiamata a due livelli:
**Livello di istanza di risorsa**
```
POST [base]/[ResourceType]/[ID]/$erase?deleteAuditEvent=true
```
**Livello specifico della versione**
```
POST [base]/[ResourceType]/[ID]/_history/[VersionID]/$erase
```
## Parameters
| Parametro | Tipo | Obbligatorio | Predefinita | Description |
| --- | --- | --- | --- | --- |
| deleteAuditEvent | booleano | No | false | Se impostato su true, elimina gli eventi di controllo associati |
## Esempi
**Richiesta di esempio**
```
POST [base]/Patient/example-patient/$erase
```
**Risposta di esempio**
```
{
"jobId": "5df47e2f51ff3c731847678cb8cad48e",
"jobStatus": "SUBMITTED"
}
```
## Stato di un processo
Per verificare lo stato di un processo di cancellazione:
```
GET [base]/$erase/[jobId]
```
L'operazione restituisce informazioni sullo stato del lavoro:
```
{
"datastoreId": "36622996b1fcecb7e12ee2ee085308d3",
"jobId": "5df47e2f51ff3c731847678cb8cad48e",
"status": "COMPLETED",
"submittedTime": "2025-10-30T16:39:24.160Z"
}
```
## Comportamento
L'`$erase`operazione:
1. Processi in modo asincrono per garantire l'integrità dei dati
1. Mantiene le transazioni ACID
1. Fornisce il monitoraggio dello stato del lavoro
1. Rimuove definitivamente la risorsa specificata e le relative versioni
1. Include una registrazione di controllo completa delle attività di eliminazione
1. Supporta l'eliminazione selettiva degli eventi di controllo
## Registrazione degli audit
L'`$erase`operazione viene registrata in base DeleteResource all'ID utente, al timestamp e ai dettagli delle risorse.
## Limitazioni
+ `$erased`la risorsa non verrà visualizzata nei risultati di ricerca o nelle query. `_history`
+ Le risorse in fase di cancellazione potrebbero essere temporaneamente inaccessibili durante l'elaborazione
+ La misurazione dello storage viene regolata immediatamente man mano che le risorse vengono rimosse definitivamente
# Acquisizione dei dati dei pazienti con `Patient/$everything`
L'`Patient/$everything`operazione viene utilizzata per interrogare una `Patient` risorsa FHIR, insieme a qualsiasi altra risorsa ad essa correlata. `Patient` L'operazione può essere utilizzata per fornire a un paziente l'accesso all'intera cartella clinica o consentire a un fornitore di eseguire un download di massa di dati relativi a un paziente. HealthLakesupporti `Patient/$everything` per un paziente `id` specifico.
`Patient/$everything`è un'operazione API REST FHIR che può essere richiamata come mostrato negli esempi seguenti.
------
#### [ GET request ]
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient/id/$everything
```
------
**Nota**
Le risorse in risposta sono ordinate per tipo di risorsa e risorsa. `id`
La risposta è sempre compilata con. `Bundle.total`
## Parametri di `Patient/$everything`
HealthLake supporta i seguenti parametri di interrogazione
| Parametro | Informazioni |
| --- | --- |
| rapida | Recupera tutti `Patient` i dati dopo una data di inizio specificata. |
| end | Ottieni tutti i `Patient` dati prima di una data di fine specificata. |
| since | Aggiorna tutti `Patient` i dati dopo una data specificata. |
| \$1tipo | Ottieni `Patient` dati per tipi di risorse specifici. |
| \$1conta | Recupera `Patient` dati e specifica la dimensione della pagina. |
**Example - Ottieni tutti i dati del paziente dopo una data di inizio specificata**
`Patient/$everything`può utilizzare il `start` filtro per interrogare solo i dati dopo una data specifica.
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient/id/$everything?start=2024-03-15T00:00:00.000Z
```
**Example - Ottieni tutti i `Patient` dati prima di una data di fine specificata**
Patient \$1everything può utilizzare il `end` filtro solo per interrogare i dati prima di una data specifica.
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient/id/$everything?end=2024-03-15T00:00:00.000Z
```
**Example - Aggiorna tutti `Patient` i dati dopo una data specificata**
`Patient/$everything`può utilizzare il `since` filtro per interrogare solo i dati aggiornati dopo una data specifica.
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient/id/$everything?since=2024-03-15T00:00:00.000Z
```
**Example - Ottieni `Patient` dati per tipi di risorse specifici**
Patient \$1everything può utilizzare il `_type` filtro per specificare tipi di risorse specifici da includere nella risposta. È possibile specificare più tipi di risorse in un elenco separato da virgole.
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient/id/$everything?_type=Observation,Condition
```
**Example - Ottieni `Patient` dati e specifica la dimensione della pagina**
Patient \$1everything può utilizzare il `_count` per impostare la dimensione della pagina.
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient/id/$everything?_count=15
```
## `Patient/$everything``start`e attributi `end`
HealthLake supporta i seguenti attributi di risorsa per i parametri `Patient/ $everything` `start` e di `end` interrogazione.
| Risorsa | Elemento risorsa |
| --- | --- |
| Account | Account.ServicePeriod.start |
| AdverseEvent | AdverseEvent.data |
| AllergyIntolerance | AllergyIntolerance.data registrata |
| Appuntamento | Appuntamento. Inizio |
| AppointmentResponse | AppointmentResponse.inizio |
| AuditEvent | AuditEvent.periodo.inizio |
| Di base | Di base. Creato |
| BodyStructure | NESSUNA\$1DATA |
| CarePlan | CarePlan.periodo. inizio |
| CareTeam | CareTeam.periodo.inizio |
| ChargeItem | ChargeItem. occurrenceDateTime, ChargeItem .OccurrencePeriod.START, .OccurrenceTiming.Event ChargeItem |
| Richiedi | claim. billablePeriod.START |
| ClaimResponse | ClaimResponse.creato |
| ClinicalImpression | ClinicalImpression.data |
| Communication | Comunicazione. Inviata |
| CommunicationRequest | CommunicationRequest. occurrenceDateTime, CommunicationRequest .Periodo di occorrenza. Inizio |
| Composizione | Composizione. Data |
| Condizione | Condizione. Data registrata |
| Consenso | Consenso. Data/ora |
| Copertura | Copertura.Period.Inizio |
| CoverageEligibilityRequest | CoverageEligibilityRequest.creato |
| CoverageEligibilityResponse | CoverageEligibilityResponse.creato |
| DetectedIssue | DetectedIssue.identificato |
| DeviceRequest | DeviceRequest. Scritto il |
| DeviceUseStatement | DeviceUseStatement. Registrato su |
| DiagnosticReport | DiagnosticReport.efficace |
| DocumentManifest | DocumentManifest.creato |
| DocumentReference | DocumentReference.contesto.periodo.inizio |
| Incontro | Incontro.period.start |
| EnrollmentRequest | EnrollmentRequest.creato |
| EpisodeOfCare | EpisodeOfCare.periodo.inizio |
| ExplanationOfBenefit | ExplanationOfBenefit. Periodo fatturabile. Inizio |
| FamilyMemberHistory | NESSUNA\$1DATA |
| Flag | flag.period.start |
| Obiettivo | Obiettivo. StatusDate |
| Gruppo | NESSUNA\$1DATA |
| ImagingStudy | ImagingStudy.iniziato |
| Immunizzazione | Immunizzazione. Registrata |
| ImmunizationEvaluation | ImmunizationEvaluation.data |
| ImmunizationRecommendation | ImmunizationRecommendation.data |
| Fattura | Data della fattura |
| List | Elenco. Data |
| MeasureReport | MeasureReport.periodo.inizio |
| Media | Media. Emesso |
| MedicationAdministration | MedicationAdministration.efficace |
| MedicationDispense | MedicationDispense. Quando preparato |
| MedicationRequest | MedicationRequest. Scritto su |
| MedicationStatement | MedicationStatement.Data inserita |
| MolecularSequence | NESSUNA\$1DATA |
| NutritionOrder | NutritionOrder.Data/ora |
| Osservazione | Osservazione. Efficace |
| Paziente | NESSUNA\$1DATA |
| Person | NESSUNA\$1DATA |
| Procedura | Procedura. Eseguita |
| Provenienza | Provenienza. Periodo occorso. Inizio, Provenienza. occurredDateTime |
| QuestionnaireResponse | QuestionnaireResponse.scritto |
| RelatedPerson | NESSUNA\$1DATA |
| RequestGroup | RequestGroup. Scritto il |
| ResearchSubject | ResearchSubject.periodo |
| RiskAssessment | RiskAssessment. occurrenceDateTime, RiskAssessment .Periodo di occorrenza. Inizio |
| Schedule | Schedule.PlanningHorizon |
| ServiceRequest | ServiceRequest. Scritto il |
| Esemplare | Esemplare. Ora di ricezione |
| SupplyDelivery | SupplyDelivery. occurrenceDateTime, SupplyDelivery .OccurrencePeriod.START, .OccurrenceTiming.Event SupplyDelivery |
| SupplyRequest | SupplyRequest. Scritto il |
| VisionPrescription | VisionPrescription.data scritta |
# Recupero dei codici con ValueSet `$expand`
AWS HealthLake ora supporta l'`$expand`operazione relativa ValueSets ai codici acquisiti da te come cliente, consentendoti di recuperare l'elenco completo dei codici contenuti in quelle ValueSet risorse. Questa operazione è particolarmente utile quando è necessario:
+ Recuperare tutti i codici possibili a scopo di convalida
+ Visualizza le opzioni disponibili nelle interfacce utente
+ Esegui ricerche complete di codice all'interno di un contesto terminologico specifico
## Utilizzo
L'`$expand`operazione può essere richiamata sulle ValueSet risorse utilizzando i metodi GET e POST:
**Operazioni supportate**
```
GET/POST [base]/ValueSet/[id]/$expand
GET [base]/ValueSet/$expand?url=http://example.com
POST [base]/ValueSet/$expand
```
## Parametri supportati
HealthLake supporta un sottoinsieme di parametri FHIR R4: `$expand`
| Parametro | Tipo | Campo obbligatorio | Description |
| --- | --- | --- | --- |
| url | uri | No | URL canonico del file da espandere ValueSet |
| id | id | No | ValueSet id della risorsa da espandere (per le operazioni GET o POST) |
| filter | stringa | No | Filtra il risultato dell'espansione del codice |
| count | numero intero | No | Numero di codici da restituire |
| offset | numero intero | No | Numero di codici corrispondenti da saltare prima della restituzione. Si applica dopo il filtraggio e solo ai codici corrispondenti, non al contenuto completo e non filtrato dell'originale ValueSet |
## Esempi
**GET Richiesta per ID**
```
GET [base]/ValueSet/example-valueset/$expand
```
**Richiesta GET per URL con filtro**
```
GET [base]/ValueSet/$expand?url=http://example.com/ValueSet/my-valueset&filter=male&count=5
```
**Richiesta POST con parametri (per ID)**
```
POST [base]/ValueSet/example-valueset/$expand
Content-Type: application/fhir+json
{
"resourceType": "Parameters",
"parameter": [
{
"name": "count",
"valueInteger": 10
},
{
"name": "filter",
"valueString": "admin"
}
]
}
```
**Richiesta POST con parametri (tramite URL)**
```
POST [base]/ValueSet/$expand
Content-Type: application/fhir+json
{
"resourceType": "Parameters",
"parameter": [
{
"name": "url",
"valueUri": "http://hl7.org/fhir/ValueSet/administrative-gender"
},
{
"name": "count",
"valueInteger": 10
}
]
}
```
**Risposta di esempio**
L'operazione restituisce una ValueSet risorsa con un `expansion` elemento contenente i codici espansi:
```
{
"resourceType": "ValueSet",
"id": "administrative-gender",
"status": "active",
"expansion": {
"identifier": "urn:uuid:12345678-1234-1234-1234-123456789abc",
"timestamp": "2024-01-15T10:30:00Z",
"total": 4,
"parameter": [
{
"name": "count",
"valueInteger": 10
}
],
"contains": [
{
"system": "http://hl7.org/fhir/administrative-gender",
"code": "male",
"display": "Male"
},
{
"system": "http://hl7.org/fhir/administrative-gender",
"code": "female",
"display": "Female"
},
{
"system": "http://hl7.org/fhir/administrative-gender",
"code": "other",
"display": "Other"
},
{
"system": "http://hl7.org/fhir/administrative-gender",
"code": "unknown",
"display": "Unknown"
}
]
}
}
```
La risposta include:
+ expansion.total: numero totale di codici nell'espanso ValueSet
+ expansion.contains: matrice di codici espansi con i relativi valori di sistema, codice e visualizzazione
+ expansion.parameter: parametri utilizzati nella richiesta di espansione
[Per ulteriori informazioni sulle specifiche `$expand` operative, consultate la documentazione FHIR R4. ValueSet `$expand`](https://build.fhir.org/valueset-operation-expand.html)
# Esportazione di HealthLake dati con FHIR `$export`
Puoi esportare i dati in blocco dal tuo archivio HealthLake dati utilizzando l'operazione FHIR \$1export. HealthLake supporta l'utilizzo e le richieste di FHIR`$export`. `POST` `GET` Per effettuare una richiesta di esportazione`POST`, devi disporre di un utente, gruppo o ruolo IAM con le autorizzazioni richieste, specificarlo `$export` come parte della richiesta e includere i parametri desiderati nel corpo della richiesta.
**Nota**
Tutte le richieste di HealthLake esportazione effettuate utilizzando FHIR `$export` vengono restituite in `ndjson` formato ed esportate in un bucket Amazon S3, dove ogni oggetto Amazon S3 contiene un solo tipo di risorsa FHIR.
Puoi mettere in coda le richieste di esportazione in base alle quote di servizio dell'account. AWS Per ulteriori informazioni, consulta [Service Quotas](reference-healthlake-endpoints-quotas.md#reference-healthlake-quotas).
HealthLake supporta i seguenti tre tipi di richieste endpoint di esportazione in blocco.
**HealthLake tipi in blocco `$export`**
| Tipo di esportazione | Description | Sintassi |
| --- | --- | --- |
| Sistema | Esporta tutti i dati dal server HealthLake FHIR. | `POST https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/$export` |
| Tutti i pazienti | Esporta tutti i dati relativi a tutti i pazienti, compresi i tipi di risorse associati al tipo di risorsa Paziente. | `POST https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient/$export` `GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient/$export` |
| Gruppo di pazienti | Esporta tutti i dati relativi a un gruppo di pazienti specificato con un ID di gruppo. | `POST https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Group/id/$export` `GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Group/id/$export` |
## Prima di iniziare
Soddisfa i seguenti requisiti per effettuare una richiesta di esportazione utilizzando l'API REST FHIR per HealthLake.
+ È necessario aver impostato un utente, un gruppo o un ruolo con le autorizzazioni necessarie per effettuare la richiesta di esportazione. Per ulteriori informazioni, consulta [Autorizzazione di una richiesta `$export`](#export-rest-auth).
+ Devi aver creato un ruolo di servizio che garantisca HealthLake l'accesso al bucket Amazon S3 in cui desideri esportare i tuoi dati. Il ruolo di servizio deve inoltre essere specificato HealthLake come principale del servizio. Per ulteriori informazioni sulla configurazione delle autorizzazioni, vedere[Impostazione delle autorizzazioni per i lavori di esportazione](getting-started-setting-up.md#setting-up-export-permissions).
## Autorizzazione di una richiesta `$export`
Per effettuare correttamente una richiesta di esportazione utilizzando l'API REST FHIR, autorizza il tuo utente, gruppo o ruolo utilizzando IAM o .0. OAuth2 È inoltre necessario avere un ruolo di servizio.
**Autorizzazione di una richiesta tramite IAM**
Quando effettui una `$export` richiesta, l'utente, il gruppo o il ruolo devono includere azioni IAM nella policy. Per ulteriori informazioni, consulta [Impostazione delle autorizzazioni per i lavori di esportazione](getting-started-setting-up.md#setting-up-export-permissions).
**Autorizzazione di una richiesta utilizzando SMART on FHIR (2.0) OAuth**
Quando si effettua una `$export` richiesta su un HealthLake data store compatibile con SMART on FHIR, è necessario assegnare gli ambiti appropriati. Per ulteriori informazioni, consulta [SMART sugli ambiti di risorse FHIR per HealthLake](reference-smart-on-fhir-oauth-scopes.md#smart-on-fhir-scopes-rest).
**Nota**
Le FHIR `$export` con `GET` richieste richiedono lo stesso metodo di autenticazione o lo stesso token portatore (nel caso di SMART su FHIR) per richiedere l'esportazione e il recupero dei file. I file esportati utilizzando FHIR `$export` con `GET` sono disponibili per il download per 48 ore.
## Effettuare una richiesta `$export`
Questa sezione descrive i passaggi necessari da eseguire quando si effettua una richiesta di esportazione utilizzando l'API REST FHIR.
Per evitare addebiti accidentali sul tuo AWS account, ti consigliamo di testare le tue richieste effettuando una `POST` richiesta senza fornire la `$export` sintassi.
Per effettuare la richiesta, devi fare quanto segue:
1. Specificare `$export` nell'URL della `POST` richiesta per un endpoint supportato.
1. Specificate i parametri di intestazione richiesti.
1. Specificate un corpo della richiesta che definisca i parametri richiesti.
### Passo 1: Specificare `$export` nell'URL della `POST` richiesta un [endpoint](reference-healthlake-endpoints-quotas.md#reference-healthlake-endpoints) supportato.
HealthLake supporta tre tipi di richieste endpoint di esportazione in blocco. Per effettuare una richiesta di esportazione in blocco, è necessario effettuare una richiesta `POST` basata su uno dei tre endpoint supportati. Gli esempi seguenti mostrano dove specificare `$export` nell'URL della richiesta.
+ `POST https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/$export`
+ `POST https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient/$export`
+ `POST https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Group/id/$export`
È possibile utilizzare i seguenti parametri di ricerca supportati nella stringa di `POST` richiesta.
#### Parametri di ricerca supportati
HealthLake supporta i seguenti modificatori di ricerca nelle richieste di esportazione in blocco.
I seguenti esempi includono caratteri speciali che devono essere codificati prima di inviare la richiesta.
| Name | Obbligatorio? | Description | Esempio |
| --- | --- | --- | --- |
| \$1outputFormat | No | Il formato per i file Bulk Data richiesti da generare. I valori accettati sonoapplication/fhir\$1ndjson,application/ndjson,ndjson. | |
| \$1type | No | Una stringa di tipi di risorse FHIR delimitati da virgole da includere nel processo di esportazione. Ti consigliamo di includerla \$1type perché ciò può avere un impatto sui costi quando tutte le risorse vengono esportate. | &\$1type=MedicationStatement, Observation |
| \$1since | No | Tipi di risorse modificati in o dopo la data e l'ora. Se un tipo di risorsa non ha l'ora dell'ultimo aggiornamento, verranno inclusi nella risposta. | &\$1since=2024-05-09T00%3A00%3A00Z |
| \$1until | No | Tipi di risorse modificati in data e ora o prima. Utilizzato in combinazione con \$1since per definire un intervallo di tempo specifico per l'esportazione. Se un tipo di risorsa non ha un'ora dell'ultimo aggiornamento, verrà escluso dalla risposta. | &\$1until=2024-12-31T23%3A59%3A59Z |
### Passaggio 2: Specificare i parametri di intestazione richiesti
Per effettuare una richiesta di esportazione utilizzando l'API REST FHIR, è necessario specificare i seguenti parametri di intestazione.
+ Tipo di contenuto: `application/fhir+json`
+ Preferisco: `respond-async`
Successivamente, è necessario specificare gli elementi richiesti nel corpo della richiesta.
### Fase 3: Specificare un corpo della richiesta e definire i parametri richiesti.
La richiesta di esportazione richiede anche un corpo in `JSON` formato. Il corpo può includere i seguenti parametri.
| Chiave | Obbligatorio? | Description | Valore |
| --- | --- | --- | --- |
| DataAccessRoleArn | Sì | Un ARN di un ruolo di HealthLake servizio. Il ruolo di servizio utilizzato deve essere specificato HealthLake come principale del servizio. | arn:aws:iam::444455556666:role/your-healthlake-service-role |
| JobName | No | Il nome della richiesta di esportazione. | your-export-job-name |
| S3Uri | Sì | Parte di una OutputDataConfig chiave. L'URI S3 del bucket di destinazione in cui verranno scaricati i dati esportati. | s3://amzn-s3-demo-bucket/EXPORT-JOB/ |
| KmsKeyId | Sì | Parte di una chiave. OutputDataConfig L'ARN della AWS KMS chiave utilizzata per proteggere il bucket Amazon S3. | arn:aws:kms:region-of-bucket:123456789012:key/1234abcd-12ab-34cd-56ef-1234567890ab |
**Example Corpo di una richiesta di esportazione effettuata utilizzando l'API REST FHIR**
Per effettuare una richiesta di esportazione utilizzando l'API REST FHIR, è necessario specificare un corpo, come illustrato di seguito.
```
{
"DataAccessRoleArn": "arn:aws:iam::444455556666:role/your-healthlake-service-role",
"JobName": "your-export-job",
"OutputDataConfig": {
"S3Configuration": {
"S3Uri": "s3://amzn-s3-demo-bucket/EXPORT-JOB",
"KmsKeyId": "arn:aws:kms:region-of-bucket:444455556666:key/1234abcd-12ab-34cd-56ef-1234567890ab"
}
}
}
```
Quando la richiesta avrà esito positivo, riceverai la seguente risposta.
*Intestazione della risposta*
```
content-location: https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/export/your-export-request-job-id
```
*Corpo di risposta*
```
{
"datastoreId": "your-data-store-id",
"jobStatus": "SUBMITTED",
"jobId": "your-export-request-job-id"
}
```
## Gestione della richiesta di esportazione
Dopo aver effettuato una richiesta di esportazione corretta, puoi gestirla descrivendo `$export` lo stato di una richiesta di esportazione corrente e `$export` annullando una richiesta di esportazione corrente.
Quando annulli una richiesta di esportazione utilizzando l'API REST, ti viene fatturata solo la parte dei dati che sono stati esportati fino al momento in cui hai inviato la richiesta di annullamento.
I seguenti argomenti descrivono come visualizzare lo stato o annullare una richiesta di esportazione corrente.
### Annullamento di una richiesta di esportazione
Per annullare una richiesta di esportazione, effettua una `DELETE` richiesta e fornisci l'ID del lavoro nell'URL della richiesta.
```
DELETE https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/export/your-export-request-job-id
```
Quando la richiesta ha esito positivo, riceverai quanto segue.
```
{
"exportJobProperties": {
"jobId": "your-original-export-request-job-id",
"jobStatus": "CANCEL_SUBMITTED",
"datastoreId": "your-data-store-id"
}
}
```
Quando la tua richiesta non va a buon fine, ricevi quanto segue.
```
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "not-supported",
"diagnostics": "Interaction not supported."
}
]
}
```
### Descrizione di una richiesta di esportazione
Per conoscere lo stato di una richiesta di esportazione, effettua una `GET` richiesta utilizzando `export` and your`export-request-job-id`.
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/export/your-export-request-id
```
La risposta JSON conterrà un `ExportJobProperties` oggetto. Può contenere le seguenti coppie chiave:valore.
| Name | Obbligatorio? | Description | Valore |
| --- | --- | --- | --- |
| DataAccessRoleArn | No | Un ARN di un ruolo di HealthLake servizio. Il ruolo di servizio utilizzato deve essere specificato HealthLake come principale del servizio. | arn:aws:iam::444455556666:role/your-healthlake-service-role |
| SubmitTime | No | La data e l'ora in cui è stato inviato un processo di esportazione. | Apr 21, 2023 5:58:02 |
| EndTime | No | L'ora in cui è stato completato un processo di esportazione. | Apr 21, 2023 6:00:08 PM |
| JobName | No | Il nome della richiesta di esportazione. | your-export-job-name |
| JobStatus | No | | I valori validi sono:SUBMITTED | IN_PROGRESS | COMPLETED_WITH_ERRORS | COMPLETED |
FAILED
|
| S3Uri | Sì | Parte di un [OutputDataConfig](https://docs.aws.amazon.com/healthlake/latest/APIReference/API_OutputDataConfig.html)oggetto. L'URI Amazon S3 del bucket di destinazione in cui verranno scaricati i dati esportati. | s3://amzn-s3-demo-bucket/EXPORT-JOB/ |
| KmsKeyId | Sì | Parte di un oggetto. [OutputDataConfig](https://docs.aws.amazon.com/healthlake/latest/APIReference/API_OutputDataConfig.html) L'ARN della AWS KMS chiave utilizzata per proteggere il bucket Amazon S3. | arn:aws:kms:region-of-bucket:123456789012:key/1234abcd-12ab-34cd-56ef-1234567890ab |
**Example : corpo di una richiesta di descrizione dell'esportazione effettuata utilizzando l'API REST FHIR**
In caso di successo, riceverai la seguente risposta JSON.
```
{
"exportJobProperties": {
"jobId": "your-export-request-id",
"JobName": "your-export-job",
"jobStatus": "SUBMITTED",
"submitTime": "Apr 21, 2023 5:58:02 PM",
"endTime": "Apr 21, 2023 6:00:08 PM",
"datastoreId": "your-data-store-id",
"outputDataConfig": {
"s3Configuration": {
"S3Uri": "s3://amzn-s3-demo-bucket/EXPORT-JOB",
"KmsKeyId": "arn:aws:kms:region-of-bucket:444455556666:key/1234abcd-12ab-34cd-56ef-1234567890ab""
}
},
"DataAccessRoleArn": "arn:aws:iam::444455556666:role/your-healthlake-service-role",
}
}
```
# `$inquire`Operazione FHIR per HealthLake
L'`$inquire`operazione consente di verificare lo stato di una richiesta di autorizzazione preventiva inviata in precedenza. Questa operazione implementa la [Guida all'implementazione del Da Vinci Prior Authorization Support (PAS)](https://hl7.org/fhir/us/davinci-pas/), che fornisce un flusso di lavoro standardizzato basato su FHIR per recuperare l'attuale decisione di autorizzazione.
## Come funziona
+ **Invia richiesta**: invii un pacchetto FHIR contenente il reclamo che desideri verificare e le informazioni di supporto
+ **Cerca**: HealthLake cerca il corrispondente ClaimResponse nel tuo archivio dati
+ **Recupera**: viene recuperato lo stato di autorizzazione più recente
+ **Rispondi**: ricevi una risposta immediata con lo stato dell'autorizzazione corrente (in coda, approvata, negata, ecc.)
**Nota**
`$inquire`è un'**operazione di sola lettura** che recupera lo stato di autorizzazione esistente. Non modifica o aggiorna alcuna risorsa nell'archivio dati.
## Endpoint API
```
POST /datastore/{datastoreId}/r4/Claim/$inquire
Content-Type: application/fhir+json
```
## Struttura della richiesta
### Requisiti del pacchetto
La tua richiesta deve essere una risorsa FHIR Bundle con:
+ **Bundle.type: Deve** essere `"collection"`
+ **bundle.entry****: deve contenere esattamente una risorsa Claim con:**
+ `use = "preauthorization"`
+ `status = "active"`
+ **Risorse referenziate**: tutte le risorse a cui fa riferimento il reclamo devono essere incluse nel pacchetto
**Interrogazione per esempio**
Le risorse del tuo pacchetto di input fungono da modello di ricerca. HealthLake utilizza le informazioni fornite per individuare il corrispondente ClaimResponse.
### Risorse obbligatorie
| Risorsa | Cardinalità | Profilo | Description |
| --- | --- | --- | --- |
| Reclamo | 1 | Richiesta di reclamo PAS | L'autorizzazione preventiva su cui stai chiedendo informazioni |
| La paziente | 1 | Paziente beneficiario PAS | Informazioni demografiche sui pazienti |
| Organizzazione (assicuratore) | 1 | Organizzazione assicurativa PAS | Compagnia assicurativa |
| Organizzazione (fornitore) | 1 | Organizzazione richiedente PAS | Operatore sanitario che ha inviato la richiesta |
### Criteri di ricerca importanti
HealthLake ricerche per l' ClaimResponse utilizzo:
+ **Riferimento del paziente** riportato nel reclamo
+ **Riferimento dell'assicuratore** riportato nel reclamo
+ **Riferimento al fornitore** riportato nel reclamo
+ **Data di creazione** del reclamo (come filtro temporale)
**Solo domande specifiche per il paziente**
Tutte le richieste devono essere legate a un paziente specifico. Non sono consentite domande a livello di sistema senza identificazione del paziente.
## Richiesta di esempio
```
POST /datastore/example-datastore/r4/Claim/$inquire
Content-Type: application/fhir+json
Authorization: Bearer
{
"resourceType": "Bundle",
"id": "PASClaimInquiryBundleExample",
"meta": {
"profile": ["http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-pas-inquiry-request-bundle"]
},
"identifier": {
"system": "http://example.org/SUBMITTER_TRANSACTION_IDENTIFIER",
"value": "5269368"
},
"type": "collection",
"timestamp": "2005-05-02T14:30:00+05:00",
"entry": [
{
"fullUrl": "http://example.org/fhir/Claim/MedicalServicesAuthorizationExample",
"resource": {
"resourceType": "Claim",
"id": "MedicalServicesAuthorizationExample",
"meta": {
"profile": ["http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-claim-inquiry"]
},
"status": "active",
"type": {
"coding": [{
"system": "http://terminology.hl7.org/CodeSystem/claim-type",
"code": "professional"
}]
},
"use": "preauthorization",
"patient": {
"reference": "Patient/SubscriberExample"
},
"created": "2005-05-02T11:01:00+05:00",
"insurer": {
"reference": "Organization/InsurerExample"
},
"provider": {
"reference": "Organization/UMOExample"
}
}
},
{
"fullUrl": "http://example.org/fhir/Patient/SubscriberExample",
"resource": {
"resourceType": "Patient",
"id": "SubscriberExample",
"meta": {
"profile": ["http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-beneficiary"]
},
"name": [{
"family": "SMITH",
"given": ["JOE"]
}],
"gender": "male"
}
},
{
"fullUrl": "http://example.org/fhir/Organization/UMOExample",
"resource": {
"resourceType": "Organization",
"id": "UMOExample",
"meta": {
"profile": ["http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-requestor"]
},
"name": "Provider Organization"
}
},
{
"fullUrl": "http://example.org/fhir/Organization/InsurerExample",
"resource": {
"resourceType": "Organization",
"id": "InsurerExample",
"meta": {
"profile": ["http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-insurer"]
},
"name": "Insurance Company"
}
}
]
}
```
## Formato della risposta
### Risposta riuscita (200 OK)
Riceverai un pacchetto PAS Inquiry Response contenente:
+ **ClaimResponse**con lo stato di autorizzazione corrente; multiplo **ClaimResponse**se corrisponde ai criteri di ricerca
+ Tutte le risorse originali contenute nella tua richiesta (riportate all'indietro)
+ Timestamp di quando è stata assemblata la risposta
**Possibili esiti ClaimResponse**
| Outcome | Description |
| --- | --- |
| queued | La richiesta di autorizzazione è ancora in attesa di revisione |
| complete | La decisione di autorizzazione è stata presa (verifica se disposition approvata/negata) |
| error | Si è verificato un errore durante l'elaborazione |
| partial | Autorizzazione parziale concessa |
```
{
"resourceType": "Bundle",
"identifier": {
"system": "http://example.org/SUBMITTER_TRANSACTION_IDENTIFIER",
"value": "5269367"
},
"type": "collection",
"timestamp": "2005-05-02T14:30:15+05:00",
"entry": [
{
"fullUrl": "http://example.org/fhir/ClaimResponse/InquiryResponseExample",
"resource": {
"resourceType": "ClaimResponse",
"id": "InquiryResponseExample",
"meta": {
"profile": ["http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-claimresponse-inquiry"]
},
"status": "active",
"type": {
"coding": [{
"system": "http://terminology.hl7.org/CodeSystem/claim-type",
"code": "professional"
}]
},
"use": "preauthorization",
"patient": {
"reference": "Patient/SubscriberExample"
},
"created": "2005-05-02T11:05:00+05:00",
"insurer": {
"reference": "Organization/InsurerExample"
},
"request": {
"reference": "Claim/MedicalServicesAuthorizationExample"
},
"outcome": "complete",
"disposition": "Approved",
"preAuthRef": "AUTH12345"
}
},
{
"fullUrl": "http://example.org/fhir/Claim/MedicalServicesAuthorizationExample",
"resource": {
"resourceType": "Claim",
"id": "MedicalServicesAuthorizationExample",
"meta": {
"profile": ["http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-claim-inquiry"]
},
"status": "active",
"type": {
"coding": [{
"system": "http://terminology.hl7.org/CodeSystem/claim-type",
"code": "professional"
}]
},
"use": "preauthorization",
"patient": {
"reference": "Patient/SubscriberExample"
},
"created": "2005-05-02T11:01:00+05:00",
"insurer": {
"reference": "Organization/InsurerExample"
},
"provider": {
"reference": "Organization/UMOExample"
}
}
},
{
"fullUrl": "http://example.org/fhir/Patient/SubscriberExample",
"resource": {
"resourceType": "Patient",
"id": "SubscriberExample",
"meta": {
"profile": ["http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-beneficiary"]
},
"name": [{
"family": "SMITH",
"given": ["JOE"]
}],
"gender": "male"
}
},
{
"fullUrl": "http://example.org/fhir/Organization/UMOExample",
"resource": {
"resourceType": "Organization",
"id": "UMOExample",
"meta": {
"profile": ["http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-requestor"]
},
"name": "Provider Organization"
}
},
{
"fullUrl": "http://example.org/fhir/Organization/InsurerExample",
"resource": {
"resourceType": "Organization",
"id": "InsurerExample",
"meta": {
"profile": ["http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-insurer"]
},
"name": "Insurance Company"
}
}
]
}
```
## Risposte agli errori
### 400 Richiesta non valida
Restituito quando il formato della richiesta non è valido o la convalida fallisce.
```
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "required",
"diagnostics": "Reference 'Patient/SubscriberExample' at path 'patient' for 'CLAIM' resource not found(at Bundle.entry[0].resource)"
}
]
}
```
### 401 - Autorizzazione negata
Restituito quando le credenziali di autenticazione sono mancanti o non valide.
```
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "forbidden",
"diagnostics": "Invalid authorization header"
}
]
}
```
### 403 Non consentito
Restituito quando l'utente autenticato non è autorizzato ad accedere alla risorsa richiesta.
```
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "exception",
"diagnostics": "Insufficient SMART scope permissions."
}
]
}
```
### 400 Quando non ne viene trovato nessuno
Restituito quando non ClaimResponse viene trovata alcuna corrispondenza per la richiesta.
```
{
"resourceType": "OperationOutcome",
"issue": [{
"severity": "error",
"code": "not-found",
"diagnostics": "Resource not found. No ClaimResponse found from the input Claim that matches the specified Claim properties patient, insurer, provider, and created(at Bundle.entry[0].resource)"
}]
}
```
### 4.1.5 Tipo di supporto non supportato
Restituito quando l'intestazione Content-Type non è application/fhir\$1json.
```
{
"resourceType": "OperationOutcome",
"issue": [{
"severity": "error",
"code": "value",
"diagnostics": "Incorrect MIME-type. Update request Content-Type header."
}]
}
```
### 429 Troppe richieste
Restituito quando vengono superati i limiti di velocità.
```
{
"resourceType": "OperationOutcome",
"issue": [{
"severity": "error",
"code": "throttled",
"diagnostics": "Rate limit exceeded. Please retry after some time."
}]
}
```
## Regole di convalida
HealthLake esegue una convalida completa della richiesta:
### Convalida del pacchetto
+ Deve essere conforme al profilo PAS Inquiry Request Bundle
+ `Bundle.type`deve essere `"collection"`
+ Deve contenere esattamente una risorsa Claim
+ Tutte le risorse referenziate devono essere incluse nel pacchetto
### Convalida del reclamo
+ Deve essere conforme al profilo PAS Claim Inquiry
+ `Claim.use`deve essere `"preauthorization"`
+ `Claim.status`deve essere `"active"`
+ Campi obbligatori:`patient`,`insurer`,`provider`, `created`
### Convalida delle risorse
+ Tutte le risorse devono essere conformi ai rispettivi profili di richiesta PAS
+ Devono essere presenti le risorse di supporto necessarie (paziente, organizzazione assicurativa, organizzazione fornitrice)
+ I riferimenti incrociati devono essere validi e risolvibili all'interno del pacchetto
## Specifiche prestazionali
| Metrica | Specifiche |
| --- | --- |
| Limite di conteggio delle risorse | 500 risorse per pacchetto |
| Limite di dimensione del pacchetto | Massimo 5 MB |
## Autorizzazioni richieste
Per utilizzare l'`$inquire`operazione, assicurati che il tuo ruolo IAM abbia:
+ `healthlake:InquirePreAuthClaim`- Per richiamare l'operazione
**SMART su FHIR Scopes**
**Ambiti minimi richiesti:**
+ **SMART v1:** `user/ClaimResponse.read`
+ **SMART versione 2:** `user/ClaimResponse.s`
## Note importanti sull'implementazione
### Comportamento di ricerca
Quando invii una richiesta, HealthLake cerca ClaimResponse utilizzando:
+ **Riferimento del paziente** riportato nel reclamo inserito
+ **Riferimento dell'assicuratore riportato** nella Richiesta inserita
+ **Riferimento al fornitore** riportato nel reclamo inserito
+ **Data di creazione** in base alla richiesta di immissione (come filtro temporale)
**Corrispondenze** multiple: se più ClaimResponses corrispondono ai criteri di ricerca, HealthLake restituisce tutti i risultati corrispondenti. È necessario utilizzare il `ClaimResponse.created` timestamp più recente per identificare lo stato più recente.
### Reclami aggiornati
Se hai inviato più aggiornamenti alla stessa autorizzazione preventiva (ad esempio, Claim v1.1, v1.2, v1.3), l'`$inquire`operazione recupererà quelli ClaimResponse associati alla **versione più recente** in base ai criteri di ricerca forniti.
### Operazione di sola lettura
L'`$inquire`operazione:
+ Recupera **lo** stato di autorizzazione esistente
+ **Restituisce** il più recente ClaimResponse
+ **Non** modifica o aggiorna alcuna risorsa
+ **Non** crea nuove risorse
+ **Non** attiva una nuova elaborazione delle autorizzazioni
## Esempio di workflow
**Tipico flusso di lavoro di richiesta di autorizzazione preventiva**
```
1. Provider submits PA request
POST /Claim/$submit
→ Returns ClaimResponse with outcome="queued"
2. Payer reviews request (asynchronous)
→ Updates ClaimResponse status internally
3. Provider checks status
POST /Claim/$inquire
→ Returns ClaimResponse with outcome="queued" (still pending)
4. Provider checks status again later
POST /Claim/$inquire
→ Returns ClaimResponse with outcome="complete", disposition="Approved"
```
## Operazioni correlate
+ `Claim/$submit`- Invia una nuova richiesta di autorizzazione preventiva o aggiornane una esistente
+ `Patient/$everything`- Recupera i dati completi del paziente per il contesto di autorizzazione preventiva
# Recupero dei dettagli concettuali con `$lookup`
AWS HealthLake ora supporta l'`$lookup`operazione per CodeSystem le risorse, consentendoti di recuperare dettagli su un concetto specifico in un sistema di codice fornendo informazioni identificative come il codice. Questa operazione è particolarmente utile quando è necessario:
+ Recuperare informazioni dettagliate su codici medici specifici
+ Convalida i significati e le proprietà dei codici
+ Accedi alle definizioni e alle relazioni dei concetti
+ Supporta il processo decisionale clinico con dati terminologici accurati
## Utilizzo
L'`$lookup`operazione può essere richiamata sulle CodeSystem risorse utilizzando i metodi GET e POST:
**Operazioni supportate**
```
GET [base]/CodeSystem/$lookup?system=http://snomed.info/sct&code=73211009&version=20230901
POST [base]/CodeSystem/$lookup
```
## Parametri supportati
HealthLake supporta un sottoinsieme di parametri FHIR R4: `$lookup`
| Parametro | Tipo | Campo obbligatorio | Description |
| --- | --- | --- | --- |
| code | code | Sì | Il codice concettuale che stai cercando (ad esempio, «71620000" in SNOMED CT) |
| system | uri | Sì | [L'URL canonico del sistema di codici (ad esempio, "http://snomed.info/sct «)](http://snomed.info/sct) |
| version | stringa | No | Versione specifica del sistema di codice |
## Esempi
**Richiesta GET**
```
GET [base]/CodeSystem/$lookup?system=http://snomed.info/sct&code=71620000&version=2023-09
```
**Richiesta POST**
```
POST [base]/CodeSystem/$lookup
Content-Type: application/fhir+json
{
"resourceType": "Parameters",
"parameter": [
{
"name": "system",
"valueUri": "http://snomed.info/sct"
},
{
"name": "code",
"valueCode": "71620000"
},
{
"name": "version",
"valueString": "2023-09"
}
]
}
```
**Risposta di esempio**
L'operazione restituisce una risorsa Parameters contenente i dettagli del concetto:
```
{
"resourceType": "Parameters",
"parameter": [{
"name": "name",
"valueString": "SNOMED CT Fractures"
},
{
"name": "version",
"valueString": "2023-09"
},
{
"name": "display",
"valueString": "Fracture of femur"
},
{
"name": "property",
"part": [{
"name": "code",
"valueCode": "child"
},
{
"name": "value",
"valueCode": "263225007"
},
{
"name": "description",
"valueString": "Fracture of neck of femur"
}
]
},
{
"name": "property",
"part": [{
"name": "code",
"valueCode": "child"
},
{
"name": "value",
"valueCode": "263227004"
},
{
"name": "description",
"valueString": "Fracture of shaft of femur"
}
]
}
]
}
```
## Parametri di risposta
La risposta include i seguenti parametri, se disponibili:
| Parametro | Tipo | Description |
| --- | --- | --- |
| name | stringa | Nome del sistema di codici |
| version | stringa | Versione del sistema di codici |
| display | stringa | Visualizza il nome del concetto |
| designation | BackboneElement | Rappresentazioni aggiuntive per questo concetto. |
| property | BackboneElement | Proprietà aggiuntive del concetto (definizione, relazioni, ecc.) |
## Comportamento
L'`$lookup`operazione:
1. Convalida i parametri richiesti (`code`e`system`)
1. Cerca il concetto all'interno del sistema di codice specificato memorizzato nel datastore
1. Restituisce informazioni dettagliate sul concetto, tra cui nome visualizzato, designazioni e proprietà.
1. Supporta ricerche specifiche per versione quando viene fornito il parametro `version`
1. Funziona solo su sistemi di codice archiviati in modo esplicito nel datastore HealthLake
## Gestione errori
L'operazione gestisce le seguenti condizioni di errore:
+ 400 Bad Request: `$lookup` operazione non valida (richiesta non conforme o parametri obbligatori mancanti)
+ 404 Not Found: Sistema di codice non trovato o codice non trovato nel sistema di codice specificato
## Avvertenze
In questa versione, non sono supportati:
+ `$lookup`operazione mediante chiamata a server terminologici esterni
+ `$lookup`operazione su CodeSystems gestita da HealthLake ma non archiviata in modo esplicito nel datastore
Per ulteriori informazioni sulle specifiche `$lookup` operative, consultate la documentazione di [FHIR](https://www.hl7.org/fhir/R4/codesystem-operation-lookup.html) R4. CodeSystem `$lookup`
# `$member-add`operazione per HealthLake
L'`$member-add`operazione FHIR aggiunge un membro (paziente) a una risorsa del Gruppo, in particolare a una lista di attribuzione dei membri. Questa operazione fa parte della DaVinci Member Attribution Implementation Guide e supporta il processo di riconciliazione per la gestione delle attribuzioni dei membri.
## Operazione Endpoint
```
POST [base]/datastore/{datastoreId}/r4/Group/{groupId}/$member-add
Content-Type: application/json
```
## Parameters
L'operazione accetta una risorsa FHIR Parameters con le seguenti combinazioni di parametri:
### Opzioni dei parametri
È possibile utilizzare una delle seguenti combinazioni di parametri:
Opzione 1: Member ID \$1 Provider NPI
`memberId` \$1 `providerNpi`
`memberId` \$1 `providerNpi` \$1 `attributionPeriod`
Opzione 2: riferimento per il paziente e riferimento per il fornitore
`patientReference` \$1 `providerReference`
`patientReference` \$1 `providerReference` \$1 `attributionPeriod`
### Dettagli dei parametri
MemberID (opzionale)
L'identificatore del membro da aggiungere al gruppo.
Tipo: identificatore
Sistema: sistema di identificazione del paziente
```
{
"name": "memberId",
"valueIdentifier": {
"system": "http://example.org/patient-id",
"value": "patient-new"
}
}
```
ProviderNPI (opzionale)
Il National Provider Identifier (NPI) del provider attribuito.
Tipo: identificatore
Sistema: http://terminology.hl7. org/CodeSystem/NPI
```
{
"name": "providerNpi",
"valueIdentifier": {
"system": "http://terminology.hl7.org/CodeSystem/NPI",
"value": "1234567890"
}
}
```
Riferimento per il paziente (opzionale)
Riferimento diretto alla risorsa per il paziente da aggiungere.
Tipo: riferimento
```
{
"name": "patientReference",
"valueReference": {
"reference": "Patient/patient-123"
}
}
```
ProviderReference (opzionale)
Riferimento diretto alla risorsa del provider.
Tipo: riferimento
```
{
"name": "providerReference",
"valueReference": {
"reference": "Practitioner/provider-456"
}
}
```
Periodo di attribuzione (opzionale)
Il periodo di tempo durante il quale il paziente viene attribuito al fornitore.
Tipo: Periodo
```
{
"name": "attributionPeriod",
"valuePeriod": {
"start": "2024-07-15",
"end": "2025-07-14"
}
}
```
## Esempi di richieste
### Utilizzo dell'ID membro e del provider NPI
```
{
"resourceType": "Parameters",
"parameter": [
{
"name": "memberId",
"valueIdentifier": {
"system": "http://example.org/patient-id",
"value": "patient-new"
}
},
{
"name": "providerNpi",
"valueIdentifier": {
"system": "http://terminology.hl7.org/CodeSystem/NPI",
"value": "1234567890"
}
},
{
"name": "attributionPeriod",
"valuePeriod": {
"start": "2024-07-15",
"end": "2025-07-14"
}
}
]
}
```
### Utilizzo dei riferimenti di pazienti e fornitori
```
{
"resourceType": "Parameters",
"parameter": [
{
"name": "patientReference",
"valueReference": {
"reference": "Patient/patient-123"
}
},
{
"name": "providerReference",
"valueReference": {
"reference": "Practitioner/provider-456"
}
},
{
"name": "attributionPeriod",
"valuePeriod": {
"start": "2024-07-15",
"end": "2025-07-14"
}
}
]
}
```
## Formato della risposta
### Risposta di aggiunta riuscita
```
HTTP Status: 200 OK
Content-Type: application/fhir+json
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "success",
"code": "informational",
"details": {
"text": "Member Patient/patient-new successfully added to the Member Attribution List."
}
}
]
}
```
### Risposte agli errori
Sintassi di richiesta non valida
Stato HTTP: 400 Richiesta errata
```
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "invalid",
"details": {
"text": "Invalid parameter combination provided"
}
}
]
}
```
Risorsa non trovata
Stato HTTP: 404 non trovato
```
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "not-found",
"details": {
"text": "Resource not found."
}
}
]
}
```
Conflitto di versione
Stato HTTP: conflitto 409
```
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "conflict",
"details": {
"text": "Resource version conflict detected"
}
}
]
}
```
Stato di attribuzione non valido
Stato HTTP: 422 Entità non processabile
```
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "business-rule",
"details": {
"text": "Cannot add member to Attribution List with status 'final'. Status must be 'draft' or 'open'."
}
}
]
}
```
## Regole aziendali
Convalida dello stato di attribuzione
L'operazione può essere eseguita solo quando lo stato di attribuzione del gruppo è:
+ `draft`
+ `open`
Le operazioni non sono consentite quando lo stato è`final`.
Prevenzione della duplicazione dei membri
Il sistema impedisce l'aggiunta di membri duplicati in base alla combinazione unica di:
+ Identificatore del membro
+ Identificativo del pagatore
+ Identificatore di copertura
Convalida del periodo di copertura
Quando ne `attributionPeriod` viene fornita una, questa deve rientrare nei limiti del periodo di copertura del socio. Il sistema consentirà di:
+ Cerca la risorsa Coverage del socio
+ Usa la copertura più recente (VersionID più alto) se ne esistono più
+ Verifica che il periodo di attribuzione non superi il periodo di copertura
Convalida del riferimento
Quando vengono forniti sia l'ID che il riferimento per la stessa risorsa (paziente o fornitore), il sistema verifica che corrispondano alla stessa risorsa.
Quando vengono forniti entrambi i campi ID e reference.identifier per la stessa risorsa (paziente o fornitore), viene generato un errore.
## Autenticazione e autorizzazione
L'operazione richiede l'autorizzazione SMART on FHIR per:
+ Autorizzazioni di lettura: per convalidare le risorse di pazienti, fornitori e gruppi
+ Autorizzazioni di ricerca: per trovare risorse in base all'identificatore
+ Aggiorna le autorizzazioni: per modificare la risorsa del gruppo
## Comportamento operativo
Aggiornamenti delle risorse
+ Aggiorna l'ID della versione della risorsa del gruppo
+ Crea una voce di cronologia con lo stato originale della risorsa prima dell'operazione
+ Aggiunge le informazioni sui membri all'array Group.member con:
+ Riferimento al paziente in entity.reference
+ Periodo di attribuzione in periodo
+ Informazioni sulla copertura e sul fornitore nei campi di estensione
Fasi di convalida
+ Convalida dei parametri: garantisce combinazioni di parametri valide
+ Esistenza di risorse: verifica l'esistenza di risorse per pazienti, fornitori e gruppi
+ Stato di attribuzione: conferma che lo stato del gruppo consente modifiche
+ Duplicate Check: impedisce l'aggiunta di membri esistenti
+ Convalida della copertura: garantisce che il periodo di attribuzione rientri nei limiti di copertura
## Limitazioni
+ Tutte le risorse referenziate devono esistere all'interno dello stesso datastore
+ L'operazione funziona solo con le risorse del Member Attribution List Group
+ I periodi di attribuzione devono rientrare nei limiti di copertura
+ Non è possibile modificare i gruppi con lo stato «finale»
# `$member-match`operazione per HealthLake
AWS HealthLake ora supporta l'`$member-match`operazione Patient Resources, consentendo alle organizzazioni sanitarie di trovare l'identificatore univoco di un membro in diversi sistemi sanitari utilizzando informazioni demografiche e di copertura. Questa operazione è essenziale per raggiungere la conformità CMS e facilitare lo scambio sicuro payer-to-payer dei dati, mantenendo al contempo la privacy dei pazienti.
Questa operazione è particolarmente utile quando è necessario:
+ Consentire lo scambio sicuro di dati sanitari tra le organizzazioni
+ Mantieni la continuità dell'assistenza ai pazienti tra diversi sistemi
+ Supporta i requisiti di conformità CMS
+ Facilita l'identificazione accurata dei membri attraverso le reti sanitarie
## Utilizzo
L'`$member-match`operazione può essere richiamata sulle risorse del paziente utilizzando il metodo POST:
```
POST [base]/Patient/$member-match
```
## Parametri supportati
HealthLake supporta i seguenti parametri FHIR`$member-match`:
| Parametro | Tipo | Obbligatorio | Predefinita | Description |
| --- | --- | --- | --- | --- |
| MemberPatient | Paziente | Sì | — | Risorsa per il paziente contenente informazioni demografiche relative al membro da abbinare |
| CoverageToMatch | Copertura | Sì | — | Risorsa di copertura che verrà utilizzata per il confronto con i record esistenti |
| CoverageToLink | Copertura | No | — | Risorsa di copertura da collegare durante il processo di abbinamento |
| Consenso | Consenso | No | — | Risorsa di consenso a fini di autorizzazione |
## Esempi
### Richiesta POST con parametri
```
POST [base]/Patient/$member-match
Content-Type: application/fhir+json
{
"resourceType": "Parameters",
"parameter": [
{
"name": "MemberPatient",
"resource": {
"resourceType": "Patient",
"name": [
{
"family": "Jones",
"given": ["Sarah"]
}
],
"gender": "female",
"birthDate": "1985-05-15"
}
},
{
"name": "CoverageToMatch",
"resource": {
"resourceType": "Coverage",
"status": "active",
"beneficiary": {
"reference": "Patient/1"
},
"relationship": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/subscriber-relationship",
"code": "self",
"display": "Self"
}
]
},
"payor": [
{
"reference": "Organization/payer456"
}
]
}
},
{
"name": "Consent",
"resource": {
"resourceType": "Consent",
"status": "active",
"scope": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/consentscope",
"code": "patient-privacy"
}
]
},
"category": [
{
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/v3-ActCode",
"code": "IDSCL"
}
]
}
],
"patient": {
"reference": "Patient/1"
},
"performer": [
{
"reference": "Patient/patient123"
}
],
"sourceReference": {
"reference": "Document/someconsent"
},
"policy": [
{
"uri": "http://hl7.org/fhir/us/davinci-hrex/StructureDefinition-hrex-consent.html#regular"
}
]
}
}
]
}
```
### Risposta di esempio
L'operazione restituisce una risorsa Parameters contenente i risultati corrispondenti:
```
{
"resourceType": "Parameters",
"parameter": [
{
"name": "MemberIdentifier",
"valueIdentifier": {
"system": "http://hospital.org/medical-record-number",
"value": "MRN-123456"
}
},
{
"name": "MemberId",
"valueReference": {
"reference": "Patient/patient123"
}
},
{
"name": "matchAlgorithm",
"valueString": "DEMOGRAPHIC_MATCH"
},
{
"name": "matchDetails",
"valueString": "Demographic match: DOB + Name"
},
{
"name": "matchedFields",
"valueString": "given,birthdate,gender,family"
}
]
}
```
## Parametri di risposta
La risposta include i seguenti parametri quando viene trovata una corrispondenza:
| Parametro | Tipo | Description |
| --- | --- | --- |
| MemberIdentifier | Identificatore | L'identificatore univoco per il membro corrispondente |
| MemberId | Documentazione di riferimento | Riferimento alla risorsa Patient |
| Match Algoritm | Stringa | Tipo di algoritmo di corrispondenza utilizzato (EXACT\$1MATCH, STRONG\$1MATCH o DEMOGRAPHIC\$1MATCH) |
| Dettagli della partita | Stringa | Informazioni dettagliate sul processo di abbinamento |
| Campi corrispondenti | Stringa | Elenco di campi specifici che sono stati abbinati correttamente |
## Algoritmi di corrispondenza
L'`$member-match`API utilizza un approccio di abbinamento a più livelli per garantire un'identificazione accurata dei membri:
EXACT\$1MATCH
Utilizza l'identificatore del paziente combinato con la copertura SubscriberId
Fornisce il massimo livello di confidenza per l'abbinamento dei membri
STRONG\$1MATCH
Utilizza Patient Identifier con informazioni minime sulla copertura
Offre un'elevata affidabilità quando non vengono soddisfatti i criteri di corrispondenza esatti
ABBINAMENTO DEMOGRAFICO
Si basa su informazioni demografiche di base
Utilizzato quando non è possibile la corrispondenza basata su identificatori
## Comportamento
L'operazione: `$member-match`
+ Accetta come input i dati demografici dei pazienti, i dettagli sulla copertura e le informazioni facoltative sul consenso
+ Restituisce un identificatore di membro univoco che può essere utilizzato per le interazioni successive
+ Implementa la corrispondenza a più livelli (esatta, forte, demografica) per garantire l'identificazione accurata dei membri nei diversi sistemi sanitari
+ Salva tutte le informazioni di consenso fornite per scopi di autorizzazione futuri
+ Supporta lo scambio sicuro di payer-to-payer dati mantenendo al contempo la privacy del paziente
+ Conforme ai requisiti CMS per lo scambio di dati sanitari
## Autorizzazione
L'API utilizza il protocollo di autorizzazione SMART on FHIR con i seguenti ambiti richiesti:
+ `system/Patient.read`
+ `system/Coverage.read`
+ `system/Organization.read`(condizionale)
+ `system/Practitioner.read`(condizionale)
+ `system/PractitionerRole.read`(condizionale)
+ `system/Consent.write`(condizionale)
## Gestione errori
L'operazione gestisce le seguenti condizioni di errore:
+ `400 Bad Request`: `$member-match` operazione non valida (richiesta non conforme o parametri obbligatori mancanti)
+ `422 Unprocessable Entity`: nessuna corrispondenza o più corrispondenze trovate
# `$member-remove`operazione per HealthLake
L'`$member-remove`operazione consente di rimuovere membri da una lista di attribuzione dei membri FHIR (risorsa di gruppo) in. AWS HealthLake Questa operazione fa parte della DaVinci Member Attribution Implementation Guide e supporta il processo di riconciliazione per la gestione delle attribuzioni dei membri.
## Prerequisiti
+ AWS HealthLake Datastore FHIR
+ Autorizzazioni IAM appropriate per le operazioni HealthLake
+ Elenco di attribuzione dei membri (risorsa di gruppo) in bozza o in stato aperto
## Dettagli dell'operazione
Endpoint
`POST /Group/{id}/$member-remove`
Content Type
`application/fhir+json`
## Parameters
L'operazione accetta una risorsa FHIR Parameters con i seguenti parametri opzionali:
| Parametro | Cardinalità | Tipo | Description |
| --- | --- | --- | --- |
| memberId | 0.1.. | Identificatore | Identificativo aziendale del membro da rimuovere |
| ProviderNPI | 0.1.. | Identificatore | NPI del fornitore attribuito |
| Riferimento per il paziente | 0.. 1 | Documentazione di riferimento | Riferimento diretto alla risorsa per i pazienti |
| Riferimento del fornitore | 0.1.. | Documentazione di riferimento | Riferimento diretto alla risorsa del Fornitore (professionista o PractitionerRole organizzazione) |
| Riferimento alla copertura | 0.1.. | Documentazione di riferimento | Riferimento alla risorsa Coverage |
### Combinazioni di parametri supportate
Sono supportate le seguenti combinazioni di parametri:
+ `memberId`solo: rimuove tutte le attribuzioni per il membro specificato
+ `memberId`\$1 `providerNpi` - Rimuove le attribuzioni per la specifica combinazione membro-provider
+ `patientReference`solo: rimuove tutte le attribuzioni per il paziente specificato
+ `patientReference`\$1 `providerReference` - Rimuove le attribuzioni per la combinazione specifica paziente-operatore
+ `patientReference``providerReference`\$1 `coverageReference` - Rimuove l'attribuzione specifica in base al paziente, al fornitore e alla copertura
## Esempio di richiesta
```
{
"resourceType": "Parameters",
"parameter": [
{
"name": "patientReference",
"valueReference": {
"reference": "Patient/12345"
}
},
{
"name": "providerReference",
"valueReference": {
"reference": "Practitioner/67890"
}
}
]
}
```
## Risposta
### Risposta riuscita
```
{
"resourceType": "Parameters",
"parameter": [
{
"name": "result",
"valueBoolean": true
},
{
"name": "effectiveDate",
"valueDate": "2024-06-30"
},
{
"name": "status",
"valueCode": "inactive"
},
{
"name": "message",
"valueString": "Member successfully removed from attribution list"
}
]
}
```
## Comportamento
Requisiti di status
L'operazione funziona solo su elenchi di attribuzione con stato o `draft` `open`
Gli elenchi con `final` stato rifiuteranno l'operazione con un errore 422
Procedura di rimozione dei membri
*Bozze di elenchi di status*: i membri sono contrassegnati come inattivi (`inactive: true`) e la loro `changeType` estensione è aggiornata a `changed`
*Liste di stato aperte*: comportamento simile alla bozza di stato
*Elenchi di stato finali*: l'operazione è rifiutata
Convalida
I riferimenti vengono convalidati per garantire che esistano nel HealthLake datastore
Se vengono forniti sia l'identificatore che il riferimento per lo stesso tipo di risorsa, devono corrispondere alla stessa risorsa
Le combinazioni di parametri vengono convalidate in base ai modelli supportati
## Gestione errori
### Risposte di errore comuni
Risorsa non trovata (404)
```
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "not-found",
"details": {
"text": "Patient with identifier 'http://example.org/fhir/identifiers|99999' not found in system"
},
"diagnostics": "Cannot remove member from attribution list. Verify patient identifier and try again.",
"expression": ["memberId"]
}
]
}
```
Stato finale dell'elenco di attribuzione (422)
```
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "business-rule",
"details": {
"coding": [
{
"system": "http://hl7.org/fhir/us/davinci-atr/CodeSystem/atr-error-codes",
"code": "list-final",
"display": "Attribution list is final and cannot be modified"
}
]
},
"diagnostics": "Cannot modify attribution list with status 'final'. List modifications are not permitted after finalization.",
"expression": ["Group.status"]
}
]
}
```
Operazione non valida (400)
Restituito quando le combinazioni di parametri non sono valide o non sono corrette.
Trovate più corrispondenze (412)
Restituito quando i parametri forniti corrispondono a più membri nell'elenco di attribuzione.
```
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "processing",
"diagnostics": "Multiple members found matching the criteria"
}
]
}
```
## Best practice
+ *Usa parametri specifici*: quando possibile, utilizza la combinazione di parametri più specifica per evitare rimozioni involontarie
+ Stato della *lista di controllo: verifica lo stato* dell'elenco di attribuzione prima di tentare le rimozioni
+ *Gestisci gli errori con garbo*: implementa una corretta gestione degli errori per tutte le possibili condizioni di errore
+ *Convalida i riferimenti*: assicurati che tutte le risorse referenziate esistano prima di effettuare la richiesta
# Eliminazione delle risorse del comparto paziente con `$purge`
AWS HealthLake supporta l'`$purge`operazione, consentendo l'eliminazione permanente di tutte le risorse all'interno del compartimento del paziente. Questa operazione è particolarmente utile quando è necessario:
+ Rimuovere tutti i dati associati a un paziente
+ Rispetta le richieste di rimozione dei dati dei pazienti
+ Gestisci il ciclo di vita dei dati dei pazienti
+ Esegui una pulizia completa delle cartelle cliniche dei pazienti
## Utilizzo
L'`$purge`operazione può essere richiamata sulle risorse del paziente:
```
POST [base]/Patient/[ID]/$purge?deleteAuditEvent=true
```
## Parameters
| Parametro | Tipo | Obbligatorio | Predefinita | Description |
| --- | --- | --- | --- | --- |
| deleteAuditEvent | booleano | No | false | Se impostato su true, elimina gli eventi di controllo associati |
| \$1since | stringa | No | Ora di creazione del datastore | Una volta inserito, seleziona l'orario limite iniziale per trovare le risorse in base all'ora dell'ultima modifica. Non può essere utilizzato con start o end |
| start | stringa | No | Ora di creazione del datastore | Una volta inserito, seleziona l'orario limite per la ricerca delle risorse in base all'ora dell'ultima modifica. Può essere usato con fine |
| end | stringa | No | Ora di invio del lavoro | Una volta inserito, seleziona l'orario limite finale per trovare le risorse in base all'ora dell'ultima modifica |
## Esempi
**Richiesta di esempio**
```
POST [base]/Patient/example-patient/$purge?deleteAuditEvent=true
```
**Risposta di esempio**
```
{
"resourceType": "OperationOutcome",
"id": "purge-job",
"issue": [
{
"severity": "information",
"code": "informational",
"diagnostics": "Purge job started successfully. Job ID: 12345678-1234-1234-1234-123456789012"
}
]
}
```
## Stato di un processo
Per verificare lo stato di un processo di eliminazione:
```
GET [base]/$purge/[jobId]
```
L'operazione restituisce informazioni sullo stato del lavoro:
```
{
"datastoreId": "36622996b1fcecb7e12ee2ee085308d3",
"jobId": "3dd1c7a5b6c0ef8c110f566eb87e2ef9",
"status": "COMPLETED",
"submittedTime": "2025-10-31T18:43:21.822Z"
}
```
## Comportamento
L'`$purge`operazione:
1. Processi in modo asincrono per gestire più risorse
1. Mantiene le transazioni ACID per l'integrità dei dati
1. Fornisce il monitoraggio dello stato del lavoro con il conteggio delle eliminazioni delle risorse
1. Rimuove definitivamente tutte le risorse presenti nel compartimento del paziente
1. Include una registrazione di controllo completa delle attività di eliminazione
1. Supporta l'eliminazione selettiva degli eventi di controllo
## Registrazione degli audit
Le `$purge` operazioni vengono registrate come Start FHIRBulk DeleteJob e Descrivi FHIRBulk DeleteJob con informazioni dettagliate sull'operazione.
## Limitazioni
+ Le risorse eliminate non verranno visualizzate nelle risposte di ricerca
+ Le risorse eliminate potrebbero essere temporaneamente inaccessibili durante l'elaborazione
+ Tutte le risorse presenti nel compartimento del paziente vengono rimosse definitivamente
# `$questionnaire-package`Operazione FHIR per HealthLake
L'`$questionnaire-package`operazione recupera un pacchetto completo contenente un questionario FHIR e tutte le sue dipendenze necessarie per il rendering e l'elaborazione del questionario. Questa operazione implementa la [Da Vinci Documentation Templates and Rules (DTR) Implementation Guide, che consente il rendering dinamico dei moduli per i requisiti di documentazione](https://hl7.org/fhir/us/davinci-dtr/OperationDefinition-questionnaire-package.html) nei flussi di lavoro sanitari.
## Come funziona
+ **Richiesta**: inviate i parametri che identificano il questionario o i questionari necessari, insieme alla copertura e al contesto dell'ordine
+ **Recupera**: HealthLake raccoglie il questionario e tutte le dipendenze (, librerie CQL, ecc.) ValueSets
+ **Package**: Tutte le risorse sono raggruppate in un formato standardizzato
+ **Rispondi**: Riceverai un pacchetto completo pronto per il rendering e la raccolta dei dati
**Casi d'uso**
+ **Documentazione di autorizzazione preventiva**: raccoglie le informazioni cliniche necessarie per le richieste di autorizzazione preventiva
+ **Requisiti di copertura**: raccogliere la documentazione necessaria per soddisfare i requisiti di copertura dei pagatori
+ **Clinical Data Exchange**: struttura dei dati clinici da presentare ai pagatori
+ **Moduli dinamici**: renderizza i questionari con dati precompilati sui pazienti e logica condizionale
## Endpoint API
```
POST /datastore/{datastoreId}/r4/Questionnaire/$questionnaire-package
Content-Type: application/fhir+json
```
## Parametri della richiesta
### Parametri di input
Il corpo della richiesta deve contenere una risorsa FHIR Parameters con i seguenti parametri:
| Parametro | Tipo | Cardinalità | Description |
| --- | --- | --- | --- |
| coverage | Copertura | 1.. \$1 (Obbligatorio) | Risorse/e di copertura per stabilire il membro e copertura della documentazione |
| questionnaire | canonico | 0.. \$1 | URL canonici per uno o più questionari specifici da restituire (la versione può includere) |
| order | Risorsa | 0.. \$1 | Ordina le risorse (DeviceRequest, ServiceRequest, MedicationRequest, Encounter, Appointment) per stabilire il contesto |
| changedSince | dateTime | 0.1. | Se presenti, restituisce solo le risorse modificate dopo questo timestamp |
### Regole di convalida dei parametri
È **necessario fornire almeno UNO dei seguenti elementi** (oltre a quelli obbligatori`coverage`):
+ Uno o più `questionnaire` canonici URLs
+ Una o più risorse `order`
**Combinazioni di richieste valide:**
+ `coverage` \$1 `questionnaire`
+ `coverage` \$1 `order`
+ `coverage` \$1 `questionnaire` \$1 `order`
## Richiesta di esempio
```
POST /datastore/example-datastore/r4/Questionnaire/$questionnaire-package
Content-Type: application/fhir+json
Authorization: Bearer
{
"resourceType": "Parameters",
"parameter": [
{
"name": "coverage",
"resource": {
"resourceType": "Coverage",
"id": "example-coverage",
"status": "active",
"beneficiary": {
"reference": "Patient/example-patient"
},
"payor": [{
"reference": "Organization/example-payer"
}],
"class": [{
"type": {
"coding": [{
"system": "http://terminology.hl7.org/CodeSystem/coverage-class",
"code": "group"
}]
},
"value": "12345"
}]
}
},
{
"name": "questionnaire",
"valueCanonical": "http://example.org/fhir/Questionnaire/home-oxygen-therapy|2.0"
},
{
"name": "order",
"resource": {
"resourceType": "ServiceRequest",
"id": "example-service-request",
"status": "active",
"intent": "order",
"code": {
"coding": [{
"system": "http://www.ama-assn.org/go/cpt",
"code": "94660",
"display": "Continuous positive airway pressure ventilation (CPAP)"
}]
},
"subject": {
"reference": "Patient/example-patient"
}
}
},
{
"name": "changedSince",
"valueDateTime": "2024-01-01T00:00:00Z"
}
]
}
```
## Formato della risposta
### Risposta riuscita (200 OK)
L'operazione restituisce una risorsa FHIR Parameters contenente uno o più **Package Bundle**. Ogni pacchetto Package include:
| Tipo di ingresso | Cardinalità | Description |
| --- | --- | --- |
| Questionario | 1 | Il questionario da rendere |
| QuestionnaireResponse | 0.1.. | Risposta precompilata o parzialmente completata (se applicabile) |
| Libreria | 0.. \$1 | Librerie CQL contenenti logica condizionale e di precompilazione |
| ValueSet | 0.. \$1 | Espanso ValueSets (per scelte di risposta con <40 espansioni) |
**Example Esempio di risposta**
```
{
"resourceType": "Parameters",
"parameter": [
{
"name": "PackageBundle",
"resource": {
"resourceType": "Bundle",
"id": "questionnaire-package-example",
"meta": {
"profile": ["http://hl7.org/fhir/us/davinci-dtr/StructureDefinition/DTR-QPackageBundle"]
},
"type": "collection",
"timestamp": "2024-03-15T10:30:00Z",
"entry": [
{
"fullUrl": "http://example.org/fhir/Questionnaire/home-oxygen-therapy",
"resource": {
"resourceType": "Questionnaire",
"id": "home-oxygen-therapy",
"url": "http://example.org/fhir/Questionnaire/home-oxygen-therapy",
"version": "2.0",
"status": "active",
"title": "Home Oxygen Therapy Documentation",
"item": [
{
"linkId": "1",
"text": "Patient diagnosis",
"type": "choice",
"answerValueSet": "http://example.org/fhir/ValueSet/oxygen-diagnoses"
}
]
}
},
{
"fullUrl": "http://example.org/fhir/Library/oxygen-prepopulation",
"resource": {
"resourceType": "Library",
"id": "oxygen-prepopulation",
"url": "http://example.org/fhir/Library/oxygen-prepopulation",
"version": "1.0",
"type": {
"coding": [{
"system": "http://terminology.hl7.org/CodeSystem/library-type",
"code": "logic-library"
}]
},
"content": [{
"contentType": "text/cql",
"data": "bGlicmFyeSBPeHlnZW5QcmVwb3B1bGF0aW9u..."
}]
}
},
{
"fullUrl": "http://example.org/fhir/ValueSet/oxygen-diagnoses",
"resource": {
"resourceType": "ValueSet",
"id": "oxygen-diagnoses",
"url": "http://example.org/fhir/ValueSet/oxygen-diagnoses",
"status": "active",
"expansion": {
"timestamp": "2024-03-15T10:30:00Z",
"contains": [
{
"system": "http://hl7.org/fhir/sid/icd-10",
"code": "J44.0",
"display": "COPD with acute lower respiratory infection"
},
{
"system": "http://hl7.org/fhir/sid/icd-10",
"code": "J96.01",
"display": "Acute respiratory failure with hypoxia"
}
]
}
}
},
{
"fullUrl": "http://example.org/fhir/QuestionnaireResponse/example-prepopulated",
"resource": {
"resourceType": "QuestionnaireResponse",
"id": "example-prepopulated",
"questionnaire": "http://example.org/fhir/Questionnaire/home-oxygen-therapy|2.0",
"status": "in-progress",
"subject": {
"reference": "Patient/example-patient"
},
"basedOn": [{
"reference": "ServiceRequest/example-service-request"
}],
"item": [
{
"linkId": "1",
"text": "Patient diagnosis",
"answer": [{
"valueCoding": {
"system": "http://hl7.org/fhir/sid/icd-10",
"code": "J44.0",
"display": "COPD with acute lower respiratory infection"
}
}]
}
]
}
}
]
}
},
{
"name": "Outcome",
"resource": {
"resourceType": "OperationOutcome",
"issue": [{
"severity": "information",
"code": "informational",
"details": {
"text": "Successfully retrieved questionnaire package"
}
}]
}
}
]
}
```
## Flusso di lavoro operativo
**Come HealthLake elabora la tua richiesta**
Quando chiami`$questionnaire-package`, HealthLake effettua le seguenti operazioni:
1. **Identify Patient & Payer**: estrae il paziente e l'organizzazione assicurativa dal parametro. `coverage`
1. **Trova il questionario giusto**:
+ **Con `questionnaire`** **parametro**: utilizza l'URL canonico che hai fornito
+ **Con `order`** **parametro**: corrisponde al codice dell'ordine (CPT/HCPCS/LOINC) e al pagatore per trovare il questionario appropriato
1. **Raccogli le dipendenze**: recupera automaticamente tutto ciò che serve per il rendering del questionario:
+ **Librerie CQL** - Logica per domande condizionali e preliminari
+ **ValueSets**- Scelte di risposta (espanse automaticamente se <40 opzioni)
+ **QuestionnaireResponse**- Eventuali risposte esistenti in corso o completate
1. **Package tutto insieme**:
+ Raggruppa tutte le risorse (ogni risorsa è inclusa una sola volta)
+ Filtra per `changedSince` timestamp, se fornito
+ Aggiunge avvisi in `Outcome` caso di mancanza di risorse
**Risultato**: un pacchetto completo e autonomo pronto per il rendering.
## Risposte agli errori
### 400 Richiesta non valida
Restituito quando la convalida della richiesta fallisce.
```
{
"resourceType": "OperationOutcome",
"issue": [{
"severity": "error",
"code": "required",
"details": {
"text": "At least one of 'questionnaire' or 'order' must be provided along with 'coverage'"
}
}]
}
```
### 4.2.4 Dipendenza non riuscita
Restituito quando una risorsa dipendente non può essere recuperata.
```
{
"resourceType": "OperationOutcome",
"issue": [{
"severity": "warning",
"code": "not-found",
"details": {
"text": "Referenced Library 'http://example.org/fhir/Library/missing-library' could not be retrieved"
}
}]
}
```
### 401 - Autorizzazione negata
Restituito quando le credenziali di autenticazione sono mancanti o non valide.
### 403 Non consentito
Restituito quando l'utente autenticato non è autorizzato ad accedere alle risorse richieste.
### 406 Non accettabile
Restituito quando non è possibile fornire il tipo di contenuto richiesto.
### 409 Conflitto
Restituito in caso di conflitto di versione o concorrenza.
### 410 Andato
Restituito quando la risorsa richiesta è stata eliminata definitivamente.
### 429 Troppe richieste
Restituito quando vengono superati i limiti di velocità.
### 500 - Errore interno del server
Restituito quando si verifica un errore imprevisto del server.
### 501 non implementato
Restituito quando l'operazione richiesta non è ancora implementata.
## Regole di convalida
### Convalida dell'input
+ `coverage`il parametro è **obbligatorio** (1.. \$1 cardinalità)
+ Almeno uno `questionnaire` o `order` deve essere fornito
+ Tutte le risorse di copertura devono essere risorse FHIR valide
+ Tutte le risorse dell'Ordine devono essere risorse FHIR valide
+ Canonical URLs deve essere formattato correttamente
+ `changedSince`deve essere un DateTime ISO 8601 valido
### QuestionnaireResponse convalida
+ `status`deve essere appropriato (`in-progress`,`completed`,`amended`)
+ La struttura deve corrispondere al questionario di riferimento
+ `basedOn`deve fare riferimento a risorse Order valide
+ `subject`deve fare riferimento a risorse valide per i pazienti
### Deduplicazione delle risorse
+ Ogni risorsa appare solo una volta nel pacchetto
+ Eccezione: è possibile includere entrambe versioni diverse della stessa risorsa
+ Le risorse sono identificate in base all'URL e alla versione canonici
## Specifiche prestazionali
| Metrica | Specifiche |
| --- | --- |
| Limite di conteggio delle risorse | 500 risorse per pacchetto |
| Limite di dimensione del pacchetto | Massimo 5 MB |
## Autorizzazioni richieste
Per utilizzare l'`$questionnaire-package`operazione, assicurati che il tuo ruolo IAM abbia:
+ `healthlake:QuestionnairePackage`- Per richiamare l'operazione
+ `healthlake:ReadResource`- Per recuperare il questionario e le risorse dipendenti
+ `healthlake:SearchWithPost`- Per cercare risorse correlate QuestionnaireResponse
**SMART su FHIR Scopes**
**Ambiti minimi richiesti:**
+ **SMART v1:** `user/Questionnaire.read user/Library.read user/ValueSet.read user/QuestionnaireResponse.read`
+ **SMART versione 2:** `user/Questionnaire.rs user/Library.rs user/ValueSet.rs user/QuestionnaireResponse.rs`
## Note importanti sull'implementazione
### Strategia di recupero delle risorse
**Priorità di identificazione del questionario:**
+ **URL canonico** (se il `questionnaire` parametro è stato fornito) - Priorità massima
+ **Analisi dell'ordine** (se il `order` parametro è fornito):
+ Abbina i codici degli ordini (CPT, HCPCS, LOINC) alle politiche mediche dei paganti
+ Utilizza Coverage Payor per filtrare i questionari specifici per ciascun pagatore
+ Prendi in considerazione i codici dei motivi per un contesto aggiuntivo
### Risoluzione delle dipendenze
**Librerie CQL:**
+ Recuperato tramite l'`cqf-library`estensione sulle risorse del questionario
+ Recupera ricorsivamente le librerie dipendenti tramite type `Library.relatedArtifact` `depends-on`
+ Tutte le dipendenze della libreria sono incluse nel pacchetto
**ValueSets:**
+ Si espandono automaticamente se contengono meno di 40 concetti
+ ValueSets I più grandi sono inclusi senza espansione
+ ValueSets a cui si fa riferimento sia nel Questionario che nelle risorse della Libreria sono incluse
### QuestionnaireResponse prepopolazione
L'operazione può restituire un file QuestionnaireResponse con dati precompilati quando:
+ Viene trovata una risposta esistente in corso o completata
+ La logica CQL nelle librerie associate può estrarre dati dalle cartelle cliniche dei pazienti
+ La risposta è collegata all'ordine e alla copertura pertinenti
**Criteri di ricerca per QuestionnaireResponse:**
| Parametro di ricerca | Percorso FHIR | Description |
| --- | --- | --- |
| based-on | QuestionnaireResponse.basedOn | Collegamenti a o ServiceRequest CarePlan |
| patient | QuestionnaireResponse.subject | Il paziente che è il soggetto |
| questionnaire | QuestionnaireResponse.questionnaire | Il questionario a cui si sta rispondendo |
### Filtraggio delle risorse modificato
Quando viene fornito il `changedSince` parametro:
+ Sono incluse solo le risorse modificate **dopo** il timestamp specificato
+ Se nessuna risorsa è stata modificata, ritorna `200 OK` con un pacchetto vuoto
+ Utile per aggiornamenti incrementali e strategie di memorizzazione nella cache
+ Il confronto dei timestamp utilizza il campo delle risorse `meta.lastUpdated`
### Pacchetti multipli
L'operazione può restituire **più Package Bundle** quando:
+ Vengono richiesti più questionari tramite canonical URLs
+ Ordini multipli richiedono questionari diversi
+ Sono applicabili versioni diverse dello stesso questionario
Ogni Package Bundle è autonomo con tutte le dipendenze necessarie.
## Casi di utilizzo comune
### Caso d'uso 1: documentazione di autorizzazione preventiva
**Scenario**: un fornitore deve raccogliere la documentazione per un'autorizzazione preventiva di ossigenoterapia domiciliare.
```
{
"resourceType": "Parameters",
"parameter": [
{
"name": "coverage",
"resource": { /* Patient's insurance coverage */ }
},
{
"name": "order",
"resource": {
"resourceType": "ServiceRequest",
"code": {
"coding": [{
"system": "http://www.ama-assn.org/go/cpt",
"code": "94660"
}]
}
}
}
]
}
```
**Risultato**: restituisce un pacco con il questionario di ossigenoterapia, precompilato con i dati anagrafici dei pazienti e i codici di diagnosi dell'EHR.
### Caso d'uso 2: recupero di una versione specifica del questionario
**Scenario**: un provider necessita di una versione specifica di un questionario per la conformità.
```
{
"resourceType": "Parameters",
"parameter": [
{
"name": "coverage",
"resource": { /* Coverage resource */ }
},
{
"name": "questionnaire",
"valueCanonical": "http://example.org/fhir/Questionnaire/dme-request|3.1.0"
}
]
}
```
**Risultato**: restituisce esattamente la versione 3.1.0 del questionario di richiesta DME con tutte le dipendenze.
### Caso d'uso 3: verifica la presenza di aggiornamenti
**Scenario**: un provider desidera verificare se alcune risorse del questionario sono state aggiornate dall'ultimo recupero.
```
{
"resourceType": "Parameters",
"parameter": [
{
"name": "coverage",
"resource": { /* Coverage resource */ }
},
{
"name": "questionnaire",
"valueCanonical": "http://example.org/fhir/Questionnaire/medication-request"
},
{
"name": "changedSince",
"valueDateTime": "2024-03-01T00:00:00Z"
}
]
}
```
**Risultato**: restituisce solo le risorse che sono state modificate dopo il 1° marzo 2024 o un pacchetto vuoto se non è cambiato nulla.
### Caso d'uso 4: ordini multipli
**Scenario**: un provider invia più richieste di assistenza che possono richiedere questionari diversi.
```
{
"resourceType": "Parameters",
"parameter": [
{
"name": "coverage",
"resource": { /* Coverage resource */ }
},
{
"name": "order",
"resource": { /* ServiceRequest for imaging */ }
},
{
"name": "order",
"resource": { /* ServiceRequest for DME */ }
}
]
}
```
**Risultato**: restituisce più Package Bundle, uno per ogni questionario applicabile.
## Integrazione con Other Da Vinci IGs
### Discovery dei requisiti di copertura (CRD)
**Integrazione del flusso di lavoro:**
+ Il fornitore ordina un servizio nel proprio EHR
+ Il CRD si blocca, verifica dei requisiti di copertura
+ Il pagatore risponde indicando che è necessaria la documentazione
+ Il provider chiama `$questionnaire-package` per recuperare il modulo di documentazione
+ Il provider completa il questionario
+ La documentazione viene inviata tramite PAS o CDex
### Support di autorizzazione preventiva (PAS)
**Integrazione del flusso di lavoro:**
+ Utilizzare `$questionnaire-package` per recuperare i requisiti di documentazione
+ Completare il modulo QuestionnaireResponse con i dati clinici richiesti
+ Inviare l'autorizzazione preventiva utilizzando `Claim/$submit` con il QuestionnaireResponse
+ Controlla lo stato utilizzando `Claim/$inquire`
### Data Exchange clinico (CDex)
**Integrazione del flusso di lavoro:**
+ Il pagante richiede documentazione aggiuntiva per un reclamo
+ Il fornitore utilizza `$questionnaire-package` per recuperare il modulo di raccolta dei dati strutturati
+ Il fornitore completa il QuestionnaireResponse
+ La documentazione viene inviata al pagatore tramite CDex il flusso di lavoro in allegato
## Guida alla risoluzione dei problemi
### Problema: nessun questionario restituito
**Possibili cause:**
+ L'URL canonico non corrisponde a nessun questionario nell'archivio dati
+ Il codice dell'ordine non corrisponde a nessun questionario nella politica medica del pagatore
+ Il beneficiario della copertura non dispone di questionari associati
**Soluzioni:**
+ Verifica che l'URL canonico sia corretto e che il questionario esista
+ Verifica che i codici d'ordine (CPT/HCPCS) siano specificati correttamente
+ Conferma che i questionari siano configurati per il pagatore o l'organizzazione
### Problema: dipendenze mancanti nel pacchetto
**Possibili cause:**
+ Libreria referenziata o ValueSet non esiste nell'archivio dati
+ I riferimenti alla libreria sono interrotti o errati
+ ValueSet espansione non riuscita
**Soluzioni:**
+ Controlla il `Outcome` parametro per gli avvisi relativi alle risorse mancanti
+ Verifica che tutte le risorse di riferimento esistano nel tuo archivio dati
+ Assicurati che ValueSet URLs siano corretti e risolvibili
### Problema: Package vuoto con ChangedSince
**Possibili cause:**
+ Questo è il comportamento previsto: nessuna risorsa è stata modificata dopo il timestamp specificato
**Soluzioni:**
+ Usa la versione cache del pacchetto
+ Rimuovi il `changedSince` parametro per recuperare il pacchetto completo
### Problema: QuestionnaireResponse non precompilato
**Possibili cause:**
+ Nessun elemento esistente QuestionnaireResponse trovato
+ La logica della libreria CQL non è in grado di estrarre i dati richiesti
+ I dati del paziente sono mancanti o incompleti
**Soluzioni:**
+ Questo è prevedibile: non tutti i questionari hanno una logica di prepopolazione
+ Verificate che i dati del paziente esistano nell'archivio dati
+ Rivedi la logica della libreria CQL per i requisiti di estrazione dei dati
## Best practice
### 1. Usa Canonical URLs con le versioni
Specificate sempre i numeri di versione quando richiedete questionari specifici:
```
{
"name": "questionnaire",
"valueCanonical": "http://example.org/fhir/Questionnaire/dme|2.1.0"
}
```
**Perché**: garantisce la coerenza e previene modifiche impreviste quando i questionari vengono aggiornati.
### 2. Sfrutta ChangedSince per le prestazioni
Per i questionari a cui si accede di frequente, utilizza `changedSince` per ridurre al minimo il trasferimento dei dati:
```
{
"name": "changedSince",
"valueDateTime": "2024-03-10T15:30:00Z"
}
```
**Perché**: riduce la latenza e l'utilizzo della larghezza di banda recuperando solo le risorse aggiornate.
### 3. Includi informazioni complete sulla copertura
Fornisci dettagli completi sulla copertura per garantire la corretta selezione del questionario:
```
{
"name": "coverage",
"resource": {
"resourceType": "Coverage",
"beneficiary": { "reference": "Patient/123" },
"payor": [{ "reference": "Organization/payer-abc" }],
"class": [{ /* Group/plan information */ }]
}
}
```
**Perché**: aiuta a HealthLake identificare i questionari e i requisiti specifici del pagatore.
## Operazioni correlate
+ `Claim/$submit`- Invia richieste di autorizzazione preventiva con documentazione completa
+ `Claim/$inquire`- Verifica lo stato delle autorizzazioni precedenti inviate
+ `ValueSet/$expand`- Espandi ValueSets per visualizzare le opzioni di risposta
# `$submit`Operazione FHIR per HealthLake
L'`$submit`operazione consente di inviare elettronicamente richieste di autorizzazione preventiva ai pagatori per l'approvazione. Questa operazione implementa la [Da Vinci Prior Authorization Support (PAS) Implementation Guide](https://hl7.org/fhir/us/davinci-pas/), che fornisce un flusso di lavoro standardizzato basato su FHIR per l'invio di autorizzazioni preventive.
## Come funziona
+ **Invio: si invia** un pacchetto FHIR contenente la richiesta di autorizzazione preventiva e i dati clinici di supporto
+ **Convalida**: HealthLake convalida l'invio rispetto ai requisiti PAS
+ **Persiste**: tutte le risorse sono archiviate nel tuo archivio dati HealthLake
+ **Rispondi**: ricevi una risposta immediata con lo stato «in coda»
+ **Processo**: la decisione di autorizzazione viene elaborata in modo asincrono dal pagatore
## Endpoint API
```
POST /datastore/{datastoreId}/r4/Claim/$submit
Content-Type: application/fhir+json
```
## Struttura della richiesta
### Requisiti del pacchetto
La tua richiesta deve essere una risorsa FHIR Bundle con:
+ **Bundle.type: Deve** essere `"collection"`
+ **bundle.entry****: deve contenere esattamente una risorsa Claim con** `use = "preauthorization"`
+ **Risorse referenziate**: tutte le risorse a cui fa riferimento il reclamo devono essere incluse nel pacchetto
### Risorse obbligatorie
| Risorsa | Cardinalità | Profilo | Description |
| --- | --- | --- | --- |
| Reclamo | 1 | Reclamo PAS | La richiesta di autorizzazione preventiva |
| Paziente | 1 | Paziente PAS | Informazioni demografiche sui pazienti |
| Organizzazione (assicuratore) | 1 | Assicuratore PAS | Compagnia assicurativa |
| Organizzazione (fornitore) | 1 | Richiedente PAS | Fornitore di assistenza sanitaria che invia la richiesta |
| Copertura | 1 o più | Copertura PAS | Dettagli della copertura assicurativa |
### Risorse opzionali
| Risorsa | Cardinalità | Profilo | Description |
| --- | --- | --- | --- |
| Professionista | 0 o più | Professionista PAS | Operatori sanitari |
| PractitionerRole | 0 o più | PAS PractitionerRole | Ruoli del professionista |
| ServiceRequest | 0 o più | PAS ServiceRequest | Servizi medici richiesti |
| DeviceRequest | 0 o più | PAS DeviceRequest | Dispositivi medici richiesti |
| MedicationRequest | 0 o più | PAS MedicationRequest | Farmaci richiesti |
| DocumentReference | 0 o più | PAS DocumentReference | Documentazione clinica di supporto |
## Richiesta di esempio
```
POST /datastore/example-datastore/r4/Claim/$submit
Content-Type: application/fhir+json
Authorization: Bearer
{
"resourceType" : "Bundle",
"id" : "MedicalServicesAuthorizationBundleExample",
"meta" : {
"profile" : ["http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-pas-request-bundle"]
},
"identifier" : {
"system" : "http://example.org/SUBMITTER_TRANSACTION_IDENTIFIER",
"value" : "5269367"
},
"type" : "collection",
"timestamp" : "2005-05-02T11:01:00+05:00",
"entry" : [{
"fullUrl" : "http://example.org/fhir/Claim/MedicalServicesAuthorizationExample",
"resource" : {
"resourceType" : "Claim",
"id" : "MedicalServicesAuthorizationExample",
"meta" : {
"profile" : ["http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-claim"]
},
"identifier" : [{
"system" : "http://example.org/PATIENT_EVENT_TRACE_NUMBER",
"value" : "111099"
}],
"status" : "active",
"type" : {
"coding" : [{
"system" : "http://terminology.hl7.org/CodeSystem/claim-type",
"code" : "professional"
}]
},
"use" : "preauthorization",
"patient" : {
"reference" : "Patient/SubscriberExample"
},
"created" : "2005-05-02T11:01:00+05:00",
"insurer" : {
"reference" : "Organization/InsurerExample"
},
"provider" : {
"reference" : "Organization/UMOExample"
},
"priority" : {
"coding" : [{
"system" : "http://terminology.hl7.org/CodeSystem/processpriority",
"code" : "normal"
}]
},
"insurance" : [{
"sequence" : 1,
"focal" : true,
"coverage" : {
"reference" : "Coverage/InsuranceExample"
}
}],
"item" : [{
"extension" : [{
"url" : "http://hl7.org/fhir/us/davinci-pas/StructureDefinition/extension-serviceItemRequestType",
"valueCodeableConcept" : {
"coding" : [{
"system" : "https://codesystem.x12.org/005010/1525",
"code" : "IN",
"display" : "Initial Medical Services Reservation"
}]
}
},
{
"url" : "http://hl7.org/fhir/us/davinci-pas/StructureDefinition/extension-certificationType",
"valueCodeableConcept" : {
"coding" : [{
"system" : "https://codesystem.x12.org/005010/1322",
"code" : "I",
"display" : "Initial"
}]
}
},
{
"url" : "http://hl7.org/fhir/us/davinci-pas/StructureDefinition/extension-authorizationNumber",
"valueString" : "1122344"
},
{
"url" : "http://hl7.org/fhir/us/davinci-pas/StructureDefinition/extension-administrationReferenceNumber",
"valueString" : "33441122"
}],
"sequence" : 1,
"category" : {
"coding" : [{
"system" : "https://codesystem.x12.org/005010/1365",
"code" : "1",
"display" : "Medical Care"
}]
},
"productOrService" : {
"coding" : [{
"system" : "http://www.cms.gov/Medicare/Coding/HCPCSReleaseCodeSets",
"code" : "99212",
"display" : "Established Office Visit"
}]
},
"servicedDate" : "2005-05-10",
"locationCodeableConcept" : {
"coding" : [{
"system" : "https://www.cms.gov/Medicare/Coding/place-of-service-codes/Place_of_Service_Code_Set",
"code" : "11"
}]
}
}]
}
},
{
"fullUrl" : "http://example.org/fhir/Organization/UMOExample",
"resource" : {
"resourceType" : "Organization",
"id" : "UMOExample",
"meta" : {
"profile" : ["http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-requestor"]
},
"identifier" : [{
"system" : "http://hl7.org/fhir/sid/us-npi",
"value" : "8189991234"
}],
"active" : true,
"type" : [{
"coding" : [{
"system" : "https://codesystem.x12.org/005010/98",
"code" : "X3"
}]
}],
"name" : "DR. JOE SMITH CORPORATION",
"address" : [{
"line" : ["111 1ST STREET"],
"city" : "SAN DIEGO",
"state" : "CA",
"postalCode" : "92101",
"country" : "US"
}]
}
},
{
"fullUrl" : "http://example.org/fhir/Organization/InsurerExample",
"resource" : {
"resourceType" : "Organization",
"id" : "InsurerExample",
"meta" : {
"profile" : ["http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-insurer"]
},
"identifier" : [{
"system" : "http://hl7.org/fhir/sid/us-npi",
"value" : "1234567893"
}],
"active" : true,
"type" : [{
"coding" : [{
"system" : "https://codesystem.x12.org/005010/98",
"code" : "PR"
}]
}],
"name" : "MARYLAND CAPITAL INSURANCE COMPANY"
}
},
{
"fullUrl" : "http://example.org/fhir/Coverage/InsuranceExample",
"resource" : {
"resourceType" : "Coverage",
"id" : "InsuranceExample",
"meta" : {
"profile" : ["http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-coverage"]
},
"status" : "active",
"subscriberId" : "1122334455",
"beneficiary" : {
"reference" : "Patient/SubscriberExample"
},
"relationship" : {
"coding" : [{
"system" : "http://terminology.hl7.org/CodeSystem/subscriber-relationship",
"code" : "self"
},
{
"system" : "https://codesystem.x12.org/005010/1069",
"code" : "18"
}]
},
"payor" : [{
"reference" : "Organization/InsurerExample"
}]
}
},
{
"fullUrl" : "http://example.org/fhir/Patient/SubscriberExample",
"resource" : {
"resourceType" : "Patient",
"id" : "SubscriberExample",
"meta" : {
"profile" : ["http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-subscriber"]
},
"extension" : [{
"url" : "http://hl7.org/fhir/us/davinci-pas/StructureDefinition/extension-militaryStatus",
"valueCodeableConcept" : {
"coding" : [{
"system" : "https://codesystem.x12.org/005010/584",
"code" : "RU"
}]
}
}],
"identifier" : [{
"type" : {
"coding" : [{
"system" : "http://terminology.hl7.org/CodeSystem/v2-0203",
"code" : "MB"
}]
},
"system" : "http://example.org/MIN",
"value" : "12345678901"
}],
"name" : [{
"family" : "SMITH",
"given" : ["JOE"]
}],
"gender" : "male"
}
}]
}
```
## Formato della risposta
### Risposta di successo (200 OK)
Riceverai un pacchetto di risposta PAS contenente:
+ **ClaimResponse**con e `outcome: "queued"` `status: "active"`
+ Tutte le risorse originali contenute nella tua richiesta
+ Timestamp di conferma della ricezione
```
{
"resourceType" : "Bundle",
"identifier": {
"system": "http://example.org/SUBMITTER_TRANSACTION_IDENTIFIER",
"value": "5269367"
},
"type" : "collection",
"timestamp" : "2005-05-02T11:02:00+05:00",
"entry" : [{
"fullUrl" : "http://example.org/fhir/ClaimResponse/PractitionerRequestorPendingResponseExample",
"resource" : {
"resourceType" : "ClaimResponse",
"id" : "PractitionerRequestorPendingResponseExample",
"meta" : {
"profile" : ["http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-claimresponse"]
},
"identifier" : [{
"system" : "http://example.org/PATIENT_EVENT_TRACE_NUMBER",
"value" : "111099"
}],
"status" : "active",
"type" : {
"coding" : [{
"system" : "http://terminology.hl7.org/CodeSystem/claim-type",
"code" : "professional"
}]
},
"use" : "preauthorization",
"patient" : {
"reference" : "Patient/SubscriberExample"
},
"created" : "2005-05-02T11:02:00+05:00",
"insurer" : {
"reference" : "Organization/InsurerExample"
},
"requestor" : {
"reference" : "PractitionerRole/ReferralPractitionerRoleExample"
},
"request" : {
"reference" : "Claim/MedicalServicesAuthorizationExample"
},
"outcome" : "queued"
}
},
{
"fullUrl" : "http://example.org/fhir/Claim/MedicalServicesAuthorizationExample",
"resource" : {
"resourceType" : "Claim",
"id" : "MedicalServicesAuthorizationExample",
"meta" : {
"profile": [
"http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-claim",
"http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-claim|2.1.0"
]
},
"identifier" : [{
"system" : "http://example.org/PATIENT_EVENT_TRACE_NUMBER",
"value" : "111099"
}
}],
"status" : "active",
"type" : {
"coding" : [{
"system" : "http://terminology.hl7.org/CodeSystem/claim-type",
"code" : "professional"
}]
},
"use" : "preauthorization",
"patient" : {
"reference" : "Patient/SubscriberExample"
},
"created" : "2005-05-02T11:01:00+05:00",
"insurer" : {
"reference" : "Organization/InsurerExample"
},
"provider" : {
"reference" : "Organization/UMOExample"
},
"priority" : {
"coding" : [{
"system" : "http://terminology.hl7.org/CodeSystem/processpriority",
"code" : "normal"
}]
},
"insurance" : [{
"sequence" : 1,
"focal" : true,
"coverage" : {
"reference" : "Coverage/InsuranceExample"
}
}],
"item" : [{
"extension" : [{
"url" : "http://hl7.org/fhir/us/davinci-pas/StructureDefinition/extension-serviceItemRequestType",
"valueCodeableConcept" : {
"coding" : [{
"system" : "https://codesystem.x12.org/005010/1525",
"code" : "IN",
"display" : "Initial Medical Services Reservation"
}]
}
},
{
"url" : "http://hl7.org/fhir/us/davinci-pas/StructureDefinition/extension-certificationType",
"valueCodeableConcept" : {
"coding" : [{
"system" : "https://codesystem.x12.org/005010/1322",
"code" : "I",
"display" : "Initial"
}]
}
},
{
"url" : "http://hl7.org/fhir/us/davinci-pas/StructureDefinition/extension-authorizationNumber",
"valueString" : "1122344"
},
{
"url" : "http://hl7.org/fhir/us/davinci-pas/StructureDefinition/extension-administrationReferenceNumber",
"valueString" : "33441122"
}],
"sequence" : 1,
"category" : {
"coding" : [{
"system" : "https://codesystem.x12.org/005010/1365",
"code" : "1",
"display" : "Medical Care"
}]
},
"productOrService" : {
"coding" : [{
"system" : "http://www.cms.gov/Medicare/Coding/HCPCSReleaseCodeSets",
"code" : "99212",
"display" : "Established Office Visit"
}]
},
"servicedDate" : "2005-05-10",
"locationCodeableConcept" : {
"coding" : [{
"system" : "https://www.cms.gov/Medicare/Coding/place-of-service-codes/Place_of_Service_Code_Set",
"code" : "11"
}]
}
}]
}
},
{
"fullUrl" : "http://example.org/fhir/Organization/UMOExample",
"resource" : {
"resourceType" : "Organization",
"id" : "UMOExample",
"meta" : {
"profile": [
"http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-requestor",
"http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-requestor|2.1.0"
]
},
"identifier" : [{
"system" : "http://hl7.org/fhir/sid/us-npi",
"value" : "8189991234"
}],
"active" : true,
"type" : [{
"coding" : [{
"system" : "https://codesystem.x12.org/005010/98",
"code" : "X3"
}]
}],
"name" : "DR. JOE SMITH CORPORATION",
"address" : [{
"line" : ["111 1ST STREET"],
"city" : "SAN DIEGO",
"state" : "CA",
"postalCode" : "92101",
"country" : "US"
}]
}
},
{
"fullUrl" : "http://example.org/fhir/Organization/InsurerExample",
"resource" : {
"resourceType" : "Organization",
"id" : "InsurerExample",
"meta" : {
"profile": [
"http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-insurer",
"http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-insurer|2.1.0"
]
},
"identifier" : [{
"system" : "http://hl7.org/fhir/sid/us-npi",
"value" : "1234567893"
}],
"active" : true,
"type" : [{
"coding" : [{
"system" : "https://codesystem.x12.org/005010/98",
"code" : "PR"
}]
}],
"name" : "MARYLAND CAPITAL INSURANCE COMPANY"
}
},
{
"fullUrl" : "http://example.org/fhir/Coverage/InsuranceExample",
"resource" : {
"resourceType" : "Coverage",
"id" : "InsuranceExample",
"meta": {
"profile": [
"http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-coverage",
"http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-coverage|2.1.0"
]
},
"status" : "active",
"subscriberId" : "1122334455",
"beneficiary" : {
"reference" : "Patient/SubscriberExample"
},
"relationship" : {
"coding" : [{
"system" : "http://terminology.hl7.org/CodeSystem/subscriber-relationship",
"code" : "self"
},
{
"system" : "https://codesystem.x12.org/005010/1069",
"code" : "18"
}]
},
"payor" : [{
"reference" : "Organization/InsurerExample"
}]
}
},
{
"fullUrl" : "http://example.org/fhir/Patient/SubscriberExample",
"resource" : {
"resourceType" : "Patient",
"id" : "SubscriberExample",
"meta": {
"profile": [
"http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-subscriber",
"http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-beneficiary",
"http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-beneficiary|2.1.0"
]
},
"extension" : [{
"url" : "http://hl7.org/fhir/us/davinci-pas/StructureDefinition/extension-militaryStatus",
"valueCodeableConcept" : {
"coding" : [{
"system" : "https://codesystem.x12.org/005010/584",
"code" : "RU"
}]
}
}],
"identifier" : [{
"type" : {
"coding" : [{
"system" : "http://terminology.hl7.org/CodeSystem/v2-0203",
"code" : "MB"
}]
},
"system" : "http://example.org/MIN",
"value" : "12345678901"
}],
"name" : [{
"family" : "SMITH",
"given" : ["JOE"]
}],
"gender" : "male"
}
}]
}
```
## Risposte agli errori
### 400 Richiesta non valida
Restituito quando il formato della richiesta non è valido o non è valido.
```
{
"resourceType": "OperationOutcome",
"issue": [{
"severity": "error",
"code": "invalid",
"diagnostics": "The provided payload was invalid and could not be parsed correctly."
}]
}
```
### 412 Precondizione non riuscita
Restituito quando è già stata inviata la stessa richiesta di autorizzazione preventiva (è stato rilevato un invio duplicato).
```
{
"resourceType": "OperationOutcome",
"issue": [{
"severity": "error",
"code": "processing",
"diagnostics": "PreAuth Claim already exists"
}]
}
```
**Idempotenza**
L'`$submit`operazione è idempotente. L'invio della stessa richiesta più volte non creerà richieste di autorizzazione preventiva duplicate. Riceverai invece un errore 412 che ti chiederà di utilizzare per `$inquire` verificare lo stato dell'invio originale.
### 422 Entità non processabile
Restituito quando la convalida FHIR fallisce.
```
{
"resourceType": "OperationOutcome",
"issue": [{
"severity": "error",
"code": "required",
"diagnostics": "Bundle contains more than one preauthorization claim"
}]
}
```
## Regole di convalida
HealthLake esegue una convalida completa dell'invio:
### Convalida del pacchetto
+ Deve essere conforme al profilo PAS Request Bundle
+ `Bundle.type`deve essere `"collection"`
+ Può contenere più risorse per i reclami
+ Tuttavia, deve contenere esattamente una risorsa Claim da utilizzare in preautorizzazione
+ E questa risorsa Claim deve essere la prima voce del pacchetto
+ Tutte le risorse a cui si fa riferimento devono essere incluse nel pacchetto
### Convalida del reclamo
+ Deve essere conforme al profilo PAS Claim
+ `Claim.use`deve essere `"preauthorization"`
+ Campi obbligatori: `patient``insurer`,`provider`,`created`, `priority`
+ Gli identificatori aziendali devono essere presenti e validi
### Convalida delle risorse
+ Tutte le risorse devono essere conformi ai rispettivi profili PAS
+ Devono essere presenti le risorse di supporto necessarie (paziente, copertura, organizzazione)
+ I riferimenti incrociati devono essere validi e risolvibili all'interno del pacchetto
## Specifiche prestazionali
| Metrica | Specifiche |
| --- | --- |
| Limite di dimensione del pacchetto | Massimo 5 MB |
| Limite di numero di risorse | 500 risorse per pacchetto |
## Autorizzazioni richieste
Per utilizzare l'`$submit`operazione, è possibile utilizzare AWS Sigv4 o SMART su FHIR:
+ Assicurati che il tuo ruolo IAM abbia: `healthlake:SubmitPreAuthClaim` - Per chiamare l'operazione
**SMART su FHIR Scopes**
**Ambiti minimi richiesti:**
+ **SMART v1:** `user/Claim.write & .write`
+ **SMART versione 2:** `user/Claim.c & .c or system/*.*`
## Note importanti sull'implementazione
### Persistenza delle risorse
+ Tutte le voci del Bundle vengono memorizzate come risorse FHIR individuali nell'archivio dati
+ I dati forniti dal cliente vengono conservati quando vengono forniti IDs
+ La cronologia delle versioni viene conservata a fini di controllo
+ Il rilevamento dei duplicati previene i conflitti di risorse
### Comportamento di elaborazione
+ Ogni invio valido restituisce esattamente ClaimResponse un `"queued"` risultato
+ Gli invii non validi restituiscono codici di stato 400 o 422 con informazioni dettagliate sull'errore
+ Gli errori di sistema restituiscono i codici di stato 5xx appropriati
+ Tutti gli invii andati a buon fine restituiscono lo stato 200 con un messaggio Risolto ClaimResponse
### Requisiti del pacchetto
+ `Bundle.entry.fullUrl`i valori devono essere REST URLs o format `"urn:uuid:[guid]"`
+ Tutti gli invii GUIDs devono essere unici (ad eccezione delle stesse istanze di risorse)
+ Le risorse referenziate devono esistere all'interno del pacchetto o essere risolvibili
## Operazioni correlate
+ `Claim/$inquire`- Verifica lo stato di una richiesta di autorizzazione preventiva inviata
+ `Patient/$everything`- Recupera i dati completi del paziente per il contesto di autorizzazione preventiva
# Convalida delle risorse FHIR con `$validate`
AWS HealthLake ora supporta il `$validate` funzionamento delle risorse FHIR, consentendoti di convalidare una risorsa rispetto alle specifiche FHIR e di verificarne la conformità a un profilo specifico o a una definizione di risorsa di base senza eseguire alcuna operazione di storage. Questa operazione è particolarmente utile quando è necessario:
+ Convalidare i requisiti di conformità FHIR CMS
+ Testa le risorse prima di utilizzarle in produzione
+ Fornisci feedback di convalida in tempo reale mentre gli utenti modificano i dati clinici
+ Riduci gli invii di dati non validi per crearli e aggiornarli APIs
## Utilizzo
L'`$validate`operazione può essere richiamata sulle risorse FHIR utilizzando i metodi POST:
**Operazioni supportate**
```
POST [base]/[type]/[id]/$validate
POST [base]/[type]/$validate
```
## Payload supportati
**Risorsa di parametri**
HealthLake supporta i seguenti `$validate` parametri FHIR:
| Parametro | Tipo | Campo obbligatorio | Description |
| --- | --- | --- | --- |
| resource | Risorsa | Sì | La risorsa da convalidare |
| profile | canonico | No | URL canonico del profilo con cui eseguire la convalida |
| mode | code | No | Modalità di convalida:, oppure create update |
**Risorsa diretta con parametri di interrogazione**
| Parametro | Tipo | Campo obbligatorio | Description |
| --- | --- | --- | --- |
| profile | canonico | No | URL canonico del profilo con cui eseguire la convalida |
| mode | code | No | Modalità di convalida:, oppure create update |
## Esempi
**Richiesta POST di risorsa con payload ID e parametri**
```
POST [base]/Patient/example-patient/$validate
Content-Type: application/fhir+json
{
"resourceType": "Parameters",
"parameter": [
{
"name": "resource",
"resource": {
"resourceType": "Patient",
"id": "example-patient",
"name": [
{
"family": "Smith",
"given": ["John"]
}
],
"gender": "male",
"birthDate": "1990-01-01"
}
},
{
"name": "profile",
"valueCanonical": "http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient"
},
{
"name": "mode",
"valueString": "create"
}
]
}
```
**Richiesta POST per il tipo di risorsa e il payload dei parametri**
```
POST [base]/Patient/$validate
Content-Type: application/fhir+json
{
"resourceType": "Parameters",
"parameter": [
{
"name": "resource",
"resource": {
"resourceType": "Patient",
"name": [
{
"family": "Doe",
"given": ["Jane"]
}
],
"gender": "female",
"birthDate": "1985-05-15"
}
},
{
"name": "profile",
"valueCanonical": "http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient"
},
{
"name": "mode",
"valueString": "update"
}
]
}
```
**Richiesta di risorsa POST con ID e payload diretto della risorsa**
```
POST [base]/Patient/example-patient/$validate?profile=http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient&mode=create
Content-Type: application/fhir+json
{
"resourceType": "Patient",
"id": "example-patient",
"name": [
{
"family": "Smith",
"given": ["John"]
}
],
"gender": "male",
"birthDate": "1990-01-01"
}
```
**Richiesta POST per tipo di risorsa e payload diretto della risorsa**
```
POST [base]/Patient/$validate?profile=http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient&mode=create
Content-Type: application/fhir+json
{
"resourceType": "Patient",
"id": "example-patient",
"name": [
{
"family": "Smith",
"given": ["John"]
}
],
"gender": "male",
"birthDate": "1990-01-01"
}
```
**Risposta di esempio**
L'operazione restituisce una OperationOutcome risorsa con risultati di convalida:
```
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "information",
"code": "informational",
"diagnostics": "Validation successful"
}
]
}
```
**Esempio di risposta con errori di convalida**
```
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "required",
"details": {
"text": "Missing required element"
},
"diagnostics": "Patient.identifier is required by the US Core Patient profile",
"location": [
"Patient.identifier"
]
},
{
"severity": "warning",
"code": "code-invalid",
"details": {
"text": "Invalid code value"
},
"diagnostics": "The provided gender code is not from the required value set",
"location": [
"Patient.gender"
]
}
]
}
```
## Comportamento
L'`$validate`operazione:
1. Convalida la risorsa rispetto alla specifica FHIR e alla definizione della risorsa di base
1. Verifica la conformità ai profili specificati quando viene fornito il parametro `profile`
1. Esegue la convalida in base alla modalità specificata (o) `create` `update`
1. Restituisce risultati di convalida dettagliati, inclusi errori, avvisi e messaggi informativi
1. Non esegue alcuna operazione di archiviazione, solo convalida
1. Restituisce HTTP 200 OK quando è possibile eseguire la convalida, indipendentemente dal fatto che vengano rilevati problemi di convalida
## Modalità di convalida
+ **create**: convalida la risorsa come se fosse in fase di creazione (nuova risorsa)
+ **update**: convalida la risorsa come se fosse in fase di aggiornamento (risorsa esistente)
## Gestione errori
L'operazione restituisce:
+ 200 OK: la convalida è stata eseguita correttamente (indipendentemente dal risultato della convalida)
+ 400 Bad Request: formato o parametri della richiesta non validi
+ 404 Not Found: Tipo di risorsa o profilo non trovato
Per ulteriori informazioni sulle specifiche `$validate` operative, consulta la documentazione delle [risorse `$validate` FHIR R4](https://www.hl7.org/fhir/R4/operation-resource-validate.html).
# Riferimento di conformità per AWS HealthLake
AWS HealthLake offre funzionalità progettate per aiutarti a tracciare e segnalare l'utilizzo delle API in linea con i requisiti di interoperabilità CMS (Centers for Medicare & Medicaid Services). Queste funzionalità consentono di classificare le transazioni API in base alle categorie obbligatorie del CMS e di acquisire automaticamente le metriche di utilizzo per scopi di reporting sulla conformità.
**Comprensione delle responsabilità in materia di conformità**
L'utilizzo AWS HealthLake e i relativi endpoint di interoperabilità CMS **non sono di per sé sufficienti per ottenere la conformità** al CMS. L'utente è responsabile di:
Mappatura corretta dei flussi di lavoro delle API sugli endpoint della categoria CMS appropriata in base ai casi d'uso specifici e agli obblighi normativi
Implementazione di controlli di autenticazione e autorizzazione adeguati che soddisfino i requisiti CMS
Garantire che le risorse e gli scambi di dati FHIR siano conformi alle normative CMS e alle guide di implementazione applicabili
Configurazione e monitoraggio delle CloudWatch metriche per supportare le esigenze di rendicontazione della conformità
Comprendere quali regole CMS si applicano alla propria organizzazione e implementare i controlli tecnici e operativi appropriati
AWS HealthLake fornisce l'infrastruttura e gli strumenti per supportare gli sforzi di conformità, ma è necessario utilizzare queste funzionalità in modo appropriato in base ai requisiti normativi specifici. Il semplice instradamento delle chiamate API attraverso questi endpoint non rende automaticamente l'applicazione conforme alle normative CMS.
**Topics**
+ [CMS](reference-compliance-cms.md)
# Funzionalità di conformità CMS
AWS HealthLake fornisce funzionalità che consentono di soddisfare i requisiti di interoperabilità e conformità dei CMS (Centers for Medicare & Medicaid Services). Queste funzionalità consentono di tenere traccia dell'utilizzo delle API per categoria CMS e successivamente di riportare le metriche di utilizzo ai fini della conformità.
**Topics**
+ [Endpoint di interoperabilità CMS](#cms-interoperability-endpoints)
+ [Metriche migliorate CloudWatch per la conformità CMS](#cms-cloudwatch-metrics)
## Endpoint di interoperabilità CMS
### Panoramica di
HealthLake fornisce quattro endpoint di interoperabilità CMS che corrispondono alle categorie di API obbligatorie per il CMS. L'URL di base sottostante del tuo data store non cambia. HealthLake Questi endpoint forniscono semplicemente un modo per classificare e tracciare le chiamate API per scopi di reporting CMS.
### Scopo
Lo scopo principale di questi endpoint di interoperabilità è consentire ai clienti di:
+ **Monitora facilmente** le transazioni API per categoria CMS
+ **Segnala automaticamente** le metriche di utilizzo per la conformità CMS
+ **Mantieni** i flussi di lavoro FHIR esistenti con modifiche minime
Tutte le chiamate API funzionano allo stesso modo, indipendentemente dal fatto che si utilizzi l'endpoint di interoperabilità o l'endpoint FHIR standard: l'unica differenza è il modo in cui le transazioni sono classificate nelle metriche. CloudWatch
### Endpoint di interoperabilità CMS supportati
| Categoria CMS | Endpoint di interoperabilità | Esempio di utilizzo |
| --- | --- | --- |
| Accesso per i pazienti | /patientaccess/v2/r4 | baseURL/patientaccess/v2/r4/Patient/123 |
| Accesso da parte del fornitore | /provideraccess/v2/r4 | baseURL/provideraccess/v2/r4/Observation?patient=123 |
| Da pagante a pagante | /payertopayerdx/v2/r4 | baseURL/payertopayerdx/v2/r4/Practitioner/456 |
| Servizio di autenticazione precedente | /priorauthservice/v2/r4 | baseURL/priorauthservice/v2/r4/ExplanationOfBenefit?patient=789 |
### Come funzionano gli endpoint di interoperabilità
**Chiamata API standard: HealthLake **
```
baseURL/resourceType/[id]
baseURL/resourceType?[parameters]
```
**Con CMS Interoperability Endpoint:**
```
baseURL/interoperability-endpoint/resourceType/[id]
baseURL/interoperability-endpoint/resourceType?[parameters]
```
Il percorso dell'endpoint di interoperabilità viene semplicemente inserito tra l'URL di base e il tipo di risorsa. Tutto ciò che segue il percorso dell'endpoint di interoperabilità rimane esattamente lo stesso delle chiamate API correnti.
### Esempi di utilizzo
#### Esempio 1: API Patient Access
**Chiamata API corrente (funziona ancora):**
```
curl -X GET \
https://healthlake.us-east-1.amazonaws.com/datastore/abc123/r4/Patient/123 \
-H "Authorization: Bearer " \
-H "Content-Type: application/fhir+json"
```
**Con l'endpoint di interoperabilità Patient Access (per il tracciamento CMS):**
```
curl -X GET \
https://healthlake.us-east-1.amazonaws.com/datastore/abc123/patientaccess/v2/r4/Patient/123 \
-H "Authorization: Bearer " \
-H "Content-Type: application/fhir+json"
```
**Punti chiave:**
+ L'URL di base rimane: `https://healthlake.us-east-1.amazonaws.com/datastore/abc123`
+ Endpoint di interoperabilità inserito: `/patientaccess/v2/r4`
+ Percorso delle risorse invariato: `/Patient/123`
+ **Entrambe le chiamate restituiscono risposte identiche**
+ La chiamata all'endpoint di interoperabilità viene tracciata automaticamente in `URIType=patient-access` CloudWatch
+ Le operazioni POST, PUT, PATCH, DELETE funzionano in modo identico.
+ Il corpo della richiesta rimane invariato.
### Riferimento alla traduzione degli endpoint
| Endpoint di interoperabilità | Si traduce in | Categoria CMS |
| --- | --- | --- |
| baseURL/patientaccess/v2/r4/Patient | baseURL/r4/Patient | Accesso per i pazienti |
| baseURL/provideraccess/v2/r4/Observation | baseURL/r4/Observation | Accesso da parte del fornitore |
| baseURL/payertopayerdx/v2/r4/Practitioner/456 | baseURL/r4/Practitioner/456 | Data Exchange tra pagatori |
| baseURL/priorauthservice/v2/r4/ExplanationOfBenefit?patient=789 | baseURL/r4/ExplanationOfBenefit?patient=789 | Autorizzazione preventiva |
### Note importanti
+ **Nessuna differenza funzionale**: gli endpoint di interoperabilità e gli endpoint FHIR standard restituiscono risposte identiche e supportano operazioni identiche
+ **URL di base invariato**: l'endpoint del data store rimane lo stesso HealthLake
+ **Integrazione semplice**: inserisci il percorso dell'endpoint di interoperabilità tra l'URL di base e il tipo di risorsa
+ **Tracciamento automatico**: le CloudWatch metriche classificano automaticamente le chiamate in base all'endpoint di interoperabilità utilizzato
+ **Compatibilità con le versioni precedenti**: le chiamate API esistenti senza endpoint di interoperabilità continuano a funzionare normalmente
## Metriche migliorate CloudWatch per la conformità CMS
### Panoramica di
Quando si utilizzano gli endpoint di interoperabilità CMS, emette HealthLake automaticamente CloudWatch metriche avanzate con dimensioni aggiuntive per supportare i requisiti di reporting CMS. **Queste metriche tengono traccia dell'utilizzo dell'API in base all'identità del chiamante, all'applicazione e ai tipi di URI specifici del CMS senza alcuna configurazione aggiuntiva.**
### Come funziona
Quando effettui una chiamata API utilizzando un endpoint di interoperabilità:
```
# This call...
curl https://healthlake.us-east-1.amazonaws.com/datastore/abc123/patientaccess/v2/r4/Patient/123
# Automatically generates metrics with:
# - URIType: "patient-access"
# - Sub: extracted from your bearer token (SMART on FHIR datastores only)
# - ClientId: extracted from your bearer token (SMART on FHIR datastores only)
# - Plus all standard dimensions (DatastoreId, Operation, etc.)
```
**Non è necessario alcun codice o configurazione aggiuntivi.** Basta usare gli endpoint di interoperabilità e le metriche avanzate vengono acquisite automaticamente.
**Nota**
Per gli archivi di dati Non-Smart on FHIR, la `URIType` dimensione viene comunque acquisita, consentendoti di tracciare l'utilizzo delle API per categoria CMS. `ClientId`Le dimensioni `Sub` and sono disponibili solo quando si utilizza l'autenticazione SMART on FHIR con token portatori contenenti queste attestazioni.
### Nuove dimensioni metriche
Oltre alle dimensioni esistenti (`DatastoreId`,,`Operation`)`DatastoreType`, le seguenti dimensioni vengono aggiunte automaticamente quando si utilizzano gli endpoint di interoperabilità:
| Dimensione | Description | Valori di esempio | Origine |
| --- | --- | --- | --- |
| URIType | Categoria di conformità CMS | patient-access, provider-access, payer-to-payer, prior-authorization | Determinato automaticamente dal percorso dell'endpoint di interoperabilità |
| Sub | Identità del chiamante | Identificatore utente/entità | Estratto dal token claim del portatore sub |
| ClientId | Identificatore dell'applicazione | portal\$1app, ehr\$1system | Estratto dalla rivendicazione del token al portatore client\$1id |
### Metriche disponibili
Tutte le HealthLake metriche esistenti ora includono le dimensioni aggiuntive quando si utilizzano gli endpoint di interoperabilità:
+ **CallCount**- Numero totale di chiamate API
+ **Latenza**: tempo di risposta dell'API in millisecondi
+ **UserErrors**- Numero di 4xx errori del client
+ **SystemErrors**- Numero di 5xx errori del server
+ **Throttles**: Numero di richieste limitate
+ **SuccessfulRequests**- Numero di chiamate API riuscite
### Interrogazione delle metriche in CloudWatch
#### CloudWatch Esempio di query Insights
**Interroga tutte le chiamate API Patient Access per applicazione:**
```
SELECT SUM(CallCount)
FROM "AWS/HealthLake"
WHERE DatastoreId = '75c1cf9b0d71cd38fec8f7fb317c4c1a'
AND URIType = 'patient-access'
GROUP BY ClientId
```
# Supporto di riferimento per AWS HealthLake
Il seguente materiale di riferimento di supporto è disponibile per. AWS HealthLake
**Nota**
Tutte le HealthLake azioni e i tipi di dati nativi sono descritti in un riferimento separato. Per ulteriori informazioni, consulta la [documentazione di riferimento dell’API di *AWS HealthLake *](https://docs.aws.amazon.com/healthlake/latest/APIReference/).
**Topics**
+ [Punti finali e quote](reference-healthlake-endpoints-quotas.md)
+ [Tipi di dati precaricati](reference-healthlake-preloaded-data-types.md)
+ [Progetti di esempio](reference-healthlake-sample-projects.md)
+ [Risoluzione dei problemi](reference-healthlake-troubleshooting.md)
+ [Lavorare con AWS SDKs](sdk-general-information-section.md)
# AWS HealthLake endpoint e quote
I seguenti argomenti contengono informazioni sugli endpoint e sulle AWS HealthLake quote di servizio.
**Topics**
+ [Endpoint di servizio](#reference-healthlake-endpoints)
+ [Service Quotas](#reference-healthlake-quotas)
## Endpoint di servizio
Un endpoint di servizio è un URL che identifica un host e una porta come punto di ingresso per un servizio Web. Ogni richiesta di servizio Web include un endpoint. La maggior parte AWS dei servizi fornisce endpoint per regioni specifiche per consentire una connettività più rapida. La tabella seguente elenca gli endpoint del servizio per. AWS HealthLake
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/healthlake/latest/devguide/reference-healthlake-endpoints-quotas.html)
## Service Quotas
Le quote di servizio sono definite come il valore massimo per le risorse, le azioni e gli elementi presenti nell'account AWS .
**Nota**
Per le quote regolabili, puoi richiedere un aumento della quota utilizzando la console [Service Quotas](https://console.aws.amazon.com/servicequotas/). Per ulteriori informazioni, consulta [Richiesta di un aumento delle quote nella ](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html)Guida per l’utente di Service Quotas**.
La velocità dell'API Sync Write aumenta proporzionalmente alla dimensione del payload, con ogni incremento di 1 KB che consuma capacità aggiuntiva (ad esempio, un payload di 4 KB utilizza una capacità di scrittura quadrupla). L'impostazione dell'`x-amz-fhir-history-consistency-level`intestazione opzionale per raddoppiare il consumo di capacità di scrittura per risorsa. `strong`
Le risorse all'interno dei pacchetti seguono i read/write limiti standard basati sulla dimensione del payload di 1 KB. Le *transazioni* di tipo bundle consumano il doppio della capacità di scrittura rispetto a quelle di tipo *batch*, il che significa che i pacchetti *batch* possono elaborare il doppio delle risorse al secondo rispetto ai pacchetti di transazioni.
La tabella seguente elenca le quote predefinite per. AWS HealthLake
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/healthlake/latest/devguide/reference-healthlake-endpoints-quotas.html)
# Tipi di dati precaricati Synthea per HealthLake
HealthLake supporta solo SYNTHEA come tipo di dati precaricato. [Synthea è un](https://synthetichealth.github.io/synthea/) generatore sintetico per pazienti che modella la storia medica. `Patient` È ospitato in un repository Git open source che consente di generare una risorsa conforme HealthLake a FHIR R4 in `Bundle` modo che gli utenti possano testare i modelli senza utilizzare i dati effettivi dei pazienti.
I seguenti tipi di risorse sono disponibili negli archivi dati precaricati. HealthLake Per ulteriori informazioni sul precaricamento degli archivi HealthLake dati con i dati Synthea, vedere. [Creazione di un archivio HealthLake dati](managing-data-stores-create.md)
**Nota**
Per visualizzare un elenco completo delle risorse FHIR HealthLake R4 supportate, vedere. [Tipi di risorse supportati da FHIR R4 per HealthLake](reference-fhir-resource-types.md)
**Tipi di risorse Synthea FHIR supportati da HealthLake**
| | |
| --- |--- |
| AllergyIntolerance | Location (Ubicazione) |
| CarePlan | MedicationAdministration |
| CareTeam | MedicationRequest |
| Richiedi | Osservazione |
| Condizione | Organizzazione |
| Dispositivo | Paziente |
| DiagnosticReport | Professionista |
| Incontro | PractitionerRole |
| ExplanationofBenefit | Procedura |
| ImagingStudy | Provenienza |
| Immunizzazione | |
# AWS HealthLake progetti di esempio
Per approfondire l'analisi, puoi utilizzare HealthLake altri AWS servizi, come dimostrato nei seguenti esempi di post di blog.
**HealthLake analisi integrata**
+ [Applicazioni per la salute della popolazione con AWS HealthLake — Parte 1: Analisi e monitoraggio con Amazon Quick](https://aws.amazon.com/blogs/machine-learning/population-health-applications-with-amazon-healthlake-part-1-analytics-and-monitoring-using-amazon-quicksight/).
+ [Creazione di modelli predittivi di malattie utilizzando Amazon SageMaker AI con AWS HealthLake dati normalizzati.](https://aws.amazon.com/blogs/machine-learning/building-predictive-disease-models-using-amazon-sagemaker-with-amazon-healthlake-normalized-data/)
+ [Crea una ricerca cognitiva e un grafico delle conoscenze sanitarie utilizzando i servizi di AWS intelligenza artificiale](https://aws.amazon.com/blogs/machine-learning/build-a-cognitive-search-and-a-health-knowledge-graph-using-amazon-healthlake-amazon-kendra-and-amazon-neptune/).
**HealthLake monitoraggio degli eventi**
+ [ EventBridge Integrazione Amazon con AWS HealthLake](https://aws.amazon.com/blogs/industries/amazon-eventbridge-integration-for-aws-healthlake/).
# Risoluzione dei problemi AWS HealthLake
I seguenti argomenti forniscono consigli per la risoluzione di errori e problemi che potrebbero verificarsi durante l'utilizzo della console AWS CLI AWS SDKs, o HealthLake . Se trovi un problema che non è elencato in questa sezione, utilizza il pulsante **Fornisci feedback** nella barra laterale destra di questa pagina per segnalarlo.
**Topics**
+ [Azioni relative all'archivio dati](#troubleshooting-data-store)
+ [Azioni di importazione](#troubleshooting-import)
+ [FHIR APIs](#troubleshooting-fhir-apis)
+ [Integrazioni NLP](#troubleshooting-nlp-integrations)
+ [Integrazioni SQL](#troubleshooting-sql-integrations)
## Azioni relative all'archivio dati
**Problema:** *quando tento di creare un archivio HealthLake dati, ricevo il seguente errore:*
```
AccessDeniedException: Insufficient Lake Formation permission(s): Required Database on Catalog
```
Il 14 novembre 2022, HealthLake ha aggiornato le autorizzazioni IAM richieste per creare un nuovo data store. Per ulteriori informazioni, consulta [Configura un utente o un ruolo IAM da utilizzare HealthLake (amministratore IAM)](getting-started-setting-up.md#setting-up-configure-iam).
**Problema:** *quando si crea un HealthLake data store utilizzando AWS SDKs, lo stato di creazione del data store restituisce un'eccezione o uno stato sconosciuto*.
Aggiorna l' AWS SDK alla versione più recente se le tue chiamate `DescribeFHIRDatastore` o le chiamate `ListFHIRDatastores` API restituiscono un'eccezione o uno stato sconosciuto del data store.
## Azioni di importazione
**Problema:** *posso ancora utilizzarli HealthLake se i miei dati non sono in formato FHIR R4*?
Solo i dati in formato FHIR R4 possono essere importati in un archivio dati. HealthLake [Per un elenco di partner che possono contribuire a trasformare i dati sanitari esistenti in formato FHIR R4, consulta Partners.AWS HealthLake](https://docs.aws.amazon.com/healthlake/partners/)
**Problema:** *perché il mio processo di importazione FHIR non* è riuscito?
Un processo di importazione riuscito genererà una cartella con i risultati (registro di output) in `.ndjson` formato, tuttavia, i singoli record potrebbero non essere importati. In tal caso, verrà generata una seconda `FAILURE` cartella con un manifesto di record che non è stato possibile importare. Per ulteriori informazioni, consulta [Importazione di dati FHIR con AWS HealthLake](importing-fhir-data.md).
Per analizzare il motivo per cui un processo di importazione non è riuscito, utilizza l'`DescribeFHIRImportJob`API per analizzare il JobProperties. Si consiglia quanto segue:
+ Se lo stato è `FAILED` ed è presente un messaggio, gli errori sono correlati a parametri del lavoro, come la dimensione dei dati di input o il numero di file di input, che superano le HealthLake quote.
+ Se lo stato del processo di importazione è`COMPLETED_WITH_ERRORS`, controllate il file manifesto per informazioni su quali file non sono stati importati correttamente. `manifest.json`
+ Se lo stato del processo di importazione è uguale `FAILED` e non è presente alcun messaggio, vai alla posizione di output del lavoro per accedere al file manifest,`manifest.json`.
Per ogni file di input, esiste un file di output non riuscito con il nome del file di input per ogni risorsa che non riesce a importare. Le risposte contengono il numero di riga (lineID) corrispondente alla posizione dei dati di input, l'oggetto di risposta FHIR (UpdateResourceResponse) e il codice di stato (statusCode) della risposta.
Un file di output di esempio potrebbe essere simile al seguente:
```
{"lineId":3, UpdateResourceResponse:{"jsonBlob":{"resourceType":"OperationOutcome","issue":[{"severity":"error","code":"processing","diagnostics":"1 validation error detected: Value 'Patient123' at 'resourceType' failed to satisfy constraint: Member must satisfy regular expression pattern: [A-Za-z]{1,256}"}]}, "statusCode":400}
{"lineId":5, UpdateResourceResponse:{"jsonBlob":{"resourceType":"OperationOutcome","issue":[{"severity":"error","code":"processing","diagnostics":"This property must be an simple value, not a com.google.gson.JsonArray","location":["/EffectEvidenceSynthesis/name"]},{"severity":"error","code":"processing","diagnostics":"Unrecognised property '@telecom'","location":["/EffectEvidenceSynthesis"]},{"severity":"error","code":"processing","diagnostics":"Unrecognised property '@gender'","location":["/EffectEvidenceSynthesis"]},{"severity":"error","code":"processing","diagnostics":"Unrecognised property '@birthDate'","location":["/EffectEvidenceSynthesis"]},{"severity":"error","code":"processing","diagnostics":"Unrecognised property '@address'","location":["/EffectEvidenceSynthesis"]},{"severity":"error","code":"processing","diagnostics":"Unrecognised property '@maritalStatus'","location":["/EffectEvidenceSynthesis"]},{"severity":"error","code":"processing","diagnostics":"Unrecognised property '@multipleBirthBoolean'","location":["/EffectEvidenceSynthesis"]},{"severity":"error","code":"processing","diagnostics":"Unrecognised property '@communication'","location":["/EffectEvidenceSynthesis"]},{"severity":"warning","code":"processing","diagnostics":"Name should be usable as an identifier for the module by machine processing applications such as code generation [name.matches('[A-Z]([A-Za-z0-9_]){0,254}')]","location":["EffectEvidenceSynthesis"]},{"severity":"error","code":"processing","diagnostics":"Profile http://hl7.org/fhir/StructureDefinition/EffectEvidenceSynthesis, Element 'EffectEvidenceSynthesis.status': minimum required = 1, but only found 0","location":["EffectEvidenceSynthesis"]},{"severity":"error","code":"processing","diagnostics":"Profile http://hl7.org/fhir/StructureDefinition/EffectEvidenceSynthesis, Element 'EffectEvidenceSynthesis.population': minimum required = 1, but only found 0","location":["EffectEvidenceSynthesis"]},{"severity":"error","code":"processing","diagnostics":"Profile http://hl7.org/fhir/StructureDefinition/EffectEvidenceSynthesis, Element 'EffectEvidenceSynthesis.exposure': minimum required = 1, but only found 0","location":["EffectEvidenceSynthesis"]},{"severity":"error","code":"processing","diagnostics":"Profile http://hl7.org/fhir/StructureDefinition/EffectEvidenceSynthesis, Element 'EffectEvidenceSynthesis.exposureAlternative': minimum required = 1, but only found 0","location":["EffectEvidenceSynthesis"]},{"severity":"error","code":"processing","diagnostics":"Profile http://hl7.org/fhir/StructureDefinition/EffectEvidenceSynthesis, Element 'EffectEvidenceSynthesis.outcome': minimum required = 1, but only found 0","location":["EffectEvidenceSynthesis"]},{"severity":"information","code":"processing","diagnostics":"Unknown extension http://synthetichealth.github.io/synthea/disability-adjusted-life-years","location":["EffectEvidenceSynthesis.extension[3]"]},{"severity":"information","code":"processing","diagnostics":"Unknown extension http://synthetichealth.github.io/synthea/quality-adjusted-life-years","location":["EffectEvidenceSynthesis.extension[4]"]}]}, "statusCode":400}
{"lineId":7, UpdateResourceResponse:{"jsonBlob":{"resourceType":"OperationOutcome","issue":[{"severity":"error","code":"processing","diagnostics":"2 validation errors detected: Value at 'resourceId' failed to satisfy constraint: Member must satisfy regular expression pattern: [A-Za-z0-9-.]{1,64}; Value at 'resourceId' failed to satisfy constraint: Member must have length greater than or equal to 1"}]}, "statusCode":400}
{"lineId":9, UpdateResourceResponse:{"jsonBlob":{"resourceType":"OperationOutcome","issue":[{"severity":"error","code":"processing","diagnostics":"Missing required id field in resource json"}]}, "statusCode":400}
{"lineId":15, UpdateResourceResponse:{"jsonBlob":{"resourceType":"OperationOutcome","issue":[{"severity":"error","code":"processing","diagnostics":"Invalid JSON found in input file"}]}, "statusCode":400}
```
L'esempio precedente mostra che si sono verificati errori sulle righe 3, 4, 7, 9, 15 delle linee di input corrispondenti del file di input. Per ognuna di queste righe, le spiegazioni sono le seguenti:
+ Nella riga 3, la risposta spiega che il contenuto `resourceType` fornito nella riga 3 del file di input non è valido.
+ Alla riga 5, la risposta spiega che c'è un errore di convalida FHIR nella riga 5 del file di input.
+ Alla riga 7, la risposta spiega che c'è un problema di convalida se viene `resourceId` fornito come input.
+ Alla riga 9, la risposta spiega che il file di input deve contenere un ID di risorsa valido.
+ Alla riga 15, la risposta del file di input è che il file non è in un formato JSON valido.
## FHIR APIs
**Problema:** *come posso implementare l'autorizzazione per il RESTful APIs FHIR*?
Determinate la [Strategia di autorizzazione all'archiviazione dei dati](getting-started-concepts.md#concept-data-store-authorization-strategy) modalità di utilizzo.
Per creare l'autorizzazione SigV4 utilizzando il AWS SDK per Python (Boto3), create uno script simile all'esempio seguente.
```
import boto3
import requests
import json
from requests_auth_aws_sigv4 import AWSSigV4
# Set the input arguments
data_store_endpoint = 'https://healthlake.us-east-1.amazonaws.com/datastore//r4//'
resource_path = "Patient"
requestBody = {"resourceType": "Patient", "active": True, "name": [{"use": "official","family": "Dow","given": ["Jen"]},{"use": "usual","given": ["Jen"]}],"gender": "female","birthDate": "1966-09-01"}
region = 'us-east-1'
#Frame the resource endpoint
resource_endpoint = data_store_endpoint+resource_path
session = boto3.session.Session(region_name=region)
client = session.client("healthlake")
# Frame authorization
auth = AWSSigV4("healthlake", session=session)
# Call data store FHIR endpoint using SigV4 auth
r = requests.post(resource_endpoint, json=requestBody, auth=auth, )
print(r.json())
```
**Problema:** *perché ricevo `AccessDenied` errori quando utilizzo il FHIR RESTful APIs per un archivio dati crittografato con una chiave KMS gestita dal cliente*?
Le autorizzazioni sia per le chiavi gestite dal cliente che per le politiche IAM sono necessarie per consentire a un utente o un ruolo di accedere a un archivio dati. Un utente deve disporre delle autorizzazioni IAM richieste per utilizzare una chiave gestita dal cliente. Se un utente ha revocato o ritirato una concessione che HealthLake consentiva di utilizzare la chiave KMS gestita dal cliente, HealthLake restituirà un errore. `AccessDenied`
HealthLake deve disporre dell'autorizzazione per accedere ai dati dei clienti, crittografare le nuove risorse FHIR importate in un archivio dati e decrittografare le risorse FHIR quando vengono richieste. [Per ulteriori informazioni, vedere Risoluzione dei problemi relativi alle autorizzazioni. AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/policy-evaluation.html)
**Problema:** *un'operazione dell'`POST`API FHIR sull' HealthLake utilizzo di un documento da 10 MB restituisce l'*errore. `413 Request Entity Too Large`
AWS HealthLake ha un limite di 5 MB per le API di creazione e aggiornamento sincrono per evitare un aumento delle latenze e dei timeout. Puoi importare documenti di grandi dimensioni, fino a 164 MB, utilizzando il tipo di risorsa che utilizza l'`Binary`API Bulk Import.
## Integrazioni NLP
**Problema:** *come posso attivare la funzionalità integrata HealthLake di elaborazione del linguaggio naturale*?
A partire dal 14 novembre 2022, il comportamento predefinito degli archivi HealthLake dati è cambiato.
**Archivi dati attuali: tutti gli archivi** di HealthLake dati attuali smetteranno di utilizzare l'elaborazione del linguaggio naturale (NLP) su risorse con codifica `DocumentReference` base64. Ciò significa che `DocumentReference` le nuove risorse non verranno analizzate utilizzando l'NLP e non verranno generate nuove risorse in base al testo del tipo di risorsa. `DocumentReference` Per `DocumentReference` le risorse esistenti, i dati e le risorse generati tramite la PNL rimangono, ma non verranno aggiornati dopo il 20 febbraio 2023.
**Nuovi archivi** HealthLake dati: gli archivi dati creati dopo il 20 febbraio 2023 *non* eseguiranno l'elaborazione del linguaggio naturale (NLP) su risorse con codifica base64. `DocumentReference`
Per attivare l'integrazione HealthLake NLP, crea un caso di supporto utilizzando. [AWS Support Center Console](https://console.aws.amazon.com/support/home#/) Per creare il tuo caso, accedi al tuo Account AWS, quindi scegli **Crea** caso. Per ulteriori informazioni sulla creazione di un caso e sulla gestione dei casi, consulta [Creazione di casi di supporto e gestione dei casi](https://docs.aws.amazon.com/awssupport/latest/user/case-management.html) nella *Guida per l'Supporto utente*.
**Problema:** *>Come posso trovare `DocumentReference` risorse che non possono essere elaborate con la PNL integrata*?
Se una `DocumentReference` risorsa non è valida, HealthLake fornisce un'estensione che indica un errore di convalida anziché inserirlo nell'output di PNL medico integrato. **Per trovare `DocumentReference` le risorse che hanno portato a un errore di convalida durante l'elaborazione NLP, è possibile utilizzare la `search` funzione FHIR con la chiave di ricerca e il valore HealthLake di ricerca VALIDATION\$1ERROR. **cm-decoration-status**** Questa ricerca elencherà tutte le `DocumentReference` risorse che hanno portato a errori di convalida, insieme a un messaggio di errore che descrive la natura dell'errore. La struttura del campo di estensione in quelle `DocumentReference` risorse con errori di convalida sarà simile all'esempio seguente.
```
"extension": [
{
"extension": [
{
"url": "http://healthlake.amazonaws.com/aws-cm/status/",
"valueString": "VALIDATION_ERROR"
},
{
"url": "http://healthlake.amazonaws.com/aws-cm/message/",
"valueString": "Resource led to too many nested objects after NLP operation processed the document. 10937 nested objects exceeds the limit of 10000."
}
],
"url": "http://healthlake.amazonaws.com/aws-cm/"
}
]
```
**Nota**
A `VALIDATION_ERROR` può verificarsi anche se la decorazione NLP crea più di 10.000 oggetti annidati. Quando ciò accade, il documento deve essere suddiviso in documenti più piccoli prima dell'elaborazione.
## Integrazioni SQL
**Problema:** *Perché ottengo un Lake Formation `permissions error: lakeformation:PutDataLakeSettings` quando aggiungo un nuovo amministratore di data lake?*
Se il tuo utente o ruolo IAM contiene la policy `AWSLakeFormationDataAdmin` AWS gestita, non puoi aggiungere nuovi amministratori di data lake. Riceverai un errore contenente quanto segue:
```
User arn:aws:sts::111122223333:assumed-role/lakeformation-admin-user is not authorized to perform: lakeformation:PutDataLakeSettings on resource: arn:aws:lakeformation:us-east-2:111122223333:catalog:111122223333 with an explicit deny in an identity-based policy
```
La policy AWS gestita `AdministratorAccess` è necessaria per aggiungere un utente o un ruolo IAM come amministratore del data lake AWS Lake Formation. Se l'utente o il ruolo IAM contiene anche `AWSLakeFormationDataAdmin` l'azione avrà esito negativo. La policy `AWSLakeFormationDataAdmin` AWS gestita contiene un rifiuto esplicito per il funzionamento dell'API AWS Lake Formation,. `PutDataLakeSetting` Anche gli amministratori con accesso completo all' AWS utilizzo della policy `AdministratorAccess` gestita possono essere limitati dalla policy. `AWSLakeFormationDataAdmin`
**Problema:** *come posso migrare un HealthLake data store esistente per utilizzare l'integrazione con Amazon Athena SQL*?
HealthLake gli archivi di dati creati prima del 14 novembre 2022 sono funzionali, ma non sono interrogabili in Athena utilizzando SQL. Per interrogare un data store preesistente con Athena, devi prima migrarlo in un nuovo data store.
**Per migrare i HealthLake dati in un nuovo data store**
1. Crea un nuovo data store.
1. Esporta i dati dal bucket preesistente in un bucket Amazon S3.
1. Importa i dati nel nuovo data store dal bucket Amazon S3.
**Nota**
L'esportazione di dati in un bucket Amazon S3 comporta un costo aggiuntivo. Il costo aggiuntivo dipende dalla dimensione dei dati esportati.
**Problema:** *quando si crea un nuovo HealthLake data store per l'integrazione SQL, lo stato del data store non cambia da`Creating`.*
Se provi a creare un nuovo HealthLake data store e lo stato del tuo data store non cambia da **Creazione**, devi aggiornare Athena per utilizzare. AWS Glue Data Catalog Per ulteriori informazioni, consulta [l'aggiornamento al AWS Glue Data Catalog step-by-step](https://docs.aws.amazon.com/athena/latest/ug/glue-upgrade.html) nella Guida per l'utente di *Amazon Athena*.
Dopo aver aggiornato correttamente AWS Glue Data Catalog, puoi creare un data store. HealthLake
Per rimuovere un vecchio archivio HealthLake dati, crea una richiesta di supporto utilizzando. [AWS Support Center Console](https://console.aws.amazon.com/support/home#/) Per creare il tuo caso, accedi al tuo Account AWS, quindi scegli **Crea caso**. Per ulteriori informazioni, consulta [Creazione di casi di supporto e gestione dei casi](https://docs.aws.amazon.com/awssupport/latest/user/case-management.html) nella *Guida Supporto per l'utente*.
**Problema:** *la console Athena non funziona dopo l'importazione dei dati in un* nuovo archivio dati HealthLake
Dopo aver importato i dati in un nuovo archivio HealthLake dati, i dati potrebbero non essere disponibili per l'uso immediato. Questo serve per consentire ai dati di essere inseriti nelle tabelle di Apache Iceberg. Riprova in un secondo momento.
**Problema:** *come posso collegare i risultati di ricerca in Athena ad altri AWS servizi*?
Quando si condividono i risultati di ricerca di Athena con altri AWS servizi, possono verificarsi problemi quando li si utilizza `json_extract[1]` come parte di una query di ricerca SQL. Per risolvere questo problema, è necessario eseguire l'aggiornamento a`CATVAR`.
Potresti riscontrare questo problema quando provi a **creare** risultati di salvataggio, una **tabella** (statica) o una **vista** (dinamica).
# Utilizzo HealthLake con un AWS SDK
AWS i kit di sviluppo software (SDKs) sono disponibili per molti linguaggi di programmazione più diffusi. Ogni SDK fornisce un’API, esempi di codice e documentazione che facilitano agli sviluppatori la creazione di applicazioni nel loro linguaggio preferito.
| Documentazione sugli SDK | Esempi di codice |
| --- | --- |
| [AWS SDK per C\$1\$1](https://docs.aws.amazon.com/sdk-for-cpp) | [AWS SDK per C\$1\$1 esempi di codice](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/cpp) |
| [AWS CLI](https://docs.aws.amazon.com/cli) | [AWS CLI esempi di codice](https://docs.aws.amazon.com/code-library/latest/ug/cli_2_code_examples.html) |
| [AWS SDK per Go](https://docs.aws.amazon.com/sdk-for-go) | [AWS SDK per Go esempi di codice](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/gov2) |
| [AWS SDK per Java](https://docs.aws.amazon.com/sdk-for-java) | [AWS SDK per Java esempi di codice](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/javav2) |
| [AWS SDK per JavaScript](https://docs.aws.amazon.com/sdk-for-javascript) | [AWS SDK per JavaScript esempi di codice](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/javascriptv3) |
| [AWS SDK per Kotlin](https://docs.aws.amazon.com/sdk-for-kotlin) | [AWS SDK per Kotlin esempi di codice](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/kotlin) |
| [AWS SDK per .NET](https://docs.aws.amazon.com/sdk-for-net) | [AWS SDK per .NET esempi di codice](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/dotnetv3) |
| [AWS SDK per PHP](https://docs.aws.amazon.com/sdk-for-php) | [AWS SDK per PHP esempi di codice](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/php) |
| [AWS Strumenti per PowerShell](https://docs.aws.amazon.com/powershell) | [AWS Strumenti per PowerShell esempi di codice](https://docs.aws.amazon.com/code-library/latest/ug/powershell_5_code_examples.html) |
| [AWS SDK per Python (Boto3)](https://docs.aws.amazon.com/pythonsdk) | [AWS SDK per Python (Boto3) esempi di codice](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/python) |
| [AWS SDK per Ruby](https://docs.aws.amazon.com/sdk-for-ruby) | [AWS SDK per Ruby esempi di codice](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/ruby) |
| [AWS SDK per Rust](https://docs.aws.amazon.com/sdk-for-rust) | [AWS SDK per Rust esempi di codice](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/rustv1) |
| [AWS SDK per SAP ABAP](https://docs.aws.amazon.com/sdk-for-sapabap) | [AWS SDK per SAP ABAP esempi di codice](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/sap-abap) |
| [AWS SDK per Swift](https://docs.aws.amazon.com/sdk-for-swift) | [AWS SDK per Swift esempi di codice](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/swift) |
**Esempio di disponibilità**
Non riesci a trovare quello che ti serve? Richiedi un esempio di codice utilizzando il link **Fornisci un feedback** nella parte inferiore di questa pagina.