Implementation Guide MII Schnittstelle Pseudonymisierung - Local Development build (v1.0.2) 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 String Beispiel2 Identifier Beispiel3 Bundle	Beispiel1 Beispiel3
$pseudonymize-secondary	Definition	Beispiel1	Beispiel1
$de-pseudonymize	Definition	Beispiel1	Beispiel1
$delete-pseudonym	Definition	Beispiel1	Beispiel1 Beispiel2 Not Found
$anonymize-original	Definition	Beispiel1	Beispiel1

Implementierungshinweise

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

In der vorliegenden ersten Version des IGs wird das Thema Listenverarbeitung zunächst außen vor gelassen und sind die Eingabe-Parameter aller Operations bewußt auf n=1 limitiert.

Alle implementierten Operationen arbeiten daher in dieser ersten IG-Version 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)

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.

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“.

Offene Punkte

Das Konzeptdokument verwendet einheitlich den Begriff „Personenpseudonym“, da das Datenschutzkonzept der MII explizit von einem dauerhaften Pseudonym je Standort und Person spricht. Die Erweiterung des Pseudonym-Begriffs auf beliebige Identifier ist für künftige Versionen des Konzeptdokumentes angedacht und wird in einer späteren Version des Schnittstellenkonzeptes (Version 2.0) berücksichtigt werden.

Ebenso ist eine Erweiterung des Konzeptes um die konkreten Szenarien 2 und 4 grundsätzlich denkbar.

Details zum Umgang mit Listen bei IN-Parametern werden in einer nächsten IG-Version erarbeitet.