Le DELETE standard de FHIR est une suppression logicielle. La ressource est marquée comme supprimée, mais son historique de versions demeure intact — chaque état passé reste accessible via _history. Pour la plupart des flux cliniques, c'est exactement ce que l'on souhaite : une piste d'audit immuable.
Mais les réglementations ne sont pas toujours du même avis.
L'article 17 du RGPD accorde aux personnes le « droit à l'effacement ». Les politiques de conservation des données ont des dates d'expiration — même si elles s'étendent sur 100 ans après le décès. Lorsque vient le moment de supprimer véritablement les données d'un patient, une suppression logicielle ne suffit pas. Les données doivent être effacées définitivement de chaque version de chaque ressource.
C'est cet écart — entre la sémantique de suppression logicielle par défaut de FHIR et les exigences réglementaires de suppression définitive — que l'opération $purge a été conçue pour combler.
De la discussion sur Zulip à la normalisation dans FHIR R6
L'opération $purge est issue de plusieurs années de discussions au sein de la communauté sur FHIR Zulip, amorcées en 2018.
La question centrale : comment FHIR devrait-il gérer l'effacement définitif des données? Plusieurs noms ont été proposés — $erase, $expunge, $gdpr-delete — et différentes implémentations existaient déjà. HAPI FHIR disposait de $expunge, mais celui-ci ne supprimait que les ressources ayant déjà fait l'objet d'une suppression logicielle.
La décision de conception clé portait sur la portée : /Patient/1/$purge devrait-il effacer uniquement la ressource Patient elle-même, ou tout le contenu du compartiment du patient? La communauté a convergé vers la seconde option — le serveur devrait prendre en charge la complexité de la recherche et de la suppression de toutes les ressources du compartiment.
Les travaux de spécification formelle se sont poursuivis en 2023, couvrant les codes de réponse, la sémantique de suppression de l'historique et les portées SMART. Résultat : $purge a été ajouté à FHIR R6 en tant qu'opération normative, remplaçant les implémentations propres aux fournisseurs par une norme commune.
Aidbox 2602 : $purge en pratique
À partir de la version 2602, Aidbox implémente l'opération $purge de FHIR R6. Un seul POST supprime définitivement la ressource Patient et chaque ressource de son compartiment — Observations, Conditions, Encounters, MedicationRequests et toutes leurs versions historiques.
L'opération utilise la définition du compartiment Patient pour déterminer quelles ressources appartiennent à un patient. Pour chaque type de ressource dans le compartiment, Aidbox interroge les paramètres de recherche correspondants afin de trouver toutes les ressources référençant Patient/<id> :
Une purge synchrone de base consiste en un seul POST :
POST /fhir/Patient/pt-1/$purge
Content-Type: application/json
Réponse :
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "fatal",
"code": "informational",
"diagnostics": "All resources for Patient/pt-1 were purged"
}
]
}
Une fois l'opération terminée, toute demande concernant le patient ou ses ressources retourne 404 Not Found — et non 410 Gone. Les données n'existent plus.
Mode asynchrone pour les grands compartiments
Certains patients accumulent des milliers de ressources au fil des années de soins. La suppression synchrone de l'ensemble de ces ressources pourrait entraîner des délais d'attente dépassés.
Ajoutez l'en-tête Prefer: respond-async pour exécuter la purge en arrière-plan :
POST /fhir/Patient/pt-1/$purge
Content-Type: application/json
Prefer: respond-async
Le patient est supprimé immédiatement. Les ressources du compartiment sont supprimées par des travailleurs en arrière-plan. Vous obtenez en retour un 202 Accepted avec un en-tête Content-Location pointant vers le point de terminaison de statut :
GET /fhir/$async/<operation-id> # 202 while in progress, 200 when complete
DELETE /fhir/$async/<operation-id> # cancel the operation
Le nombre de travailleurs asynchrones simultanés est contrôlé par le paramètre BOX_SCHEDULER_EXECUTORS (valeur par défaut : 4).
Le problème des ressources partagées : pourquoi les compartiments personnalisés sont importants
Prenons une ressource Group représentant la cohorte d'un essai clinique regroupant 50 patients. Ou une ressource List assurant le suivi du groupe de patients partagé par une équipe de soins. Ces ressources font référence à plusieurs patients simultanément. Lorsque vous purgez le patient A, l'intégralité du Group devrait-elle être supprimée — même si les patients B à Z y figurent toujours?
Il n'existe pas de réponse universellement correcte. Supprimer l'ensemble de la ressource brise l'intégrité référentielle pour les autres patients qui y font encore référence. N'en supprimer qu'une partie — par exemple, retirer un membre d'un Group — soulève ses propres questions : toutes les versions historiques de cette ressource devraient-elles également être réécrites pour en retirer le patient? Et la ressource modifiée préserve-t-elle même sa sémantique d'origine?
La spécification principale de FHIR laisse délibérément ce comportement à la discrétion des implémenteurs — et pour de bonnes raisons. La bonne réponse dépend de votre modèle de données, de votre contexte réglementaire et de la façon dont votre système utilise ces ressources partagées.
$purge prend en charge un paramètre compartmentDefinition qui vous permet de contrôler précisément quels types de ressources sont inclus dans la purge. Au lieu d'utiliser le compartiment Patient par défaut du serveur (qui inclut Group, List et des dizaines d'autres types), vous pouvez transmettre une CompartmentDefinition personnalisée qui en limite la portée.
Par exemple, pour purger uniquement les données cliniques — en excluant délibérément Group et List :
{
"resourceType": "Parameters",
"parameter": [
{
"name": "compartmentDefinition",
"resource": {
"resourceType": "CompartmentDefinition",
"url": "http://example.com/purge-clinical-only",
"name": "PurgeClinicalOnly",
"code": "Patient",
"status": "active",
"search": true,
"resource": [
{ "code": "Observation", "param": ["subject"] },
{ "code": "Condition", "param": ["subject"] },
{ "code": "Encounter", "param": ["subject"] },
{ "code": "MedicationRequest", "param": ["subject"] }
]
}
}
]
}
Cela offre un contrôle explicite : purgez les données cliniques individuelles du patient tout en laissant les ressources partagées intactes pour qu'elles soient traitées séparément par la logique applicative.
La CompartmentDefinition personnalisée doit avoir code défini à Patient et au moins une entrée de ressource avec une liste param non vide.
Garanties de sécurité intégrées
Idempotent par conception. La purge d'un patient qui n'existe pas (ou qui a déjà été purgé) retourne un succès. Vous pouvez relancer $purge en toute sécurité après un échec partiel sans craindre d'erreurs.
Piste d'audit. Chaque purge réussie crée un AuditEvent avec action: "E" (Execute) et subtype: "$purge". La purge supprime les données du patient, mais le fait qu'une purge ait eu lieu est enregistré de façon permanente. Consultez comment configurer le journal d'audit pour les instructions de configuration.
Premiers pas
$purge est disponible dans Aidbox à partir de la version 2602. Le point de terminaison suit la spécification FHIR R6 :
POST /fhir/Patient/<patient-id>/$purge
Aucune configuration supplémentaire n'est requise. Pour les détails complets de l'API et la référence des paramètres, consultez la documentation Aidbox sur $purge.
