Implementation Guide Pseudonymization Interface for the MII - Local Development build (v1.1.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

Funktionen

Version 1.1 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 String Beispiel2 Identifier Beispiel3 Bundle
$pseudonymize-multiple	Definition	Beispiel1	Beispiel1
$de-pseudonymize	Definition	Beispiel1	Beispiel1
$delete-pseudonym	Definition	Beispiel1	Beispiel1 Beispiel2 Not Found
$anonymize-original	Definition	Beispiel1	Beispiel1

Unterscheidung von Pseudonym-Kardinalitäten

Single-Pseudonym-Kontext

Wenn Pseudonyme für Personen generiert werden, dann besteht meist eine 1 zu 1 Beziehung zwischen den verschiedenen Kontexten. D.h. eine Person hat pro Domäne nur ein Pseudonym. Daraus ergibt sich, dass es in jeder Domäne zu jedem Originalwert stets nur ein Pseudonym gibt (Single-Pseudonym-Domäne).

Die Operation $pseudonymize fokussiert die Verwendung in Single-Pseudonym-Kontexten.

Multi-Pseudonym-Kontext

In bestimmten Fällen kann es jedoch erforderlich sein, dass es zu einer Person mehrere Pseudonyme geben soll innerhalb des gleichen Kontextes (Domäne). Dies kann z.B. für eine Sekundärpseudonymisierung oder bei der Verwaltung von Bioproben oder Bilddaten erforderlich sein. In diesen Fällen werden für eine Person mehrere Pseudonyme innerhalb eines Kontextes (Domäne) erzeugt. Sogenannte Multi-Pseudonym-Kontexte erlauben es pro Originalwert mehrere Pseudonyme innerhalb der gleichen Domäne zu erzeugen. Es besteht eine 1 zu n Beziehung zwischen Originalwert und Pseudonym, wobei n beliebig groß sein kann.

Die Auflösung von Pseudonymen erfolgt auf die gleiche Weise wie bei 1 zu 1 Beziehungen. Der umgekehrte Fall muss jedoch berücksichtigen, dass es mehrere Pseudonyme geben kann und diese ggf. in höheren Pseudonymstufen nicht als Originalwert auftauchen.

Die Operation $pseudonymize-multiple fokussiert die Verwendung in Multi-Pseudonym-Kontexten.

Die Umsetzung der oben beschriebenen Use Cases zur Sekundärpseudonymisierung erfordern die Verwendung von Multi-Pseudonym-Kontexten (siehe oben: ohne RL und mit RL).

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.