Validierung von Software Mehr Tests bei weniger Dokumentation

Anbieter zum Thema

FOBA Laser Marking + Engraving | ALLTEC Angewandte Laserlicht Technologie GmbH

CAQ AG Factory Systems

oxaion gmbh

sepp.med GmbH

Die FDA hat das neue Guidance-Dokument Computer Software Assurance zur Validierung von Software in Produktion und Qualitätssicherung von Medizinprodukten vorgestellt. Was ist das Besondere am neuen Dokument und wo liegen Vorteile für Hersteller? Eine Bestandsaufnahme.

Mitte September 2022 stellte die Food and Drug Administration (FDA) eine Vorabversion des Guidance-Dokuments „Computer Software Assurance for Production and Quality System Software“ vor, das Hersteller und Auditoren bei der Validierung von Software unterstützen soll, die in Produktion und Qualitätssicherung von Medizinprodukten eingesetzt wird. Vor dem Hintergrund zunehmend automatisierter Produktionsverfahren, moderner, agiler Methoden der Softwareentwicklung und der allgemeinen Bestrebungen zu mehr Digitalisierung soll dieses neue Guidance-Dokument dabei helfen, die Vorteile dieser Methoden auch bei der Validierung von Software in Produktion und Qualitätssicherung nutzbar zu machen und damit die Produktqualität und auch die Sicherheit für Patienten und Bediener zu erhöhen.

Basierend auf den „General Principles for Software Validation“ (GPSV) galten bislang grundsätzlich die gleichen Anforderungen und Empfehlungen für die Validierung von Software in Produktion und Qualitätssicherung wie für Software im oder als Medizinprodukt: Die Validierung sollte auf dokumentierten Anforderungen basieren, deren Erfüllung durch dokumentierte Tests nachzuweisen war. Je nach Einsatzzweck der Software, den entstehenden Risiken und deren Auswirkungen auf die Produktqualität und -sicherheit ließen zwar schon die bisherigen Empfehlungen unterschiedlich aufwändige Validierungsansätze zu, am Grundsatz des vorab dokumentierten Tests gegen eine dokumentierte Anforderung war jedoch nicht zu rütteln.

In der Praxis erwiesen sich die Vorgaben der GPSV als zu wenig flexibel, um mit angemessenem Aufwand die Validierung relevanter Funktionalitäten durchzuführen. Die geforderte feingranulare Dokumentation vor, während und nach einer Validierung führte im schlimmsten Fall dazu, dass nicht sicherheitsrelevante Funktionalitäten mit ähnlichem Aufwand validiert werden mussten wie sicherheitsrelevante Funktionalitäten. Dies führte zu ineffizientem Ressourceneinsatz, lenkte von erwünschten, kritischen Betrachtungen ab und erhöhte damit letztlich weder Produktqualität noch -sicherheit, sondern führte nur zu überbordender Dokumentation.

Mehr kritisches Denken bei Validierungen

Im neuen Guidance-Dokument stellt die FDA die Betrachtung des Risikos durch den Softwareeinsatz in den Mittelpunkt anstelle der Definition von Anforderungen. Sie ermuntert zu mehr kritischem Denken bei Validierungen, anstatt des Versuchs, „alles“ zu dokumentieren. Ausgehend von den ermittelten Prozessrisiken und deren möglichen Auswirkungen auf die Produktqualität und -sicherheit wird der geforderte Validierungsansatz und -aufwand bestimmt. Es werden konkrete Validierungsverfahren vorgeschlagen und Empfehlungen für die notwendige Dokumentation gegeben.

Die Computer Software Assurance (CSA) besteht aus vier Schritten:

• Feststellen der Zweckbestimmung (Intended Use)

• Abschätzung des Prozessrisikos und seiner Auswirkungen auf die Produktqualität und -sicherheit (Risk-Based Approach)

• Angemessene Validierungsaktivitäten (Appropriate Assurance Activities)

• Angemessene Dokumentation (Appropriate Record)

Beim Festlegen der Zweckbestimmung ist zunächst festzustellen, ob die Software tatsächlich in der Produktion oder Qualitätssicherung eingesetzt wird und inwieweit sie sich direkt auf die Prozess- bzw. Produktqualität auswirken kann. Bei Software, die in allgemeinen Geschäftsprozessen eingesetzt wird (z. B. E-Mail, Textverarbeitung), oder Software für die allgemeine Infrastruktur (z. B. Netzwerke) muss an dieser Stelle nichts weiter getan werden, als die Zweckbestimmung festzuhalten, sie muss nicht validiert werden. Weiter muss entschieden werden, ob die Software einen direkten Einfluss auf die Produktion oder die Qualitätssicherung (z. B. Prozessautomatisierung, Prüfungen, Erfassung oder Dokumentation relevanter Produktions- oder Qualitätssicherungsdaten) hat oder ob sie nur die Produktion/Qualitätssicherung unterstützt (z. B. Entwicklungswerkzeuge, Scripting, allgemeine Aufzeichnungen). In beiden Fällen muss eine Validierung durchgeführt werden.

Risiken müssen bewertet werden

Ist die Zweckbestimmung festgestellt, müssen aus den vorhersehbaren Fehlfunktionen die Risiken für den Prozess und im Weiteren die daraus entstehenden Risiken für die Sicherheit des Medizinprodukts bewertet werden. Die FDA bewertet eine Funktionalität mit einem hohen Prozessrisiko, wenn eine Nichterfüllung der Zweckbestimmung sich auf die Sicherheit des Medizinprodukts auswirkt. Ist die Auswirkung nicht sicherheitsrelevant, erfolgt die Bewertung als niedriges Risiko. Im Fokus der FDA stehen die hohen Risikobewertungen, da diese sicherheitsrelevant sind. Hersteller können darüber hinaus aber auch feingranularere Risikoklassifikationen vornehmen.

Anhand des festgestellten Risikos müssen nun geeignete Validierungsaktivitäten festgelegt werden. In aller Regel werden dies Tests sein, die sich – wieder abhängig vom Risiko – dahingehend unterscheiden, inwieweit sie fest vorgegeben definiert sind (Scripted Testing) oder mehr den Erfahrungshintergrund der Tester mit einbeziehen und nur grobe Vorgaben zum Test machen (Unscripted Testing).

Für Funktionalitäten mit hohem Risiko sind demnach Testverfahren zu wählen, die durch striktere Vorgaben (Scripted Testing) eine höhere Nachweisqualität und Nachvollziehbarkeit gewährleisten. Hierzu ist es notwendig, die durchzuführenden Testschritte vorher detailliert festzulegen und die Durchführung detailliert zu dokumentieren. Solche Testverfahren bedürfen einer aufwändigen Dokumentation und lassen wenig Raum für erfahrungsbasiertes Testen oder eine Anpassung des Tests während der Durchführung.

Für Funktionalitäten mit niedrigem Risiko können weniger fest vorgegebene Verfahren (Unscripted Testing) angewendet werden, die eine schnellere und effizientere Testdurchführung gewährleisten und die Erfahrung der Tester mit nutzen können. Hier lassen sich sehr schnell und auch sehr effizient Aussagen zur Erfüllung der Zweckbestimmung erreichen. Erwünschter Nebeneffekt solcher Verfahren ist u. a., dass auch Funktionalitäten gezielt intensiver getestet werden können, wenn sich während der Testdurchführung entsprechende Verdachtsmomente ergeben.

Die Ergebnisse der CSA müssen aufgezeichnet werden, um belegen zu können, dass die Zweckbestimmung erfüllt wird. Grundsätzlich müssen alle Schritte der CSA dokumentiert werden, wie sie hier vorgestellt wurden: die Zweckbestimmung, die Risikobetrachtung, die abgeleiteten Validierungsaktivitäten und schließlich deren Ergebnisse, insbesondere gefundene Abweichungen. Auch bei der Dokumentation skaliert der Umfang mit dem ermittelten Risiko. Die FDA empfiehlt, den Prozess der CSA in einer Verfahrensanweisung festzulegen, um ein einheitliches Rahmenwerk für das Vorgehen bei einer Validierung zu schaffen.

Hin zu mehr Agilität

Die im neuen Guidance-Dokument skizzierte Computer Software Assurance stellt einen Paradigmenwechsel dar, weg von Dokumentation um jeden Preis, hin zu mehr Agilität und iterativen Verfahren, bei gleichzeitiger Konzentration auf das Thema Sicherheit. Sie erleichtert es den Herstellern von Medizinprodukten, schneller innovative Verfahren in Produktion und Qualitätssicherung zu etablieren und gleichzeitig die Prozessqualität zu steigern. Durch die Konzentration auf das Wesentliche – nämlich die Sicherheit des produzierten Medizinproduktes – wird Raum für eine intensivere Begutachtung kritischer Prozesskomponenten geschaffen.

Weitere Artikel zur Führung von Medizintechnik-Unternehmen finden Sie in unserem Themenkanal Management.

* Der Autor: Karl-Heinz Kühnlein ist als Senior IT-Projektleiter im Bereich Medical Engineering bei der Sepp.Med GmbH tätig.

(ID:49019389)