Software-Validierung – Chance oder lästiges Übel?

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“.


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.
213
2019-04-12T12:10:05+00:0012. April 2019|Artikel-Serie, Fachwissen, Neues im QM-Lexikon, News, QM, QM-Software, roXtra|0 Kommentare

Über den Autor:

Lucille Exler
Masterandin im Bereich Software-Validierung bei der Rossmanith GmbH

Hinterlassen Sie einen Kommentar

*