gms | German Medical Science

GMDS 2014: 59. Jahrestagung der Deutschen Gesellschaft für Medizinische Informatik, Biometrie und Epidemiologie e. V. (GMDS)

Deutsche Gesellschaft für Medizinische Informatik, Biometrie und Epidemiologie

07. - 10.09.2014, Göttingen

Dynamische Generierung einer Ontologie in dem klinischen Data Warehouse i2b2

Meeting Abstract

  • C. Karmen - Universität Heidelberg, Heidelberg
  • M. Ganzinger - Universität Heidelberg, Heidelberg
  • D. Firnkorn - Universität Heidelberg, Heidelberg
  • C. Kohl - Universität Heidelberg, Heidelberg
  • P. Knaup-Gregori - Universität Heidelberg, Heidelberg

GMDS 2014. 59. Jahrestagung der Deutschen Gesellschaft für Medizinische Informatik, Biometrie und Epidemiologie e.V. (GMDS). Göttingen, 07.-10.09.2014. Düsseldorf: German Medical Science GMS Publishing House; 2014. DocAbstr. 366

doi: 10.3205/14gmds082, urn:nbn:de:0183-14gmds0822

Veröffentlicht: 4. September 2014

© 2014 Karmen et al.
Dieser Artikel ist ein Open Access-Artikel und steht unter den Creative Commons Lizenzbedingungen (http://creativecommons.org/licenses/by-nc-nd/3.0/deed.de). Er darf vervielfältigt, verbreitet und öffentlich zugänglich gemacht werden, vorausgesetzt dass Autor und Quelle genannt werden.


Gliederung

Text

Einleitung und Fragestellung: Bei medizinisch-wissenschaftlichen Untersuchungen wird eine Vielzahl von klinischen Daten erhoben, um die Wirksamkeit verschiedener Therapien zu einem speziellen Krankheitsbild zu untersuchen. Zu diesem Krankheitsbild existiert eine große Anzahl von Merkmalsausprägungen, welche aus einer Kohorte von Patienten stammen. Das Ziel dieser Datenerhebung besteht darin, einen Rückschluss darüber zu gewinnen, welche Therapie bzw. welche Dosis unter welchen Umständen die zukünftige Versorgung ähnlicher Fälle optimiert. Um die statistische Signifikanz und damit die Aussagekraft der Untersuchungsergebnisse aus dieser Datenbasis zu erhöhen, ist eine größtmögliche Fallzahl erforderlich. Oft reichen die gesammelten klinischen Daten einer einzigen medizinischen Einrichtung dazu nicht aus, sodass mehrere Einrichtungen ihre medizinischen Faktendaten in einer multi-zentrischen Datenbank zusammenführen [1].

Die Integration von klinischen Daten erfordert einen nicht unerheblichen Aufwand. In der Regel verfolgt jede Einrichtung mit der Sammlung von Daten zu einem Krankheitsbild einen genau definierten Forschungszweck. Weiterhin unterscheiden sich die Anzahl und Granularität der erfassten Daten, sowie die Art der Labormessungen, die Maßeinheiten, oder auch die als klinisch relevant angesehen Merkmale an sich. Durch diese Diversität ist meist ein Harmonisierungsprozess notwendig, in dem sich die Domänenexperten aller beteiligten Einrichtungen auf eine gemeinsame Datenbasis und -struktur einigen müssen. Dabei kommt in vielen Fällen ein elektronisches tabellarisches Dokument zum Einsatz, die sogenannte Harmonisierungstabelle, welche die Datenintegration aller teilnehmenden klinischen Einrichtungen beschreibt. Der Harmonisierungsprozess beansprucht erfahrungsgemäß mehrere Monate. Auch nach begonnener Datenintegration können sich Datendefinitionen aufgrund von Anforderungen der Endanwender und bisher nicht in Betracht gezogener Merkmale noch in vielen Details ändern. Daher ist es eine wichtige Voraussetzung, dass auf Änderungen in der Datenstruktur flexibel reagiert werden kann.

Das in diesem Kontext häufig eingesetzte Data Warehouse (DWH) i2b2 [2] bietet bezüglich der Handhabung der Datenstruktur noch einige Schwachstellen. So steht zwar ein Editor zur Erstellung einer hierarchischen Baumstruktur (i2b2 Ontology) für klinische Merkmale zur Verfügung, jedoch lassen sich diese nicht in der Baumstruktur verschieben, sodass sie manuell gelöscht und neu angelegt werden müssen. Dies hat auch Auswirkungen auf bereits integrierte Daten, denn es muss auf die Integrität zwischen der Merkmalsart (Konzept) und Merkmalsausprägung (Fakt) geachtet werden. Eine IT-Lösung, welche die definierte Datenstruktur schon während des Harmonisierungsprozesses aufbereiten, verarbeiten und in die i2b2 Ontology exportieren kann, erhöht die Flexibilität der Datenintegration drastisch. Ebenfalls wird die Komplexität der Datenpflege und -aktualisierung geringer, da nur noch in der Harmonisierungstabelle Änderungen nachgepflegt werden müssen, die als Grundlage zum Aufbau der i2b2 Ontology dient.

Material und Methoden: Das von den National Institutes of Health (NIH) [3] geförderte DWH i2b2 ist speziell für klinische Merkmalsdaten ausgelegt und eignet sich besonders gut für das Szenario einer multi-zentrischen Datenhaltung. Die Datenspeicherarchitektur ist auf hohe Analysegeschwindigkeit ausgelegt und erlaubt eine dynamische Erweiterung der Merkmalsarten. I2b2 ist als Open Source Software verfügbar und verfolgt einen modularen und damit äußerst flexiblen Ansatz, um eigene Erweiterungen zu entwickeln. Es verfügt über die Möglichkeit des Kohortenmanagements mit Hilfe einer Abfragemaske (Query Tool). Hier können einzelne Knoten (Merkmalsarten) und Blätter (Merkmalsausprägungen) mit Hilfe der Maus aus der i2b2 Ontology in Filtergruppen zusammengefasst werden.

Ergebnisse: Wir stellen eine Lösung vor, bei der eine mit Microsoft Excel erstellte Harmonisierungstabelle so erweitert werden kann, dass sie als Vorlage für eine automatische Generierung der i2b2 Ontology dient. Ausgangspunkt ist das Anlegen eines zusätzlichen Tabellenblattes, welches ausschließlich für die automatische Generierung der i2b2 Ontology verwendet wird. Dieses Tabellenblatt folgt einem vorgegeben Datenschema, welches auf das Tabellenblatt mit den gesammelten Harmonisierungsdaten verweist. Darunter fallen u.a. die kurze und lange Merkmalsartbeschreibung, der Datentyp bzw. die Merkmalsausprägungen, ggf. die Masseinheit und die Referenz (Konzept-Code) auf Merkmalsausprägung (Konzept). Damit ist gewährleistet, dass die Merkmalshierarchie nur zentral an einer Stelle gewartet werden muss. Anschließend verwerten wir das genannte neue Ontologie-Tabellenblatt und laden die Informationen direkt in die i2b2 Ontology. Wir verwenden die Open Source ETL (Extraktion, Transformation, Laden) Software Talend Open Studio for Data Integrations [4] auf eine Weise, dass damit ein alleine lauffähiges Programm entsteht. Dies ist in der Lage, nach entsprechender Parametrisierung der i2b2 Konfiguration und der Lokalität der Harmonsierungstabelle, eine Synchronisation zwischen der Harmonisierungstabelle und der i2b2 Ontology herzustellen.

Als Ergebnis dieses Vorgehens lässt sich nahtlos, und dynamisch aus dem Harmonisierungsprozess heraus, eine i2b2 Ontology erzeugen. Damit wird eine flexible Baumstruktur in i2b2 eingeführt, welche nicht mehr mit Hilfe des i2b2 eigenen Ontologie-Editors nachgebessert werden muss. Änderungen der i2b2 Ontology müssen jetzt nur noch an einer zentralen Stelle, der Harmonisierungstabelle, nachgepflegt werden und können sofort nach Aufruf unserer Software in i2b2 verwendet werden. Dadurch ist eine Beschleunigung der technischen Umsetzung des Harmonisierungsprozesses zu erwarten.

Diskussion: Zusammenfassend lässt sich sagen, dass unser Ansatz einer flexiblen i2b2 Ontology durch Mitnutzung der Informationen einer vorhandenen Harmonisierungstabelle vielversprechend ist. Der geringe Mehraufwand zur Bereitstellung der vorgegebenen Beschreibung der Merkmalshierarchie in dem genannten neuen Tabellenblatt steht in keinem Verhältnis zur Zeitersparnis bei der ansonsten anfallenden technischen Umsetzung.

Noch nicht ausdiskutiert und somit offen bleibt die Problematik von nun nötigen Schutzmechanismen von benötigten Spalten in der Harmonisierungstabelle für das neue Tabellenblatt der i2b2 Ontology Generierung. Eine Verschiebung von Spalten darf hier nachträglich nicht stattfinden, da dies zu falschen Interpretationen in der i2b2 Ontology führen würde.

Für die Zukunft ist vorstellbar, dass bei genügend großer Anwenderakzeptanz ein i2b2-Plug-In anstelle des ETL-Werkzeuges tritt. Somit ist eine engere Kopplung des Harmonisierungsprozesses mit i2b2 erreicht.

An der Universität Erlangen wurde die Problematik des i2b2 Ontology Managements ebenfalls erkannt. Dort wird an der „OntoImportSuite“ [5] gearbeitet, einer sinnvollen Werkzeugkette bestehend aus einem Ontologie-Editor, der semantischen Verknüpfung der Daten des Quellsystems und dem Laden in die i2b2 Ontology. Diese Werkzeuge können ergänzend zu dem i2b2-eigenen Ontologie-Editor verwendet werden und die Problematik der nicht verschiebbaren Hierarchieelemente lösen. Allerdings besteht hier der zusätzliche Aufwand innerhalb des Harmonisierungsprozesses, dass die Merkmalshierarchie parallel zu der Harmonisierungstabelle gewartet werden muss.

Eine andere Möglichkeit, um das Management der i2b2 Ontology flexibler zu gestalten, ist die Implementierung einer Drag-and-Drop Funktionalität im i2b2-eigenen Ontologie-Editor. Dadurch ist zwar eine schnelle und komfortablere Bearbeitung der Merkmalshierarchie im Sinne des Rapid Prototyping möglich, es wird jedoch auch hier nicht die Problematik der Pflege der redundanten Ontologie-Informationen gelöst.


Literatur

1.
European Union 7th Framework Programme, EURenOmics. Available from: http://www.eurenomics.eu [last accessed: 2014 Mar 30] Externer Link
2.
Murphy SN, Mendis M, Hackett K, Kuttan R, Pan W, Phillips LC, Gainer V, Berkowicz D, Glaser JP, Kohane I, Chueh HC. Architecture of the open-source clinical research chart from Informatics for Integrating Biology and the Bedside. AMIA Annu Symp Proc. 2007 Oct 11:548-52.
3.
National Institutes of Health (NIH). Available from: http://www.nih.gov/about/index.html [last accessed: 2014 Mar 30] Externer Link
4.
Talend Open Studio, Talend Inc. 2014. Available from: http://www.talend.com Externer Link
5.
OntoImportSuite. Available from: http://www.imi.med.uni-erlangen.de/tools/ontoimportsuite/ [last accessed: 2014 Mar 30] Externer Link