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 String Beispiel2 Identifier Beispiel3 Bundle Beispiel4 SecondaryPseudonyms	Beispiel1 Beispiel3 Beispiel4
$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“.

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.

Aktuell setzt der Implementation Guide bei der Umsetzung auf Parameters-Objekte. Hier ist künftig ebenfalls eine Umsetzung auf Basis von Outcome denkbar. Diese Arbeiten werden direkt hier im Implementation Guide fortgeführt.