gms | German Medical Science

Einleitung: Um Integrationsprobleme zu lösen, die bei der Sekundärnutzung von Gesundheitsdaten entstehen, werden Common Data Models (CDM) entwickelt. Das OMOP (Observational Medical Outcome Partnership) CDM ist ein solches Modell, das als Mechanismus zur Standardisierung der Struktur, des Inhalts und der Semantik von Gesundheitsdaten dient [1]. Das Modell wird von der OHDSI-Community betreut und entwickelt. Die Machbarkeit der Abbildung deutscher Versorgungsdaten auf das Modell wurde bereits in früheren Arbeiten gezeigt [2], [3], [4]. Die folgende Arbeit soll zeigen, ob ein beispielhaftes Mapping eines multizentrischen Registers mit Forschungsdaten auf das OMOP CDM möglich ist.

Methodik: Als Quelldatensatz für dieses Vorhaben dient ein Register zur Dokumentation der Akuten Myeloischen Leukämie, welches aus verschiedenen Events besteht, deren Dokumentation mittels elektronischer Case Report Forms erfolgt. Um das Mapping durchzuführen, wurde zunächst ein Extract-Transform-Load-Prozess (ETL) entworfen. Die Daten wurden mit White-Rabbit gescannt und ein Design für den ETL-Prozess wurde mit Hilfe von Rabbit-In-A-Hat entworfen [5]. Die Mappings der Konzept-Codes wurden mit Hilfe des Online-Repositories Athena und dem OHDSI-Tool Usagi erstellt. Schließlich wurde der ETL-Prozess mit Talend Open Studio for Data Integration implementiert und die Daten wurden in eine PostgreSQL-Datenbank geladen. Die Qualität der abgebildeten Daten wurde mit dem Data Quality Dashboard überprüft und das Mapping wurde quantitativ ausgewertet. Abschließend wurden die Erfahrungen mit den Tools und dem Modell dargestellt.

Ergebnisse: Es konnten 14 OMOP-Tabellen und 51.9% der Felder im Modell befüllt werden. Alle Pflichtfelder konnten befüllt werden mit Ausnahme der Felder „Race“ und „Ethnicity“, da die Quelldaten keine Informationen zu diesen Feldern beinhalten. Für diese Felder wurde die Konzept-ID 0 („no matching concept“) genutzt. Die Tabelle OBSERVATION wurde auch für nicht-klinische Beobachtungen und „Ereignis-ergänzende“ Felder für einige Quellfelder genutzt. Drei Datenfelder konnten aus Datenschutz-Gründen nicht abgebildet werden: Vorname, Nachname, Klinik-interne ID. 61,6% der Werte konnten einem eindeutigen Konzept zugeordnet werden, für 3% der Werte musste „Uphill-Mapping“ genutzt werden und 11,5% der Werte mussten auf 0 („no matching concept“) abgebildet werden. Außerdem konnten 3,9% der Werte nicht gemappt werden, da das Nicht-Eintreten von Ereignissen in OMOP nicht gespeichert werden kann. Das Data Quality Dashboard zeigte eine Qualität von 98%, stellt aber auch „Fails“ im Mapping dar. Die OHDSI-Tools und das OMOP CDM waren einfach zu verstehen und nutzen.

Diskussion: Es konnte gezeigt werden, dass ein exemplarisches Mapping in begrenztem Umfang möglich ist. Die fehlende Möglichkeit, Ereignisse im OMOP CDM zu speichern, die nicht eingetreten sind, führte zu einem Informationsverlust. Für einige genetische Veränderungen fehlten passende Konzepte. Das Mapping von Freitextfeldern wurde aus Ressourcengründen nicht durchgeführt. Die Zeichenbeschränkung einiger Felder im Modell führte ebenfalls zu einem Informationsverlust. Die endgültigen Abbildungen konnten mangels medizinischer Kenntnisse nicht auf ihre Korrektheit überprüft werden, daher sollten für zukünftige Mapping-Projekte medizinische und terminologische Experten zusammenarbeiten. Die Werkzeuge unterstützten den ETL-Designprozess, aber es gibt kein ETL-Tool, so dass der Mapping-Prozess technisches Wissen erfordert.

Schlussfolgerung: Das OMOP CDM eignet sich, um einen exemplarischen Forschungsdatensatz abzubilden. In weiteren Schritten sollten die Daten über das Modell abgefragt und die Eignung für typische Analysen von Registerdaten geprüft werden.

The authors declare that they have no competing interests.

The authors declare that an ethics committee vote is not required.