Implementation Guide MII Schnittstelle Pseudonymisierung - Local Development build (v0.9.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

Funktionen

Version 1.0 der Schnittstelle sieht 5 Basisfunktionalitäten zur Umsetzung der folgenden Use Cases vor:

• Erzeugung und Verwaltung von Personenpseudonymen
• Sekundärpseudonymisierung ohne standortübergreifendes Record Linkage
• Sekundärpseudonymisierung mit standortübergreifendem Record Linkage

Operation	Spezifikation	Beispiel Requests	Beispiel Responses
$pseudonymize	Definition	Beispiel1 Beispiel2 Beispiel3	Beispiel1 Beispiel3
$pseudonymize-secondary	Definition	Beispiel1	Beispiel1
$de-pseudonymize	Definition	Beispiel1	Beispiel1
$delete-pseudonyms	Definition	Beispiel1	Beispiel1
$anonymize-originals	Definition	Beispiel1	Beispiel1

Implementierungshinweise

Der IG gestattet den erforderlichen Spielraum für die praktischen Umsetzung und Implementierung der obigen Funktionalitäten.

Grundsätzlich ist dabei darauf zu achten, dass

• Inhaltliche Fehler (eines Listeneintrags) zu kennzeichnen sind und bekannte Fehlerursachen entsprechend nachvollziehbar gewürdigt werden sollten, z.B. ein zu depseudonymisierendes Pseudonym ist dem angefragten System unbekannt. Der Fehler kann per http://hl7.org/fhir/issue-type kodiert werden.
• die Verarbeitung von Listen sowohl Blocking (Abbruch Verarbeitung bei auftretendem Fehler) als auch Non-Blocking (Abarbeitung der kompletten Liste trotz Fehler) erfolgen kann. Die konkrete Variante wird durch die Implementierung festgelegt.

Alle implementierten Operationen arbeiten jeweils auf singulären Eingaben, d.h. es wird genau ein Eingabewert z.B. pseudonymisiert. Um Listen von Eingabewerten zu verarbeiten wird bei der Implementierung auf die Batch- bzw. Transaction-Verarbeitung des FHIR Standards zurückgegriffen 1

Ein Bundle beinhaltet dabei die Liste an auszuführenden Operationen als Einträge in Bundle.entry. Abhängig vom Typ des Bundles wird die Listenverarbeitung entweder Blocking (Transaction) oder Non-Blocking (Batch) erfolgen (siehe Beispiel-Bundle)

Umgang mit Fehlern

Der http-Response-Status gibt Auskunft über die Art auftretender Fehler.

HTTP-Status Code	Bedeutung
4XX	Client-Seitige Fehler: falsche Parameter, z.B. fehlende oder fehlerhafte Parameter, unzureichende Rechte, Request Throttling,
404	Wert (z.B. Context, Pseudonym) ist nicht vorhanden
200	Keine Fehler

Weitere Fehlerarten sind möglich, z.B. 500 zur Meldung „unerwarteter Ereignisse bei der Verarbeitung“.