gms | German Medical Science

Einleitung: Das Multiple Myelom ist eine seltene Krebserkrankung, die geprägt ist von starker Heterogenität des Krankheitsbildes mit variierenden Überlebenszeiten der Betroffenen, von einigen Monaten bis zu 15 Jahren [1]. Als Ursache für die Heterogenität der Erkrankung werden molekularbiologische Veränderungen des Genoms angesehen, diese sind durch chromosomale Aberrationen und veränderter Genexpression charakterisiert [1]. Das Gene Expression Profiling (GEP) wird als geeignetes Werkzeug zur Bestimmung des Grads der Heterogenität und der Planung einer individualisierten Behandlung geschätzt [1]. Im Rahmen einer vorhergegangenen Arbeit wurde ein R-basiertes Softwaretool (GEP-R) für die Risikostratifizierung anhand von Affymetrix Microarray-Daten (CEL-Dateiformat) entwickelt [1]. Hauptfunktion des Softwaretools ist die Generierung eines Arztbriefes mit klinischen Parametern und eines Genexpressionsreports mit einer Auswahl auffällig exprimierter Gene und Prognosefaktoren zur Risikostratifizierung. Die Software ist ein wertvolles Analyseinstrument und findet Anwendung in der klinischen Patientenversorgung der Sektion Multiples Myelom des Universitätsklinikums Heidelberg.

Wie bei der Genexpressionsanalyse werden klinisch relevante Informationen biomedizinischer Daten häufig erst nach einer rechnerunterstützten Aufbereitung für einen Menschen interpretierbar. Dabei bestehen oftmals zeitliche Abhängigkeiten und eine lange Dauer der Verarbeitung. Bei GEP-R beispielsweise kann die Erstellung von Berichten immer nur nacheinander erfolgen und muss sequentiell angestoßen werden. Die Dauer der Analyse einzelner CEL-Dateien beträgt ungefähr zehn Minuten, entstehende Wartezeiten mindern die Produktivität. Durch moderne Diagnoseverfahren werden immer mehr biomedizinische Daten generiert, und zu all diesen Daten müssen wie bei GEP-R Systeme bereitstehen diese aufzubereiten. In Folge führt dies zu einer stark heterogenen Systemlandschaft und ist Nachteilig für die langfristige Pflege und Weiterentwicklung. Eine integrierte Plattform und Vereinheitlichung der technologischen Basis kann hier Abhilfe schaffen.

Ziel dieser Arbeit ist es, die Möglichkeiten und Einschränkungen einer Forschungsplattform am Beispiel eines konkret existierenden Problems zu untersuchen und allgemeine Aussagen abzuleiten. Dazu ist die stark monolithisch aufgebaute GEP-R Anwendung in eine neue integrierbare Anwendung zu überführen. Die Handhabungsdefizite von GEP-R sollen gelöst werden, die zeitlich aufwändige Analyse der Microarray-Daten ist von den erforderlichen Benutzereingaben zu entkoppeln. Die Implementierung muss für die Anpassung an geänderte technologische klinische Anforderungen vorbereitet sein. Dazu sollte eine Abstraktion von visueller Präsentation und Ablaufsteuerung einerseits, und der eigentlichen Microarray-Analyse andererseits stattfinden. Wesentliche Komponenten der Anwendungsarchitektur sollen wiederverwendbar sein und den Transfer auf andere Krankheitsbilder erleichtern.

Material und Methoden: Auf Basis der Vorarbeiten, wird die Report-Engine als neue Anwendung wesentliche Aspekte einer Microarray-Analysepipeline kapseln. Unter Berücksichtigung des stattfindenden technologischen Fortschritts, soll die evolutionäre Weiterentwicklung der bisherigen Pipeline eine weichere Transition erlauben und zu einer Minderung der inhärenten Risiken abrupter Veränderung beisteuern. Die Wiederverwendung bereits existierender Komponenten wird auf die Eignung geprüft. Als Plattform wird das Enterprise Content Management System (CMS) Liferay [2] in Version 6.x genutzt. Die Entscheidung zur Verwendung leitet sich aus einem Anforderungskatalog wie der Etablierung, Reife und Vielseitigkeit ab.

Die neu zu entwickelnde Webapplikation wird als Liferay Portlet in Eclipse Luna implementiert und das Laufzeitsystem ist, abhängig zu der Portalsoftware, Oracle Java und Apache Tomcat als Laufzeitcontainer. Bei den genutzten Bibliotheken wird BIRT [3] (Business Enterprise Reporting Toolkit) zukünftig für die Generierung der Reports genutzt und Maven zur Unterstützung des Build-Prozesses. Die Nutzung von Open Source Technologien bietet die Möglichkeit, die Software allgemein verfügbar zu machen. Die Entwicklung der Anwendung erfolgt schrittweise und wird modular aufgebaut sein.

Zusammen mit den klinischen Nutzern erfolgen eine Validierung der Analyseergebnisse und die weitere Anpassung der Weboberfläche an die bestehenden Nutzeranforderungen. Regeln zur automatischen Plausibilitätsprüfung und Meldung erfolgter Verstöße sollen als Maßnahmen die Qualität der Dokumentation sichern helfen.

Ergebnisse: Die Report-Engine wurde als erster Prototyp implementiert und verfügt in der derzeitigen Version über die Funktionen des bisherigen GEP-R, gleichzeitig werden die erkannten Problemfelder adressiert. Architekturell ist die Anwendung in verschiedene Ebenen differenziert und nutzt derzeit noch einen angepassten Analysekern des bewährten GEP-R. Sowohl die Präsentationsschicht und die Ablaufsteuerung, als auch die Reportgenerierung wurden aus R herausgelöst und in Java reimplementiert. Dafür wurde der bestehende R-Code auf einen Analysekern reduziert und für eine Parametrisierung durch XML angepasst. Die Kernkomponente ist soweit funktional unabhängig, dass eine automatisierte Verarbeitung ohne Benutzereingaben ermöglicht wird. Die Ablaufsteuerung der Analyse wird aus der Webapplikation heraus unter Verwendung von RServe gesteuert. Der Bericht kann nach vorliegendem Ergebnis zu jedem Zeitpunkt in unterschiedlichen Formaten erstellt werden (HTML wird als Preview in der Webapplikation benutzt, PDF für die Archivierung und DOCX für die Nachbearbeitung in einer Textverarbeitung). Für die Verwaltung der CEL-Dateien wurden einfache Managementfunktionen implementiert (Erstellen/Ändern/Löschen von Patientendaten). Zu jeder CEL-Datei werden Patientendaten, bestehend aus Stammdaten, klinischen Daten, Kontaktinformationen des behandelnden Arztes und Sampleinformationen, erfasst. Die Patientendaten werden zusammen mit den Analyseergebnissen für die Reportgenerierung verwendet und vorbelegte Felder automatisch ausgefüllt. Ein Teil der klinischen Daten (z.B. ISS-Score [4]) muss a priori bekannt sein und wird zusammen mit weiteren Parametern dem Analysekern übergeben. Der Workflow wurde mehrbenutzerfähig gestaltet. Die Batch-Verarbeitung kann so gesteuert werden, dass die Analyse über Nacht laufen kann und die Ergebnisse mit Beginn des nächsten Arbeitstags vorliegen.

Diskussion: Liferay ist eine verbreitete Plattform für die Bereitstellung von Inhalten und geschätztes Zielsystem für die Entwicklung eigener Software. Ausdruck der Flexibilität und guten Eignung sind die Möglichkeiten zur Anpassung an vielfältige Einsatzgebiete. Bereitgestellte integrierte Portlets sind zusammen mit Eigenentwicklungen parallel nutzbar und erlauben es Anwendern sich ihre eigene Oberfläche zu personalisieren. Für die Anwendungsentwicklung kann auf das Liferay API und ein Metaframework (AlloyUI) zur Oberflächengestaltung zurückgegriffen werden. Wichtige Kernfunktionen (Benutzermanagement) müssen nicht erneut für jede Anwendung neu implementiert werden. Aus der Kombination der Funktionalität eines Portals mit einem Content Management System ergeben sich Synergieeffekte bei der kollaborativen Forschung. Versionierung und die Ablage der Dateien im CMS erlauben es über bereits existente Schnittstellen (WebDAV) auf eine gemeinsame Datenbasis zuzugreifen und Forschungsergebnisse zu kommentieren und zu teilen. Portlets sind ein guter Ansatz für den schrittweisen Aufbau einer personalisierbaren und adaptierbaren Forschungsplattform. Analysekomponenten zu heterogenen biomedizinischen Daten können entweder gekapselt oder im Verbund synergetisch genutzt werden. Die Report-Engine ist der erste Baustein eines integrierten Webportals für die Krebsforschung zum Multiplen Myelom. Durch die Nutzung von Komponenten der Report-Engine wird die Adaption an das Smoldering Myeloma vereinfacht.