Validierung computergestützter Systeme.
Computergestützte Systeme, die GxP-relevante Prozesse tragen, müssen validiert werden. Die Pflicht dazu folgt aus der GxP-Bewertung des Prozesses und gilt für jedes System, das in diesem Prozess eingesetzt wird. EU GMP Annex 11 formuliert diese Pflicht ausdrücklich. 21 CFR Part 11 setzt ein validiertes System voraus, damit elektronischen Aufzeichnungen und Signaturen vertraut werden kann. Validiert wird dabei nicht die Software, sondern ihre Anwendung im Prozess. Maßstab ist der Intended Use. Wir führen diesen Nachweis aus Betreibersicht, ausgerichtet an den Risiken für Patientensicherheit, Produktqualität und Datenintegrität, 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 anhand des Intended Use. Es umfasst die Technologie, den Prozess, in dem sie eingesetzt wird, und die Menschen in diesem Prozess. Der Prozess ist dabei der Ausgangspunkt. Er definiert den Zweck des Systems, und aus diesem Zweck 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 stützt dieser Nachweis? Derselben Logik folgt die Computer Software Assurance.
Vom Prozess zum validierten Zustand.
Die Validierung folgt einem dokumentierten Lebenszyklus. In jedem Spezifikationsschritt wird festgelegt, was später nachzuweisen ist. Die methodische Grundlage liefert die GAMP-5-Validierung. Die Freigabe schließt den Aufbau ab, nicht den Lebenszyklus. Der validierte Zustand gilt für die nachgewiesene Konfiguration und wird im Betrieb erhalten. Der Revisionsentwurf des Annex 11 sieht für diese Betriebsphase ein eigenes Prüfprogramm vor.
- 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
In der Anforderungsanalyse wird der Intended Use in Systemanforderungen übersetzt. In der Risikobewertung werden Systeme und Funktionen nach ihren Risiken für Patientensicherheit, Produktqualität und Datenintegrität gewichtet.
- 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, Bericht & Freigabe
Die relevanten Funktionen werden nach freigegebenen Testfällen geprüft. Ausführung, Ergebnis und Abweichungen werden für jeden Test so dokumentiert, dass die Abdeckung der Anforderungen rückverfolgbar bleibt. Den Abschluss bilden Validierungsbericht und Freigabe für den GxP-Betrieb.
- 6
Betrieb: den Zustand erhalten
Im Change Control wird für jede Änderung geprüft, ob sie den validierten Zustand berührt. Falls erforderlich, wird eine Nachprüfung ausgelöst. Durch kontinuierliches Monitoring und periodische Bewertungen werden bislang unbemerkte Veränderungen sichtbar. Mit Vorfallsmanagement, Sicherheit, Support und Schulung hält der Betreiber den validierten Zustand im Betrieb aufrecht.
Das Fundament unter der Anwendung hat seinen eigenen Nachweisweg: Die Anwendung wird validiert, die IT-Infrastruktur darunter 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 Schritte des Lebenszyklus werden zunehmend digital statt auf Papier ausgeführt. Die Seite zur digitalen Transformation im GxP-Umfeld behandelt diesen Wandel ausführlicher.
Wie CSA das Testen verändert.
Die Verifizierung der Software und die Validierung des computergestützten Systems sind zwei verschiedene Nachweise. Die Software ist Teil des Systems. Ihr Nachweis heißt Verifizierung, auch wenn oft missverständlich von Softwarevalidierung gesprochen wird. Computer Software Assurance betrifft genau diesen Nachweis, die risikobasierte Verifizierung der Anwendungssoftware in Produktion und Qualitätsmanagementsystem. Die finale FDA-Guidance erschien im September 2025. Maßgeblich ist die Fassung vom Februar 2026.
CSA begründet keine neue Disziplin. Die Guidance folgt dem risikobasierten Denken von ICH Q9 und beschreibt im Kern 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 Funktionen gleich tief getestet | Testtiefe skaliert mit dem 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 Verifizierung der Software 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 europäische 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 2nd 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 in GxP-relevanten Prozessen eingesetzt werden. Maßgebend ist die Kausalkette: Beeinflusst das System, auch mittelbar, Daten, Produkt und damit den Patienten? Wo das zutrifft, richten sich Umfang und Tiefe des Nachweises nach 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 Softwareanbieter validiert nicht. Er sichert die Qualität seines Produkts nach definierten Standards und wird dafür vom Betreiber bewertet und auditiert. Anders liegt der Fall beim Softwarehersteller, dessen Software selbst das regulierte Produkt ist, etwa als Medizinprodukt. Dort ist die Validierung eine eigene Disziplin.
Ja. Auch dort wird die Anwendung im Prozess des Betreibers validiert. Der Anbieter verifiziert sein Produkt gegen die eigene Spezifikation und betreibt die Plattform. Der Betreiber bewertet den Anbieter, stützt seinen Nachweis risikobasiert auf dessen Vorarbeiten und bleibt für die Eignung im eigenen Prozess verantwortlich, einschließlich Konfiguration, Release-Zyklen und Datenübernahme beim Ausstieg. Die Infrastruktur darunter ist nach Annex 11 zu qualifizieren.
So tief, wie es das Risiko verlangt. Testtiefe und Dokumentationsumfang skalieren mit dem Risiko, das die jeweilige Funktion für den Patienten, das Produkt und die Datenintegrität birgt. Der Funktionsumfang des Systems ist dafür kein Maß.
Stand:
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
