Toolvalidierung gemäß DIN EN ISO 13485

Wenn Sie nach DIN EN ISO 13485 zertifiziert sind oder genau das Ihr Ziel ist, sind Sie bestimmt schon einmal über die Toolvalidierung gestolpert. Vielleicht kann dieser Artikel Sie auffangen und etwas Licht ins Dunkle bringen.

Warum benötigen wir eine Toolvalidierung?

Der Hauptgrund und vermutlich auch der Grund, weshalb Sie auf diesen Artikel gestoßen sind, sind die Kapitel 4.1.6, 4.2.5 und 7.6 der DIN EN ISO 13485. Hier wird gefordert, dass Computersoftware-Anwendungen im Rahmen des Qualitätsmanagementsystems validiert werden. Der Fokus liegt hier auf solch einer Computer Software, welche für die Überwachung und Messung von Anforderungen eingesetzt wird. Doch nicht alle Tools müssen validiert werden. Die Notwendigkeit liegt vor allem bei Tools, welche einen Einfluss auf die Prozesse, die Arbeitssicherheit oder die Produktsicherheit nehmen. Wichtig ist es auch, die Entdeckungswahrscheinlichkeit eines Fehlers des Tools mit einzubeziehen.

Man spricht hier von einem risikobasierten Ansatz. Je höher also der Einfluss eines Tools auf die eben genannten Punkte ist und je niedriger die Entdeckungswahrscheinlichkeit eines Fehlers ist, umso ausführlicher wird die Validierung sein. In einer Prozessbeschreibung kann man beispielsweise festlegen, welche Dokumente je nach Kritikalität und Einsatzgebiet des Tools zu erstellen sind.

Wichtige Begrifflichkeiten für die Toolvalidierung

Die folgenden Bezeichnungen sind die wichtigsten Parameter für eine Toolvalidierung und die Festlegung des Validierungsumfangs. Mit Hilfe dieser Kenngrößen werden der Einfluss des Tools (Tool Impact, TI), die Fehler-Entdeckungswahrscheinlichkeit (Tool Error Detection, TD) und das daraus resultierende Tool-Vertrauenslevel (Tool Confidence Level, TCL) bestimmt. Das folgende Vorgehen dient als Beispiel und ist eine schlanke Möglichkeit, den Umfang der Toolvalidierung zu ermitteln und auch später noch im Audit nachvollziehen zu können.

Tool Impact (TI)

Der Tool Impact beschreibt den Einfluss des Tools auf die Sicherheit des Produkts/ die Arbeitssicherheit/ die Prozesse und lässt sich in TI-0 (Tool hat keinen Einfluss auf die Sicherheit) und TI-1 (Tool kann die Sicherheit des Produkts/ der Arbeitssicherheit/ der Prozesse gefährden) unterteilen.

Egal in welche Ebene das Tool eingeteilt wird: es sollte immer eine kurze Begründung hierfür erfolgen.

Tool Error Detection (TD)

Die Tool Error Detection dient der Einschätzung der Wahrscheinlichkeit, einen Fehler des Tools zu erkennen. Man kann die Tool Error Detection in drei Stufen festsetzen. Diese können TD-0 (hohe Entdeckungswahrscheinlichkeit), TD-1 (Toolfehler wird vermutlich erkannt) und TD-2 (Toolfehler wird vermutlich nicht erkannt) sein.

Auch hier ist eine kurze Begründung für die Einteilung notwendig.

Tool Confidence Level (TCL)

Das Tool Confidence Level ergibt sich aus den oben beschriebenen Punkten TI und TD. Mit Hilfe der folgenden Matrix kann man das Tool in das entsprechende Confidence Level einstufen. Sie ermöglicht eine schnelle Festlegung aufgrund der vorher getroffenen Einschätzungen.

Mit Hilfe des obig ermittelten Tool Confidence Level können aus der nächsten Matrix die sich ergebenden Folge-Aktivitäten je nach Einstufung abgelesen werden. Die Tabelle zeigt beispielhaft weitere Dokumente, die man im Rahmen einer Toolvalidierung erstellen kann/muss. Es wird deutlich, dass mit höherem TCL auch der Umfang der notwendigen Aktivitäten zunimmt. Dies spiegelt noch einmal den risikobasierten Ansatz der Toolvalidierung wider.

Unterschiedlicher Validierungsumfang je nach TCL

Unsere Empfehlung ist es, für alle zu validierenden Tools stets einen Validierungsplan und -bericht zu erstellen!

Im Validierungsplan werden zunächst grundsätzliche Informationen zum Tool, dessen Einsatzzweck und bspw. eine Begründung für die Auswahl dieses Tools geliefert. Anschließend sollten die Faktoren TI, TD und TCL klassifiziert werden, sodass der notwendige Validierungsumfang festgelegt werden kann.

Der Validierungsbericht zeigt das Ergebnis der Validierung sowie die Planung eventueller Folgeaktivitäten (z.B. Revalidierung o.Ä.)

Bei einem höheren TCL (in unserem Falle ab TCL-1) birgt das Tool mehr Risiken und die Validierung muss daher ausführlicher gestaltet werden. Zu Validierungsplan und -bericht kommen dann – je nach Klassifizierung innerhalb des Unternehmens – Testspezifikation und -bericht hinzu. Hier werden verschiedene Testfälle, die die alle Anforderungen an das Tool abdecken, definiert und überprüft.

Bei einem noch höheren TCL (hier bei TCL-2) werden zusätzliche Dokumente gefordert. Das sind z.B. eine Installationsqualifikation (beschreibt das Vorgehen zur Installation des Tools) sowie eine FMEA (Fehlermöglichkeits- und Einflussanalyse, in der mögliche Fehler, deren Einfluss und entsprechende Maßnahmen aufgezeigt werden).

Haben Sie noch Fragen?

Stehen Sie gerade vor einer Toolvalidierung und brauchen Unterstützung? MEDtech steht Ihnen als QM-Partner zur Seite und hilft Ihnen im Audit mit einer vollständigen und normkonformen Dokumentation zu überzeugen. Kommen Sie gerne auf uns zu!

Viele Grüße,

Eva Maier

Kontaktieren Sie uns!

Autor

  • Eva Maier

    Eva hat biomedizinische Technik (B. Eng.) an der HAW Landshut studiert. Während ihres Praxissemesters hat sie begonnen in der Produktentwicklung und im Qualitätsmanagement Erfahrung zu sammeln und ist seit November 2021 Teil des MEDtech Teams und arbeitet vor allem im Bereich der Softwareentwicklung.

Auch interessant:

Wenn Software auf Qualität (s-Metriken) trifft – Teil 2

quality
SW-Metriken aus Sicht des QMS Warum sollen Software Qualitätsmetriken im Produktlebenszyklus eingesetzt werden? Eine Softwaremetrik bildet eine Software-Einheit in einen Zahlenwert ab. Der Zahlenwert steht für ein Maß für die innere Qualität von Software. Software Code Metriken werden eingesetzt, um in möglichst kurzer Zeit Eigenschaften von Software quantifizieren zu können.…
Getagged mit: , , , , , , , , , ,