Einführung
Mit der Revision der EN ISO 13485 und dem MDSAP Auditprogramm ist die praktische Bedeutung der Softwarevalidierung in der EU gestiegen. Sie erlangt in Audits zunehmende Aufmerksamkeit. Die US-amerikanische FDA hat mit FDA 21CFR820.70(i) bereits länger einen Fokus in dieser Richtung gehabt.
Arten von Softwarevalidierungen
Die Begriffswelt ist verworren und schwer zu durchschauen. In der Praxis lohnt sich die Unterscheidung in zwei Arten Software:
- Software, die Teil eines Medizinproduktes ist, oder gar das Medizinprodukt selber (SaMD)
- Software, die im Rahmen der Produktion des Medizinproduktes eingesetzt wird oder innerherhalb des Qualitätsmanagementsystems.
Software, die Teil eines Medizinproduktes ist (oder das Medizinprodukt selber – SaMD), lässt sich unter strikter Anwendung der harmonisierten und von der FDA anerkannten IEC/EN 62304 validieren. Dieser Artikel befasst sich mit der zweiten Art Software: Die Validierung von Software die innerhalb der Produktion oder des QM-Systems eingesetzt wird.
Synonyme für Softwarevalidierung in der Medizintechnik
Die Softwarevalidierung ist in der Medizintechnik auch bekannt als:
- Software Validierung
- Computer System Validierung / Computer-System-Validation / CSV
- Validation of automated systems (siehe 21CFR 820.70(i))
Vorgaben für die Validierung von Software für die Produktion und das QM-System
Bei Software, die für die Produktion, inklusive Prüfungen (!!), von Medizinprodukten verwendet wird oder, die im Qualitätsmanagementsystem selber verwendet wird (z.B. Dokumentenmanagementsystem, Messwertdatenbank, etc.) verhält es sich wesentlich komplizierter. Für diese Art Software existiert keine anerkannte Norm, nach der man bei der Softwarevalidierung vorgehen kann. Häufig fällt im Kontext der Softwarevalidierung für das QM-System oder die Produktion der Begriff GAMP 5. Hierbei handelt es sich um einen Leitfaden aus der pharmazeutischen Industrie zur Validierung dieser Art Software. GAMP 5 ist allerdings sehr mächtig und seine vollständige Umsetzung dementsprechend aufwendig und teuer. Ich selber habe noch nicht ein Unternehmen der Medizintechnik gesehen, dass streng nach GAMP 5 vorgeht. Wo liegt also die Mindestanforderung für die Softwarevalidierung? Sofern Sie in die USA liefern, definiert die Guidance General Principles of Software Validation der FDA das erwartete Vorgehen. Dieses Niveau überzeugt auch europäische Auditoren. Allerdings, so richtig selbsterklärend ist diese Guidance nicht. Daneben existiert noch die AAMI TIR36. Dieses Dokument ist eine recht pragmatische Anweisung zur Softwarevalidierung innerhalb der Medizintechnik, sollte jedoch nur in Verbindung mit der Guidance der FDA verwendet werden.
Praktische Heransgehensweise bei einer Softwarevalidierung
Den richtigen Ansatz für die Validierung finden
Für den Ansatz der Softwarevalidierung hat es sich in der Praxis bewährt, das Brauchbarste aus den verschiedenen bereits genannten Quellen zusammen zu mischen. Es sollte darauf geachtet werden dass die folgenden typischen Elemente erreicht werden:
- User Requirements
- Kategorisierung der Software gemäß GAMP 5
- (Functional Requirements)
- Risikoanalyse
- Testplan
- Testreport
Kategorisierung der Software gemäß GAMP 5
Hier geht es im Wesentlichen darum, dass eine Software um so fehleranfälliger sein wird, je kundenspezifischer diese ist. Auf dieser Philosophie basierend, können die Aufwände bei sogenannter Off-The-Shelf-Software, also gängiger Software, wesentlich reduziert werden. Viel mehr sollte man aus Gründen der Praktikabilität allerdings nicht aus GAMP 5 für die Softwarevalidierung übernehmen.
Vollständiger Umfang einer Softwarevalidierung
Eine lehrbuchhafte Softwarevalidierung umfasst die folgenden Elemente:
Dieser Umfang ist in der Praxis jedoch nur bei speziell für Ihr Unternehmen entwickelte Software gerechtfertigt. Die Grundidee der jeweiligen Elemente ist wie folgt.
| Software-Validierungs-Plan | Dient der Planung der Softwarevalidierung. Insbesondere sollen die Zuständigkeiten der weiteren Softwarevalidierungselemente dargestellt werden. Sowie welche Elemente die Softwarevalidierung enthalten soll. |
| Anwender-Lastenheft (User Requirements Specification – URS) | Beschreibt aus Ihrer Sicht, was die Software leisten soll. Dies ist die Basis der späteren Softwaretests. Wichtig ist es insbesondere bei umfangreicheren Softwarepaketen einzuschränken, was sie wirklich verwenden möchten. Dies erspart massiv Testaufwände. |
| Pflichtenhefft (Functional Requirements Specification – FRS | Die Idee dieses Dokumentes ist zu beschreiben, wie die Anwenderanforderungen umgesetzt werden. In der Praxis ist es meist eine reine Detaillierung der URS. In Theorie soll dieses Dokument vom Lieferanten der Software erstellt werden. |
| Entwurfsspezifikation (Design Specification – DS) | Spezifiziert auf einer technischen Ebene die Software. Insbesondere, wie verschiedene Softwaremodule miteinander interagieren sollen. |
| Modulspezifikation | Stellt die Anforderungen an einzelne Softwaremodule auf: Was soll das Modul leisten, welche Inputs und Outputs werden erwartet. |
| Programmieren | Der Akt der Erstellung der Software selber (Achtung: Dies ist KEIN Teil einer Softwarevalidierung!!). Die Darstellung in der Grafik dient lediglich der Verständlichkeit. |
| Modul-Test | Bei modular erstellter Software erfolgt ein Test des programmierten Softwaremoduls gegen die jeweilige Modulspezifikation (DS). |
| Integrations-Test | Testet die Zusammenarbeit der verschiedenen Module nach deren Integration. |
| Funktionaler-Test | Es erfolgt ein Test gegen das Pflichtenheft (Functional Requirements Specification – FRS). |
| Testen der Lasten | Es erfolgt ein Test gegen das Anwender-Lastenheft (User Requirements Specification – URS). |
| Software-Valieirungs-Report | Eine Zusammenfassung, dass alle vom Software-Validierungs-Plan geforderten Aktivitäten erfolgreich durchgeführt wurden. Zumeist enthält er eine Freigabe der Software für die Anwendung. |
| Risikomanagement | Das in der Grafik nicht dargestellte Risikomanagement ist die Basis für die Festlegung von Testbreite und Teststärke des aufsteigenden Astes des Validierungs-“V”. |
Steuerung der Komplexität – Planung einer Softwarevalidierung
Sicherlich haben Sie erkannt, dass der volle Umfang einer Softwarevalidierung gemäß Lehrbuch für einen Großteil Ihrer Software absolut unverhältnismäßig wäre.
Ihre Aufgabe besteht daher darin zu rechtfertigen, dass ein reduzierter Aufwand an Validierungsmaßnahmen und Validierungsdokumenten gerechtfertigt ist.
Als erstes gilt es, genau aufschreiben muss, was die Software für Ihr Unternehmen machen soll. Hierbei ist der Fokus auf dem Qualitätsmanagement-Aspekten zu halten. Meist wird nur ein geringer Funktionsumfang der Software tatsächlich benötigt. Die Softwarevalidierung muss nur den tatsächlich genutzten Teil der Software umfassen.
Darauf folgt die Risikoanalyse. Für jede genutzte Softwarefunktion gilt es zu analysieren, ob sich die Funktion im Fehlerfall negativ auf das Produkt auswirken könnte oder eine Fehlfunktion zu einer Nicht-Erfüllung von gesetzlichen Vorgaben, wie der Einhaltung des QM-Systems führen kann. Diese Risikoanalyse dient der Steuerung der Testumfänge im Rahmen der Softwarevalidierung. Damit die Risikoanalyse und die daraus abgeleiteten Tests jedoch einen Wert haben, müssen die an der Risikoanalyse beteiligten Personen ein Grundverständnis für Softwarearchitektur und -programmierung haben. Typischerweise wird eingekaufte Software validiert, über die keine Informationen zur genauen Funktionsweise verfügbar ist. Daher müssen die an der Softwarevalidierung beteiligten Personen wissen, wie die von Ihnen untersuchten Softwarefunktionen mit hoher Wahrscheinlichkeit aufgebaut sind. Anderenfalls lassen sich mögliche Fehlerquellen nicht identifizieren und die Risikoanalyse läuft ins Leere. Dasselbe Verständnis von Software ist für die Planung der tatsächlichen Tests der Softwarevalidierung erforderlich.
Mit einer genauen Beschreibung, was die Software für Sie machen soll und einer darauf aufbauenden Risikoanalyse lässt sich dann argumentieren, welche Tiefe an Anforderungen und Test erforderlich sind. Überzeugen Sie Außenstehende durch eine schlüssige Argumentation, dass die von Ihnen gewählten Umfänge in Ihrer Softwarevalidierung angemessen sind!
Validierung der Software einer Produktions- oder Prüfanlage
Die Komplexität einer Softwarevalidierung kann gesteigert werden, wenn die zu validierende Software Teil einer Produktions- oder Prüfanlage ist. In diesem Fall werden einige, jedoch nicht alle Softwarefunktionen die Anlage steuern oder deren Daten verarbeiten. Gemäß 21CFR820.70(g) ist für alles Produktionsequipment (inkl. Prüfequipment) eine Abnahme durchzuführen ist. Diese Abnahme wird meist als Installation Qualification (IQ) bezeichnet. Eine der wesentlichen Punkte der Installation Qualification ist die Abnahme der tatsächlichen Funktionen der Anlage.
Jetzt treffen zwei Abnahmeinstrumente – die Softwarevalidierung und die Installation Qualification – auf dieselbe Anlage. Nun gilt es zu ermitteln, welche Teile der Softwarefunktionen bereits über die Installation Qualification zufriedenstellend geprüft werden können, und welche eine weitergehende Softwarevalidierung erfordern. Die Abgrenzung, welche Funktionen in der IQ und welche in der Softwarevalidierung abgeprüft werden, gilt es natürlich zu dokumentieren, sodass am Ende sichergestellt ist, dass wirklich alle Software- und Anlagenfunktionen getestet wurden. Eine weitere Steigerung der Komplexität der Softwarevalidierung ist möglich, wenn die Software z.B. an ihr ERP-System angeschlossen wird oder Teile der Softwarefunktion in noch weiteren Teilaspekten Ihres QM-Systems wie beispielsweise einer Kalibrierung abgedeckt werden.
Eine effiziente Softwarevalidierung in der Medizintechnik lebt von der gründlichen Analyse der Software im Kontext ihres Anwendungsumfeldes. Für die Vermeidung von mehrfachen Testungen derselben Softwarefunktion ist eine enge Abstimmung des Risikomanagements, der Equipmentqualifizierung (IQ), der Softwarevalidierung und ggf. der Softwarevalidierungen weiterer angebundener Software notwendig. Hierfür ist interdisziplinäres Wissen und Erfahrung sowie ein Blick für das Big-Picture erforderlich.
