Validierung computergestützter Systeme.
Computergestützte Systeme, die GxP-relevante Prozesse tragen, müssen validiert werden. So fordern es 21 CFR Part 11 und EU GMP Annex 11. Validiert wird dabei nicht die Software, sondern ihre Anwendung im Prozess, gegen den Intended Use. Wir führen diesen Nachweis aus Betreibersicht: risikobasiert, ausgerichtet am Patienten-, Produkt- und Datenintegritätsrisiko, mit einer Teststrategie nach Computer Software Assurance (CSA). Gebräuchlich sind für diesen Nachweis auch die Begriffe Computervalidierung und CSV-Validierung.
Was genau wird validiert?
Validiert wird das computergestützte Gesamtsystem gegen den Intended Use. Es umfasst die Technologie, den von ihr getragenen Prozess und die Menschen in diesem Prozess. Der Prozess ist dabei der Ausgangspunkt: Er definiert den Zweck des Systems; daraus folgen Anforderungen, Risiken und Nachweisumfang. Jede Ebene des Systems hat ihre eigene Nachweishandlung:
| Ebene | Nachweishandlung |
|---|---|
| Hardware und Infrastruktur | werden qualifiziert. Einmal nachgewiesen, bleibt der qualifizierte Zustand unter kontrollierten Bedingungen belastbar |
| Software-Schichten, Konfiguration, Modelle | werden fortlaufend gegen die Spezifikation verifiziert |
| Das Gesamtsystem im Prozess | wird gegen den Intended Use validiert. Das Ergebnis ist der validierte Zustand |
Der Markt spricht in verkürzten Formeln wie "Validierung der Software" oder "Qualifizierung der Werkzeuge". Wer die Zusammenhänge kennt, übersetzt solche Formeln stillschweigend in die korrekte Nachweishandlung. Entscheidend ist nicht das Etikett eines Nachweises, sondern sein klar benannter Gegenstand: Was genau wird nachgewiesen, und welche Aussage trägt dieser Nachweis? Derselben Logik folgt die Computer Software Assurance.
Vom Prozess zum validierten Zustand.
Die Validierung folgt einem dokumentierten Lebenszyklus, in dem jeder Spezifikationsschritt festlegt, was später nachzuweisen ist. Die methodische Grundlage liefert die GAMP-5-Validierung. Die Freigabe schließt dabei den Aufbau ab, nicht den Lebenszyklus: Der validierte Zustand gilt für die Konfiguration, für die er nachgewiesen wurde, und wird im Betrieb erhalten. Der Revisionsentwurf des Annex 11 verlangt für diese Betriebsphase ein eigenes Prüfprogramm.
- 1
Prozessverständnis & Intended Use
Am Anfang steht der Prozess: Was soll das System im Geschäftsprozess leisten? Der Intended Use ist der Maßstab aller weiteren Schritte.
- 2
Validierungsplanung
Auf die Analyse des bestehenden QMS folgt der Validierungsplan. Er legt Umfang, Rollen, Verantwortlichkeiten und Akzeptanzkriterien fest und gibt den risikobasierten Ansatz vor, an dem sich die weiteren Schritte ausrichten.
- 3
Anforderungen & Risikobewertung
Die Anforderungsanalyse übersetzt den Intended Use in Systemanforderungen; die Risikobewertung gewichtet Systeme und Funktionalitäten nach dem Patienten-, Produkt- und Datenintegritätsrisiko.
- 4
Teststrategie & Spezifikation
Die risikobasierte Teststrategie nach CSA legt fest, welcher Nachweis wie tief geführt wird: Testarten, Testtiefe und Dokumentationsumfang je Funktion.
- 5
Testen, Report & Freigabe
Die relevanten Funktionalitäten werden dokumentiert getestet, mit nachweisbarer Abdeckung der Anforderungen; den Abschluss bilden Validierungsreport und Freigabe für den GxP-Betrieb.
- 6
Betrieb: den Zustand erhalten
Change Control prüft jede Änderung daraufhin, ob sie den validierten Zustand berührt, und löst die nötige Nachprüfung aus; kontinuierliches Monitoring und periodische Bewertung machen sichtbar, was sich unbemerkt verändert. Vorfallsmanagement, Sicherheit, Support und Training halten den validierten Zustand im Betrieb aufrecht.
Das Fundament unter der Anwendung hat seinen eigenen Nachweisweg: Die Anwendung wird validiert, die tragende IT-Infrastruktur wird qualifiziert. Wie der kontrollierte Zustand der Infrastruktur entsteht, zeigt die IT-Infrastruktur-Qualifizierung, vom eigenen Rechenzentrum bis zur Cloud. Wo Systeme unmittelbar in der Herstellung stehen, greifen Prozess- und Systemnachweis ineinander. Wie dieses Zusammenspiel aussieht, beschreibt die Qualifizierung und Validierung produktionsnaher Systeme.
Vom Papierprotokoll zum strukturierten Record.
Die Ausführung des Lebenszyklus wandelt sich grundlegend: Aus der papierbasierten Validierung wird die digitale. Vertieft wird dieser Wandel in der digitalen Transformation im GxP-Umfeld.
Wie CSA das Testen verändert.
Software-Verifizierung und die Validierung des computergestützten Systems sind zwei verschiedene Nachweise. Die Software ist Teil des Systems, und ihr Nachweis heißt korrekt Verifizierung, auch wenn oft missverständlich von Software-Validierung gesprochen wird. Computer Software Assurance adressiert genau diesen Nachweis: die risikobasierte Verifizierung der Anwendungssoftware in der Produktion und im Qualitätsmanagementsystem. Die finale FDA-Guidance erschien erstmals im September 2025 und gilt in der Fassung vom Februar 2026.
CSA erfindet dabei keine neue Disziplin; sie folgt demselben risikobasierten Denken wie ICH Q9: gutes Testen, konsequent angewandt. Der Unterschied liegt nicht zwischen zwei Methoden, sondern zwischen schwerfälligem und wirksamem Testen, vom Auslöser über die Testtiefe bis in den Betrieb:
| Dimension | Schwerfälliges Testen | Risikobasiertes Testen (CSA) |
|---|---|---|
| Testauslöser | getestet wird alles, aus Regulierungsreflex und Unsicherheit vor dem Audit | getestet wird nach Intended Use und tatsächlichem Risiko |
| Testtiefe | alle Funktionalitäten gleich tief getestet | Testtiefe skaliert mit dem tatsächlichen Risiko der jeweiligen Funktion |
| Nachweisführung | umfangreiche Dokumentation als Selbstzweck | wirksames Testen, Dokumentation auf das Nötige reduziert |
| Änderungen im Betrieb | pauschale Nachtests bei jeder Änderung | Nachprüfung risikobewertet, der nachgewiesene Zustand wird gezielt erhalten |
| Aufwand vs. Sicherheit | hoher Aufwand, oft ohne Mehrwert | Aufwand dort, wo er Patientensicherheit und Produktqualität schützt |
Die Guidance nimmt Infrastruktur-Software ohne spezifischen Produktions- oder QMS-Bezug ausdrücklich aus, etwa für Netzwerk, Authentifizierung oder Backup und Restore. Diese Software gehört zur IT-Infrastruktur, die nach Annex 11 qualifiziert wird. Und die Validierung des Gesamtsystems im Prozess bleibt die Aufgabe des Betreibers: Die Software-Verifizierung ist darin ein Baustein.
Validierung, durchgängig begleitet.
Über den gesamten Lebenszyklus begleiten wir Betreiber mit den Leistungen, die den validierten Zustand herstellen und im Betrieb bewahren. Wie das im Ergebnis aussieht, zeigt die Fallstudie Drug Safety Implementation: risikobasierte Validierung nach GAMP 5 bei einem internationalen CRO. Die interne QA stellte keine Mängel fest.
Seit 2004 in jedem Umbruch der Systemvalidierung, von Part 11 bis KI.
Jeder Umbruch stellte dieselbe Frage neu: Kann man elektronischen Daten und Systemen trauen, und wie weist man es nach?
Part 11 fragte nach den Records, ICH Q9 nach dem Risiko, die Data-Integrity-Welle nach dem Verhalten der Menschen am System, die Cloud nach der Kontrolle über Fremdinfrastruktur. KI fragt nach der Beherrschbarkeit des Nichtdeterminismus.
Zum Thema Cloud trugen wir 2011 vor, als der Markt die Zulässigkeit noch diskutierte. Agile Validierungsprojekte in GxP liefen bei uns ab 2013, Jahre vor der Formalisierung.
Am weitesten zurück reicht die GCP-Linie: Im klinischen Umfeld sind die Daten das Produkt, und 2008 gab es für die Systeme, die sie erzeugen, keine eigene Leitlinie, nur ICH E6 und verstreute Inspektionsvorgaben. Diese Lücke war der Anlass: Wir stießen die GAMP-Arbeitsgruppe für GCP-Systeme an (Arbeitsaufnahme 2009, aufgegangen in der ISPE GAMP R&D and Clinical Systems SIG). 2014 schulten wir die europäischen GCP-Inspektoren beim Workshop der EMA GCP Inspectors Working Group. Hier war nicht der Markt das Publikum, sondern die Inspektoren selbst.
Und als die Branche nachzog, wirkten wir an den Antworten mit: im Kernteam der GAMP 5 Second Edition und am Good Practice Guide "Enabling Innovation". Critical Thinking, von GAMP 5 in den Mittelpunkt gestellt, ist die Signatur unserer Teststrategien.
Häufige Fragen zur Validierung computergestützter Systeme.
Nein. Validiert werden Systeme, die GxP-relevante Prozesse tragen. Maßgebend ist die Kausalkette: Beeinflusst das System, auch mittelbar, Daten, Produkt und damit den Patienten? Wo das zutrifft, skalieren Umfang und Tiefe des Nachweises mit dem Risiko; wo nicht, genügen die guten IT-Praktiken des Unternehmens.
Ja. Computervalidierung, CSV-Validierung und Validierung computergestützter Systeme meinen denselben Nachweis; CSV steht für Computerized System Validation. Geprüft wird die Anwendung der Software in ihrem GxP-Prozess, gemessen am Intended Use.
Die Validierung ist Sache des Betreibers: Nur er kennt seinen Prozess und dessen Intended Use. Der Software-Anbieter validiert nicht. Er sichert die Qualität seines Produkts gegen definierte Standards und wird dafür vom Betreiber bewertet und auditiert. Eine eigene Disziplin ist die Software-Validierung beim Hersteller, dessen Software selbst das Produkt ist, etwa als Medizinprodukt.
Ja. Validiert wird auch dort die Anwendung im Prozess, am Intended Use des Betreibers ausgerichtet. SaaS ist die Anwendungsebene, nicht die Infrastruktur. Was sich verschiebt, ist die Nachweislast: Der Anbieter verifiziert sein Produkt gegen die eigene Spezifikation und betreibt die Plattform. Der Betreiber bewertet den Anbieter und stützt seinen Nachweis risikobasiert auf dessen Vorarbeiten. Die Verantwortung für die Eignung im eigenen Prozess bleibt beim Betreiber. Sie schließt Konfiguration, Release-Zyklen und den Weg der Daten beim Ausstieg ein. Die tragende Infrastruktur darunter ist nach Annex 11 zu qualifizieren.
Wenn der dokumentierte Nachweis vorliegt, dass es in seinem Prozess für den Intended Use geeignet ist. Mit der Freigabe ist dieser Zustand erreicht. Er gilt allerdings nur für die nachgewiesene Konfiguration: Jede Änderung wird über Change Control bewertet, damit der validierte Zustand über den Lebenszyklus erhalten bleibt.
So tief, wie es das Risiko verlangt. Testtiefe und Dokumentationsumfang skalieren mit dem Risiko der jeweiligen Funktionalität für Patienten, Produkt und Datenintegrität. Der Funktionsumfang des Systems ist dafür kein Maß.
Validieren Sie nach Risiko, nicht nach Funktionsumfang.
Im Erstgespräch sichten wir Ihr QMS und Ihren Systembestand. Daraus skizzieren wir den Weg Ihres Nachweises: vom Intended Use über die Teststrategie nach CSA bis zum validierten Zustand im Betrieb. Kostenfrei, etwa 30 Minuten.
Erstgespräch vereinbaren
