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.
# Gestion des ressources FHIR dans AWS HealthLake
Utilisez les interactions de l' RESTful API FHIR R4 pour gérer les ressources FHIR dans un HealthLake magasin de données. Les sections suivantes décrivent toutes les interactions de l' RESTful API FHIR R4 HealthLake prises en charge et disponibles pour la gestion des ressources FHIR. Pour plus d'informations sur HealthLake les fonctionnalités du magasin de données et sur les parties de la spécification FHIR prises en charge, consultez[Déclaration de capacité du FHIR R4 pour AWS HealthLake](reference-fhir-capability-statement.md).
**Note**
Les interactions FHIR répertoriées dans ce chapitre sont conçues conformément à la norme HL7 FHIR R4 pour l'échange de données sur les soins de santé. Parce qu'ils sont des représentations des services HL7 FHIR, ils ne sont pas proposés par le biais de AWS CLI et AWS SDKs. Pour plus d'informations, consultez la section [RESTful API](https://hl7.org/fhir/R4/http.html) dans la documentation de l'** RESTful API FHIR R4**.
Le tableau suivant répertorie les interactions FHIR R4 prises en charge par. AWS HealthLake Pour plus d'informations sur les *types de ressources* FHIR pris en charge par HealthLake, consultez[Types de ressources](reference-fhir-resource-types.md).
**Interactions FHIR R4 prises en charge par AWS HealthLake**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/healthlake/latest/devguide/managing-fhir-resources.html)
**Topics**
+ [Création d'une ressource FHIR](managing-fhir-resources-create.md)
+ [Lire une ressource FHIR](managing-fhir-resources-read.md)
+ [Lire l'historique des ressources du FHIR](managing-fhir-resources-read-history.md)
+ [Mettre à jour une ressource FHIR](managing-fhir-resources-update.md)
+ [Modification des ressources à l'aide de l'opération PATCH](managing-fhir-resources-patch.md)
+ [Regroupement des ressources FHIR](managing-fhir-resources-bundle.md)
+ [Supprimer une ressource FHIR](managing-fhir-resources-delete.md)
+ [Idempotencie et simultanéité](managing-fhir-resources-idempotency.md)
# Création d'une ressource FHIR
L'`create`interaction FHIR crée une nouvelle ressource FHIR dans un magasin de HealthLake données. Pour plus d'informations, consultez la [https://hl7.org/fhir/R4/http.html#create](https://hl7.org/fhir/R4/http.html#create)documentation de l'** RESTful API FHIR R4**.
**Pour créer une ressource FHIR**
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. Déterminez le type de FHIR `Resource` à créer. Pour de plus amples informations, veuillez consulter [Types de ressources](reference-fhir-resource-types.md).
1. Créez une URL pour la demande en utilisant les valeurs collectées pour HealthLake `region` et`datastoreId`. Incluez également le `Resource` type FHIR à créer. Pour afficher le chemin complet de l'URL dans l'exemple suivant, faites défiler le curseur sur le bouton **Copier**.
```
POST https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Resource
```
1. Construisez un corps JSON pour la demande, en spécifiant les données FHIR de la nouvelle ressource. Dans le cadre de cette procédure, nous utilisons une `Patient` ressource FHIR. Enregistrez donc le fichier sous`create-patient.json`.
```
{
"resourceType": "Patient",
"identifier": [
{
"system": "urn:oid:1.2.36.146.595.217.0.1",
"value": "12345"
}
],
"name": [
{
"family": "Silva",
"given": [
"Ana",
"Carolina"
]
}
],
"gender": "female",
"birthDate": "1992-02-10"
}
```
1. Envoyez la demande . L'`create`interaction FHIR utilise une `POST` demande avec [AWS signature version 4](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) ou SMART sur autorisation FHIR. Les exemples suivants créent une `Patient` ressource FHIR en HealthLake utilisant curl ou la HealthLake console. Pour afficher un exemple complet, faites défiler la souris sur le bouton **Copier**.
------
#### [ SigV4 ]
Autorisation SigV4
```
curl --request POST \
'https://healthlake.region.amazonaws.com/datastore/datastore-id/r4/Patient' \
--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' \
--data @create-patient.json
```
------
#### [ SMART on FHIR ]
Exemple d'autorisation SMART sur FHIR pour le 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.
```
{
"AuthorizationStrategy": "SMART_ON_FHIR",
"FineGrainedAuthorizationEnabled": true,
"IdpLambdaArn": "arn:aws:lambda:your-region:your-account-id:function:your-lambda-name",
"Metadata": "{\"issuer\":\"https://ehr.example.com\", \"jwks_uri\":\"https://ehr.example.com/.well-known/jwks.json\",\"authorization_endpoint\":\"https://ehr.example.com/auth/authorize\",\"token_endpoint\":\"https://ehr.token.com/auth/token\",\"token_endpoint_auth_methods_supported\":[\"client_secret_basic\",\"foo\"],\"grant_types_supported\":[\"client_credential\",\"foo\"],\"registration_endpoint\":\"https://ehr.example.com/auth/register\",\"scopes_supported\":[\"openId\",\"profile\",\"launch\"],\"response_types_supported\":[\"code\"],\"management_endpoint\":\"https://ehr.example.com/user/manage\",\"introspection_endpoint\":\"https://ehr.example.com/user/introspect\",\"revocation_endpoint\":\"https://ehr.example.com/user/revoke\",\"code_challenge_methods_supported\":[\"S256\"],\"capabilities\":[\"launch-ehr\",\"sso-openid-connect\",\"client-public\",\"permission-v2\"]}"
}
```
L'appelant peut attribuer des autorisations dans le lambda d'autorisation. Pour de plus amples informations, veuillez consulter [OAuth Éscopes 2.0](reference-smart-on-fhir-oauth-scopes.md).
------
#### [ AWS Console ]
**Note**
La HealthLake console prend uniquement en charge l'autorisation [AWS SigV4](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html).
1. Connectez-vous à la page [Exécuter une requête](https://console.aws.amazon.com/healthlake/home#/crud) sur la HealthLake console.
2. Dans la section **Paramètres de requête**, effectuez les sélections suivantes.
+ **ID du magasin de données** : choisissez un identifiant de magasin de données pour générer une chaîne de requête.
+ **Type de requête** : choisissez`Create`.
+ **Type de ressource** : choisissez le [type de ressource](reference-fhir-resource-types.md) FHIR à créer.
+ **Corps de la demande** : créez un corps JSON pour la demande, en spécifiant les données FHIR de la nouvelle ressource.
3. Choisissez **Exécuter la requête**.
------
**Configuration du niveau de validation pour la création de ressources**
Lorsque vous créez une ressource FHIR, vous pouvez éventuellement spécifier un en-tête `x-amzn-healthlake-fhir-validation-level` HTTP pour configurer un niveau de validation pour la ressource. AWS HealthLake prend actuellement en charge les niveaux de validation suivants :
+ `strict`: Les ressources sont validées en fonction de l'élément de profil de la ressource ou de la spécification R4 si aucun profil n'est présent. Il s'agit du niveau de validation par défaut pour AWS HealthLake.
+ `structure-only`: Les ressources sont validées par rapport à R4, en ignorant les profils référencés.
+ `minimal`: Les ressources sont validées de manière minimale, sans tenir compte de certaines règles R4. Les ressources qui échouent aux vérifications de structure requises search/analytics seront mises à jour pour inclure un avertissement d'audit.
Les ressources créées avec le niveau de validation minimal peuvent être ingérées dans une banque de données malgré l'échec de la validation requise pour l'indexation des recherches. Dans ce cas, les ressources seront mises à jour pour inclure une extension spécifique à Healthlake afin de documenter ces échecs :
```
{
"url": "http://healthlake.amazonaws.com/fhir/StructureDefinition/validation-issue",
"valueString": "{\"resourceType\":\"OperationOutcome\",\"issue\":[{\"severity\":\"error\",\"code\":\"processing\",\"details\":{\"text\":\"FHIR resource in payload failed FHIR validation rules.\"},\"diagnostics\":\"FHIR resource in payload failed FHIR validation rules.\"}]}"
}
```
En outre, l'en-tête de réponse HTTP suivant sera inclus avec la valeur « true » :
```
x-amzn-healthlake-validation-issues : true
```
**Note**
Les données ingérées qui sont mal formées conformément à la spécification R4 peuvent ne pas être consultables comme prévu si ces erreurs sont présentes.
# Lire une ressource FHIR
L'`read`interaction FHIR lit l'état actuel d'une ressource dans un magasin de HealthLake données. Pour plus d'informations, consultez la [https://hl7.org/fhir/R4/http.html#read](https://hl7.org/fhir/R4/http.html#read)documentation de l'** RESTful API FHIR R4**.
**Pour lire une ressource FHIR**
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. Déterminez le type de FHIR `Resource` à lire et collectez la `id` valeur associée. Pour de plus amples informations, veuillez consulter [Types de ressources](reference-fhir-resource-types.md).
1. Construisez une URL pour la demande en utilisant les valeurs collectées pour HealthLake `region` et`datastoreId`. Incluez également le `Resource` type FHIR et son associé`id`. Pour afficher le chemin complet de l'URL dans l'exemple suivant, faites défiler le curseur sur le bouton **Copier**.
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Resource/id
```
1. Envoyez la demande . L'`read`interaction FHIR utilise une `GET` demande avec [AWS signature version 4](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) ou SMART sur autorisation FHIR. L'`curl`exemple suivant lit l'état actuel d'une `Patient` ressource FHIR dans HealthLake. Pour afficher l'exemple dans son intégralité, faites défiler la souris sur le bouton **Copier**.
------
#### [ SigV4 ]
Autorisation SigV4
```
curl --request GET \
'https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient/id' \
--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'
```
------
#### [ SMART on FHIR ]
Exemple d'autorisation SMART sur FHIR pour le 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.
```
{
"AuthorizationStrategy": "SMART_ON_FHIR",
"FineGrainedAuthorizationEnabled": true,
"IdpLambdaArn": "arn:aws:lambda:your-region:your-account-id:function:your-lambda-name",
"Metadata": "{\"issuer\":\"https://ehr.example.com\", \"jwks_uri\":\"https://ehr.example.com/.well-known/jwks.json\",\"authorization_endpoint\":\"https://ehr.example.com/auth/authorize\",\"token_endpoint\":\"https://ehr.token.com/auth/token\",\"token_endpoint_auth_methods_supported\":[\"client_secret_basic\",\"foo\"],\"grant_types_supported\":[\"client_credential\",\"foo\"],\"registration_endpoint\":\"https://ehr.example.com/auth/register\",\"scopes_supported\":[\"openId\",\"profile\",\"launch\"],\"response_types_supported\":[\"code\"],\"management_endpoint\":\"https://ehr.example.com/user/manage\",\"introspection_endpoint\":\"https://ehr.example.com/user/introspect\",\"revocation_endpoint\":\"https://ehr.example.com/user/revoke\",\"code_challenge_methods_supported\":[\"S256\"],\"capabilities\":[\"launch-ehr\",\"sso-openid-connect\",\"client-public\",\"permission-v2\"]}"
}
```
L'appelant peut attribuer des autorisations dans le lambda d'autorisation. Pour de plus amples informations, veuillez consulter [OAuth Éscopes 2.0](reference-smart-on-fhir-oauth-scopes.md).
------
#### [ AWS Console ]
1. Connectez-vous à la page [Exécuter une requête](https://console.aws.amazon.com/healthlake/home#/crud) sur la HealthLake console.
2. Dans la section **Paramètres de requête**, effectuez les sélections suivantes.
+ **ID du magasin de données** : choisissez un identifiant de magasin de données pour générer une chaîne de requête.
+ **Type de requête** : choisissez`Read`.
+ **Type de ressource** : choisissez le [type de ressource](reference-fhir-resource-types.md) FHIR à lire.
+ **ID de ressource** — entrez l'ID de ressource FHIR.
3. Choisissez **Exécuter la requête**.
------
# Lire l'historique des ressources du FHIR
L'`history`interaction FHIR permet de récupérer l'historique d'une ressource FHIR particulière dans un HealthLake magasin de données. Grâce à cette interaction, vous pouvez déterminer l'évolution du contenu d'une ressource FHIR au fil du temps. Il est également utile en coordination avec les journaux d'audit pour voir l'état d'une ressource avant et après modification. Les interactions `create` FHIR et `delete` aboutissent à une version historique de la ressource à enregistrer. `update` Pour plus d'informations, consultez la [https://hl7.org/fhir/R4/http.html#history](https://hl7.org/fhir/R4/http.html#history)documentation de l'** RESTful API FHIR R4**.
**Note**
Vous pouvez choisir de ne pas utiliser `history` des types de ressources FHIR spécifiques. Pour vous désinscrire, créez un dossier en utilisant [AWS Support Center Console](https://console.aws.amazon.com/support/home#/). Pour créer votre dossier, connectez-vous à votre dossier Compte AWS et choisissez **Créer un dossier**.
**Pour lire l'historique des ressources du FHIR**
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. Déterminez le type de FHIR `Resource` à lire et collectez la `id` valeur associée. Pour de plus amples informations, veuillez consulter [Types de ressources](reference-fhir-resource-types.md).
1. Créez une URL pour la demande en utilisant les valeurs collectées pour HealthLake `region` et`datastoreId`. Incluez également le `Resource` type FHIR, ses paramètres de recherche associés `id` et facultatifs. Pour afficher le chemin complet de l'URL dans l'exemple suivant, faites défiler le curseur sur le bouton **Copier**.
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Resource/id/_history{?[parameters]}
```
**HealthLake paramètres de recherche pris en charge pour l'interaction FHIR `history`**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/healthlake/latest/devguide/managing-fhir-resources-read-history.html)
1. Envoyez la demande . L'`history`interaction FHIR utilise une `GET` demande avec [AWS signature version 4](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) ou SMART sur autorisation FHIR. L'`curl`exemple suivant utilise le paramètre `_count` de recherche pour renvoyer 100 résultats de recherche historiques par page pour une `Patient` ressource FHIR dans HealthLake. Pour afficher l'exemple dans son intégralité, faites défiler la souris sur le bouton **Copier**.
------
#### [ SigV4 ]
Autorisation SigV4
```
curl --request GET \
'https://healthlake.region.amazonaws.com/datastore/datastore-id/r4/Patient/id/_history?_count=100' \
--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'
```
------
#### [ SMART on FHIR ]
Exemple d'autorisation SMART sur FHIR pour le 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.
```
{
"AuthorizationStrategy": "SMART_ON_FHIR",
"FineGrainedAuthorizationEnabled": true,
"IdpLambdaArn": "arn:aws:lambda:your-region:your-account-id:function:your-lambda-name",
"Metadata": "{\"issuer\":\"https://ehr.example.com\", \"jwks_uri\":\"https://ehr.example.com/.well-known/jwks.json\",\"authorization_endpoint\":\"https://ehr.example.com/auth/authorize\",\"token_endpoint\":\"https://ehr.token.com/auth/token\",\"token_endpoint_auth_methods_supported\":[\"client_secret_basic\",\"foo\"],\"grant_types_supported\":[\"client_credential\",\"foo\"],\"registration_endpoint\":\"https://ehr.example.com/auth/register\",\"scopes_supported\":[\"openId\",\"profile\",\"launch\"],\"response_types_supported\":[\"code\"],\"management_endpoint\":\"https://ehr.example.com/user/manage\",\"introspection_endpoint\":\"https://ehr.example.com/user/introspect\",\"revocation_endpoint\":\"https://ehr.example.com/user/revoke\",\"code_challenge_methods_supported\":[\"S256\"],\"capabilities\":[\"launch-ehr\",\"sso-openid-connect\",\"client-public\",\"permission-v2\"]}"
}
```
L'appelant peut attribuer des autorisations dans le lambda d'autorisation. Pour de plus amples informations, veuillez consulter [OAuth Éscopes 2.0](reference-smart-on-fhir-oauth-scopes.md).
------
Le contenu renvoyé par une `history` interaction est contenu dans une ressource FHIR`Bundle`, dont le type est défini sur. `history` Il contient l'historique des versions spécifié, trié avec les versions les plus anciennes en dernier et inclut les ressources supprimées. Pour plus d'informations, consultez la [https://hl7.org/fhir/R4/bundle.html](https://hl7.org/fhir/R4/bundle.html)documentation du **FHIR R4**.
## Lire l'historique des ressources FHIR spécifiques à une version
L'`vread`interaction FHIR effectue une lecture spécifique à la version d'une ressource dans un HealthLake magasin de données. Grâce à cette interaction, vous pouvez visualiser le contenu d'une ressource FHIR tel qu'il était à un moment donné dans le passé.
**Note**
Si vous utilisez l'`history`interaction FHIR *sans*`vread`, renvoie HealthLake toujours la dernière version des métadonnées de la ressource.
HealthLake déclare qu'il prend en charge le versionnement [https://hl7.org/fhir/R4/capabilitystatement-definitions.html#CapabilityStatement.rest.resource.versioning](https://hl7.org/fhir/R4/capabilitystatement-definitions.html#CapabilityStatement.rest.resource.versioning)pour chaque ressource prise en charge. Tous les magasins de HealthLake données incluent `Resource.meta.versionId` (`vid`) sur toutes les ressources.
Lorsque `history` l'interaction FHIR est activée (par défaut pour les magasins de données créés après le 25/10/2024 ou par demande pour les anciens magasins de données), la `Bundle` réponse inclut `vid` le dans l'élément. [https://hl7.org/fhir/R4/bundle-definitions.html#Bundle.entry.response.location](https://hl7.org/fhir/R4/bundle-definitions.html#Bundle.entry.response.location) Dans l'exemple suivant, le `vid` s'affiche sous forme de numéro`1`. Pour voir l'exemple complet, voir [Example bundle/bundle-response (JSON](https://build.fhir.org/bundle-response.json.html)).
```
"response" : {
"status" : "201 Created",
"location" : "Patient/12423/_history/1",
...}
```
**Pour lire l'historique des ressources FHIR spécifiques à une version**
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. Déterminez le `Resource` type de FHIR à lire et à collecter les `vid` valeurs `id` et associées. Pour de plus amples informations, veuillez consulter [Types de ressources](reference-fhir-resource-types.md).
1. Construisez une URL pour la demande en utilisant les valeurs collectées pour HealthLake et FHIR. Pour afficher le chemin complet de l'URL dans l'exemple suivant, faites défiler le curseur sur le bouton **Copier**.
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Resource/id/_history/vid
```
1. Envoyez la demande . L'`history`interaction FHIR utilise une `GET` demande avec [AWS signature version 4](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) ou SMART sur autorisation FHIR. L'`vread`interaction suivante renvoie une seule instance avec le contenu spécifié pour la `Patient` ressource FHIR pour la version des métadonnées de ressource spécifiée par le`vid`. Pour afficher le chemin complet de l'URL dans l'exemple suivant, faites défiler le curseur sur le bouton **Copier**.
------
#### [ SigV4 ]
Autorisation SigV4
```
curl --request GET \
'https://healthlake.region.amazonaws.com/datastore/datastore-id/r4/Patient/id/_history/vid' \
--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'
```
------
#### [ SMART on FHIR ]
Exemple d'autorisation SMART sur FHIR pour le 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.
```
{
"AuthorizationStrategy": "SMART_ON_FHIR",
"FineGrainedAuthorizationEnabled": true,
"IdpLambdaArn": "arn:aws:lambda:your-region:your-account-id:function:your-lambda-name",
"Metadata": "{\"issuer\":\"https://ehr.example.com\", \"jwks_uri\":\"https://ehr.example.com/.well-known/jwks.json\",\"authorization_endpoint\":\"https://ehr.example.com/auth/authorize\",\"token_endpoint\":\"https://ehr.token.com/auth/token\",\"token_endpoint_auth_methods_supported\":[\"client_secret_basic\",\"foo\"],\"grant_types_supported\":[\"client_credential\",\"foo\"],\"registration_endpoint\":\"https://ehr.example.com/auth/register\",\"scopes_supported\":[\"openId\",\"profile\",\"launch\"],\"response_types_supported\":[\"code\"],\"management_endpoint\":\"https://ehr.example.com/user/manage\",\"introspection_endpoint\":\"https://ehr.example.com/user/introspect\",\"revocation_endpoint\":\"https://ehr.example.com/user/revoke\",\"code_challenge_methods_supported\":[\"S256\"],\"capabilities\":[\"launch-ehr\",\"sso-openid-connect\",\"client-public\",\"permission-v2\"]}"
}
```
L'appelant peut attribuer des autorisations dans le lambda d'autorisation. Pour de plus amples informations, veuillez consulter [OAuth Éscopes 2.0](reference-smart-on-fhir-oauth-scopes.md).
------
# Mettre à jour une ressource FHIR
L'`update`interaction FHIR crée une nouvelle version actuelle pour une ressource existante ou crée une version initiale si aucune ressource n'existe déjà pour la ressource donnée`id`. Pour plus d'informations, consultez la [https://hl7.org/fhir/R4/http.html#update](https://hl7.org/fhir/R4/http.html#update)documentation de l'** RESTful API FHIR R4**.
**Pour mettre à jour une ressource FHIR**
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. Déterminez le type de FHIR `Resource` à mettre à jour et collectez la `id` valeur associée. Pour de plus amples informations, veuillez consulter [Types de ressources](reference-fhir-resource-types.md).
1. Construisez une URL pour la demande en utilisant les valeurs collectées pour HealthLake `region` et`datastoreId`. Incluez également le `Resource` type FHIR et son associé`id`. Pour afficher le chemin complet de l'URL dans l'exemple suivant, faites défiler le curseur sur le bouton **Copier**.
```
PUT https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Resource/id
```
1. Construisez un `JSON` corps pour la demande, en spécifiant les mises à jour des données FHIR à effectuer. Dans le cadre de cette procédure, enregistrez le fichier sous`update-patient.json`.
```
{
"id": "2de04858-ba65-44c1-8af1-f2fe69a977d9",
"resourceType": "Patient",
"active": true,
"name": [
{
"use": "official",
"family": "Doe",
"given": [
"Jane"
]
},
{
"use": "usual",
"given": [
"Jane"
]
}
],
"gender": "female",
"birthDate": "1985-12-31"
}
```
1. Envoyez la demande . L'`update`interaction FHIR utilise une `PUT` demande avec [AWS signature version 4](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) ou SMART sur autorisation FHIR. L'`curl`exemple suivant met à jour une `Patient` ressource dans HealthLake. Pour afficher l'exemple dans son intégralité, faites défiler la souris sur le bouton **Copier**.
------
#### [ SigV4 ]
Autorisation SigV4
```
curl --request PUT \
'https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient/id' \
--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' \
--data @update-patient.json
```
Votre demande renverra un code d'état `200` HTTP si une ressource existante est *mise à jour* ou un code d'état `201` HTTP si une nouvelle ressource est créée.
------
#### [ SMART on FHIR ]
Exemple d'autorisation SMART sur FHIR pour le 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.
```
{
"AuthorizationStrategy": "SMART_ON_FHIR",
"FineGrainedAuthorizationEnabled": true,
"IdpLambdaArn": "arn:aws:lambda:your-region:your-account-id:function:your-lambda-name",
"Metadata": "{\"issuer\":\"https://ehr.example.com\", \"jwks_uri\":\"https://ehr.example.com/.well-known/jwks.json\",\"authorization_endpoint\":\"https://ehr.example.com/auth/authorize\",\"token_endpoint\":\"https://ehr.token.com/auth/token\",\"token_endpoint_auth_methods_supported\":[\"client_secret_basic\",\"foo\"],\"grant_types_supported\":[\"client_credential\",\"foo\"],\"registration_endpoint\":\"https://ehr.example.com/auth/register\",\"scopes_supported\":[\"openId\",\"profile\",\"launch\"],\"response_types_supported\":[\"code\"],\"management_endpoint\":\"https://ehr.example.com/user/manage\",\"introspection_endpoint\":\"https://ehr.example.com/user/introspect\",\"revocation_endpoint\":\"https://ehr.example.com/user/revoke\",\"code_challenge_methods_supported\":[\"S256\"],\"capabilities\":[\"launch-ehr\",\"sso-openid-connect\",\"client-public\",\"permission-v2\"]}"
}
```
L'appelant peut attribuer des autorisations dans le lambda d'autorisation. Pour de plus amples informations, veuillez consulter [OAuth Éscopes 2.0](reference-smart-on-fhir-oauth-scopes.md).
------
#### [ AWS Console ]
1. Connectez-vous à la page [Exécuter une requête](https://console.aws.amazon.com/healthlake/home#/crud) sur la HealthLake console.
2. Dans la section **Paramètres de requête**, effectuez les sélections suivantes.
+ **ID du magasin de données** : choisissez un identifiant de magasin de données pour générer une chaîne de requête.
+ **Type de requête** : choisissez`Update (PUT)`.
+ **Type de ressource** : choisissez le [type de ressource](reference-fhir-resource-types.md) FHIR à mettre à jour ou à créer.
+ **Corps de la demande** : créez un corps JSON pour la demande, en spécifiant les données FHIR avec lesquelles mettre à jour la ressource.
3. Choisissez **Exécuter la requête**.
------
## Mise à jour des ressources du FHIR en fonction des conditions
La mise à jour conditionnelle vous permet de mettre à jour une ressource existante en fonction de certains critères de recherche d'identification, plutôt que selon un FHIR `id` logique. Lorsque le serveur traite la mise à jour, il effectue une recherche à l'aide de ses fonctionnalités de recherche standard pour le type de ressource, dans le but de résoudre une seule logique `id` pour la demande.
L'action entreprise par le serveur dépend du nombre de correspondances qu'il trouve :
+ **Aucune correspondance, aucune information `id` fournie dans le corps de la requête** : le serveur crée la ressource FHIR.
+ **Aucune correspondance, `id` fournie et la ressource n'existe pas déjà avec le `id` : Le** serveur traite l'interaction comme une interaction Mettre à jour en tant qu'interaction Créer.
+ **Aucune correspondance, `id` fournie et existante** : le serveur rejette la mise à jour avec une `409 Conflict` erreur.
+ **Une correspondance, aucune ressource `id` fournie OU (ressource `id` fournie et elle correspond à la ressource trouvée)** : Le serveur effectue la mise à jour par rapport à la ressource correspondante comme ci-dessus où, si la ressource a été mise à jour, le serveur DOIT renvoyer un`200 OK`.
+ **Une correspondance, ressource `id` fournie mais ne correspondant pas à la ressource trouvée** : le serveur renvoie une `409 Conflict` erreur indiquant que la spécification de l'identifiant du client posait problème, de préférence avec un `OperationOutcome`
+ **Correspondances multiples** : le serveur renvoie une `412 Precondition Failed` erreur indiquant que les critères du client n'étaient pas suffisamment sélectifs, de préférence avec un OperationOutcome
L'exemple suivant met à jour une `Patient` ressource dont le nom est Peter, la date de naissance est le 1er janvier 2000 et le numéro de téléphone est 1234567890.
```
PUT https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient?name=peter&birthdate=2000-01-01&phone=1234567890
```
## Configuration du niveau de validation pour les mises à jour des ressources
Lors de la mise à jour d'une ressource FHIR, vous pouvez éventuellement spécifier un en-tête `x-amzn-healthlake-fhir-validation-level` HTTP pour configurer un niveau de validation pour la ressource. AWS HealthLake prend actuellement en charge les niveaux de validation suivants :
+ `strict`: Les ressources sont validées en fonction de l'élément de profil de la ressource ou de la spécification R4 si aucun profil n'est présent. Il s'agit du niveau de validation par défaut pour AWS HealthLake.
+ `structure-only`: Les ressources sont validées par rapport à R4, en ignorant les profils référencés.
+ `minimal`: Les ressources sont validées de manière minimale, sans tenir compte de certaines règles R4. Les ressources qui échouent aux vérifications de structure requises search/analytics seront mises à jour pour inclure un avertissement d'audit.
Les ressources mises à jour avec le niveau de validation minimal peuvent être ingérées dans une banque de données malgré l'échec de la validation requise pour l'indexation des recherches. Dans ce cas, les ressources seront mises à jour pour inclure une extension spécifique à Healthlake afin de documenter ces échecs :
```
{
"url": "http://healthlake.amazonaws.com/fhir/StructureDefinition/validation-issue",
"valueString": "{\"resourceType\":\"OperationOutcome\",\"issue\":[{\"severity\":\"error\",\"code\":\"processing\",\"details\":{\"text\":\"FHIR resource in payload failed FHIR validation rules.\"},\"diagnostics\":\"FHIR resource in payload failed FHIR validation rules.\"}]}"
}
```
En outre, l'en-tête de réponse HTTP suivant sera inclus avec la valeur « true » :
```
x-amzn-healthlake-validation-issues : true
```
**Note**
Notez que les données ingérées qui sont mal formées conformément à la spécification R4 peuvent ne pas être consultables comme prévu si ces erreurs sont présentes.
# Modification des ressources à l'aide de l'opération PATCH
AWS HealthLake prend en charge l'opération PATCH pour les ressources FHIR, vous permettant de modifier les ressources en ciblant des éléments spécifiques à ajouter, remplacer ou supprimer sans mettre à jour l'intégralité de la ressource. Cette opération est particulièrement utile lorsque vous devez :
+ Procéder à des mises à jour ciblées à des ressources importantes
+ Réduire l'utilisation de la bande passante du réseau
+ Effectuer des modifications atomiques sur des éléments de ressources spécifiques
+ Minimisez le risque de remplacer des modifications simultanées
+ Mettre à jour les ressources dans le cadre des flux de travail par lots et par transactions
## Formats PATCH pris en charge
AWS HealthLake prend en charge deux formats PATCH standard :
### Correctif JSON (RFC 6902)
Utilise la syntaxe du pointeur JSON pour cibler les éléments en fonction de leur position dans la structure des ressources.
**Type de contenu :** `application/json-patch+json`
### FHIRPath Patch (spécification FHIR R4)
Utilise des FHIRPath expressions pour cibler les éléments en fonction de leur contenu et de leurs relations, offrant ainsi une approche native du FHIR pour l'application de correctifs.
**Type de contenu :** `application/fhir+json`
## Usage
### Opérations PATCH directes
L'opération PATCH peut être invoquée directement sur les ressources FHIR à l'aide de la méthode HTTP PATCH :
```
PATCH [base]/[resource-type]/[id]{?_format=[mime-type]}
```
### PATCH en packs
Les opérations PATCH peuvent être incluses sous forme d'entrées dans des ensembles FHIR de type `batch` ou`transaction`, ce qui vous permet de combiner des opérations de correctif avec d'autres interactions FHIR (création, lecture, mise à jour, suppression) dans une seule demande.
+ **Packs de transactions** : toutes les entrées réussissent ou échouent de manière atomique
+ **Batch bundles** : chaque entrée est traitée indépendamment
## Format de correctif JSON
### Opérations prises en charge
| Opération | Description |
| --- | --- |
| add | Ajouter une nouvelle valeur à la ressource |
| remove | Supprimer une valeur de la ressource |
| replace | Remplacer une valeur existante dans la ressource |
| move | Supprimer une valeur d'un emplacement et l'ajouter à un autre |
| copy | Copier une valeur d'un emplacement à un autre |
| test | Vérifiez qu'une valeur à l'emplacement cible est égale à une valeur spécifiée |
### Syntaxe du chemin
Le patch JSON utilise la syntaxe du pointeur JSON (RFC 6901) :
| Exemple de chemin | Description |
| --- | --- |
| /name/0/family | Élément de famille du prénom |
| /telecom/- | Ajouter au réseau de télécommunications |
| /active | Élément actif au niveau de la racine |
| /address/0/line/1 | Deuxième ligne de la première adresse |
### Exemples
**Demande de correctif JSON directe avec plusieurs opérations**
```
PATCH [base]/Patient/example
Content-Type: application/json-patch+json
If-Match: W/"1"
[
{
"op": "replace",
"path": "/name/0/family",
"value": "Smith"
},
{
"op": "add",
"path": "/telecom/-",
"value": {
"system": "phone",
"value": "555-555-5555",
"use": "home"
}
},
{
"op": "remove",
"path": "/address/0"
},
{
"op": "move",
"from": "/name/0/family",
"path": "/name/1/family"
},
{
"op": "test",
"path": "/gender",
"value": "male"
},
{
"op": "copy",
"from": "/name/0",
"path": "/name/1"
}
]
```
**Demande de correctif JSON directe avec une seule opération**
```
PATCH [base]/Patient/example
Content-Type: application/json-patch+json
[
{
"op": "replace",
"path": "/active",
"value": false
}
]
```
**Patch JSON dans le bundle**
Utilisez une ressource binaire contenant la charge utile du patch JSON codé en base64 :
```
{
"resourceType": "Bundle",
"type": "transaction",
"entry": [{
"resource": {
"resourceType": "Binary",
"contentType": "application/json-patch+json",
"data": "W3sib3AiOiJhZGQiLCJwYXRoIjoiL2JpcnRoRGF0ZSIsInZhbHVlIjoiMTk5MC0wMS0wMSJ9XQ=="
},
"request": {
"method": "PATCH",
"url": "Patient/123"
}
}]
}
```
## FHIRPath Format du correctif
### Opérations prises en charge
| Opération | Description |
| --- | --- |
| add | Ajouter un nouvel élément à une ressource |
| insert | Insérer un élément à un endroit précis dans une liste |
| delete | Supprimer un élément d'une ressource |
| replace | Remplacer la valeur d'un élément existant |
| move | Réorganiser les éléments d'une liste |
### Syntaxe du chemin
FHIRPath Le correctif utilise des FHIRPath expressions prenant en charge :
+ **Accès basé sur un index** : `Patient.name[0]`
+ **Filtrer avec `where()`** : `Patient.name.where(use = 'official')`
+ **Logique booléenne** : `Patient.telecom.where(system = 'phone' and use = 'work')`
+ **Fonctions de sous-définition** :`first()`, `last()`
+ **Contrôles d'existence** :`exists()`, `count()`
+ **Navigation polymorphe** : `Observation.value`
### Exemples
**Demande de FHIRPath correctif directe**
```
PATCH [base]/Patient/123
Content-Type: application/fhir+json
Authorization: ...
{
"resourceType": "Parameters",
"parameter": [{
"name": "operation",
"part": [
{ "name": "type", "valueCode": "add" },
{ "name": "path", "valueString": "Patient" },
{ "name": "name", "valueString": "birthDate" },
{ "name": "value", "valueDate": "1990-01-01" }
]
}]
}
```
**FHIRPath Patch dans le bundle**
Utilisez une ressource Parameters comme ressource d'entrée avec `method: PATCH` :
```
{
"resourceType": "Bundle",
"type": "transaction",
"entry": [{
"resource": {
"resourceType": "Parameters",
"parameter": [{
"name": "operation",
"part": [
{ "name": "type", "valueCode": "add" },
{ "name": "path", "valueString": "Patient" },
{ "name": "name", "valueString": "birthDate" },
{ "name": "value", "valueDate": "1990-01-01" }
]
}]
},
"request": {
"method": "PATCH",
"url": "Patient/123"
}
}]
}
```
## En-têtes de demande
| En-tête | Obligatoire | Description |
| --- | --- | --- |
| Content-Type | Oui | application/json-patch\$1jsonpour JSON Patch ou application/fhir\$1json pour FHIRPath Patch |
| If-Match | Non | Mise à jour conditionnelle spécifique à la version à l'aide de ETag |
## Exemple de réponse
L'opération renvoie la ressource mise à jour avec les nouvelles informations de version :
```
HTTP/1.1 200 OK
Content-Type: application/fhir+json
ETag: W/"2"
Last-Modified: Mon, 05 May 2025 10:10:10 GMT
{
"resourceType": "Patient",
"id": "example",
"active": true,
"name": [
{
"family": "Smith",
"given": ["John"]
}
],
"telecom": [
{
"system": "phone",
"value": "555-555-5555",
"use": "home"
}
],
"meta": {
"versionId": "2",
"lastUpdated": "2025-05-05T10:10:10Z"
}
}
```
## Comportement
L'opération PATCH :
+ Valide la syntaxe du correctif conformément à la spécification appropriée (RFC 6902 pour le correctif JSON, FHIR R4 pour le correctif) FHIRPath
+ Applique les opérations de manière atomique : toutes les opérations réussissent ou échouent
+ Met à jour l'ID de version de la ressource et crée une nouvelle entrée d'historique
+ Préserve la ressource d'origine dans l'historique avant d'appliquer les modifications
+ Valide les contraintes de ressources FHIR après l'application des correctifs
+ Supporte les mises à jour conditionnelles à l'aide de l'en-tête If-Match avec ETag
## Gestion des erreurs
L'opération gère les conditions d'erreur suivantes :
+ **400 Mauvaise demande** : syntaxe de correctif non valide (demande non conforme ou document de correctif mal formé)
+ **404 Introuvable** : ressource introuvable (l'ID spécifié n'existe pas)
+ **409 Conflit : conflit** de version (mises à jour simultanées ou identifiant de version non actuel fourni)
+ **422 Entité non traitable** : les opérations de correctif ne peuvent pas être appliquées aux éléments de ressource spécifiés
## Résumé des capacités
| Capacité | Correctif JSON | FHIRPath Patch |
| --- | --- | --- |
| Type de contenu | application/json-patch\$1json | application/fhir\$1json |
| Format du chemin | Pointeur JSON (RFC 6901) | FHIRPath expressions |
| API PATCH directe | Pris en charge | Pris en charge |
| Bundle Batch | Pris en charge (via le binaire) | Pris en charge (via les paramètres) |
| Transaction groupée | Pris en charge (via le binaire) | Pris en charge (via les paramètres) |
| Opérations | ajouter, supprimer, remplacer, déplacer, copier, tester | ajouter, insérer, supprimer, remplacer, déplacer |
## Limitations
+ Les opérations PATCH conditionnelles utilisant des conditions de recherche ne sont pas prises en charge
+ Les patchs JSON intégrés aux bundles doivent utiliser des ressources binaires avec un contenu codé en base64
+ FHIRPath Les packs de patchs doivent utiliser les ressources de paramètres
## Ressources supplémentaires
Pour plus d'informations sur les opérations PATCH, voir :
+ [Documentation du PATCH FHIR R4](https://hl7.org/fhir/http.html#patch)
+ [Spécification du patch FHIR R4 FHIRPath ](https://hl7.org/fhir/fhirpatch.html)
+ [RFC 6902 - Correctif JSON](https://datatracker.ietf.org/doc/html/rfc6902#section-4)
+ [RFC 6901 - Pointeur JSON](https://datatracker.ietf.org/doc/html/rfc6901)
# Regroupement des ressources FHIR
Un FHIR `Bundle` est un conteneur contenant une collection de ressources FHIR. AWS HealthLake AWS HealthLake prend en charge deux types de bundles avec des comportements de traitement différents.
[https://hl7.org/fhir/R4/http.html#transaction](https://hl7.org/fhir/R4/http.html#transaction)les bundles traitent chaque ressource indépendamment. Si l'une des ressources échoue, les ressources restantes peuvent toujours réussir. Chaque opération est traitée individuellement et le traitement se poursuit même en cas d'échec de certaines opérations. Utilisez des lots pour les opérations groupées où un succès partiel est acceptable, comme le téléchargement de plusieurs dossiers de patients indépendants.
[https://hl7.org/fhir/R4/http.html#transaction](https://hl7.org/fhir/R4/http.html#transaction)les bundles traitent toutes les ressources de manière atomique comme une seule unité. Soit toutes les opérations sur les ressources réussissent, soit aucune d' AWS HealthLake entre elles n'est validée. Utilisez des ensembles de transactions lorsque vous avez besoin de garantir l'intégrité référentielle des ressources connexes, par exemple pour créer un patient présentant des observations et des affections connexes où toutes les données doivent être enregistrées ensemble.
**Différences entre les lots et les ensembles de transactions**
| Fonctionnalité | Par lots | Transaction |
| --- | --- | --- |
| Modèle de traitement | Chaque opération réussit ou échoue indépendamment. | Toutes les opérations réussissent ou échouent en tant qu'unité atomique unique. |
| Gestion des défaillances | Le traitement se poursuit même en cas d'échec des opérations individuelles. | L'ensemble échoue en cas d'échec d'une seule opération. |
| Ordre d'exécution | L'ordre d'exécution n'est pas garanti. | Les opérations sont traitées dans l'ordre indiqué. |
| Intégrité référentielle | Non appliqué dans toutes les opérations. | Appliqué pour les ressources référencées localement au sein du bundle. |
| Utiliser en priorité pour | Opérations groupées pour lesquelles un succès partiel est acceptable. | Ressources connexes qui doivent être créées ou mises à jour ensemble. |
Vous pouvez regrouper des ressources FHIR de types identiques ou différents, et elles peuvent inclure une combinaison d'opérations FHIR, telles que`create`,, `read` `update``delete`, et. `patch` Pour plus d'informations, consultez le [pack de ressources](https://hl7.org/fhir/R4/Bundle) dans la documentation du **FHIR R4**.
Voici des exemples de cas d'utilisation pour chaque type de bundle.
Packs Batch
+ Téléchargez plusieurs dossiers de patients indépendants provenant de différents établissements lors de la synchronisation nocturne des données.
+ Téléchargez en masse l'historique des médicaments lorsque certains dossiers peuvent présenter des problèmes de validation.
+ Chargez des données de référence, telles que les organisations et les professionnels, où les défaillances individuelles n'affectent pas les autres entrées.
Packs de transactions
+ Créez un patient présentant des observations et des affections connexes lors d'une admission au service des urgences, où toutes les données doivent être enregistrées ensemble.
+ Mettez à jour la liste des médicaments d'un patient et les informations connexes sur les allergies qui doivent rester cohérentes.
+ Enregistrez une rencontre complète avec le patient, les observations, les procédures et les informations de facturation dans une seule unité atomique.
**Important**
Les ensembles de lots et de transactions utilisent la même structure de `Bundle` ressources. La seule différence réside dans la valeur du `type` champ.
L'exemple suivant montre un ensemble de transactions comprenant plusieurs types de ressources et opérations.
```
{
"resourceType": "Bundle",
"type": "transaction",
"entry": [
{
"fullUrl": "urn:uuid:4f6a30fb-cd3c-4ab6-8757-532101f72065",
"resource": {
"resourceType": "Patient",
"id": "new-patient",
"active": true,
"name": [
{
"family": "Johnson",
"given": [
"Sarah"
]
}
],
"gender": "female",
"birthDate": "1985-08-12",
"telecom": [
{
"system": "phone",
"value": "555-123-4567",
"use": "home"
}
]
},
"request": {
"method": "POST",
"url": "Patient"
}
},
{
"fullUrl": "urn:uuid:7f83f473-d8cc-4a8d-86d3-9d9876a3248b",
"resource": {
"resourceType": "Observation",
"id": "blood-pressure",
"status": "final",
"code": {
"coding": [
{
"system": "http://loinc.org",
"code": "85354-9",
"display": "Blood pressure panel"
}
],
"text": "Blood pressure panel"
},
"subject": {
"reference": "urn:uuid:4f6a30fb-cd3c-4ab6-8757-532101f72065"
},
"effectiveDateTime": "2023-10-15T09:30:00Z",
"component": [
{
"code": {
"coding": [
{
"system": "http://loinc.org",
"code": "8480-6",
"display": "Systolic blood pressure"
}
]
},
"valueQuantity": {
"value": 120,
"unit": "mmHg",
"system": "http://unitsofmeasure.org",
"code": "mm[Hg]"
}
},
{
"code": {
"coding": [
{
"system": "http://loinc.org",
"code": "8462-4",
"display": "Diastolic blood pressure"
}
]
},
"valueQuantity": {
"value": 80,
"unit": "mmHg",
"system": "http://unitsofmeasure.org",
"code": "mm[Hg]"
}
}
]
},
"request": {
"method": "POST",
"url": "Observation"
}
},
{
"resource": {
"resourceType": "Appointment",
"id": "appointment-123",
"status": "booked",
"description": "Annual physical examination",
"start": "2023-11-15T09:00:00Z",
"end": "2023-11-15T09:30:00Z",
"participant": [
{
"actor": {
"reference": "urn:uuid:4f6a30fb-cd3c-4ab6-8757-532101f72065"
},
"status": "accepted"
}
]
},
"request": {
"method": "PUT",
"url": "Appointment/appointment-123"
}
},
{
"request": {
"method": "DELETE",
"url": "MedicationRequest/med-request-456"
}
}
]
}
```
## Regrouper les ressources du FHIR en tant qu'entités indépendantes
**Regrouper les ressources FHIR en tant qu'entités indépendantes**
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. Créez une URL pour la demande en utilisant les valeurs collectées pour HealthLake `region` et`datastoreId`. Ne spécifiez *pas* de type de ressource 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**.
```
POST https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/
```
1. Construisez un corps JSON pour la demande, en spécifiant chaque verbe HTTP comme faisant partie des `method` éléments. L'exemple suivant utilise une interaction `batch` de type avec la `Bundle` ressource pour créer de nouvelles `Medication` ressources `Patient` et. Toutes les sections requises sont commentées en conséquence. Dans le cadre de cette procédure, enregistrez le fichier sous`batch-independent.json`.
```
{
"resourceType": "Bundle",
"id": "bundle-batch",
"meta": {
"lastUpdated": "2014-08-18T01:43:30Z"
},
"type": "batch",
"entry": [
{
"resource": {
"resourceType": "Patient",
"meta": {
"lastUpdated": "2022-06-03T17:53:36.724Z"
},
"text": {
"status": "generated",
"div": "Some narrative"
},
"active": true,
"name": [
{
"use": "official",
"family": "Jackson",
"given": [
"Mateo",
"James"
]
}
],
"gender": "male",
"birthDate": "1974-12-25"
},
"request": {
"method": "POST",
"url": "Patient"
}
},
{
"resource": {
"resourceType": "Medication",
"id": "med0310",
"contained": [
{
"resourceType": "Substance",
"id": "sub03",
"code": {
"coding": [
{
"system": "http://snomed.info/sct",
"code": "55452001",
"display": "Oxycodone (substance)"
}
]
}
}
],
"code": {
"coding": [
{
"system": "http://snomed.info/sct",
"code": "430127000",
"display": "Oral Form Oxycodone (product)"
}
]
},
"form": {
"coding": [
{
"system": "http://snomed.info/sct",
"code": "385055001",
"display": "Tablet dose form (qualifier value)"
}
]
},
"ingredient": [
{
"itemReference": {
"reference": "#sub03"
},
"strength": {
"numerator": {
"value": 5,
"system": "http://unitsofmeasure.org",
"code": "mg"
},
"denominator": {
"value": 1,
"system": "http://terminology.hl7.org/CodeSystem/v3-orderableDrugForm",
"code": "TAB"
}
}
}
]
},
"request": {
"method": "POST",
"url": "Medication"
}
}
]
}
```
1. Envoyez la demande . Le type de `Bundle` lot FHIR utilise une `POST` demande avec [AWS signature version 4](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) ou SMART sur autorisation FHIR. L'exemple de code suivant utilise l'outil de ligne de `curl` commande à des fins de démonstration.
------
#### [ SigV4 ]
Autorisation SigV4
```
curl --request POST \
'https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/' \
--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' \
--data @batch-type.json
```
------
#### [ SMART on FHIR ]
Exemple d'autorisation SMART sur FHIR pour le 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.
```
{
"AuthorizationStrategy": "SMART_ON_FHIR",
"FineGrainedAuthorizationEnabled": true,
"IdpLambdaArn": "arn:aws:lambda:your-region:your-account-id:function:your-lambda-name",
"Metadata": "{\"issuer\":\"https://ehr.example.com\", \"jwks_uri\":\"https://ehr.example.com/.well-known/jwks.json\",\"authorization_endpoint\":\"https://ehr.example.com/auth/authorize\",\"token_endpoint\":\"https://ehr.token.com/auth/token\",\"token_endpoint_auth_methods_supported\":[\"client_secret_basic\",\"foo\"],\"grant_types_supported\":[\"client_credential\",\"foo\"],\"registration_endpoint\":\"https://ehr.example.com/auth/register\",\"scopes_supported\":[\"openId\",\"profile\",\"launch\"],\"response_types_supported\":[\"code\"],\"management_endpoint\":\"https://ehr.example.com/user/manage\",\"introspection_endpoint\":\"https://ehr.example.com/user/introspect\",\"revocation_endpoint\":\"https://ehr.example.com/user/revoke\",\"code_challenge_methods_supported\":[\"S256\"],\"capabilities\":[\"launch-ehr\",\"sso-openid-connect\",\"client-public\",\"permission-v2\"]}"
}
```
L'appelant peut attribuer des autorisations dans le lambda d'autorisation. Pour de plus amples informations, veuillez consulter [OAuth Éscopes 2.0](reference-smart-on-fhir-oauth-scopes.md).
------
Le serveur renvoie une réponse indiquant les `Medication` ressources `Patient` et créées à la suite de la demande de type de `Bundle` lot.
## Conditionnel PUTs en lots
AWS HealthLake prend en charge les mises à jour conditionnelles au sein des bundles à l'aide des paramètres de requête suivants :
+ `_id`(autonome)
+ `_id`en combinaison avec l'un des éléments suivants :
+ `_tag`
+ `_createdAt`
+ `_lastUpdated`
Lorsque vous utilisez le conditionnel PUTs dans les bundles, vous AWS HealthLake évaluez les paramètres de requête par rapport aux ressources existantes et prenez des mesures en fonction des résultats du match.
**Comportement des mises à jour**
| Scénario | Statut HTTP | Mesures prises |
| --- | --- | --- |
| Ressource sans identifiant fourni | 201 créés | Crée toujours une nouvelle ressource. |
| Ressource avec un nouvel identifiant (aucune correspondance) | 201 créés | Crée une nouvelle ressource avec l'ID spécifié. |
| Ressource avec identifiant existant (correspondance unique) | 200 OK | Met à jour la ressource correspondante. |
| Ressource avec identifiant existant (conflit détecté) | 409 – Conflit | Renvoie une erreur. Aucune modification n'est apportée. |
| Ressource avec ID existant (ID non concordant) | 400 Requête erronée | Renvoie une erreur. Aucune modification n'est apportée. |
| Plusieurs ressources correspondent aux conditions | 412 – Échec de condition préalable | Renvoie une erreur. Aucune modification n'est apportée. |
Dans l'exemple de bundle suivant avec une mise à jour conditionnelle, la `Patient` ressource avec un identifiant FHIR est mise `476` à jour uniquement si la condition `_lastUpdated=lt2025-04-20` est remplie.
```
{
"resourceType": "Bundle",
"id": "bundle-batch",
"meta": {
"lastUpdated": "2014-08-18T01:43:30Z"
},
"type": "batch",
"entry": [
{
"resource": {
"resourceType": "Patient",
"id": "476",
"meta": {
"lastUpdated": "2022-06-03T17:53:36.724Z"
},
"active": true,
"name": [
{
"use": "official",
"family": "Jackson",
"given": [
"Mateo",
"James"
]
}
],
"gender": "male",
"birthDate": "1974-12-25"
},
"request": {
"method": "PUT",
"url": "Patient?_id=476&_lastUpdated=lt2025-04-20"
}
},
{
"resource": {
"resourceType": "Medication",
"id": "med0310",
"contained": [
{
"resourceType": "Substance",
"id": "sub03",
"code": {
"coding": [
{
"system": "http://snomed.info/sct",
"code": "55452001",
"display": "Oxycodone (substance)"
}
]
}
}
],
"code": {
"coding": [
{
"system": "http://snomed.info/sct",
"code": "430127000",
"display": "Oral Form Oxycodone (product)"
}
]
},
"form": {
"coding": [
{
"system": "http://snomed.info/sct",
"code": "385055001",
"display": "Tablet dose form (qualifier value)"
}
]
},
"ingredient": [
{
"itemReference": {
"reference": "#sub03"
},
"strength": {
"numerator": {
"value": 5,
"system": "http://unitsofmeasure.org",
"code": "mg"
},
"denominator": {
"value": 1,
"system": "http://terminology.hl7.org/CodeSystem/v3-orderableDrugForm",
"code": "TAB"
}
}
}
]
},
"request": {
"method": "POST",
"url": "Medication"
}
}
]
}
```
## Regroupement des ressources FHIR en une seule entité
**Regrouper les ressources FHIR en une seule entité**
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. Créez une URL pour la demande en utilisant les valeurs collectées pour HealthLake `region` et`datastoreId`. Incluez le type `Bundle` de ressource 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**.
```
POST https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Bundle
```
1. Construisez un corps JSON pour la demande, en spécifiant les ressources FHIR à regrouper. L'exemple suivant regroupe deux `Patient` ressources dans HealthLake. Dans le cadre de cette procédure, enregistrez le fichier sous`batch-single.json`.
```
{
"resourceType": "Bundle",
"id": "bundle-minimal",
"language": "en-US",
"identifier": {
"system": "urn:oid:1.2.3.4.5",
"value": "28b95815-76ce-457b-b7ae-a972e527db4f"
},
"type": "document",
"timestamp": "2020-12-11T14:30:00+01:00",
"entry": [
{
"fullUrl": "urn:uuid:f40b07e3-37e8-48c3-bf1c-ae70fe12dabf",
"resource": {
"resourceType": "Composition",
"id": "f40b07e3-37e8-48c3-bf1c-ae70fe12dabf",
"status": "final",
"type": {
"coding": [
{
"system": "http://loinc.org",
"code": "60591-5",
"display": "Patient summary Document"
}
]
},
"date": "2020-12-11T14:30:00+01:00",
"author": [
{
"reference": "urn:uuid:45271f7f-63ab-4946-970f-3daaaa0663ff"
}
],
"title": "Patient Summary as of December 7, 2020 14:30"
}
},
{
"fullUrl": "urn:uuid:45271f7f-63ab-4946-970f-3daaaa0663ff",
"resource": {
"resourceType": "Practitioner",
"id": "45271f7f-63ab-4946-970f-3daaaa0663ff",
"active": true,
"name": [
{
"family": "Doe",
"given": [
"John"
]
}
]
}
}
]
}
```
1. Envoyez la demande . Le type de `Bundle` document FHIR utilise une `POST` demande avec le protocole de [AWS signature Signature Version 4](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html). L'exemple de code suivant utilise l'outil de ligne de `curl` commande à des fins de démonstration.
------
#### [ SigV4 ]
Autorisation SigV4
```
curl --request POST \
'https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Bundle' \
--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' \
--data @document-type.json
```
------
#### [ SMART on FHIR ]
Exemple d'autorisation SMART sur FHIR pour le 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.
```
{
"AuthorizationStrategy": "SMART_ON_FHIR",
"FineGrainedAuthorizationEnabled": true,
"IdpLambdaArn": "arn:aws:lambda:your-region:your-account-id:function:your-lambda-name",
"Metadata": "{\"issuer\":\"https://ehr.example.com\", \"jwks_uri\":\"https://ehr.example.com/.well-known/jwks.json\",\"authorization_endpoint\":\"https://ehr.example.com/auth/authorize\",\"token_endpoint\":\"https://ehr.token.com/auth/token\",\"token_endpoint_auth_methods_supported\":[\"client_secret_basic\",\"foo\"],\"grant_types_supported\":[\"client_credential\",\"foo\"],\"registration_endpoint\":\"https://ehr.example.com/auth/register\",\"scopes_supported\":[\"openId\",\"profile\",\"launch\"],\"response_types_supported\":[\"code\"],\"management_endpoint\":\"https://ehr.example.com/user/manage\",\"introspection_endpoint\":\"https://ehr.example.com/user/introspect\",\"revocation_endpoint\":\"https://ehr.example.com/user/revoke\",\"code_challenge_methods_supported\":[\"S256\"],\"capabilities\":[\"launch-ehr\",\"sso-openid-connect\",\"client-public\",\"permission-v2\"]}"
}
```
L'appelant peut attribuer des autorisations dans le lambda d'autorisation. Pour de plus amples informations, veuillez consulter [OAuth Éscopes 2.0](reference-smart-on-fhir-oauth-scopes.md).
------
Le serveur renvoie une réponse indiquant deux `Patient` ressources créées suite à la demande de type de `Bundle` document.
## Configuration du niveau de validation pour les bundles
Lorsque vous regroupez des ressources FHIR, vous pouvez éventuellement spécifier un en-tête `x-amzn-healthlake-fhir-validation-level` HTTP pour configurer un niveau de validation pour la ressource. Ce niveau de validation sera défini pour toutes les demandes de création et de mise à jour du bundle. AWS HealthLake prend actuellement en charge les niveaux de validation suivants :
+ `strict`: Les ressources sont validées en fonction de l'élément de profil de la ressource ou de la spécification R4 si aucun profil n'est présent. Il s'agit du niveau de validation par défaut pour AWS HealthLake.
+ `structure-only`: Les ressources sont validées par rapport à R4, en ignorant les profils référencés.
+ `minimal`: Les ressources sont validées de manière minimale, sans tenir compte de certaines règles R4. Les ressources qui échouent aux vérifications de structure requises search/analytics seront mises à jour pour inclure un avertissement d'audit.
Les ressources groupées avec le niveau de validation minimal peuvent être ingérées dans une banque de données malgré l'échec de la validation requise pour l'indexation des recherches. Dans ce cas, les ressources seront mises à jour pour inclure une extension spécifique à Healthlake afin de documenter ces échecs, et les entrées de la réponse du bundle incluront les OperationOutcome ressources suivantes :
```
{
"resourceType": "Bundle",
"type": "batch-response",
"timestamp": "2025-08-25T22:58:48.846287342Z",
"entry": [
{
"response": {
"status": "201",
"location": "Patient/195abc49-ba8e-4c8b-95c2-abc88fef7544/_history/1",
"etag": "W/\"1\"",
"lastModified": "2025-08-25T22:58:48.801245445Z",
"outcome": {
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "processing",
"details": {
"text": "FHIR resource in payload failed FHIR validation rules."
},
"diagnostics": "FHIR resource in payload failed FHIR validation rules."
}
]
}
}
}
]
}
```
En outre, l'en-tête de réponse HTTP suivant sera inclus avec la valeur « true » :
```
x-amzn-healthlake-validation-issues : true
```
**Note**
Notez que les données ingérées qui sont mal formées conformément à la spécification R4 peuvent ne pas être consultables comme prévu si ces erreurs sont présentes.
## Support limité pour le type « message » de type Bundle
HealthLake fournit un support limité pour le type de bundle FHIR `message` par le biais d'un processus de conversion interne. Cette prise en charge est conçue pour les scénarios dans lesquels les ensembles de messages ne peuvent pas être reformatés à la source, tels que l'ingestion de flux ADT (admission, sortie, transfert) provenant des anciens systèmes hospitaliers.
**Avertissement**
Cette fonctionnalité nécessite une liste explicite des AWS comptes autorisés et n'applique pas la sémantique des messages FHIR R4 ni l'intégrité référentielle. Contactez AWS le Support pour demander l'activation de votre compte avant d'utiliser des ensembles de messages.
### Principales différences par rapport au traitement standard des messages
+ **Ensembles de messages** (spécification FHIR) : La première entrée doit être une `MessageHeader` qui fait référence à d'autres ressources. Les ressources ne disposent pas `request` d'objets individuels, et l' MessageHeader événement détermine les actions de traitement.
+ **HealthLake Traitement** : convertit les ensembles de messages en ensembles par lots en affectant automatiquement des opérations PUT à chaque entrée de ressource. Les ressources sont traitées indépendamment sans appliquer la sémantique des messages ou l'intégrité référentielle.
### Limitations importantes
+ FHIR R4 Les règles de traitement spécifiques aux messages ne sont pas appliquées
+ Aucune intégrité transactionnelle entre les ressources
+ Les références inter-ressources ne sont pas validées
+ Nécessite une liste explicite des comptes autorisés
### Exemple de structure de bundle de messages
```
{
"resourceType": "Bundle",
"type": "message",
"entry": [
{
"resource": {
"resourceType": "MessageHeader",
"eventCoding": {
"system": "http://hl7.org/fhir/us/davinci-alerts/CodeSystem/notification-event",
"code": "notification-admit"
},
"focus": [{"reference": "Encounter/example-id"}]
}
},
{
"resource": {"resourceType": "Patient", "id": "example-id"}
},
{
"resource": {"resourceType": "Encounter", "id": "example-id"}
}
]
}
```
**Note**
Chaque ressource est stockée indépendamment, comme si elle était soumise via des opérations PUT individuelles. Si une sémantique complète de la messagerie FHIR ou une validation de l'intégrité référentielle sont requises, prétraitez les ensembles de messages ou implémentez une validation au niveau de l'application avant de les soumettre.
## Transactions groupées asynchrones
AWS HealthLake prend en charge le `Bundle` type asynchrone `transaction` qui vous permet de soumettre des transactions avec un maximum de 500 ressources. Lorsque vous soumettez une transaction asynchrone, mettez-la en HealthLake file d'attente pour traitement et renvoyez immédiatement une URL d'interrogation. Vous pouvez utiliser cette URL pour vérifier le statut et récupérer la réponse. Cela suit le modèle de [bundle asynchrone FHIR](https://hl7.org/fhir/async-bundle.html).
**Quand utiliser les transactions asynchrones**
+ Vous devez soumettre plus de 100 ressources (limite synchrone) en une seule transaction.
+ Vous voulez éviter de bloquer votre application en attendant la fin du traitement de la transaction.
+ Vous devez traiter de gros volumes de ressources connexes avec un meilleur débit.
**Important**
Les résultats du sondage sont disponibles pendant 90 jours après la fin de la transaction. Après cette période de 90 jours, l'URL du sondage ne renvoie plus de résultats. Concevez votre intégration pour récupérer et stocker les résultats dans cette fenêtre.
**Note**
`transaction`Le `Bundle` type synchrone continue de prendre en charge jusqu'à 100 ressources et constitue le mode de traitement par défaut. Si vous soumettez un `Bundle` type `transaction` contenant plus de 100 ressources sans `Prefer: respond-async` en-tête, HealthLake renvoie une `422 Unprocessable Entity` erreur. Les ensembles avec type ne `batch` sont pas pris en charge pour le traitement asynchrone : seul le `Bundle` type `transaction` peut être soumis de manière asynchrone (avec un maximum de 500 opérations).
### Soumission d'une transaction asynchrone
Pour soumettre une transaction asynchrone, envoyez une `POST` demande au point de terminaison du magasin de données avec l'`Prefer: respond-async`en-tête. Le bundle doit avoir un type`transaction`. Les ensembles avec type ne `batch` sont pas pris en charge pour le traitement asynchrone des ensembles.
HealthLake effectue les validations initiales du bundle au moment de la soumission. Si la validation aboutit, HealthLake renvoie HTTP 202 Accepted avec un en-tête de `content-location` réponse contenant l'URL d'interrogation.
**Pour soumettre un type asynchrone `Bundle` `transaction`**
1. Envoyez une `POST` demande au point de terminaison du magasin de HealthLake données.
```
POST https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/
```
1. Construisez un corps JSON pour la demande avec le type de bundle`transaction`. Dans le cadre de cette procédure, enregistrez le fichier sous`async-transaction.json`.
```
{
"resourceType": "Bundle",
"type": "transaction",
"entry": [
{
"resource": {
"resourceType": "Patient",
"active": true,
"name": [
{
"use": "official",
"family": "Smith",
"given": ["Jane"]
}
],
"gender": "female",
"birthDate": "1990-01-15"
},
"request": {
"method": "POST",
"url": "Patient"
}
},
{
"resource": {
"resourceType": "Observation",
"status": "final",
"code": {
"coding": [
{
"system": "http://loinc.org",
"code": "85354-9",
"display": "Blood pressure panel"
}
]
},
"subject": {
"reference": "urn:uuid:example-patient-id"
}
},
"request": {
"method": "POST",
"url": "Observation"
}
}
]
}
```
1. Envoyez la demande avec l'`Prefer: respond-async`en-tête. Le type de `Bundle` transaction FHIR utilise une `POST` demande avec [AWS signature version 4](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) ou une autorisation SMART on FHIR. L'exemple de code suivant utilise l'outil de ligne de `curl` commande à des fins de démonstration.
------
#### [ SigV4 ]
Autorisation SigV4
```
curl --request POST \
'https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/' \
--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' \
--header 'Prefer: respond-async' \
--data @async-transaction.json
```
------
#### [ SMART on FHIR ]
Exemple d'autorisation SMART sur FHIR pour le 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.
```
{
"AuthorizationStrategy": "SMART_ON_FHIR",
"FineGrainedAuthorizationEnabled": true,
"IdpLambdaArn": "arn:aws:lambda:your-region:your-account-id:function:your-lambda-name",
"Metadata": "{\"issuer\":\"https://ehr.example.com\", \"jwks_uri\":\"https://ehr.example.com/.well-known/jwks.json\",\"authorization_endpoint\":\"https://ehr.example.com/auth/authorize\",\"token_endpoint\":\"https://ehr.token.com/auth/token\",\"token_endpoint_auth_methods_supported\":[\"client_secret_basic\",\"foo\"],\"grant_types_supported\":[\"client_credential\",\"foo\"],\"registration_endpoint\":\"https://ehr.example.com/auth/register\",\"scopes_supported\":[\"openId\",\"profile\",\"launch\"],\"response_types_supported\":[\"code\"],\"management_endpoint\":\"https://ehr.example.com/user/manage\",\"introspection_endpoint\":\"https://ehr.example.com/user/introspect\",\"revocation_endpoint\":\"https://ehr.example.com/user/revoke\",\"code_challenge_methods_supported\":[\"S256\"],\"capabilities\":[\"launch-ehr\",\"sso-openid-connect\",\"client-public\",\"permission-v2\"]}"
}
```
L'appelant peut attribuer des autorisations dans le lambda d'autorisation. Pour de plus amples informations, veuillez consulter [OAuth Éscopes 2.0](reference-smart-on-fhir-oauth-scopes.md).
------
1. En cas de soumission réussie, le serveur renvoie HTTP 202 Accepted. L'en-tête de `content-location` réponse contient l'URL du sondage. L'organisme de réponse est une `OperationOutcome` ressource.
```
HTTP/1.1 202 Accepted
content-location: https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Transaction/transactionId
```
```
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "information",
"code": "informational",
"diagnostics": "Submitted Asynchronous Bundle Transaction",
"location": [
"https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Transaction/transactionId"
]
}
]
}
```
### Sondage de l'état de la transaction
Après avoir soumis une transaction asynchrone, utilisez l'URL de sondage figurant dans l'en-tête de `content-location` réponse pour vérifier le statut de la transaction. Envoyez une `GET` demande à l'URL du sondage.
**Note**
Pour les magasins de données compatibles SMART sur FHIR, le jeton d'autorisation doit inclure `read` des autorisations sur le type de `Transaction` ressource pour demander l'état de la transaction. Pour plus d'informations sur SMART sur les oscilloscopes FHIR, consultez. [SMART sur les oscilloscopes FHIR OAuth 2.0 pris en charge par HealthLake](reference-smart-on-fhir-oauth-scopes.md)
Envoyez une `GET` demande à l'URL du sondage. L'exemple suivant utilise l'outil de ligne de `curl` commande.
------
#### [ SigV4 ]
Autorisation SigV4
```
curl --request GET \
'https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Transaction/transactionId' \
--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'
```
------
#### [ SMART on FHIR ]
Autorisation SMART sur FHIR. Le jeton d'autorisation doit inclure `read` des autorisations sur le type de `Transaction` ressource.
```
curl --request GET \
'https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Transaction/transactionId' \
--header 'Authorization: Bearer $SMART_ACCESS_TOKEN' \
--header 'Accept: application/json'
```
------
Le tableau suivant décrit les réponses possibles.
**Codes de réponse aux sondages**
| Statut HTTP | Signification | Corps de la réponse |
| --- | --- | --- |
| 202 Accepté | La transaction est en file d'attente | OperationOutcomeavec diagnostic « SOUMIS » |
| 202 Accepté | La transaction est en cours de traitement | OperationOutcomeavec diagnostic « IN\$1PROGRESS » |
| 200 OK | Transaction terminée avec succès | Bundleavec type transaction-response |
| 4xx/5xx | Échec de la transaction | OperationOutcomeavec les détails de l'erreur |
Les exemples suivants montrent chaque type de réponse.
**Transaction en file d'attente (202)**
```
{
"resourceType": "OperationOutcome",
"id": "transactionId",
"issue": [
{
"severity": "information",
"code": "informational",
"diagnostics": "SUBMITTED"
}
]
}
```
**Traitement des transactions (202)**
```
{
"resourceType": "OperationOutcome",
"id": "transactionId",
"issue": [
{
"severity": "information",
"code": "informational",
"diagnostics": "IN_PROGRESS"
}
]
}
```
**Transaction terminée (200)**
```
{
"resourceType": "Bundle",
"type": "transaction-response",
"entry": [
{
"response": {
"status": "201",
"location": "Patient/example-id/_history/1",
"etag": "W/\"1\"",
"lastModified": "2024-01-15T10:30:00.000Z"
}
},
{
"response": {
"status": "201",
"location": "Observation/example-id/_history/1",
"etag": "W/\"1\"",
"lastModified": "2024-01-15T10:30:00.000Z"
}
}
]
}
```
**Échec de la transaction (4xx/5xx)**
```
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "exception",
"diagnostics": "Transaction failed: conflict detected on resource Patient/example-id"
}
]
}
```
### Commande en cours
Les ensembles de type asynchrone sont mis en file d'attente mais ne `transaction` sont pas traités dans un ordre de soumission strict. HealthLake optimise le traitement en fonction de la capacité disponible et de la charge du système.
**Important**
Ne vous fiez pas au traitement des transactions dans l'ordre dans lequel elles ont été soumises. Par exemple, si vous soumettez la transaction A à 10 h 00 et la transaction B à 10 h 01, la transaction B peut être terminée avant la transaction A. Concevez votre application pour :
Terminez out-of-order la manipulation.
Utilisez l'URL du sondage pour suivre chaque transaction indépendamment.
Mettez en œuvre le séquençage au niveau de l'application si la commande est importante pour votre cas d'utilisation.
### Quotas et régulation
Les quotas et limites de taux suivants s'appliquent aux transactions asynchrones.
**Quotas de transactions asynchrones**
| Quota | Value | Ajustable |
| --- | --- | --- |
| Nombre maximum d'opérations par transaction asynchrone | 500 | Non |
| Nombre maximum de transactions en attente par magasin de données | 500 | Oui |
+ Les transactions asynchrones partagent les mêmes limites de débit d'API définies ci-dessous. [Quotas de service](reference-healthlake-endpoints-quotas.md#reference-healthlake-quotas)
+ L'interrogation du statut des transactions partage les mêmes limites de débit d'API que les opérations read (`GET`) sur les ressources FHIR.
+ Si la limite de transactions en attente est atteinte, les soumissions suivantes renvoient une erreur jusqu'à ce que les transactions existantes soient terminées.
### Gestion des erreurs
Pour un bundle « transactionnel », toutes les ressources FHIR contenues dans le bundle sont traitées comme une opération atomique. Toutes les ressources de l'opération doivent réussir, sinon aucune opération du bundle n'est traitée.
Les erreurs se répartissent en deux catégories : les erreurs de soumission HealthLake renvoyées de manière synchrone et les erreurs de traitement que vous détectez par le biais d'un sondage.
**Erreurs de soumission**
HealthLake valide le bundle au moment de l'envoi et renvoie les erreurs de manière synchrone avant que la transaction ne soit mise en file d'attente. Les erreurs de soumission incluent des erreurs de validation des ressources FHIR non valides, des types de ressources non pris en charge, le dépassement de la limite de 500 opérations et l'utilisation de l'`Prefer: respond-async`en-tête avec des ensembles de lots. Si la limite de transactions en attente pour le magasin de données a été atteinte, HealthLake renvoie `ThrottlingException` a. Lorsqu'une erreur de soumission se produit, la transaction ne sera pas mise en file d'attente.
**Erreurs de traitement**
Des erreurs de traitement se produisent une fois que la transaction a été mise en file d'attente et sont renvoyées via l'URL d'interrogation. Il s'agit notamment des conflits de transactions, lorsqu'une autre opération a modifié une ressource faisant partie de la transaction, et des erreurs de serveur pendant le traitement. Lorsqu'une erreur de traitement se produit, aucune mutation de ressource n'est effectuée pour les ressources de la transaction. L'URL du sondage renverra un `OperationOutcome` contenant les détails de l'erreur.
# Supprimer une ressource FHIR
L'`delete`interaction FHIR supprime une ressource FHIR existante d'un magasin de HealthLake données. Pour plus d'informations, consultez la [https://hl7.org/fhir/R4/http.html#delete](https://hl7.org/fhir/R4/http.html#delete)documentation de l'** RESTful API FHIR R4**.
**Pour supprimer une ressource FHIR**
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. Déterminez le type de FHIR `Resource` à supprimer et collectez la `id` valeur associée. Pour de plus amples informations, veuillez consulter [Types de ressources](reference-fhir-resource-types.md).
1. Construisez une URL pour la demande en utilisant les valeurs collectées pour HealthLake `region` et`datastoreId`. Incluez également le `Resource` type FHIR et son associé`id`. Pour afficher le chemin complet de l'URL dans l'exemple suivant, faites défiler le curseur sur le bouton **Copier**.
```
DELETE https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Resource/id
```
1. Envoyez la demande . L'`delete`interaction FHIR utilise une `DELETE` demande avec [AWS signature version 4](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) ou SMART sur autorisation FHIR. L'`curl`exemple suivant supprime une `Patient` ressource FHIR existante d'un magasin de HealthLake données. Pour afficher l'exemple dans son intégralité, faites défiler la souris sur le bouton **Copier**.
------
#### [ SigV4 ]
Autorisation SigV4
```
curl --request DELETE \
'https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient/id' \
--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 serveur renvoie un code d'état `204` HTTP confirmant que la ressource a été supprimée du magasin de HealthLake données. Si une demande de suppression échoue, vous recevrez un code d'état HTTP en `400` série indiquant pourquoi la demande a échoué.
------
#### [ SMART on FHIR ]
Exemple d'autorisation SMART sur FHIR pour le 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.
```
{
"AuthorizationStrategy": "SMART_ON_FHIR",
"FineGrainedAuthorizationEnabled": true,
"IdpLambdaArn": "arn:aws:lambda:your-region:your-account-id:function:your-lambda-name",
"Metadata": "{\"issuer\":\"https://ehr.example.com\", \"jwks_uri\":\"https://ehr.example.com/.well-known/jwks.json\",\"authorization_endpoint\":\"https://ehr.example.com/auth/authorize\",\"token_endpoint\":\"https://ehr.token.com/auth/token\",\"token_endpoint_auth_methods_supported\":[\"client_secret_basic\",\"foo\"],\"grant_types_supported\":[\"client_credential\",\"foo\"],\"registration_endpoint\":\"https://ehr.example.com/auth/register\",\"scopes_supported\":[\"openId\",\"profile\",\"launch\"],\"response_types_supported\":[\"code\"],\"management_endpoint\":\"https://ehr.example.com/user/manage\",\"introspection_endpoint\":\"https://ehr.example.com/user/introspect\",\"revocation_endpoint\":\"https://ehr.example.com/user/revoke\",\"code_challenge_methods_supported\":[\"S256\"],\"capabilities\":[\"launch-ehr\",\"sso-openid-connect\",\"client-public\",\"permission-v2\"]}"
}
```
L'appelant peut attribuer des autorisations dans le lambda d'autorisation. Pour de plus amples informations, veuillez consulter [OAuth Éscopes 2.0](reference-smart-on-fhir-oauth-scopes.md).
------
#### [ AWS Console ]
1. Connectez-vous à la page [Exécuter une requête](https://console.aws.amazon.com/healthlake/home#/crud) sur la HealthLake console.
2. Dans la section **Paramètres de requête**, effectuez les sélections suivantes.
+ **ID du magasin de données** : choisissez un identifiant de magasin de données pour générer une chaîne de requête.
+ **Type de requête** : choisissez`Delete`.
+ **Type de ressource** : choisissez le [type de ressource](reference-fhir-resource-types.md) FHIR à supprimer.
+ **ID de ressource** — entrez l'ID de ressource FHIR.
3. Choisissez **Exécuter la requête**.
------
## Suppression de ressources FHIR en fonction des conditions
La suppression conditionnelle est particulièrement utile lorsque vous ne connaissez pas l'ID de ressource FHIR spécifique mais que vous disposez d'autres informations d'identification concernant la ressource que vous souhaitez supprimer.
La suppression conditionnelle vous permet de supprimer une ressource existante en fonction de critères de recherche plutôt que d'un identifiant FHIR logique. Lorsque le serveur traite la demande de suppression, il effectue une recherche à l'aide des fonctionnalités de recherche standard pour le type de ressource afin de résoudre un identifiant logique unique pour la demande.
### Fonctionnement de la suppression conditionnelle
**L'action du serveur dépend du nombre de correspondances qu'il trouve :**
1. **Aucune correspondance** : le serveur tente une suppression ordinaire et répond de manière appropriée (404 introuvable pour une ressource inexistante, 204 Aucun contenu pour une ressource déjà supprimée)
1. **Une correspondance** : le serveur effectue une suppression ordinaire sur la ressource correspondante
1. **Correspondances multiples** : renvoie une erreur 412 Precondition Failed indiquant que les critères du client n'étaient pas suffisamment sélectifs
### Scénarios de réponse
AWS HealthLake gère les opérations de suppression conditionnelle avec les modèles de réponse suivants :
**Opérations réussies**
+ Lorsque vos critères de recherche identifient avec succès une seule ressource active, le système renvoie **204 No Content** une fois la suppression terminée, comme pour les opérations de suppression standard.
**Suppression conditionnelle basée sur un identifiant**
Lorsque vous effectuez une suppression conditionnelle basée sur `id` des paramètres supplémentaires (`createdAt`,`tag`, ou`_lastUpdated`) :
+ **204 Aucun contenu** : la ressource a déjà été supprimée
+ **404 Introuvable** : la ressource n'existe pas
+ **409 Conflit** : l'identifiant correspond mais les autres paramètres ne correspondent pas
**Non-ID-Based Suppression conditionnelle**
Quand n'`id`est pas fourni ou lorsque vous utilisez des paramètres autres que `createdAt``tag`, ou `_lastUpdated` :
+ **404 Introuvable** : Aucune correspondance n'a été trouvée
**Situations de conflit**
Plusieurs scénarios entraînent l'échec de 412 réponses à la condition préalable :
+ Plusieurs ressources correspondent à vos critères de recherche (critères trop peu spécifiques)
+ Conflits de version lors de l'utilisation d' ETag en-têtes avec `If-Match`
+ Mises à jour des ressources survenant entre les opérations de recherche et de suppression
**Exemple de suppression conditionnelle réussie**
L'exemple suivant supprime une ressource Patient en fonction de critères spécifiques :
```
DELETE https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient?name=peter&birthdate=2000-01-01&phone=1234567890
```
Cette demande supprime une ressource Patient dans laquelle :
+ Le nom est « Peter »
+ La date de naissance est le 1er janvier 2000
+ Le numéro de téléphone est 1234567890
**Bonnes pratiques**
1. Utilisez des critères de recherche spécifiques pour éviter les correspondances multiples et éviter 412 erreurs.
1. Envisagez ETag des en-têtes pour le contrôle de version lorsque cela est nécessaire pour gérer des modifications simultanées.
1. Gérez les réponses aux erreurs de manière appropriée :
+ Pour 404 : Affinez vos critères de recherche
+ Pour 4.1.2 : préciser les critères ou résoudre les conflits de versions
1. Préparez-vous à des conflits temporels dans des environnements où la concurrence est élevée, dans lesquels les ressources peuvent être modifiées entre les opérations de recherche et de suppression.
# Idempotencie et simultanéité
## Clés d'impuissance
AWS HealthLake prend en charge les clés d'idempuissance pour les `POST` opérations FHIR, fournissant un mécanisme robuste pour garantir l'intégrité des données lors de la création des ressources. En incluant un UUID unique comme clé d'idempuissance dans l'en-tête de demande, les applications de santé peuvent garantir que chaque ressource FHIR est créée exactement une fois, même dans les scénarios impliquant une instabilité du réseau ou des tentatives automatiques.
Cette fonctionnalité est particulièrement cruciale pour les systèmes de santé où les doublons de dossiers médicaux peuvent avoir de graves conséquences. Lorsqu'une demande est reçue avec la même clé d'idempuissance qu'une demande précédente, elle HealthLake renvoie la ressource d'origine au lieu de créer un doublon. Par exemple, cela peut se produire lors d'une boucle de nouvelles tentatives ou en raison de pipelines de requêtes redondants. L'utilisation de la clé d'idempotencie permet HealthLake de maintenir la cohérence des données tout en offrant une expérience fluide aux applications clientes traitant des problèmes de connectivité intermittents.
### Mise en œuvre
```
POST //Patient
x-amz-fhir-idempotency-key: 123e4567-e89b-12d3-a456-426614174000
{
"resourceType": "Patient",
"name": [...]
}
```
### Scénarios de réponse
Première demande (201 créés)
+ Nouvelle ressource créée avec succès
+ La réponse inclut l'ID de ressource
Demande dupliquée (conflit 409)
+ Même clé d'impuissance détectée
+ Ressource d'origine renvoyée
+ Aucune nouvelle ressource n'a été créée
Demande non valide (400 demandes erronées)
+ UUID mal formé
+ Champs obligatoires manquants
### Bonnes pratiques
+ Générez un UUID unique pour chaque nouvelle création de ressource
+ Stockez les clés d'impuissance pour la logique des nouvelles tentatives
+ Utiliser un format de clé cohérent : UUID v4 recommandé
+ Implémenter dans les applications clientes gérant la création de ressources
**Note**
Cette fonctionnalité est particulièrement utile pour les systèmes de santé qui exigent une précision stricte des données et évitent la duplication des dossiers médicaux.
## ETag dans AWS HealthLake
AWS HealthLake utilise ETags pour un contrôle de simultanéité optimiste des ressources FHIR, fournissant un mécanisme fiable pour gérer les modifications simultanées et maintenir la cohérence des données. An ETag est un identifiant unique qui représente une version spécifique d'une ressource, fonctionnant comme un système de contrôle de version via des en-têtes HTTP. Lors de la lecture ou de la modification des ressources, les applications peuvent les utiliser ETags pour empêcher les remplacements involontaires et garantir l'intégrité des données, en particulier dans les scénarios impliquant des mises à jour simultanées potentielles.
### Exemple de mise en œuvre
```
// Initial Read
GET /fhir/Patient/123
Response:
ETag: W/"1"
// Update with If-Match
PUT /fhir/Patient/123
If-Match: W/"1"
{resource content}
// Create with If-None-Match
PUT /fhir/Patient/123
If-None-Match: *
{resource content}
// Succeeds only if resource doesn't exist
// Fails with 412 if resource exists
```
### Scénarios de réponse
Opération réussie (200 OK ou 204 sans contenu)
+ ETag correspond à la version actuelle
+ L'opération se déroule comme prévu
Conflit de version (échec de la condition préalable 412)
+ ETag ne correspond pas à la version actuelle
+ Mise à jour rejetée pour éviter la perte de données
### Bonnes pratiques
+ Inclure ETags dans toutes les opérations de mise à jour et de suppression
+ Implémenter une logique de nouvelle tentative pour gérer les conflits de versions
+ Utilisez If-None-Match :\$1 pour les create-if-not-exists scénarios
+ Vérifiez toujours la ETag fraîcheur avant de procéder à des modifications
Ce système de contrôle de simultanéité est essentiel pour maintenir l'intégrité des données de santé, en particulier dans les environnements où plusieurs utilisateurs ou systèmes accèdent aux mêmes ressources et les modifient.