Prof. Dr. Christian Johner

Autor: Prof. Dr. Christian Johner

Inhaber der Johner Institut GmbH

Werkzeug Validierung bei der Entwicklung von Medizinprodukten

Freitag 15. Januar 2016

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.

Und falls die Antwort ja wäre, müsste man dann die zu dieser Validierung bzw. Verifizierung eingesetzten Werkzeuge selbst wieder prüfen? Da würde sich ja ein Teufelskreis auftun.

Dieser Artikel gibt einen Überblick über die regulatorischen Anforderungen und gibt Praxistipps zur Werkzeug Validierung.

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

Weiterführende Informationen

Die Werkzeug Validierung ist ein Teilaspekt der Validierung von Software, die im Rahmen des QM-Systems eingesetzt wird. Klicken Sie hier, um mehr zur Computerized Systems Validation zu lesen.

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

Werkzeug Validierung

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 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: „Bei Verwendung von Computersoftware zur Erfassung und Messung festgelegter Anforderungen muss die Eignung dieser Software für die beabsichtigte Anwendung bestätigt werden. Dies muss vor dem Erstgebrauch vorgenommen und wenn notwendig auch später bestätigt werden.“

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.3: „Prozess-Messwerkzeuge“

Weiter lesen wir in Kapitel 8.2.3 „Erfassung und Messung von Prozessen“: „Die Organisation muss geeignete Methoden zur Erfassung und, falls zutreffend, 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.

Beachten Sie, dass diese Forderung mit der ISO 13485:2016 in das Kapitel 4.1.6 verschoben wurde.

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

Im Kapitel 7.5.2.1 zu den „allgemeine Anforderungen an die Validierung der Prozesse zur Produktion und zur Dienstleistungserbringung“ finden Sie noch folgende Forderung: „Die Organisation muss dokumentierte Verfahren für die Validierung der Anwendung der Computersoftware (und von Veränderungen an solcher Software und/oder ihrer Anwendung) festlegen, die bei Tätigkeiten in der Produktion und Dienstleistungserbringung eingesetzt wird und die die Fähigkeit des Produkts, festgelegte Anforderungen zu erfüllen, beeinflussen kann. Solche Softwareanwendungen müssen vor dem ersten Einsatz validiert werden.“

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.

Beachten Sie, dass diese Forderung mit der ISO 13485:2016 in das Kapitel 4.1.6 verschoben wurde.

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.

Weiterführende Informationen

Klicken Sie auf diesen Link zum 21 CFR part 11.

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

 

Prof. Dr. Christian Johner
Sind Sie unsicher, ob die Validierung Ihrer Software-Werkzeuge im Audit bestand haben wird? Haben Sie das Gefühl, viel zu viel Aufwände dafür betreiben zu müssen? Professor Johner und sein Team helfen gerne! Nehmen Sie Kontakt auf!

Kategorien: Beliebteste Beiträge, QM-Systeme & ISO 13485, Software & IEC 62304
Tags: , ,

10 Kommentare über “Werkzeug Validierung bei der Entwicklung von Medizinprodukten”

  1. Christian Johner schrieb:

    Lieber Christian,

    ich habe eben Deinen Blog gelesen. Mich nervt der Zwang zur Validierung von Testwerkzeugen nicht. Es beschwert sich ja auch keiner, dass Messwerkzeuge kalibriert werden müssen. Und ich halte beides für vergleichbar. Gut, ich gebe zu, es gibt sicherlich Trivialfälle, wie eben Dein JUnit.

    Aber häufig ist es eben nicht dieser Fall. Mittlerweile werden hochkomplexe Werkzeuge für Test eingesetzt. Einer meiner Kunden führt Komponententests aus, bei dem Test auf der Basis von LabView geschrieben werden, ein anderer verwendet Open Source-Tools zur Unit-Tests von VHDL-Code, ein weiter verwendet selbst geschriebene Simulatoren in Kombination mit einen kommerziellen Testwerkzeug. Sollen alle unterstellen, dass die Werkzeuge schon tun, was wir von ihnen erwarten?

    Besser nicht. Vor zwei Wochen ist es immerhin schon im dritten Anlauf gelungen, ein Testwerkzeug zu validieren. Die beiden vorherigen Male schlugen fehl, weil der Anwender falsche Vorstellungen darüber hatte, wie sich das Werkzeug verhielt bzw. verhalten sollte.

    Als Fazit: Ja, manchmal ist es lästig. Trotzdem sollten wir keinesfalls auf die Validierung verzichten.

    Liebe Grüße

    Bernhard

  2. Jochen schrieb:

    Hallo Christian,

    besonders ist der Markt an ALM Tools so unheimlich groß. Wenn man die Auswahl an Tools für die komplette Toolkette anschaut, noch riesiger. Da kommt man aus der Evaluierung, wenn man alles abdecken will, fast gar nicht mehr raus.

    Danke für den ausführlichen Artikel!

    LG
    Jochen

  3. Udo Klinger schrieb:

    Hallo Herr Johner,

    warum müssen Ihrer Meinung nach Versionsverwaltungssysteme nicht validiert werden? Ich würde diese in die Kat. „Werkzeuge, die einen Einfluss auf die Güte von Produkten oder Dienstleistungen haben“ einstufen. Beispielsweise werden einerseits (typischerweise) Änderungen protokolliert (Check in Comments) andererseits Baselines gezogen (für alle Releases) oder auch die vollständige Rückverfolgbarkeit / Wiederherstellung von alten Konfigurationen gewährleistet.

    Liebe Grüße
    Udo Klinger

  4. Prof. Dr. Christian Johner schrieb:

    Lieber Herr Klinger,

    der Beitrag war an der Stelle missverständlich: Es geht in dem Kapitel um Messwerkzeuge. Üblicherweise ist ein Versionsverwaltungssystem kein Messwerkzeug.

    Ein Versionsverwaltungssystem ist aber ein Prozesswerkzeug. Da man sich bei der Konfigurationsverwaltung eines Software-Systems sich darauf verlassen muss, dass es funktioniert, wäre es als Prozesswerkzeug zu validieren.

    Ich habe Dank Ihrer Anregung dies im Artikel überarbeiten können. Danke für Ihre hervorragende Frage!
    Beste Grüße
    Christian Johner

  5. Walter Kallinger schrieb:

    würden Sie C++ Compiler als validierungspflichtig einstufen?

  6. Prof. Dr. Christian Johner schrieb:

    Den Compiler nicht notwendigerweise, aber die Compiler-Settings würde ich prüfen. Die sollten auch unter Versionskontrolle sein.

  7. Wolf Kürschner schrieb:

    Moin Moin!

    Zunächst möchte ich mich für diese zahlreichen, sehr ausführlichen und informativen Blog-Beiträge bedanken!

    Und dann habe ich noch eine kurze Frage bezüglich Softwarevalidierung (13485:2016 betreffend). Für z.B. Tabellenkalkulationen kann ich mir da ja was einfallen lassen, die Mängel von Excel sind ja bekannt und gut dokumentiert.
    Aber wie sieht es z.B. mit der Auslesesoftware von (kalibrierten) Dataloggern aus? Wir haben einige Geräte, die ein LCD besitzen und Temperatur- und Luftfeuchte anzeigen (aktuell sowie Min/Max). Da kann ich regelmäßig mir mal Werte notieren und nach dem Auslesen der Logger einen Vergleich vornehmen. Aber es gibt auch Modelle ohne Interface, nur mit USB-Anschluß. Was kann man da machen? Oder reicht ein Zertifikat vom Softwarehersteller, solange man die Spezifikationen an die Computerhardware einhält? (Gibt es überhaupt Loggerhersteller mit solchen Zertifikaten?)

    Liebe Grüße
    W. Kürschner

  8. Prof. Dr. Christian Johner schrieb:

    Sie müssen an die Produkte Anforderungen stellen und deren Erfüllung prüfen. Das macht man i.d.R mit Tests. Natürlich können Tests nicht die Korrektheit beweisen. Das ist auch nicht verlangt. Wenn Sie bei dem Logger wie beschrieben vorgehen, ist das gut. Schauen Sie nur, dass alle Anforderungen and den Logger geprüft werden, die relevant sind — z.B. Performanz.

    Software ohne jede Schnittstelle kenne ich nicht. Bei einem USB-Anschluss liegt eine Schnittstelle vor — es ist ja ein Bussystem. Was über diesen Bus ausgetauscht werden soll, gilt es zu spezifizieren und verifizieren. Lassen Sie die Kirche im Dorf und agieren Sie „risk based“.

    Zertifikate von Herstellern benötigen Sie nicht.

  9. Philipp Ott schrieb:

    Hallo Herr Johner,

    hat sich eigentlich durch die ISO 13485:2016 die Tool-Validierung nicht vereinfacht? Das Kapitel 4.1.6 spricht ja von einer risikobasierte Validierung. Der Grad der Validierung ist mir noch nicht ganz klar. Vielleicht können Sie mich ein bisschen aufschlauen?

    Liebe Grüße,
    Philipp Ott

  10. Prof. Dr. Christian Johner schrieb:

    Lieber Herr Ott,

    in der Tat dürfen und sollten die Aufwände für die Validierung risikobasiert sein. Validierung ist allerdings nicht nur als Prüfung zu verstehen, ob Anforderungen erfüllt sind. Validierung ist hier im breiteren Kontext zu verstehen, die ggf. den ganzen Software-Lebenszyklus umfasst.

    Im Artikel zur CSV finden Sie weitere Details. Zudem arbeite ich gerade daran, eine mehrteilige Serie dazu für den Auditgarant zu entwickeln.

    Weitere Infos gerne auch vorab per E-Mail.

    Danke für Ihre wichtige Anmerkung, herzliche Grüße und beste Grüße
    Christian Johner

Kommentar schreiben