gms | German Medical Science

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

Deutsche Gesellschaft für Medizinische Informatik, Biometrie und Epidemiologie

15. bis 18.09.2008, Stuttgart

Integration dezentral erhobener klinischer Daten in ein Data-Warehouse – serviceorientierter Entwurf und Realisierung in OpEN.SC

Meeting Abstract

  • Sabine Hanß - Institut für medizinische Informatik, Charité, Berlin, Deutschland
  • Thorsten Schaaf - Institut für medizinische Informatik, Charité, Berlin, Deutschland
  • Thomas Wetzel - Insitut für Pathologie, Charité, Berlin, Deutschland
  • Claudia Hahn - Insitut für Pathologie, Charité, Berlin, Deutschland
  • Thomas Schrader - Insitut für Pathologie, Charité, Berlin, Deutschland
  • Thomas Tolxdorff - Institut für medizinische Informatik, Charité, Berlin, Deutschland

Deutsche Gesellschaft für Medizinische Informatik, Biometrie und Epidemiologie. 53. Jahrestagung der Deutschen Gesellschaft für Medizinische Informatik, Biometrie und Epidemiologie (gmds). Stuttgart, 15.-19.09.2008. Düsseldorf: German Medical Science GMS Publishing House; 2008. DocMI17-3

Die elektronische Version dieses Artikels ist vollständig und ist verfügbar unter: http://www.egms.de/de/meetings/gmds2008/08gmds191.shtml

Veröffentlicht: 10. September 2008

© 2008 Hanß 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&aauml;ltigt, verbreitet und &oauml;ffentlich zug&aauml;nglich gemacht werden, vorausgesetzt dass Autor und Quelle genannt werden.


Gliederung

Text

Einleitung und Fragestellung

Stellvertretend für eine Reihe ähnlicher Vorhaben, dezentral erhobene klinische Daten zentral für Analyse und Auswertezwecke bereit zu halten, verarbeitet das Projekt Open European Nephrology Science Center (OpEN.SC) diese nach dem Data-Warehouse-Prinzip [2]. Zu gewährleisten ist üblicherweise, dass spezifizierte Suchmethoden Zugriff auf die Datenbasis erhalten [4] sowie durch geeignete Maßnahmen die Regeln der Qualitätssicherung erfüllt werden [6]. Es stellt sich die Frage nach einem generalisierten Entwurf für einen Integrationsprozesses, der die schützenswerte Belange der Urheber berücksichtigt, in dem diesen eine durchsetzungsfähige Kontrollfunktion eingeräumt wird, die für die Rechteinhaber nachvollziehbar ist. Darüber hinaus hat eine Anwendung dieses Prozesses die geltenden Datenschutzgesetze zu berücksichtigen.

Material und Methoden

Ein wichtiger Bestandteil zum Aufbau einer Forschungsdatenbank ist der Integrationsprozess, der den Datenexport aus verschiedenen Datenbanken, das Analogisieren der unterschiedlichen Datenstrukturen sowie den Datenimport in die zentrale OpEN.SC-Datenbank beinhaltet. Dieser, im Folgenden ‚Data Input‘, genannte Prozess, wird transparent, nachvollziehbar und flexibel gestaltet, wodurch der vollständige Prozess für den Eigentümer der Daten überprüfbar wird. Diese Überprüfbarkeit ist ein Bestandteil des Vertrages zwischen OpEN.SC und den klinischen Informationsgebern.

Um einen transparenten sowie nachvollziehbaren Entwurf zu gewährleisten, wird ein an die Service Oriented Architecture (SOA) [3] angepasster Rational Unified Process (RUP) [1] gewählt. Das Paradigma SOA dient dazu, ein komplexes System in weniger komplexe Teile zu zerlegen und eine Wiederverwendbarkeit einzelner Prozesse zu ermöglichen. RUP liefert ein standardisiertes und transparentes Vorgehen der Softwareentwicklung einschließlich der Softwaredokumentation, das von OpEN.SC auf die Bedürfnisse dieses Projektes zugeschnitten wurde (vgl. [5]).

Entsprechend dieser Herangehensweise werden Anwendungsfälle (Use Cases) entsprechend der Anforderungen bestimmt. Bezogen auf den ´Data Input´ ergibt sich eine Zergliederung in mehrere Teilprozesse, die unabhängig von einander entworfen und entwickelt werden. Im Resultat entstehen generalisierte Prozesse, die auf konkrete Anwendungsfälle adaptiert werden können.

Ergebnisse

Der Prozess ´Data Input´ wurde in sieben Komponenten ´Initialize´, ´Collect´, ´Transform´, ´Encrypt´, ´Transfer´, ´Write´, ´Log´ zergliedert (siehe Abbildung 1 [Abb. 1]). ´Initialize´ realisiert die Initialisierung des Prozesses, ´Collect´ extrahiert die für den Export bestimmten Daten aus der Quelle und ´Transform´ transformiert die Daten in die OpEN.SC-Datenstruktur. Die Komponente ´Encrypt´ beinhaltet die Verschlüsselung der Daten und die Komponente ´Transfer´ leistet die benötigte Übertragung der Daten vom Quellsystem zum OpEN.SC-System. ´Write´ ist das Synonym für den Import der Daten in die OpEN.SC-Datenbank und die Komponente ´Log´ ist Bestandteil des Monitoring-Prozesses. Die Reihenfolge ist nicht zwingend festgelegt.

Ein wichtiges Kriterium für die Charakterisierung der Komponenten ist die Frage, ob die Komponente quellunabhängig entworfen werden kann oder ob einige Funktionalitäten von den Eigenschaften der jeweiligen Quellsystems abhängen.

Die Komponenten ´Write´ und ´Initialize´ bilden jeweils eigenständigen Webservices OpEN.SC-seitig, um die Quellsystem-Unabhängigkeit sicherzustellen. Die Log Komponente ist für sämtliche Bestandteile des ´Data Input´ Prozesses relevant. Die Möglichkeit des Schreibzugriffs kann nicht auf jedem Quellsystem gewährleistet werden, deshalb werden die Logging Informationen grundsätzlich auf das OpEN.SC-System übertragen. Die Komponenten ´Collect´, ´Transform´, ´Encrypt´ und ´Transfer´ stehen in Abhängigkeit eines konkreten Quellsystems und werden daher zu einem auf dem Quellsystem auszuführenden Service zusammengefasst. Im Hinblick auf die tatsächliche Ausführung der Komponentenservices sind folgende Randbedingungen erfüllt worden: 1. Vermeidung von Beeinträchtigung von Routineprozesse auf dem Quellrechner, 2. Garantie von Konsistenz und Persistenz durch einen Transaktionsmechanismus, 3. Parametrisierbarkeit der ´Collect´-Komponente mittels eines sogenanntes Transfer-Property-File, um die vertraglich vereinbarte Ausprägung der zu übertragenen Daten abzubilden, 5. Vermeidung von Datenübertragungen, die einen Rückschluss auf die Person des Patienten zulassen, 6. Ermöglichung der Rück-Referenzierung ausschließlich auf dem Quellsystem, 7. Umsetzung der Quellsystemdatenstruktur mittels der implementierten ´Transform´-Komponente.

Diskussion

Der hier realisierte Entwurf erleichtert, durch die konsequente Umsetzung der RUP- und SOA-Paradigmen, die Wiederverwendbarkeit und Adaption für die Datenintegration in multizentrische Studien, generell. Die Abbildung eines individuellen Datenübernahmevertrages zwischen den klinischen Partnern in die Ausprägungen der einzelnen Komponenten des ´Data Input´ Prozesses gewährleistet und fördert die Bereitschaft, wissenschaftlich wertvolle Daten einer zentralen Datenauswertung zugänglich zu machen.

Danksagung

OpEN.SC wird von der DFG gefördert.


Literatur

1.
Kruchten, Philippe. The Rational Unified Process. An Introduction. Second Edition. s.l. : Addison Wesley, 2000. 0-201-70710-1.
2.
Lyman, Jason A, Scully, Kenneth und Harrison, James H Jr. The Development of Health Care Data Warehouses to Support Data Mining. Clinics In Laboratory Medicine. 28, 2008, S. 55-71.
3.
Nadkarni, Prakash M und Miller, Randolph A. Service-oriented Architecture in Medical Software: Promises and Perils. Journal of the American Medical Informatics Association. 14, 2007, S. 244-246.
4.
Schmidt, Danilo, Lindemann, Gabriela und Schrader, Thomas. First Steps towards an Intelligent Catalogue within the Open European Nephrology Science Center. 19th IEEE International conference on tools with artificial intelligence, (ICTAI-2007). Patras, Greece : IEEE, 2007.
5.
Szirbik, N.B., Pelletier, C. und Chaussalet, T. Six methodological steps to build medical data warehouses for research. International Journal of Medical Informatics. 2006, 75, S. 683-691.
6.
Zhou, Yao. The Development of A Quality Assurance Process for Medical Research Related Data in OpEN.SC Using BPEL, Master Thesis. 2008.