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. Im Sprachgebrauch begegnen dafür auch die Begriffe Computervalidierung und CSV-Validierung. 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).
Was genau wird validiert?
Validiert wird das computergestützte Gesamtsystem - die Technologie, der getragene Prozess und die Menschen darin - gegen den Intended Use. 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 | wird qualifiziert - einmal nachgewiesen, bleibt der Zustand unter kontrollierten Bedingungen belastbar |
| Software-Schichten, Konfiguration, Modelle | werden verifiziert - fortlaufend gegen die Spezifikation |
| Das Gesamtsystem im Prozess | wird validiert - gegen den Intended Use; das Ergebnis ist der validierte Zustand |
Der Markt spricht in verkürzten Formeln - "Validierung der Software", "Qualifizierung der Werkzeuge". Wer die Zusammenhänge kennt, übersetzt sie 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 - methodische Grundlage ist die Validierung nach GAMP 5. Die Freigabe ist dabei ein Endpunkt, kein Abschluss: Der validierte Zustand gilt für die Konfiguration, für die er nachgewiesen wurde - im Betrieb wird er erhalten.
- 1
Prozessverständnis & Intended Use
Am Anfang steht der Prozess: Was soll das System im Geschäftsprozess leisten? Der Intended Use ist Vor-Kriterium und Maßstab aller weiteren Schritte.
- 2
Validierungsplanung
Analyse des bestehenden QMS und Erstellung des Validierungsplans - Umfang, Rollen, Verantwortlichkeiten und Akzeptanzkriterien; der Plan gibt den risikobasierten Ansatz vor, an dem sich die weiteren Schritte ausrichten.
- 3
Anforderungen & Risikobewertung
Die Anforderungen übersetzen den Intended Use in Systemanforderungen; die Risikobewertung gewichtet Systeme und Funktionalitäten am Patienten-, Produkt- und Datenintegritätsrisiko.
- 4
Teststrategie & Spezifikation
Die risikobasierte Teststrategie nach CSA legt fest, welcher Nachweis wie tief geführt wird - hier wird angelegt, was das Testen später einlöst.
- 5
Testen, Report & Freigabe
Dokumentiertes Testen der relevanten Funktionalitäten mit nachweisbarer Abdeckung der Anforderungen, Validierungsreport und Freigabe für den GxP-Betrieb.
- 6
Betrieb: den Zustand erhalten
Change Control bewertet jede Änderung darauf, 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 das System dauerhaft inspektionssicher.
Das Fundament darunter hat seinen eigenen Nachweisweg: Die Anwendung wird validiert, die tragende IT-Infrastruktur wird qualifiziert. Wie deren kontrollierter Zustand entsteht - vom eigenen Rechenzentrum bis zur Cloud -, zeigt die IT-Infrastruktur-Qualifizierung.
Vom Papierprotokoll zum strukturierten Record.
Die Ausführung des Lebenszyklus wandelt sich grundlegend: von der papierbasierten zur digitalen Validierung. Wie dieser Wandel gelingt, zeigt die digitale 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 Produktion und Qualitätsmanagementsystem - als finale FDA-Guidance erstmals im September 2025 veröffentlicht, geltend in der Fassung vom Februar 2026.
CSA erfindet dabei keine neue Disziplin: Es ist die risikobasierte Entscheidungsfindung nach ICH Q9 - gutes Testen, konsequent angewandt. Der Unterschied liegt nicht zwischen zwei Methoden, sondern zwischen schwerfälligem und wirksamem Testen - beim Auslöser, bei der Testtiefe und im Betrieb:
| Dimension | Falsches Testen | Risikobasiertes Testen (CSA) |
|---|---|---|
| Testauslöser | getestet wird alles - weil reguliert und aus Unsicherheit vor dem Audit | getestet wird nach Intended Use und tatsächlichem Risiko |
| Testtiefe | alle Funktionalitäten gleich tief getestet | Testtiefe skaliert mit Patienten-, Produkt- und Datenintegritätsrisiko |
| 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 validierte Zustand bleibt gezielt erhalten |
| Aufwand vs. Sicherheit | hoher Aufwand, oft ohne Mehrwert | Aufwand dort, wo er Patientensicherheit und Produktqualität schützt |
Betriebssysteme und IT-Infrastruktur nimmt die Guidance ausdrücklich aus - Infrastruktur-Software wie Netzwerk, Authentifizierung oder Backup und Restore wird qualifiziert. 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 das System inspektionssicher machen - und im validierten Zustand halten.
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, die Cloud nach der Kontrolle über Fremdinfrastruktur - KI fragt nach der Beherrschbarkeit des Nichtdeterminismus.
Über Cloud haben wir 2011 vorgetragen, als der Markt noch über die Zulässigkeit diskutierte; agile Validierungsprojekte in GxP liefen bei uns ab 2013 - Jahre vor der Formalisierung.
Am tiefsten 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. In diese Lücke hinein stießen wir 2008 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 Aufsicht.
Und als die Branche nachzog, haben wir an den Antworten mitgeschrieben: im Kernteam der GAMP 5 Second Edition, 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 Computer System Validation. Wir verwenden durchgängig den präzisen Begriff - geprüft wird nicht die Software allein, sondern ihre Anwendung im GxP-Prozess gegen den 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 Softwarevalidierung beim Hersteller, dessen Software selbst das Produkt ist - etwa als Medizinprodukt.
Ja - validiert wird auch dort die Anwendung im Prozess, gegen den Intended Use des Betreibers. 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 dabei bei ihm - bis hin zu Konfiguration, Release-Zyklen und dem Weg der Daten beim Ausstieg. Die tragende Infrastruktur darunter ist entsprechend den dafür geltenden Anforderungen 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 Patienten-, Produkt- und Datenintegritätsrisiko der jeweiligen Funktionalität - nicht mit dem Funktionsumfang des Systems. Entscheidend ist wirksames Testen, dokumentiert in dem Umfang, den der Nachweis wirklich braucht.
Validieren Sie risikobasiert, nicht auf Vorrat.
Im Erstgespräch analysieren wir Ihr QMS und Ihren Systembestand und legen fest, wie der Nachweis geführt wird - vom Intended Use über die Teststrategie nach CSA bis zum validierten Zustand im Betrieb. Kostenfrei, etwa 30 Minuten.
Erstgespräch vereinbaren
