Data Warehouse, klinisches

Das Ziel eines klinischen Data Warehouse ist, die für die Behandlung von Patienten routinemäßig erhobenen Daten zusätzlich für die Forschung und in speziellen Fällen auch für die Behandlung nutzbar zu machen [1]. Die wesentlichen Schritte umfassen die Anonymisierung beziehungsweise Pseudonymisierung der Behandlungsdaten aus dem Krankenhausinformationssystem, Extraktion, Transformation und Hochladen (ETL) dieser Daten in das Data Warehouse, deren Normalisierung durch Abbildung auf eine klinische Ontologie, die Definition einer Abfragesprache sowie einer geeigneten Daten- und Indexstruktur zur Effizienzsteigerung, die Validierung der Dateninhalte sowie die Bereitstellung von Diensten für verschiedene Anfragetypen. Die wesentliche Herausforderung ist die Integration unterschiedlicher Datentypen auf mehreren Ebenen: Innerhalb eines Krankenhauses werden zum Patienten strukturierte Daten wie ICD-kodierte Diagnosen und Labordaten, semistrukturierte Daten für viele Untersuchungen wie beispielsweise Herzecho oder EKG und unstrukturierte Daten wie Arztbriefe und textuelle Befundberichte erhoben. Wenn Patienten mehrfach behandelt werden, müssen die meist fallbezogen gespeicherten Daten zeitlich integriert werden. Weitere Daten zu einem Patienten können in Biobanken oder in Genomics-, Proteomics- oder Metabolomics- (kurz "omics-") [Krankheiten können als Wechselspiel zwischen äußeren Einflüssen und erblich bedingten Dispositionen verstanden werden, die von der individuellen Genkonstellation (genomics) über die durch sie kodierten Proteine (proteomics) bis zu den Stoffwechselprozessen in der Zelle (metabolomics) reichen.  Allerdings steht die Forschung noch am Anfang, dieses komplizierte Wechselspiel zu verstehen, was durch ein übergreifendes Data Warehouse unterstützt wird.] Datenbanken verfügbar sein, die eine eigene Pseudonymisierung haben. Ein krankenhausübergreifendes Data Warehouse muss zwei zusätzliche Herausforderungen bewältigen: Die Abbildung eventuell unterschiedlicher klinikinterner Ontologien aufeinander und die Identifikation gleicher Patienten, die an verschiedenen Krankenhäusern behandelt wurden.

Die wichtigsten Dienste, die ein klinisches Data Warehouse bereitstellen kann, umfassen:

• Finden von Patienten für klinische Studien mit Ein- und Ausschlusskriterien. Dies geschieht oft in zwei Stufen: Zunächst retrospektiv durch eine Einschätzung, ob überhaupt genügend Patienten für eine Studie vorhanden sind, und dann prospektiv durch Finden möglichst aller Patienten, die an der Studie teilnehmen sollen
• Finden von Daten für Patienten aus klinischen Studien. Bei klinischen Studien werden viele Daten erhoben, wovon ein Teil der Untersuchungen eventuell schon bei der Behandlung gemacht worden ist. Um doppelte Datenerhebungen zu vermeiden, sollten die vorhandenen Daten erkannt und in die Datenbank der Studie transferiert werden, gegebenenfalls mit einem Zuverlässigkeitsgrad, weil in Studien oft eine höhere Zuverlässigkeit der Datenvalidität als in der Behandlung gefordert wird.
• Entscheidungsunterstützung in der Patientenbehandlung [5]: Durch die Abbildung von Behandlungsdaten auf eine standardisierte Ontologie können einerseits zu einem Patienten ähnliche Patienten gesucht werden und die Diagnose, Therapie und Prognose verglichen werden, und andererseits können Regeln Empfehlungen geben oder im Sinne einer "Second Opinion" auf eventuelle Fehler hinweisen, was z.B. bei der Verschreibung von Medikamenten erfolgreich eingesetzt wird. Weiterhin kann die Notwendigkeit von Leistungsanforderungen (z.B. für Labordaten und bildgebende Verfahren) überprüft werden. Das Potential zur Entscheidungsunterstützung wird durch die Verfügbarkeit von individuellen omics-Daten von Patienten beträchtlich erweitert.
• Epidemiologische Analysen wie die zeitliche Entwicklung der Häufigkeiten von Diagnosen, Therapien und Gesundheitszustand, ggf. unter Berücksichtigung weiterer Parameter wie z.B. demographischen Daten oder Risikofaktoren.
• Validitätsanalysen klinischer Daten, indem dieselben Beobachtungen aus unterschiedlichen Quelldokumenten derselben Patienten verglichen werden (z.B. Vergleich von ICD-kodierten Diagnosen mit Arztbrief-Diagnosen).

Ein klinisches Data Warehouse (kDW) zur Unterstützung der Forschung ist wie folgt aufgebaut (Abb. 1; nach Geibel et al. 2015): Das kDW basiert auf einem Krankenhausinformationssystem mit einer elektronischen Krankenakte, das gewöhnlich aus verschiedenen Subsystemen besteht. Laut einer Erhebung in Trinczek et al. [6] in 111 betrachteten deutschen Universitätskliniken und Krankenhäusern gibt es wenige verbreitete KIS Systeme (ORBIS, i.s.h.med Soarian, Medico) mit ca. 2/3 Marktanteil und weitere KIS-Systeme mit ca. 1/3 Marktanteil. Je besser die Struktur der elektronischen Krankenakte, desto einfacher ist der folgende ETL-Prozess.  

Ein zentraler Prozess ist die Pseudonymisierung der Patientendaten für das Data Warehouse, weil einerseits für viele Abfragen die Namen der Patienten nicht erforderlich sind, andererseits aber zur Unterstützung klinischer Studien die Patienten identifizierbar sein müssen. Dazu müssen die identifizierenden Merkmale der Patienten erkannt und durch Pseudonyme ersetzt werden, wobei die Zuordnung von Pseudonymen zu Identitäten außerhalb des kDW in einem eigenen Server erfolgen sollte (vgl. Empfehlungen der TMF zum Identitätsmanagement in [4]). Insbesondere in textuellen Dokumenten wie Arztbriefen können Verweise auf Patienten oder deren Angehörige (z.B. bei der Familienanamnese) schwierig zu finden sein.

Die Komplexität des ETL-Prozesses hängt stark von der Strukturiertheit der Daten ab. Wenn die Daten schon kodiert sind (ICD bei Diagnosen und OPS bei Prozeduren) ist er sehr einfach. Für Labordaten gibt es zwar eine Standardisierung (LOINC), allerdings haben viele Laborsysteme in Kliniken ihre eigene Kodierung, die auf den Standard abgebildet werden sollte. Für die meisten Daten gibt es allerdings keine allgemein verwendeten Ontologien in Deutsch. Im Englischen ist die Situation mit dem UMLS (Unified Medical Language System) und SNOMED CT (Systematized Nomenclauture of Medicine - Clinical Terms) besser, wenn auch nicht ideal, aber die verfügbaren Übersetzungen fürs Deutsche sind derzeit nur eingeschränkt praxistauglich [2]. Daher besteht ein großer Teil der Arbeit für ein umfassendes kDW in der Modellierung von Ontologien und der Abbildung verschiedener Ontologien aufeinander.

Textuelle Daten kann man mit Information Retrieval Technologien von Suchmaschinen ad hoc abfragen, allerdings ist dies wegen vieler Synonyme und linguistischer Probleme nur näherungsweise möglich.  Eine höhere Genauigkeit erzielt man durch einen Vorverarbeitungsprozess, dem Information Extraction [Piskorski 2013], bei dem vordefinierte Begriffe und Beziehungen aus einem Text extrahiert werden. Die Methoden reichen von der Anwendung von einfacher Segmentierung mit Satzzeichen und Extraktion mit regulären Ausdrücken bis zu komplexen syntaktischen und semantischen Parsing-Techniken.

Das Ergebnis des ETL-Prozesses und der Information Extraction ist das Füllen des Data Warehouse mit Daten. Die Datenstruktur hat meist ein einfaches Tupel-Schema der Art ID, Attribut, Wert, Zeit, z. B. Patient-4711, Herzinsuffizienz, vorhanden, 11.03.2016, wobei zu den Tupel-Elementen in einem Stern-Schema weitere Informationen  (z. B. bei Attributen Beschreibung, Synonyme, Wertebereich, Hierarchische Struktur usw.) hinterlegt sind. Das Tupel-Schema kann erweitert werden, z.B. um einen Sicherheitsgrad des Attributwertes. Da medizinische Data Warehouses sehr groß werden können (> 109 Tupel) und häufig kombinierte Anfragen über viele Parameter gestellt werden, sind für die Abfrage effiziente Datenstrukturen  wie z.B. In-Memory-Datenbanken wie HANA  oder Indizes von Suchmaschinen nützlich.

Der Benutzer interagiert mit dem Data Warehouse über eine einfache Abfrageoberfläche. Wesentliche Elemente sind der Katalog mit den strukturierten Daten, die häufig hierarchisch organisiert sind, das Zusammenstellen der Anfrage aus verschiedenen Einzelparametern und die Anzeige in Tabellen- oder graphischer Form. Dabei gibt es zwei Modi: Anzeige aggregierter Informationen über viele Patienten oder Anzeige der Daten einzelner pseudonymer Patienten (z.B. für Studienrekrutierungen). Eine Rückverfolgung der Daten zu den Quellen (z.B. Befundberichten), aus denen sie stammen, ist zur Validitätsprüfung vorteilhaft. Ein Beispiel für  eine Anfrageoberfläche zeigt Abb. 2 von dem open Source System I2B2 [https://www.i2b2.org/ bzw. https://www.i2b2.org/webclient/] (andere Beispiele sind Medical Research Insights von SAP [https://icn.sap.com/projects/sap-medical-research-insights.html] oder Padawan der Universitätsklinik Würzburg [http://go.uniwue.de/ls6-pub-2016-web-padawan] ).

Es gibt viele Herausforderungen für die klinikinterne Etablierung eines klinischen Data Warehouse und deren klinikübergreifender Vernetzung: Dazu zählt die Sicherstellung strenger Richtlinien beim Datenschutz, Standardisierung der Daten, Techniken der Informationsextraktion zur Auswertung textueller Daten, die Integration von klinischen Daten mit Informationen aus Biobanken und individuellen omics Daten, und insbesondere auch die Validierung der Daten, da eine schlechten Datenqualität zu irreführenden Schlussfolgerungen führt. Zwei Ansätze dazu sind, dass Daten bereits beim Hochladen hinsichtlich ihrer Validität bewertet werden und dass die Redundanz klinischer Daten ausgenutzt wird, um systematisch Kreuzvalidierungen zwischen den Daten durchzuführen.

Sollen mehrere Data Warehouses überregional zu einem gemeinsamen Netzwerk integriert werden, bietet sich hierzu die Verwendung eines föderalen Ansatzes an. Auf diese Weise entstehen sogenannte Datenintegrationszentren (DIZ) mit der Problematik, dass lokale Daten einzelner Data Warehouses aufeinander abgebildet werden müssen. Ganz wesentlich ist hierbei die Notwendigkeit, lokale Ontologien aufeinander abzubilden. Die hierzu benötigten Metriken zur Verknüpfung verschiedener Ontologien befinden sich noch im Forschungsstadium. Weiterhin werden Verzeichnisdienste benötigt, die sicherstellen, dass Daten eines Patienten, die über mehrere Krankenhäuser verteilt sind, widerspruchsfrei zusammengeführt werden können, wobei die strengen Datenschutzrichtlinien eingehalten werden müssen.

Weiterhin ist die Protokollierung nicht nur der Datenzugriffe, sondern darüber hinaus auch der Veränderung von Daten eine beträchtliche Herausforderung. Hierzu müssen geeignete Rollenmodelle gefunden und ihre Implementierung sichergestellt werden.

Schließlich müssen geeignete Regelwerke dafür sorgen, dass sich Anreize ergeben, einem DIZ beizutreten. Diese werden erst dann Erfolg zeigen, wenn sich die Bereitschaft, Patientendaten einzubringen, Datenschutz zu gewährleisten und die Vielfalt von zunehmenden Auswertemöglichkeiten großer Patientenkollektive ausbalancieren. Diese Regelwerke entstehen beispielsweise aus vermarktungsfähigen Wertschöpfungsketten, die sich aus den bereits genannten Diensten eines klinischen Data Warehouse ableiten lassen. Hierbei können sich sowohl finanzielle als auch immaterielle Anreize ergeben, beispielsweise durch die sich erst aufgrund der verknüpften Datenbasis eröffneten Möglichkeit, publikationswürdige Studien durchzuführen. Kern jeder dieser spezifischen Regelwerke ist demnach die Nachvollziehbarkeit der Datenquellen, die für die jeweilige Verwertung herangezogen werden. Dadurch werden gegenseitige Vergütungen möglich, die beispielsweise den andernorts etablierten Modellen von "Pay-per-Use" oder Pauschalen entsprechen können.

Wenn diese Herausforderungen gemeistert werden, ist der potentielle Nutzen enorm: da die Medizin auch eine empirische Wissenschaft ist, können aus mehr Daten bessere Schlussfolgerungen gezogen werden. Weiterhin kann das Wissen auch unmittelbar zur Patientenbehandlung eingesetzt werden.

1. Drepper, J., Prokosch, H.U., Dugas, M., Semler, S.: Sekundärnutzung klinischer Daten. TMF - Technologie und Methodenplattform für die vernetzte medizinische Forschung e.V.: IT-Infrastrukturen in der patientenorientierten Forschung, Akademische Verlagsgesellschaft, 119-143, 2014.
2. Geibel, P., Trautwein, M., Erdur, H., Zimmermann, L., Jegzentis, K., Bengner, M., Nolte, C.H., Tolxdorff, T.: Ontology-Based Information Extraction: Identifying Eligible Patients for Clinical Trials in Neurology. Journal on Data Semantics 4 (2), 133-147, 2015.
3. Piskorski, J., Yangarber, R.: Information Extraction, Past, Present, Future. Poibeau et al. (eds.): Multi-source Multilingual Information Extraction and Summarization, Springer, 23-49, 2013.
4. Pommering, K., Ückert, F.: Identitätsmanagement. TMF - Technologie und Methodenplattform für die vernetzte medizinische Forschung e.V.: IT-Infrastrukturen in der patientenorientierten Forschung, Akademische Verlagsgesellschaft, 19-29, 2014.
5. Puppe, F.: Medizinische Entscheidungsunterstützungssysteme. Informatik Spektrum 37 (3), Aktuelles Schlagwort, 246-249, 2014.
6. Trinczek, B., Köpcke, F., Leusch, T., Majeed, R.W., Schreiweis, B., Wenk, J., Bergh, B., Ohmann, C., Röhrig, R., Prokosch, H.U., Dugas, M.: Design and Multicentric Implementation of a Generic Software Architecture for Patient Recruitment Systems Re-using Existing HIS tools and Routine Patient Data. Applied Clinical Informatics 5 (1), 264-283, 2014.

Thomas Tolxdorff
Institut für Medizinische Informatik,
Charité – Universitätsmedizin Berlin, Berlin
E-Mail 

Frank Puppe
Lehrstuhl für Künstliche Intelligenz und
Angewandte Informatik, Universität Würzburg, Würzburg
E-Mail

© Springer-Verlag Berlin Heidelberg 2016