Freudensprünge löst das Thema Validierung von Software bei den wenigsten Menschen aus. Im Gegensatz zu elektronischen oder mechanischen Baugruppen haben digitale Anwendungssysteme keine statistischen Ausfälle von Teilkomponenten, sie korrodieren und verschleißen nicht. Aus diesem Grund fällt es Nutzern zumeist schwer, Software als Teil des “Werkzeugkastens” zu betrachten und es steht für sie außer Frage, dass die Anforderungen, welche die Nutzer an das System stellen, auch erfüllt werden. Die Validierung wird zum lastigen Übel und ihr Sinn und Zweck bleiben verborgen.
Warum es dennoch sinnvoll ist seine Software-Werkzeuge zu validieren
Kurz gesagt: Software ist komplex. Aufgrund dieser Komplexität kann sie nicht für jede Kombination von potenziellen Pfaden durch den Code oder für jeden historischen Pfad sowie jede Ansammlung von Daten vollständig getestet werden. Die Einsatzgebiete und Szenarien sind so vielseitig, dass nicht jedes mögliche Risiko präventiv eliminiert werden kann.
Hinzu kommt, dass die Überprüfung von Software durch Konfigurationen zusätzlich an Komplexität gewinnt. Änderungen, wie beispielsweise die Modifikation von Verzeichnispfaden, sind erst dann offensichtlich, wenn sie tatsächlich verwendet werden oder der Benutzer explizit auf Veränderungen hingewiesen wird. Im Gegensatz dazu sind Änderungen an einem Bildschirm, einer Tastatur oder anderen physischen Komponenten viel offensichtlicher.
Nicht validiertes System führt zu katastrophalen Folgen
Ein Systemfehler mit verheerenden Folgen trat beispielsweise Ende der 1980er Jahre beim Therac-25 auf – ein Linearbeschleuniger zur Anwendung in der Strahlentherapie. Der Computer des Therac-25 war zugleich für die Messwerterfassung und Steuerung des Geräts, als auch für die Benutzerinteraktion zuständig. Durch Multitasking wurden beide Aufgaben quasi-gleichzeitig erledigt. Das Kernproblem dabei war die korrekte Synchronisation der beiden Prozesse – die Benutzer tätigten die Eingaben schneller, als das Gerät reagieren und zwischen den verschiedenen Modi umschalten konnte. Von Juni 1985 bis 1987 kostete es deshalb drei Patienten das Leben und verletzte drei weitere schwer. Bis zu diesem Zeitpunkt hatten Behörden nur wenig Erfahrung im Umgang mit Computersoftware und damit zusammenhängenden Ausfällen in diesem Schweregrad.
Die Problematik des Therac-25 brachte den Stein für die Entwicklung von Regularien für die Validierung von Software ins Rollen.
Selbst wenn es aufgrund von Feldfehlern glücklicherweise nicht zu Personenschäden oder Rückruf von Produkten kommt, entstehen in der Regel Kosten für Konfigurationen, Wartung und Instandhaltung sowie Schaden für den Ruf des Unternehmens.
Auch der GAMP 5-Leitfaden – DAS Handbuch für die Validierung computergestützter Systeme – weist klar darauf hin, dass sich gut definierte und spezifizierte Systeme leichter unterstützen und warten lassen. Dies wiederum führt zu geringeren Ausfallzeiten und Wartungskosten.
Es sollte somit klar sein, dass die Validierung eines Systems zu einer Nettoeinsparung führt, wenn die folgenden Ziele anstrebt werden:
- Analyse und Beherrschung von Risiken,
- Vermeidung potenzieller Gefahren für Personal, Patienten/Kunden oder Dritte,
- Ermöglichen lückenloser Rückverfolgbarkeit
Das große Problem bei der Umsetzung ist, dass es nicht nur irgendeine, sondern eine sinnvolle, strukturierte und auf das System zugeschnittene Validierung sein muss. Eine Software bis ins letzte Detail „tot zu validieren“, um Inspektoren mit einer Dokumenten-Wand zu erschlagen und ruhig zu stellen, bringt einen extremen Zeit- und Ressourcenaufwand mit sich. Zudem kennt man die realen Schwachstellen und Fehlerquellen des Systems genauso wenig wie vorher. Der Detaillierungsgrad der Validierung sollte Risiko, Komplexität und Neuartigkeit des Systems widerspiegeln.
David A. Vogel bringt es auf den Punkt: “Software validation is subject to opinion. It is part science, part engineering, part psychology, and part organizational management. “ Solange der Sinn und Zweck der Validierung nicht verstanden wird, ist es wirklich, wie so häufig beklagt, „verschwendete Zeit“.
Übrigens: Die roXtra Softwarelösungen gibt es auch als GxP-konforme Standardversion – roXtra GxP. roXtra GxP erfüllt die Anforderungen gängiger nationaler sowie internationaler Regularien und Leitlinien, wodurch Ihre Qualifizierungs- und Validierungstätigkeiten reduziert werden können.
Referenzen:
GAMP 5 – A Risk-Based Approach to Compliant GxP Computerized Systems. (2008). ISPE.
Vogel, D. (2011). Medical Device Software Verification, Validation, and Compliance. Norwood, Massachusetts: ARTECH HOUSE.
Bildnachweis:
iStock.com/anyaberkut
