19. Januar 2023
Im September 2022 veröffentlichte die FDA Entwurf der Leitlinien zur Computer Systems Assurance (CSA) Klärung der Softwarevalidierungsanforderungen für Hersteller medizinischer Geräte. Die Leitlinien reduzieren den Validierungsaufwand für Hersteller erheblich und schaffen ein größeres Potenzial für eine beschleunigte Einführung digitaler Technologien.
Die CSA-Leitlinien basieren auf 21 CFR Teil 820, die Software für Produktions- und Qualitätssicherungssysteme umfassend regelt. Aus diesem Grund untersuchen wir, wie sich CSA von der Computer Software Validation (CSV) unterscheidet und was in den neuen Richtlinien steht.
Was ist Computer Software Assurance (CSA)?
Laut FDA-Definition ist CSA „ein risikobasierter Ansatz zur Schaffung und Aufrechterhaltung des Vertrauens, dass Software für den vorgesehenen Gebrauch geeignet ist.“
Darüber hinaus berücksichtigt der CSA-Ansatz Risiken für die Gerätesicherheit und/oder -qualität, wenn die Software nicht wie vorgesehen funktioniert. Daher basieren das Sicherheitsniveau und die damit verbundenen Aktivitäten zur Schaffung von Vertrauen in die Software auf diesen Risiken. am wenigsten belastender Ansatz, stellen Assurance-Aktivitäten die Mindestmenge an Informationen dar, die zur Bewältigung des Risikos erforderlich ist.
Letztendlich zielt der CSA-Leitfaden für Qualitätssysteme darauf ab, unnötige Hindernisse abzubauen, die die Vermarktung medizinischer Geräte verzögern würden, um sicherzustellen, dass Patienten rechtzeitig auf die Produkte zugreifen können.
Wo die neue Anleitung hineinpasst
Derzeit Qualitätssystemverordnung 21 CFR 820.70(i) Hersteller müssen die im Rahmen ihrer Produktion oder ihres Qualitätssystems eingesetzte Software validieren. Dazu gehört auch Software für Qualitätsmanagementsysteme (QMS).
Seit der Veröffentlichung von 21 CFR 820.70(i) hat die FDA an verschiedenen Leitlinien zur Softwarevalidierung mitgewirkt. Dazu gehören die Allgemeine Grundsätze der Softwarevalidierung (GPSV) und der International Society for Pharmaceutical Engineering (ISPE) Risikobasierter Ansatz für konforme GxP-Computersysteme (GAMP 5).
Die CSA-Richtlinie ergänzt die GPSV und ersetzt lediglich Abschnitt 6. Sie basiert auf der GAMP 5-Rahmenwerk, das die unterschiedlichen Risikograde anerkennt, die mit verschiedenen Arten von Software verbunden sind.
Die CSA-Leitlinien zum Qualitätssystemansatz verstehen
Seit Jahrzehnten wenden Hersteller die Prinzipien der Softwarevalidierung auf jede verwendete Software an, unabhängig vom Sicherheitsrisiko. Die GPSV empfiehlt jedoch eine Software-Qualitätssicherung, um Fehler in der Softwareentwicklung zu vermeiden. Dazu gehört ein risikobasierter Ansatz zum Nachweis der korrekten Funktionsweise der Software.
Die neue CSA-Leitlinie zur Softwaresicherung enthält Empfehlungen für Computer und Software, die in Produktions- oder Qualitätssystemen eingesetzt werden. Daher ist die Leitlinie auch auf QMS-Software anwendbar.
Glücklicherweise bietet CSA mehr Flexibilität bei der Einhaltung von 21 CFR 820.70(i), indem es Herstellern ermöglicht, Aktivitäten wie die folgenden zu nutzen:
- Risikobasiertes Testen – Analyse des Risikos basierend auf Softwarekomplexität, Geschäftskritikalität, Nutzungshäufigkeit und wahrscheinlichen Fehlerbereichen
- Tests ohne Skript –weniger zeitaufwendig als herkömmliche Testskripte; reserviert für Funktionen und Systeme mit geringem bis mittlerem Risiko
- Kontinuierliche Leistungsüberwachung – der Prozess der kontinuierlichen Bewertung, wie Software den Erwartungen entspricht
- Datenüberwachung – klare Identifizierung, wie die Datenqualität die festgelegten Ziele erreichen wird
- Validierungsaktivitäten – wie von anderen Parteien, wie z. B. Softwareanbietern, ausgefüllt
Das CSA-Leitfaden-Risikorahmenwerk
Das CSA-Risikorahmenwerk konzentriert sich auf vier verschiedene Schritte:
- Identifizierung der beabsichtigten Verwendung der Softwarefunktion
- Festlegung des risikobasierten Ansatzes
- Festlegen der entsprechenden durchzuführenden Sicherungsaktivitäten
- Erstellen des entsprechenden Datensatzes, der dokumentiert, WAS
1. Bestimmung des Verwendungszwecks
21 CFR 820.70(i) verpflichtet Hersteller, Software, die Teil von Produktions- oder Qualitätssystemen ist, für ihren vorgesehenen Einsatzzweck zu validieren. Dazu gehört Software zur Automatisierung von Qualitätsprozessen, zur Erfassung und Verarbeitung von Qualitätsdaten oder zur Führung von Qualitätsaufzeichnungen.
Manchmal verfügt Software in Produktions- oder Qualitätssystemen über mehrere Merkmale, Funktionen und Vorgänge mit einem oder mehreren Verwendungszwecken. In diesem Fall empfiehlt die FDA, den Verwendungszweck jedes Merkmals und jeder Funktion zu prüfen, um die entsprechenden Sicherungsmaßnahmen festzulegen.
Beispielsweise wird handelsübliche Software (COTS) zur Dokumentation von Zeit- und Temperaturdaten eines Aushärtungsprozesses verwendet. Da die Software die Führung von Qualitätsaufzeichnungen unterstützt, sind zur Aufrechterhaltung eines validierten Zustands möglicherweise keine weiteren Sicherungsmaßnahmen erforderlich als:
- Was der Entwickler bereits in Sachen Validierung getan hat
- Durchführung einer Lieferantenbewertung
- Softwareinstallation und -konfiguration
Wenn hingegen eine benutzerdefinierte Formel Statistiken zur Überwachung des Aushärtungsprozesses berechnet, ist möglicherweise eine zusätzliche Validierung erforderlich.
2. Festlegung des risikobasierten Ansatzes
Nachdem festgestellt wurde, dass Software Teil von Produktions- oder Qualitätssystem ist, folgt im nächsten Schritt eine risikobasierte Analyse zur Festlegung der Sicherungsmaßnahmen. Dieser risikobasierte Ansatz umfasst:
- Identifizierung vernünftigerweise vorhersehbarer Softwarefehler
- Feststellen, ob jeder Fehler ein hohes Prozessrisiko darstellt
- Auswahl und Durchführung von Sicherungsmaßnahmen, die dem jeweiligen Risiko für Medizinprodukte oder Prozesse angemessen sind
Darüber hinaus sollten bei der risikobasierten Analyse Faktoren berücksichtigt werden, die die Funktionsfähigkeit der Software beeinträchtigen können. Dazu gehören:
- Systemkonfiguration oder -verwaltung
- Systemsicherheit
- Datenspeicherung und -übertragung
- Bedienungsfehler
Bei vernünftigerweise vorhersehbaren Ausfällen sollte diese Analyse das daraus resultierende Risiko untersuchen, einschließlich (1) des Prozessrisikos und (2) des Medizinprodukterisikos. Die FDA definiert diese Risiken wie folgt:
- Prozessrisiko: Potenzielle Beeinträchtigung der Produktion oder des Qualitätssystems
- Risiken für Medizinprodukte: Mögliche Schädigung des Patienten
Ein hohes Prozessrisiko liegt vor, wenn ein Softwarefehler zu einem Qualitätsproblem führen kann, das das Risiko für Medizinprodukte erhöhen könnte. Stellt ein Softwarefehler hingegen kein Risiko für Medizinprodukte dar, gilt er nicht als hohes Prozessrisiko. Daher sind QMS-Funktionen wie Beschwerdemanagement, Änderungskontrolle und Dokumentenmanagement gelten nicht als risikoreich.
In den FDA-Richtlinien heißt es, die Behörde sei „vor allem mit der Überprüfung und Absicherung jener Softwaremerkmale, -funktionen und -vorgänge befasst, die ein hohes Prozessrisiko darstellen, da ein Fehler auch ein Risiko für das Medizinprodukt darstellt.“
In der Praxis verwenden viele Hersteller Risikomanagement Tools, die eine Reihe mittlerer Risiken abdecken. Da die FDA in diesem Fall nur zwischen hohem und nicht hohem Risiko differenziert, werden mittlere Risiken ebenfalls als nicht hohe Risiken eingestuft. Für Risiken mit hohem Prozessrisiko ist der nächste logische Schritt die Bewertung des Medizinproduktrisikos.
3. Bestimmung der geeigneten Prüfungsaktivitäten
Die CSA-Richtlinien empfehlen, dass bei Qualitätsproblemen mit hohem Prozessrisiko die Sicherungsmaßnahmen mit dem Risiko für Medizinprodukte korrelieren sollten. Wenn ein Qualitätsproblem hingegen kein hohes Prozessrisiko darstellt, sollte das Niveau der Sicherungsmaßnahmen dem Prozessrisiko entsprechen.
Die FDA nutzt beispielsweise eine Funktion zur Aufzeichnung von Prozessdaten für die Prüfung. Dies stellt ein geringeres Prozessrisiko dar. Das Risiko ist jedoch höher, wenn Prozessdaten dazu beitragen, die Produktakzeptanz vor der Prüfung zu bestimmen.
Softwarefunktionen mit hohem Risiko erfordern typischerweise strengere Sicherungsmaßnahmen wie skriptbasierte Tests oder eingeschränkte skriptbasierte Tests. Ein geringes Prozessrisiko hingegen bedeutet typischerweise die Generierung weniger objektiver Nachweise. Zu den Sicherungsmaßnahmen mit geringem Prozessrisiko können beispielsweise nicht skriptbasierte Testmethoden (wie Ad-hoc-Tests, Fehlerraten oder explorative Tests) gehören.
Zusätzlich zu den Softwarefunktionen sollten Gerätehersteller auch andere Kontrollen innerhalb des Qualitätssystems überprüfen und dabei Maßnahmen wie die folgenden nutzen:
- Produktionskontrollaktivitäten, einschließlich Verfahren zur Datenintegrität
- Lieferantenauswahlprozesse
- Vom Softwareanbieter bereits durchgeführte Validierungsarbeiten
- Kontinuierliche Überwachungsdaten zur Erkennung von Softwareleistungsproblemen
- CSV-Tools wie Fehlerverfolgung und automatisiertes Testen
Auch wenn die verwendeten Tools unterschiedlich sein können, ist es wichtig, dass der Hersteller sicherstellt, dass die Software in einem validierten Zustand bleibt.
4. Erstellen des Datensatzes
Die FDA-Richtlinie schreibt vor, dass Hersteller ein Protokoll ihrer Sicherungsmaßnahmen erstellen sollten. Für jede eingesetzte Software sollte das Protokoll den Verwendungszweck, die Risikobestimmung und die Dokumentation der durchgeführten Sicherungsmaßnahmen enthalten, darunter:
- Beschreibung der Prüfung
- Gefundene Probleme und Maßnahmen zur Problemlösung
- Schlussfolgerung zur Akzeptanz der Ergebnisse
- Testdatum und Person, die ihn durchgeführt hat
- Unterschrift und Datum der Person, die die Akte überprüft
Die Qualitätsmanagementsystem-Verbindung zur CSV-Anleitung
QMS-Software Fällt gemäß GAMP 4 typischerweise in die Kategorie 5 oder 5, je nachdem, ob benutzerdefinierte Funktionen hinzugefügt wurden. Kategorie 4 ist die am häufigsten verwendete Branchensoftware. Im Vergleich zur Standardsoftware bietet sie validierte Tools zur Konfiguration der Software ohne Programmierung, um Geschäftsanforderungen zu erfüllen. Im Vergleich dazu verfügt Kategorie 5 über zusätzliche Anpassungsebenen, die Codeänderungen erfordern.
Das CSA-Ansatz Reduziert den Validierungsbedarf erheblich, wenn der Softwareanbieter bereits eine vollständige Validierung durchgeführt hat. Für einige Funktionen können Unternehmen einfach die Dokumentation des Anbieters nutzen, um die Funktionalität der Software in einem umfassenden Anwendungsfall-Testszenario nachzuweisen. Unternehmen sollten die technische Dokumentation des Anbieters sowie Validierungsvorlagen für konfigurierte QMS-Funktionen prüfen.
Fazit
Die Umstellung von der Validierung computergestützter Systeme auf CSA kann den Zeit- und Kostenaufwand für die Implementierung automatisierter Software drastisch reduzieren. Das Case for Quality Forum des Medical Device Innovation Consortium (MDIC) aus dem Jahr 2020 stellt fest, dass sich die Validierungszeit mit diesem Ansatz um 50 % oder mehr verkürzt.
Aufbauend auf bestehenden Vorschriften und Richtlinien bietet CSA einen vereinfachten Weg, Software in einem validierten Zustand zu halten. Für Hersteller reduziert es die Hürden bei der Einführung neuer Technologien zur Verbesserung der Patientensicherheit, einschließlich QMS-Software. Mit der Änderung können Unternehmen Zeit und Geld sparen und gleichzeitig Produktivität und Effizienz steigern.
Über den Autor
Stephanie Ojeda ist Leiterin des Produktmanagements für die Life-Science-Branche bei AssurX. Stephanie verfügt über mehr als 15 Jahre Erfahrung in leitenden Funktionen der Qualitätssicherung in verschiedenen Branchen, darunter Pharma, Biotechnologie, Medizintechnik, Lebensmittel und Getränke sowie Fertigung.
