gms | German Medical Science

Einleitung (inkl. Ziele / Anforderungen): In der medizinischen Verbundforschung verwendete Software muss sensible Patientendaten datenschutzkonform und technisch korrekt verarbeiten. Softwaretests sind ein Werkzeug, diese Korrektheit nachvollziehbar zu prüfen. Die Mainzelliste ist eine Web-basierte Implementierung einer Patientenliste, die sich inzwischen in vielfachem produktivem Einsatz befindet [1]. Mit der wachsenden Komplexität der Anwendung, u.a. durch Codebeiträge aus der Open-Source-Community [2], nimmt auch der Aufwand zu, mittels manueller Softwaretests die Konformität zur dokumentierten Schnittstelle [3] zu prüfen. Die Implementierung automatisierter Tests hingegen ist im Fall einer Patientenliste anspruchsvoll, weil ein solches System kein isoliertes Programm ist, sondern neben der klassischen Betriebsumgebung (Datenbank, Applikationsserver) auch mit anderen Systemen kommuniziert.

Stand der Technik (verwandte Arbeiten & Nachteile): Heutzutage verwendet man meistens automatisierte Unit Tests, um die Softwarefunktionalität schon in der Entwicklungsphase zu überprüfen [4]. Diese Tests sind auf die kleinsten Programmeinheiten orientiert, meistens Klassen, und werden vor einem Deployment automatisiert durchgeführt. Als Testframework für Java Anwendungen wird oft JUnit verwendet. Im Fall der oben erwähnten Abhängigkeiten zu anderen Anwendungen erscheint das isolierte Testen einzelner Klassen nicht ausreichend. In solchen Fällen können Black-Box-Tests nicht nur einzelne Komponenten überprüfen, sondern auch komponentenübergreifende Prozesse.

Konzept: Kern der Testumgebung ist die Mainzelliste in einem leichtgewichtigen Applikationsserver mit In-Memory-Datenbank. Black-Box-Tests werden unter Nutzung der Schnittstelle durchgeführt. Obwohl diese Tests somit keine echten Unit-Tests [4] sind, wird das JUnit-Framework genutzt, damit zusätzlich einzelne Backendklassen geprüft werden können.

Die Erstellung eines Testdatensatzes ist problematisch, da dieser aus identifizierenden Patientendaten (IDAT) bestehen müsste und dadurch keine anonymisierten/pseudonymisierten Realdaten verwendet werden können. Zur Veröffentlichung in einem Open-Source-Projekt kommen somit nur synthetische Testdaten infrage.

Umsetzung: In Rahmen des DFG-geförderten MAGIC-Verbunds [5] wurde eine Testumgebung für die Mainzelliste implementiert. Zur Implementierung der Testumgebung wurden der Jersey RESTful Webservice und die Apache Derby In-Memory-Datenbank verwendet. Die implementierten Tests können in zwei Gruppen unterteilt werden:

• Tests zur Prüfung der Funktionalität der Schnittstelle (korrekte Schnittstellenfunktionalität und Umgang mit inkompletten oder falschen Angaben).
• Tests zur Prüfung des Record Linkage mithilfe synthetisch erzeugter IDAT. Dabei muss jeder Patient genau ein Pseudonym erhalten und auch bei kleinen Fehlern oder Änderungen (z.B. Namenswechsel) wiedererkannt werden. Für diesen Zweck wurde ein Testdatensatz erstellt, welcher typische Fehlerquellen berücksichtigt.

Gewonnene Erkenntnisse: Die Testumgebung kann eine echte Betriebsumgebung für Patientenlisten modellieren, aber nicht vollständig ersetzen. Aufgrund des Black-Box-Testings kann dieselbe Test-Suite prinzipiell auch für andere Implementierungen derselben REST-Schnittstelle verwendet werden. Eine umfassende Prüfung des Record Linkage, die nicht nur die grundsätzlich korrekte Funktion sicherstellt, sondern auch die Güte der Fehlererkennung misst, erfordert hingegen einen großen Datensatz repräsentativer IDAT samt Kenntnis von Fehleingaben und kann daher nicht open-source veröffentlicht, sondern nur lokal ausgeführt werden. Anwender der Mainzelliste können die Testumgebung aber in Kombination mit eigenen Testdaten nutzen, um die Record-Linkage-Konfiguration an eigene Anwendungsfälle anzupassen. Nicht zuletzt erleichtern automatisierte Tests die Integration externer Codebeiträge und fördern damit die Weiterentwicklung durch die Nutzergemeinschaft.

Die Autoren geben an, dass kein Interessenkonflikt besteht.