gms | German Medical Science

Einleitung und Zielstellung: Um die übergreifende Funktionalität der vier Konsortien der Medizininformatik-Initiative (MII) zu demonstrieren wurde 2018 vom BMBF ein Programm zur Förderung von übergreifenden Use Cases gestartet. Das Vorhaben POLypharmazie – Arzneimittelwechselwirkungen – Risiken (POLAR) wurde 2019 bewilligt. Beteiligt sind 13 Standorte aller Konsortien; davon 6 der 7 SMITH Standorte. Das Vorhaben hat das Ziel, mit Methoden und Prozessen der MII einen Beitrag zur Detektion von Gesundheitsrisiken bei Patienten mit Polymedikation zu leisten [1]. Polymedikation kommt insbesondere bei älteren Patienten mit Multimorbidität vor. Dabei kann es zu Arzneimittelwechselwirkungen kommen, welche entweder die gewünschte Wirkung einzelner Wirkstoffe herabsetzen bzw. verstärken oder durch pharmakologische Wechselwirkungen zu unerwünschten Wirkungen führen. Diese können zusätzliche Krankheitsbilder und zusätzlichen Therapiebedarf auslösen, die aber bei einem besseren Arzneimittelmanagement vermeidbar wären.

Im Folgenden werden technische Aspekte beim Einsatz der verteilten Analyse auf Basis der MII-weit abgestimmten Kerndatensatz (KDS) Profile, der Verfügbarkeit der Daten, dem Zugang zu den Daten und der interdisziplinären Arbeit ausgeführt. Die verfolgten pharmakologischen Fragstellungen und das biometrische Konzept ist Fokus weiterer Veröffentlichungen.

Methoden: POLAR operiert auf retrospektiv erhobenen klinischen Routinedaten, die ausschließlich automatisiert im Behandlungskontext analysiert werden. Die für die unterschiedlichen Analysen benötigten Merkmale entstammen den KDS Modulen Demographie, Falldaten, Diagnosen, Prozeduren, Laborbefunde und Medikation. Diese wurde in einem Catalog of Items (COI) zusammengestellt, über den im Vorfeld die prinzipielle Datenverfügbarkeit an den teilnehmenden Standorten abgeklärt wurde. Eine Einwilligung der Patienten in die Verarbeitung dieser Daten ist dabei nicht erforderlich; Grundlage dieser dezentralen Analyse ist in einem speziellen Datenschutzkonzept dargelegt. Es wurde eine zweistufige Analyse durchgeführt: die erste Stufe stellt die benötigten Daten des Patientenkollektivs zusammen und erzeugt lokale Zwischenauswertungen; die zweite Stufe erfolgt zentral. Für die Standardaufgaben der FHIR-Daten-Verarbeitung wurden eigene Tools entwickelt und publiziert, die mittlerweile in der MII breit zum Einsatz kommen [2]. Die Auswertungspipeline (POLAR-Suite) wurde in R geschrieben und über Softwarecontainer (Docker) zur dezentralen Ausführung in den DIZ bereitgestellt. Voraussetzung an den Standorten ist lediglich eine FHIR Endpunkt, über den die im COI spezifizierten Daten via FHIR Search API erfragt wurden. Die lokal aggregierten Daten ohne direkten Patientenbezug wurden über sichere Übertragungswege zentral zusammengeführt und biometrisch ausgewertet. Das technische Vorgehen in POLAR entstammt den Konzepten des methodischen SMITH Use Case Phenotyping.

Ergebnisse: Es traten verschiedene Hemmnisse in diesem Prozess auf, die mehrfache Optimierungs- und Entwicklungsschleifen über alle Gewerke (Pharmakologie/Pharmazie, Biometrie, Entwicklung, Datenintegrationszentren/DIZ) nach sich zogen. Die Problembereiche lassen sich wie folgt kategorisieren; hier jeweils anekdotisch ergänzt:

1.

Heterogenität in der Umsetzung des KDS: Beispiele sind neben Profilverletzungen, z.B. fehlende Codes und falsche Codesysteme, fehlende optionale Attribute wie Stationszuordnung oder Diagnosetypen und Inter-Ressourcen-Referenzen, gerade in Bezug auf Fälle

2.

IT-Infrastruktur der DIZ, z.B. mangelnde Performanz der lokalen FHIR Server bei Abfrage großer Kohorten Datenmengen über FHIR Search API; geschuldet dem verwendeten Produkt und der technischen Ausstattung führten zu mehrtägigen Ausleitungsvorgängen

3.

Probleme der Analyseskripte: Fehler aufgrund unvorhergesehener Datenlage und auch Performanzeinbrüche aufgrund von Fehlerumgehungen. Beispiel: Fehlt technisch die Zuordnung der Medikationen zu einem Fall muss über aufwändiges Datumsmatching approximiert werden

4.

Mangelnde Datenverfügbarkeit aufgrund noch nicht angebundener Quellsysteme, insbesondere der Apotheken-Bestellsysteme oder der Dokumentation der Aufnahmemedikation, die zum Fehlen ganzer Ressourcenklassen führt (MedicationStatement, MedicationAdministration)

5.

Datensemantik und Datenqualität: Zeitliche überlappende Fälle, Fälle ohne Abschlussdatum, unerwartete Platzhalter für Fehlwerte (z.B. Geburtsdatum 1.1.1111), nicht konklusive Zeitangaben (Zeitpunkt der Medikationsgabe vor oder nach Diagnose?), Einheiten als Freitext

6.

Organisatorisch: Eine Herausforderung ist das enge interdisziplinäre Zusammenspiel, was häufig zu Fehlinterpretationen hinsichtlich der Zielstellung führte. Insbesondere die ursprünglich formulierten Fragestellungen erwiesen sich als zu strikt und damit nicht hinreichend beantwortbar

Hinzu kommen systemische Hemmnisse bedingt durch die dezentralen Analyseverfahren, die dem Entwickler/Biometriker den direkten Blick auf Datensätze verbietet.

Diskussion und Lessons Learned: Die DIZ selber befanden sich in der Laufzeit von POLAR noch im Aufbau; die Anbindung der klinischen Quellsysteme war nicht abgeschlossen. Insbesondere die Medikationsverfügbarkeit zeigte sich noch unvollständig. Die präzise Unterscheidung von Zeitpunkten (Aufnahme, Aufenthalt und Entlassung) zu Diagnose/Therapie verhindert klare Kausalitätshypothesen. Dosisberechnungen sind, anders als erwartet, noch nicht zuverlässig möglich. Die im KDS hinterlegten Profile erlauben viele Freiheiten im Mapping der klinischen Quelldaten, die übergreifend jedoch die semantische Interoperabilität einschränken. Die Methodik der verteilten Analyse verwehrt den Entwicklern und Biometrikern dabei den Blick auf die Ursprungsdaten, eine Fehleranalyse ist so stark erschwert. Übergreifende MII Infrastrukturen wie das Forschungsdatenportal Gesundheit (FDPG), das Konzept der Datenmanagementstellen oder ein breit eingeführter Broad Consent, der Patienteneinwilligung, die eine direkte zentrale Ausleitung der Daten ermöglichen würde, standen zum Projektstart nicht zur Verfügung.

Wir lernen, dass transparente Minimalstandards bzgl. des FHIR Servers/Endpunktes, so z.B. der vorhandenen FHIR Capabilities und minimale Performanzanforderungen z.B. über standardisierte MII Benchmarks auf hinreichend komplexen Testdaten notwendig sind. Eine striktere Vorgabe von KDS Profilen (z.B. Pflichtattribute in einem POLAR Profil) kann zwar definiert werden; die Datenlage der DIZ bleibt von den Möglichkeiten und Schnittstellen der Quellsysteme der Kliniken abhängig. Wichtig ist hier die verlässliche Überprüfung der Datenverfügbarkeit im Vorfeld über FHIR-basierte Werkzeuge wie dem vor kurzem verfügbaren Machbarkeitsportal des FDPG. Wir sehen, dass erst die breite Nutzung der Daten und eine stichprobenartige Plausibilisierung der Daten in den Patientenakten zu einer Verbesserung der Datenqualität führen kann.

Den aufgeführten Hemmnissen zum Trotz konnten die Ziele von POLAR, wenn auch mit vermehrtem Aufwand und teils schmerzhaften Kompromissen, weitgehend erreicht werden. Dem POLAR Use Case, insbesondere der POLAR-Suite, fiel damit eine starke Rolle als Evaluationstool für den erreichten Reifegrad der Interoperabilität innerhalb der MII-Standorte zu.