

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.

# Supprimer une ressource FHIR
<a name="managing-fhir-resources-delete"></a>

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
<a name="conditional-delete-fhir"></a>

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
<a name="conditional-delete-works"></a>

**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
<a name="response-scenerios"></a>

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.