Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# AWS HealthLake référence
Les documents de référence complémentaires suivants sont disponibles pour SMART sur FHIR, FHIR et. AWS HealthLake
**Note**
Toutes les HealthLake actions natives et tous les types de données sont décrits dans une référence séparée. Pour plus d’informations, consultez la [Référence des API *AWS HealthLake *](https://docs.aws.amazon.com/healthlake/latest/APIReference/).
**Topics**
+ [SMART sur FHIR](reference-smart-on-fhir.md)
+ [FHIR R4](reference-fhir.md)
+ [Conformité d’](reference-compliance.md)
+ [HealthLake](reference-healthlake.md)
# SMART sur le support FHIR pour AWS HealthLake
Un magasin de HealthLake données compatible avec les applications médicales substituables et les technologies réutilisables (SMART) sur FHIR permet d'accéder aux applications compatibles SMART sur FHIR. HealthLake les données sont accessibles en authentifiant et en autorisant les demandes à l'aide d'un serveur d'autorisation tiers. Ainsi, au lieu de gérer les informations d'identification des utilisateurs via Gestion des identités et des accès AWS, vous le faites à l'aide d'un serveur d'autorisation compatible SMART on FHIR.
**Note**
HealthLake supporte SMART sur les versions 1.0 et 2.0 de FHIR. Pour en savoir plus sur ces frameworks, consultez [SMART App Launch](https://www.hl7.org/fhir/smart-app-launch/) dans la documentation *FHIR R4*.
HealthLake les magasins de données prennent en charge les cadres d'authentification et d'autorisation suivants pour les demandes SMART on FHIR :
**OpenID (AuthN)** : pour authentifier la personne ou l'application cliente, c'est la personne (ou ce que) elle prétend être.
**OAuth 2.0 (AuthZ)** : pour autoriser les ressources FHIR de votre magasin de HealthLake données sur lesquelles une demande authentifiée peut lire ou écrire. Ceci est défini par les étendues configurées sur votre serveur d'autorisation.
Vous pouvez créer un magasin de données compatible SMART sur FHIR à l'aide du AWS CLI ou AWS SDKs. Pour de plus amples informations, veuillez consulter [Création d'un magasin HealthLake de données](managing-data-stores-create.md).
**Topics**
+ [Commencer à utiliser SMART sur FHIR](reference-smart-on-fhir-getting-started.md)
+ [HealthLake exigences d'authentification pour SMART sur FHIR](reference-smart-on-fhir-authentication.md)
+ [SMART sur les oscilloscopes FHIR OAuth 2.0 pris en charge par HealthLake](reference-smart-on-fhir-oauth-scopes.md)
+ [Validation des jetons en utilisant AWS Lambda](reference-smart-on-fhir-token-validation.md)
+ [Utilisation d'une autorisation précise avec un magasin de données compatible SMART on FHIR HealthLake](reference-smart-on-fhir-fine-grained-authorization.md)
+ [Récupération du document SMART sur FHIR Discovery](reference-smart-on-fhir-discovery-document.md)
+ [Effectuer une demande d'API REST FHIR sur un magasin de données compatible SMART HealthLake](reference-smart-on-fhir-request-example.md)
# Commencer à utiliser SMART sur FHIR
Les rubriques suivantes décrivent comment démarrer avec SMART sur l'autorisation FHIR pour AWS HealthLake. Ils incluent les ressources que vous devez fournir sur votre AWS compte, la création d'un magasin de HealthLake données compatible SMART on FHIR et un exemple de la façon dont une application client SMART on FHIR interagit avec un serveur d'autorisation et un HealthLake magasin de données.
**Topics**
+ [Configuration des ressources pour SMART sur FHIR](#smart-on-fhir-resources)
+ [Flux de travail des applications clientes pour SMART sur FHIR](#smart-on-fhir-client-app-workflow)
## Configuration des ressources pour SMART sur FHIR
Les étapes suivantes définissent la manière dont les demandes SMART on FHIR sont traitées HealthLake et les ressources nécessaires pour qu'elles aboutissent. Les éléments suivants fonctionnent ensemble dans un flux de travail pour effectuer une demande SMART on FHIR :
+ **L'utilisateur final** : en général, un patient ou un clinicien utilisant une application SMART on FHIR tierce pour accéder aux données d'un HealthLake magasin de données.
+ **L'application SMART on FHIR (appelée application client) : application** qui souhaite accéder aux données présentes dans le magasin de HealthLake données.
+ **Le serveur d'autorisation** : un serveur compatible OpenID Connect capable d'authentifier les utilisateurs et d'émettre des jetons d'accès.
+ **Le magasin de HealthLake données** : un magasin de HealthLake données compatible SMART on FHIR qui utilise une fonction Lambda pour répondre aux requêtes REST FHIR qui fournissent un jeton porteur.
Pour que ces éléments fonctionnent ensemble, vous devez créer les ressources suivantes.
**Note**
Nous vous recommandons de créer votre banque de HealthLake données compatible SMART on FHIR après avoir configuré le serveur d'autorisation, défini les [étendues](reference-smart-on-fhir-oauth-scopes.md) nécessaires et créé une AWS Lambda fonction pour gérer l'introspection des [jetons](reference-smart-on-fhir-token-validation.md).
**1. Configuration d'un point de terminaison de serveur d'autorisation**
Pour utiliser le framework SMART on FHIR, vous devez configurer un serveur d'autorisation tiers capable de valider les requêtes REST FHIR effectuées sur un magasin de données. Pour de plus amples informations, veuillez consulter [HealthLake exigences d'authentification pour SMART sur FHIR](reference-smart-on-fhir-authentication.md).
**2. Définissez des étendues sur votre serveur d'autorisation pour contrôler les niveaux d'accès au magasin de HealthLake données**
Le framework SMART on FHIR utilise des OAuth portées pour déterminer à quelles ressources FHIR une demande authentifiée a accès et dans quelle mesure. La définition des étendues est un moyen de concevoir avec le moindre privilège. Pour de plus amples informations, veuillez consulter [SMART sur les oscilloscopes FHIR OAuth 2.0 pris en charge par HealthLake](reference-smart-on-fhir-oauth-scopes.md).
**3. Configurer une AWS Lambda fonction capable d'effectuer une introspection symbolique**
Une demande REST FHIR envoyée par l'application cliente sur un magasin de données compatible SMART on FHIR contient un jeton Web JSON (JWT). Pour plus d'informations, consultez la section [Décodage d'un JWT](reference-smart-on-fhir-token-validation.md).
**4. Créez un magasin de HealthLake données compatible SMART on FHIR**
Pour créer un magasin de HealthLake données SMART sur FHIR, vous devez fournir un`IdentityProviderConfiguration`. Pour de plus amples informations, veuillez consulter [Création d'un magasin HealthLake de données](managing-data-stores-create.md).
## Flux de travail des applications clientes pour SMART sur FHIR
La section suivante explique comment lancer une application cliente et effectuer une requête REST FHIR réussie sur un magasin de HealthLake données dans le contexte de SMART on FHIR.
**1. Faire une `GET` demande à Known Uniform Resource Identifier à l'aide de l'application cliente**
Une application cliente compatible SMART doit effectuer une `GET` demande pour trouver les points de terminaison d'autorisation de votre magasin de HealthLake données. Cela se fait via une demande d'identifiant de ressource uniforme (URI) bien connu. Pour de plus amples informations, veuillez consulter [Récupération du document SMART sur FHIR Discovery](reference-smart-on-fhir-discovery-document.md).
**2. Demande d'accès et champs d'application**
L'application cliente utilise le point de terminaison d'autorisation du serveur d'autorisation afin que l'utilisateur puisse se connecter. Ce processus authentifie l'utilisateur. Les étendues sont utilisées pour définir les ressources FHIR de votre magasin de HealthLake données auxquelles une application cliente peut accéder. Pour de plus amples informations, veuillez consulter [SMART sur les oscilloscopes FHIR OAuth 2.0 pris en charge par HealthLake](reference-smart-on-fhir-oauth-scopes.md).
**3. Jetons d'accès**
Maintenant que l'utilisateur est authentifié, une application cliente reçoit un jeton d'accès JWT du serveur d'autorisation. Ce jeton est fourni lorsque l'application cliente envoie une demande FHIR REST à HealthLake. Pour de plus amples informations, veuillez consulter [Validation des jetons](reference-smart-on-fhir-token-validation.md).
**4. Effectuer une demande d'API REST FHIR sur SMART sur un magasin de données activé HealthLake par FHIR**
L'application cliente peut désormais envoyer une demande d'API REST FHIR à un point de terminaison du magasin de HealthLake données à l'aide du jeton d'accès fourni par le serveur d'autorisation. Pour de plus amples informations, veuillez consulter [Effectuer une demande d'API REST FHIR sur un magasin de données compatible SMART HealthLake](reference-smart-on-fhir-request-example.md).
**5. Validez le jeton d'accès JWT**
Pour valider le jeton d'accès envoyé dans la requête REST FHIR, utilisez une fonction Lambda. Pour de plus amples informations, veuillez consulter [Validation des jetons en utilisant AWS Lambda](reference-smart-on-fhir-token-validation.md).
# HealthLake exigences d'authentification pour SMART sur FHIR
Pour accéder aux ressources FHIR dans un magasin de HealthLake données compatible SMART sur FHIR, une application cliente doit être autorisée par un serveur d'autorisation OAuth compatible 2.0 et présenter un jeton OAuth Bearer dans le cadre d'une demande d'API REST FHIR. Pour trouver le point de terminaison du serveur d'autorisation, utilisez le document HealthLake SMART on FHIR Discovery via un identifiant de ressource `Well-Known` uniforme. Pour en savoir plus sur ce processus, consultez [Récupération du document SMART sur FHIR Discovery](reference-smart-on-fhir-discovery-document.md).
Lorsque vous créez un magasin de HealthLake données SMART on FHIR, vous devez définir le point de terminaison du serveur d'autorisation et le point de terminaison du jeton dans l'`metadata`élément de la `CreateFHIRDatastore` demande. Pour en savoir plus sur la définition de l'`metadata`élément, voir[Création d'un magasin HealthLake de données](managing-data-stores-create.md).
À l'aide des points de terminaison du serveur d'autorisation, l'application cliente authentifie un utilisateur auprès du service d'autorisation. Une fois autorisé et authentifié, un jeton Web JSON (JWT) est généré par le service d'autorisation et transmis à l'application cliente. Ce jeton contient des étendues de ressources FHIR que l'application cliente est autorisée à utiliser, ce qui limite les données auxquelles l'utilisateur peut accéder. Facultativement, si le périmètre de lancement a été fourni, la réponse contiendra ces détails. Pour en savoir plus sur les oscilloscopes SMART on FHIR pris en charge par HealthLake, voir. [SMART sur les oscilloscopes FHIR OAuth 2.0 pris en charge par HealthLake](reference-smart-on-fhir-oauth-scopes.md)
À l'aide du JWT accordé par le serveur d'autorisation, une application cliente effectue des appels d'API REST FHIR à un magasin de données compatible HealthLake SMART sur FHIR. Pour valider et décoder le JWT, vous devez créer une fonction Lambda. HealthLake invoque cette fonction Lambda en votre nom lorsqu'une demande d'API REST FHIR est reçue. Pour voir un exemple de fonction Lambda de démarrage, reportez-vous à. [Validation des jetons en utilisant AWS Lambda](reference-smart-on-fhir-token-validation.md)
## Éléments du serveur d'autorisation requis pour créer un magasin de HealthLake données compatible SMART on FHIR
Dans la `CreateFHIRDatastore` demande, vous devez fournir le point de terminaison d'autorisation et le point de terminaison du jeton dans le cadre de l'`metadata`élément de l'`IdentityProviderConfiguration`objet. Le point de terminaison d'autorisation et le point de terminaison jeton sont tous deux requis. Pour voir un exemple de la manière dont cela est spécifié dans la `CreateFHIRDatastore` demande, voir[Création d'un magasin HealthLake de données](managing-data-stores-create.md).
## Réclamations requises pour compléter une demande d'API REST FHIR sur un magasin de données compatible HealthLake SMART on FHIR
Votre AWS Lambda fonction doit contenir les affirmations suivantes pour qu'il s'agisse d'une demande d'API REST FHIR valide sur un magasin de HealthLake données compatible SMART on FHIR.
+ `nbf`: [(Pas avant) Réclamation — La réclamation](https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.5) « nbf » (pas avant) indique le délai avant lequel le JWT NE DOIT PAS être accepté pour traitement. Le traitement de la réclamation « nbf » nécessite que le courant date/time DOIT être supérieur ou égal à celui date/time indiqué dans la réclamation « nbf ». L'exemple de fonction Lambda que nous fournissons convertit la réponse `iat` du serveur en. `nbf`
+ `exp`: [(Date d'expiration) Réclamation](https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.4) — La demande « exp » (délai d'expiration) identifie le délai d'expiration à partir duquel ou après lequel le JWT ne doit pas être accepté pour traitement.
+ `isAuthorized`: un booléen défini sur. `True` Indique que la demande a été autorisée sur le serveur d'autorisation.
+ `aud`: Réclamation [(audience) — La réclamation](https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.3) « aud » (audience) identifie les destinataires auxquels le JWT est destiné. Il doit s'agir d'un point de terminaison de banque de HealthLake données compatible SMART on FHIR.
+ `scope`: Il doit s'agir d'au moins une étendue liée à une ressource FHIR. Cette étendue est définie sur votre serveur d'autorisation. Pour en savoir plus sur les champs d'application liés aux ressources FHIR acceptés par HealthLake, voir. [SMART sur les champs de ressources FHIR pour HealthLake](reference-smart-on-fhir-oauth-scopes.md#smart-on-fhir-scopes-rest)
# SMART sur les oscilloscopes FHIR OAuth 2.0 pris en charge par HealthLake
HealthLake utilise le OAuth 2.0 comme protocole d'autorisation. L'utilisation de ce protocole sur votre serveur d'autorisation vous permet de définir HealthLake des autorisations de stockage de données (création, lecture, mise à jour, suppression et recherche) pour les ressources FHIR auxquelles une application cliente a accès.
Le framework SMART on FHIR définit un ensemble de champs d'application qui peuvent être demandés au serveur d'autorisation. Par exemple, une application client conçue uniquement pour permettre aux patients de consulter leurs résultats de laboratoire ou de consulter leurs coordonnées ne doit être *autorisée* qu'à demander `read` des scopes.
**Note**
HealthLake fournit un support pour SMART sur FHIR V1 et V2, comme décrit ci-dessous. Le SMART on FHIR [https://docs.aws.amazon.com/healthlake/latest/APIReference/API_IdentityProviderConfiguration.html#HealthLake-Type-IdentityProviderConfiguration-AuthorizationStrategy](https://docs.aws.amazon.com/healthlake/latest/APIReference/API_IdentityProviderConfiguration.html#HealthLake-Type-IdentityProviderConfiguration-AuthorizationStrategy)est défini sur l'une des trois valeurs suivantes lors de la création de votre magasin de données :
`SMART_ON_FHIR_V1`— Support uniquement pour SMART sur FHIR V1, qui inclut les autorisations `read` (lecture/recherche) et `write` (create/update/delete).
`SMART_ON_FHIR`— Support de SMART sur FHIR V1 et V2, qui inclut`create`,`read`, `update``delete`, et `search` les autorisations.
`AWS_AUTH`— La stratégie AWS HealthLake d'autorisation par défaut ; non affiliée à SMART on FHIR.
## Périmètre de lancement autonome
HealthLake prend en charge le champ `launch/patient` d'application du mode de lancement autonome.
En mode de lancement autonome, une application client demande l'accès aux données cliniques du patient car l'utilisateur et le patient ne sont pas connus de l'application cliente. Ainsi, la demande d'autorisation de l'application cliente demande explicitement que le dossier du patient soit renvoyé. Une fois l'authentification réussie, le serveur d'autorisation émet un jeton d'accès contenant le champ d'application du patient de lancement demandé. Le contexte patient nécessaire est fourni avec le jeton d'accès dans la réponse du serveur d'autorisation.
**Champs d'application du mode de lancement pris en charge**
| Scope | Description |
| --- | --- |
| `launch/patient` | Paramètre d'une demande d'autorisation OAuth 2.0 demandant que les données du patient soient renvoyées dans la réponse d'autorisation. |
## SMART sur les champs de ressources FHIR pour HealthLake
HealthLake définit trois niveaux de SMART sur les étendues de ressources FHIR.
+ `patient`les scopes donnent accès à des données spécifiques concernant un seul patient.
+ `user`les étendues donnent accès à des données spécifiques auxquelles un utilisateur peut accéder.
+ `system`les étendues donnent accès à toutes les ressources FHIR présentes dans le magasin de HealthLake données.
Les sections suivantes répertorient la syntaxe permettant de créer des étendues de ressources FHIR à l'aide de SMART sur FHIR V1 ou SMART sur FHIR V2.
**Note**
La stratégie d'autorisation SMART on FHIR est définie lors de la création de votre magasin de données. Pour plus d’informations, consultez [https://docs.aws.amazon.com/healthlake/latest/APIReference/API_IdentityProviderConfiguration.html#HealthLake-Type-IdentityProviderConfiguration-AuthorizationStrategy](https://docs.aws.amazon.com/healthlake/latest/APIReference/API_IdentityProviderConfiguration.html#HealthLake-Type-IdentityProviderConfiguration-AuthorizationStrategy) dans la *Référence d’API AWS HealthLake *.
### SMART sur les oscilloscopes FHIR V1 pris en charge par HealthLake
Lorsque vous utilisez SMART sur FHIR V1, la syntaxe générale pour la construction des étendues de ressources FHIR est la suivante. HealthLake Pour afficher le chemin complet de l'URL dans l'exemple suivant, faites défiler le curseur sur le bouton **Copier**.
```
('patient' | 'user' | 'system') '/' (fhir-resource | '*') '.' ('read' | 'write' | '*')
```
**Champs d'autorisation pris en charge par SMART on FHIR v1**
| Syntaxe Scope | Exemple de champ d'application | Résultat |
| --- | --- | --- |
| `patient/(fhir-resource \| '*').('read' \| 'write' \| '*')` | patient/AllergyIntolerance.\$1 | L'application client du patient dispose d'un accès en lecture/écriture au niveau de l'instance à toutes les allergies enregistrées. |
| `user/(fhir-resource \| '*').('read' \| 'write' \| '*')` | user/Observation.read | L'application cliente utilisateur dispose d'un read/write accès au niveau de l'instance à toutes les observations enregistrées. |
| system/('read' \$1 'write' \$1 \$1) | system/\$1.\$1 | L'application cliente du système a read/write accès à toutes les données des ressources FHIR. |
### SMART sur les oscilloscopes FHIR V2 pris en charge par HealthLake
Lorsque vous utilisez SMART sur FHIR V2, la syntaxe générale pour la construction des étendues de ressources FHIR est la suivante. HealthLake Pour afficher le chemin complet de l'URL dans l'exemple suivant, faites défiler le curseur sur le bouton **Copier**.
```
('patient' | 'user' | 'system') '/' (fhir-resource | '*') '.' ('c' | 'r' | 'u' | 'd' | 's')
```
**Note**
Pour utiliser SMART sur FHIR V2, vous devez transmettre la valeur [https://hl7.org/fhir/smart-app-launch/STU2/conformance.html#permissions](https://hl7.org/fhir/smart-app-launch/STU2/conformance.html#permissions)dans la `capabilities` chaîne de métadonnées, qui est membre du type de [https://docs.aws.amazon.com/healthlake/latest/APIReference/API_IdentityProviderConfiguration.html](https://docs.aws.amazon.com/healthlake/latest/APIReference/API_IdentityProviderConfiguration.html)données.
HealthLake prend en charge les oscilloscopes granulaires. Pour plus d'informations, voir les [étendues granulaires prises en charge](https://hl7.org/fhir/us/core/scopes.html#the-following-granular-scopes-shall-be-supported) dans le guide de mise en œuvre de *FHIR US Core*.
**Étendue d'autorisation compatible avec SMART on FHIR V2**
| Syntaxe Scope | Exemple de scope V1 | Résultat |
| --- | --- | --- |
| `patient/Observation.rs` | user/Observation.read | Autorisation de lire et de rechercher Observation une ressource pour le patient actuel. |
| `system/*.cruds` | system/\$1.\$1 | L'application cliente du système dispose d'un create/read/update/delete/search accès complet à toutes les données de ressources FHIR. |
# Validation des jetons en utilisant AWS Lambda
Lorsque vous créez un magasin de données compatible HealthLake SMART sur FHIR, vous devez fournir l'ARN de la AWS Lambda fonction dans la `CreateFHIRDatastore` demande. L'ARN de la fonction Lambda est spécifié dans l'`IdentityProviderConfiguration`objet à l'aide du `IdpLambdaArn` paramètre.
Vous devez créer la fonction Lambda avant de créer votre magasin de données compatible SMART on FHIR. Une fois que vous avez créé le magasin de données, l'ARN Lambda ne peut pas être modifié. Pour voir l'ARN Lambda que vous avez spécifié lors de la création du magasin de données, utilisez l'action `DescribeFHIRDatastore` API.
**Pour qu'une demande REST FHIR aboutisse sur un magasin de données compatible SMART on FHIR, votre fonction Lambda doit effectuer les opérations suivantes :**
+ Renvoie une réponse en moins d'une seconde au point de terminaison du magasin de HealthLake données.
+ Décodez le jeton d'accès fourni dans l'en-tête d'autorisation de la demande d'API REST envoyée par l'application cliente.
+ Attribuez un rôle de service IAM doté d'autorisations suffisantes pour exécuter la demande d'API REST FHIR.
+ Les demandes suivantes sont requises pour compléter une demande d'API REST FHIR. Pour en savoir plus, veuillez consulter la section [Demandes requises](reference-smart-on-fhir-authentication.md#server-response).
+ `nbf`
+ `exp`
+ `isAuthorized`
+ `aud`
+ `scope`
Lorsque vous travaillez avec Lambda, vous devez créer un rôle d'exécution et une politique basée sur les ressources en plus de votre fonction Lambda. Le rôle d'exécution d'une fonction Lambda est un rôle IAM qui accorde à la fonction l'autorisation d'accéder aux services et aux ressources AWS nécessaires au moment de l'exécution. La politique basée sur les ressources que vous fournissez doit HealthLake permettre d'invoquer votre fonction en votre nom.
Les sections de cette rubrique décrivent un exemple de demande provenant d'une application cliente et une réponse décodée, les étapes nécessaires à la création d'une fonction AWS Lambda et la manière de créer une politique basée sur les ressources qui peut être assumée. HealthLake
+ [Partie 1 : Création d'une fonction Lambda](#smart-on-fhir-lambda-create)
+ [Partie 2 : Création d'un rôle HealthLake de service utilisé par la fonction AWS Lambda](#smart-on-fhir-lambda-service-role)
+ [Partie 3 : Mise à jour du rôle d'exécution de la fonction Lambda](#smart-on-fhir-lambda-service-role-execution-role)
+ [Partie 4 : Ajouter une politique de ressources à votre fonction Lambda](#smart-on-fhir-lambda-invoke-healthlake)
+ [Partie 5 : Configuration de la simultanéité pour votre fonction Lambda](#smart-on-fhir-lambda-function-scaling)
## Création d'une fonction AWS Lambda
La fonction Lambda créée dans cette rubrique est déclenchée lors de la HealthLake réception d'une demande à un magasin de données compatible SMART on FHIR. La demande de l'application cliente contient un appel d'API REST et un en-tête d'autorisation contenant un jeton d'accès.
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/
Authorization: Bearer i8hweunweunweofiwweoijewiwe
```
L'exemple de fonction Lambda présenté dans cette rubrique permet de masquer AWS Secrets Manager les informations d'identification liées au serveur d'autorisation. Nous vous recommandons vivement de ne pas fournir les informations de connexion au serveur d'autorisation directement dans une fonction Lambda.
**Example validation d'une requête REST FHIR contenant un jeton porteur d'autorisation**
L'exemple de fonction Lambda vous montre comment valider une demande REST FHIR envoyée à un magasin de données compatible SMART on FHIR. Pour savoir step-by-steps comment implémenter cette fonction Lambda, consultez. [Création d'une fonction Lambda à l'aide du AWS Management Console](#create-lambda-console)
Si la demande d'API REST FHIR ne contient pas de point de terminaison de stockage de données, de jeton d'accès et d'opération REST valides, la fonction Lambda échouera. Pour en savoir plus sur les éléments du serveur d'autorisation requis, consultez[Demandes requises](reference-smart-on-fhir-authentication.md#server-response).
```
import base64
import boto3
import logging
import json
import os
from urllib import request, parse
logger = logging.getLogger()
logger.setLevel(logging.INFO)
## Uses Secrets manager to gain access to the access key ID and secret access key for the authorization server
client = boto3.client('secretsmanager', region_name="region-of-datastore")
response = client.get_secret_value(SecretId='name-specified-by-customer-in-secretsmanager')
secret = json.loads(response['SecretString'])
client_id = secret['client_id']
client_secret = secret['client_secret']
unencoded_auth = f'{client_id}:{client_secret}'
headers = {
'Authorization': f'Basic {base64.b64encode(unencoded_auth.encode()).decode()}',
'Content-Type': 'application/x-www-form-urlencoded'
}
auth_endpoint = os.environ['auth-server-base-url'] # Base URL of the Authorization server
user_role_arn = os.environ['iam-role-arn'] # The IAM role client application will use to complete the HTTP request on the datastore
def lambda_handler(event, context):
if 'datastoreEndpoint' not in event or 'operationName' not in event or 'bearerToken' not in event:
return {}
datastore_endpoint = event['datastoreEndpoint']
operation_name = event['operationName']
bearer_token = event['bearerToken']
logger.info('Datastore Endpoint [{}], Operation Name: [{}]'.format(datastore_endpoint, operation_name))
## To validate the token
auth_response = auth_with_provider(bearer_token)
logger.info('Auth response: [{}]'.format(auth_response))
auth_payload = json.loads(auth_response)
## Required parameters needed to be sent to the datastore endpoint for the HTTP request to go through
auth_payload["isAuthorized"] = bool(auth_payload["active"])
auth_payload["nbf"] = auth_payload["iat"]
return {"authPayload": auth_payload, "iamRoleARN": user_role_arn}
## access the server
def auth_with_provider(token):
data = {'token': token, 'token_type_hint': 'access_token'}
req = request.Request(url=auth_endpoint + '/v1/introspect', data=parse.urlencode(data).encode(), headers=headers)
with request.urlopen(req) as resp:
return resp.read().decode()
```
### Création d'une fonction Lambda à l'aide du AWS Management Console
La procédure suivante suppose que vous avez déjà créé le rôle de service que vous HealthLake souhaitez assumer lors du traitement d'une demande d'API REST FHIR sur un magasin de données compatible SMART sur FHIR. Si vous n'avez pas créé le rôle de service, vous pouvez toujours créer la fonction Lambda. Vous devez ajouter l'ARN du rôle de service pour que la fonction Lambda fonctionne. Pour en savoir plus sur la création d'un rôle de service et sa spécification dans la fonction Lambda, voir [Création d'un rôle HealthLake de service à utiliser dans la fonction AWS Lambda utilisée pour décoder un JWT](#smart-on-fhir-lambda-service-role)
**Pour créer une fonction Lambda ()AWS Management Console**
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home/functions) (Fonctions) de la console Lambda.
1. Choisissez **Créer une fonction**.
1. Sélectionnez **Créer à partir de zéro**.
1. Dans **Informations de base**, entrez le **nom de la fonction**. Sous **Runtime**, choisissez un environnement d'exécution basé sur Python.
1. Pour **Execution role** (Rôle d'exécution), choisissez **Create a new role with basic Lambda permissions** (Créer un nouveau rôle avec les autorisations Lambda de base).
Lambda crée un [rôle d'exécution](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html) qui accorde à la fonction l'autorisation de télécharger des journaux sur Amazon. CloudWatch La fonction Lambda assume le rôle d'exécution lorsque vous appelez votre fonction et utilise le rôle d'exécution pour créer des informations d'identification pour le AWS SDK.
1. Choisissez l'onglet **Code** et ajoutez l'exemple de fonction Lambda.
Si vous n'avez pas encore créé le rôle de service que la fonction Lambda doit utiliser, vous devez le créer pour que l'exemple de fonction Lambda fonctionne. Pour en savoir plus sur la création d'un rôle de service pour la fonction Lambda, consultez. [Création d'un rôle HealthLake de service à utiliser dans la fonction AWS Lambda utilisée pour décoder un JWT](#smart-on-fhir-lambda-service-role)
```
import base64
import boto3
import logging
import json
import os
from urllib import request, parse
logger = logging.getLogger()
logger.setLevel(logging.INFO)
## Uses Secrets manager to gain access to the access key ID and secret access key for the authorization server
client = boto3.client('secretsmanager', region_name="region-of-datastore")
response = client.get_secret_value(SecretId='name-specified-by-customer-in-secretsmanager')
secret = json.loads(response['SecretString'])
client_id = secret['client_id']
client_secret = secret['client_secret']
unencoded_auth = f'{client_id}:{client_secret}'
headers = {
'Authorization': f'Basic {base64.b64encode(unencoded_auth.encode()).decode()}',
'Content-Type': 'application/x-www-form-urlencoded'
}
auth_endpoint = os.environ['auth-server-base-url'] # Base URL of the Authorization server
user_role_arn = os.environ['iam-role-arn'] # The IAM role client application will use to complete the HTTP request on the datastore
def lambda_handler(event, context):
if 'datastoreEndpoint' not in event or 'operationName' not in event or 'bearerToken' not in event:
return {}
datastore_endpoint = event['datastoreEndpoint']
operation_name = event['operationName']
bearer_token = event['bearerToken']
logger.info('Datastore Endpoint [{}], Operation Name: [{}]'.format(datastore_endpoint, operation_name))
## To validate the token
auth_response = auth_with_provider(bearer_token)
logger.info('Auth response: [{}]'.format(auth_response))
auth_payload = json.loads(auth_response)
## Required parameters needed to be sent to the datastore endpoint for the HTTP request to go through
auth_payload["isAuthorized"] = bool(auth_payload["active"])
auth_payload["nbf"] = auth_payload["iat"]
return {"authPayload": auth_payload, "iamRoleARN": user_role_arn}
## Access the server
def auth_with_provider(token):
data = {'token': token, 'token_type_hint': 'access_token'}
req = request.Request(url=auth_endpoint + '/v1/introspect', data=parse.urlencode(data).encode(), headers=headers)
with request.urlopen(req) as resp:
return resp.read().decode()
```
### Modifier le rôle d'exécution d'une fonction Lambda
Après avoir créé la fonction Lambda, vous devez mettre à jour le rôle d'exécution afin d'inclure les autorisations nécessaires pour appeler Secrets Manager. Dans Secrets Manager, chaque secret que vous créez possède un ARN. Pour appliquer le moindre privilège, le rôle d'exécution ne doit avoir accès qu'aux ressources nécessaires à l'exécution de la fonction Lambda.
Vous pouvez modifier le rôle d'exécution d'une fonction Lambda en la recherchant dans la console IAM ou en choisissant **Configuration** dans la console Lambda. Pour en savoir plus sur la gestion de votre rôle d'exécution des fonctions Lambda, consultez. [Rôle d’exécution Lambda](#smart-on-fhir-lambda-service-role-execution-role)
**Example Rôle d'exécution de la fonction Lambda qui donne accès à `GetSecretValue`**
L'ajout de l'action IAM `GetSecretValue` au rôle d'exécution accorde l'autorisation nécessaire au fonctionnement de l'exemple de fonction Lambda.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "secretsmanager:GetSecretValue",
"Resource": "arn:aws:secretsmanager:us-east-1:123456789012:secret:secret-name-DKodTA"
}
]
}
```
À ce stade, vous avez créé une fonction Lambda qui peut être utilisée pour valider le jeton d'accès fourni dans le cadre de la demande REST FHIR envoyée à votre banque de données compatible SMART on FHIR.
## Création d'un rôle HealthLake de service à utiliser dans la fonction AWS Lambda utilisée pour décoder un JWT
**Persona : administrateur IAM**
Utilisateur qui peut ajouter ou supprimer des politiques IAM et créer de nouvelles identités IAM.
**Rôle de service **
Un rôle de service est un [rôle IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) qu’un service endosse pour accomplir des actions en votre nom. Un administrateur IAM peut créer, modifier et supprimer un rôle de service à partir d’IAM. Pour plus d’informations, consultez [Création d’un rôle pour la délégation d’autorisations à un Service AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) dans le *Guide de l’utilisateur IAM*.
Une fois le jeton Web JSON (JWT) décodé, l'autorisation dont Lambda a besoin doit également renvoyer un ARN de rôle IAM. Ce rôle doit disposer des autorisations nécessaires pour exécuter la demande d'API REST, sinon il échouera en raison d'autorisations insuffisantes.
Lorsque vous configurez une politique personnalisée à l'aide d'IAM, il est préférable d'accorder les autorisations minimales requises. Pour en savoir plus, consultez la section [Appliquer les autorisations de moindre privilège](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) dans le Guide de l'utilisateur *IAM*.
La création d'un rôle de HealthLake service à désigner dans la fonction Lambda d'autorisation nécessite deux étapes.
+ Tout d'abord, vous devez créer une politique IAM. La politique doit spécifier l'accès aux ressources FHIR pour lesquelles vous avez fourni des étendues sur le serveur d'autorisation.
+ Ensuite, vous devez créer le rôle de service. Lorsque vous créez le rôle, vous désignez une relation de confiance et vous y associez la politique que vous avez créée à la première étape. La relation de confiance désigne HealthLake le principal du service. Vous devez spécifier un ARN de stockage de HealthLake données et un ID de AWS compte au cours de cette étape.
### Création d'une nouvelle politique IAM
Les étendues que vous définissez dans votre serveur d'autorisation déterminent les ressources FHIR auxquelles un utilisateur authentifié a accès dans un HealthLake magasin de données.
La politique IAM que vous créez peut être adaptée aux étendues que vous avez définies.
Les actions suivantes peuvent être définies dans l'`Action`élément d'une déclaration de politique IAM. Pour chacun `Action` des éléments du tableau, vous pouvez définir un`Resource types`. Dans HealthLake un magasin de données, le seul type de ressource pris en charge peut être défini dans l'`Resource`élément d'une déclaration de politique d'autorisation IAM.
Les ressources FHIR individuelles ne sont pas des ressources que vous pouvez définir en tant qu'élément d'une politique d'autorisation IAM.
**Actions définies par HealthLake**
| Actions | Description | Niveau d’accès | Type de ressource (obligatoire) |
| --- | --- | --- | --- |
| CreateResource | Accorde l'autorisation de créer une ressource | Écrire | ARN de la banque de données : arn:aws:healthlake : ::datastore/fhir/ your-region 111122223333 your-datastore-id |
| DeleteResource | Accorde l'autorisation de supprimer une ressource | Écrire | ARN de la banque de données : arn:aws:healthlake : ::datastore/fhir/ your-region 111122223333 your-datastore-id |
| ReadResource | Accorde l'autorisation de lire une ressource | Lecture | ARN de la banque de données : arn:aws:healthlake : ::datastore/fhir/ your-region 111122223333 your-datastore-id |
| SearchWithGet | Accorde l'autorisation de rechercher des ressources avec la méthode GET | Lecture | ARN de la banque de données : arn:aws:healthlake : ::datastore/fhir/ your-region 111122223333 your-datastore-id |
| SearchWithPost | Accorde l'autorisation de rechercher des ressources avec la méthode POST | Lecture | ARN de la banque de données : arn:aws:healthlake : ::datastore/fhir/ your-region 111122223333 your-datastore-id |
| Démarrer FHIRExport JobWithPost | Donne l'autorisation de commencer un travail d'exportation FHIR avec GET | Écrire | ARN de la banque de données : arn:aws:healthlake : ::datastore/fhir/ your-region 111122223333 your-datastore-id |
| UpdateResource | Accorde l'autorisation de mettre à jour des ressources | Écrire | ARN de la banque de données : arn:aws:healthlake : ::datastore/fhir/ your-region 111122223333 your-datastore-id |
Pour commencer, vous pouvez utiliser`AmazonHealthLakeFullAccess`. Cette politique autoriserait la lecture, l'écriture, la recherche et l'exportation de toutes les ressources FHIR présentes dans un magasin de données. Pour accorder des autorisations de lecture seule sur un magasin de données, utilisez. `AmazonHealthLakeReadOnlyAccess`
Pour en savoir plus sur la création d'une politique personnalisée à l'aide de AWS Management Console AWS CLI, ou IAM SDKs, consultez la section [Création de politiques IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) dans le guide de l'utilisateur *IAM*.
### Création d'un rôle de service pour HealthLake (console IAM)
Utilisez cette procédure pour créer un rôle de service. Lorsque vous créez un service, vous devez également définir une politique IAM.
**Pour créer le rôle de service pour HealthLake (console IAM)**
1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.
1. Dans le panneau de navigation de la console IAM, choisissez **Rôles**.
1. Puis, choisissez **Create role** (Créer un rôle).
1. Sur la page **Sélectionner une entité de confiance**, choisissez **Politique de confiance personnalisée**.
1. Ensuite, sous **Politique de confiance personnalisée**, mettez à jour l'exemple de politique comme suit. Remplacez-le **your-account-id** par votre numéro de compte et ajoutez l'ARN du magasin de données que vous souhaitez utiliser dans vos tâches d'importation ou d'exportation.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Principal": {
"Service": "healthlake.amazonaws.com"
},
"Condition": {
"StringEquals": {
"aws:SourceAccount": "123456789012"
},
"ArnEquals": {
"aws:SourceArn": "arn:aws:healthlake:us-east-1:123456789012:datastore/fhir/your-datastore-id"
}
}
}
]
}
```
------
1. Ensuite, choisissez **Suivant**.
1. Sur la page **Ajouter des autorisations**, choisissez la politique que vous souhaitez que le HealthLake service adopte. Pour trouver votre politique, recherchez-la dans **Politiques d'autorisations**.
1. Choisissez ensuite **Attach policy**.
1. Ensuite, sur la page **Nom, révision et création** sous **Nom du rôle**, entrez un nom.
1. (Facultatif) Ensuite, sous **Description**, ajoutez une brève description de votre rôle.
1. Si possible, saisissez un nom de rôle ou le suffixe d'un nom de rôle vous permettant d'identifier l'objectif du rôle. Les noms de rôle doivent être uniques dans votre Compte AWS. Ils ne sont pas distingués au cas par cas. Par exemple, vous ne pouvez pas créer deux rôles nommés **PRODROLE** et **prodrole**. Différentes entités peuvent référencer le rôle et il n'est donc pas possible de modifier son nom après sa création.
1. Passez en revue les détails du rôle, puis choisissez **Créer un rôle**.
Pour savoir comment spécifier l'ARN du rôle dans l'exemple de fonction Lambda, consultez. [Création d'une fonction AWS Lambda](#smart-on-fhir-lambda-create)
## Rôle d’exécution Lambda
Le rôle d'exécution d'une fonction Lambda est un rôle IAM qui accorde à la fonction l'autorisation d'accéder aux AWS services et aux ressources. Cette page fournit des informations sur la façon de créer, d’afficher et de gérer le rôle d’exécution d’une fonction Lambda.
Par défaut, Lambda crée un rôle d'exécution avec des autorisations minimales lorsque vous créez une nouvelle fonction Lambda à l'aide du. AWS Management Console Pour gérer les autorisations accordées dans le rôle d'exécution, consultez la section [Création d'un rôle d'exécution dans la console IAM](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html#permissions-executionrole-console) du guide du développeur *Lambda*.
L'exemple de fonction Lambda fourni dans cette rubrique utilise Secrets Manager pour masquer les informations d'identification du serveur d'autorisation.
Comme pour tout rôle IAM que vous créez, il est important de suivre les meilleures pratiques du moindre privilège. Au cours de la phase de développement, vous pouvez parfois accorder des autorisations au-delà de ce qui est requis. Avant de publier votre fonction dans l’environnement de production, une bonne pratique consiste à ajuster la stratégie de manière à inclure uniquement les autorisations requises. Pour plus d'informations, consultez la section [Appliquer le moindre privilège dans](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) le guide de l'utilisateur *IAM*.
## HealthLake Autoriser le déclenchement de votre fonction Lambda
HealthLake Vous pouvez donc invoquer la fonction Lambda en votre nom, vous devez procéder comme suit :
+ Vous devez définir une `IdpLambdaArn` valeur égale à l'ARN de la fonction Lambda que vous HealthLake souhaitez invoquer dans la `CreateFHIRDatastore` demande.
+ Vous avez besoin d'une politique basée sur les ressources permettant HealthLake d'appeler la fonction Lambda en votre nom.
Lorsqu'il HealthLake reçoit une demande d'API REST FHIR sur un magasin de données compatible SMART on FHIR, il a besoin d'autorisations pour appeler la fonction Lambda spécifiée lors de la création du magasin de données en votre nom. Pour accorder HealthLake l'accès, vous allez utiliser une politique basée sur les ressources. *Pour en savoir plus sur la création d'une politique basée sur les ressources pour une fonction Lambda, voir [Autoriser un AWS service à appeler une fonction Lambda](https://docs.aws.amazon.com/lambda/latest/dg/access-control-resource-based.html#permissions-resource-serviceinvoke) dans le Guide du développeur.AWS Lambda *
## Provisionnement de la simultanéité pour votre fonction Lambda
**Important**
HealthLake exige que la durée d'exécution maximale de votre fonction Lambda soit inférieure à une seconde (1 000 millisecondes).
Si votre fonction Lambda dépasse la limite de temps d'exécution, vous obtenez une TimeOutexception.
Pour éviter cette exception, nous vous recommandons de configurer la simultanéité provisionnée. En allouant la simultanéité provisionnée avant une augmentation des appels, vous pouvez vous assurer que toutes les demandes sont servies par des instances initialisées avec une faible latence. *Pour en savoir plus sur la configuration de la simultanéité provisionnée, voir [Configuration de la simultanéité provisionnée dans le Guide du développeur](https://docs.aws.amazon.com/ambda/latest/dg/provisioned-concurrency.html) Lambda*
Pour connaître la durée d'exécution moyenne de votre fonction Lambda, utilisez actuellement la page de **surveillance** de votre fonction Lambda sur la console Lambda. Par défaut, la console Lambda fournit un graphique de **durée** qui indique le temps moyen, minimum et maximum consacré par votre code de fonction au traitement d'un événement. *Pour en savoir plus sur la surveillance des fonctions Lambda, consultez la section [Surveillance des fonctions dans la console Lambda dans le guide du développeur Lambda](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-functions-access-metrics.html#monitoring-console-graph-types).*
*Si vous avez déjà configuré la simultanéité pour votre fonction Lambda et que vous souhaitez la surveiller, consultez la section [Surveillance de la simultanéité](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-concurrency.html) dans le guide du développeur Lambda.*
# Utilisation d'une autorisation précise avec un magasin de données compatible SMART on FHIR HealthLake
[Les champs](reference-smart-on-fhir-oauth-scopes.md#smart-on-fhir-scopes-rest) d'application à eux seuls ne vous fournissent pas les précisions nécessaires quant aux données auxquelles un demandeur est autorisé à accéder dans un magasin de données. L'utilisation d'une autorisation précise permet d'obtenir un niveau de spécificité plus élevé lors de l'octroi de l'accès à un magasin de données compatible HealthLake SMART on FHIR. Pour utiliser une autorisation précise, définissez la `FineGrainedAuthorizationEnabled` valeur égale à `True` dans le `IdentityProviderConfiguration` paramètre de votre `CreateFHIRDatastore` demande.
Si vous avez activé l'autorisation détaillée, votre serveur d'autorisation renvoie une `fhirUser` étendue en `id_token` même temps que le jeton d'accès. Cela permet de récupérer des informations sur l'utilisateur par l'application cliente. L'application cliente doit traiter la `fhirUser` demande comme l'URI d'une ressource FHIR représentant l'utilisateur actuel. Cette valeur peut être `Patient`, `Practitioner` ou `RelatedPerson`. La réponse du serveur d'autorisation inclut également une `user/` étendue qui définit les données auxquelles l'utilisateur peut accéder. Cela utilise la syntaxe définie pour les portées liées aux portées spécifiques aux ressources FHIR :
```
user/(fhir-resource | '*').('read' | 'write' | '*')
```
Vous trouverez ci-dessous des exemples de la manière dont une autorisation précise peut être utilisée pour spécifier davantage les types de ressources FHIR liés à l'accès aux données.
+ Quand `fhirUser` une `Practitioner` autorisation précise détermine-t-elle le nombre de patients auxquels l'utilisateur peut accéder. L'accès à n'`fhirUser`est autorisé qu'aux patients auxquels le patient fait référence en `fhirUser` tant que médecin généraliste.
```
Patient.generalPractitioner : [{Reference(Practitioner)}]
```
+ Quand `fhirUser` un `Patient` ou `RelatedPerson` le patient référencé dans la demande est différent de `fhirUser` l'autorisation précise détermine l'accès `fhirUser` du patient demandé. L'accès est autorisé lorsqu'une relation est spécifiée dans la `Patient` ressource demandée.
```
Patient.link.other : {Reference(Patient|RelatedPerson)}
```
# Récupération du document SMART sur FHIR Discovery
SMART définit un document de découverte qui permet aux clients de connaître le point de terminaison d'autorisation URLs et propose des fonctionnalités prises en charge par un magasin de HealthLake données. Ces informations aident les clients à diriger les demandes d'autorisation vers le point de terminaison approprié et à créer des demandes d'autorisation prises en charge par le magasin de HealthLake données.
Pour qu'une application cliente puisse envoyer une demande FHIR REST réussie HealthLake, elle doit rassembler les exigences d'autorisation définies par le magasin de HealthLake données. Aucun jeton porteur (autorisation) *n'*est requis pour que cette demande aboutisse.
**Pour demander le document de découverte pour un magasin HealthLake de données**
1. Collectez HealthLake `region` et `datastoreId` valorisez. Pour de plus amples informations, veuillez consulter [Obtenir les propriétés du magasin de données](managing-data-stores-describe.md).
1. Construisez une URL pour la demande en utilisant les valeurs collectées pour HealthLake `region` et`datastoreId`. Ajouter au point `/.well-known/smart-configuration` de terminaison de l'URL. Pour afficher le chemin complet de l'URL dans l'exemple suivant, faites défiler le curseur sur le bouton **Copier**.
```
https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/.well-known/smart-configuration
```
1. Envoyez la demande en utilisant `GET` le protocole de [AWS signature Signature Version 4](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html). Pour afficher l'exemple dans son intégralité, faites défiler la souris sur le bouton **Copier**.
------
#### [ curl ]
```
curl --request GET \
'https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/.well-known/smart-configuration \
--aws-sigv4 'aws:amz:region:healthlake' \
--user "$AWS_ACCESS_KEY_ID:$AWS_SECRET_ACCESS_KEY" \
--header "x-amz-security-token:$AWS_SESSION_TOKEN" \
--header 'Accept: application/json'
```
------
Le document de découverte du magasin de HealthLake données est renvoyé sous la forme d'un blob JSON, dans lequel vous pouvez trouver le `authorization_endpoint` et le`token_endpoint`, ainsi que les spécifications et les fonctionnalités définies pour le magasin de données.
```
{
"authorization_endpoint": "https://oidc.example.com/authorize",
"token_endpoint": "https://oidc.example.com/oauth/token",
"capabilities": [
"launch-ehr",
"client-public"
]
}
```
Le `authorization_endpoint` et le `token_endpoint` sont tous deux nécessaires pour lancer une application client.
+ Point de **terminaison d'autorisation** : URL nécessaire pour autoriser une application cliente ou un utilisateur.
+ Point de **terminaison du jeton** : point de terminaison du serveur d'autorisation avec lequel l'application cliente communique.
# Effectuer une demande d'API REST FHIR sur un magasin de données compatible SMART HealthLake
Vous pouvez effectuer des demandes d'API REST FHIR sur un magasin de données compatible SMART sur FHIR. HealthLake L'exemple suivant montre une demande d'une application cliente contenant un JWT dans l'en-tête d'autorisation et montre comment Lambda doit décoder la réponse. Une fois que la demande d'application cliente est autorisée et authentifiée, elle doit recevoir un jeton porteur du serveur d'autorisation. Utilisez le jeton porteur dans l'en-tête d'autorisation lorsque vous envoyez une demande d'API REST FHIR sur un magasin de données compatible SMART on HealthLake FHIR.
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient/[ID]
Authorization: Bearer auth-server-provided-bearer-token
```
Comme un jeton porteur a été trouvé dans l'en-tête d'autorisation et qu'aucune identité AWS IAM n'a été détectée, la fonction Lambda spécifiée lors de HealthLake la création du magasin de données compatible SMART on FHIR a été créé. HealthLake Lorsque le jeton est correctement décodé par votre fonction Lambda, l'exemple de réponse suivant est envoyé à. HealthLake
```
{
"authPayload": {
"iss": "https://authorization-server-endpoint/oauth2/token", # The issuer identifier of the authorization server
"aud": "https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/", # Required, data store endpoint
"iat": 1677115637, # Identifies the time at which the token was issued
"nbf": 1677115637, # Required, the earliest time the JWT would be valid
"exp": 1997877061, # Required, the time at which the JWT is no longer valid
"isAuthorized": "true", # Required, boolean indicating the request has been authorized
"uid": "100101", # Unique identifier returned by the auth server
"scope": "system/*.*" # Required, the scope of the request
},
"iamRoleARN": "iam-role-arn" #Required, IAM role to complete the request
}
```
# Support FHIR R4 pour AWS HealthLake
AWS HealthLake prend en charge la spécification FHIR R4 pour l'échange de données de santé. Les sections suivantes fournissent des informations complémentaires sur la façon dont la spécification FHIR R4 est HealthLake utilisée pour vous aider à [gérer](managing-fhir-resources.md) et à [rechercher](searching-fhir-resources.md) des ressources FHIR dans votre banque de HealthLake données à l'aide de FHIR R4. RESTful APIs
**Topics**
+ [Déclaration de capacité](reference-fhir-capability-statement.md)
+ [Validations de profils](reference-fhir-profile-validations.md)
+ [Types de ressources](reference-fhir-resource-types.md)
+ [Paramètres de recherche](reference-fhir-search-parameters.md)
+ [\$1 Opérations](reference-fhir-operations.md)
# Déclaration de capacité du FHIR R4 pour AWS HealthLake
Pour connaître les fonctionnalités (comportements) liées au FHIR d'un magasin de HealthLake données actif, vous devez récupérer sa déclaration de capacité. La déclaration de capacité est utilisée comme déclaration de fonctionnalité réelle du serveur ou comme déclaration de mise en œuvre requise ou souhaitée du serveur. L'[https://hl7.org/fhir/R4/http.html#capabilities](https://hl7.org/fhir/R4/http.html#capabilities)interaction FHIR récupère des informations sur les capacités du magasin de HealthLake données et les parties de la spécification FHIR prises en charge. HealthLake valide les types de ressources FHIR en fonction de la ressource FHIR R4. [https://hl7.org/fhir/R4/structuredefinition.html](https://hl7.org/fhir/R4/structuredefinition.html)
**Pour obtenir la déclaration de capacité d'un magasin HealthLake de données**
1. Collectez HealthLake `region` et `datastoreId` valorisez. Pour de plus amples informations, veuillez consulter [Obtenir les propriétés du magasin de données](managing-data-stores-describe.md).
1. Construisez une URL pour la demande en utilisant les valeurs collectées pour HealthLake `region` et`datastoreId`. Incluez également l'`metadata`élément FHIR dans l'URL. Pour afficher le chemin complet de l'URL dans l'exemple suivant, faites défiler le curseur sur le bouton **Copier**.
```
https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/metadata
```
1. Envoyez la demande . L'`capabilities`interaction FHIR utilise une `GET` demande avec le protocole de [AWS signature Signature Version 4](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html). L'`curl`exemple suivant obtient la déclaration de capacité pour le magasin de HealthLake données spécifié par le`datastoreId`. Pour afficher l'exemple dans son intégralité, faites défiler la souris sur le bouton **Copier**.
------
#### [ curl ]
```
curl --request GET \
'https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/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'
```
------
Vous recevrez un code de réponse `200` HTTP et la déclaration de capacité pour votre magasin de HealthLake données. Pour plus d'informations, consultez la [https://hl7.org/fhir/R4/capabilitystatement.html](https://hl7.org/fhir/R4/capabilitystatement.html)documentation du **FHIR R4**.
# Validations du profil FHIR pour HealthLake
AWS HealthLake prend en charge la spécification [FHIR R4 de](https://hl7.org/fhir/R4) base. Les profils FHIR sont inclus dans la spécification FHIR R4 de base. Les profils sont utilisés sur un type de ressource FHIR pour définir une définition de type de ressource plus spécifique à l'aide d' and/or extensions de contraintes sur le type de ressource de base. Par exemple, un profil FHIR peut identifier les champs obligatoires tels que les extensions et les ensembles de valeurs. Une ressource peut prendre en charge plusieurs profils. Tous les magasins HealthLake de données prennent en charge l'utilisation des profils FHIR.
**Note**
L'ajout d'un profil FHIR *n'est pas* obligatoire lors de l'ajout de données dans un magasin de HealthLake données. Si aucun profil FHIR n'est spécifié lors de l'ajout ou de la mise à jour d'une ressource, la ressource est validée uniquement par rapport au schéma FHIR R4 de base.
Les profils FHIR, auxquels les ressources FHIR sont conformes, sont inclus dans les ressources avant leur importation. HealthLake Par conséquent, les profils FHIR sont validés HealthLake lors de l'importation.
Les profils FHIR sont spécifiés dans un guide de mise en œuvre. Un guide de mise en œuvre FHIR (IG) est un ensemble d'instructions qui décrivent comment utiliser la norme FHIR dans un but spécifique. HealthLake valide les profils FHIR définis dans les guides de mise en œuvre suivants.
**Profils FHIR pris en charge par AWS HealthLake**
| Nom | Version | Guide d'implémentation | Capacité | USA Est (Ohio) | USA Est (Virginie du Nord) | USA Ouest (Oregon) | Asie-Pacifique (Mumbai) | Asie-Pacifique (Sydney) | Canada (Central) | Europe (Irlande) | Europe (Londres) |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Noyau américain | 3.1.1 | [http://hl7.org/fhir/us/core/STU3.1.1/](http://hl7.org/fhir/us/core/STU3.1.1/) | Par défaut | X | X | X | X | X | X | X | X |
| Noyau américain | 4.0.0 | [https://hl7.org/fhir/us/core/STU4/index.html](https://hl7.org/fhir/us/core/STU4/index.html) | Pris en charge | X | X | X | X | X | X | X | X |
| Noyau américain | 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) | Pris en charge | X | X | X | X | X | X | X | X |
| Noyau américain | 6.1.0 | [https://hl7.org/fhir/us/core/STU6.1/index.html](https://hl7.org/fhir/us/core/STU6.1/index.html) | Pris en charge | X | X | X | X | X | X | X | X |
| Noyau américain | 7.0.0 | [https://hl7.org/fhir/us/core/STU7/](https://hl7.org/fhir/us/core/STU7/) | Pris en charge | X | X | X | X | X | X | X | X |
| Noyau britannique | 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) | Pris en charge | X | X | X | X | | | X | X |
| Bouton bleu CARIN | 1.1.0 | [http://hl7.org/fhir/us/carin-bb/STU1.1/](http://hl7.org/fhir/us/carin-bb/STU1.1/) | Par défaut | X | X | X | X | X | X | X | X |
| Bouton bleu 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) | Pris en charge | 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/) | Par défaut | 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) | Pris en charge | X | X | X | X | X | X | X | X |
| Échange de dossiers médicaux Da Vinci (HRex) | 0.2.0 | [https://hl7.org/fhir/us/davinci-hrex/2020Sep/](https://hl7.org/fhir/us/davinci-hrex/2020Sep/) | Par défaut | X | X | X | X | X | X | X | X |
| DaVinci PDEX Plan 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/) | Par défaut | X | X | X | X | X | X | X | X |
| DaVinci PDEX Plan Net | 1.0.0 | [https://hl7.org/fhir/us/davinci-pdex-plan-net/STU1/](https://hl7.org/fhir/us/davinci-pdex-plan-net/STU1/) | Pris en charge | X | X | X | X | X | X | X | X |
| DaVinci Payer Data Exchange (PDex) Formulaire de médicaments américain | 1.1.0 | [https://hl7.org/fhir/us/davinci-drug-formulary/STU1.1/](https://hl7.org/fhir/us/davinci-drug-formulary/STU1.1/) | Par défaut | X | X | X | X | X | X | X | X |
| DaVinci Payer Data Exchange (PDex) Formulaire de médicaments américain | 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) | Pris en charge | 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) | Par défaut | X | X | X | X | X | X | X | X |
| Support d'autorisation préalable (PAS) Da Vinci FHIR IG | 2.1.0 | [https://hl7.org/fhir/us/davinci-pas/](https://hl7.org/fhir/us/davinci-pas/) | Par défaut | X | X | X | X | X | X | X | X |
| Guide de mise en œuvre du NCQA HEDIS® | 0,3.1 | [https://www.ncqa.org/resources/hedis-ig-resource-page/](https://www.ncqa.org/resources/hedis-ig-resource-page/) | Par défaut | X | X | X | X | | | X | X |
| Résumé international des patients (IPS) | bulletin de vote 2.0.0 | [https://hl7.org/fhir/uv/ips/2024Sep/](https://hl7.org/fhir/uv/ips/2024Sep/) | Par défaut | X | X | X | X | X | X | X | X |
| Mesure de 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) | Par défaut | X | X | X | X | | | X | X |
| Rapports sur la génomique | 3.0.0 | [https://build.fhir.org/ig/HL7/genomics-reporting/index.html](https://build.fhir.org/ig/HL7/genomics-reporting/index.html) | Par défaut | X | X | X | X | | | X | X |
| Mission numérique Ayushman Bharat (ABDM) de la National Health Authority | 2.0 | [https://www.nrces.in/ndhm/fhir/r4/index.html](https://www.nrces.in/ndhm/fhir/r4/index.html) | Par défaut | X | X | X | X | | | X | X |
| CA Core\$1 | 1.1.0 | [https://simplifier.net/ca-core](https://simplifier.net/ca-core) | Pris en charge | | | | | | X | | |
| CA : eReferal-eConsult pancanadien | 1.1.0 | [https://simplifier.net/CA-eReC/~introduction](https://simplifier.net/CA-eReC/~introduction) | Pris en charge | | | | | | X | | |
| Résumé destiné aux patients, édition canadienne - (PS-CA) | 2.11 | [https://simplifier.net/PS-CA-R1/~introduction](https://simplifier.net/PS-CA-R1/~introduction) | Pris en charge | | | | | | X | | |
| Répertoire des médicaments de santé numériques de l'Ontario | 4.0.3 | [https://simplifier.net/ca-on-dhdr-r4/~introduction](https://simplifier.net/ca-on-dhdr-r4/~introduction) | Pris en charge | | | | | | X | | |
| Noyau UA | 1.0.0 | [https://hl7.org.au/fhir/core/](https://hl7.org.au/fhir/core/) | Pris en charge | | | | | X | | | |
| Gestion du cabinet 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) | Pris en charge | | | | | X | | | |
## Validation des profils FHIR spécifiés dans une ressource
Pour qu'un profil FHIR soit validé, ajoutez-le à l'`profile`élément des ressources individuelles en utilisant l'URL du profil indiquée dans le guide de mise en œuvre.
Les profils FHIR sont validés lorsque vous ajoutez une nouvelle ressource à votre banque de données. Pour ajouter une nouvelle ressource, vous pouvez utiliser l'opération `StartFHIRImportJob` API, faire une `POST` demande pour ajouter une nouvelle ressource ou faire ` PUT ` pour mettre à jour une ressource existante.
**Example — Pour voir quel profil FHIR est référencé dans une ressource**
L'URL du profil est ajoutée à l'`profile`élément de la paire `"meta" : "profile"` clé-valeur. Cette ressource a été tronquée pour des raisons de clarté.
```
{
"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 — Comment référencer un profil FHIR non pris en charge par défaut**
Pour valider par rapport à un profil autre que celui par défaut pris en charge (par exemple CarinBB 1.0.0), ajoutez l'URL du profil avec la version (séparée par « \$1 ») et l'URL du profil de base dans l'élément. `meta.profile` Cet exemple de ressource a été tronqué pour des raisons de clarté.
```
{
"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“
]
}
}
```
# Types de ressources pris en charge par FHIR R4 pour HealthLake
Le tableau suivant répertorie les types de ressources FHIR R4 pris en charge par. AWS HealthLake Pour plus d'informations, consultez l'[index des ressources](https://hl7.org/fhir/R4/resourcelist.html) dans la documentation du **FHIR R4**.
**Types de ressources FHIR R4 pris en charge par HealthLake**
| | | | |
| --- |--- |--- |--- |
| Compte | DetectedIssue | Invoice | Praticien |
| ActivityDefinition | Appareil | Bibliothèque | PractitionerRole |
| AdverseEvent | DeviceDefinition | Liaison | Procédure |
| AllergyIntolerance | DeviceMetric | List | Provenance |
| Rendez-vous | DeviceUseStatement | Location | Questionnaire |
| AppointmentResponse | DeviceRequest | Mesure | QuestionnaireResponse |
| AuditEvent - Voir la note | DiagnosticReport | MeasureReport | RelatedPerson |
| Binaire | DocumentManifest | Multimédia | RequestGroup |
| BodyStructure | DocumentReference | Médicaments | ResearchStudy |
| Bundle - Voir note | EffectEvidenceSynthesis | MedicationAdministration | ResearchSubject |
| CapabilityStatement | Rencontre | MedicationDispense | RiskAssessment |
| CarePlan | Endpoint | MedicationKnowledge | RiskEvidenceSynthesis |
| CareTeam | EpisodeOfCare | MedicationRequest | Planning |
| ChargeItem | EnrollmentRequest | MedicationStatement | ServiceRequest |
| ChargeItemDefinition | EnrollmentResponse | MessageHeader | Slot |
| Demander | ExplanationOfBenefit | MolecularSequence | Spécimen |
| ClaimResponse | FamilyMemberHistory | NutritionOrder | StructureDefinition |
| Communication | Indicateur | Observation | StructureMap |
| CommunicationRequest | Objectif | OperationOutcome - Voir la note | Substance |
| Montage | Groupe | Organisation | SupplyDelivery |
| ConceptMap | GuidanceResponse | OrganizationAffiliation | SupplyRequest |
| Condition | HealthcareService | Paramètres - Voir note | Sous-tâche |
| Consentement | ImagingStudy | Patient | ValueSet |
| Contrat | Immunisation | PaymentNotice | VisionPrescription |
| Couverture | ImmunizationEvaluation | PaymentReconciliation | VerificationResult - Voir la note |
| CoverageEligibilityRequest | ImmunizationRecommendation | Personne | |
| CoverageEligibilityResponse | InsurancePlan | PlanDefinition | |
**spécifications FHIR et HealthLake**
Vous ne pouvez pas faire `GET` de `POST` demandes avec le FHIR `OperationOutcome` et les types de `Parameters` ressources.
**AuditEvent**— Une AuditEvent ressource peut être créée ou lue, mais elle ne peut pas être mise à jour ou supprimée.
**Bundle** — Il existe plusieurs façons de HealthLake gérer les demandes de bundle. Pour en savoir plus, consultez [Regroupement des ressources FHIR](managing-fhir-resources-bundle.md).
**VerificationResult**— Ce type de ressource n'est pris en charge que pour les magasins de données créés après le 9 décembre 2023.
# Paramètres de recherche FHIR R4 pour HealthLake
Utilisez l'[https://hl7.org/fhir/R4/http.html#search](https://hl7.org/fhir/R4/http.html#search)interaction FHIR pour rechercher un ensemble de ressources FHIR dans un magasin de HealthLake données en fonction de certains critères de filtrage. L'`search`interaction peut être effectuée à l'aide d'une `POST` demande `GET` ou. Pour les recherches impliquant des informations personnelles identifiables (PII) ou des informations de santé protégées (PHI), il est recommandé d'utiliser des `POST` demandes, car les informations personnelles et les PHI sont ajoutées dans le corps de la demande et sont cryptées pendant le transfert.
**Note**
L'`search`interaction FHIR décrite dans ce chapitre est construite conformément à la norme HL7 FHIR R4 pour l'échange de données sur les soins de santé. Comme il s'agit d'une représentation d'un service HL7 FHIR, il n'est pas proposé par le biais de AWS CLI et AWS SDKs. Pour plus d'informations, consultez la [https://hl7.org/fhir/R4/http.html#search](https://hl7.org/fhir/R4/http.html#search)documentation de l'** RESTful API FHIR R4**.
Vous pouvez également interroger les banques de HealthLake données avec SQL à l'aide d'Amazon Athena. Pour plus d'informations, consultez la section Intégration.
HealthLake prend en charge le sous-ensemble suivant de paramètres de recherche FHIR R4. Pour de plus amples informations, veuillez consulter [Paramètres de recherche FHIR R4 pour HealthLake](#reference-fhir-search-parameters).
## Types de paramètres de recherche pris en charge
Le tableau suivant indique les types de paramètres de recherche pris en charge dans HealthLake.
**Types de paramètres de recherche pris en charge**
| Paramètre de recherche | Description |
| --- | --- |
| \$1identifiant | ID de ressource (il ne s'agit pas d'une URL complète) |
| \$1Dernière mise à jour | Date de dernière mise à jour. Le serveur a le pouvoir discrétionnaire de définir la précision des limites. |
| \$1tag | Effectuez une recherche à l'aide d'une balise de ressource. |
| \$1profil | Recherchez toutes les ressources associées à un profil. |
| \$1sécurité | Effectuez une recherche sur les étiquettes de sécurité appliquées à cette ressource. |
| \$1source | Recherchez d'où vient la ressource. |
| \$1texte | Effectuez une recherche sur le récit de la ressource. |
| createdAt | Recherchez sur l'extension personnalisée CreatedAt. |
**Note**
Les paramètres de recherche suivants ne sont pris en charge que pour les banques de données créées après le 9 décembre 2023 : \$1security, \$1source, \$1text, CreateDat.
Le tableau suivant présente des exemples de modification des chaînes de requête en fonction des types de données spécifiés pour un type de ressource donné. Pour des raisons de clarté, les caractères spéciaux de la colonne des exemples n'ont pas été codés. Pour que la requête soit réussie, assurez-vous que la chaîne de requête a été correctement codée.
**Exemples de paramètres de recherche**
| Types de paramètres de recherche | Détails | Exemples |
| --- | --- | --- |
| Number | Recherche une valeur numérique dans une ressource spécifiée. Des chiffres significatifs sont observés. Le nombre de chiffres significatifs est défini par la valeur du paramètre de recherche, à l'exception des zéros en tête. Les préfixes de comparaison sont autorisés. | `[parameter]=100` `[parameter]=1e2` `[parameter]=lt100` |
| Date/ DateTime | Recherche une date ou une heure spécifique. Le format attendu est `yyyy-mm-ddThh:mm:ss[Z\|(+\|-)hh:mm]` mais peut varier. Accepte les types de données suivants : `date``dateTime`,`instant`,`Period`, et`Timing`. Pour plus de détails sur l'utilisation de ces types de données dans les recherches, consultez la [date](https://www.hl7.org/fhir/search.html#date) dans la documentation de l'** RESTful API FHIR R4**. Les préfixes de comparaison sont autorisés. | `[parameter]=eq2013-01-14` `[parameter]=gt2013-01-14T10:00` `[parameter]=ne2013-01-14` |
| String | Recherche une séquence de caractères en distinguant majuscules et minuscules. Supporte `HumanName` les deux `Address` types. Pour plus de détails, consultez la saisie du [type de HumanName données](https://www.hl7.org/fhir/datatypes.html#HumanName) et les entrées du [type de `Address` données](https://www.hl7.org/fhir/datatypes.html#Address) dans la documentation **FHIR R4**. La recherche avancée est prise en charge à l'aide de `:text` modificateurs. | `[base]/Patient?given=eve` `[base]/Patient?given:contains=eve` |
| Jeton | Recherche une close-to-exact correspondance par rapport à une chaîne de caractères, souvent comparée à une paire de valeurs de code médical. La distinction majuscules/minuscules est liée au système de code utilisé lors de la création d'une requête. Les requêtes basées sur les subsumptions peuvent aider à réduire les problèmes liés à la distinction majuscules/minuscules. Pour plus de clarté, `\|` il n'a pas été encodé. | `[parameter]=[system]\|[code]`: Ici, il `[system]` fait référence à un système de codage et `[code]` à une valeur de code trouvée dans ce système spécifique. `[parameter]=[code]`: Ici, votre saisie correspondra soit à un code, soit à un système. `[parameter]=\|[code]`: Ici, votre entrée correspondra à un code, et la propriété du système n'a aucun identifiant. |
| Composite | Recherche plusieurs paramètres au sein d'un même type de ressource à l'aide des modificateurs `$` et de l'`,`opération. Les préfixes de comparaison sont autorisés. | `/Patient?language=FR,NL&language=EN` `Observation?component-code-value-quantity=http://loinc.org\|8480-6$lt60` `[base]/Group?characteristic-value=gender$mixed` |
| Quantity | Recherche un nombre, un système et un code sous forme de valeurs. Un numéro est requis, mais le système et le code sont facultatifs. Basé sur le type de données de quantité. Pour plus de détails, consultez [la section Quantité](https://www.hl7.org/fhir/datatypes.html#Quantity) dans la documentation du **FHIR R4**. Utilise la syntaxe supposée suivante `[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` |
| Référence | Recherche des références à d'autres ressources. | `[base]/Observation?subject=Patient/23` `test` |
| URI | Recherche une chaîne de caractères identifiant sans ambiguïté une ressource particulière. | `[base]/ValueSet?url=http://acme.org/fhir/ValueSet/123` |
| Spécial | Recherches basées sur des extensions de PNL médicale intégrées. |
## Paramètres de recherche avancés pris en charge par HealthLake
HealthLake prend en charge les paramètres de recherche avancée suivants.
| Nom | Description | Exemple | Capacité |
| --- | --- | --- | --- |
| \$1include | Utilisé pour demander que des ressources supplémentaires soient renvoyées dans une demande de recherche. Elle renvoie les ressources référencées par l'instance de ressource cible. | Encounter?\$1include=Encounter:subject | |
| \$1revinclude | Utilisé pour demander que des ressources supplémentaires soient renvoyées dans une demande de recherche. Elle renvoie des ressources qui font référence à l'instance de ressource principale. | Patient?\$1id=patient-identifier&\$1revinclude=Encounter:patient | |
| \$1summary | Le résumé peut être utilisé pour demander un sous-ensemble de la ressource. | Patient?\$1summary=text | Les paramètres récapitulatifs suivants sont pris en charge : \$1summary=true\$1summary=false,,\$1summary=text,\$1summary=data. |
| \$1elements | Demandez qu'un ensemble spécifique d'éléments soit renvoyé dans le cadre d'une ressource dans les résultats de recherche. | Patient?\$1elements=identifier,active,link | |
| \$1total | Renvoie le nombre de ressources correspondant aux paramètres de recherche. | Patient?\$1total=accurate | Support\$1total=accurate,\$1total=none. |
| \$1sort | Indiquez l'ordre de tri des résultats de recherche renvoyés à l'aide d'une liste séparée par des virgules. Le - préfixe peut être utilisé pour n'importe quelle règle de tri de la liste séparée par des virgules afin d'indiquer l'ordre décroissant. | Observation?\$1sort=status,-date | Support : tri par champs avec typesNumber, String, Quantity, Token, URI, Reference. Le tri par n'Dateest pris en charge que pour les magasins de données créés après le 9 décembre 2023. Support jusqu'à 5 règles de tri. |
| \$1count | Contrôlez le nombre de ressources renvoyées par page du bundle de recherche. | Patient?\$1count=100 | La taille de page maximale est de 100. |
| chaining | Éléments de recherche des ressources référencées. .Dirige la recherche en chaîne vers l'élément de la ressource référencée. | DiagnosticReport?subject:Patient.name=peter | |
| reverse chaining (\$1has) | Recherchez une ressource en fonction des éléments des ressources qui y font référence. | Patient?\$1has:Observation:patient:code=1234-5 | |
`_include`
L'utilisation `_include` dans une requête de recherche permet de renvoyer également des ressources FHIR spécifiées supplémentaires. `_include`À utiliser pour inclure des ressources liées vers le bas.
**Example — À utiliser `_include` pour retrouver les patients ou le groupe de patients chez lesquels une toux a été diagnostiquée**
Vous devez effectuer une recherche sur le type de `Condition` ressource en spécifiant le code de diagnostic de la toux, puis en utilisant « `_include` Spécifier que vous souhaitez que le `subject` diagnostic soit également renvoyé ». Dans le type de `Condition` ressource, on `subject` entend soit le type de ressource du patient, soit le type de ressource du groupe.
Pour des raisons de clarté, les caractères spéciaux de l'exemple n'ont pas été codés. Pour réussir une requête, assurez-vous que la chaîne de requête a été correctement encodée.
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/
Condition?code=49727002&_include=Condition:subject
```
`_include:iterate`Modificateur
Le `_include:iterate` modificateur permet l'inclusion récursive de ressources référencées sur deux niveaux. Par exemple,
```
GET /ServiceRequest?identifier=025C0931195&_include=ServiceRequest:requester&_include:iterate=PractitionerRole:practitioner
```
renverra le ServiceRequest, son associé PractitionerRole (via la référence du demandeur), puis inclura de manière récursive le praticien référencé par celui-ci. PractitionerRole Ce modificateur est disponible pour tous les types de ressources dans HealthLake.
`_include=*`Modificateur
Le `_include=*` modificateur est un caractère générique qui inclut automatiquement toutes les ressources directement référencées par les résultats de recherche. Par exemple,
```
GET /ServiceRequest?specimen.accession=12345&_include=*
```
renverra la correspondance ServiceRequest ainsi que toutes les ressources auxquelles elle fait référence (telles que le patient, le praticien, le spécimen, etc.) sans qu'il soit nécessaire de spécifier chaque chemin de référence individuellement. Ce modificateur est disponible pour tous les types de ressources dans HealthLake.
`_revinclude`
L'utilisation `_revinclude` dans une requête de recherche permet de renvoyer également des ressources FHIR spécifiées supplémentaires. `_revinclude`À utiliser pour inclure des ressources liées à l'envers.
**Example — À utiliser `_revinclude` pour inclure des types de ressources de rencontre et d'observation connexes liés à un patient spécifique**
Pour effectuer cette recherche, vous devez d'abord définir l'individu `Patient` en spécifiant son identifiant dans le paramètre `_id` de recherche. Ensuite, vous devez spécifier des ressources FHIR supplémentaires à l'aide de la structure `Encounter:patient` et`Observation:patient`.
Pour des raisons de clarté, les caractères spéciaux de l'exemple n'ont pas été codés. Pour réussir une requête, assurez-vous que la chaîne de requête a été correctement encodée.
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/
Patient?_id=patient-identifier&_revinclude=Encounter:patient&_revinclude=Observation:patient
```
`_summary`
L'utilisation `_summary` dans une requête de recherche permet à l'utilisateur de demander un sous-ensemble de la ressource FHIR. Il peut contenir l'une des valeurs suivantes : `true, text, data, false` Toutes les autres valeurs seront considérées comme non valides. Les ressources renvoyées seront marquées `'SUBSETTED'` dans le méta.tag, pour indiquer que les ressources sont incomplètes.
+ `true`: renvoie tous les éléments pris en charge marqués comme « résumé » dans la définition de base de la ou des ressources.
+ `text`: Renvoie uniquement les éléments « text », « id », « méta » et uniquement les éléments obligatoires de haut niveau.
+ `data`: Renvoie toutes les parties sauf l'élément « texte ».
+ `false`: renvoie toutes les parties de la ou des ressources
Dans une seule demande de recherche, il `_summary=text` ne peut pas être combiné avec `_include` des paramètres `_revinclude` de recherche.
**Example — Récupère l'élément « texte » des ressources destinées aux patients dans un magasin de données.**
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient?_summary=text
```
`_elements`
L'utilisation `_elements` dans une requête de recherche permet de demander des éléments de ressources FHIR spécifiques. Les ressources renvoyées seront marquées `'SUBSETTED'` dans le méta.tag, pour indiquer que les ressources sont incomplètes.
Le `_elements` paramètre consiste en une liste de noms d'éléments de base séparés par des virgules, tels que les éléments définis au niveau racine de la ressource. Seuls les éléments listés doivent être renvoyés. Si les valeurs des `_elements` paramètres contiennent des éléments non valides, le serveur les ignorera et renverra des éléments obligatoires et des éléments valides.
`_elements`ne sera pas applicable aux ressources incluses (ressources renvoyées dont le mode de recherche est`include`).
Dans une seule demande de recherche, il `_elements` ne peut pas être combiné avec les paramètres `_summary` de recherche.
**Example — Obtenez les éléments « identifiant », « actif », « lien » des ressources destinées aux patients dans votre banque de HealthLake données.**
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient?_elements=identifier,active,link
```
`_total`
L'utilisation `_total` dans une requête de recherche renverra le nombre de ressources correspondant aux paramètres de recherche demandés. HealthLake renverra le nombre total de ressources correspondantes (ressources renvoyées dont le mode de recherche est`match`) dans la réponse `Bundle.total` de recherche.
`_total`prend en charge `accurate` les valeurs des `none` paramètres. `_total=estimate`n'est pas pris en charge. Toutes les autres valeurs seront considérées comme non valides. `_total`n'est pas applicable aux ressources incluses (ressources renvoyées dont le mode de recherche est`include`).
**Example — Obtenez le nombre total de ressources pour les patients dans un magasin de données :**
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient?_total=accurate
```
`_sort`
L'utilisation `_sort` dans la requête de recherche organise les résultats dans un ordre spécifique. Les résultats sont classés par ordre de priorité en fonction de la liste des règles de tri séparées par des virgules. Les règles de tri doivent être des paramètres de recherche valides. Toutes les autres valeurs seront considérées comme non valides.
Dans une seule demande de recherche, vous pouvez utiliser jusqu'à 5 paramètres de recherche de tri. Vous pouvez éventuellement utiliser un `-` préfixe pour indiquer l'ordre décroissant. Le serveur triera par ordre croissant par défaut.
Les types de paramètres de recherche de tri pris en charge sont les suivants :`Number, String, Date, Quantity, Token, URI, Reference`. Si un paramètre de recherche fait référence à un élément imbriqué, il n'est pas pris en charge pour le tri. Par exemple, une recherche sur le « nom » du type de ressource Patient fait référence à l'élément Patient.Name dont le type de HumanName données est considéré comme imbriqué. Par conséquent, le tri des ressources pour les patients par « nom » n'est pas pris en charge.
**Example — Accédez aux ressources des patients dans un magasin de données et triez-les par date de naissance dans l'ordre croissant :**
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient?_sort=birthdate
```
`_count`
Le paramètre `_count` est défini comme une instruction au serveur concernant le nombre de ressources à renvoyer sur une seule page.
La taille de page maximale est de 100. Toute valeur supérieure à 100 n'est pas valide. `_count=0`n'est pas pris en charge.
**Example — Recherchez la ressource Patient et définissez la taille de la page de recherche sur 25 :**
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient?_count=25
```
`Chaining and Reverse Chaining(_has)`
Le chaînage et le chaînage inversé dans FHIR constituent un moyen plus efficace et plus compact d'obtenir des données interconnectées, réduisant ainsi le besoin de plusieurs requêtes distinctes et rendant la récupération de données plus pratique pour les développeurs et les utilisateurs.
Si un niveau de récursivité renvoie plus de 100 résultats, il HealthLake renverra 4xx pour éviter que le magasin de données ne soit surchargé et ne provoque des paginations multiples.
**Example — Chainage - Obtient tout DiagnosticReport ce qui fait référence à un patient dont le nom est Peter.**
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/DiagnosticReport?subject:Patient.name=peter
```
**Example — Chainage inversé - Accédez aux ressources du patient, où la ressource du patient est référencée par au moins une observation dont le code de l'observation est 1234, et où l'observation fait référence à la ressource du patient dans le paramètre de recherche du patient.**
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient?_has:Observation:patient:code=1234
```
## Modificateurs de recherche pris en charge
Les modificateurs de recherche sont utilisés avec les champs basés sur des chaînes. Tous les modificateurs de recherche HealthLake utilisés utilisent une logique booléenne. Par exemple, vous pouvez `:contains` spécifier qu'un champ de chaîne plus grand doit inclure une petite chaîne pour qu'il soit inclus dans les résultats de recherche.
**Modificateurs de recherche pris en charge**
| Modificateur de recherche | Type |
| --- | --- |
| :manquant | Tous les paramètres sauf Composite |
| :exact | String |
| :contient | String |
| :non | Jeton |
| :texte | Jeton |
| :identifiant | Référence |
| :ci-dessous | URI |
## Comparateurs de recherche pris en charge
Vous pouvez utiliser des comparateurs de recherche pour contrôler la nature de la correspondance lors d'une recherche. Vous pouvez utiliser des comparateurs lorsque vous effectuez une recherche dans les champs de numéro, de date et de quantité. Le tableau suivant répertorie les comparateurs de recherche et leurs définitions pris en charge par HealthLake.
**Comparateurs de recherche pris en charge**
| Comparateur de recherche | Description |
| --- | --- |
| eq | La valeur du paramètre dans la ressource est égale à la valeur fournie. |
| ne | La valeur du paramètre dans la ressource n'est pas égale à la valeur fournie. |
| gt | La valeur du paramètre dans la ressource est supérieure à la valeur fournie. |
| lt | La valeur du paramètre dans la ressource est inférieure à la valeur fournie. |
| gm | La valeur du paramètre dans la ressource est supérieure ou égale à la valeur fournie. |
| le | La valeur du paramètre dans la ressource est inférieure ou égale à la valeur fournie. |
| sa | La valeur du paramètre dans la ressource commence après la valeur fournie. |
| eb | La valeur du paramètre dans la ressource se termine avant la valeur fournie. |
## Les paramètres de recherche FHIR ne sont pas pris en charge par HealthLake
HealthLake prend en charge tous les paramètres de recherche FHIR à l'exception de ceux répertoriés dans le tableau suivant. Pour une liste complète des paramètres de recherche FHIR, consultez le registre des paramètres de [recherche FHIR](https://hl7.org/fhir/R4/searchparameter-registry.html).
**Paramètres de recherche non pris en charge**
| | |
| --- |--- |
| Composition du bundle | Lieu : à proximité |
| Identifiant du bundle | C onsent-source-reference |
| Message groupé | Patient sous contrat |
| Type d'offre groupée | Contenu des ressources |
| Horodatage du bundle | Requête de ressources |
# FHIR R4 pour `$operations` HealthLake
Les opérations FHIR \$1 (également appelées « opérations dollar ») sont des fonctions spéciales côté serveur qui vont au-delà des opérations CRUD (`Create`,, `Read``Update`,`Delete`) standard de la spécification FHIR. Ces opérations sont identifiées par le préfixe « \$1 » et permettent un traitement complexe, une transformation de données et des opérations en masse qui seraient difficiles ou inefficaces à effectuer à l'aide d'appels d'API REST standard. Les opérations \$1 peuvent être invoquées au niveau du système, au niveau du type de ressource ou sur des instances de ressources spécifiques, offrant ainsi des moyens flexibles d'interagir avec les données FHIR. AWS HealthLake prend en charge plusieurs FHIR`$operations`. Veuillez vous référer à chacune des pages ci-dessous pour plus de détails.
**Topics**
+ [Fonctionnement du FHIR R4 `$attribution-status` pour HealthLake](reference-fhir-operations-attribution-status.md)
+ [Supprimer des types de ressources avec `$bulk-delete`](reference-fhir-operations-bulk-delete.md)
+ [`$bulk-member-match`opération pour HealthLake](reference-fhir-operations-bulk-member-match.md)
+ [Fonctionnement du FHIR R4 `$confirm-attribution-list` pour HealthLake](reference-fhir-operations-confirm-attribution-list.md)
+ [Fonctionnement du FHIR R4 `$davinci-data-export` pour HealthLake](reference-fhir-operations-davinci-data-export.md)
+ [Génération de documents cliniques avec `$document`](reference-fhir-operations-document.md)
+ [Suppression permanente de ressources avec `$erase`](reference-fhir-operations-erase.md)
+ [Obtenir les données des patients avec `Patient/$everything`](reference-fhir-operations-everything.md)
+ [Récupération de ValueSet codes avec `$expand`](reference-fhir-operations-expand.md)
+ [Exporter HealthLake des données avec FHIR `$export`](reference-fhir-operations-export.md)
+ [`$inquire`Opération FHIR pour HealthLake](reference-fhir-operations-inquire.md)
+ [Récupération des détails du concept avec `$lookup`](reference-fhir-operations-lookup.md)
+ [`$member-add`opération pour HealthLake](reference-fhir-operations-member-add.md)
+ [`$member-match`opération pour HealthLake](reference-fhir-operations-member-match.md)
+ [`$member-remove`opération pour HealthLake](reference-fhir-operations-member-remove.md)
+ [Supprimer les ressources du compartiment réservé aux patients grâce à `$purge`](reference-fhir-operations-purge.md)
+ [`$questionnaire-package`Opération FHIR pour HealthLake](reference-fhir-operations-questionnaire-package.md)
+ [`$submit`Opération FHIR pour HealthLake](reference-fhir-operations-submit.md)
+ [Validation des ressources FHIR avec `$validate`](reference-fhir-operations-validate.md)
# Fonctionnement du FHIR R4 `$attribution-status` pour HealthLake
Récupère le statut d'attribution d'un membre spécifique, renvoyant un bundle contenant toutes les ressources d'attribution liées au patient. Cette opération fait partie de la mise en œuvre de la [version 2.1.0 de la liste d'attribution des membres FHIR (ATR) List IG](https://build.fhir.org/ig/HL7/davinci-atr/spec.html).
## Endpoint
```
POST [base]/Group/[id]/$attribution-status
```
## Paramètres de demande
L'opération accepte les paramètres facultatifs suivants :
| Paramètre | Type | Description |
| --- | --- | --- |
| memberId | Identifiant | Le MemberId membre pour lequel le statut d'attribution est demandé |
| Référence du patient | Référence | Référence à la ressource pour les patients dans le système du producteur |
**Note**
L'un `memberId` ou l'autre `patientReference` peut être fourni, ou les deux à des fins de validation.
## Exemple de demande
```
{
"resourceType": "Parameters",
"parameter": [
{
"name": "memberId",
"valueIdentifier": {
"system": "http://example.org",
"value": "MBR123456789"
}
},
{
"name": "patientReference",
"valueReference": {
"reference": "Patient/patient-123",
"display": "John Doe"
}
}
]
}
```
## Réponse
Renvoie un bundle contenant des ressources d'attribution liées au patient :
| Ressource | Cardinalité | Location |
| --- | --- | --- |
| Patient | 1..1 | Groupe.membre/entité |
| Couverture | 0,1 | Group.Member.Extension : CoverageReference |
| Organization/Practitioner/PractitionerRole | 0,1 | group.member.extension : fournisseur attribué |
| N'importe quelle ressource | 0,1 | group.member.extension : données associées |
### Exemple de réponse
```
{
"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
}
}
]
}
```
## Gestion des erreurs
L'opération gère les conditions d'erreur suivantes :
| Erreur | État du protocole HTTP | Description |
| --- | --- | --- |
| Demande d'opération non valide | 400 | Paramètres ou structure de demande non conformes |
| Ressource de groupe introuvable | 404 | L'ID de groupe spécifié n'existe pas |
| Ressource pour les patients introuvable | 404 | La référence du patient spécifiée n'existe pas |
## Autorisation et sécurité
Exigences relatives à SMART Scope
Les clients doivent disposer des privilèges appropriés pour lire les ressources du groupe et les ressources d'attribution associées
Les mécanismes d'autorisation FHIR standard s'appliquent à toutes les opérations
# Supprimer des types de ressources avec `$bulk-delete`
AWS HealthLake prend en charge l'`$bulk-delete`opération en permettant de supprimer toutes les ressources d'un type spécifique au sein d'une banque de données. Cette opération est particulièrement utile lorsque vous devez :
+ Réaliser un audit saisonnier et un nettoyage
+ Gérez le cycle de vie des données à grande échelle
+ Supprimer des types de ressources spécifiques
+ Respectez les politiques de conservation des données
## Usage
L'`$bulk-delete`opération peut être invoquée à l'aide des méthodes POST :
```
POST [base]/[ResourceType]/$bulk-delete?isHardDelete=false&deleteAuditEvent=true
```
## Parameters
| Paramètre | Type | Obligatoire | Par défaut | Description |
| --- | --- | --- | --- | --- |
| isHardDelete | booléen | Non | false | Lorsque c'est vrai, supprime définitivement les ressources du stockage |
| deleteAuditEvent | boolean | Non | true | Lorsque c'est vrai, supprime les événements d'audit associés |
| \$1since | chaîne | Non | Heure de création de la banque de données | Une fois saisie, sélectionne l'heure limite de début pour rechercher les ressources en fonction de leur heure de dernière modification. Ne peut pas être utilisé avec le début ou la fin |
| start | chaîne | Non | Heure de création de la banque de données | Une fois saisie, sélectionne l'heure limite pour rechercher les ressources en fonction de leur heure de dernière modification. Peut être utilisé avec extrémité |
| end | chaîne | Non | Heure de soumission des offres d'emploi | Une fois saisi, sélectionne l'heure limite de fin pour rechercher les ressources en fonction de leur heure de dernière modification |
## Exemples
**Exemple de requête**
```
POST [base]/Observation/$bulk-delete?isHardDelete=false
```
**Exemple de réponse**
```
{
"jobId": "jobId",
"jobStatus": "SUBMITTED"
}
```
## Statut de la tâche
Pour vérifier le statut d'une tâche de suppression en bloc, procédez comme suit :
```
GET [base]/$bulk-delete/[jobId]
```
L'opération renvoie les informations relatives à l'état de la tâche :
```
{
"datastoreId": "datastoreId",
"jobId": "jobId",
"status": "COMPLETED",
"submittedTime": "2025-10-09T15:09:51.336Z"
}
```
## Comportement
L'`$bulk-delete`opération :
1. Processus asynchrones pour gérer de gros volumes de ressources
1. Maintient les transactions ACID pour garantir l'intégrité des données
1. Fournit un suivi de l'état des tâches avec le nombre de ressources supprimées
1. Supporte les modes de suppression souple et rigide
1. Inclut un enregistrement d'audit complet des activités de suppression
1. Permet la suppression sélective des versions historiques et des événements d'audit
## Journalisation des audits
L'`$bulk-delete`opération est enregistrée sous les noms Start FHIRBulk DeleteJob et Describe FHIRBulk DeleteJob avec des informations détaillées sur l'opération.
## Limitations
+ Lorsque `isHardDelete` ce paramètre est défini sur true, les ressources supprimées définitivement n'apparaissent pas dans les résultats de recherche ni dans les `_history` requêtes.
+ Les ressources supprimées par cette opération peuvent être temporairement inaccessibles pendant le traitement
+ La mesure du stockage est ajustée uniquement sur les versions historiques - deleteVersionHistory =false n'ajustera pas le stockage de la banque de données
# `$bulk-member-match`opération pour HealthLake
AWS HealthLake prend en charge l'`$bulk-member-match`opération de traitement asynchrone des demandes de correspondance de plusieurs membres. Cette opération permet aux établissements de santé de faire correspondre efficacement les identifiants uniques de centaines de membres dans différents systèmes de santé en utilisant des informations démographiques et de couverture dans une seule demande groupée. Cette fonctionnalité est essentielle pour l'échange de payer-to-payer données à grande échelle, les transitions de membres et les exigences de conformité au CMS et est conforme à la [spécification](https://build.fhir.org/ig/HL7/davinci-epdx/OperationDefinition-BulkMemberMatch.html) FHIR.
**Note**
L'`$bulk-member-match`opération est basée sur une spécification FHIR sous-jacente qui est actuellement expérimentale et sujette à modification. Au fur et à mesure de l'évolution des spécifications, le comportement et l'interface de cette API seront mis à jour en conséquence. Il est conseillé aux développeurs de surveiller les notes de HealthLake publication d'AWS et les mises à jour pertinentes des spécifications FHIR afin de rester informés de toute modification susceptible d'avoir un impact sur leurs intégrations.
Cette opération est particulièrement utile lorsque vous devez :
+ Procédez au jumelage des membres à grande échelle pendant les périodes d'inscription ouvertes
+ Faciliter les transitions de membres en masse entre les payeurs
+ Support des exigences d'échange de données de conformité des CMS à grande échelle
+ Associez efficacement les cohortes de membres à travers les réseaux de santé
+ Minimisez les appels d'API et améliorez l'efficacité opérationnelle pour les scénarios de mise en correspondance de volumes élevés
## Usage
L'`$bulk-member-match`opération est une opération asynchrone invoquée sur les ressources du groupe à l'aide de la méthode POST :
```
POST [base]/Group/$bulk-member-match
```
Après avoir soumis une demande de correspondance groupée, vous pouvez consulter le statut du poste en utilisant :
```
GET [base]/$bulk-member-match-status/{jobId}
```
## Paramètres pris en charge
HealthLake prend en charge les `$bulk-member-match` paramètres FHIR suivants :
| Paramètre | Type | Obligatoire | Description |
| --- | --- | --- | --- |
| `MemberPatient` | Patient | Oui | Ressource destinée aux patients contenant des informations démographiques pour le membre à jumeler. |
| `CoverageToMatch` | Couverture | Oui | Ressource de couverture qui sera utilisée pour la comparaison avec les enregistrements existants. |
| `CoverageToLink` | Couverture | Non | Ressource de couverture à associer pendant le processus de mise en correspondance. |
| `Consent` | Consentement | Oui | La ressource de consentement à des fins d'autorisation est également stockée. Cela est différent de l'`$member-match`opération individuelle pour laquelle le consentement *n'est pas* requis. |
## Demande POST pour soumettre en masse un job correspondant à un nombre de membres
L'exemple suivant montre une demande POST visant à soumettre un job de mise en relation groupé de membres. Chaque membre est encapsulé dans un `MemberBundle` paramètre contenant les `Consent` ressources requises `MemberPatient``CoverageToMatch`, ainsi qu'un paramètre facultatif`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"
}
]
}
}
]
}
]
}
```
## Réponse à la tâche terminée avec sortie
Lorsque le travail est terminé, la réponse inclut les métadonnées du travail et une ressource de paramètres FHIR contenant trois ressources de groupe qui catégorisent les résultats du match.
```
{
"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"
}
}
]
}
}
]
}
}
```
## Ressources du groupe de sortie
La tâche terminée renvoie une ressource Parameters contenant trois ressources de groupe :
**MatchedMembers Groupe**
Contient les références des patients pour tous les membres correctement mis en correspondance et n'est pas classé dans la catégorie des contraintes de consentement.
Le `Group.quantity` champ contient le nombre total de membres dans chacun de leurs groupes respectifs.
**NonMatchedMembers Groupe**
Contient des références aux membres pour lesquels aucune correspondance n'a été trouvée ou plusieurs correspondances ont été identifiées.
**ConsentConstrainedMembers Groupe**
Contient des références de patients pour tous les membres mis en correspondance avec succès lorsque les contraintes de consentement empêchent le partage de données. Une ressource de consentement est considérée comme limitée lorsque les deux conditions suivantes sont présentes :
+ **L'URI de la politique se termine par `#sensitive`** — Il s'agit du signal le plus clair et le plus direct. Le payeur soumissionnaire déclare explicitement : « Les données de ce membre sont sensibles, manipulez-les avec soin ».
```
"policy": [{ "uri": "...hrex-consent.html#sensitive" }]
```
+ **Le type de disposition de niveau supérieur est** le `deny` suivant : le membre a largement refusé le partage de données.
```
"provision": { "type": "deny" }
```
## Intégration avec \$1 davinci-data-export
La ressource de MatchedMembers groupe renvoyée par `$bulk-member-match` peut être directement utilisée avec l'`$davinci-data-export`opération de récupération des données des membres en masse :
```
POST [base]/Group/{matched-group-id}/$davinci-data-export
GET [base]/Group/{matched-group-id}
```
Cette intégration permet des flux de travail efficaces dans lesquels vous identifiez d'abord les membres correspondants en masse, puis exportez leurs dossiers médicaux complets à l'aide de la ressource de groupe qui en résulte.
## Caractéristiques de performance
L'`$bulk-member-match`opération est conçue pour le traitement de gros volumes et s'exécute de manière asynchrone :
+ **Simultanéité** : maximum de 5 opérations simultanées par magasin de données.
+ **Évolutivité** : gère jusqu'à 500 membres par demande (limite de charge utile de 5 Mo).
+ **Opérations parallèles** : compatible avec les opérations simultanées d'importation, d'exportation ou de suppression en bloc.
## Autorisation
L'API utilise le protocole d'autorisation SMART on FHIR avec les étendues requises suivantes :
+ `system/Patient.read`— Nécessaire pour rechercher et associer les ressources destinées aux patients.
+ `system/Coverage.read`— Nécessaire pour valider les informations de couverture.
+ `system/Group.write`— Nécessaire pour créer des ressources de groupe de résultats.
+ `system/Organization.read`— Conditionnel, obligatoire si la couverture fait référence à des organisations.
+ `system/Practitioner.read`— Conditionnel, obligatoire si la couverture fait référence à des praticiens.
+ `system/PractitionerRole.read`— Conditionnel, obligatoire si la couverture fait référence aux rôles des praticiens.
+ `system/Consent.write`— Conditionnel, obligatoire si des ressources de consentement sont fournies.
L'opération prend également en charge AWS l'autorisation IAM Signature Version 4 (SigV4) pour l'accès programmatique.
## Gestion des erreurs
L'opération gère les conditions d'erreur suivantes :
+ **400 Mauvaise demande** : format de demande non valide, paramètres requis manquants ou charge utile supérieure aux limites de taille (500 membres ou 5 Mo).
+ **422 Entité intraitable** : erreurs de traitement lors de l'exécution de la tâche.
+ **Erreurs relatives à un membre individuel** : lorsqu'un membre en particulier échoue, l'opération se poursuit avec les membres restants et inclut les détails de l'erreur dans le NonMatchedMembers groupe avec les codes de motif appropriés. Par exemple, un `MemberBundle` Patient dont le `birthDate` paramètre est absent renverra le message d'erreur suivant :
```
"errors": [
{
"memberIndex": 1,
"jsonBlob": {
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "invalid",
"diagnostics": "MemberPatient.birthDate is required"
}
],
"statusCode": 400
}
}
]
```
Les détails de l'erreur sont disponibles via le point de terminaison du sondage d'état et incluent :
+ `numberOfMembersWithCustomerError`: Nombre de membres présentant des erreurs de validation ou de saisie.
+ `numberOfMembersWithServerError`: nombre de membres présentant des erreurs de traitement côté serveur.
## Opérations liées
+ [`$member-match`opération pour HealthLake](reference-fhir-operations-member-match.md)— Opération de mise en correspondance de membres individuels.
+ [Fonctionnement du FHIR R4 `$davinci-data-export` pour HealthLake](reference-fhir-operations-davinci-data-export.md)— Exportation de données en masse à l'aide des ressources du groupe.
+ [FHIR R4 pour `$operations` HealthLake](reference-fhir-operations.md)— Liste complète des opérations prises en charge.
# Fonctionnement du FHIR R4 `$confirm-attribution-list` pour HealthLake
Indique au producteur que le consommateur n'a plus aucune modification à apporter à la liste d'attribution. Cette opération finalise la liste d'attribution en supprimant les membres inactifs de la liste, en modifiant le statut en « final » et en accusant réception de l'opération. Cette opération fait partie de la mise en œuvre de la [version 2.1.0 de la liste d'attribution des membres FHIR (ATR) List IG](https://build.fhir.org/ig/HL7/davinci-atr/spec.html).
## Endpoint
```
POST [base]/Group/[id]/$confirm-attribution-list
```
## Demande
Aucun paramètre n'est requis.
```
POST [base]/Group/[id]/$confirm-attribution-list
```
## Réponse
Renvoie HTTP 201 avec un message de confirmation.
### Exemple de réponse
```
HTTP Status Code: 201
{
"resourceType": "Parameters",
"parameter": [
{
"name": "message",
"valueString": "Accepted."
}
]
}
```
## État du groupe après confirmation
Une fois la confirmation réussie, le statut de la liste d'attribution de la ressource du groupe sera défini sur « final » :
```
{
"resourceType": "Group",
"id": "fullexample",
"extension": [
{
"url": "http://hl7.org/fhir/us/davinci-atr/StructureDefinition/ext-attributionListStatus",
"valueCode": "final"
}
]
// ... other Group properties
}
```
## Gestion des erreurs
L'opération gère les conditions d'erreur suivantes :
| Erreur | État du protocole HTTP | Description |
| --- | --- | --- |
| Demande d'opération non valide | 400 | Paramètres ou structure de demande non conformes |
| Ressource de groupe introuvable | 404 | L'ID de groupe spécifié n'existe pas |
## Autorisation et sécurité
Exigences relatives à SMART Scope
Les clients doivent disposer des privilèges appropriés pour lire les ressources du groupe et les ressources d'attribution associées
En effet`$confirm-attribution-list`, les clients doivent également disposer de privilèges d'écriture pour modifier les ressources du groupe
Les mécanismes d'autorisation FHIR standard s'appliquent à toutes les opérations
# Fonctionnement du FHIR R4 `$davinci-data-export` pour HealthLake
Il s'agit d'une `$davinci-data-export` opération FHIR asynchrone à partir de laquelle vous pouvez exporter des données de santé. AWS HealthLake Cette opération prend en charge plusieurs types d'exportation, notamment l'attribution de membres (ATR) Payer-to-Payer, l'accès au PDex fournisseur et l'accès aux membres APIs. Il s'agit d'une version spécialisée de l'`$export`opération FHIR standard, conçue pour répondre aux exigences des guides de mise DaVinci en œuvre.
## Fonctionnalités principales
+ *Traitement asynchrone* : suit le modèle de demande asynchrone FHIR standard
+ Exportation *au niveau du groupe : exporte* les données pour les membres d'une ressource de groupe spécifique
+ *Plusieurs types d'exportation* : prend en charge l'ATR (attribution de membres) Payer-to-Payer, l'accès aux PDex fournisseurs et l'accès aux membres APIs
+ *Support complet pour les profils* : inclut US Core, CARIN Blue Button et PDex profils
+ *Filtrage flexible* : prend en charge le filtrage par patients, types de ressources et plages de temps
+ *Sortie NDJSON* : fournit des données au format JSON délimité par de nouvelles lignes
## Opération Endpoint
```
GET [base]/Group/[id]/$davinci-data-export
POST [base]/Group/[id]/$davinci-data-export
```
## Paramètres de demande
| Paramètre | Cardinalité | Description |
| --- | --- | --- |
| patient | 0.. \$1 | Membres spécifiques dont les données doivent être exportées. En cas d'omission, tous les membres du groupe sont exportés. |
| \$1type | 0,1 | Liste séparée par des virgules des types de ressources FHIR à exporter. |
| \$1since | 0,1 | N'incluez que les ressources mises à jour après cette date et cette heure. |
| \$1until | 0,1 | N'incluez que les ressources mises à jour avant cette date et cette heure. |
| exportType | 0,1 | Type d'export à effectuer. Valeurs valides: hl7.fhir.us.davinci-atr, hl7.fhir.us.davinci-pdex, hl7.fhir.us.davinci-pdex.p2p, hl7.fhir.us.davinci-pdex.member. Valeur par défaut : hl7.fhir.us.davinci-atr. |
| \$1includeEOB2xWoFinancial | 0,1 | Spécifie s'il faut inclure les ExplanationOfBenefit ressources CARIN BB 2.x avec les données financières supprimées. Valeur par défaut : false. |
### Types de ressource pris en charge
Les types de ressources pris en charge dépendent du type d'exportation que vous spécifiez. Pour les exportations ATR, les types de ressources suivants sont pris en charge :
+ `Group`
+ `Patient`
+ `Coverage`
+ `RelatedPerson`
+ `Practitioner`
+ `PractitionerRole`
+ `Organization`
+ `Location`
Pour les PDex exportations (accès fournisseur et accès membre), tous les types de ressources cliniques et de réclamations sont pris en charge en plus des types précédents. Payer-to-Payer Pour une liste complète des types de ressources pris en charge, consultez le [US Core Implementation Guide (STU 6.1)](https://hl7.org/fhir/us/core/STU6.1/), le [CARIN Blue Button Implementation Guide](https://hl7.org/fhir/us/carin-bb/) et le [Da Vinci Prior Authorization Support Implementation](https://hl7.org/fhir/us/davinci-pas/) Guide.
## Types d'exportation
L'`$davinci-data-export`opération prend en charge les types d'exportation suivants. Vous spécifiez le type d'exportation à l'aide du `exportType` paramètre.
| Type d'exportation | Objectif | Étendue des données | Limite temporelle |
| --- | --- | --- | --- |
| hl7.fhir.us.davinci-atr | Liste d'attribution des membres | Ressources liées à l'attribution | Aucune |
| hl7.fhir.us.davinci-pdex | API d'accès aux fournisseurs | Données cliniques et relatives aux demandes de remboursement pour les patients concernés | 5 ans |
| hl7.fhir.us.davinci-pdex.p2p | Payer-to-Payer Échange | Données historiques sur les membres pour les transitions d'assurance | 5 ans |
| hl7.fhir.us.davinci-pdex.member | API d'accès aux membres | Données de santé propres au membre | 5 ans |
**Note**
Pour les PDex exportations, la limite temporelle de 5 ans ne s'applique pas aux types de ressources ATR (`Group``Patient`,`Coverage`,`RelatedPerson`,`Practitioner`,`PractitionerRole`,`Organization`,`Location`). Ces ressources sont toujours incluses quel que soit l'âge.
### ATR (hl7.fhir.us.davinci-atr)
Avec le type d'exportation ATR, vous pouvez exporter les données de la liste d'attribution des membres. Utilisez ce type d'exportation pour récupérer les ressources liées à l'attribution pour les membres d'un groupe. Pour plus d'informations, consultez l'[opération d'exportation de Da Vinci ATR](https://build.fhir.org/ig/HL7/davinci-atr/OperationDefinition-davinci-data-export.html).
Types de ressource pris en charge
`Group`, `Patient`, `Coverage`, `RelatedPerson`, `Practitioner`, `PractitionerRole`, `Organization`, `Location`
Filtrage temporel
Aucun filtrage temporel n'est appliqué. Toutes les ressources correspondantes sont exportées quelle que soit la date.
### PDex Types d'exportation
Tous les types PDex d'exportation partagent les mêmes profils pris en charge et la même logique de filtrage. Pour plus d'informations, consultez l'[API Da Vinci PDex Provider Access](https://build.fhir.org/ig/HL7/davinci-epdx/provider-access-api.html). Les profils suivants sont pris en charge :
+ US Core 3.1.1, 6.1.0 et 7.0.0
+ PDex Autorisation préalable (non prise en charge pour l'accès des membres)
+ CARIN BB 2.x Profils de base : établissement hospitalier, établissement ambulatoire, professionnel, oral, pharmacie NonClinician
Accès au fournisseur (`hl7.fhir.us.davinci-pdex`)
Permet aux fournisseurs du réseau de récupérer les données des patients pour les patients auxquels ils ont été attribués.
Payer-to-Payer (`hl7.fhir.us.davinci-pdex.p2p`)
Permet l'échange de données entre les payeurs lorsqu'un patient change d'assurance.
Accès aux membres (`hl7.fhir.us.davinci-pdex.member`)
Permet aux membres d'accéder à leurs propres données de santé. Ce type d'exportation peut inclure des données financières dans les ressources relatives aux sinistres.
## Support du profil et logique d'inclusion
Pour les PDex exportations, l'`$davinci-data-export`opération utilise des déclarations de profil dans l'`meta.profile`élément pour déterminer les ressources à inclure dans l'exportation.
### ExplanationOfBenefit Gestion des ressources
`ExplanationOfBenefit`Les ressources (EOB) sont incluses ou exclues des PDex exportations en fonction de leurs `meta.profile` déclarations :
+ ExplanationOfBenefit les ressources dotées d'un profil CARIN BB 1.x sont exclues de l'exportation.
+ ExplanationOfBenefit les ressources non `meta.profile` définies sont exclues de l'exportation.
+ ExplanationOfBenefit les ressources avec un profil CARIN BB 2.x Basis sont toujours incluses.
+ ExplanationOfBenefit les ressources dotées d'un profil CARIN BB 2.x contenant des données financières sont exclues par défaut. Lorsqu'il `_includeEOB2xWoFinancial=true` est défini, ils sont inclus dans les données financières supprimées et la ressource est transformée selon le profil de base correspondant.
+ ExplanationOfBenefit les ressources avec un profil d'autorisation PDex préalable sont toujours incluses.
### Transformation des données financières
Lorsque vous le définissez`_includeEOB2xWoFinancial=true`, l'opération transforme les ExplanationOfBenefit ressources [CARIN BB 2.x](https://hl7.org/fhir/us/carin-bb/) en leurs profils de base correspondants en supprimant les données financières. Par exemple, une `C4BB ExplanationOfBenefit Oral` ressource est transformée en`C4BB ExplanationOfBenefit Oral Basis`, ce qui supprime les données financières de l'enregistrement conformément à la spécification FHIR.
Les éléments de données financières suivants sont supprimés lors de la transformation :
+ Tous les éléments sont tranchés `total`
+ Tous les `adjudication` éléments avec `amounttype` tranche
+ Tous les `item.adjudication` éléments avec des informations sur le montant
L'opération met également à jour les métadonnées du profil lors de la transformation :
+ `meta.profile`est mis à jour vers l'URL canonique du profil Basis
+ La version est mise à jour vers la version CARIN BB 2.x Basis
+ Les ressources existantes dans le magasin de données ne sont pas modifiées
+ Les ressources exportées ne sont pas renvoyées dans le magasin de données
### Règles de détection des profils
L'opération utilise les règles suivantes pour détecter et valider les profils :
+ La détection des versions est basée sur la norme `meta.profile` canonique URLs
+ Une ressource est incluse si l'un de ses profils déclarés correspond aux critères d'exportation
+ La validation du profil a lieu pendant le traitement de l'exportation
## Filtrage temporel quinquennal pour les PDex exportations
Pour tous les types PDex d'exportation, HealthLake applique un filtre temporel de 5 ans basé sur la date de dernière mise à jour de la ressource. Le filtre temporel s'applique à toutes les ressources, à l'exception des types de ressources d'attribution de base suivants, qui sont toujours exportés quel que soit leur âge :
+ `Patient`
+ `Coverage`
+ `Organization`
+ `Practitioner`
+ `PractitionerRole`
+ `RelatedPerson`
+ `Location`
+ `Group`
Ces ressources administratives et démographiques sont exemptées car elles fournissent un contexte essentiel pour les données exportées. Les exportations ATR ne sont soumises à aucun filtrage temporel.
## Exemple de demandes
Les exemples suivants montrent comment démarrer des tâches d'exportation pour différents types d'exportation.
*Exportation 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"
}
}
}
```
*Exportation de l'accès au fournisseur avec suppression des données ExplanationOfBenefit financières*
```
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 exportation*
```
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
```
*Exportation de l'accès aux membres pour un patient spécifique*
```
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
```
## Exemple de réponse
```
{
"datastoreId": "eaee622d8406b41eb86c0f4741201ff9",
"jobStatus": "SUBMITTED",
"jobId": "48d7b91dae4a64d00d54b70862f33f61"
}
```
## Relations avec les ressources
L'opération exporte les ressources en fonction de leurs relations au sein de la liste d'attribution des membres :
```
Group (Attribution List)
├── Patient (Members)
├── Coverage → RelatedPerson (Subscribers)
├── Practitioner (Attributed Providers)
├── PractitionerRole → Location
└── Organization (Attributed Providers)
```
### Sources de ressources
| Ressource | Emplacement de la source | Description |
| --- | --- | --- |
| Patient | Group.member.entity | Les patients membres de la liste d'attribution |
| Coverage | Group.member.extension:coverageReference | Couverture qui a donné lieu à l'adhésion du patient |
| Organization | Group.member.extension:attributedProvider | Organisations auxquelles les patients sont attribués |
| Practitioner | Group.member.extension:attributedProvider | Praticiens individuels auxquels les patients sont attribués |
| PractitionerRole | Group.member.extension:attributedProvider | Rôles de praticiens auxquels les patients sont attribués |
| RelatedPerson | Coverage.subscriber | Abonnés de la couverture |
| Location | PractitionerRole.location | Lieux associés aux rôles des praticiens |
| Group | Point final d'entrée | La liste d'attribution elle-même |
## Gestion du Job
Vérifier le statut du job
`GET [base]/export/[job-id]`
Annuler une tâche
`DELETE [base]/export/[job-id]`
### Cycle de vie d'une tâche
+ `SUBMITTED`- Le job a été reçu et mis en file d'attente
+ `IN_PROGRESS`- Job en cours de traitement actif
+ `COMPLETED`- Job terminé avec succès, fichiers disponibles au téléchargement
+ `FAILED`- Job a rencontré une erreur
## Format de sortie
+ *Format de fichier* : NDJSON (JSON délimité par une nouvelle ligne)
+ *Organisation des fichiers* : fichiers distincts pour chaque type de ressource
+ *Extension de fichier* : .ndjson
+ *Emplacement* : compartiment et chemin S3 spécifiés
## Gestion des erreurs
L'opération renvoie une mauvaise demande HTTP 400 avec un OperationOutcome pour les conditions suivantes :
Erreurs d'autorisation
Le rôle IAM spécifié dans `DataAccessRoleArn` ne dispose pas des autorisations suffisantes pour effectuer l'opération d'exportation. Pour obtenir la liste complète des autorisations S3 et KMS requises, voir [Configuration des autorisations pour les tâches d'exportation](getting-started-setting-up.md#setting-up-export-permissions).
Erreurs de validation des paramètres
+ Le `patient` paramètre n'est pas formaté comme `Patient/id,Patient/id,...`
+ Une ou plusieurs références de patients ne sont pas valides ou n'appartiennent pas au groupe spécifié
+ La valeur du `exportType` paramètre n'est pas un type d'exportation pris en charge
+ Le `_type` paramètre contient les types de ressources qui ne sont pas pris en charge pour le type d'exportation spécifié
+ Le `_type` paramètre ne contient pas les types de ressources requis (`Group`,`Patient`,`Coverage`) pour le type `hl7.fhir.us.davinci-atr` d'exportation
+ La valeur du `_includeEOB2xWoFinancial` paramètre n'est pas une valeur booléenne valide
Erreurs de validation des ressources
+ La ressource de groupe spécifiée n'existe pas dans le magasin de données
+ La ressource de groupe spécifiée n'a aucun membre
+ Un ou plusieurs membres du groupe font référence à des ressources pour patients qui n'existent pas dans le magasin de données
## Sécurité et autorisation
+ Les mécanismes d'autorisation FHIR standard s'appliquent
+ Le rôle d'accès aux données doit disposer des autorisations IAM requises pour les opérations S3 et KMS. Pour obtenir la liste complète des autorisations requises, voir [Configuration des autorisations pour les tâches d'exportation](getting-started-setting-up.md#setting-up-export-permissions).
## Bonnes pratiques
+ *Sélection du type de ressource* : demandez uniquement les types de ressources dont vous avez besoin pour minimiser la taille des exportations et le temps de traitement
+ *Filtrage basé sur le temps* : utilisez le `_since` paramètre pour les exportations incrémentielles
+ *Filtrage des patients* : utilisez le `patient` paramètre lorsque vous n'avez besoin de données que pour des membres spécifiques
+ *Surveillance des tâches* : vérifiez régulièrement l'état des tâches pour les exportations importantes
+ *Gestion des erreurs* : implémentez une logique de nouvelle tentative appropriée pour les tâches ayant échoué
+ *Connaissance du filtre temporel* : pour les PDex exportations, considérez le filtre temporel de 5 ans lorsque vous sélectionnez les types de ressources
+ *Suppression des données financières* : à utiliser `_includeEOB2xWoFinancial=true` lorsque vous avez besoin de données relatives aux réclamations sans informations financières
+ *Gestion des profils* : assurez-vous que les ressources disposent de déclarations de profil appropriées, validez par rapport aux profils cibles avant l'ingestion et utilisez le versionnement des profils pour contrôler le comportement d'exportation
## Limitations
+ Un maximum de 500 patients peut être spécifié dans le `patient` paramètre
+ L'exportation est limitée aux opérations au niveau du groupe uniquement
+ Supporte uniquement l'ensemble prédéfini de types de ressources pour chaque type d'exportation
+ La sortie est toujours au format NDJSON
+ PDex les exportations sont limitées à 5 ans de données cliniques et de réclamations
+ La transformation des données financières ne s'applique qu'aux profils CARIN BB 2.x ExplanationOfBenefit
## Ressources supplémentaires
+ [Liste d'attribution des membres de Da Vinci IG](https://build.fhir.org/ig/HL7/davinci-atr/)
+ [Da Vinci Payer Data Exchange IG](https://hl7.org/fhir/us/davinci-pdex/)
+ [CARIN Consumer Directed Payer Data Exchange IG](https://build.fhir.org/ig/HL7/carin-bb/)
+ [Guide de mise en œuvre de base aux États-Unis](https://www.hl7.org/fhir/us/core/)
+ [Spécification d'accès aux données en masse FHIR](https://hl7.org/fhir/uv/bulkdata/)
# Génération de documents cliniques avec `$document`
AWS HealthLake prend désormais en charge le `$document` fonctionnement des ressources de composition, ce qui vous permet de générer un document clinique complet en regroupant la composition et toutes ses ressources référencées dans un seul package cohérent. Cette opération est essentielle pour les applications de santé qui doivent :
+ Créez des documents cliniques standardisés
+ Échangez les dossiers complets des patients
+ Stockez une documentation clinique complète
+ Générez des rapports qui incluent tous les contextes pertinents
## Usage
L'`$document`opération peut être invoquée sur les ressources de composition à l'aide des méthodes GET et POST :
**Opérations prises en charge**
```
GET/POST [base]/Composition/[id]/$document
```
## Paramètres pris en charge
HealthLake prend en charge le `$document` paramètre FHIR suivant :
| Paramètre | Type | Obligatoire | Par défaut | Description |
| --- | --- | --- | --- | --- |
| persist | booléen | Non | false | Booléen indiquant si le serveur doit stocker le paquet de documents généré |
## Exemples
**Demande GET**
```
GET [base]/Composition/180f219f-97a8-486d-99d9-ed631fe4fc57/$document?persist=true
```
**Requête POST avec paramètres**
```
POST [base]/Composition/180f219f-97a8-486d-99d9-ed631fe4fc57/$document
Content-Type: application/fhir+json
{
"resourceType": "Parameters",
"parameter": [
{
"name": "persist",
"valueBoolean": true
}
]
}
```
**Exemple de réponse**
L'opération renvoie une ressource Bundle de type « document » contenant la composition et toutes les ressources référencées :
```
{
"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"
}
]
}
}
}
]
}
```
## Comportement
L'`$document`opération :
1. Utilise la ressource de composition spécifiée comme base du document
1. Identifie et récupère toutes les ressources directement référencées par la composition
1. Regroupe la composition et toutes les ressources référencées dans un ensemble de type « document »
1. Stocke le paquet de documents généré dans la banque de données lorsque le paramètre persist est défini sur true
1. Identifie et récupère les ressources référencées indirectement par la composition pour une génération complète de documents
L'`$document`opération prend actuellement en charge la récupération de références de ressources au format suivant :
1.
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Resource/id
```
1. Ressource/ID
Les références de ressources non prises en charge dans la ressource Composition seront éliminées du document généré.
## Gestion des erreurs
L'opération gère les conditions d'erreur suivantes :
+ 400 Mauvaise demande : `$document` opération non valide (demande non conforme) ou si le document obtenu échoue à la validation FHIR en raison du filtrage des références lorsque persist est défini sur true
+ 404 Introuvable : ressource de composition introuvable
Pour plus d'informations sur les spécifications de `$document` fonctionnement, consultez la documentation de [composition `$document` du FHIR R4](https://www.hl7.org/fhir/R4/composition-operation-document.html).
# Suppression permanente de ressources avec `$erase`
AWS HealthLake prend en charge l'`$erase`opération, permettant la suppression permanente d'une ressource spécifique et de ses versions historiques. Cette opération est particulièrement utile lorsque vous devez :
+ Supprimer définitivement des ressources individuelles
+ Supprimer des historiques de versions spécifiques
+ Gérez le cycle de vie des ressources individuelles
+ Respectez les exigences spécifiques en matière de suppression des données
## Usage
L'`$erase`opération peut être invoquée à deux niveaux :
**Niveau de l'instance de ressource**
```
POST [base]/[ResourceType]/[ID]/$erase?deleteAuditEvent=true
```
**Niveau spécifique à la version**
```
POST [base]/[ResourceType]/[ID]/_history/[VersionID]/$erase
```
## Parameters
| Paramètre | Type | Obligatoire | Par défaut | Description |
| --- | --- | --- | --- | --- |
| deleteAuditEvent | booléen | Non | false | Lorsque c'est vrai, supprime les événements d'audit associés |
## Exemples
**Exemple de requête**
```
POST [base]/Patient/example-patient/$erase
```
**Exemple de réponse**
```
{
"jobId": "5df47e2f51ff3c731847678cb8cad48e",
"jobStatus": "SUBMITTED"
}
```
## Statut de la tâche
Pour vérifier le statut d'une tâche d'effacement :
```
GET [base]/$erase/[jobId]
```
L'opération renvoie les informations relatives à l'état de la tâche :
```
{
"datastoreId": "36622996b1fcecb7e12ee2ee085308d3",
"jobId": "5df47e2f51ff3c731847678cb8cad48e",
"status": "COMPLETED",
"submittedTime": "2025-10-30T16:39:24.160Z"
}
```
## Comportement
L'`$erase`opération :
1. Traite de manière asynchrone pour garantir l'intégrité des données
1. Maintient les transactions ACID
1. Assure le suivi de l'état des tâches
1. Supprime définitivement la ressource spécifiée et ses versions
1. Inclut un enregistrement d'audit complet des activités de suppression
1. Supporte la suppression sélective des événements d'audit
## Journalisation des audits
L'`$erase`opération est enregistrée sous forme DeleteResource d'ID utilisateur, d'horodatage et de détails sur les ressources.
## Limitations
+ `$erased`la ressource n'apparaîtra pas dans les résultats de recherche ou `_history` les requêtes.
+ Les ressources en cours d'effacement peuvent être temporairement inaccessibles pendant le traitement
+ La mesure du stockage est ajustée immédiatement lorsque les ressources sont définitivement supprimées
# Obtenir les données des patients avec `Patient/$everything`
L'`Patient/$everything`opération est utilisée pour interroger une `Patient` ressource FHIR, ainsi que toute autre ressource associée à celle-ci`Patient`. L'opération peut être utilisée pour permettre à un patient d'accéder à l'intégralité de son dossier ou pour qu'un fournisseur effectue un téléchargement massif de données relatives à un patient. HealthLakesoutiens `Patient/$everything` pour un patient spécifique`id`.
`Patient/$everything`est une opération d'API REST FHIR qui peut être invoquée comme indiqué dans les exemples ci-dessous.
------
#### [ GET request ]
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient/id/$everything
```
------
**Note**
Les ressources en réponse sont triées par type de ressource et par ressource`id`.
La réponse est toujours renseignée avec`Bundle.total`.
## Paramètres dans l’`Patient/$everything`
HealthLake prend en charge les paramètres de requête suivants
| Paramètre | Détails |
| --- | --- |
| démarrer | Obtenez toutes les `Patient` données après une date de début spécifiée. |
| end | Obtenez toutes les `Patient` données avant une date de fin spécifiée. |
| since | Mettez toutes les `Patient` données à jour après une date spécifiée. |
| \$1type | Obtenez `Patient` des données pour des types de ressources spécifiques. |
| \$1compter | Obtenez `Patient` des données et spécifiez le format de page. |
**Example - Obtenez toutes les données du patient après une date de début spécifiée**
`Patient/$everything`peut utiliser le `start` filtre pour interroger uniquement les données après une date précise.
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient/id/$everything?start=2024-03-15T00:00:00.000Z
```
**Example - Obtenez toutes les `Patient` données avant une date de fin spécifiée**
Patient \$1everything peut utiliser le `end` filtre pour n'interroger que des données antérieures à une date précise.
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient/id/$everything?end=2024-03-15T00:00:00.000Z
```
**Example - Mettre à jour toutes les `Patient` données après une date spécifiée**
`Patient/$everything`peut utiliser le `since` filtre pour n'interroger que les données mises à jour après une date précise.
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient/id/$everything?since=2024-03-15T00:00:00.000Z
```
**Example - Obtenir `Patient` des données pour des types de ressources spécifiques**
Le patient \$1everything peut utiliser le `_type` filtre pour spécifier des types de ressources spécifiques à inclure dans la réponse. Plusieurs types de ressources peuvent être spécifiés dans une liste séparée par des virgules.
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient/id/$everything?_type=Observation,Condition
```
**Example - Obtenez `Patient` des données et spécifiez le format de page**
Le patient \$1everything peut utiliser le `_count` pour définir le format de page.
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient/id/$everything?_count=15
```
## `Patient/$everything``start`et `end` attributs
HealthLake prend en charge les attributs de ressource suivants pour les paramètres de `end` requête `Patient/ $everything` `start` et.
| Ressource | Élément de ressource |
| --- | --- |
| Compte | Account.ServicePeriod.Start |
| AdverseEvent | AdverseEvent.date |
| AllergyIntolerance | AllergyIntolerance. Date d'enregistrement |
| Rendez-vous | Rendez-vous.Start |
| AppointmentResponse | AppointmentResponse.démarrer |
| AuditEvent | AuditEvent.period.start |
| Base | Basic. Créé |
| BodyStructure | AUCUNE DATE |
| CarePlan | CarePlan.period.start |
| CareTeam | CareTeam.period.start |
| ChargeItem | ChargeItem. occurrenceDateTime, ChargeItem .occurrencePeriod.start, .occurrenceTiming.Event ChargeItem |
| Demander | Réclamer. Période facturable. Début |
| ClaimResponse | ClaimResponse.créé |
| ClinicalImpression | ClinicalImpression.date |
| Communication | Communication. Envoyée |
| CommunicationRequest | CommunicationRequest. occurrenceDateTime, CommunicationRequest .occurrencePeriod.start |
| Montage | Date de composition |
| Condition | État. Date d'enregistrement |
| Consentement | Consent.Date/Heure |
| Couverture | Couverture.Period.Start |
| CoverageEligibilityRequest | CoverageEligibilityRequest.créé |
| CoverageEligibilityResponse | CoverageEligibilityResponse.créé |
| DetectedIssue | DetectedIssue.identifié |
| DeviceRequest | DeviceRequest. Rédigé le |
| DeviceUseStatement | DeviceUseStatement. Enregistré le |
| DiagnosticReport | DiagnosticReport.efficace |
| DocumentManifest | DocumentManifest.créé |
| DocumentReference | DocumentReference.context .period .start |
| Rencontre | Encounter.Period.Start |
| EnrollmentRequest | EnrollmentRequest.créé |
| EpisodeOfCare | EpisodeOfCare.period.start |
| ExplanationOfBenefit | ExplanationOfBenefit. Période facturable. Début |
| FamilyMemberHistory | AUCUNE DATE |
| Indicateur | Flag.Period.Start |
| Objectif | Objectif. Date d'état |
| Groupe | AUCUNE DATE |
| ImagingStudy | ImagingStudy.démarré |
| Immunisation | Vaccination enregistrée |
| ImmunizationEvaluation | ImmunizationEvaluation.date |
| ImmunizationRecommendation | ImmunizationRecommendation.date |
| Invoice | Date de facturation |
| List | Date de la liste |
| MeasureReport | MeasureReport.period.start |
| Multimédia | Publié dans les médias |
| MedicationAdministration | MedicationAdministration.efficace |
| MedicationDispense | MedicationDispense. Une fois préparé |
| MedicationRequest | MedicationRequest. Rédigé le |
| MedicationStatement | MedicationStatement. Date affirmée |
| MolecularSequence | AUCUNE DATE |
| NutritionOrder | NutritionOrder.Date/Heure |
| Observation | Observation. Efficace |
| Patient | AUCUNE DATE |
| Personne | AUCUNE DATE |
| Procédure | Procédure. Exécutée |
| Provenance | Provenance. Période survenue. Début, provenance. occurredDateTime |
| QuestionnaireResponse | QuestionnaireResponse.écrit |
| RelatedPerson | AUCUNE DATE |
| RequestGroup | RequestGroup. Rédigé le |
| ResearchSubject | ResearchSubject.période |
| RiskAssessment | RiskAssessment. occurrenceDateTime, RiskAssessment .occurrencePeriod.start |
| Planning | Calendrier. Horizon de planification |
| ServiceRequest | ServiceRequest. Rédigé le |
| Spécimen | Spécimen. Heure de réception |
| SupplyDelivery | SupplyDelivery. occurrenceDateTime, SupplyDelivery .occurrencePeriod.start, .occurrenceTiming.Event SupplyDelivery |
| SupplyRequest | SupplyRequest. Rédigé le |
| VisionPrescription | VisionPrescription. Date de rédaction |
# Récupération de ValueSet codes avec `$expand`
AWS HealthLake prend désormais en charge les `$expand` opérations ValueSets que vous avez ingérées en tant que client, ce qui vous permet de récupérer la liste complète des codes contenus dans ces ValueSet ressources. Cette opération est particulièrement utile lorsque vous devez :
+ Récupérez tous les codes possibles à des fins de validation
+ Afficher les options disponibles dans les interfaces utilisateur
+ Effectuez des recherches de code complètes dans un contexte terminologique spécifique
## Usage
L'`$expand`opération peut être invoquée sur les ValueSet ressources à l'aide des méthodes GET et POST :
**Opérations prises en charge**
```
GET/POST [base]/ValueSet/[id]/$expand
GET [base]/ValueSet/$expand?url=http://example.com
POST [base]/ValueSet/$expand
```
## Paramètres pris en charge
HealthLake prend en charge un sous-ensemble de paramètres FHIR `$expand` R4 :
| Paramètre | Type | Obligatoire | Description |
| --- | --- | --- | --- |
| url | uri | Non | URL canonique du ValueSet à développer |
| id | id | Non | ValueSet identifiant de ressource à étendre (pour les opérations GET ou POST) |
| filter | chaîne | Non | Filtrer le résultat de l'extension du code |
| count | entier | Non | Nombre de codes à retourner |
| offset | entier | Non | Nombre de codes correspondants à ignorer avant de retourner. S'applique après le filtrage et uniquement aux codes correspondants, et non à l'intégralité du contenu non filtré de l'original ValueSet |
## Exemples
**Demande GET par identifiant**
```
GET [base]/ValueSet/example-valueset/$expand
```
**Requête GET par URL avec filtre**
```
GET [base]/ValueSet/$expand?url=http://example.com/ValueSet/my-valueset&filter=male&count=5
```
**Requête POST avec paramètres (par ID)**
```
POST [base]/ValueSet/example-valueset/$expand
Content-Type: application/fhir+json
{
"resourceType": "Parameters",
"parameter": [
{
"name": "count",
"valueInteger": 10
},
{
"name": "filter",
"valueString": "admin"
}
]
}
```
**Requête POST avec paramètres (par 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
}
]
}
```
**Exemple de réponse**
L'opération renvoie une ValueSet ressource avec un `expansion` élément contenant les codes développés :
```
{
"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 réponse inclut :
+ expansion.total : nombre total de codes dans l'extension ValueSet
+ expansion.contains : tableau de codes étendus avec leur système, leur code et leurs valeurs d'affichage
+ expansion.parameter : paramètres utilisés dans la demande d'extension
Pour plus d'informations sur les spécifications de `$expand` fonctionnement, consultez la documentation du [FHIR R4 ValueSet `$expand`](https://build.fhir.org/valueset-operation-expand.html).
# Exporter HealthLake des données avec FHIR `$export`
Vous pouvez exporter des données en masse depuis votre magasin de HealthLake données à l'aide de l'opération FHIR \$1export. HealthLake prend en charge l'`$export`utilisation `POST` et les `GET` demandes de FHIR. Pour effectuer une demande d'exportation avec`POST`, vous devez disposer d'un utilisateur, d'un groupe ou d'un rôle IAM doté des autorisations requises, le spécifier dans le `$export` cadre de la demande et inclure les paramètres souhaités dans le corps de la demande.
**Note**
Toutes les demandes HealthLake d'exportation effectuées à l'aide de FHIR `$export` sont renvoyées au `ndjson` format et exportées vers un compartiment Amazon S3, où chaque objet Amazon S3 ne contient qu'un seul type de ressource FHIR.
Vous pouvez mettre en file d'attente les demandes d'exportation conformément aux quotas de service du AWS compte. Pour de plus amples informations, veuillez consulter [Quotas de service](reference-healthlake-endpoints-quotas.md#reference-healthlake-quotas).
HealthLake prend en charge les trois types suivants de demandes de terminaux d'exportation en masse.
**HealthLake `$export`types en vrac**
| Type d’exportation | Description | Syntaxe |
| --- | --- | --- |
| Système | Exportez toutes les données depuis le serveur HealthLake FHIR. | `POST https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/$export` |
| Tous les patients | Exportez toutes les données relatives à tous les patients, y compris les types de ressources associés au type de ressource Patient. | `POST https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient/$export` `GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient/$export` |
| Groupe de patients | Exportez toutes les données relatives à un groupe de patients spécifié par un identifiant de groupe. | `POST https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Group/id/$export` `GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Group/id/$export` |
## Avant de commencer
Répondez aux exigences suivantes pour effectuer une demande d'exportation à l'aide de l'API REST FHIR pour HealthLake.
+ Vous devez avoir configuré un utilisateur, un groupe ou un rôle disposant des autorisations nécessaires pour effectuer la demande d'exportation. Pour en savoir plus, veuillez consulter la section [Autoriser une demande `$export`](#export-rest-auth).
+ Vous devez avoir créé un rôle de service qui accorde l' HealthLake accès au compartiment Amazon S3 vers lequel vous souhaitez que vos données soient exportées. Le rôle de service doit également être spécifié HealthLake comme principal de service. Pour plus d'informations sur la configuration des autorisations, consultez[Configuration des autorisations pour les tâches d'exportation](getting-started-setting-up.md#setting-up-export-permissions).
## Autoriser une demande `$export`
Pour effectuer une demande d'exportation réussie à l'aide de l'API REST FHIR, autorisez votre utilisateur, votre groupe ou votre rôle à l'aide d'IAM ou OAuth2 .0. Vous devez également avoir un rôle de service.
**Autoriser une demande à l'aide d'IAM**
Lorsque vous faites une `$export` demande, les actions IAM de l'utilisateur, du groupe ou du rôle doivent être incluses dans la politique. Pour de plus amples informations, veuillez consulter [Configuration des autorisations pour les tâches d'exportation](getting-started-setting-up.md#setting-up-export-permissions).
**Autoriser une demande à l'aide de SMART sur FHIR (2.0) OAuth**
Lorsque vous faites une `$export` demande sur un magasin de HealthLake données compatible SMART sur FHIR, les étendues appropriées doivent vous être attribuées. Pour de plus amples informations, veuillez consulter [SMART sur les champs de ressources FHIR pour HealthLake](reference-smart-on-fhir-oauth-scopes.md#smart-on-fhir-scopes-rest).
**Note**
Le FHIR `$export` avec `GET` demandes nécessite la même méthode d'authentification ou le même jeton porteur (dans le cas de SMART sur FHIR) pour demander l'exportation et la récupération de fichiers. Les fichiers exportés à l'aide de FHIR `$export` avec `GET` peuvent être téléchargés pendant 48 heures.
## Faire une `$export` demande
Cette section décrit les étapes obligatoires que vous devez suivre lorsque vous effectuez une demande d'exportation à l'aide de l'API REST FHIR.
Pour éviter des frais accidentels sur votre AWS compte, nous vous recommandons de tester vos demandes en effectuant une `POST` demande sans fournir de `$export` syntaxe.
Pour faire la demande, vous devez effectuer les opérations suivantes :
1. Spécifiez `$export` dans l'URL de `POST` demande un point de terminaison pris en charge.
1. Spécifiez les paramètres d'en-tête requis.
1. Spécifiez un corps de demande qui définit les paramètres requis.
### Étape 1 : Spécifiez `$export` dans l'URL de `POST` demande un point de [terminaison](reference-healthlake-endpoints-quotas.md#reference-healthlake-endpoints) pris en charge.
HealthLake prend en charge trois types de demandes d'exportation groupées pour les terminaux. Pour effectuer une demande d'exportation groupée, vous devez effectuer une demande `POST` basée sur l'un des trois points de terminaison pris en charge. Les exemples suivants montrent où spécifier `$export` dans l'URL de la demande.
+ `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`
Vous pouvez utiliser les paramètres de recherche pris en charge suivants dans la chaîne de `POST` requête.
#### Paramètres de recherche pris en charge
HealthLake prend en charge les modificateurs de recherche suivants dans les demandes d'exportation groupées.
Les exemples suivants incluent des caractères spéciaux qui doivent être codés avant de soumettre votre demande.
| Nom | Obligatoire ? | Description | Exemple |
| --- | --- | --- | --- |
| \$1outputFormat | Non | Format des fichiers de données en masse demandés à générer. Les valeurs acceptées sont application/fhir\$1ndjsonapplication/ndjson,ndjson. | |
| \$1type | Non | Chaîne de types de ressources FHIR séparés par des virgules que vous souhaitez inclure dans votre tâche d'exportation. Nous vous recommandons de l'inclure, \$1type car cela peut avoir une incidence financière lorsque toutes les ressources sont exportées. | &\$1type=MedicationStatement, Observation |
| \$1since | Non | Types de ressources modifiés le jour ou après l'horodatage. Si un type de ressource n'a pas d'heure de dernière mise à jour, il sera inclus dans votre réponse. | &\$1since=2024-05-09T00%3A00%3A00Z |
| \$1until | Non | Types de ressources modifiés le jour ou avant l'horodatage. Utilisé en combinaison avec \$1since pour définir une plage de temps spécifique pour l'exportation. Si un type de ressource n'a pas d'heure de dernière mise à jour, il sera exclu de votre réponse. | &\$1until=2024-12-31T23%3A59%3A59Z |
### Étape 2 : Spécifier les paramètres d'en-tête requis
Pour effectuer une demande d'exportation à l'aide de l'API REST FHIR, vous devez spécifier les paramètres d'en-tête suivants.
+ Type de contenu : `application/fhir+json`
+ Préférez : `respond-async`
Ensuite, vous devez spécifier les éléments requis dans le corps de la demande.
### Étape 3 : Spécifiez un corps de demande qui définit les paramètres requis.
La demande d'exportation nécessite également un corps au `JSON` format. Le corps peut inclure les paramètres suivants.
| Clé | Obligatoire ? | Description | Value |
| --- | --- | --- | --- |
| DataAccessRoleArn | Oui | L'ARN d'un rôle HealthLake de service. Le rôle de service utilisé doit être spécifié HealthLake comme principal de service. | arn:aws:iam::444455556666:role/your-healthlake-service-role |
| JobName | Non | Nom de la demande d'exportation. | your-export-job-name |
| S3Uri | Oui | Partie d'une OutputDataConfig clé. L'URI S3 du compartiment de destination dans lequel vos données exportées seront téléchargées. | s3://amzn-s3-demo-bucket/EXPORT-JOB/ |
| KmsKeyId | Oui | Partie d'une OutputDataConfig clé. L'ARN de la AWS KMS clé utilisée pour sécuriser le compartiment Amazon S3. | arn:aws:kms:region-of-bucket:123456789012:key/1234abcd-12ab-34cd-56ef-1234567890ab |
**Example Corps d'une demande d'exportation effectuée à l'aide de l'API REST FHIR**
Pour effectuer une demande d'exportation à l'aide de l'API REST FHIR, vous devez spécifier un corps, comme indiqué ci-dessous.
```
{
"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"
}
}
}
```
Lorsque votre demande sera acceptée, vous recevrez la réponse suivante.
*En-tête de réponse*
```
content-location: https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/export/your-export-request-job-id
```
*Organisme de réponse*
```
{
"datastoreId": "your-data-store-id",
"jobStatus": "SUBMITTED",
"jobId": "your-export-request-job-id"
}
```
## Gestion de votre demande d'exportation
Après avoir effectué une demande d'exportation réussie, vous pouvez la gérer en `$export` décrivant le statut d'une demande d'exportation en cours et `$export` en annulant une demande d'exportation en cours.
Lorsque vous annulez une demande d'exportation à l'aide de l'API REST, vous n'êtes facturée que pour la partie des données exportées jusqu'au moment où vous avez soumis la demande d'annulation.
Les rubriques suivantes décrivent comment vous pouvez obtenir le statut d'une demande d'exportation en cours ou l'annuler.
### Annulation d'une demande d'exportation
Pour annuler une demande d'exportation, faites une `DELETE` demande et indiquez l'ID de tâche dans l'URL de la demande.
```
DELETE https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/export/your-export-request-job-id
```
Lorsque votre demande est acceptée, vous recevez ce qui suit.
```
{
"exportJobProperties": {
"jobId": "your-original-export-request-job-id",
"jobStatus": "CANCEL_SUBMITTED",
"datastoreId": "your-data-store-id"
}
}
```
Lorsque votre demande n'aboutit pas, vous recevez ce qui suit.
```
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "not-supported",
"diagnostics": "Interaction not supported."
}
]
}
```
### Décrire une demande d'exportation
Pour connaître le statut d'une demande d'exportation, faites une `GET` demande en utilisant `export` et votre`export-request-job-id`.
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/export/your-export-request-id
```
La réponse JSON contiendra un `ExportJobProperties` objet. Il peut contenir les paires clé:valeur suivantes.
| Nom | Obligatoire ? | Description | Value |
| --- | --- | --- | --- |
| DataAccessRoleArn | Non | L'ARN d'un rôle HealthLake de service. Le rôle de service utilisé doit être spécifié HealthLake comme principal de service. | arn:aws:iam::444455556666:role/your-healthlake-service-role |
| SubmitTime | Non | Date à laquelle une tâche d'exportation a été soumise. | Apr 21, 2023 5:58:02 |
| EndTime | Non | Heure à laquelle une tâche d'exportation a été terminée. | Apr 21, 2023 6:00:08 PM |
| JobName | Non | Nom de la demande d'exportation. | your-export-job-name |
| JobStatus | Non | | Les valeurs valides sont :SUBMITTED | IN_PROGRESS | COMPLETED_WITH_ERRORS | COMPLETED |
FAILED
|
| S3Uri | Oui | Partie d'un [OutputDataConfig](https://docs.aws.amazon.com/healthlake/latest/APIReference/API_OutputDataConfig.html)objet. L'URI Amazon S3 du compartiment de destination dans lequel vos données exportées seront téléchargées. | s3://amzn-s3-demo-bucket/EXPORT-JOB/ |
| KmsKeyId | Oui | Partie d'un [OutputDataConfig](https://docs.aws.amazon.com/healthlake/latest/APIReference/API_OutputDataConfig.html)objet. L'ARN de la AWS KMS clé utilisée pour sécuriser le compartiment Amazon S3. | arn:aws:kms:region-of-bucket:123456789012:key/1234abcd-12ab-34cd-56ef-1234567890ab |
**Example : corps d'une demande d'exportation de description effectuée à l'aide de l'API REST FHIR**
En cas de succès, vous obtiendrez la réponse JSON suivante.
```
{
"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`Opération FHIR pour HealthLake
L'`$inquire`opération vous permet de vérifier le statut d'une demande d'autorisation préalable soumise précédemment. Cette opération met en œuvre le [guide de mise en œuvre du Da Vinci Prior Authorization Support (PAS)](https://hl7.org/fhir/us/davinci-pas/), fournissant un flux de travail standardisé basé sur le FHIR pour récupérer la décision d'autorisation actuelle.
## Comment ça marche
+ **Soumettre une demande** : vous envoyez un bundle FHIR contenant la réclamation que vous souhaitez vérifier et les informations justificatives
+ **Rechercher** : HealthLake recherche le correspondant ClaimResponse dans votre magasin de données
+ **Récupérer** : le statut d'autorisation le plus récent est récupéré
+ **Répondre** : vous recevez une réponse immédiate avec le statut d'autorisation actuel (en file d'attente, approuvé, refusé, etc.)
**Note**
`$inquire`est une **opération en lecture seule** qui permet de récupérer le statut d'autorisation existant. Il ne modifie ni ne met à jour aucune ressource de votre banque de données.
## Point de terminaison d’API
```
POST /datastore/{datastoreId}/r4/Claim/$inquire
Content-Type: application/fhir+json
```
## Structure de la demande
### Exigences relatives au bundle
Votre demande doit être une ressource FHIR Bundle contenant :
+ **Bundle.type** : Doit être `"collection"`
+ **Bundle.entry** : Doit contenir exactement **une** ressource Claim avec :
+ `use = "preauthorization"`
+ `status = "active"`
+ **Ressources référencées** : Toutes les ressources référencées par la réclamation doivent être incluses dans le bundle
**Requête par exemple**
Les ressources de votre bundle d'entrée servent de modèle de recherche. HealthLake utilise les informations fournies pour localiser le correspondant ClaimResponse.
### Ressources requises
| Ressource | Cardinalité | Profil | Description |
| --- | --- | --- | --- |
| Réclamation | 1 | Demande de réclamation PAS | L'autorisation préalable que vous demandez |
| Patient | 1 | Patient bénéficiaire du PAS | Informations démographiques sur les patients |
| Organisation (assureur) | 1 | Organisation d'assurance PAS | Compagnie d'assurance |
| Organisation (fournisseur) | 1 | Organisation demandeuse du PAS | Prestataire de santé qui a soumis la demande |
### Critères de recherche importants
HealthLake recherche l' ClaimResponse utilisation de :
+ **Référence du patient** tirée de la réclamation
+ **Référence de l'assureur** tirée de la réclamation
+ **Référence du fournisseur** figurant dans la réclamation
+ **Date de création** à partir de la réclamation (en tant que filtre temporel)
**Demandes spécifiques au patient uniquement**
Toutes les demandes doivent être liées à un patient en particulier. Les requêtes à l'échelle du système sans identification du patient ne sont pas autorisées.
## Exemple de demande
```
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"
}
}
]
}
```
## Format de la réponse
### Réponse positive (200 OK)
Vous recevrez un ensemble de réponses aux demandes de renseignements PAS contenant :
+ **ClaimResponse**avec le statut d'autorisation actuel ; multiple **ClaimResponse**s'il correspond aux critères de recherche
+ Toutes les ressources originales de votre demande (renvoyées)
+ Horodatage du moment où la réponse a été assemblée
**ClaimResponse Résultats possibles**
| Outcome | Description |
| --- | --- |
| queued | La demande d'autorisation est toujours en attente d'examen |
| complete | La décision d'autorisation a été prise (vérifier si elle est disposition approuvée/refusée) |
| error | Une erreur s'est produite lors du traitement |
| partial | Autorisation partielle accordée |
```
{
"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"
}
}
]
}
```
## Réponses d'erreur
### 400 Requête erronée
Renvoyé lorsque le format de demande n'est pas valide ou que la validation échoue.
```
{
"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 Accès non autorisé
Renvoyé lorsque les informations d'authentification sont manquantes ou non valides.
```
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "forbidden",
"diagnostics": "Invalid authorization header"
}
]
}
```
### 403 Forbidden
Renvoyé lorsque l'utilisateur authentifié n'est pas autorisé à accéder à la ressource demandée.
```
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "exception",
"diagnostics": "Insufficient SMART scope permissions."
}
]
}
```
### 400 Quand aucun n'est trouvé
Renvoyé lorsqu'aucune correspondance n' ClaimResponse est trouvée pour la demande.
```
{
"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)"
}]
}
```
### 415 Type de média non pris en charge
Renvoyé lorsque l'en-tête Content-Type n'est pas application/fhir\$1json.
```
{
"resourceType": "OperationOutcome",
"issue": [{
"severity": "error",
"code": "value",
"diagnostics": "Incorrect MIME-type. Update request Content-Type header."
}]
}
```
### 429 Trop de demandes
Renvoyé lorsque les limites de débit sont dépassées.
```
{
"resourceType": "OperationOutcome",
"issue": [{
"severity": "error",
"code": "throttled",
"diagnostics": "Rate limit exceeded. Please retry after some time."
}]
}
```
## Règles de validation
HealthLake effectue une validation complète de votre demande :
### Validation du bundle
+ Doit être conforme au profil du bundle PAS Inquiry Request
+ `Bundle.type`doit être `"collection"`
+ Doit contenir exactement une ressource de réclamation
+ Toutes les ressources référencées doivent être incluses dans le bundle
### Validation des réclamations
+ Doit être conforme au profil PAS Claim Inquiry
+ `Claim.use`doit être `"preauthorization"`
+ `Claim.status`doit être `"active"`
+ Champs obligatoires : `patient``insurer`,`provider`, `created`
### Validation des ressources
+ Toutes les ressources doivent être conformes à leurs profils d'enquête PAS respectifs
+ Les ressources de soutien requises doivent être présentes (patient, organisme assureur, organisme fournisseur)
+ Les références croisées doivent être valides et résolvables dans le bundle
## Spécifications de performance
| Métrique | Spécification de |
| --- | --- |
| Limite du nombre de ressources | 500 ressources par bundle |
| Limite de taille du bundle | 5 Mo maximum |
## Autorisations requises
Pour utiliser l'`$inquire`opération, assurez-vous que votre rôle IAM possède les éléments suivants :
+ `healthlake:InquirePreAuthClaim`- Pour appeler l'opération
**SMART sur les oscilloscopes FHIR**
**Étendue minimale requise :**
+ **SMART version 1** : `user/ClaimResponse.read`
+ **SMART v2** : `user/ClaimResponse.s`
## Remarques de mise en œuvre importantes
### Comportement de recherche
Lorsque vous soumettez une demande, recherchez l' HealthLake utilisateur à l' ClaimResponse aide de :
+ **Référence du patient** tirée de la demande d'entrée
+ **Référence de l'assureur** tirée de la demande d'entrée
+ **Référence du fournisseur** à partir de la demande d'entrée
+ **Date de création** à partir de la demande d'entrée (en tant que filtre temporel)
**Correspondances multiples** : si plusieurs ClaimResponses correspondent à vos critères de recherche, HealthLake renvoie tous les résultats correspondants. Vous devez utiliser l'`ClaimResponse.created`horodatage le plus récent pour identifier le dernier statut.
### Demandes mises à jour
Si vous avez soumis plusieurs mises à jour pour la même autorisation préalable (par exemple, Claim v1.1, v1.2, v1.3), l'`$inquire`opération récupérera la version ClaimResponse associée à la **version la plus récente** en fonction des critères de recherche fournis.
### Fonctionnement en lecture seule
L'`$inquire`opération :
+ **Récupère le** statut d'autorisation existant
+ **Renvoie** le plus récent ClaimResponse
+ **Ne modifie ni ne** met à jour aucune ressource
+ **Ne crée pas** de nouvelles ressources
+ **Ne déclenche pas** de nouveau traitement d'autorisation
## Exemple de flux de travail
**Flux de travail typique de demande d'autorisation préalable**
```
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"
```
## Opérations liées
+ `Claim/$submit`- Soumettre une nouvelle demande d'autorisation préalable ou mettre à jour une demande existante
+ `Patient/$everything`- Récupérez les données complètes du patient pour le contexte de l'autorisation préalable
# Récupération des détails du concept avec `$lookup`
AWS HealthLake prend désormais en charge les `$lookup` opérations relatives aux CodeSystem ressources, ce qui vous permet de récupérer les détails d'un concept spécifique dans un système de code en fournissant des informations d'identification telles que son code. Cette opération est particulièrement utile lorsque vous devez :
+ Récupérez des informations détaillées sur des codes médicaux spécifiques
+ Valider la signification et les propriétés du code
+ Définitions et relations des concepts d'accès
+ Support à la prise de décisions cliniques grâce à des données terminologiques précises
## Usage
L'`$lookup`opération peut être invoquée sur les CodeSystem ressources à l'aide des méthodes GET et POST :
**Opérations prises en charge**
```
GET [base]/CodeSystem/$lookup?system=http://snomed.info/sct&code=73211009&version=20230901
POST [base]/CodeSystem/$lookup
```
## Paramètres pris en charge
HealthLake prend en charge un sous-ensemble de paramètres FHIR `$lookup` R4 :
| Paramètre | Type | Obligatoire | Description |
| --- | --- | --- | --- |
| code | code | Oui | Le code conceptuel que vous recherchez (par exemple, « 71620000 » dans SNOMED CT) |
| system | uri | Oui | L'URL canonique du système de code (par exemple, "[http://snomed.info/sct](http://snomed.info/sct) «) |
| version | chaîne | Non | Version spécifique du système de code |
## Exemples
**Demande GET**
```
GET [base]/CodeSystem/$lookup?system=http://snomed.info/sct&code=71620000&version=2023-09
```
**Demande 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"
}
]
}
```
**Exemple de réponse**
L'opération renvoie une ressource Parameters contenant les détails du concept :
```
{
"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"
}
]
}
]
}
```
## Paramètres de réponse
La réponse inclut les paramètres suivants lorsqu'ils sont disponibles :
| Paramètre | Type | Description |
| --- | --- | --- |
| name | chaîne | Nom du système de code |
| version | chaîne | Version du système de code |
| display | chaîne | Afficher le nom du concept |
| designation | BackboneElement | Des représentations supplémentaires pour ce concept. |
| property | BackboneElement | Propriétés supplémentaires du concept (définition, relations, etc.) |
## Comportement
L'`$lookup`opération :
1. Valide les paramètres requis (`code`et`system`)
1. Recherche le concept dans le système de code spécifié stocké dans la banque de données
1. Renvoie des informations détaillées sur le concept, notamment le nom d'affichage, les désignations et les propriétés.
1. Prend en charge les recherches spécifiques à la version lorsque le paramètre est fourni `version`
1. Fonctionne uniquement sur les systèmes de code explicitement stockés dans la HealthLake banque de données
## Gestion des erreurs
L'opération gère les conditions d'erreur suivantes :
+ 400 Mauvaise demande : `$lookup` opération non valide (demande non conforme ou paramètres requis manquants)
+ 404 Introuvable : système de code introuvable ou code introuvable dans le système de code spécifié
## Mises en garde
Dans cette version, les éléments suivants ne sont pas pris en charge :
+ `$lookup`opération en appelant des serveurs terminologiques externes
+ `$lookup`opération sur CodeSystems gérée par HealthLake mais non explicitement stockée dans la banque de données
Pour plus d'informations sur les spécifications de `$lookup` fonctionnement, consultez la documentation du [FHIR R4 CodeSystem `$lookup`](https://www.hl7.org/fhir/R4/codesystem-operation-lookup.html).
# `$member-add`opération pour HealthLake
L'`$member-add`opération FHIR ajoute un membre (patient) à une ressource de groupe, en particulier à une liste d'attribution de membres. Cette opération fait partie du guide de mise en œuvre de l'attribution des DaVinci membres et soutient le processus de rapprochement pour la gestion des attributions des membres.
## Opération Endpoint
```
POST [base]/datastore/{datastoreId}/r4/Group/{groupId}/$member-add
Content-Type: application/json
```
## Parameters
L'opération accepte une ressource de paramètres FHIR avec les combinaisons de paramètres suivantes :
### Options de paramètres
Vous pouvez utiliser l'une des combinaisons de paramètres suivantes :
Option 1 : ID de membre \$1 NPI du fournisseur
`memberId` \$1 `providerNpi`
`memberId` \$1 `providerNpi` \$1 `attributionPeriod`
Option 2 : référence du patient et référence du fournisseur
`patientReference` \$1 `providerReference`
`patientReference` \$1 `providerReference` \$1 `attributionPeriod`
### Détails des paramètres
ID de membre (facultatif)
Identifiant du membre à ajouter au groupe.
Type : Identifiant
Système : système d'identification du patient
```
{
"name": "memberId",
"valueIdentifier": {
"system": "http://example.org/patient-id",
"value": "patient-new"
}
}
```
ProviderNPI (facultatif)
L'identifiant national du fournisseur (NPI) du fournisseur attribué.
Type : Identifiant
Système : http://terminology.hl7. org/CodeSystem/NPI
```
{
"name": "providerNpi",
"valueIdentifier": {
"system": "http://terminology.hl7.org/CodeSystem/NPI",
"value": "1234567890"
}
}
```
Référence du patient (facultatif)
Référence directe à la ressource patient à ajouter.
Type : Référence
```
{
"name": "patientReference",
"valueReference": {
"reference": "Patient/patient-123"
}
}
```
Référence du fournisseur (facultatif)
Référence directe à la ressource du fournisseur.
Type : Référence
```
{
"name": "providerReference",
"valueReference": {
"reference": "Practitioner/provider-456"
}
}
```
Période d'attribution (facultatif)
Période pendant laquelle le patient est attribué au prestataire.
Type : Période
```
{
"name": "attributionPeriod",
"valuePeriod": {
"start": "2024-07-15",
"end": "2025-07-14"
}
}
```
## Exemples de demandes
### Utilisation de l'ID de membre et du NPI du fournisseur
```
{
"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"
}
}
]
}
```
### Utilisation des références des patients et des prestataires
```
{
"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"
}
}
]
}
```
## Format de la réponse
### Réponse d'ajout réussie
```
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."
}
}
]
}
```
### Réponses d’erreur
Syntaxe de demande non valide
État HTTP : 400 demandes incorrectes
```
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "invalid",
"details": {
"text": "Invalid parameter combination provided"
}
}
]
}
```
Ressource introuvable
État HTTP : 404 introuvable
```
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "not-found",
"details": {
"text": "Resource not found."
}
}
]
}
```
Conflit de version
État HTTP : 409 Conflit
```
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "conflict",
"details": {
"text": "Resource version conflict detected"
}
}
]
}
```
État d'attribution non valide
État HTTP : 422 Entité non traitable
```
{
"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'."
}
}
]
}
```
## Règles commerciales
Validation du statut d'attribution
L'opération ne peut être effectuée que lorsque le statut d'attribution du groupe est :
+ `draft`
+ `open`
Les opérations ne sont pas autorisées lorsque le statut est défini`final`.
Prévention des doublons de membres
Le système empêche l'ajout de membres dupliqués sur la base de la combinaison unique de :
+ Identifiant du membre
+ Identifiant du payeur
+ Identifiant de couverture
Validation des périodes de couverture
Lorsqu'une offre `attributionPeriod` est fournie, elle doit se situer dans les limites de la période de couverture du membre. Le système va :
+ Recherchez la ressource de couverture du membre
+ Utiliser la couverture la plus récente (versionID le plus élevé) s'il en existe plusieurs
+ Validez que la période d'attribution ne dépasse pas la période de couverture
Validation des références
Lorsque l'identifiant et la référence sont fournis pour la même ressource (patient ou fournisseur), le système valide qu'ils correspondent à la même ressource.
Lorsque les champs ID et reference.identifier sont fournis pour la même ressource (patient ou fournisseur), une erreur est générée.
## Authentification et autorisation
L'opération nécessite une autorisation SMART on FHIR pour :
+ Permissions de lecture : pour valider les ressources du patient, du fournisseur et du groupe
+ Autorisations de recherche : pour rechercher des ressources par identifiant
+ Mettre à jour les autorisations : pour modifier la ressource du groupe
## Comportement opérationnel
Mise à jour des ressources
+ Met à jour l'ID de version de la ressource du groupe
+ Crée une entrée d'historique avec l'état de la ressource d'origine avant l'opération
+ Ajoute des informations sur les membres au tableau Group.member avec :
+ Référence du patient dans entity.reference
+ Période d'attribution dans la période
+ Couverture et informations sur les fournisseurs dans les domaines d'extension
Étapes de validation
+ Validation des paramètres : garantit la validité des combinaisons de paramètres
+ Existence des ressources : valide l'existence des ressources du patient, du fournisseur et du groupe
+ État d'attribution : confirme que le statut du groupe autorise les modifications
+ Duplicate Check - Empêche l'ajout de membres existants
+ Validation de la couverture : garantit que la période d'attribution se situe dans les limites de couverture
## Limitations
+ Toutes les ressources référencées doivent exister dans la même banque de données
+ L'opération ne fonctionne qu'avec les ressources du groupe de listes d'attribution de membres
+ Les périodes d'attribution doivent se situer dans les limites de couverture
+ Impossible de modifier les groupes ayant le statut « final »
# `$member-match`opération pour HealthLake
AWS HealthLake soutient désormais le `$member-match` fonctionnement des ressources destinées aux patients, permettant aux établissements de santé de trouver l'identifiant unique d'un membre dans différents systèmes de santé à l'aide d'informations démographiques et de couverture. Cette opération est essentielle pour garantir la conformité au CMS et faciliter l'échange de payer-to-payer données sécurisé tout en préservant la confidentialité des patients.
Cette opération est particulièrement utile lorsque vous devez :
+ Permettre un échange sécurisé de données de santé entre les organisations
+ Assurer la continuité des soins aux patients dans les différents systèmes
+ Support des exigences de conformité du CMS
+ Faciliter l'identification précise des membres dans les réseaux de santé
## Usage
L'`$member-match`opération peut être invoquée sur les ressources du patient à l'aide de la méthode POST :
```
POST [base]/Patient/$member-match
```
## Paramètres pris en charge
HealthLake prend en charge les `$member-match` paramètres FHIR suivants :
| Paramètre | Type | Obligatoire | Par défaut | Description |
| --- | --- | --- | --- | --- |
| MemberPatient | Patient | Oui | — | Ressource destinée aux patients contenant des informations démographiques pour le membre à jumeler |
| CoverageToMatch | Couverture | Oui | — | Ressource de couverture qui sera utilisée pour la comparaison avec les enregistrements existants |
| CoverageToLink | Couverture | Non | — | Ressource de couverture à associer pendant le processus de jumelage |
| Consentement | Consentement | Non | — | Ressource de consentement à des fins d'autorisation |
## Exemples
### Requête POST avec paramètres
```
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"
}
]
}
}
]
}
```
### Exemple de réponse
L'opération renvoie une ressource Parameters contenant les résultats correspondants :
```
{
"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"
}
]
}
```
## Paramètres de réponse
La réponse inclut les paramètres suivants lorsqu'une correspondance est trouvée :
| Paramètre | Type | Description |
| --- | --- | --- |
| MemberIdentifier | Identifiant | L'identifiant unique du membre correspondant |
| MemberId | Référence | Référence à la ressource destinée aux patients |
| Algorithme de correspondance | String | Type d'algorithme de correspondance utilisé (EXACT\$1MATCH, STRONG\$1MATCH ou DEMOGRAPHIC\$1MATCH) |
| Détails du match | String | Informations détaillées sur le processus de mise en correspondance |
| Champs correspondants | String | Liste des champs spécifiques qui ont été correctement mis en correspondance |
## Algorithmes correspondants
L'`$member-match`API utilise une approche de correspondance à plusieurs niveaux pour garantir une identification précise des membres :
MATCH EXACT
Utilise l'identifiant du patient combiné à la couverture SubscriberId
Fournit le niveau de confiance le plus élevé pour le jumelage des membres
STRONG\$1MATCH
Utilise l'identifiant du patient avec les informations de couverture minimales
Offre un niveau de confiance élevé lorsque les critères de correspondance exacts ne sont pas respectés
MATCH DÉMOGRAPHIQUE
S'appuie sur des informations démographiques de base
Utilisé lorsque la correspondance basée sur un identifiant n'est pas possible
## Comportement
L'`$member-match`opération :
+ Accepte les données démographiques des patients, les détails de la couverture et les informations de consentement facultatives en entrée
+ Renvoie un identifiant de membre unique qui peut être utilisé pour les interactions suivantes
+ Met en œuvre un appariement à plusieurs niveaux (exact, solide, démographique) pour garantir l'identification précise des membres dans les différents systèmes de santé
+ Enregistre toutes les informations de consentement fournies à des fins d'autorisation futures
+ Permet un échange de payer-to-payer données sécurisé tout en préservant la confidentialité des patients
+ Conforme aux exigences du CMS pour l'échange de données de santé
## Autorisation
L'API utilise le protocole d'autorisation SMART on FHIR avec les étendues requises suivantes :
+ `system/Patient.read`
+ `system/Coverage.read`
+ `system/Organization.read`(conditionnel)
+ `system/Practitioner.read`(conditionnel)
+ `system/PractitionerRole.read`(conditionnel)
+ `system/Consent.write`(conditionnel)
## Gestion des erreurs
L'opération gère les conditions d'erreur suivantes :
+ `400 Bad Request`: `$member-match` opération non valide (demande non conforme ou paramètres obligatoires manquants)
+ `422 Unprocessable Entity`: Aucune correspondance ou plusieurs correspondances trouvées
# `$member-remove`opération pour HealthLake
L'`$member-remove`opération vous permet de supprimer des membres d'une liste d'attribution de membres FHIR (ressource de groupe) dans AWS HealthLake. Cette opération fait partie du guide de mise en œuvre de l'attribution des DaVinci membres et soutient le processus de rapprochement pour la gestion des attributions des membres.
## Conditions préalables
+ AWS HealthLake Banque de données FHIR
+ Autorisations IAM appropriées pour les opérations HealthLake
+ Liste d'attribution des membres (ressource du groupe) en version provisoire ou ouverte
## Détails de l'opération
Endpoint
`POST /Group/{id}/$member-remove`
Type de contenu
`application/fhir+json`
## Parameters
L'opération accepte une ressource de paramètres FHIR avec les paramètres facultatifs suivants :
| Paramètre | Cardinalité | Type | Description |
| --- | --- | --- | --- |
| memberId | 0,1 | Identifiant | Identifiant professionnel du membre à supprimer |
| Fournisseur NPI | 0,1 | Identifiant | NPI du fournisseur attribué |
| Référence du patient | 0,1 | Référence | Référence directe à la ressource destinée aux patients |
| Référence du fournisseur | 0,1 | Référence | Référence directe à la ressource du fournisseur (praticien ou organisation) PractitionerRole |
| Référence de couverture | 0,1 | Référence | Référence à la ressource Coverage |
### Combinaisons de paramètres prises en charge
Les combinaisons de paramètres suivantes sont prises en charge :
+ `memberId`uniquement - Supprime toutes les attributions pour le membre spécifié
+ `memberId`\$1 `providerNpi` - Supprime les attributions pour la combinaison membre-fournisseur spécifique
+ `patientReference`uniquement - Supprime toutes les attributions pour le patient spécifié
+ `patientReference`\$1 `providerReference` - Supprime les attributions pour la combinaison patient-fournisseur spécifique
+ `patientReference`\$1 `providerReference` \$1 `coverageReference` - Supprime l'attribution spécifique en fonction du patient, du fournisseur et de la couverture
## Exemple de requête
```
{
"resourceType": "Parameters",
"parameter": [
{
"name": "patientReference",
"valueReference": {
"reference": "Patient/12345"
}
},
{
"name": "providerReference",
"valueReference": {
"reference": "Practitioner/67890"
}
}
]
}
```
## Réponse
### Réponse réussie
```
{
"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"
}
]
}
```
## Comportement
Exigences relatives au statut
L'opération ne fonctionne que sur les listes d'attribution avec statut `draft` ou `open`
Les listes avec un `final` statut rejetteront l'opération avec une erreur 422
Processus de suppression d'un membre
*Brouillons de listes de statut* : les membres sont marqués comme inactifs (`inactive: true`) et leur `changeType` extension est mise à jour pour `changed`
*Listes de statut ouvertes* : comportement similaire à celui du statut des brouillons
*Listes de statut final* : l'opération est rejetée
Validation
Les références sont validées pour garantir leur existence dans la HealthLake banque de données
Si l'identifiant et la référence sont fournis pour le même type de ressource, ils doivent correspondre à la même ressource
Les combinaisons de paramètres sont validées selon les modèles pris en charge
## Gestion des erreurs
### Réponses aux erreurs courantes
Ressource introuvable (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"]
}
]
}
```
État final de la liste d'attribution (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"]
}
]
}
```
Opération non valide (400)
Renvoyé lorsque les combinaisons de paramètres ne sont pas valides ou sont mal formées.
Plusieurs résultats trouvés (412)
Renvoyé lorsque les paramètres fournis correspondent à plusieurs membres de la liste d'attribution.
```
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "processing",
"diagnostics": "Multiple members found matching the criteria"
}
]
}
```
## Bonnes pratiques
+ *Utiliser des paramètres spécifiques* : Dans la mesure du possible, utilisez la combinaison de paramètres la plus spécifique pour éviter les suppressions involontaires
+ État de *la liste de vérification : vérifiez l'état* de la liste d'attribution avant de tenter de le supprimer
+ *Gérez les erreurs avec élégance* : implémentez une gestion des erreurs appropriée pour toutes les conditions d'erreur possibles
+ *Valider les références* : assurez-vous que toutes les ressources référencées existent avant de faire la demande
# Supprimer les ressources du compartiment réservé aux patients grâce à `$purge`
AWS HealthLake soutient l'`$purge`opération, permettant la suppression permanente de toutes les ressources présentes dans le compartiment du patient. Cette opération est particulièrement utile lorsque vous devez :
+ Supprimer toutes les données associées à un patient
+ Respectez les demandes de suppression des données des patients
+ Gérer le cycle de vie des données des patients
+ Effectuez un nettoyage complet des dossiers des patients
## Usage
L'`$purge`opération peut être invoquée sur les ressources du patient :
```
POST [base]/Patient/[ID]/$purge?deleteAuditEvent=true
```
## Parameters
| Paramètre | Type | Obligatoire | Par défaut | Description |
| --- | --- | --- | --- | --- |
| deleteAuditEvent | booléen | Non | false | Lorsque c'est vrai, supprime les événements d'audit associés |
| \$1since | chaîne | Non | Heure de création de la banque de données | Une fois saisie, sélectionne l'heure limite de début pour rechercher les ressources en fonction de leur heure de dernière modification. Ne peut pas être utilisé avec le début ou la fin |
| start | chaîne | Non | Heure de création de la banque de données | Une fois saisie, sélectionne l'heure limite pour rechercher les ressources en fonction de leur heure de dernière modification. Peut être utilisé avec extrémité |
| end | chaîne | Non | Heure de soumission des offres d'emploi | Une fois saisi, sélectionne l'heure limite de fin pour rechercher les ressources en fonction de leur heure de dernière modification |
## Exemples
**Exemple de requête**
```
POST [base]/Patient/example-patient/$purge?deleteAuditEvent=true
```
**Exemple de réponse**
```
{
"resourceType": "OperationOutcome",
"id": "purge-job",
"issue": [
{
"severity": "information",
"code": "informational",
"diagnostics": "Purge job started successfully. Job ID: 12345678-1234-1234-1234-123456789012"
}
]
}
```
## Statut de la tâche
Pour vérifier l'état d'une tâche de purge :
```
GET [base]/$purge/[jobId]
```
L'opération renvoie les informations relatives à l'état de la tâche :
```
{
"datastoreId": "36622996b1fcecb7e12ee2ee085308d3",
"jobId": "3dd1c7a5b6c0ef8c110f566eb87e2ef9",
"status": "COMPLETED",
"submittedTime": "2025-10-31T18:43:21.822Z"
}
```
## Comportement
L'`$purge`opération :
1. Processus asynchrones pour gérer plusieurs ressources
1. Maintient les transactions ACID pour garantir l'intégrité des données
1. Fournit un suivi de l'état des tâches avec le nombre de ressources supprimées
1. Supprime définitivement toutes les ressources du compartiment du patient
1. Inclut un enregistrement d'audit complet des activités de suppression
1. Supporte la suppression sélective des événements d'audit
## Journalisation des audits
L'`$purge`opération est enregistrée sous les noms Start FHIRBulk DeleteJob et Describe FHIRBulk DeleteJob avec des informations détaillées sur l'opération.
## Limitations
+ Les ressources purgées n'apparaîtront pas dans les réponses de recherche
+ Les ressources en cours de purge peuvent être temporairement inaccessibles pendant le traitement
+ Toutes les ressources du compartiment patient sont définitivement supprimées
# `$questionnaire-package`Opération FHIR pour HealthLake
L'`$questionnaire-package`opération récupère un ensemble complet contenant un questionnaire FHIR et toutes ses dépendances nécessaires au rendu et au traitement du questionnaire. Cette opération met en œuvre le [guide de mise en œuvre des modèles et règles de documentation Da Vinci (DTR)](https://hl7.org/fhir/us/davinci-dtr/OperationDefinition-questionnaire-package.html), permettant le rendu dynamique des formulaires pour les exigences en matière de documentation dans les flux de travail du secteur de la santé.
## Comment ça marche
+ **Demande** : vous envoyez des paramètres identifiant le ou les questionnaires nécessaires, ainsi que la couverture et le contexte de la commande
+ **Récupérer** : HealthLake rassemble le questionnaire et toutes les dépendances (ValueSetsbibliothèques CQL, etc.)
+ **Package** : Toutes les ressources sont regroupées dans un format standardisé
+ **Répondre** : vous recevez un package complet prêt pour le rendu et la collecte de données
**Cas d'utilisation**
+ **Documentation d'autorisation préalable** : Collectez les informations cliniques requises pour les demandes d'autorisation préalable
+ **Exigences de couverture** : Rassemblez la documentation nécessaire pour satisfaire aux exigences de couverture du payeur
+ **Clinical Data Exchange** : structurez les données cliniques pour les soumettre aux payeurs
+ **Formulaires dynamiques** : créez des questionnaires avec des données préremplies sur les patients et une logique conditionnelle
## Point de terminaison d’API
```
POST /datastore/{datastoreId}/r4/Questionnaire/$questionnaire-package
Content-Type: application/fhir+json
```
## Paramètres de demande
### Paramètres d’entrée
Le corps de la demande doit contenir une ressource de paramètres FHIR avec les paramètres suivants :
| Paramètre | Type | Cardinalité | Description |
| --- | --- | --- | --- |
| coverage | Couverture | 1.. \$1 (Obligatoire) | Ressource (s) de couverture pour établir le membre et couverture pour la documentation |
| questionnaire | canonial | 0.. \$1 | URL (s) canoniques pour un ou plusieurs questionnaires spécifiques à renvoyer (peut inclure la version) |
| order | Ressource | 0.. \$1 | Commandez des ressources (DeviceRequest, ServiceRequest, MedicationRequest, Encounter, Appointment) pour établir le contexte |
| changedSince | dateTime | 0,1 | Le cas échéant, ne renvoie que les ressources modifiées après cet horodatage |
### Règles de validation des paramètres
**Au moins UN des éléments suivants doit être fourni** (en plus de ce qui est obligatoire`coverage`) :
+ Un ou plusieurs `questionnaire` canoniques URLs
+ Une ou plusieurs `order` ressources
**Combinaisons de demandes valides :**
+ `coverage` \$1 `questionnaire`
+ `coverage` \$1 `order`
+ `coverage` \$1 `questionnaire` \$1 `order`
## Exemple de demande
```
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"
}
]
}
```
## Format de la réponse
### Réponse positive (200 OK)
L'opération renvoie une ressource de paramètres FHIR contenant un ou plusieurs **Package Bundles**. Chaque Package Bundle inclut :
| Type d'entrée | Cardinalité | Description |
| --- | --- | --- |
| Questionnaire | 1 | Le questionnaire à rendre |
| QuestionnaireResponse | 0,1 | Réponse préremplie ou partiellement complétée (le cas échéant) |
| d'outils | 0.. \$1 | Bibliothèques CQL contenant une logique de pré-peuplement et une logique conditionnelle |
| ValueSet | 0.. \$1 | Étendu ValueSets (pour les choix de réponses avec moins de 40 extensions) |
**Example Exemple de réponse**
```
{
"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"
}
}]
}
}
]
}
```
## Flux de travail des opérations
**Comment HealthLake traite-t-on votre demande**
Lorsque vous appelez`$questionnaire-package`, HealthLake exécute les étapes suivantes :
1. **Identifier le patient et le payeur** : extrait le patient et l'organisme d'assurance de vos `coverage` paramètres.
1. **Trouvez le bon questionnaire** :
+ **Avec `questionnaire`** **paramètre** : utilise l'URL canonique que vous avez fournie
+ **Avec `order`** **paramètre** : fait correspondre le code de commande (CPT/HCPCS/LOINC) et le payeur pour trouver le questionnaire approprié
1. **Collecter les dépendances** : récupère automatiquement tout ce qui est nécessaire pour afficher le questionnaire :
+ **Bibliothèques CQL** - Logique pour les questions de prépopulation et les questions conditionnelles
+ **ValueSets**- Choix de réponses (automatiquement étendus si <40 options)
+ **QuestionnaireResponse**- Toutes les réponses existantes en cours ou terminées
1. **Emballez le tout ensemble** :
+ Regroupe toutes les ressources (chaque ressource n'est incluse qu'une seule fois)
+ Filtre par `changedSince` horodatage s'il est fourni
+ Ajoute des avertissements `Outcome` si des ressources sont manquantes
**Résultat** : un package complet et autonome prêt pour le rendu.
## Réponses d'erreur
### 400 Requête erronée
Renvoyé en cas d'échec de la validation de la demande.
```
{
"resourceType": "OperationOutcome",
"issue": [{
"severity": "error",
"code": "required",
"details": {
"text": "At least one of 'questionnaire' or 'order' must be provided along with 'coverage'"
}
}]
}
```
### 424 Dépendance défaillante
Renvoyé lorsqu'une ressource dépendante ne peut pas être récupérée.
```
{
"resourceType": "OperationOutcome",
"issue": [{
"severity": "warning",
"code": "not-found",
"details": {
"text": "Referenced Library 'http://example.org/fhir/Library/missing-library' could not be retrieved"
}
}]
}
```
### 401 Accès non autorisé
Renvoyé lorsque les informations d'authentification sont manquantes ou non valides.
### 403 Forbidden
Renvoyé lorsque l'utilisateur authentifié n'est pas autorisé à accéder aux ressources demandées.
### 406 Non acceptable
Renvoyé lorsque le type de contenu demandé ne peut pas être fourni.
### 409 – Conflit
Renvoyé en cas de conflit de version ou de simultanéité.
### 410 Disparus
Renvoyé lorsque la ressource demandée a été définitivement supprimée.
### 429 Trop de demandes
Renvoyé lorsque les limites de débit sont dépassées.
### 500 Erreur de serveur interne
Renvoyé lorsqu'une erreur de serveur inattendue se produit.
### 501 Non implémenté
Renvoyé lorsque l'opération demandée n'est pas encore implémentée.
## Règles de validation
### Validation des entrées
+ `coverage`le paramètre est **obligatoire** (1.. \$1 cardinalité)
+ Au moins l'un `questionnaire` des éléments `order` suivants doit être fourni
+ Toutes les ressources de couverture doivent être des ressources FHIR valides
+ Toutes les ressources de la commande doivent être des ressources FHIR valides
+ Canonical URLs doit être correctement formaté
+ `changedSince`doit être un DateTime ISO 8601 valide
### QuestionnaireResponse validation
+ `status`doit être approprié (`in-progress`,`completed`,`amended`)
+ La structure doit correspondre au questionnaire référencé
+ `basedOn`doit faire référence à des ressources de commande valides
+ `subject`doit faire référence à des ressources valides pour les patients
### Déduplication des ressources
+ Chaque ressource n'apparaît qu'une seule fois dans le bundle
+ Exception : différentes versions de la même ressource peuvent toutes deux être incluses
+ Les ressources sont identifiées par leur URL canonique et leur version
## Spécifications de performance
| Métrique | Spécification de |
| --- | --- |
| Limite du nombre de ressources | 500 ressources par bundle |
| Limite de taille du bundle | 5 Mo maximum |
## Autorisations requises
Pour utiliser l'`$questionnaire-package`opération, assurez-vous que votre rôle IAM possède les éléments suivants :
+ `healthlake:QuestionnairePackage`- Pour appeler l'opération
+ `healthlake:ReadResource`- Pour récupérer le questionnaire et les ressources dépendantes
+ `healthlake:SearchWithPost`- Pour rechercher QuestionnaireResponse des ressources connexes
**SMART sur les oscilloscopes FHIR**
**Étendue minimale requise :**
+ **SMART version 1** : `user/Questionnaire.read user/Library.read user/ValueSet.read user/QuestionnaireResponse.read`
+ **SMART v2** : `user/Questionnaire.rs user/Library.rs user/ValueSet.rs user/QuestionnaireResponse.rs`
## Remarques de mise en œuvre importantes
### Stratégie de récupération des ressources
**Priorité d'identification du questionnaire :**
+ **URL canonique** (si le `questionnaire` paramètre est fourni) - Priorité la plus élevée
+ **Analyse de la commande** (si `order` le paramètre est fourni) :
+ Associez les codes de commande (CPT, HCPCS, LOINC) aux politiques médicales du payeur
+ Utilisez le payeur de couverture pour filtrer les questionnaires spécifiques au payeur
+ Tenez compte des codes de motif pour un contexte supplémentaire
### Résolution des dépendances
**Bibliothèques CQL :**
+ Récupéré via l'`cqf-library`extension sur les ressources du questionnaire
+ Récupère récursivement les bibliothèques dépendantes via le type `Library.relatedArtifact` `depends-on`
+ Toutes les dépendances de bibliothèque sont incluses dans le package
**ValueSets:**
+ Développé automatiquement s'ils contiennent moins de 40 concepts
+ ValueSets Les plus grands sont inclus sans extension
+ ValueSets référencées à la fois dans le questionnaire et les ressources de la bibliothèque sont incluses
### QuestionnaireResponse pré-population
L'opération peut renvoyer un fichier QuestionnaireResponse avec des données préremplies lorsque :
+ Une réponse existante en cours ou terminée est trouvée
+ La logique CQL des bibliothèques associées peut extraire des données des dossiers des patients
+ La réponse est liée à la commande et à la couverture pertinentes
**Critères de recherche pour QuestionnaireResponse :**
| Paramètre de recherche | Parcours FHIR | Description |
| --- | --- | --- |
| based-on | QuestionnaireResponse.basedOn | Liens vers ServiceRequest ou CarePlan |
| patient | QuestionnaireResponse.subject | Le patient qui est le sujet |
| questionnaire | QuestionnaireResponse.questionnaire | Le questionnaire auquel il est répondu |
### Filtrage des ressources modifié
Lorsque le `changedSince` paramètre est fourni :
+ Seules les ressources modifiées **après** l'horodatage spécifié sont incluses
+ Si aucune ressource n'a changé, retourne `200 OK` avec un package vide
+ Utile pour les mises à jour incrémentielles et les stratégies de mise en cache
+ La comparaison des horodatages utilise le champ de ressources `meta.lastUpdated`
### Forfaits groupés multiples
L'opération peut renvoyer **plusieurs Package Bundles** lorsque :
+ Plusieurs questionnaires sont demandés via Canonical URLs
+ Les commandes multiples nécessitent des questionnaires différents
+ Différentes versions du même questionnaire sont applicables
Chaque Package Bundle est autonome avec toutes les dépendances nécessaires.
## Cas d’utilisation courants
### Cas d'utilisation 1 : documentation relative à l'autorisation préalable
**Scénario** : Un fournisseur doit recueillir de la documentation pour une autorisation préalable d'oxygénothérapie à domicile.
```
{
"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"
}]
}
}
}
]
}
```
**Résultat** : renvoie un colis contenant le questionnaire d'oxygénothérapie, prérempli avec les données vitales du patient et les codes de diagnostic du dossier médical électronique.
### Cas d'utilisation 2 : récupérer une version spécifique du questionnaire
**Scénario** : un fournisseur a besoin d'une version spécifique d'un questionnaire pour se conformer.
```
{
"resourceType": "Parameters",
"parameter": [
{
"name": "coverage",
"resource": { /* Coverage resource */ }
},
{
"name": "questionnaire",
"valueCanonical": "http://example.org/fhir/Questionnaire/dme-request|3.1.0"
}
]
}
```
**Résultat** : renvoie exactement la version 3.1.0 du questionnaire de demande DME avec toutes les dépendances.
### Cas d'utilisation 3 : Vérifier les mises à jour
**Scénario** : un fournisseur souhaite vérifier si des ressources du questionnaire ont été mises à jour depuis la dernière extraction.
```
{
"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"
}
]
}
```
**Résultat** : renvoie uniquement les ressources qui ont été modifiées après le 1er mars 2024, ou un package vide si rien n'a changé.
### Cas d'utilisation 4 : commandes multiples
**Scénario** : un fournisseur soumet plusieurs demandes de service qui peuvent nécessiter différents questionnaires.
```
{
"resourceType": "Parameters",
"parameter": [
{
"name": "coverage",
"resource": { /* Coverage resource */ }
},
{
"name": "order",
"resource": { /* ServiceRequest for imaging */ }
},
{
"name": "order",
"resource": { /* ServiceRequest for DME */ }
}
]
}
```
**Résultat** : renvoie plusieurs Packages groupés, un pour chaque questionnaire applicable.
## Intégration avec d'autres Da Vinci IGs
### Découverte des exigences de couverture (CRD)
**Intégration du flux de travail :**
+ Le fournisseur commande un service dans son dossier électronique
+ Feux à l'hameçon CRD, vérification des exigences de couverture
+ Le payeur répond en indiquant que la documentation est nécessaire
+ Le fournisseur appelle `$questionnaire-package` pour récupérer le formulaire de documentation
+ Le fournisseur remplit le questionnaire
+ La documentation est soumise via PAS ou CDex
### Support d'autorisation préalable (PAS)
**Intégration du flux de travail :**
+ `$questionnaire-package`À utiliser pour récupérer les exigences en matière de documentation
+ Complétez le QuestionnaireResponse avec les données cliniques requises
+ Soumettez l'autorisation préalable `Claim/$submit` en utilisant le QuestionnaireResponse
+ Vérifiez le statut à l'aide de `Claim/$inquire`
### Échange de données cliniques (CDex)
**Intégration du flux de travail :**
+ Le payeur demande des documents supplémentaires pour une réclamation
+ Le fournisseur utilise `$questionnaire-package` pour récupérer le formulaire de collecte de données structuré
+ Le fournisseur complète le QuestionnaireResponse
+ La documentation est soumise au payeur via un flux de travail de CDex pièces jointes
## Guide de dépannage
### Problème : aucun questionnaire n'a été renvoyé
**Causes possibles :**
+ L'URL canonique ne correspond à aucun questionnaire du magasin de données
+ Le code de commande ne correspond à aucun questionnaire de la police médicale du payeur
+ Le payeur de couverture n'a pas de questionnaires associés
**Solutions :**
+ Vérifiez que l'URL canonique est correcte et que le questionnaire existe
+ Vérifiez que les codes de commande (CPT/HCPCS) sont correctement spécifiés
+ Vérifiez que l'organisation payeuse a configuré des questionnaires
### Problème : dépendances manquantes dans le package
**Causes possibles :**
+ Bibliothèque référencée ou ValueSet n'existe pas dans le magasin de données
+ Les références de bibliothèque sont cassées ou incorrectes
+ ValueSet échec de l'extension
**Solutions :**
+ Vérifiez le `Outcome` paramètre pour les avertissements concernant les ressources manquantes
+ Vérifiez que toutes les ressources référencées existent dans votre magasin de données
+ Assurez-vous qu' ValueSet URLs ils sont corrects et résolvables
### Problème : Package vide avec ChangedSince
**Causes possibles :**
+ Ce comportement est attendu : aucune ressource n'a été modifiée depuis l'horodatage spécifié
**Solutions :**
+ Utiliser la version mise en cache du package
+ Supprimer `changedSince` le paramètre pour récupérer le package complet
### Problème : QuestionnaireResponse Non prérempli
**Causes possibles :**
+ Aucun objet existant n' QuestionnaireResponse a été trouvé
+ La logique de la bibliothèque CQL n'a pas pu extraire les données requises
+ Les données du patient sont manquantes ou incomplètes
**Solutions :**
+ On peut s'y attendre, car tous les questionnaires ne reposent pas sur une logique de pré-population
+ Vérifiez que les données du patient existent dans le magasin de données
+ Vérifiez la logique de la bibliothèque CQL pour connaître les exigences en matière d'extraction de données
## Bonnes pratiques
### 1. Utiliser Canonical URLs avec les versions
Spécifiez toujours les numéros de version lorsque vous demandez des questionnaires spécifiques :
```
{
"name": "questionnaire",
"valueCanonical": "http://example.org/fhir/Questionnaire/dme|2.1.0"
}
```
**Pourquoi** : Garantit la cohérence et empêche les changements inattendus lors de la mise à jour des questionnaires.
### 2. Tirez parti de ChangedSince pour améliorer les performances
Pour les questionnaires fréquemment consultés, utilisez `changedSince` pour minimiser le transfert de données :
```
{
"name": "changedSince",
"valueDateTime": "2024-03-10T15:30:00Z"
}
```
**Pourquoi** : réduit la latence et l'utilisation de la bande passante en ne récupérant que les ressources mises à jour.
### 3. Incluez des informations complètes sur la couverture
Fournissez des informations complètes sur la couverture afin de garantir une sélection correcte du questionnaire :
```
{
"name": "coverage",
"resource": {
"resourceType": "Coverage",
"beneficiary": { "reference": "Patient/123" },
"payor": [{ "reference": "Organization/payer-abc" }],
"class": [{ /* Group/plan information */ }]
}
}
```
**Pourquoi** : aide à HealthLake identifier les questionnaires et les exigences spécifiques au payeur.
## Opérations liées
+ `Claim/$submit`- Soumettre les demandes d'autorisation préalable avec la documentation complète
+ `Claim/$inquire`- Vérifier l'état des autorisations antérieures soumises
+ `ValueSet/$expand`- Élargir ValueSets pour les choix de réponses
# `$submit`Opération FHIR pour HealthLake
L'`$submit`opération vous permet de soumettre électroniquement des demandes d'autorisation préalable aux payeurs pour approbation. Cette opération met en œuvre le [guide de mise en œuvre du Da Vinci Prior Authorization Support (PAS)](https://hl7.org/fhir/us/davinci-pas/), fournissant un flux de travail standardisé basé sur le FHIR pour les soumissions d'autorisations préalables.
## Comment ça marche
+ **Soumettre** : vous envoyez un bundle FHIR contenant votre demande d'autorisation préalable et les données cliniques à l'appui
+ **Valider** : HealthLake valide la soumission par rapport aux exigences du PAS
+ **Persister** : toutes les ressources sont stockées dans votre magasin HealthLake de données
+ **Répondre** : vous recevez une réponse immédiate avec le statut « en file d'attente »
+ **Processus** : La décision d'autorisation est traitée de manière asynchrone par le payeur
## Point de terminaison d’API
```
POST /datastore/{datastoreId}/r4/Claim/$submit
Content-Type: application/fhir+json
```
## Structure de la demande
### Exigences relatives au bundle
Votre demande doit être une ressource FHIR Bundle contenant :
+ **Bundle.type** : Doit être `"collection"`
+ **Bundle.entry** : doit contenir exactement **une** ressource Claim avec `use = "preauthorization"`
+ **Ressources référencées** : Toutes les ressources référencées par la réclamation doivent être incluses dans le bundle
### Ressources requises
| Ressource | Cardinalité | Profil | Description |
| --- | --- | --- | --- |
| Réclamation | 1 | Réclamation PAS | La demande d'autorisation préalable |
| Patient | 1 | Patient PAS | Informations démographiques sur les patients |
| Organisation (assureur) | 1 | Assureur PAS | Compagnie d'assurance |
| Organisation (fournisseur) | 1 | Demandeur PAS | Prestataire de santé soumettant la demande |
| Couverture | 1 ou plus | Couverture PAS | Détails de la couverture d'assurance |
### Ressources facultatives
| Ressource | Cardinalité | Profil | Description |
| --- | --- | --- | --- |
| Praticien | 0 ou plus | Praticien PAS | Praticiens de santé |
| PractitionerRole | 0 ou plus | PAS PractitionerRole | Rôles des praticiens |
| ServiceRequest | 0 ou plus | PAS ServiceRequest | Services médicaux demandés |
| DeviceRequest | 0 ou plus | PAS DeviceRequest | Dispositifs médicaux demandés |
| MedicationRequest | 0 ou plus | PAS MedicationRequest | Médicaments demandés |
| DocumentReference | 0 ou plus | PAS DocumentReference | Documentation clinique à l'appui |
## Exemple de demande
```
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"
}
}]
}
```
## Format de la réponse
### Réponse positive (200 OK)
Vous recevrez un pack de réponses PAS contenant :
+ **ClaimResponse**avec `outcome: "queued"` et `status: "active"`
+ Toutes les ressources originales de votre demande
+ Horodatage confirmant la réception
```
{
"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"
}
}]
}
```
## Réponses d'erreur
### 400 Requête erronée
Renvoyé lorsque le format de demande n'est pas valide ou est mal formé.
```
{
"resourceType": "OperationOutcome",
"issue": [{
"severity": "error",
"code": "invalid",
"diagnostics": "The provided payload was invalid and could not be parsed correctly."
}]
}
```
### 412 – Échec de condition préalable
Renvoyé lorsque la même demande d'autorisation préalable a déjà été soumise (envoi dupliqué détecté).
```
{
"resourceType": "OperationOutcome",
"issue": [{
"severity": "error",
"code": "processing",
"diagnostics": "PreAuth Claim already exists"
}]
}
```
**Idempotence**
L'`$submit`opération est idempotente. Le fait de soumettre la même demande plusieurs fois ne créera pas de demandes d'autorisation préalable dupliquées. Au lieu de cela, vous recevrez un message d'erreur 412 vous demandant de `$inquire` vérifier le statut de votre envoi initial.
### 422 Entité non traitable
Renvoyé en cas d'échec de la validation FHIR.
```
{
"resourceType": "OperationOutcome",
"issue": [{
"severity": "error",
"code": "required",
"diagnostics": "Bundle contains more than one preauthorization claim"
}]
}
```
## Règles de validation
HealthLake effectue une validation complète de votre soumission :
### Validation du bundle
+ Doit être conforme au profil du bundle de demandes PAS
+ `Bundle.type`doit être `"collection"`
+ Peut contenir plusieurs ressources de réclamation
+ Cependant, il doit contenir exactement une ressource Claim avec une utilisation préautorisée
+ Et cette ressource Claim doit être la première entrée du bundle
+ Toutes les ressources référencées doivent être incluses dans le bundle
### Validation des réclamations
+ Doit être conforme au profil de réclamation PAS
+ `Claim.use`doit être `"preauthorization"`
+ Champs obligatoires : `patient``insurer`,`provider`,`created`, `priority`
+ Les identifiants commerciaux doivent être présents et valides
### Validation des ressources
+ Toutes les ressources doivent être conformes à leurs profils PAS respectifs
+ Les ressources de soutien requises doivent être présentes (patient, couverture, organisation)
+ Les références croisées doivent être valides et résolvables dans le bundle
## Spécifications de performance
| Métrique | Spécification de |
| --- | --- |
| Limite de taille du bundle | 5 Mo maximum |
| Limite du nombre de ressources | 500 ressources par bundle |
## Autorisations requises
Pour utiliser l'`$submit`opération, on peut utiliser AWS Sigv4 ou SMART sur FHIR :
+ Assurez-vous que votre rôle IAM comporte : `healthlake:SubmitPreAuthClaim` - Pour appeler l'opération
**SMART sur les oscilloscopes FHIR**
**Étendue minimale requise :**
+ **SMART version 1** : `user/Claim.write & .write`
+ **SMART v2** : `user/Claim.c & .c or system/*.*`
## Remarques de mise en œuvre importantes
### Persistance des ressources
+ Toutes les entrées du bundle sont conservées en tant que ressources FHIR individuelles dans votre magasin de données
+ Les produits fournis par le client IDs sont conservés lorsqu'ils sont fournis
+ L'historique des versions est conservé à des fins d'audit
+ La détection des doublons prévient les conflits de ressources
### Comportement de traitement
+ Chaque soumission valide donne lieu à exactement une ClaimResponse avec `"queued"` résultat
+ Les soumissions non valides renvoient 400 ou 422 codes d'état avec des informations d'erreur détaillées
+ Les erreurs du système renvoient les codes d'état 5xx appropriés
+ Toutes les soumissions réussies renvoient le statut 200 avec un statut en attente ClaimResponse
### Exigences relatives au bundle
+ `Bundle.entry.fullUrl`les valeurs doivent être soit au format REST, URLs soit `"urn:uuid:[guid]"` au format
+ Toutes les soumissions GUIDs doivent être uniques (sauf pour les mêmes instances de ressources)
+ Les ressources référencées doivent exister dans le bundle ou être résolvables
## Opérations liées
+ `Claim/$inquire`- Vérifier le statut d'une demande d'autorisation préalable soumise
+ `Patient/$everything`- Récupérez les données complètes du patient pour le contexte de l'autorisation préalable
# Validation des ressources FHIR avec `$validate`
AWS HealthLake prend désormais en charge le `$validate` fonctionnement des ressources FHIR, ce qui vous permet de valider une ressource par rapport à la spécification FHIR et de vérifier sa conformité à un profil spécifié ou à une définition de ressource de base sans effectuer d'opérations de stockage. Cette opération est particulièrement utile lorsque vous devez :
+ Valider les exigences de conformité du CMS FHIR
+ Testez les ressources avant de les utiliser en production
+ Fournir des commentaires de validation en temps réel lorsque les utilisateurs modifient les données cliniques
+ Réduisez les soumissions de données non valides pour la création et la mise à jour APIs
## Usage
L'`$validate`opération peut être invoquée sur les ressources FHIR à l'aide des méthodes POST :
**Opérations prises en charge**
```
POST [base]/[type]/[id]/$validate
POST [base]/[type]/$validate
```
## Charges utiles prises en charge
**Ressource de paramètres**
HealthLake prend en charge les `$validate` paramètres FHIR suivants :
| Paramètre | Type | Obligatoire | Description |
| --- | --- | --- | --- |
| resource | Ressource | Oui | La ressource à valider |
| profile | canonial | Non | URL canonique du profil par rapport auquel valider |
| mode | code | Non | Mode de validation :create, ou update |
**Ressource directe avec paramètres de requête**
| Paramètre | Type | Obligatoire | Description |
| --- | --- | --- | --- |
| profile | canonial | Non | URL canonique du profil par rapport auquel valider |
| mode | code | Non | Mode de validation :create, ou update |
## Exemples
**Demande POST pour une ressource avec ID et paramètres (charge utile)**
```
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"
}
]
}
```
**Demande POST pour le type de ressource et la charge utile des paramètres**
```
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"
}
]
}
```
**Demande de ressource POST avec identifiant et charge utile directe de la ressource**
```
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"
}
```
**Demande POST pour le type de ressource et la charge utile directe de la ressource**
```
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"
}
```
**Exemple de réponse**
L'opération renvoie une OperationOutcome ressource avec les résultats de validation :
```
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "information",
"code": "informational",
"diagnostics": "Validation successful"
}
]
}
```
**Exemple de réponse avec erreurs de validation**
```
{
"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"
]
}
]
}
```
## Comportement
L'`$validate`opération :
1. Valide la ressource par rapport à la spécification FHIR et à la définition de la ressource de base
1. Vérifie la conformité aux profils spécifiés lorsque le `profile` paramètre est fourni
1. Valide en fonction du mode spécifié (`create`ou`update`)
1. Renvoie les résultats de validation détaillés, y compris les erreurs, les avertissements et les messages d'information
1. N'effectue aucune opération de stockage - validation uniquement
1. Renvoie HTTP 200 OK lorsque la validation peut être effectuée, que des problèmes de validation soient détectés ou non
## Modes de validation
+ **créer** : valide la ressource comme si elle était en cours de création (nouvelle ressource)
+ **mise à jour** : valide la ressource comme si elle était mise à jour (ressource existante)
## Gestion des erreurs
L'opération renvoie :
+ 200 OK : La validation a été effectuée avec succès (quel que soit le résultat de la validation)
+ 400 Demande incorrecte : format ou paramètres de demande non valides
+ 404 Introuvable : type de ressource ou profil introuvable
Pour plus d'informations sur les spécifications de `$validate` fonctionnement, consultez la documentation des [ressources `$validate` FHIR R4](https://www.hl7.org/fhir/R4/operation-resource-validate.html).
# Référence de conformité pour AWS HealthLake
AWS HealthLake fournit des fonctionnalités conçues pour vous aider à suivre et à signaler l'utilisation des API conformément aux exigences d'interopérabilité des CMS (Centers for Medicare & Medicaid Services). Ces fonctionnalités vous permettent de classer les transactions d'API par catégories mandatées par le CMS et de capturer automatiquement les statistiques d'utilisation à des fins de rapports de conformité.
**Comprendre vos responsabilités en matière de conformité**
L'utilisation AWS HealthLake de points de terminaison d'interopérabilité avec le CMS **ne suffit pas à elle seule pour garantir** la conformité avec le CMS. Vous êtes responsable de :
Associer correctement vos flux de travail d'API aux points de terminaison de la catégorie CMS appropriée en fonction de vos cas d'utilisation spécifiques et de vos obligations réglementaires
Mettre en œuvre des contrôles d'authentification et d'autorisation appropriés qui répondent aux exigences du CMS
Veiller à ce que vos ressources FHIR et vos échanges de données soient conformes aux réglementations CMS applicables et aux guides de mise en œuvre
Configuration et surveillance des CloudWatch indicateurs pour répondre à vos besoins en matière de rapports de conformité
Comprendre quelles règles du CMS s'appliquent à votre organisation et mettre en œuvre les contrôles techniques et opérationnels appropriés
AWS HealthLake fournit l'infrastructure et les outils nécessaires pour soutenir vos efforts de mise en conformité, mais vous devez utiliser ces fonctionnalités de manière appropriée en fonction de vos exigences réglementaires spécifiques. Le simple fait de router les appels d'API via ces points de terminaison ne rend pas automatiquement votre application conforme aux réglementations du CMS.
**Topics**
+ [SCG](reference-compliance-cms.md)
# Fonctionnalités de conformité du CMS
AWS HealthLake fournit des fonctionnalités pour vous aider à répondre aux exigences d'interopérabilité et de conformité des CMS (Centers for Medicare & Medicaid Services). Ces fonctionnalités vous permettent de suivre l'utilisation des API par catégorie de CMS et de signaler ensuite les mesures d'utilisation à des fins de conformité.
**Topics**
+ [Points de terminaison d'interopérabilité CMS](#cms-interoperability-endpoints)
+ [CloudWatch Mesures améliorées pour la conformité aux CMS](#cms-cloudwatch-metrics)
## Points de terminaison d'interopérabilité CMS
### Présentation de
HealthLake fournit quatre points de terminaison d'interopérabilité du CMS qui correspondent aux catégories d'API mandatées par le CMS. L'URL de base sous-jacente de votre HealthLake banque de données ne change pas. Ces points de terminaison fournissent simplement un moyen de classer et de suivre vos appels d'API à des fins de reporting CMS.
### Objectif
L'objectif principal de ces points de terminaison d'interopérabilité est de permettre aux clients de :
+ **Suivez facilement les** transactions d'API par catégorie de CMS
+ **Signalez automatiquement** les mesures d'utilisation pour garantir la conformité au CMS
+ **Maintenir** les flux de travail FHIR existants avec un minimum de modifications
Tous les appels d'API fonctionnent de la même manière, que vous utilisiez le point de terminaison d'interopérabilité ou le point de terminaison FHIR standard. La seule différence réside dans la manière dont les transactions sont classées dans les métriques. CloudWatch
### Points de terminaison d'interopérabilité CMS pris en charge
| Catégorie CMS | Endpoint d'interopérabilité | Exemple d'utilisation |
| --- | --- | --- |
| Accès pour les patients | /patientaccess/v2/r4 | baseURL/patientaccess/v2/r4/Patient/123 |
| Accès du fournisseur | /provideraccess/v2/r4 | baseURL/provideraccess/v2/r4/Observation?patient=123 |
| Payeur à payeur | /payertopayerdx/v2/r4 | baseURL/payertopayerdx/v2/r4/Practitioner/456 |
| Service d'authentification préalable | /priorauthservice/v2/r4 | baseURL/priorauthservice/v2/r4/ExplanationOfBenefit?patient=789 |
### Comment fonctionnent les points de terminaison d'interopérabilité
**Appel HealthLake d'API standard :**
```
baseURL/resourceType/[id]
baseURL/resourceType?[parameters]
```
**Avec CMS Interoperability Endpoint :**
```
baseURL/interoperability-endpoint/resourceType/[id]
baseURL/interoperability-endpoint/resourceType?[parameters]
```
Le chemin du point de terminaison d'interopérabilité est simplement inséré entre votre URL de base et le type de ressource. Après le chemin du point de terminaison d'interopérabilité, tout reste exactement le même que celui de vos appels d'API actuels.
### Exemples d’utilisation
#### Exemple 1 : API d'accès aux patients
**Appel d'API en cours (fonctionne toujours) :**
```
curl -X GET \
https://healthlake.us-east-1.amazonaws.com/datastore/abc123/r4/Patient/123 \
-H "Authorization: Bearer " \
-H "Content-Type: application/fhir+json"
```
**Avec le point de terminaison d'interopérabilité Patient Access (pour le suivi du 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"
```
**Points clés :**
+ L'URL de base reste la suivante : `https://healthlake.us-east-1.amazonaws.com/datastore/abc123`
+ Point de terminaison d'interopérabilité inséré : `/patientaccess/v2/r4`
+ Le chemin de la ressource est inchangé : `/Patient/123`
+ **Les deux appels renvoient des réponses identiques**
+ L'appel du terminal d'interopérabilité est automatiquement suivi `URIType=patient-access` dans CloudWatch
+ Les opérations POST, PUT, PATCH, DELETE fonctionnent de manière identique.
+ Le corps de la demande reste inchangé.
### Référence de traduction des terminaux
| Endpoint d'interopérabilité | Traduit vers | Catégorie CMS |
| --- | --- | --- |
| baseURL/patientaccess/v2/r4/Patient | baseURL/r4/Patient | Accès pour les patients |
| baseURL/provideraccess/v2/r4/Observation | baseURL/r4/Observation | Accès du fournisseur |
| baseURL/payertopayerdx/v2/r4/Practitioner/456 | baseURL/r4/Practitioner/456 | Data Exchange de payeur à payeur |
| baseURL/priorauthservice/v2/r4/ExplanationOfBenefit?patient=789 | baseURL/r4/ExplanationOfBenefit?patient=789 | Autorisation préalable |
### Remarques importantes
+ **Aucune différence fonctionnelle** : les points de terminaison d'interopérabilité et les points de terminaison FHIR standard renvoient des réponses identiques et prennent en charge des opérations identiques
+ **URL de base inchangée** : le point de terminaison de votre banque de HealthLake données reste le même
+ **Intégration simple** : insérez le chemin du point de terminaison d'interopérabilité entre votre URL de base et le type de ressource
+ **Suivi automatique** : CloudWatch les métriques classent automatiquement les appels par point de terminaison d'interopérabilité utilisé
+ **Rétrocompatible** : les appels d'API existants sans points de terminaison d'interopérabilité continuent de fonctionner normalement
## CloudWatch Mesures améliorées pour la conformité aux CMS
### Présentation de
Lorsque vous utilisez les points de terminaison d'interopérabilité du CMS, émet HealthLake automatiquement des CloudWatch métriques améliorées avec des dimensions supplémentaires pour répondre aux exigences de reporting du CMS. Ces mesures permettent de suivre l'utilisation des API par identité de l'appelant, par application et par type d'URI spécifique au CMS, **sans qu'aucune configuration supplémentaire** ne soit requise.
### Comment ça marche
Lorsque vous effectuez un appel d'API à l'aide d'un point de terminaison d'interopérabilité :
```
# 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.)
```
**Aucun code ou configuration supplémentaire n'est nécessaire.** Il suffit d'utiliser les points de terminaison d'interopérabilité pour que les métriques améliorées soient automatiquement capturées.
**Note**
Pour les magasins de données non intelligents sur FHIR, la `URIType` dimension est toujours capturée, ce qui vous permet de suivre l'utilisation des API par catégorie de CMS. Les `ClientId` dimensions `Sub` et ne sont disponibles que lors de l'utilisation de l'authentification SMART sur FHIR avec des jetons au porteur contenant ces allégations.
### Nouvelles dimensions métriques
Outre les dimensions existantes (`DatastoreId`,,`Operation`)`DatastoreType`, les dimensions suivantes sont automatiquement ajoutées lors de l'utilisation de points de terminaison d'interopérabilité :
| Dimension | Description | Exemple de valeurs | Source |
| --- | --- | --- | --- |
| URIType | Catégorie de conformité du CMS | patient-access, provider-access, payer-to-payer, prior-authorization | Déterminé automatiquement à partir du chemin du terminal d'interopérabilité |
| Sous | Identité de l'appelant | Identifiant de l'utilisateur/de l'entité | Extrait de la réclamation du jeton sub au porteur |
| ClientId | Identifiant de l’application | portal\$1app, ehr\$1system | Extrait de la réclamation du jeton client\$1id au porteur |
### Métriques disponibles
Toutes les HealthLake métriques existantes incluent désormais les dimensions supplémentaires lors de l'utilisation de points de terminaison d'interopérabilité :
+ **CallCount**- Nombre total d'appels d'API
+ **Latence** : temps de réponse de l'API en millisecondes
+ **UserErrors**- Nombre de 4xx erreurs client
+ **SystemErrors**- Nombre de 5xx erreurs de serveur
+ **Throttles** : nombre de demandes limitées
+ **SuccessfulRequests**- Nombre d'appels d'API réussis
### Interrogation de métriques dans CloudWatch
#### CloudWatch Exemple de requête Insights
**Interrogez tous les appels de l'API Patient Access par application :**
```
SELECT SUM(CallCount)
FROM "AWS/HealthLake"
WHERE DatastoreId = '75c1cf9b0d71cd38fec8f7fb317c4c1a'
AND URIType = 'patient-access'
GROUP BY ClientId
```
# Support de référence pour AWS HealthLake
Les documents de référence complémentaires suivants sont disponibles pour AWS HealthLake.
**Note**
Toutes les HealthLake actions natives et tous les types de données sont décrits dans une référence séparée. Pour plus d’informations, consultez la [Référence des API *AWS HealthLake *](https://docs.aws.amazon.com/healthlake/latest/APIReference/).
**Topics**
+ [Points de terminaison et quotas](reference-healthlake-endpoints-quotas.md)
+ [Types de données préchargés](reference-healthlake-preloaded-data-types.md)
+ [Exemples de projets](reference-healthlake-sample-projects.md)
+ [Résolution des problèmes](reference-healthlake-troubleshooting.md)
+ [Travailler avec AWS SDKs](sdk-general-information-section.md)
# AWS HealthLake points de terminaison et quotas
Les rubriques suivantes contiennent des informations sur les points de terminaison de AWS HealthLake service et les quotas.
**Topics**
+ [Points de terminaison de service](#reference-healthlake-endpoints)
+ [Quotas de service](#reference-healthlake-quotas)
## Points de terminaison de service
Un point de terminaison de service est une URL qui identifie un hôte et un port comme point d'entrée d'un service Web. Chaque demande de service web contient un point de terminaison. La plupart AWS des services fournissent des points de terminaison pour des régions spécifiques afin de permettre une connectivité plus rapide. Le tableau suivant répertorie les points de terminaison de service pour AWS HealthLake.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/healthlake/latest/devguide/reference-healthlake-endpoints-quotas.html)
## Quotas de service
Les quotas de service sont définis comme la valeur maximale des ressources, des actions et des éléments de votre AWS compte.
**Note**
Pour les quotas ajustables, vous pouvez demander une augmentation de quota à l'aide de la [console Service Quotas](https://console.aws.amazon.com/servicequotas/). Pour plus d’informations, consultez [Demande d’augmentation de quota](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html) dans le *Guide de l’utilisateur Service Quotas*.
Le débit de l'API Sync Write augmente proportionnellement à la taille de la charge utile, chaque incrément de 1 Ko consommant de la capacité supplémentaire (par exemple, une charge utile de 4 Ko utilise 4 fois la capacité d'écriture). Définissez l'`x-amz-fhir-history-consistency-level`en-tête facultatif pour `strong` doubler la consommation de capacité d'écriture par ressource.
Les ressources contenues dans les bundles suivent les read/write limites standard basées sur une taille de charge utile de 1 Ko. Les *transactions* de type bundle consomment deux fois plus de capacité d'écriture que les transactions de type *batch*, ce qui signifie que les bundles par *lots* peuvent traiter deux fois plus de ressources par seconde que les bundles de transactions.
Le tableau suivant répertorie les quotas par défaut pour AWS HealthLake.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/healthlake/latest/devguide/reference-healthlake-endpoints-quotas.html)
# Types de données préchargés Synthea pour HealthLake
HealthLake ne prend en charge que SYNTHEA en tant que type de données préchargé. [Synthea est un](https://synthetichealth.github.io/synthea/) générateur synthétique de patients qui modélise les antécédents `Patient` médicaux. Il est hébergé dans un référentiel Git open source qui permet de générer une ressource conforme HealthLake à la norme FHIR R4 `Bundle` afin que les utilisateurs puissent tester des modèles sans utiliser les données réelles des patients.
Les types de ressources suivants sont disponibles dans les magasins de HealthLake données préchargés. Pour plus d'informations sur le préchargement HealthLake des banques de données avec les données Synthea, consultez. [Création d'un magasin HealthLake de données](managing-data-stores-create.md)
**Note**
Pour consulter la liste complète des ressources FHIR R4 HealthLake prises en charge, voir. [Types de ressources pris en charge par FHIR R4 pour HealthLake](reference-fhir-resource-types.md)
**Types de ressources Synthea FHIR pris en charge par HealthLake**
| | |
| --- |--- |
| AllergyIntolerance | Location |
| CarePlan | MedicationAdministration |
| CareTeam | MedicationRequest |
| Demander | Observation |
| Condition | Organisation |
| Appareil | Patient |
| DiagnosticReport | Praticien |
| Rencontre | PractitionerRole |
| ExplanationofBenefit | Procédure |
| ImagingStudy | Provenance |
| Immunisation | |
# AWS HealthLake exemples de projets
Pour approfondir votre analyse, vous pouvez utiliser HealthLake d'autres AWS services, comme le montrent les exemples d'articles de blog suivants.
**HealthLake analyse intégrée**
+ [Applications de santé de la population avec AWS HealthLake — Partie 1 : Analyse et surveillance à l'aide d'Amazon Quick](https://aws.amazon.com/blogs/machine-learning/population-health-applications-with-amazon-healthlake-part-1-analytics-and-monitoring-using-amazon-quicksight/).
+ [Création de modèles prédictifs de maladies à l'aide d'Amazon SageMaker AI avec des données AWS HealthLake normalisées](https://aws.amazon.com/blogs/machine-learning/building-predictive-disease-models-using-amazon-sagemaker-with-amazon-healthlake-normalized-data/).
+ [Créez une recherche cognitive et un graphe de connaissances sur la santé à l'aide de services d' AWS IA](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 surveillance des événements**
+ [ EventBridge Intégration d'Amazon avec AWS HealthLake](https://aws.amazon.com/blogs/industries/amazon-eventbridge-integration-for-aws-healthlake/).
# Résolution des problèmes AWS HealthLake
Les rubriques suivantes fournissent des conseils de résolution des erreurs et des problèmes que vous pourriez rencontrer lors de l'utilisation de la HealthLake console AWS CLI AWS SDKs, ou. Si vous trouvez un problème qui n'est pas répertorié dans cette section, utilisez le bouton **Envoyer des commentaires** dans la barre latérale droite de cette page pour le signaler.
**Topics**
+ [Actions relatives au stockage des données](#troubleshooting-data-store)
+ [Actions d'importation](#troubleshooting-import)
+ [FHIR APIs](#troubleshooting-fhir-apis)
+ [Intégrations NLP](#troubleshooting-nlp-integrations)
+ [Intégrations SQL](#troubleshooting-sql-integrations)
## Actions relatives au stockage des données
**Problème :** *Lorsque j'essaie de créer un magasin de HealthLake données, le message d'erreur suivant s'affiche :*
```
AccessDeniedException: Insufficient Lake Formation permission(s): Required Database on Catalog
```
Le 14 novembre 2022, les autorisations IAM requises ont été HealthLake mises à jour pour créer un nouveau magasin de données. Pour de plus amples informations, veuillez consulter [Configuration d'un utilisateur ou d'un rôle IAM à utiliser HealthLake (administrateur IAM)](getting-started-setting-up.md#setting-up-configure-iam).
**Problème :** *lors de la création d'un magasin de HealthLake données à l'aide du AWS SDKs, le statut de création du magasin de données renvoie une exception ou un statut inconnu.*
Mettez à jour votre AWS SDK vers la dernière version si vos appels `DescribeFHIRDatastore` ou ceux de `ListFHIRDatastores` l'API renvoient une exception ou un statut de banque de données inconnu.
## Actions d'importation
**Problème :** *Puis-je toujours l'utiliser HealthLake si mes données ne sont pas au format FHIR R4 ?*
Seules les données au format FHIR R4 peuvent être importées dans un HealthLake magasin de données. [Pour une liste des partenaires qui peuvent aider à transformer les données de santé existantes au format FHIR R4, voir AWS HealthLake Partenaires.](https://docs.aws.amazon.com/healthlake/partners/)
**Problème :** *Pourquoi ma tâche d'importation FHIR a-t-elle échoué* ?
Une tâche d'importation réussie générera un dossier avec les résultats (journal de sortie) au `.ndjson` format, mais l'importation d'enregistrements individuels peut échouer. Dans ce cas, un deuxième `FAILURE` dossier sera généré avec un manifeste des enregistrements dont l'importation n'a pas pu être effectuée. Pour de plus amples informations, veuillez consulter [Importation de données FHIR avec AWS HealthLake](importing-fhir-data.md).
Pour analyser pourquoi une tâche d'importation a échoué, utilisez l'`DescribeFHIRImportJob`API pour analyser le JobProperties. Il est recommandé de procéder comme suit :
+ Si le statut est `FAILED` et qu'un message est présent, les échecs sont liés à des paramètres de tâche tels que la taille des données d'entrée ou le nombre de fichiers d'entrée dépassant les HealthLake quotas.
+ Si le statut de la tâche d'importation est le suivant `COMPLETED_WITH_ERRORS``manifest.json`, consultez le fichier manifeste pour savoir quels fichiers n'ont pas été importés correctement.
+ Si le statut de la tâche d'importation est le même `FAILED` et qu'aucun message n'est présent, rendez-vous à l'emplacement de sortie de la tâche pour accéder au fichier manifeste,`manifest.json`.
Pour chaque fichier d'entrée, il existe un fichier de sortie d'échec avec le nom du fichier d'entrée pour toute ressource dont l'importation échoue. Les réponses contiennent le numéro de ligne (LineID) correspondant à l'emplacement des données d'entrée, l'objet de réponse FHIR (UpdateResourceResponse) et le code d'état (StatusCode) de la réponse.
Un exemple de fichier de sortie peut être similaire au suivant :
```
{"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'exemple ci-dessus montre qu'il y a eu des défaillances sur les lignes 3, 4, 7, 9, 15 à partir des lignes d'entrée correspondantes du fichier d'entrée. Pour chacune de ces lignes, les explications sont les suivantes :
+ Sur la ligne 3, la réponse explique que le contenu `resourceType` fourni dans la ligne 3 du fichier d'entrée n'est pas valide.
+ Sur la ligne 5, la réponse explique qu'il y a une erreur de validation FHIR dans la ligne 5 du fichier d'entrée.
+ À la ligne 7, la réponse explique qu'il existe un problème de validation avec la `resourceId` valeur fournie en entrée.
+ Sur la ligne 9, la réponse explique que le fichier d'entrée doit contenir un identifiant de ressource valide.
+ À la ligne 15, la réponse du fichier d'entrée est que le fichier n'est pas dans un format JSON valide.
## FHIR APIs
**Problème :** *Comment mettre en œuvre l'autorisation pour le FHIR RESTful APIs* ?
Déterminez le [Stratégie d'autorisation du magasin de données](getting-started-concepts.md#concept-data-store-authorization-strategy) à utiliser.
Pour créer une autorisation SigV4 à l'aide de AWS SDK pour Python (Boto3), créez un script similaire à l'exemple suivant.
```
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())
```
**Problème :** *Pourquoi est-ce que je reçois `AccessDenied` des erreurs lorsque j'utilise le FHIR RESTful APIs pour un magasin de données chiffré avec une clé KMS gérée par le client* ?
Les autorisations relatives aux clés gérées par le client et aux politiques IAM sont requises pour qu'un utilisateur ou un rôle puisse accéder à un magasin de données. Un utilisateur doit disposer des autorisations IAM requises pour utiliser une clé gérée par le client. Si un utilisateur révoque ou retire une HealthLake autorisation autorisant l'utilisation de la clé KMS gérée par le client, un `AccessDenied` message d'erreur HealthLake sera renvoyé.
HealthLake doit avoir l'autorisation d'accéder aux données des clients, de chiffrer les nouvelles ressources FHIR importées dans un magasin de données et de déchiffrer les ressources FHIR lorsqu'elles sont demandées. Pour plus d'informations, consultez la section [Résolution des problèmes liés AWS KMS aux autorisations](https://docs.aws.amazon.com/kms/latest/developerguide/policy-evaluation.html).
**Problème :** *Une opération de `POST` l'API FHIR HealthLake utilisant un document de 10 Mo renvoie l'`413 Request Entity Too Large`erreur*.
AWS HealthLake dispose d'une limite d'API de création et de mise à jour synchrone de 5 Mo afin d'éviter des latences et des délais d'attente accrus. Vous pouvez ingérer des documents volumineux, jusqu'à 164 Mo, en utilisant le type de `Binary` ressource à l'aide de l'API d'importation en bloc.
## Intégrations NLP
**Problème :** *Comment activer la fonction intégrée HealthLake de traitement du langage naturel ?*
Le 14 novembre 2022, le comportement par défaut des magasins de HealthLake données a changé.
**Magasins de données actuels** : tous les magasins de HealthLake données actuels cesseront d'utiliser le traitement du langage naturel (NLP) sur les ressources codées en base64`DocumentReference`. Cela signifie que les nouvelles `DocumentReference` ressources ne seront pas analysées à l'aide du NLP et qu'aucune nouvelle ressource ne sera générée à partir du texte du type de `DocumentReference` ressource. Pour les `DocumentReference` ressources existantes, les données et les ressources générées via le NLP sont conservées, mais elles ne seront pas mises à jour après le 20 février 2023.
**Nouveaux magasins de données : les** magasins de HealthLake données créés après le 20 février 2023 *n'effectueront pas* de traitement du langage naturel (NLP) sur les ressources codées en base64`DocumentReference`.
Pour activer l'intégration du HealthLake NLP, créez un dossier d'assistance à l'aide [AWS Support Center Console](https://console.aws.amazon.com/support/home#/)de. Pour créer votre dossier, connectez-vous à votre dossier Compte AWS, puis choisissez **Créer un dossier**. Pour en savoir plus sur la création d'un dossier et sur la gestion des [dossiers, voir Création de dossiers d'assistance et gestion de cas](https://docs.aws.amazon.com/awssupport/latest/user/case-management.html) dans le *Guide de Support l'utilisateur*.
**Problème :** *>Comment trouver les `DocumentReference` ressources qui n'ont pas pu être traitées par le NLP intégré* ?
Si une `DocumentReference` ressource n'est pas valide, HealthLake fournit une extension indiquant une erreur de validation au lieu de la fournir dans la sortie PNL médicale intégrée. **Pour rechercher les `DocumentReference` ressources qui ont entraîné une erreur de validation lors du traitement NLP, vous pouvez utiliser la `search` fonction FHIR avec la clé HealthLake de recherche **cm-decoration-status**et la valeur de recherche VALIDATION\$1ERROR.** Cette recherche répertorie toutes les `DocumentReference` ressources ayant entraîné des erreurs de validation, ainsi qu'un message d'erreur décrivant la nature de l'erreur. La structure du champ d'extension dans les `DocumentReference` ressources présentant des erreurs de validation ressemblera à l'exemple suivant.
```
"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/"
}
]
```
**Note**
Un `VALIDATION_ERROR` peut également se produire si la décoration NLP crée plus de 10 000 objets imbriqués. Dans ce cas, le document doit être scindé en documents plus petits avant d'être traité.
## Intégrations SQL
**Problème :** *Pourquoi est-ce que j'obtiens un Lake Formation `permissions error: lakeformation:PutDataLakeSettings` lorsque j'ajoute un nouvel administrateur de lac de données ?*
Si votre utilisateur ou rôle IAM contient la politique `AWSLakeFormationDataAdmin` AWS gérée, vous ne pouvez pas ajouter de nouveaux administrateurs de data lake. Vous recevrez un message d'erreur contenant les informations suivantes :
```
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 politique AWS gérée `AdministratorAccess` est requise pour ajouter un utilisateur ou un rôle IAM en tant qu'administrateur AWS du lac de données de Lake Formation. Si votre utilisateur ou rôle IAM en contient également, `AWSLakeFormationDataAdmin` l'action échouera. La politique `AWSLakeFormationDataAdmin` AWS gérée contient un refus explicite de l'opération de l'API AWS Lake Formation,`PutDataLakeSetting`. Même les administrateurs disposant d'un accès complet à l' AWS utilisation de la politique `AdministratorAccess` gérée peuvent être limités par cette `AWSLakeFormationDataAdmin` dernière.
**Problème :** *Comment migrer un magasin de HealthLake données existant pour utiliser l'intégration SQL d'Amazon Athena* ?
HealthLake les magasins de données créés avant le 14 novembre 2022 sont fonctionnels, mais ne peuvent pas être interrogés dans Athena à l'aide de SQL. Pour interroger un magasin de données préexistant avec Athena, vous devez d'abord le migrer vers un nouveau magasin de données.
**Pour migrer vos HealthLake données vers un nouveau magasin de données**
1. Créez un nouveau magasin de données.
1. Exportez les données du compartiment préexistant vers un compartiment Amazon S3.
1. Importez les données dans le nouveau magasin de données depuis le compartiment Amazon S3.
**Note**
L'exportation de données vers un compartiment Amazon S3 entraîne des frais supplémentaires. Les frais supplémentaires dépendent de la taille des données que vous exportez.
**Problème :** *lors de la création d'un nouveau magasin de HealthLake données pour l'intégration SQL, le statut du magasin de données ne change pas de`Creating`.*
Si vous essayez de créer un nouveau magasin de HealthLake données et que le statut de votre magasin de données ne change pas depuis **Création**, vous devez mettre Athéna à jour pour qu'elle utilise le. AWS Glue Data Catalog Pour plus d'informations, consultez la section [Mise à niveau vers le catalogue de données AWS Glue step-by-step](https://docs.aws.amazon.com/athena/latest/ug/glue-upgrade.html) dans le guide de l'*utilisateur Amazon Athena*.
Une fois la mise à niveau réussie AWS Glue Data Catalog, vous pouvez créer un magasin de HealthLake données.
Pour supprimer un ancien magasin de HealthLake données, créez un dossier d'assistance à l'aide de [AWS Support Center Console](https://console.aws.amazon.com/support/home#/). Pour créer votre dossier, connectez-vous à votre dossier Compte AWS, puis choisissez **Créer un dossier**. Pour en savoir plus, consultez les sections [Création de demandes d'assistance et gestion de dossiers](https://docs.aws.amazon.com/awssupport/latest/user/case-management.html) dans le *Guide de Support l'utilisateur*.
**Problème :** *La console Athena ne fonctionne pas après l'importation de données dans un nouveau HealthLake * magasin de données
Une fois que vous avez importé des données dans un nouveau magasin de HealthLake données, il est possible que celles-ci ne soient pas disponibles pour une utilisation immédiate. Cela permet de laisser le temps aux données d'être ingérées dans les tables Apache Iceberg. Réessayez ultérieurement.
**Problème :** *Comment associer les résultats de recherche d'Athena à d'autres AWS services* ?
Lorsque vous partagez les résultats de recherche d'Athena avec d'autres AWS services, des problèmes peuvent survenir lorsque vous les utilisez dans `json_extract[1]` le cadre d'une requête de recherche SQL. Pour résoudre ce problème, vous devez effectuer une mise à jour vers`CATVAR`.
Vous pouvez rencontrer ce problème lorsque vous essayez de **créer des** résultats de sauvegarde, une **table** (statique) ou une **vue** (dynamique).
# Utilisation HealthLake avec un AWS SDK
AWS des kits de développement logiciel (SDKs) sont disponibles pour de nombreux langages de programmation courants. Chaque kit SDK fournit une API, des exemples de code et de la documentation qui facilitent la création d’applications par les développeurs dans leur langage préféré.
| Documentation SDK | Exemples de code |
| --- | --- |
| [AWS SDK pour C\$1\$1](https://docs.aws.amazon.com/sdk-for-cpp) | [AWS SDK pour C\$1\$1 exemples de code](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/cpp) |
| [AWS CLI](https://docs.aws.amazon.com/cli) | [AWS CLI exemples de code](https://docs.aws.amazon.com/code-library/latest/ug/cli_2_code_examples.html) |
| [AWS SDK pour Go](https://docs.aws.amazon.com/sdk-for-go) | [AWS SDK pour Go exemples de code](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/gov2) |
| [AWS SDK pour Java](https://docs.aws.amazon.com/sdk-for-java) | [AWS SDK pour Java exemples de code](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/javav2) |
| [AWS SDK pour JavaScript](https://docs.aws.amazon.com/sdk-for-javascript) | [AWS SDK pour JavaScript exemples de code](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/javascriptv3) |
| [AWS SDK pour Kotlin](https://docs.aws.amazon.com/sdk-for-kotlin) | [AWS SDK pour Kotlin exemples de code](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/kotlin) |
| [AWS SDK pour .NET](https://docs.aws.amazon.com/sdk-for-net) | [AWS SDK pour .NET exemples de code](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/dotnetv3) |
| [AWS SDK pour PHP](https://docs.aws.amazon.com/sdk-for-php) | [AWS SDK pour PHP exemples de code](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/php) |
| [Outils AWS pour PowerShell](https://docs.aws.amazon.com/powershell) | [Outils AWS pour PowerShell exemples de code](https://docs.aws.amazon.com/code-library/latest/ug/powershell_5_code_examples.html) |
| [AWS SDK pour Python (Boto3)](https://docs.aws.amazon.com/pythonsdk) | [AWS SDK pour Python (Boto3) exemples de code](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/python) |
| [AWS SDK pour Ruby](https://docs.aws.amazon.com/sdk-for-ruby) | [AWS SDK pour Ruby exemples de code](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/ruby) |
| [AWS SDK pour Rust](https://docs.aws.amazon.com/sdk-for-rust) | [AWS SDK pour Rust exemples de code](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/rustv1) |
| [AWS SDK pour SAP ABAP](https://docs.aws.amazon.com/sdk-for-sapabap) | [AWS SDK pour SAP ABAP exemples de code](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/sap-abap) |
| [AWS SDK pour Swift](https://docs.aws.amazon.com/sdk-for-swift) | [AWS SDK pour Swift exemples de code](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/swift) |
**Exemple de disponibilité**
Vous n’avez pas trouvé ce dont vous avez besoin ? Demandez un exemple de code en utilisant le lien **Provide feedback (Fournir un commentaire)** en bas de cette page.