04338 Validierung prozessunterstützender Softwarewerkzeuge
|
In der Medizintechnik ist der Einsatz prozessunterstützender Werkzeuge nicht nur sinnvoll, sondern teilweise unabdingbar, um den gesetzlichen Anforderungen an den Entwicklungsprozess gerecht zu werden. Ein gutes Beispiel ist die Trace-Matrix, die ab einer bestimmten Anzahl von Anforderungen und Testfällen ohne unterstützende Software kaum noch manuell zu bewältigen ist.
Da Werkzeuge jedoch potenziell Einfluss auf die Produktqualität haben können, müssen sie validiert werden. In der Praxis hat sich hierfür eine workflow- und risikobasierte Vorgehensweise bewährt. Prozess-, Kritikalitäts- und Part-11-Compliance-Analysen legen dabei den zu prüfenden Funktionsumfang und die Testabläufe fest. Arbeitshilfen: von: |
1 Motivation
Die Fähigkeit, Werkzeuge zu verwenden, unterscheidet den Menschen, die Primaten und einige andere Tierarten wie z. B. Rabenvögel von weniger hoch entwickelten Lebensformen. Tatsächlich setzen wir diese Gabe gerne mit Intelligenz gleich. Während uns die Krähen, die mit einem Stöckchen Leckerbissen aus einer Röhre ziehen, jedoch noch beeindrucken [1], sind Werkzeuge im menschlichen Alltag völlig selbstverständlich geworden.
Entwicklungswerkzeuge
Werkzeuge erleichtern uns die tägliche Arbeit. In manchen Fällen ermöglichen sie diese Arbeit überhaupt erst. Wenn wir im Zusammenhang mit der Entwicklung medizinischer Geräte von „Werkzeugen” sprechen, meinen wir in der Regel Messgeräte oder Software-Applikationen. Manche dieser Entwicklungswerkzeuge sind uns selbstverständlich geworden. Wir sprechen davon, dass Testfälle „per Hand” geschrieben wurden, obwohl tatsächlich dafür Microsoft Word™ oder ein vergleichbares Programm verwendet wurde. Im Gegensatz zu einem Testmanagement-Werkzeug tritt der unterstützende Texteditor allerdings stark in den Hintergrund. Nichtsdestotrotz handelt es sich auch hier um ein „Werkzeug”.
Werkzeuge erleichtern uns die tägliche Arbeit. In manchen Fällen ermöglichen sie diese Arbeit überhaupt erst. Wenn wir im Zusammenhang mit der Entwicklung medizinischer Geräte von „Werkzeugen” sprechen, meinen wir in der Regel Messgeräte oder Software-Applikationen. Manche dieser Entwicklungswerkzeuge sind uns selbstverständlich geworden. Wir sprechen davon, dass Testfälle „per Hand” geschrieben wurden, obwohl tatsächlich dafür Microsoft Word™ oder ein vergleichbares Programm verwendet wurde. Im Gegensatz zu einem Testmanagement-Werkzeug tritt der unterstützende Texteditor allerdings stark in den Hintergrund. Nichtsdestotrotz handelt es sich auch hier um ein „Werkzeug”.
Werkzeuge müssen validiert werden. Dies gebietet nicht zuletzt der gesunde Menschenverstand. Wer eine alte Axt einsetzt, sollte sich unbedingt vorher vergewissern, dass der Axtkopf auch nach Jahren noch fest auf dem Stiel verankert ist. Wir sprechen hier ganz klar von einer risikominimierenden Maßnahme. Ebenso ist es mit Software-Applikationen. Auch hier müssen wir überprüfen, dass die Software im aktuellen Umfeld noch funktioniert und im jeweiligen Entwicklungsprozess eines Medizinprodukts eingesetzt werden kann.
Validierung aus Selbstschutz
Werkzeugvalidierung ist somit reiner Selbstschutz. Nebenbei wird sie auch aus regulatorischer Sicht gefordert. In der für alle sicherheitskritischen Branchen geltenden IEC 61508:2010 heißt es in Part 3, Abschnitt 7.4.4.6: „For each tool in class T3, evidence shall be available that the tool conforms to its specification or documentation." Die Klasse T3 bezeichnet hierbei Werkzeuge, die direkt oder indirekt Einfluss auf den ausführbaren Code haben.
Werkzeugvalidierung ist somit reiner Selbstschutz. Nebenbei wird sie auch aus regulatorischer Sicht gefordert. In der für alle sicherheitskritischen Branchen geltenden IEC 61508:2010 heißt es in Part 3, Abschnitt 7.4.4.6: „For each tool in class T3, evidence shall be available that the tool conforms to its specification or documentation." Die Klasse T3 bezeichnet hierbei Werkzeuge, die direkt oder indirekt Einfluss auf den ausführbaren Code haben.
IEC 62304 hält sich, wie gewohnt, bedeckt und fordert lediglich lapidar ein Konfigurationsmanagement für Werkzeuge, welche die Medizinprodukte-Software beeinflussen können (gilt für SW der Klasse B oder C). ISO 13485:2016 wird da schon deutlicher und fordert (seit 2016 sogar verstärkt) eine risikobasierte Validierung aller Messmittel und prozessunterstützenden Werkzeuge, sofern diese Einfluss auf die Produktqualität haben können. Weitere Hilfestellung findet sich im neuen Standard ISO/TR 80002-2:2017, in welchem ebenfalls ein risikobasierter Ansatz empfohlen wird. Neu ist dabei jedoch nur die Tatsache, dass es nun endlich einen internationalen Standard gibt. Inhaltlich ist ISO/TR 80002-2:2017 nämlich nahezu wortgleich zum zehn Jahre älteren technischen Report AAAMI TIR 36.
Wie so oft, kommen die deutlichsten Vorgaben somit von der FDA. In 21 CFR 820.70(i) heißt es: „When computers or automated data processing systems are used as part of production or the quality system, the manufacturer shall validate computer software for its intended use according to an established protocol. All software changes shall be validated before approval and issuance. These validation activities and results shall be documented”.
FDA-Forderungen nach Werkzeugvalidierung
Daraus ergeben sich vier grundlegende Forderungen:
Daraus ergeben sich vier grundlegende Forderungen:
| • | Wir müssen wissen (und dokumentiert haben), wozu wir ein Werkzeug einsetzen, oder anders ausgedrückt, die Zweckbestimmung („for its intended use”) des Werkzeugs muss geklärt sein. |
| • | Jedes Werkzeug, auf dessen Ergebnisse wir uns verlassen, muss dokumentiert validiert werden („the manufacturer shall validate ... activities and results shall be documented”). |
| • | Die Validierungstestfälle müssen vorab spezifiziert werden („according to a specified protocol”). |
| • | Die Validierung muss vor dem Einsatz erfolgen. Danach dürfen Änderungen nur noch kontrolliert erfolgen. Gegebenenfalls. wird eine Re-Validierung erforderlich („shall be validated before approval and issuance”). |
Die Forderungen der FDA schließen auch solche Werkzeuge mit ein, bei denen das Ergebnis zwar noch geprüft wird, wir jedoch nicht mehr glaubhaft vermitteln können, dass ein Fehler wirklich bemerkt würde. Unglücklicherweise sind gerade dies die Aufgaben, die wir besonders gerne durch Werkzeuge erledigen lassen. Das klassische Beispiel hierfür ist die Erstellung einer Trace-Matrix. Je mehr Zeilen die Matrix hat, desto weniger glaubhaft wird es, dass im Review wirklich jede Zeile geprüft wurde. Umgekehrt wird es aber auch umso schwerer, die Matrix ohne entsprechende Unterstützung zu erstellen.
2 Inventur
Was ist also zu tun? Als Erstes sollten Sie sich einen Überblick verschaffen, welche Werkzeuge überhaupt wo und wofür im Einsatz sind (siehe beigefügte Excel-Datei). Gehen Sie dabei gründlich vor und betrachten Sie alle Entwicklungs- und Produktionsphasen. Die üblichen Verdächtigen sind zunächst einmal die klassischen Büroanwendungen, also Texteditoren und Tabellenkalkulationsprogramme. In der Software-Entwicklung finden wir ferner Quellcode-Editoren, Compiler, Debugger sowie Versions- bzw. Konfigurationsmanagementsysteme. Weitere Kandidaten für eine Validierung sind das Buildmanagementsystem, Werkzeuge zur Fehlerverfolgung und statischen Codeanalyse. Schließlich gibt es noch eine Reihe prozessunterstützender Werkzeuge, z. B. für das Anforderungs-, Test- oder Dokumentenmanagement. Auch die Hardwareentwicklung und die Produktion setzen eine Vielzahl von Werkzeugen ein.[
04338_a.xlsx]
04338_a.xlsx]Makros sind Werkzeuge
Bis dahin ist die Inventur reine Fleißarbeit. Interessant wird es, wenn Sie genauer hinschauen. Sie werden überrascht sein, wie viele meist frei verfügbare kleine Hilfsmittel und selbst geschriebene Makros im Einsatz sind. Letztere erfüllen oftmals wichtige Aufgaben im Prozess, ohne bislang einer strengen Qualitätskontrolle unterworfen worden zu sein. Natürlich gibt es auch Grenzfälle. Makros, die sich jemand selbst angelegt hat, um beispielsweise das Layout eines Dokuments zu verbessern, sind keine Werkzeuge in unserem Sinne. Als Faustregel kann man sagen, dass alles als Werkzeug zählt, was von mehreren Personen für prozessrelevante Aufgaben verwendet wird.
Bis dahin ist die Inventur reine Fleißarbeit. Interessant wird es, wenn Sie genauer hinschauen. Sie werden überrascht sein, wie viele meist frei verfügbare kleine Hilfsmittel und selbst geschriebene Makros im Einsatz sind. Letztere erfüllen oftmals wichtige Aufgaben im Prozess, ohne bislang einer strengen Qualitätskontrolle unterworfen worden zu sein. Natürlich gibt es auch Grenzfälle. Makros, die sich jemand selbst angelegt hat, um beispielsweise das Layout eines Dokuments zu verbessern, sind keine Werkzeuge in unserem Sinne. Als Faustregel kann man sagen, dass alles als Werkzeug zählt, was von mehreren Personen für prozessrelevante Aufgaben verwendet wird.
Mit der Inventur ist der erste Schritt zum Validierungsplan getan. Wichtig ist dabei, dass Sie nicht nur die Werkzeuge, sondern auch die Version und den Verwendungszweck ermitteln. Daraus lässt sich erkennen, ob das Werkzeug Einfluss auf die Produktqualität bzw. auf die Prozesskonformität hat. Ist dies der Fall, so muss eine Validierung geplant werden.