Integrated Data Repository Toolkit...

21
Integrated Data Repository Toolkit (IDRT) TMF-Projekt V091-MI_03 D4.1 Standardterminologien Report Matthias Löbe Sebastian Stäubert Prof. Dr. Alfred Winter

Transcript of Integrated Data Repository Toolkit...

Integrated Data Repository Toolkit (IDRT)

TMF-Projekt V091-MI_03

D4.1 Standardterminologien

Report

Matthias Löbe

Sebastian Stäubert

Prof. Dr. Alfred Winter

Deliverable D2.5: Anbindung §21-Datenquellen, Integrated Data Repository Toolkit (IDRT), November 2012 2 / 21

1. Autoren

Autor 1: Matthias Löbe

Institut für Medizinische Informatik, Statistik und Epidemiologie (IMISE)

Universität Leipzig

Härtelstraße 16-18

04107 Leipzig

Tel.: +49 341 97 16113

Fax: +49 341 97 16169

E-Mail: [email protected]

sowie

Center for Sepsis Control and Care (CSCC)

Universitätsklinikum Jena

Autor 2: Sebastian Stäubert

Institut für Medizinische Informatik, Statistik und Epidemiologie (IMISE)

Universität Leipzig

Härtelstraße 16-18

04107 Leipzig

Tel.: +49 341 97 16122

Fax: +49 341 97 16130

E-Mail: [email protected]

sowie

IFB AdipositasErkrankungen

Universitätsklinikum Leipzig

Autor 3: Prof. Dr. Alfred Winter

Institut für Medizinische Informatik, Statistik und Epidemiologie (IMISE)

Universität Leipzig

Härtelstraße 16-18

04107 Leipzig

Tel.: +49 341 97 16107

Fax: +49 341 97 16109

E-Mail: [email protected]

Deliverable D2.5: Anbindung §21-Datenquellen, Integrated Data Repository Toolkit (IDRT), November 2012 3 / 21

2. Inhaltsverzeichnis

1. Autoren .................................................................................................................. 2

2. Inhaltsverzeichnis .................................................................................................... 3

3. Zusammenfassung ................................................................................................... 4

4. Einleitung ................................................................................................................ 5

5. Methode ................................................................................................................. 7

5.1. Konventionen .................................................................................................... 7

5.1.1. Globale Variablen ........................................................................................ 7

5.1.2. Benennung der Navigationspfade ................................................................. 8

5.1.3. Benennung der Konzepte ............................................................................ 9

5.1.4. Benennung der Codes ................................................................................. 9

5.1.5. Wahl der Hierarchieebene ........................................................................... 9

5.2. Prozess des Imports ........................................................................................ 10

5.2.1. Vorbereitung der Datenbank ...................................................................... 10

5.2.2. Transformation aus ClaML-Format in XML ................................................... 10

5.2.3. Import aus XML-Format ............................................................................ 11

5.2.4. Import aus CSV-Format ............................................................................. 12

5.2.5. Einspielen der Datensätze in die Datenbank ................................................ 13

5.3. Import über das Standalone-Importwerkzeug .................................................... 14

6. Ergebnisse, Diskussion und Ausblick ........................................................................ 16

7. Literatur ................................................................................................................ 18

8. Abbildungen & Tabellen.......................................................................................... 19

9. Glossar/Abkürzungsverzeichnis ............................................................................... 20

10. Anhänge ............................................................................................................ 21

Deliverable D2.5: Anbindung §21-Datenquellen, Integrated Data Repository Toolkit (IDRT), November 2012 4 / 21

3. Zusammenfassung

Ziel von Arbeitspaket 4.1 ist die Entwicklung eines Verfahrens zur Bereitstellung von häufig

verwendeten Terminologien, darunter ICD-10, OPS, §21-Codelisten, TNM, ICD-O, LOINC und

MedDRA, für den automatisierten Aufbau von Data-Warehouse-Ontologien. Die Auswahl der

bereitzustellenden Terminologien erfolgte im Rahmen der Anforderungsanalyse im

Arbeitspaket 1.1 unter Beachtung der Wünsche und Prioritäten der Anwendercommunity.

Zur Umsetzung des Zieles wurde aufbauend auf den Ergebnissen des Arbeitspakets 2.2 "ETL-

Plattform" das Datenintegrationswerkzeug Talend Open Studio verwendet. Es wurde ein

"Job" (Transformationsprozess) entwickelt, welcher – soweit möglich – aus den originären

(normativen) Quellformaten der einzelnen Standardterminologien Ontologien im i2b2-Format

erzeugt.

Dieses Dokument beschreibt die Vorgehensweise und Konfigurationsoptionen des Jobs zum

Import der Standardterminologien. Damit lassen sich Designentscheidungen innerhalb der

verwendeten Methodik nachvollziehen und darauf aufbauend Sub-Jobs für andere

Terminologien ergänzen oder notwendige Modifikationen der vorhandenen neue Formate

vornehmen. Ferner wird im Folgenden auf die Möglichkeit des vereinfachten Imports der in

diesem Arbeitspaket erstellten i2b2-Ontologien mit Hilfe des Standalone-Importer-Werkzeugs

hingewiesen.

Eine tiefere Erläuterung der prinzipiellen Möglichkeiten und Konstrukte zum Aufbau von i2b2-

Ontologien erfolgt im Arbeitspaket 5.1 "Dokumentation Best Practices – Ontologie-Aufbau".

Deliverable D2.5: Anbindung §21-Datenquellen, Integrated Data Repository Toolkit (IDRT), November 2012 5 / 21

4. Einleitung

Datenelemente sind sowohl in Informationssystemen der klinischen Forschung wie auch der

Versorgung häufig mit Konzepten standardisierter medizinischer Terminologien annotiert.

Diese Terminologien müssen, wenn sie als Parameter für Analysen in einem Data Warehouse

verwendet werden sollen, in der Data-Warehouse-Ontologie verfügbar sein. Ein Beispiel

hierfür ist die Verwendung (von Teilen) der ICD-10- bzw. der OPS-Klassifikation zur Bildung

von Diagnosebezogenen Fallgruppen (DRG) zum Zwecke der Abrechnung zwischen

Leistungsträger und Kostenträger im deutschen Gesundheitswesen.

Ein weiteres Problem bei der Integration von Daten aus verschiedenen Quellsystemen ist die

Frage, ob bestimmte Datenelemente im Hinblick auf Bedeutung und Ausprägung gleich sind,

ob also identische und damit aufeinander abbildbare Variablen erhoben wurden. Diese Frage

lässt sich retrospektiv meist nicht zufriedenstellend beantworten. Daher ist es vorteilhaft,

wenn vorhandene Standardterminologien im Sinne von Referenzterminologien a priori die

semantische Ebene der Integration unterstützen.

Das Arbeitspaket verfolgt im Wesentlichen zwei Ziele:

1. Die Anwender sollen bei der Definition von Navigationshierarchien für die

Quelldaten unterstützt werden. Dies betrifft im Besonderen das Problem, dass viele

Terminologien teilweise oder ausschließlich in elektronischen Formaten vorliegen, die

nicht für eine maschinelle Weiterverarbeitung geeignet sind und somit vor Übergabe

an den Transformationsjob manuell bearbeitet werden müssen.

2. Die Bereitstellung standardisierter Terminologien soll den Aufwand für die

Erstellung von Dimensionshierarchien in lokalen Installationen verringern. Einerseits

profitieren Anwender von bereits fertig verfügbaren Terminologien und von einer

aufgrund der durchgeführten Tests postulierten geringeren Wahrscheinlichkeit

enthaltener Fehler, andererseits können die hier erarbeitenden Lösungen leicht an

eigene Erfordernisse adaptiert werden.

Medizinische Terminologien sind in ihrer Struktur und in ihrer intendierten Anwendungsweise

häufig sehr komplex und zueinander wenig homogen. Für die Nutzung in einem Data

Warehouse wie i2b2 können jedoch eine Reihe von Vereinfachungen angenommen werden,

da es nicht um ein Werkzeug zur Unterstützung der Kodierung von medizinischen Daten

handelt (welches alle Sprachkonstrukte und gegebenenfalls Koordination, Sonderfälle,

Konsistenzprüfungen usw. unterstützen muss), sondern um ein Werkzeug zur

Unterstützung des Information Retrieval, d.h. der Informationsgewinnung und -

Deliverable D2.5: Anbindung §21-Datenquellen, Integrated Data Repository Toolkit (IDRT), November 2012 6 / 21

veredelung. Hier liegen Daten bereits kodiert vor. Die Datenqualität muss bereits in früheren

Schritten der Verwertungskette adressiert worden sein. Idealerweise geschieht dies bei der

Erfassung der Daten oder in speziellen Verfahren der Datenqualitätskontrolle. Insofern kann

i2b2 natürlich genutzt werden, um manuell widersprüchliche Fakten durch geeignete

Abfragen aufzufinden, stellt aber selbst keine automatisierbaren Verfahren dazu zur

Verfügung.

Des Weiteren ist i2b2 kein Terminologieserver, welcher kontrollierte Vokabulare oder

Klassifikationen dem Anwender zum Zweck der Verbesserung der semantischen

Interoperabilität bereitstellt. Der Anwender muss sich eigenverantwortlich mit der Ontologie

seines Data Warehouses vertraut machen. Die Verwendung von Standardterminologien

gegenüber selbst entworfenen Navigationsstrukturen ist nur insofern vorteilhaft, als dass

erstere für externe Personen einfacher verständlich sind, sich besser mit weiteren

Datensätzen zusammenführen lassen und in den meisten Fällen von Fachexperten entworfen

und in langen Zeiträumen der Benutzung vervollkommnet wurden. Standardterminologien

lassen sich in i2b2 jedoch nur sinnvoll verwenden, wenn die Quelldaten bereits damit kodiert

wurden. Dann stellt der in diesem Arbeitspaket entworfene Prozess eine Erleichterung dar,

weil die Navigationsstruktur nicht manuell aufgebaut werden muss, sondern mit Hilfe des

Importtools automatisch aus den hinterlegten Terminologiequelldateien erzeugt werden

kann.

Deliverable D2.5: Anbindung §21-Datenquellen, Integrated Data Repository Toolkit (IDRT), November 2012 7 / 21

5. Methode

Im Rahmen dieses Arbeitspakets soll sowohl die Benutzung verbreiteter Terminologien als

auch von der Community aufgebauter Datensätze und Datensatzbeschreibungen beschrieben

werden. Aufgrund der großen Zahl medizinischer Ordnungssysteme, die dem weiten und

wenig präzisen Begriff der "Standardterminologie" genügen mögen (auf allein 76 Quellen

verweist der NCI Metathesaurus1), musste eine Vorselektion getroffen werden. Dies geschah

im Rahmen der Nutzer- bzw. Expertenbefragung innerhalb der Anforderungsanalyse. Die hier

gesammelten Terminologie-Nennungen wurden von der Projektgruppe dahingehend

priorisiert, ob bzw. mit welcher Wahrscheinlichkeit tatsächlich auch kodierte klinische Daten

zur Verfügung stehen würden und wie komplex die Umsetzung werden würde. Im Ergebnis

wurde beschlossen, mindestens folgende Terminologien anzubieten:

ICD-10 zur Kodierung von Krankheitsdiagnosen und OPS zur Kodierung von

Operationen als die in Deutschland am häufigsten verwendeten Systeme in der

Krankenversorgung

DRG-Schlüssel und §21-Codelisten als Systeme zur Leistungsabrechnung, die in

jedem Krankenhaus zur Verfügung stehen

LOINC für die Kodierung von Laborwerten und Dokumenten

TNM und ICD-O für onkologische Datensammlungen

MedDRA zur Kodierung von unerwünschten Ereignissen bzw. Nebenwirkungen

besonders in klinischen Studien mit Menschen

5.1. Konventionen

Bei der Verwendung einer komplexen Datentransformationssoftware wie Talend Open Studio

bzw. dem Data Warehouse i2b2 unterstützen Konventionen die Wartbarkeit und die

Verständlichkeit des entwickelten Codes. Aus diesem Grund wurde in dem vorliegenden Job

verschiedene Konventionen zur Benennung und Konfiguration von Komponenten entworfen.

5.1.1. Globale Variablen

Talend Open Studio unterstützt Methoden zur projektweiten Konfiguration von Parametern

(globale Variablen) über sogenannte Kontexte. Es wurde versucht, besonders solche

Konfigurationsoptionen auszulagern, deren Änderung durch den Anwender wahrscheinlich

ist.

1 http://ncim.nci.nih.gov/ncimbrowser/

Deliverable D2.5: Anbindung §21-Datenquellen, Integrated Data Repository Toolkit (IDRT), November 2012 8 / 21

Es existieren aktuell zwei Kontexte:

1. Der erste Kontext enthält projektspezifische Einstellungen, die sicherheitskritisch sind

(z.B. Datenbankpasswörter). Er heißt DB_{uid}1.0. es ist darauf zu achten, diesen

Kontext bei Weitergabe des Jobs nicht mit zu exportieren oder Passwörter zu löschen.

Die voreingestellten Parameter des Datenbankkontexts werden beim Start des Jobs in

einem Dialogfenster angezeigt und können an dieser Stelle auch geändert werden.

2. Der zweite Kontext enthält projektspezifische Einstellungen, die nicht

sicherheitskritisch sind. Diese beinhalten Dateipfade zu den einzelnen Terminologien.

Wird in einem Kontext eine Variable aktualisiert oder eine neue Variable angelegt, muss der

Jobkontext aktualisiert werden, indem man den Kontext aus dem Repository (linke Seite der

Talend-Bedienoberfläche) auf den Kontext des Jobs „fallen lässt“.

Die Auslagerung von Parametern in Kontexte ermöglicht es ferner, für unterschiedliche

Systemumgebungen (Windows, Linux) jeweils eigene Kontexte zu erstellen und schnell

zwischen diesen zu wechseln.

5.1.2. Benennung der Navigationspfade

Die i2b2-Ontologie kennt zwei wesentliche Typen von Objekten zum Aufbau einer

Navigationshierarchie: Blätter, die medizinische Konzepte repräsentieren und Ordner bzw.

Container, die zur Strukturierung dienen und konzeptionell Ordnern in einem Dateisystem

entsprechen. Die datenbankseitige Repräsentation erfolgt denormalisiert, jede Zeile der

Ontologietabelle entspricht einem Ordner oder einem Blatt, wobei die Position innerhalb der

Hierarchie nicht durch Verweise auf Eltern- oder Kindelemente realisiert ist wie bei einer

verkettete Liste, sondern durch die vollständige Angabe des Pfades für jedes Element.

Während dieses Verfahren deutliche Nachteile bezüglich des Speicherplatzverbrauchs hat,

können Teilbäume sehr einfach mittels SQL-Selects ausgelesen werden, die das Ergebnis

durch Angabe des führenden Teil des Pfads einschränken.

Die verwendeten Pfade sind derzeit fest in den Job einkodiert:

\i2b2\ST\DRG\ für G-DRG

\i2b2\ST\P21\ für P21

\i2b2\ST\ICD-10-GM\ für ICD-10-GM

\i2b2\ST\OPS\ für OPS

\i2b2\ST\LOINC\ für LOINC

\i2b2\ST\ICD-O\ für ICD-O-3

\i2b2\ST\TNM\ für die TNM-Klassifikation

Deliverable D2.5: Anbindung §21-Datenquellen, Integrated Data Repository Toolkit (IDRT), November 2012 9 / 21

\i2b2\ST\MedDRA\ für MedDRA

5.1.3. Benennung der Konzepte

Die Konzepte enthalten soweit vorhanden die Labels der Originaldaten. Häufig wird jedoch

ein Präfix vorangestellt, einerseits, um Forscher zu unterstützen, die kodierungsorientiert

arbeiten und die Bezeichnung u.U. nicht kennen. Ein anderer Punkt ist, dass der i2b2-Client

immer alphabetisch sortiert, was die originale Sortierung zerreißt. Hier ist es leichter, sich an

Code-Präfixen zu orientieren.

5.1.4. Benennung der Codes

ST|<OFFIZIELLES TERMINOLOGIE-KÜRZEL>:<CODE AUS TERMINOLOGIE>

Beispiele:

ICD: ST|ICD-10-GM:J52.1

OPS: ST|OPS:8-801.a

DRG: ST|DRG-2012:A52Z

Geschlecht: ST|P21|GSCHL:M

Aufnahmeanlass: ST|P21|AUFNAN:A

Aufnahmegrund: ST|P21|AUFNGR:0107

Entlassungsgrund: ST|P21|ENTLGR:07

Fachabteilung: ST|P21|FACHABT:2900

5.1.5. Wahl der Hierarchieebene

Derzeit ist die gesamte Hierarchie fest vorgegeben. Sie beginnt auf Ebene 1 mit einem Punkt

„Standardterminologien“. Darunter (Ebene 2) werden alle Terminologien alphabetisch

aufgelistet.

Abbildung 1: Darstellung der Standardterminologien im i2b2-Webclient

Deliverable D2.5: Anbindung §21-Datenquellen, Integrated Data Repository Toolkit (IDRT), November 2012 10 / 21

5.2. Prozess des Imports

Aktuell besteht der Prozess zum Import der Standardterminologien nur aus einem einzigen

Talend-Job. Daraus folgt, dass immer alle Terminologien importiert werden. Falls dies nicht

gewünscht ist, müssen Teilkomponenten temporär deaktiviert werden. Alle Ergebnisse

werden mit Hilfe von Talendkomponenten vom Typ tUnite „zusammengefügt“.

Abbildung 2: "Vereinigen" der Importe

5.2.1. Vorbereitung der Datenbank

Im ersten Schritt wird eine Verbindung zur Datenbank hergestellt. Danach wird die

Datenbank (genauer die Tabellen I2B2 und CONCEPT_DIMENSION) geleert, wobei nur ein

Wurzelobjekt für die Ontologie in der Tabelle I2B2 verbleibt.

Abbildung 3: Öffnen und Leeren der Datenbank

5.2.2. Transformation aus ClaML-Format in XML

Folgende Terminologien liegen normativ im ClaML-Format vor und können vom DIMDI

heruntergeladen werden:

ICD-10 German Modification

OPS

ICD-O-3

Deliverable D2.5: Anbindung §21-Datenquellen, Integrated Data Repository Toolkit (IDRT), November 2012 11 / 21

ClaML steht für „Classification Markup Language“ und ist in der ISO-Norm 131202 definiert.

Es handelt sich um einen XML-Standard zu Pflege und Austausch medizinischer

Klassifikationen. ClaML ist mittlerweile das bevorzugte Format der

Weltgesundheitsorganisation (WHO).

Da sich ClaML nicht ohne Zwischenschritte in das i2b2-Tabellenformat überführen lässt, wird

zuerst aus der ClaML-XML-Datei eine einfachere XML-Version erzeugt. Dies geschieht mit

Hilfe eine Stylesheets und einer XSL-Transformation. Im Ergebnis entsteht ein XML der

Form:

<tnm> <class> <level>3</level> <path>\i2b2\ST\TNM\Metastasis</path> <label>Fernmetastasen\</label> <code>M</code> </class> … </tnm>

Es beinhaltet nur jene Parameter, die für den Aufbau der i2b2-Ontologie verwendet werden.

Das XSLT-Skript kann generisch auf beliebige ClaML-Daten angewendet werden, allein der

Präfix (im obigen Beispiel TNM) muss projektspezifisch angepasst werden.

Abbildung 4: XSLT-Komponente zum Transformation von ClaML in ein einfaches XML-Format

5.2.3. Import aus XML-Format

Aus dem einfachen XML-Format lässt sich das I2B2-Datenbanktabellenschema erzeugen.

Dies gilt für die Terminologien:

ICD-10

OPS

ICD-O

TNM (hier wurde das einfache XML-Format manuell erstellt)

2 ISO 13120 Health informatics -- Syntax to represent the content of healthcare classification systems -- Classification Markup Language (ClaML) [http://www.iso.org/iso/home/store/catalogue_tc/

catalogue_detail.htm?csnumber=52952]

Deliverable D2.5: Anbindung §21-Datenquellen, Integrated Data Repository Toolkit (IDRT), November 2012 12 / 21

Dabei wird das einfache XML-Format mithilfe einer tMAP-Komponente von Talend so

transformiert, dass jedes Konzept aus einer einzelne Zeile besteht, deren Spalten mit denen

der I2B2-Tabelle übereinstimmen.

Zu beachten ist ferner die Erstellung des Wurzelkonzepts einer Terminologie über eine

manuell geschriebene CSV-Datei.

Abbildung 5: Transformation aus dem einfachen XML-Format in das i2b2-Format

5.2.4. Import aus CSV-Format

Einige Terminologien liegen nicht im ClaML-Format vor und wurden entweder aus Erlangen

bezogen oder aus den gesetzlichen Standardwerken manuell erstellt.

Dies gilt für die Terminologien:

§21 (Geschlecht, Aufnahmeanlass, Entlassungsgrund, Fachabteilung,

Aufnahmegrund)

DRG

LOINC

MedDRA

Auch wenn sich die CSV-Dateien im Hinblick auf Größe, Aufbau, Feldtrenner oder

Zeilenabschlusszeichen unterscheiden, handelt es sich doch strukturell um tabellarische

Daten.

Auch hier wird das Wurzelkonzept der Terminologie über eine manuell geschriebene CSV-

Datei angelegt.

Deliverable D2.5: Anbindung §21-Datenquellen, Integrated Data Repository Toolkit (IDRT), November 2012 13 / 21

Abbildung 6: Transformation aus CSV in das i2b2-Format

5.2.5. Einspielen der Datensätze in die Datenbank

Im letzten Schritt werden die erzeugten Statements der Datenbank übergeben, genauer der

Tabelle „I2B2“. Die Änderungen werden mit COMMIT festgeschrieben. Danach wird die

Tabelle CONCEPT_DIMENSION aus der Tabelle I2B2 erzeugt und ebenfalls commited. Zum

Schluss wird die Datenbankverbindung getrennt.

Deliverable D2.5: Anbindung §21-Datenquellen, Integrated Data Repository Toolkit (IDRT), November 2012 14 / 21

Abbildung 7: Festschreiben der Änderungen in Oracle

5.3. Import über das Standalone-Importwerkzeug

Der bislang beschriebene Weg des Imports mithilfe des Talendjobs ermöglicht ausschließlich

den Import der Standardterminologien selbst. Der Import der klinischen Fakten kann durch

andere Jobs bearbeitet werden. Für eine konkrete Nutzung müssen jedoch die Fakten mit

den Codes der Standardterminologien verbunden sein. Ansonsten kann das Vorhandensein

vieler Terminologie gar als nachteilig angesehen werden, denn der Anwender wird durch die

scheinbare Reichhaltigkeit des Ontologiebaumes insofern getäuscht, als das Abfragen keine

Patienten in der Ergebnismenge enthalten und somit unklar ist, welche Ontologie-Teilbäume

mit Fakten hinterlegt sind und welche nicht.

Deliverable D2.5: Anbindung §21-Datenquellen, Integrated Data Repository Toolkit (IDRT), November 2012 15 / 21

Aus diesem Grund wurde eine zusätzliche Importmöglichkeit geschaffen und der

Terminologie-Job als Option in das IDRT-Importtool (siehe AP2.3 und AP2.5) für Daten des

§21-Datensatzes eingebunden. Ist das Häkchen in Abbildung 8 gesetzt, werden jene

Standardterminologiekonzepte importiert, für die Fakten in der Tabelle OBSERVATION_FACT

existieren. Die Codes der Fakten werden auf die Codes der Standardterminologien gemappt.

Standardterminologien ohne Entsprechung in den klinischen Fakten werden überhaupt nicht

importiert.

Abbildung 8: Aktivieren der Jobs zum Import von Standardterminologien

Deliverable D2.5: Anbindung §21-Datenquellen, Integrated Data Repository Toolkit (IDRT), November 2012 16 / 21

6. Ergebnisse, Diskussion und Ausblick

Alle Terminologien, die im Rahmen der Anforderungsanalyse erfasst und in der

Projektgruppe priorisiert wurden, konnten erfolgreich mit Hilfe des erstellten Talend-Jobs

(siehe 10. Anhänge) importiert werden. Insgesamt sind bei einem vollständigen Import der

Standardterminologien über 125.000 Konzepte in der Ontologie vorhanden. Der Talend-Job

importiert die Terminologien sequentiell, sodass eigene Adaptionen (Hinzufügen weiterer

Vokabulare, Ausblenden vorhandener Vokabulare, Modifikationen) leicht möglich sind. Ferner

kann der gewählte Ansatz auch Basis für eigene Importjobs sein.

Ein Grund für den Erfolg besteht unzweifelhaft in dem relativ einfachen Format für i2b2-

Ontologien. Im Wesentlichen wird für ein Konzept nur ein textueller Bezeichner zur Anzeige

im Clientprogramm sowie ein interner Code zur Referenz auf das Konzept benötigt, ferner

eine einfache Hierarchierelation für generischere bzw. spezifischere Konzepte

Probleme beim Import von Standardterminologien resultieren aus verschiedenen

Besonderheiten:

Terminologien sind nicht in jeden Fall frei verfügbar: So ist MedDRA bspw. geschützt

und kann deshalb auch nicht in modifizierter Form weitergegeben werden.

Terminologien sind nicht elektronisch verfügbar oder das Format ist nicht maschinell

verarbeitbar: Einige Ordnungssysteme liegen nicht normativ in elektronischen

Formaten vor (TNM) und wurden daher manuell erstellt. Häufiger sind aber Office-

Formate mit Überschriften, Bemerkungen und Farbkodierungen, welche eine

vollautomatische Weiterverarbeitung stark einschränken. Dies ist z.B. bei der §21-

Codelisten (PDF) oder bei den DRGs (XLS) der Fall. Beide müssen stark manuell

vorverarbeitet werden.

Terminologien liegen in vielen Datenformaten vor: Selbst wenn die Daten intern gut

strukturiert sind, erschwert die Vielzahl an Datenformaten (CSV, XLS, MDB, XML,

OWL, SQL) den Import, da für jedes Quellformat eigene Importer geschrieben

werden müssen.

Als am besten geeignet für den Import erwies sich das ClaML-Format.

Die gewählte Methode über die Datenintegrationsplattform Talend Open Studio konnte die in

sie gesetzten Erwartungen erfüllen. Talend-Jobs sind immer noch recht kompliziert und für

Außenstehende schwer verständlich, lassen sich aber deutlich besser warten und sind

fehlerfreier als selbst programmierte Importroutinen. Die grafische Modellierung und Live-

Aktualisierung während des Ausführens erleichtert das Verständnis etwas. Des Weiteren ist

Deliverable D2.5: Anbindung §21-Datenquellen, Integrated Data Repository Toolkit (IDRT), November 2012 17 / 21

der Import über Talend Open Studio relativ performant, der Import der

Standardterminologien benötigt auf einem aktuellen Standard-PC unter einer Minute und

selbst im Falle einer Verteilung auf Client-PC mit Talend, Server mit i2b2 und eigenem

Oracle-Datenbankserver im IMISE-Netz auf leistungsärmerer Hardware nur ca. 3 - 5 Minuten.

Im Laufe des Arbeitspakets wurde eine Reihe von Herausforderungen identifiziert, die in

zukünftigen Versionen des Jobs Beachtung finden sollen. Dies betrifft zum einen das mit i2b2

1.6 neu hinzugekommene Konstrukt der Modifier (Näheres im Deliverable 5.1 Best Practices

zum Ontologieaufbau), welche es ermöglichen werden, zusätzliche Aussagen zu einem

Konzept zu tätigen. Damit kann beispielsweise zwischen Haupt- und Nebendiagnosen

unterschieden werden, ohne dass diese in zwei separaten (redundanten) Bäumen gehalten

werden.

Zum anderen stellen die häufigen Aktualisierungen von Terminologien eine Herausforderung

dar, weniger wegen dem Aufwand des Importierens an sich, sondern wegen den

Änderungen an den im Vokabular enthaltenen Konzepten (neue kommen hinzu, alte werden

ungültig, die Bedeutung von Konzepten wird intensional geändert, in Einzelfällen wie beim G-

DRG bekommen Konzepte z.B. durch Wegfall eines Schweregrads Codes, die in der letzten

Version noch für ein anderes Konzept standen).

Für das im Anschluss an das aktuelle Projekt geplante Folgeprojekt wird der konzipierte

Ontologie-Editor einige Möglichkeiten zum Mapping zwischen Ontologiebäumen bieten.

Ferner soll eine Anbindung an das Nationale Metadata Repository erfolgen, um i2b2-

Ontologien aus dort gespeicherten Forschungsvorhaben zu erzeugen. Prinzipiell handelt es

sich aber um eine generelle, nicht-triviale Problematik medizinischer Ordnungssystemen,

deren Lösung nicht Ziel dieses Arbeitspakets ist.

Im Laufe des Arbeitspakets wurde des Weiteren ein Bedarf für zusätzliche Terminlogien

offenbar, darunter Standardized MedDRA Queries zur einfacheren Abfrage von Klassen von

unerwünschten Ereignissen, CDISC SDTM für annotierte Daten klinischer Studien, speziell

Arzneimittelstudien zur Einreichung an die FDA, SNOMED-CT als derzeit wohl populärstes

und reichhaltigstes Terminologiesystem, der NCI Thesaurus, welcher in einigen europäischen

Partnerländern zum Einsatz kommt, ATC zur Kodierung von Arzneistoffen (wie im

Arbeitspaket 5.2 Use Case Data Warehouse beschrieben) und MeSH. Es wäre

wünschenswert, wenn eine Auswahl hiervon in eine aktualisierte Version des Talend-Jobs

aufgenommen werden könnte.

Deliverable D2.5: Anbindung §21-Datenquellen, Integrated Data Repository Toolkit (IDRT), November 2012 18 / 21

7. Literatur

[1] ICD-10-GM http://www.dimdi.de/static/de/klassi/icd-10-gm/index.htm

[2] OPS http://www.dimdi.de/static/de/klassi/ops/index.htm

[3] §21 http://www.g-drg.de/cms/Datenlieferung_gem._21_KHEntgG/Dokumente_zur_

Datenlieferung/Datensatzbeschreibung

[4] G-DRG http://www.g-drg.de/cms/G-DRG-System_2013/Fallpauschalen-Katalog/

Fallpauschalen-Katalog_2013

[5] LOINC http://loinc.org/downloads

[6] TNM Ch. Wittekind, H.-J. Meyer: TNM Klassifikation maligner Tumoren. 7. Auflage.

Wiley-VCH, Weinheim 2010, ISBN 978-3-527-32759-1.

[7] ICD-O http://www.dimdi.de/dynamic/de/klassi/downloadcenter/icd-o-3/

[8] Talend Nutzerhandbuch und Talend Referenz http://de.talend.com/download/data-

integration?qt-product_download_tabs=2#qt-product_download_tabs

Deliverable D2.5: Anbindung §21-Datenquellen, Integrated Data Repository Toolkit (IDRT), November 2012 19 / 21

8. Abbildungen & Tabellen

Abbildung 1: Darstellung der Standardterminologien im i2b2-Webclient .............................. 9

Abbildung 2: "Vereinigen" der Importe ........................................................................... 10

Abbildung 3: Öffnen und Leeren der Datenbank .............................................................. 10

Abbildung 4: XSLT-Komponente zum Transformation von ClaML in ein einfaches XML-Format

.................................................................................................................................. 11

Abbildung 5: Transformation aus dem einfachen XML-Format in das i2b2-Format .............. 12

Abbildung 6: Transformation aus CSV in das i2b2-Format ................................................ 13

Abbildung 7: Festschreiben der Änderungen in Oracle ..................................................... 14

Abbildung 8: Aktivieren der Jobs zum Import von Standardterminologien .......................... 15

Deliverable D2.5: Anbindung §21-Datenquellen, Integrated Data Repository Toolkit (IDRT), November 2012 20 / 21

9. Glossar/Abkürzungsverzeichnis

BMBF Bundesministerium für Bildung und Forschung (www.bmbf.de)

DIMDI Deutsches Institut für Medizinische Dokumentation und Information (www.dimdi.de)

ICD-10 International Statistical Classification of Diseases and Related Health Problems, 10. Revision

LOINC Logical Observation Identifiers Names and Codes (www.loinc.org)

OPS Operationen- und Prozedurenschlüssel; vom DIMDI herausgegebener Katalog zur Verschlüsselung medizinischer Prozeduren im Krankenhaus und ambulanter Operationen

TMF TMF – Technologie- und Methodenplattform für die vernetzte medizinische Forschung e.V. (www.tmf-ev.de)

TNM Klassifikationssystem der UICC für maligne Tumoren mit den Kategorien (T)umor, (N)odes (Lymphknotenbeteiligung) und (M)etastasen

UICC International Union against Cancer (www.uicc.org)

ZKS Zentrum für Klinische Studien

Deliverable D2.5: Anbindung §21-Datenquellen, Integrated Data Repository Toolkit (IDRT), November 2012 21 / 21

10. Anhänge

1. Talendjob (Export als Item) in der Version vom 04.04.2013.