ISO 80002-2: Validierung von Prozess-Software

Auf den ersten Blick mag verwirren, dass der Technical Report unter Software-Validierung nicht die Validierung der Medizinprodukt-Software selbst versteht. Auch ist der Begriff der Validierung breiter gefasst als gewöhnlich.

Anwendungsbereich: Wann Sie die ISO 80002-2 beachten sollten

Der „Technical Report“ behandelt im Gegensatz zur IEC 82304 nicht die Validierung von Software, die Teil eines Medizinprodukts ist oder selbst ein Medizinprodukt darstellt (standalone Software). Vielmehr formuliert die ISO 80002-2, wie Software zu validieren ist, die bei Prozessen im Anwendungsbereich des Qualitätsmanagementsystems eingesetzt wird. Allerdings verwendet der „Technical Report“ den Begriff „Validierung“ in einem sehr breiten Sinn (siehe „Kritik“).

Beispiele

Beispiele für solche automatisierte Prozesse und Aktivitäten sind

• Entwicklung (z.B. Build, Code-Analyse)
• Automatisiertes Testing
• Produktion
• Verpackung
• Beschriftung
• Versand
• Umgang mit Beschwerden

In den Anwendungsbereich dieses „Technical Reports“ fällt jede Software, die im Rahmen des QM-Systems, in der Produktion oder bei der Erbringung von Dienstleistungen genutzt wird. Das kann durchaus auch eine ERP-Software wie SAP sein.

Regulatorische Anforderungen

Zusammenfassung

Wenn ein Software-Fehler eine Auswirkung auf die Qualität eines Medizinprodukts oder auf die Wirksamkeit des Qualitätsmanagementsystems hat, fällt sie in den Anwendungsbericht der Norm – es sei denn die Software ist selbst das Medizinprodukt oder ein Teil davon.

Regulatorischer Rahmen: Ist die Norm verpflichtend?

Die ISO 80002-2 ist keine harmonisierte Norm und wird es als „Technical Report“ auch nicht werden. Die ISO 80002-2 ist nicht verpflichtend. Verstehen Sie diesen „Technical Report“ aber als eine Beschreibung von Best Practices und als Richtlinie für das Validieren Ihrer Prozess-Software und für die Computer System Validation.

Ihr Auditor wird keine Abweichung gegen die ISO 80002-2 monieren können, aber eine gegen die ISO 13485:2016, insbesondere gegen das Kapitel 4.1.6 zur „Software Validation“.

Was sagt die ISO 80002-2 in wenigen Worten?

Ganzen Lebenszyklus betrachten

Die ISO 80002-2 möchte auf den kompletten Software-Lebenszyklus Anwendung finden – von der Festlegung der Zweckbestimmung über die Entwicklung, das Testen bis zur Wartung und der Außerbetriebnahme.

Risikobasiert arbeiten

Sie appelliert an das kritische Denken und daran, die Aufwände an das Risiko durch eine fehlerhafte Software und damit einen fehlerhaften Prozess anzupassen. Die FDA würde das eine „risk-based approach“ nennen. Das bedingt ein professionelles Risikomanagement vergleichbar den Anforderungen der ISO 14971.

Interessanterweise weitet die ISO 80002-2 den Begriff Risiko aus und bezieht nicht nur Risiken für Menschen mit ein, sondern auch regulatorische Risiken (z.B. für das QM-System) und Umweltrisiken. Dabei ist unter Umwelt nicht die ökologische Umwelt gemeint, sondern das Umfeld, in der die Software arbeitet, sowohl das physikalische als auch das virtuelle.

Professionell Software entwickeln

Abhängig vom Risiko sollen die Hersteller die Best Practices auf die konstruktive und analytische Qualitätssicherung von Software wie das Erheben von Anforderungen, das Entwerfen einer Architektur und das Testen der Software anwenden. Diese Anforderungen erinnern zumindest teilweise an die der IEC 62304.

Von der ISO 80002-2 geforderte Aktivitäten

Initiale Entwicklung

Die ISO 80002-2 stellt folgende Anforderungen

1. Prozessanforderungen festlegen
2. Risiken durch Prozessfehler analysieren. Es geht um Risiken für Menschen, die „regulatory compliance“ und die „Umwelt“(!)
3. Erste Version des Validierungsplans erstellen
4. Zweckbestimmung der Software festlegen einschließlich:
   1. Wer nutzt die Software wann, wie häufig, weshalb, wo und warum?
   2. Was sind die Nutzungsanforderungen?
   3. Was sind die Software-Anforderungen?
   4. Wo sind die Grenzen der Software, mit welchen Systemen und Prozessen interagiert sie?
   5. Was sind die Risiken durch Software-Fehler?
5. Software entwickeln, testen und deployen.
6. Im Rahmen des letzten Schritts sollen die Hersteller auch die Risiken durch Software-Fehler analysieren und den Validierungsplan überarbeiten. Auch die Software-Validierung selbst und den Validierungsbericht sieht die ISO 80002-2 als Teil des Schritts „Software entwickeln, testen und deployen“.
7. Software freigeben

Wartungsphase

In der Wartungsphase sollen die Entwickler bzw. Hersteller

• Fehler beheben
• Maßnahmen ergreifen, um die Leistungsfähigkeit, Wartbarkeit und andere „software attributes“ zu verbessern. Möglicherweise meint sie damit Software-Qualitätseigenschaften gemäß ISO 25010.
• Anpassungen durchführen, die durch die Umgebung wie Betriebssystemänderungen bedingt sind
• Änderungen aufgrund von Prozessänderungen durchführen.

Wenn solche Änderungen anfallen, fordert die ISO 80002-2 die Hersteller auf, die Risiken erneut zu bewerten, ebenso die (unveränderte) Wirksamkeit von Maßnahmen zur Risikokontrolle.

Dokumentation

Hersteller sollen all die oben genannten Tätigkeiten nicht nur durchführen, sondern auch dokumentieren. Weil der Technical Report auch die Wartungsphase adressiert, muss diese Dokumentation entsprechend aktualisiert werden.

Kritik

Sehr unkonkret im Hauptteil

Wer hofft, dass die ISO 80002-2 konkrete Hinweise für die Software-Validierung gibt, wird im Hauptteil enttäuscht. Die ISO TR 80002-2 gibt kaum Hinweise zu Methoden (z.B. Blackbox-Testverfahren) oder gar Werkzeugen. Vielmehr benennt sie notwendige Aktivitäten innerhalb eines wasserfallartigen Prozesses – allerdings sehr abstrakt und ohne konkrete Handlungsleitung.

Gute Toolbox im Anhang

Hingegen ist die „Toolbox“ im Anhang dahingehend wohltuend, dass sie die Aktivitäten konkretisiert und beispielsweise von Stresstests, „Output forcing testing“ und anderen Methoden der Software-Qualitätssicherung spricht.

Dieser Anhang wirkt, als sei er von einer anderen Personengruppe als der „Hauptteil“ geschrieben worden.

Begriffsverwirrungen

Die „Norm“ verwendet manche Begriffe nicht ganz im Einklang mit üblichen Definitionen. Das betrifft weit mehr als nur den Begriff Software-Validierung – Gegenstand dieser Norm.

Sie verwendet diesen Begriff nicht definitionsgemäß, sondern als Synonym zu allen Maßnahmen der analytischen und konstruktiven Software-Qualitätssicherung. Das wird zu unnötiger Verwirrung und zu Diskussionen über den Unterschied von Validierung und Verifizierung führen.

Frage nach Notwendigkeit

Nach dem Lesen bleibt unklar, wann welche Aktivitäten der Toolbox notwendig sind und wann nicht. Klar, man soll risikobasiert entscheiden. Aber entweder man gibt konkrete Handlungsleitungen oder man lässt es bleiben.

Manchem Leser bleiben möglicherweise folgende Fragen bezüglich der Notwendigkeit der ISO 80002-2 unbeantwortet:

• Weshalb fordert man nicht einfach, auch für Prozesssoftware IEC 62304-konform zu entwickeln? Die FDA unterscheidet Software in Medizinprodukten und Prozess-Software nicht.
• Wenn man in der Toolbox Methoden nennt, weshalb erfindet man das Rad neu und referenziert nicht einfach die ISO 15504 (SPICE) und nennt Reifegrade, die abhängig von Risiken zu erreichen sind? Apropos: Es gibt ein Medical SPICE.

Fazit

Die ISO 80002-2 erreicht die Güte, insbesondere die konzeptionelle Integrität anderer Normen, wahrscheinlich nicht, was angesichts des geforderten „critical thinkings“ auffällt. Der Mehrwert zu einer AAMI TIR 36 ist fraglich. Dennoch liefert dieser „Technical Report“ insbesondere mit der Toolbox und den umfangreichen Beispielen im Anhang wertvolle Gedankenanstöße.