--- { "title": "$purge: Patientendaten dauerhaft mit einem einzigen FHIR-Aufruf löschen", "description": "Aidbox 2602 implementiert die FHIR R6-Operation $purge — löschen Sie einen Patienten und sein gesamtes Compartment, einschließlich aller Versionshistorie, in einem einzigen, prüfbaren Aufruf dauerhaft.", "date": "2026-04-03", "author": "Evgeny Mukha", "reading-time": "6 min read", "tags": ["FHIR Standard", "Aidbox", "Compliance"], "tldr": "Die FHIR R6-Operation $purge löscht einen Patienten und alle Compartment-Ressourcen dauerhaft — einschließlich der Versionshistorie. Aidbox 2602 implementiert sie mit synchronem/asynchronem Modus, benutzerdefinierten Compartment-Definitionen und Audit-Logging." } --- Das Standard-`DELETE` in FHIR ist ein Soft-Delete. Die Ressource wird als gelöscht markiert, doch ihre Versionshistorie bleibt vollständig erhalten — jeder vergangene Zustand ist weiterhin über `_history` abrufbar. Für die meisten klinischen Arbeitsabläufe ist das genau das Gewünschte: ein unveränderlicher Prüfpfad. Regulatorische Anforderungen sehen das jedoch nicht immer so. Artikel 17 der DSGVO gewährt Einzelpersonen das „Recht auf Löschung". Datenaufbewahrungsrichtlinien haben Verfallsdaten — selbst wenn diese 100 Jahre nach dem Tod liegen. Wenn es darum geht, die Daten eines Patienten wirklich zu entfernen, reicht ein Soft-Delete nicht aus. Die Daten müssen dauerhaft aus jeder Version jeder Ressource gelöscht werden. Diese Lücke — zwischen der standardmäßigen Soft-Delete-Semantik von FHIR und den regulatorischen Hard-Delete-Anforderungen — ist es, die die Operation `$purge` schließen soll. ## Von der Zulip-Diskussion zur FHIR R6-Standardisierung Die Operation `$purge` entstand aus jahrelangen [Community-Diskussionen](https://chat.fhir.org/#narrow/stream/179166-implementers/topic/GDPR.20and.20hard.20delete) auf FHIR Zulip, die 2018 begannen. Die zentrale Frage lautete: Wie soll FHIR die dauerhafte Datenlöschung handhaben? Verschiedene Namen wurden vorgeschlagen — `$erase`, `$expunge`, `$gdpr-delete` — und unterschiedliche Implementierungen existierten bereits. HAPI FHIR verfügte über `$expunge`, das jedoch nur zuvor soft-gelöschte Ressourcen entfernte. Die wichtigste Designentscheidung betraf den Geltungsbereich: Soll `/Patient/1/$purge` nur die Patient-Ressource selbst löschen oder alles im Compartment des Patienten? Die Community einigte sich auf Letzteres — der Server soll die Komplexität des Auffindens und Entfernens aller Compartment-Ressourcen übernehmen. Die [formale Spezifikationsarbeit](https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Purge.20and.20Delete.20History.20Operations.20.28FHIR-16198.29) wurde 2023 fortgesetzt und behandelte Antwort-Codes, Semantiken zur Historienbereinigung und SMART-Scopes. Das Ergebnis: `$purge` wurde als normative Operation in [FHIR R6](https://build.fhir.org/patient-operation-purge.html) aufgenommen und ersetzt damit herstellerspezifische Implementierungen durch einen Standard. ## Aidbox 2602: $purge in der Praxis Ab Version 2602 implementiert Aidbox die [FHIR R6](/articles/getting-ready-for-fhir-r6-what-you-need-to-know)-Operation `$purge`. Ein einziger POST löscht die Patient-Ressource und jede Ressource in deren Compartment dauerhaft — Observations, Conditions, Encounters, MedicationRequests und alle ihre Versionshistorien. Die Operation verwendet die [Patient-Compartment-Definition](https://build.fhir.org/compartmentdefinition-patient.html), um zu bestimmen, welche Ressourcen zu einem Patienten gehören. Für jeden Ressourcentyp im Compartment fragt Aidbox die entsprechenden Suchparameter ab, um alle Ressourcen zu finden, die auf `Patient/` verweisen: ```mermaid flowchart LR A["POST /fhir/Patient/pt-1/$purge"] --> B[Load compartment definition] B --> C[Delete Patient/pt-1] C --> D[Delete Observations] C --> E[Delete Conditions] C --> F[Delete Encounters] C --> G[Delete ...] ``` Ein einfaches synchrones Purge ist ein einzelner POST: ```http POST /fhir/Patient/pt-1/$purge Content-Type: application/json ``` Antwort: ```json { "resourceType": "OperationOutcome", "issue": [ { "severity": "fatal", "code": "informational", "diagnostics": "All resources for Patient/pt-1 were purged" } ] } ``` Nach Abschluss der Operation gibt jede Anfrage nach dem Patienten oder seinen Ressourcen **404 Not Found** zurück — nicht 410 Gone. Die Daten existieren nicht mehr. ## Asynchroner Modus für große Compartments Einige Patienten akkumulieren im Laufe jahrelanger Behandlung Tausende von Ressourcen. Das synchrone Löschen aller Ressourcen könnte zu Timeouts führen. Fügen Sie den Header `Prefer: respond-async` hinzu, um den Purge im Hintergrund auszuführen: ```http POST /fhir/Patient/pt-1/$purge Content-Type: application/json Prefer: respond-async ``` Der Patient wird sofort gelöscht. Compartment-Ressourcen werden von Hintergrund-Workern gelöscht. Sie erhalten eine `202 Accepted`-Antwort mit einem `Content-Location`-Header, der auf den Status-Endpunkt verweist: ```http GET /fhir/$async/ # 202 while in progress, 200 when complete DELETE /fhir/$async/ # cancel the operation ``` Die Anzahl der gleichzeitigen asynchronen Worker wird durch die Einstellung [`BOX_SCHEDULER_EXECUTORS`](https://www.health-samurai.io/docs/aidbox/reference/all-settings#scheduler-executor-threads) gesteuert (Standard: 4). ## Das Problem gemeinsam genutzter Ressourcen: Warum benutzerdefinierte Compartments wichtig sind Betrachten Sie eine `Group`-Ressource, die eine klinische Studienkohorte mit 50 Patienten repräsentiert. Oder eine `List`-Ressource, die das gemeinsame Patientenpanel eines Pflegeteams verfolgt. Diese Ressourcen verweisen gleichzeitig auf mehrere Patienten. Wenn Sie Patient A bereinigen, soll dann die gesamte `Group` gelöscht werden — obwohl die Patienten B bis Z noch darin enthalten sind? Es gibt keine universell richtige Antwort. Das Löschen der gesamten Ressource verletzt die referentielle Integrität für andere Patienten, die noch darauf verweisen. Das Löschen nur eines Teils — etwa das Entfernen eines Mitglieds aus einer Group — wirft eigene Fragen auf: Sollen auch alle historischen Versionen dieser Ressource umgeschrieben werden, um den Patienten zu entfernen? Und bewahrt die geänderte Ressource überhaupt noch ihre ursprüngliche Semantik? Die FHIR-Kernspezifikation überlässt dieses Verhalten bewusst den Implementierern — und das aus gutem Grund. Die richtige Antwort hängt von Ihrem Datenmodell, Ihrem regulatorischen Kontext und der Verwendung dieser gemeinsam genutzten Ressourcen in Ihrem System ab. `$purge` unterstützt einen Parameter `compartmentDefinition`, mit dem Sie genau steuern können, welche Ressourcentypen in den Purge einbezogen werden. Anstatt die Standard-Patient-Compartment-Definition des Servers zu verwenden (die Group, List und Dutzende anderer Typen umfasst), können Sie eine benutzerdefinierte `CompartmentDefinition` übergeben, die den Geltungsbereich einschränkt. Um beispielsweise nur klinische Daten zu bereinigen — und dabei Group und List bewusst auszuschließen: ```json { "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"] } ] } } ] } ``` Dies bietet explizite Kontrolle: Die individuellen klinischen Daten des Patienten werden bereinigt, während gemeinsam genutzte Ressourcen für eine separate Behandlung durch Ihre Anwendungslogik intakt bleiben. Die benutzerdefinierte `CompartmentDefinition` muss `code` auf `Patient` gesetzt haben und mindestens einen Ressourceneintrag mit einer nicht leeren `param`-Liste enthalten. ## Integrierte Sicherheitsgarantien **Von Grund auf idempotent.** Das Bereinigen eines Patienten, der nicht existiert (oder bereits bereinigt wurde), gibt einen Erfolgsstatus zurück. Sie können `$purge` nach einem partiellen Fehler sicher erneut ausführen, ohne sich um Fehler sorgen zu müssen. **Prüfpfad.** Jeder erfolgreiche Purge erstellt ein `AuditEvent` mit `action: "E"` (Execute) und `subtype: "$purge"`. Der Purge entfernt die Daten des Patienten, aber die Tatsache, dass ein Purge stattgefunden hat, wird dauerhaft aufgezeichnet. Informationen zur Einrichtung finden Sie unter [Konfiguration des Audit-Logs](https://docs.aidbox.app/tutorials/security-access-control-tutorials/how-to-configure-audit-log). ## Erste Schritte `$purge` ist in Aidbox ab Version 2602 verfügbar. Der Endpunkt folgt der FHIR R6-Spezifikation: ```http POST /fhir/Patient//$purge ``` Es ist keine zusätzliche Konfiguration erforderlich. Vollständige API-Details und eine Parameterreferenz finden Sie in der [Aidbox $purge-Dokumentation](https://docs.aidbox.app/api/bulk-api/purge).