Computer Software Assurance.
Die Computer Software Assurance (CSA) ist ein risikobasierter Ansatz der FDA für Software in der Produktion und im Qualitätsmanagementsystem (QMS) von Herstellern von Medizinprodukten. Art, Umfang und Nachweistiefe der Assurance-Aktivitäten richten sich dabei nach dem Intended Use und dem Risiko einer Fehlfunktion für die Produktsicherheit und -qualität und nicht nach pauschalen Test- und Dokumentationsroutinen.
Kein Kurswechsel - die Bestätigung eines Wegs.
Risikobasierte Validierung ist älter als die CSA-Guidance-Debatte: Der europäische GMP-Rahmen knüpfte Umfang und Tiefe der Validierung computergestützter Systeme schon vor 2002 an Risiko und Nutzung, und ICH Q9 machte das Qualitätsrisikomanagement ab 2005 zum systematischen Prozess. Die Stationen im Überblick - CSA führt den Weg auf FDA-Seite konsequent weiter, aus der Device-Ecke.
| Station | Rolle auf dem risikobasierten Weg |
|---|---|
| EU GMP Annex 11 + Annex 15Erstfassungen 1992 / 2001 - heute gültig: 2011 / 2015 | Annex 11 etablierte die Validierung und kontrollierte Nutzung GMP-relevanter computergestützter Systeme; Annex 15 verlangte ausdrücklich, Umfang und Tiefe ("scope and extent") der Validierung auf Basis einer Risikobewertung festzulegen |
| FDA "General Principles of Software Validation"01/2002 | Verankerte den risikobasierten Software-Nachweis auf FDA-Seite: Validierungsumfang ausdrücklich nach Komplexität und Risiko, Nachweis als "Level of Confidence", Least Burdensome als erklärtes Prinzip. CSA löst 2025 nur ihren Abschnitt 6 ab - der Rest gilt fort |
| FDA-Initiative "Pharmaceutical CGMPs for the 21st Century - A Risk-Based Approach"2002 / Final Report 2004 | Erhob Risiko, Wissenschaft und moderne Qualitätssysteme zum behördenweiten Steuerungsprinzip - modernisierte die Anwendung der CGMP, keine neue Verordnung |
| PIC/S PI 011in Kraft 09/2003 | Übersetzte Annex 11 in die risikobasierte Prüfpraxis: PIC/S-Leitfaden für Inspektoren computergestützter Systeme - Mängeleinstufung ausdrücklich nach relativem Risiko der Anwendung und Risikokritikalität; inhaltlich unverändert gültig (PI 011-3, 2007) |
| ICH Q9 / Q9(R1)2005/2006 / 2023 | Harmonisierte das Qualitätsrisikomanagement (QRM) als systematischen Prozess (Assessment, Control, Communication, Review) - Übernahme als Annex 20 in die GMP-Leitfäden: EU 2008, PIC/S 2009 |
| GAMP 5 / Second Edition2008 / 2022 | Überführt den risikobasierten Lebenszyklus-Ansatz in eine praktische Methodik für GxP-relevante computergestützte Systeme; die Second Edition stärkt Critical Thinking und skalierte Nachweise - industrielle Good Practice, keine Rechtsvorschrift; die CSA-Guidance nennt die Second Edition seit der Fassung 02/2026 als eine Orientierungsquelle für Testmethoden - Entwurf und Erstfassung enthielten die Referenz noch nicht |
| FDA CSA Guidancefinal 09/2025 / QMSR-Fassung 02/2026 | Konkretisiert den risikobasierten Assurance-Ansatz für Software in Medizinprodukteproduktion und QMS: Intended Use, Prozessrisiko, geeignete Assurance-Aktivitäten, ausreichende objektive Evidenz |
| GAMP GPG "Testing GxP Systems"3rd Edition, Juli 2026 | Konkretisiert risikobasiertes Testen in der Praxis - industrielle Good Practice, keine Rechtsvorschrift: skalierbare Testaktivitäten, Qualitätsrisikomanagement, Lieferantennachweise; ein eigenes Kapitel gilt den computergestützten Testwerkzeugen, Anhänge den iterativen Vorgehensmodellen, SaaS und AI/ML. Der Guide erklärt seinen Ansatz ausdrücklich für konsistent mit GAMP 5 (Second Edition) und der FDA-CSA-Guidance. Mitglieder des FDA-Industrie-CSA-Teams (FICSA) haben am Guide mitgewirkt; Frank Henrichmann (QFINITY) hat ihn als Reviewer des ISPE Editorial Review Board begutachtet |
Erst Intended Use und Prozessrisiko bestimmen. Dann gezielt absichern.
Ein höheres Prozessrisiko erfordert grundsätzlich mehr Rigor. Die Testmethode folgt jedoch nicht mechanisch einer Risikoklasse. Die Guidance unterscheidet zwei Typen: geskriptetes und ungeskriptetes Testen. Welcher davon greift, in welcher Ausprägung (etwa szenariobasiert, explorativ oder automatisiert ausgeführt) und ob eine Kombination beider sinnvoll ist, richtet sich danach, welche Methode die Eignung der jeweiligen Funktion am wirksamsten nachweist. Die Zuordnung von Methoden zu Risikoklassen ist dabei ausdrücklich nicht exklusiv. Intended Use und Prozessrisiko entstehen im Prozess - die Grundlage legt Prozessmanagement.
Ersetzt CSA die klassische CSV?
Nein, CSA ersetzt die CSV nicht - die Guidance löst lediglich Abschnitt 6 der FDA-Leitlinie "General Principles of Software Validation" ab. Für Software, die selbst Teil eines Medizinprodukts ist, gilt die Leitlinie unverändert weiter - CSA übernimmt den Bereich der Produktions- und QMS-Software. Drei Blickwinkel zeigen, was CSA tatsächlich ändert - und was nicht.
Methodik
CSA und GAMP 5 folgen einer vergleichbaren Grundlogik:
- Intended Use verstehen
- Risiken analysieren
- geeignete Aktivitäten auswählen
- ausreichende Evidenz erzeugen
GAMP 5 liefert den umfassenden Lebenszyklus-Rahmen - CSA formuliert dieselbe Logik als FDA-Erwartung.
Geltungsbereich
CSA betrifft mehr als das Testen einzelner Funktionen. Die Guidance umfasst:
- Intended Use und risikobasierte Analyse
- Änderungen im Lebenszyklus
- Lieferantennachweise, Prozesskontrollen und laufende Überwachung
- objektive Evidenz und elektronische Aufzeichnungen
- die ausdrückliche Anwendbarkeit auf Automatisierungswerkzeuge (etwa Bots und automatische Arbeitsabläufe), Datenanalyse- und KI/ML-Werkzeuge sowie Cloud Computing
Der umfassende Validierungsblick auf Prozess, Anwender, Betriebsumgebung und Daten bleibt bestehen.
Etikett
"Assurance" ist ein neues Etikett für einen präziser benannten Gegenstand: Nachgewiesen wird, dass die Software für den im Prozess definierten Intended Use geeignet ist - und dass diese Eignung über den Lebenszyklus erhalten bleibt. Wer diese Frage sauber beantwortet, braucht die Begriffsdebatte nicht.
An den Pflichten ändert CSA nichts: Welche Aufzeichnungen zu führen sind, ergibt sich unverändert aus den predicate rules. Neu ist die Klarheit über den Assurance-Nachweis selbst - die Guidance beschreibt, was er festhält:
Die Dokumentation muss ausreichen, um die Eignung für das identifizierte Risiko nachzuweisen. Mehr ist nicht gefordert. Wie derselbe risikobasierte Gedanke auf KI-Systeme wirkt, zeigt unsere Seite zur Validierung von KI im GxP-Umfeld.
Die Assurance bleibt. Formalität ohne Beweiswert entfällt.
CSA verschiebt den Schwerpunkt von der Dokumentationsmenge zur Evidenzqualität. Das Testformat richtet sich nach seiner Eignung für die konkrete Funktion, vorhandene Lieferantennachweise lassen sich anrechnen, und über den Lebenszyklus erhalten wirksame Kontrollen die zur Inbetriebnahme nachgewiesene Eignung. Als Nachweis empfiehlt die FDA ausdrücklich digitale Originaldaten wie System-Logs, Audit Trails und automatisch erzeugte Aufzeichnungen anstelle redundanter Screenshots.
CSA in der Validierung - gezielt unterstützt.
Aufwand, Formalität und Dokumentation - nach Risiko.
"The level of effort, formality and documentation of the quality risk management process should be commensurate with the level of risk."
ICH Q9(R1), Kapitel 3 - seit 2005/2006 der internationale Maßstab. CSA überträgt dieselbe Proportionalitätslogik auf die Assurance von Produktions- und QMS-Software.
CSA korrigiert nicht das Ziel der Validierung. CSA korrigiert eine Praxis, in der Dokumentationsvolumen zu häufig mit Validierung verwechselt wurde.
Häufige Fragen zur CSA.
Nein. Eine FDA-Guidance beschreibt die aktuelle Auffassung der Behörde, sie verpflichtet nicht. Verbindlich sind die anwendbaren Anforderungen - in den USA seit dem 2. Februar 2026 die QMSR mit den einbezogenen Anforderungen der ISO 13485:2016. CSA beschreibt einen anerkannten risikobasierten Weg, sie zu erfüllen; alternative Ansätze bleiben zulässig, solange sie die Anforderungen einhalten.
Nein. In Europa koppelten Annex 11 (Erstfassung 1992, heute gültig in der Fassung von 2011) und Annex 15 (2001, heute 2015) die Validierung schon vor der FDA-Initiative an Nutzung, Lebenszyklus und Risiko; die PIC/S-Prüfpraxis (PI 011, 2003) stufte Mängel nach dem relativen Risiko der Anwendung ein. Die FDA erhob Risiko 2002-2004 zum Steuerungsprinzip, ICH Q9 systematisierte es als QRM. CSA ist die jüngste Bestätigung dieses Wegs - nicht sein Anfang.
Formal ja: CSA gilt für Software in Produktion und QMS von Medizinprodukteherstellern - die Device-Software selbst (Designverifizierung und -validierung) ist ausdrücklich nicht ihr Gegenstand. Ihr Kern - Prüfaufwand nach Intended Use und Prozessrisiko - folgt demselben Denken wie ICH Q9 und GAMP 5, die branchenweit als methodische Orientierung dienen. Deshalb wirkt CSA über die Device-Welt hinaus - ersetzt dort aber nicht die jeweils anwendbaren Anforderungen.
Least Burdensome heißt nicht: möglichst wenig prüfen oder dokumentieren. Es heißt: nicht mehr Aufwand und Evidenz erzeugen, als die Beherrschung des identifizierten Risikos erfordert - etwa vorhandene Lieferantennachweise nutzen, digitale Systemnachweise statt redundanter Screenshots, ungeskriptetes Testen, etwa exploratives, wo es geeigneter ist, automatisierte Tests wiederverwenden, eigene Tests auf echte Evidenzlücken konzentrieren. Bei hohem Risiko bleibt hoher Rigor erforderlich.
CSA braucht den Gesamtkontext.
Validierungsaufwand am echten Risiko ausrichten.
Wir entwickeln Validierungsstrategie, Planung und Spezifikation, leiten daraus die risikobasierte Teststrategie ab und führen Nachweise, die den Erwartungen der finalen CSA-Guidance entsprechen. Start mit einem kostenfreien Erstgespräch, in dem wir Ihren CSA-Hebel konkret benennen.
Erstgespräch vereinbaren
