Softwarevalidierung mit Computer Software Assurance
30.05.2025
Die Idee der Computer Software Assurance im Umfeld von Healthcare Unternehmen ist nicht neu. Sie steht seit Jahren für eine Reihe von Aktivitäten, mit denen die Medizintechnikhersteller die Vollständigkeit, Zuverlässigkeit und somit auch die Sicherheit ihrer Software-Prozesse und -Produkte gewährleisten.
Computer Software Assurance
Computer System Validierung (CSV)
Die Vorgehensweise für die Validierung von Computer Systemen besteht in der Erstellung von Dokumenten zum Nachweis der Compliance mit den jeweiligen anwendbaren regulatorischen Vorschriften. Die Historie dieses Ansatzes liegt weit zurück. So finden sich z.B. Vorgaben, die im Rahmen der Computer Software Validierung Anwendung finden, in einer von der FDA ausgegebenen Richtlinie aus dem Jahr 2003: „General Principle of Software Validation; Final Guidance for Industry and FDA Staff.“
Konkreter ist jedoch dem dortigen Abschnitt 4.7 über die Validierung von Software eine Änderung zu entnehmen: „Due to the complexitiy of software, a seemingly small local change may have a significant global system impact. When any change (even a small change) is made to the software, the validation status of the software needs to be re-established.”
Im Umkehrschluss führt dieser Validierungsansatz zu einem umfangreichen Satz an Testdokumentationen. Diese sollen dem objektiven Nachweis dienen, dass bestimmte Anforderungen, die durch Software umgesetzt werden, konsistent zur Erfüllung der Bedürfnisse der Nutzer oder des Systems beitragen. Die Durchführung der erneuten Prüfung im Zuge des CSV gilt dabei als vorausgesetzt. Die Aufwände für die CSV kann dabei enorm sein und der tatsächliche Mehrwert ist für viele unklar.
Die Zeit, die den Projekten zur Validierung von Software zur Verfügung steht, wird demnach zum größten Teil für die Dokumentation aufgewendet und weniger für die Tests. Implementierungen nach GAMP 5 sowie ISO TR 80002-2 finden dabei Anwendung.
Computer Software Assurance (CSA)
Ein anderer Ansatz lässt sich nun im Zuge der erwarteten Veröffentlichung einer neuen FDA Richtlinie zum Thema „Computer Software Assurance for Manufacturing, Operations, and Quality System Software“ erkennen.
Durch die Etablierung dieses Ansatzes soll es den Medizintechnikherstellern gelingen:
- die Qualität zu verbessern,
- die Zeit und Kosten für die Validierung zu verringern,
- Testprobleme zu verringern und
- eine schnelle Bereitstellung Ihrer Produkte zu erreichen
Die wesentliche Neuerung des CSA besteht in der Einbindung von zwei wesentlichen Faktoren in die Aktivitäten und Handlungen, die durchzuführen sind, um Vertrauen in die beabsichtigte Funktionsweise der Software zu schaffen:
- Kritisches Denken
- Risikobasierter Ansatz
Der risikobasierte Ansatz ist auch über die ISO TR ISO/TR 80002-2:2017-06 „Medizinische Gerätesoftware - Teil 2: Validierung von Software zur Verwendung in der Qualitätssicherung für medizinische Geräte“ verknüpft.
Kritisches Denken: Chance und Notwendigkeit
Ist kritisches Denken der neue Schlüssel zur Validierung von Entwicklungs- und Produktionswerkzeugen (Software)?
Die digitale Welt unterliegt, nicht nur seit der COVID-19-Krise einem Kulturwandel. Es entsteht eine stärkere Abhängigkeit von internetbasierten IT- und Cloud-Systemen. Hersteller müssen sich intensiver denn je mit der Etablierung von Vorschriften und der Art und Weise der Validierung ihrer digitalen Technologien beschäftigen.
Das FDA (Food and Drug Administration) Guidance Dokument „Computer Software Assurance for Manufacturing, Operations, and Quality System Software“ ist leider bisher nur als draft Version veröffentlicht. Das Release dieses Guidance-Dokuments ist bisher absehbar. Aber es zeigt bereits jetzt Wege auf, den Übergang vom traditionellen Konzept der Computer System Validierung (CSV) zu Computer System Assurance (CSA) zu etablieren.
Risikobasierter Ansatz mit kritischem Denken
Die neue Richtlinie legt den Fokus auf die Vermeidung von Fehlinterpretation in der Anwendung von Verfahren zur Bestimmung von hohen Risiken und dem daraus resultierenden Prüfgeschehen. Es lässt sich ein Paradigmenwechsel in der Qualitätssicherung von Software erkennen.
Bisher galt das Prinzip, zum Nachweis der Einhaltung der Vorschriften möglichst viel zu dokumentieren. Dazu wurde jeder einzelne Schritt eines Softwaresystems durch detaillierte, teils auf Skripten basierte Testaktivitäten abgedeckt. Bei dem neuen Ansatz der CSA steht das kritische Denken im Vordergrund. Dies schließt ein, dass das Vertrauen in die Funktion der Software durch einen risikobasierten Ansatz sichergestellt wird.
Als Abgrenzung zu dem bisherigen Ansatz des CSV können die folgenden Elemente unter dem Einfluss von kritischem Denken im Sinne der neuen Richtlinie herangezogen werden:
- Eignet sich die Methode für den bestimmungsgemäßen Gebrauch des Systems und ist sie von Relevanz?
- Welcher Basis unterliegen die vorhandenen Informationen, die in Betracht gezogen werden? Sind diese interne Überzeugungen oder historisch im Unternehmen gewachsen?
- Beruhen die Informationen auf genau vorgegebenen Fakten?
- Kann der Informationsaustausch als klar und verständlich kategorisiert werden?
Welche Schritte die CSA umfassen wird, lässt sich erst sagen, sobald die Richtlinie veröffentlicht wurde. Anzunehmen ist, dass der CSA-Ansatz grob die folgenden Schritte umfasst:
- Identifizierung der beabsichtigten Verwendung
- Bestimmung eines risikobasierten Ansatzes
- Entscheidung über Methoden und Aktivitäten
- Erzeugung der entsprechenden Aufzeichnungen
Im Fokus der Validierung steht die Frage, wie sich die Verwendung der Software auf die Sicherheit von Patienten und Anwendern, die Qualität oder die Datenintegrität auswirkt. Hat das Merkmal, das Feature, die Bedienung oder die Funktion direkten Einfluss auf die Sicherheit oder die Qualität des Produkts (Software) oder auf das Qualitätssicherungssystem?
Darauf aufbauend sollte der Medizinproduktehersteller angemessene Sicherungsmaßnahmen ermitteln ‚[…] the manufacturer should identify the assurance activities commensurate with the medical device risk or the process risk‘.
Ausgehend von der Verwendung ergibt sich die Einstufung im Rahmen des risikobasierten Ansatzes.
Wie in der bisherigen Herangehensweise im Rahmen der Softwareentwicklung muss auch weiterhin die zuverlässige Ausführung von Merkmalen und Funktionen, welche ein hohes Risiko haben, sichergestellt und nachgewiesen werden . ‚In either case, heightened risks of software features, functions, or operations generally entail greater rigor, i.e., a greater amount of objective evidence‘
Zudem ist erkennbar, dass sich der Wandel auch im Hinblick auf die Dokumentation zeigen wird. Dabei besteht bisher der Fokus auf der Erstellung von Dokumentation zum Zweck des Nachweises der Compliance (Evidence). Der CSA Ansatz legt den Fokus auf das Testen für mehr Vertrauen in die Systemleistung. Das Guidance Dokument verweist explizit auch das Durchführen von ungeplanten, explorativen Tests ‚Types of assurance activities commonly performed by manufacturers include, […] Unscripted testing […] ad-hoc testing […] error-guessing […] exploratory testing.‘ wie auch von strukturierten und automatisierten Tests.
Selbstentwicklung vs. bereits verfügbares Tool
Da nicht für alle Zwecke eigene Tools zur Testung und Validierung von den Medizintechnikherstellern entwickelt werden können, bleibt noch die Frage, inwiefern der Umgang mit Drittanbietern durch das CSA abgedeckt wird. Sofern Medizintechnikhersteller von der FDA regulierte Produkte herstellen, sollten diese sich ebenfalls mit den Standards der Drittanbieter Firmen befassen. Diese Firmen stellen Ihre Tools bereit, unterliegen aber nicht im gleichen Maße den Regulierungsbestimmungen der FDA. Daher ist bei der Auswahl zu berücksichtigen, welche Branchenzertifizierungen bestehen und wie die Qualität der Produkte erreicht wird.
Entscheidend wird sein, inwiefern sich die richtige Teststrategie mit den künftigen Vorgaben der CSA in der Praxis vereinbaren lässt. Denn sofern aufgrund der Risikoeinstufung ein einfacher Test gewählt und einmalig durchgeführt wird, besteht dadurch keine Garantie für weitere erfolgreiche Test.
Was sollten und können Hersteller von Medizinprodukten daher bereits jetzt vor der Veröffentlichung der Computer Software Assurance tun?
Hier sind einige Beispiele:
- Gap Analysis für den Übergang zu CSA
- Entwicklung einer CSA Strategie und Übergangsplan
- Auswahl Pilot Programm oder Projekt
- Change Management im Blick behalten
- Critical Thinking bei den Mitarbeitern etablieren
- Risk-Based Approach schulen
Zusammenfassung
Obwohl das FDA-Guidance Dokument „Computer Software Assurance for Manufacturing, Operations, and Quality System Software“ bisher nicht freigegeben ist, kann die Verwendung von Mechanismen für die smarte SW-Toolvalidierung beim Medizinproduktehersteller empfehlenswert sein, da ein risikobasierter Ansatz und kritisches Denken niemals verkehrt sind, um Prozesse zu verschlanken und den Hersteller wettbewerbsfähig und innovativ zu halten.
Gern entwickeln wir gemeinsam mit Ihnen ein auf CSA basierendes Konzept, das zu ihrem Umfeld der Softwarevalidierung passt.
Unser Newsletter „qonzentrat“
kompakt, professionell und präzise
Profitieren Sie von unserem Fachwissen.
Jetzt anmelden
