FHIR-to-OMOP ETL-Prozess

Zur vereinheitlichten Analyse von Daten für die nationale und internationale medizinische Forschung müssen die Daten aus Kliniken harmonisiert und standardisiert werden. Observational Medical Outcomes Partnership (OMOP) Common Data Models (CDM) von Observational Health Data Sciences and Informatics (OHDSI) Community ist für die Analyse von großen Datenmengen und den Aufbau von Kohorten geeignet, was bedeutet, dass eine Übertragung der lokalen medizinischen Daten nach OMOP CDM für eine Teilnahme an der medizinischen Forschung erforderlich ist. Dieser Prozess wird jedoch durch die große Vielfalt der Datenverwaltungssysteme und die heterogenen Daten, die sie produzieren, erschwert. Um das Problem zu erleichtern, wurde ein Kerndatensatz (KDS) im Fast Healthcare Interoperability Resources (FHIR) Format aus Health Level 7 (HL7) im Rahmen der Medizininformatik Initiative (MI-I) definiert. Allerdings ist eine direkte Überführung von lokalen Daten in ein standardisiertes Format nicht immer möglich, da nicht alle Krankenhausdatenverwaltungssysteme über eine entsprechende Schnittstelle verfügen. Dafür haben wir den FHIR-to-OMOP ETL-Prozess implementiert.

Dieser ETL-Prozess unterstützt derzeit OMOP CDM v5.3.1 als Ziel und GECCO Profile und die Version v1.0 der folgenden Profile aus MI-I KDS Basis Module als Quelle:

Dieser ETL-Prozess ist mit Java17 und Springbatch-Framework implementiert. Für eine einfachere Ausführung ist der ETL-Prozess bereits dockeresiert.

Der ETL-Prozess ist sowohl mit  FHIR-Gateway als auch FHIR Server (HAPI oder Blaze) kompatibel.

Ausführungsmodi

Bulk Load

Bei diesem Modus wird die OMOP CDM Datenbank komplett geleert und wieder mit Daten gefüllt. In der Regel wird der BulkLoad-Modus als Initial-Load verwendet. Alle FHIR Ressourcen in FHIR Gateway oder FHIR Server (HAPI oder Blaze), die nicht als storniert gekennzeichnet sind, werden durch diesem ETL-Prozess eingelesen und in OMOP CDM transformiert.

Inkremental Load

Bei diesem Modus wird die OMOP CDM Datenbank nicht geleert. Der ETL-Prozess liest und transformiert nur die FHIR Ressourcen, die sich seit letzten Ausführung des ETL-Prozesses geändert haben (aktualisieren und löschen) oder die in FHIR-Gateway oder FHIR Server (HAPI oder Blaze) neu hinzugekommen sind.

Um die referentielle Integrität zu gewährleisten, werden alle FHIR Ressourcen in beide Modi in einer bestimmten Reihenfolge ausgeführt:

Patient  ->  Fall (Einrichtungskontakt, Abteilungskontakt) -> restliche Ressourcen