gms | German Medical Science

Einleitung & Zielsetzung: Der konsortienübergreifende Use Case POLAR („POLypharmazie, Arzneimittelwechselwirkungen und Risiken“) zielt auf die Detektion von Gesundheitsrisiken bei Patientinnen und Patienten mit Polymedikation ab. Möglicherweise inadäquate Medikationen sollen dabei rechtzeitig erkannt und unerwünschte Wechselwirkungen vorgebeugt werden [1].

Für diesen Prozess wurde eine einzigartige ETL-Strecke geschaffen, deren Ziel es ist, in unterschiedlichen Datenintegrationszentren (DIZ) die zur Beantwortung verschiedenster Fragestellungen notwendigen Daten zu extrahieren und diese vor Ort so aufzubereiten und lokal auszuwerten, dass eine zentrumsübergreifende Meta-Analyse möglich ist. Gleichzeitig müssen bei der Datentransformation verschiedene Aspekte rund um das Thema Datenschutz berücksichtigt werden; ein Bauteil dafür ist die zuvor erwähnte verteilte Analyse (lokale Auswertung, zentrale Meta-Analyse). Zu diesem Zweck wurden verschiedene Teilprojekte definiert, die zu unterschiedlichen Projektzeitpunkten realisiert wurden.

Methode: Die eigentliche ETL-Strecke wurde wie folgt entwickelt: (a) zu untersuchende Fragestellung [Pharmakologie/Pharmazie], (b) Definition notwendiger Ressourcen für die Beantwortung der Fragestellung und Übersetzung der Fragestellung in einen statistischen Analyseplan [Biometrie, IT], (c) Entwicklung der Retrieval- und Analyse-Skripte für die lokale Auswertung [Biometrie, IT], (d) Durchführung der lokalen Auswertung und Datenausleitung (d.h. Übermittlung der lokalen Ergebnisse) [DIZ], (e) Meta-Analyse der lokalen Ergebnisse [Biometrie], (f) Auswertung/Analyse der Ergebnisse, Fehlersuche und Skriptoptimierung [Biometrie, IT, Pharmazie/Pharmakologie] und zurück zu (b) bzw. zu (a) für eine notwendige Anpassung der Fragestellung.

Die technische Realisierung der ETL-Strecke erfolgt dabei unter Einsatz der nachfolgenden Technologien: Docker, R, git und FHIR. Exemplarisch sei an dieser Stelle das entwickelte R-Paket fhircrackr [2] genannt, welches inzwischen für eine über POLAR und SMITH hinausgehende Community auf dem R Project CRAN (https://cran.r-project.org/web/packages/fhircrackr/index.html) bereit steht.

Die praktische Umsetzung der ETL-Strecke setzt eine harmonisierte Art und Weise der Datenbereitstellung voraus. Skripttechnisch wurde dies über die Bereitstellung der ETL-Skripte als Docker-Container realisiert, während die Bereitstellung der Krankenhaus-Daten im FHIR-Format erfolgt (s. Abbildung 1 [Abb. 1]). Der von uns bereitgestellte Docker-Container [3] startet dabei eine Serie von FHIR-Requests, um die auszuwertenden Daten abzurufen und lokal auszuwerten. Die finalen, aggregierten lokalen Ergebnisse werden anschließend an die Biometrie übermittelt, welche die lokalen Ergebnisse in einer übergreifenden Meta-Analyse kombiniert, um ein Gesamtergebnis zu erhalten. Die Ergebnisse der Meta-Analyse wurden im Rahmen des Projektes regelmäßig vorgestellt und wurden auch für eine inhaltliche Plausibilitätsprüfung and die Pharmazie/Pharmakologie übermittelt, um mögliche Daten- oder Skriptinkonsistenzen bzw. -fehler zu identifizieren.

Ergebnis: Nach Umsetzung von drei der insgesamt fünf Teilprojekte wurde in einer ersten Revision festgestellt, dass die ursprünglich geplante ETL-Strecke aufgrund diverser Gegebenheiten an den Kliniken und angeschlossenen DIZ nicht von Beginn an eingesetzt werden konnte. Die sehr „naive“ Herangehensweise, bei der zunächst eine Expertengruppe für die Pharmazie/Pharmakologie relevante Fragestellungen definiert, sowie die dafür notwendigen Medikations-, Diagnose- oder Laborressourcen festlegt, brachte nur wenige verwertbare Ergebnisse. Hierbei wurden verschiedene Probleme im ETL-Prozess ausgemacht:

1.

Die sehr heterogene Datenlage, sowie die unterschiedlich detaillierte Umsetzung der Datenintegration im KDS-FHIR-Profil [4] über alle Projektpartner stellt eine Herausforderung bei der erfolgreichen Datenextraktion dar.

2.

Die als Zielstellung zu klärenden Fragestellungen und ihre Vorgaben zur Beantwortung, z.B. eine bestimmte zeitliche Abfolge der Medikationsgabe (teilweise in Verbindung mit der Erhebung von Laborwerten), erwiesen sich als zu strikt.

3.

Die vorgegebenen Fragestellungen sollten stets umfassend und vollständig ungeachtet ihrer Komplexität beantwortet werden.

4.

Die im FHIR-Format hinterlegten Zeitstempel sind häufig ungeeignet, um vermeintlich einfache Fragen damit adressieren zu können. Als Beispiel sei hier erwähnt, dass an manchen Standorten nur 3 vorspezifizierte Uhrzeiten pro Tag für die Gabe mor-gens/mittags/abends hinterlegt wird, statt der tatsächlichen Zeitstempel. Der Zeitpunkt der Gabe ist somit nicht exakt dokumentiert. Unklar bleibt dann, wie mit den lokalen Dokumentationsgegebenheiten umgegangen werden soll, um multizentrische Abfragen zu einem Sachverhalt verlässlich gestalten zu können.

5.

Der Rechenaufwand und die notwendigen Ressourcen, um die eigentlichen Daten aus FHIR zu extrahieren, wurde unterschätzt. Simple Programmier- oder Auswertungsfehler sorgten so für Verzögerungen von mehreren Wochen.

6.

Die ETL-Schiene wurde auf Live-gepflegten Daten etabliert. Lokale Anpassungen im Datenintegrationsprozess zogen somit Modifikationen bei der Datenextraktion nach sich.

Diskussion: Aus diesen Erfahrungen heraus wurde für zwei weitere Teilprojekte die vorhandene Strategie modifiziert. Dabei wird über mehrere Ausleitungszyklen hinweg ein iterativer, modularer Aufbau inklusiver schrittweiser Entwicklung der Fragestellungen angestrebt. Dabei sollten zunächst sehr einfache Fragen (z.B. Patient hat eine bestimmte Diagnose erhalten, dem Patient wurde ein bestimmtes Medikament verordnet/gegeben) beantwortet werden. Mit diesen Antworten wurden Probleme im Datenbestand identifiziert, die eine Anpassung der weiteren und komplexeren Fragestellungen erforderten. Schlussendlich konnten bei hinreichender Beantwortung einfacher Fragestellungen neue Ressourcen hinzugezogen werden, um die Beantwortung einer komplexeren Frage zu ermöglichen. Diese Vorgehensweise erwies sich als vorteilhaft, da über mehrere Iterationen auf eine bis dato unbekannte Datenlage oder fehlende Daten reagiert werden konnte.

Zukünftig soll die ETL-Strecke so modifiziert werden, dass der eigentliche Extraktionsprozess von der Transformation der Daten entkoppelt erfolgt. So muss der vergleichsweise teure Extraktionsprozess nicht mehrfach gestartet werden, einfache Analysen können auf einem stabilen Datenbestand mehrfach modifiziert und wiederholt werden. Hierzu ist eine detaillierte Planung der benötigten Daten essentiell und ein Anforderungsprofil zu den erwarteten Informationen angelehnt an die elektronische Patientenakte, den Versorgungsprozess und den verwendeten Codierungsstandards notwendig.