gms | German Medical Science

Einleitung: Die personalisierte Medizin bietet neue Lösungen für viele Herausforderungen der klinischen Forschung und der Entwicklung von neuen Medikamenten [1]. Der personalisierte Ansatz erfordert allerdings komplexe und interaktive Softwaretools [2]. Diese innovativen Softwarelösungen werden häufig nicht von Softwarefirmen, sondern von akademischen Gruppen im Rahmen von Forschungsprojekten entwickelt. Um aber in klinischen Studien eingesetzt werden zu können [3], müssen diese Werkzeuge auf Konformität mit dem Good Clinical Practice (GCP)-Standard [4], [5] validiert werden. Nur validierte Software kann in klinischen Studien die Sicherheit aller Studienteilnehmer und die Qualität der Studiendaten garantieren.

Das EU FP7-Projekt p-medicine entwickelte eine Infrastruktur mit eingebetteten Tools für den Übergang von der konventionellen Versorgung bei der Krebsbehandlung hin zu einem personalisierten Behandlungsansatz [6]. Die dabei zu unterstützenden Prozesse erfordern Datenerfassung in klinischen Studien, Datenimporte aus elektronischen Patientenakten, Zugriffe auf Bilder und den Austausch mit Biobanken. Hierbei spielt die Datenmanagementsoftware ObTiMA [7] eine zentrale Rolle. Diese Vielfalt an zu unterstützenden Prozessen resultiert aber auch in zusätzlichen Herausforderungen an die Computer System Validierung (CSV) der entsprechenden Softwarelösungen.

Historisch bedingt ist die CSV ein Prozess der eher auf kommerzielle Softwareentwicklung hin ausgelegt und für seine Umständlichkeit und Papierlastigkeit bekannt ist [8], [9]. Während die Entwicklung von Software immer agiler geworden ist und mit geringem papierbasierten Dokumentationsbedarf auskommt, hat sich im Bereich der CSV wenig verschlankt. Akademische Entwicklung bedeutet zudem, dass nicht ein kommerzielles Produkt erzeugt wird, sondern ein „Proof-of-Concept“. Aus diesen Gründen besteht im akademischen Umfeld die Notwendigkeit zur Anpassung und Optimierung der CSV.

Material und Methoden: Entwicklergruppen von FORTH (Foundation for Research and Technology – Hellas) in Kreta, King's College in London, Fraunhofer-Institut in Bonn und der Universität des Saarlandes in Homburg wurden mit Hilfe einer Umfrage zum Thema Validierung, GCP-Compliance, Qualitätsmanagement, Softwaretestung, Nachhaltigkeit und Entwicklungsprozesse befragt. Die Fragen zu den Methoden in der Softwareentwicklung umfassten Qualitätsanforderungen, Standardarbeitsanweisungen (SOPs), Entwicklungspläne, funktionale Spezifikationen, Nutzerspezifikationen, Dokumentationsverfahren für Tests). GCP-Regeln und Validierungsanforderungen wurden von den Vorschriften für die Computersystemvalidierung [10], dem ECRIN-Standard [5] und den Dokumentenvorlagen des TMF-Projektes Systemvalidierung [11], [12] abgeleitet. Die Umfrageergebnisse wurden mit den Entwicklergruppen diskutiert, um sie zu optimieren und als Basis für die Validierungssimulation einzusetzen. Für die Validierungssimulation wurde der Einsatz von Tools für das Datenmanagement [13], Imaging und Biobanking in einer regulierten Umgebung für klinische Studien simuliert. Dazu wurden die entsprechenden Anforderungen und Aktivitätsbeschreibungen mit den Anforderungen an GCP, Datensicherheit und Prozesskontrolle verglichen und für den regulierten Einsatz mit Hilfe einer Gap-Analyse [14] fortgeschrieben. Die Ergebnisse der Simulation ergaben neue Anforderungen, aber auch Empfehlungen für die Software und den Entwicklungsprozess, die wiederum als Grundlage des Trainings dienten. Auf der Anwendungsebene wurde ein Konzept entwickelt, um die ermittelten Anforderungen in Tools für das Bug-Tracking und die Versionskontrolle einzubringen, um regulatorische Anforderungen schon während der Softwareentwicklung darzustellen und zu integrieren.

Ergebnisse: Normalerweise spielen CSV-Anforderungen für den Softwareentwickler im akademischen Bereich keine große Rolle. Softwaretools werden für eine Pilotanwendung und nicht für eine GCP-konforme Studie oder den Verkauf an Pharmafirmen entwickelt. Softwarelösungen müssen deshalb nachträglich für den Einsatz im regulierten Umfeld vorbereitet werden. Und für diese Vorbereitung fehlen dann häufig Dokumente, wie z.B. Spezifikationen, Testdokumentationen, Softwarebeschreibungen. Auch müssen Anforderungen an das Design der Software teilweise nachträglich umgesetzt werden.

In unserer Methodik wird das zu entwickelnde Softwaretool schon während der Entwicklung fortgeschrieben und ein bereits fertiges und im regulierten Umfeld eingesetztes Produkt simuliert. Die dabei abgeleiteten Anforderungen umfassen GCP-Anforderungen und solche für den Datenschutz, sowie Anforderungen an die Nachhaltigkeit, an das Qualitätsmanagement und spezifische Anforderungen an den Datenaustausch mit Biobanken und Bildverarbeitungssystemen. Zum Beispiel wurden für das Datenmanagementsystem ObTiMA zusätzliche Qualitätschecks bei der Datensammlung, Verfahren zur Protokollierung der Dateneingabe (Audit Trail), Änderungen in der Verlinkung von „Visiten“ mit entsprechenden Erfassungsbögen, Änderungen in der Darstellung der Pseudonymisierung der Studienteilnehmer, und der Datenschutz bei der Integration von Biobankdaten mit klinischen Daten, zusätzlich etabliert.

Die aus der Simulation ermittelten Anforderungen wurden den Entwicklern auf zwei Wegen zur Kenntnis gebracht: erstens, durch Training (z.B. Workshops, SOPs, und Newsletter) und zweitens, durch Einbindung der Anforderungen in das Qualitätsmanagement der Entwicklungsumgebung (Integrationsplan, Bug-Tracking, Testszenarien, Usability Tests) [15].

Die Berücksichtigung von GCP-Anforderungen bedeutet einen zusätzlichen Aufwand für Entwickler. Insbesondere sind die Regeln für das Qualitätsmanagement und die dafür notwendige Dokumentation eine Belastung. Deshalb sollten die Anforderungen zur erfolgreichen Validierung den Entwicklern in Bezug auf die reale Nutzerumgebung erklärt werden. Dies erreichten wir durch die Beteiligung von Studienärzten an dem Evaluieren der Software.

Zur Ablaufunterstützung werden häufig Werkzeuge für die Softwareentwicklung benutzt, die in der Lage sind den Verbesserungsprozess zu steuern und automatisch Dokumentation zu erzeugen. Zum Beispiel lassen sich dazu JIRA [16], eine Anwendung zum Bug-Tracking und Projektmanagement oder Flyspray [17], ein Web-basiertes Bug-Trackingsystem mit zusätzlichen Funktionen für die Softwareentwicklung verwenden. Für die Unterstützung von Tests kann zudem der Integrations-Service Jenkins [18] eingesetzt werden. JIRA ist flexibel und kann einfach erweitert werden, um zusätzliche GCP-Anforderungen und Qualitätsaktivitäten zu unterstützen. So ist ein Audit- und Reportingmodul vorhanden und es gibt zusätzliche Add-ons, z.B. FDA 21CFR Part 11 [19], [20], die Anforderungen an elektronische Dokumente berücksichtigt. Diese Werkzeuge können, wenn sie richtig angepasst werden, regulatorische Anforderungen in den Entwicklungsprozess einbringen und zum dokumentierten Nachweis von Prüfungen und Aktivitäten verwendet werden.

Diskussion: Der GAMP (Good Automated Manufacturing Practice)-Standard [10] setzt immer noch auf das V-Modell für die Validierung, inzwischen zwar risikobasiert, aber orientiert an nicht-agilen Entwicklungszyklen, während sich auf der Entwicklerseite bereits agile Ansätze etabliert haben. Akademischen Entwicklergruppen arbeiten agil und setzen Softwarelösungen zum Bug-Tracking und für das Softwaremanagement ein. Die Validierungssimulierung kann einen agileren Ansatz bei der Validierung unterstützen. Sie geht dabei über eine simple Auflistung von Anforderungen hinaus, da sie auch Empfehlungen für das Qualitätsmanagement und die Nachhaltigkeit der Software generiert (z.B. Inhalte des Entwicklungsplans, Plan für die Softwarepflege und den Support. Das Hauptziel dabei ist, regulatorische Anforderungen frühzeitig in den Entwicklungsprozess einzubringen und die nötige Dokumentation und Verifizierung teilweise automatisch zu erstellen [21]. Unterstützt werden muss dieser Prozess aber durch das Training der Entwickler über alle Aspekte der CSV. Dieser zweigleisige Ansatz führt dazu, dass Entwickler sich den regulatorischen Anforderungen und den Besonderheiten der Nutzerumgebung bewusst werden und in der Entwicklung berücksichtigen können.

Acknowledgement: Das p-medicine Projekt erhielt Finanzmittel aus dem „EU Seventh Framework Programme“ (FP7/2007-2013) unter Grant Agreement No 270089.