Häufig stellt sich beim Thema „Werkzeug Validierung“ die Frage, ob man auch Testwerkzeuge (z.B. N/JUnit) und ALM-Tools (z.B. MedPack, JIRA, Microsoft TFS) validieren bzw. verifizieren muss.

Update: Aktuelle Erfahrungen, wie in Audits die Werkzeug-Validierung adressiert wird (mehr »)

Regulatorische Anforderungen an die Werkzeug-Validierung

Unterschätzen Sie nicht die regulatorischen Anforderungen und die Überprüfung derer durch Auditoren! Ich habe mir selbst schon Minor-Non-Conformities wegen mangelnder Tool-Validierung „eingefangen“.

Die Validierung von (Entwicklungs-)Werkzeugen ist gesetzlich vorgeschrieben

Die Anforderungen an die Werkzeug Validierung finden Sie v.a. in den Regularien mit Bezug zum Qualitätsmanagement.

1. Anforderung der ISO 13485 an die „Tool Validierung“

a) Kapitel 4.1.6 (Neu seit ISO 13485:2016)

Seit der 2016-er Ausgabe der ISO 13485 fordert die Norm explizit, dass die Hersteller Verfahren zur Software-Validierung für Software festlegen müssen, die das Qualitätsmanagementsystem nutzt. Diese Validierung sei risikobasiert durchzuführen.

Der Technical Report ISO 80002-2 gibt konkretere Hinweise,

• auf welche Software diese Anforderungen zutreffen,
• wie eine solche Validierung erfolgen kann und
• wie der Grad dieser Validierung mit dem Risiko korrelieren sollte.

Dieses neue Kapitel übernimmt teilweise die Forderungen der ISO 13485:2012 aus den Kapiteln 7.5.2.1 und 8.2.3.

b) Kapitel 7.6: Messmittel

Im Kapitel 7.6 (Lenkung und Erfassung von Messmitteln) schreibt die ISO 13485:

„Die Organisation muss Verfahren für die Validierung der Anwendung von Computersoftware dokumentieren, die für die Überwachung und Messung von Anforderungen eingesetzt wird. Derartige Softwareanwendungen müssen vor der ersten Verwendung validiert werden und, soweit angemessen, nach Änderungen an dieser Software oder deren Anwendung.“

D.h. Entwicklungswerkzeuge sind dann zu validieren, wenn Sie ein Messmittel darstellen.

Beispiele für diese Werkzeuge finden Sie weiter unten.

c) Kapitel 8.2.5: „Prozess-Messwerkzeuge“

Weiter lesen wir in Kapitel 8.2.5 „Überwachung und Messung von Prozessen“: „Die Organisation muss geeignete Methoden zur Erfassung und, soweit angemessen, Messung der Prozesse des Qualitätsmanagementsystems anwenden. Diese Methoden müssen darlegen, dass die Prozesse in der Lage sind, die geplanten Ergebnisse zu erreichen.“

D.h. Werkzeuge, die zur Messung von Prozessen des QM-System (z.B. des Entwicklungsprozesses) genutzt werden, müssen Sie ebenfalls der Werkzeug Validierung unterziehen.

Beispiele für diese Werkzeuge finden Sie weiter unten.

d) Kapitel 7.5.6: Werkzeuge mit Auswirkungen auf die Güte von Produkten und Prozessen

Im Kapitel 7.5.6 zur „Validierung der Prozesse zur Produktion und zur Dienstleistungserbringung“ finden Sie folgende Forderung (fast gleichlautend mit der in Kapitel 7.6):

„Die Organisation muss Verfahren für die Validierung der Anwendung von Computersoftware dokumentieren, die bei der Produktion und Dienstleistungserbringung eingesetzt wird. Derartige Softwareanwendungen müssen vor der ersten Verwendung validiert werden und, soweit angemessen, nach Änderungen an dieser Software oder deren Anwendung.“ 

D.h Sie müssen auch sonstige Werkzeuge validieren, die eine Auswirkung auf die Güte der Produkte haben.

Beispiele für diese Werkzeuge finden Sie weiter unten.

2. Anforderungen der FDA an die Validierung

Die FDA enthält in mehreren Teilen des 21 CFR Anforderungen an die Validierung von Software, von Messmitteln und sonstigen Werkzeugen. Dazu zählt auch der 21 CFR part 11 mit den elektronischen Unterschriften und Aufzeichnungen. Wie diese Validierung zu erfolgen hat, beschreibt die FDA im Guidance Document „Software Validation“, das sowohl auf Software anzuwenden ist, die Teil des Medizinprodukts ist, als auch auf Prozess-Software.

Beispiele für Werkzeuge, die validiert werden müssen

Wohlgemerkt, wir sprechen hier nicht von der Software, die Teil des Medizinprodukts wird wie Datenbanken, Betriebssysteme, Bibliotheken und sonstige SOUPs, sondern von Werkzeugen.

1. Werkzeuge die der Messung des Produkts dienen

• Unit-Test-Werkzeug
• Werkzeug für die statische Code-Analyse wie Code-Metriken
• Automatische GUI-Tests
• Software im Prüfstand
• Werkzeug zum Auswerten von Fragebögen

Eine IDE muss nicht per se validiert werden, es sei denn sie enthält Messfunktionen, beispielsweise die eben genannten. Andere Werkzeuge wie Versionsverwaltungssysteme oder UML-Modellierungswerkzeug müssen Sie als Messsystem(!) nicht nicht validieren, als Prozesswerkzeug ggf. schon (s.u.).

2. Werkzeuge, die der Messung von Prozessen dienen

Viele Hersteller nutzen ALM- und Ticketing-System auch zur Messung der Prozessgüte um z.B. folgende Größen zu bestimmen:

• Anzahl der Fehler pro Zeiteinheit
• Verhältnis und Trends kritischer und unkritischer Fehler
• Zeiten zum Beheben von Fehlern
• usw.

3. Werkzeuge, die einen Einfluss auf die Güte von Produkten oder Dienstleistungen haben

Es gibt Werkzeuge, die einen direkten Einfluss auf die Güte von Produkten oder Dienstleistungen haben, die nicht den Messwerkzeugen zugeordnet werden können:

• Build-und Continuous Integrationsserver
• Versionsverwaltungssystem
• Byte-Code-Modifikation
• Compiler
• Produktionssteuerung

Wenn man argumentieren kann, dass Fehler in diesen Werkzeugen mit ausreichender Wahrscheinlichkeit erkannt würden oder hinreichend unwahrscheinlich sind, kann ggf. auf eine Validierung verzichtet werden.

4. Werkzeuge, die unter die Anforderungen des 21 CFR part 11 fallen

Diese Forderungen entstammen zwar der FDA, allerdings gehen viele europäische Auditoren analog vor. Sie müssen daher nachweisen, dass die elektronischen Unterschriften und elektronischen Dokumente nicht verfälscht werden können und sich die Autoren/Ersteller eindeutig und unabstreitbar identifizieren lassen.

Auch diese Werkzeuge — genau gesagt die Teile dieser Werkzeuge der den Messungen dienen — wären zu validieren.

5. Sonderfall Compiler

Compiler haben sicher auch einen Einfluss auf die Qualität der Software. Sie sind aber erst dann ein Messwerkzeug, wenn Sie den Compiler nicht nur nutzen, um einen Quellcode in ein binäres Artefakt zu überführen, sondern wenn Sie die Ergebnisse der statischen Code-Analyse nutzen, die so ein Compiler zweifelsfrei auch durchführt.

Wie bzw. wie intensiv sollten Sie ihren Compiler validieren? Hier gibt es sicher keine allgemeingültige Regel. Außer vielleicht den folgenden:

• Je weniger verbreitet Ihr Compiler ist, desto intensiver müssen Sie ihn validieren.
• Wenn Sie in Ihren Richtlinien Vorschriften an das Compiler-Level stellen, dann sollten Sie (zumindest exemplarisch) prüfen, ob der Compiler die mit diesem Compiler-Level verbundenen Prüfungen durchführt und Verstöße gegen diese Prüfregeln tatsächlich erkennt.

Tipps für die Validierung von Werkzeugen

Der Begriff Verifizierung in diesem Kontext erscheint bei Software etwas problematisch. Eigentlich ist es eine Validierung, nämlich eine Prüfung, ob das Werkzeug den Nutzungszweck tatsächlich erfüllt. Bei einem Testwerkzeug müsste beispielsweise geprüft werden, ob Fehler tatsächlich gefunden werden und ob das Werkzeug bei fehlerfreier Software auch keine Fehler meldet.

1. Auswahl der zu validierenden Werkzeuge begründen und dokumentieren

Zuerst sollten Sie bewerten, ob ein Werkzeug zu validieren ist – oder nicht.  Dafür eignet sich am besten eine Checkliste, mit Sie charakterisieren, in welche Klassen von Typen (siehe oben) eine Software fällt.  Die Hersteller nennen dieses Dokument unterschiedlich, beispielsweise „CSV Decision Matrix“ (CSV steht für Computer System Validation). Identifizieren und charakterisieren Sie in dieser Tabelle die Werkzeuge anhand folgender Punkte:

• Typischer Name des Werkzeugs
• Version des Werkzeugs
• Hersteller
• Art des Werkzeugs
• kurze Beschreibung des Einsatzzweckes bzw. eine Referenz darauf
• Typ(en) (siehe oben)

2. Anforderungen an die zu validierenden Werkzeuge beschreiben

Falls ein Werkzeug validiert werden muss, sollten Sie beschreiben, wozu Sie das Werkzeug einsetzen wollen. Man nennt das häufig eine User Requirements Specification URS. Wenn Sie das minimal kurz halten wollen, können Sie das auch in der oben genannten Tabelle dokumentieren. Wir haben diese Angaben auch schon in Test-Spezifikationen gefunden. Gleich wo, Sie müssen das dokumentieren.

Mein Tipp: Beschränken Sie den Aufwand für die Verifizierung/Validierung der Messwerkzeuge (zumindest solange diese bereits im Markt bewährt sind), indem Sie v.a. die absolute und für Sie relevante Kernfunktionalität sowie die Bereiche der Software prüfen, die Sie durch Konfiguration für sich spezifisch gestaltet haben (Customizing). Sie wollen die Qualitätssicherung ja nicht zum Selbstzweck machen, sondern für sich (und den Auditor) weitgehend sicherstellen, dass die Werkzeuge ihren Zweck erfüllen. Die Wahrscheinlichkeit einen Fehler in einem 100.00-fach eingesetzten Werkzeug wie NUnit, CPPUnit oder JUnit zu finden, ist eher gering.

Wie gesagt, fokussieren Sie sich auf den für Sie spezifischen Teil des Werkzeugs („Customizing“) und die eigene Software selbst. Die Wahrscheinlichkeit in der eigenen Software einen Fehler zu haben, ist um Größenordnungen höher als bei kommerziellen oder Open-Source Werkzeugen. Eine Werkzeug Validierung kann in 30 Minuten abgeschlossen sein.

3. Test spezifizieren (Plan für Werkzeug Validierung beschreiben)

Eine Testspezifikation für ein Werkzeug unterscheidet sich nicht notwendigerweise von einer, die Sie für die Verifikation des Produkte verwenden. Sie können also das gleiche Template verwenden. Es sollte enthalten:

• Eine eindeutige Referenz auf das Werkzeuges, das geprüft wird
• Die Testdaten
• Die Vorbedingungen für den Test (die Werkzeug Validierung)
• Das Vorgehen beispielsweise welche Daten in welcher Reihenfolge wo einzugeben sind
• Ggf. andere Werkzeuge, die Sie zum Validieren des Werkzeuges nutzen
• Die Nachbedingungen, d.h. die erwarteten Testergebnisse einschließlich von Pass-Fail-Kriterien

Als Premium-Mitglied im Auditgarant können Sie sich so ein Template direkt herunterladen.

Achten Sie darauf, dass Ihre Tests alle Anforderungen, die Sie unter 1. bzw. 2. formuliert haben, auch wirklich geprüft werden.

4. Werkzeug Validierung durchführen und dokumentieren

Der Testreport dokumentiert die Ausführung des Tests insbesondere die Testergebnisse. Er lässt die Beurteilung zu, ob gemäß der Testspezifikation validiert wurde und ob die tatsächlichen Ergebnisse den erwarteten entsprechen. Idealerweise enthält der Testreport auch die Entscheidung, ob das Werkzeug auf Grund der durchgeführten Tests als validiert gilt. Sonst benötigen Sie eine separates Dokument dafür.

Der Testreport enthält auch Meta-Informationen wie den Tester, das Datum und die Unterschrift.

Zusammenfassung

Sie benötigen somit folgende Dokumente bzw. Informationen

• Liste der Software-Werkzeuge
• Für jedes Software-Werkzeug eine Entscheidung, ob es validierungspflichtig ist
• Für jedes validierungspflichtige Werkzeug die Anforderungen, die das Werkzeug erfüllen muss
• Für jedes validierungspflichtige Werkzeug eine Testspezifikation und
• einen Testreport inklusive bzw. sowie
• eine Entscheidung, ob die Validierung des Werkzeugs erfolgreich war

Werfen Sie einen Blick in die ISO 80002-2, die die Validierung von Software für das QM-System und andere Prozesse beschreibt.

Weitere Gedanken und Tipps

1. Denken Sie an die Dokumentenlenkung! Packen Sie alles in ein Versionsverwaltungssystem oder auf eine CD. Wiederholen Sie diese Prüfung, wenn Sie Ihr Werkzeug updaten.
2. Sie müssen natürlich nicht über den Source-Code des Werkzeugs verfügen. Die Verifizierung/Validierung ist ein Blackbox-Testing.
3. Die Werkzeuge, die Sie zur Prüfung der Werkzeuge einsetzen, müssen Sie nicht selbst validieren/verifizieren (es sein denn, Sie setzen diese Werkzeuge auch zum Prüfen des eigentlichen Produkts/Prozesses ein). Andernfalls käme man ja in einen unendlichen Zyklus.

Bei den Audits, die ich selbst über mich ergehen ließ oder bei denen ich meine Kunden unterstützte, war es meist entscheidend, dass das Werkzeug überhaupt und sei es noch so minimal geprüft und dies auch dokumentiert wurde. Der Umfang dieser Prüfungen wurde nie bemängelt. Falls dies doch erfolgen sollte, empfehle ich, den Auditor auf die Wahrscheinlichkeiten aufmerksam zu machen, einen Fehler in einem Werkzeug und im eigenen Code zu finden. Er soll bitte seinen Auditschwerpunkt darauf zu legen, wo die Fehler am wahrscheinlichsten sind. Und das bleibt nun mal der eigene Code.

Tool-Validierung im Audit

Seit meiner Tätigkeit als Auditor bei einer benannten Stelle, habe ich viele Auditoren-Kollegen beobachten können, wie diese die Werkzeug-Validierung adressieren:

1. Die Validierung der Tools ist bei fast jedem Audit ein Thema!
2. Bei Software-Testwerkzeugen ziehen die Auditoren eher das Kapitel 7.5.6 der ISO 13485 als das Kapitel 7.6 (Messmittel) heran. Damit sind die Anforderungen etwas höher: Die Hersteller müssen nicht nur die Eignung eines Messmittels nachweisen, sondern eine explizite Software-Validierung durchführen.
3. Verstöße gegen diese Normkapitel werden meist als Minor-Nonconformity bewertet. D.h. das Zertifikat wird nicht ausgesetzt, aber der Hersteller muss nach einem Audit einen Plan vorlegen, wie und wann er diese Normabweichung beheben wird. Die Norm sagt dazu „ohne ungerechtfertigte Verzögerung“…

Kategorien: Beliebteste Beiträge, QM-Systeme & ISO 13485, Software & IEC 62304
Tags: Audit – Voraussetzung für ISO-13485-Zertifikat, Software-Qualitätssicherung bei Medizinprodukten, Validierung

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.