gms | German Medical Science

Einleitung: Während in reinen Forschungsdatenbanken medizinische Daten (MDAT) von Probanden oder Patienten in der Regel nur in pseudonymisierter Form zugänglich sind, erfordern behandlungsnahe Anwendungen, dass auch die zugehörigen identifizierenden Daten (IDAT) einsehbar sind, damit im Klinikalltag eine schnelle und sichere Zuordnung zu den betroffenen Patienten möglich ist. Bei institutionsübergreifenden Projekten, die eine zentrale Speicherung von Patientendaten erfordern, gebietet der Datenschutz andererseits eine technisch und organisatorisch getrennte Speicherung von MDAT und IDAT. Eine Zusammenführung dieser Datenklassen darf deshalb erst beim Anwender, bei internetbasieren Systemen also im Webbrowser, stattfinden. Für die Implementierung der Registertoolbox OSSE [1] musste eine softwaretechnische Lösung für diesen Anwendungsfall gefunden werden.

Material und Methoden: In Deutschland haben sich für den Datenschutz in der medizinischen Forschung die Konzepte der Technologie- und Methodenplattform für die vernetzte medizinische Forschung (TMF e.V.) etabliert [2]. Das oben genannte Szenario ist dabei als sogenanntes „klinisches Modul“ berücksichtigt. Ein zentraler Bestandteil der Datenflüsse dieses Moduls sind temporäre Identifikatoren („Temp-IDs“), die einen Patienten für einen begrenzten Zeitraum identifizieren. Beim Zugriff auf einen Patienten werden üblicherweise MDAT und Temp-ID an den Webbrowser ausgeliefert und die IDAT mittels der Temp-ID vom IDAT-Server nachgeladen. Die Temp-ID dient dabei zum einen dazu, das permanente Pseudonym des Patienten (PID) vor dem Benutzer zu verbergen; zum anderen kann auf eine doppelte Benutzerauthentifizierung verzichtet werden, wenn die Temp-IDs nicht erratbar sind und ihre Gültigkeit zeitlich beschränkt ist.

Eine erste Softwareimplementierung dieses Konzepts für PHP-basierte Webanwendungen bietet die Bibliothek DSLib [3]. Diese realisiert Benutzersessions, die über zwei Server (MDAT und IDAT) synchronisiert werden, stellt eine Schnittstelle zur Verwaltung von Temp-IDs bereit und unterstützt das dynamische Nachladen von Daten im Webbrowser. Wegen der Verwendung von Java für die Implementierung von OSSE war ein direkter Einsatz der DSLib aber nicht möglich.

Als Patientenliste kommt in OSSE die Mainzelliste [4] zum Einsatz. Diese stellt die Funktionen einer zentralen Patientenliste (z.B. Anlegen von Patienten, Erzeugen von Pseudonymen) über eine REST-Schnittstelle zur Verfügung. Seit ihrer Version 1.3.0 unterstützt die Mainzelliste auch das für den gegebenen Fall benötigte Nachladen von IDAT im Webbrowser.

Ergebnisse: Um die benötigte Funktionalität umzusetzen, wurde die Java-Bibliothek Mainzelliste.Client implementiert, die das Konzept der DSLib aufgreift und die Schnittstelle der Mainzelliste anspricht. Die Bibliothek wurde als Open-Source-Software unter der AGPL-Lizenz veröffentlicht und steht im Quellcode auf der Plattform Bitbucket zur Verfügung (https://bitbucket.org/medinfo_mainz/mainzelliste.client). Die Implementierung als unabhängige Bibliothek bietet eine Reihe von Vorteilen:

• Technische Details wie der Aufbau von Netzwerkverbindungen und die Fehlerbehandlung werden
• transparent gehandhabt.
• Häufig benutzte Parameter müssen nur einmal im Programmablauf gesetzt werden.
• Die Komponente ist für andere Projekte wiederverwendbar.

Mainzelliste.Client bildet die Struktur der Schnittstelle der Mainzelliste in Form von Klassen und Methoden ab. Eine konkrete Instanz der Mainzelliste wird durch ein Objekt der Klasse „MainzellisteConnection“ repräsentiert, welches alle Zugriffe auf die Instanz abwickelt. MainzellisteConnection speichert neben der URL der Instanz auch das zur Authentifizierung benötigte Zugangspasswort („API-Key“), dieses wird dann bei allen Aufrufen der Mainzelliste automatisch mitübertragen:

MainzellisteConnection con = new MainzellisteConnection("https://patientenliste.de/beispiel", "sesame");

Für die weitere Kommunikation werden über die instanziierte MainzellisteConnection Sitzungen („Sessions“) aufgebaut:

Session mySession = con.createSession();

Eine Session dient der Mainzelliste als Container für Zugriffstokens. Aus Gründen der Sicherheit und Wartbarkeit implementiert die Mainzelliste nämlich keine eigene Nutzerdatenbank, sondern eine delegierte Authentifizierung: Es authentifiziert sich nur die zugreifende Anwendung (z.B. ein Register) gegenüber der Mainzelliste. Individuelle Benutzer erhalten über Tokens, deren Gültigkeit an die Lebensdauer der zugehörigen Session gebunden ist, Zugriff auf definierte Funktionen (z.B. „Patient anlegen“). Auch Tokens werden in Mainzelliste.Client durch eigene Klassen repräsentiert. Diese bieten Methoden, um die vom Tokentyp abhängigen Parameter zu setzen, im folgenden Beispiel den angeforderten Pseudonymtyp eines „addPatient“-Tokens:

AddPatientToken t = new AddPatientToken(); t.addIdType("pid");

Mittels des Sessionobjekts wird das Token auf der Mainzelliste angelegt und die Token-Id zurückgegeben:

String tokenId = mySession.getToken(t);

In Anlehnung an die DSLib werden Methoden zum Übersetzen von permanenten Pseudonymen in Temp-IDs und umgekehrt angeboten. Als Erweiterung gegenüber der DSLib kann dabei der Zugriff auf bestimmte Datenfelder des Patienten beschränkt werden (im Beispiel Monat und Jahr des Geburtsdatums):

List<String> fieldsToShow = Arrays.asList("geburtsmonat", "geburtsjahr");

String tempId = mySession.getTempId(new ID("pid", "ZJN5EUNZ"), fieldsToShow, null);

Um das Nachladen identifizierender Daten im Webbrowser zu realisieren war es ausreichend, den Javascript-Code der DSLib um eine Schnittstelle zur Mainzelliste zu erweitern. Für HTML-Elemente, die IDAT enthalten sollen, wird mittels spezieller Attribute die Temp-ID des Patienten („data-tempid“) sowie das anzuzeigende Feld („data-subject“) definiert:

<span data-subject="geburtsjahr", data-tempid="4aff5b70be484178ab410a2b897f4354" />

Clientseitig sammelt der sogenannte „Temp-ID-Resolver“ alle entsprechend ausgezeichneten Elemente, ruft die gewünschten IDAT mittels asynchroner Zugriffe von der Mainzelliste ab (sofern sie nicht im internen Cache auffindbar sind) und fügt sie an den passenden Stellen ein. Der Entwickler muss dafür nur wenige Zeilen Javascript-Code ergänzen:

tempIdResolver = tempIdResolverConstructor(\'7buseDefaultResolver:"mainzellisteResolver",

mainzellisteURL:"https://patientenliste.de/beispiel"\'7d);

$(document).ready(function() \'7b

tempIdResolver.resolve();

\'7d);

Diskussion: Mainzelliste.Client kommt sowohl in OSSE als auch in der CCP-IT des Deutschen Konsortiums für Translationale Krebsforschung (DKTK) [5] zum Einsatz und hat in diesen Projekten seine Praxistauglichkeit bewiesen. Die Realisierung als unabhängiges Modul erleichterte die Arbeitsteilung bei der Entwicklung der zugehörigen Softwarekomponenten und vermied konkurrierende Lösungen innerhalb des achtköpfigen Entwicklerteams.

Durch die Verwendung des Build-Management-Tools Maven kann Mainzelliste.Client einfach in andere Anwendungen integriert werden; die wenigen Abhängigkeiten zu Drittbibliotheken werden dadurch automatisch aufgelöst. Da die Kommunikation mit der Mainzelliste ausschließlich über die offene REST-Schnittstelle abläuft, kann Mainzelliste.Client prinzipiell jede Patientenliste ansprechen, die diese Schnittstelle implementiert. Umgekehrt ist die Schnittstelle der Mainzelliste für Clientsysteme, bei deren Implementierung die Verwendung von Mainzelliste.Client nicht möglich oder erwünscht ist, weiterhin auch direkt per HTTP ansprechbar.

Durch die delegierte Authentifizierung per Zugrifftokens entfällt eine doppelte Benutzerverwaltung in zugreifender Anwendung und Patientenliste; dies erleichtert insbesondere den Betrieb der Mainzelliste durch einen Dienstleister. Mainzelliste.Client unterstützt diesen Mechanismus im Besonderen beim Einsatz von Temp-IDs für den datenschutzgerechten Zugriff auf identifizierende Daten aus dem Webbrowser des Benutzers heraus.

Ein wichtiger Fokus bei der weiteren Entwicklung der Bibliothek wird sein, auch in Anwendungsfällen mit großen Nutzer- und Patientenzahlen eine hinreichende Performance sicherzustellen, da das atomare Konzept der an die Mainzelliste gesendeten REST-Aufrufe (ein Request pro angeforderter Temp-ID) dann möglicherweise an seine Grenzen stößt. Es wird zu prüfen sein, ob hier Techniken wie Parallelisierung oder HTTP-Pipelining vorteilhaft eingesetzt werden können.