Computer System Validation planbarer machen: Der pragmatische Leitfaden

Warum CSV ohne Taktung ausfranst

Die meisten Validierungen scheitern nicht an fehlender Kompetenz, sondern an fehlender Taktung. Ein System wird angeschafft, die Validierung „läuft mit“, und nach drei Monaten steht ein Stapel halbfertiger Dokumente, deren Bezug zueinander niemand mehr vollständig rekonstruieren kann. Das Risiko verlagert sich dann von der Software auf den Validierungsprozess selbst.

Der Gegenentwurf ist nicht „schneller arbeiten“, sondern enger schneiden und klarer abschließen. Wenn jede Phase ein definiertes Eingangs- und Ausgangsdokument hat, wird die Validierung prüfbar — nicht erst am Ende, sondern in jedem Schritt. Die hier beschriebenen acht Wochen sind genau das: eine Struktur, die Anfang und Ende jeder Phase sichtbar macht. Sie sind keine Zusage, dass jedes System in acht Wochen validiert ist. Ein einzelnes SaaS-Tool mit niedrigem GxP-Risiko kann schneller sein; ein tief integriertes MES mit individueller Konfiguration braucht länger.

Die meisten Validierungen scheitern nicht an fehlender Kompetenz, sondern an fehlender Taktung.

Phase 1 (Woche 1–2): Scope und Risikoklassifizierung

Die erste Phase entscheidet über alle folgenden. Zuerst klären Sie den Systemtyp nach GAMP-5-Kategorie: ein Standardprodukt ohne Konfiguration (Kategorie 3), ein konfiguriertes Produkt (Kategorie 4) oder kundenspezifische Software (Kategorie 5). Die Kategorie bestimmt die Validierungstiefe — sie ist kein Etikett, sondern die Logik dahinter, wie viel Sie testen müssen.

Parallel führen Sie eine risikobasierte Klassifizierung durch: Welche Funktionen berühren Patientensicherheit, Produktqualität oder Datenintegrität? GAMP 5 in der 2nd Edition stellt diesen risikobasierten Ansatz und Critical Thinking konsequent in den Mittelpunkt — der Aufwand richtet sich nach dem Risiko, nicht nach einer pauschalen „alles testen“-Regel. Diese Linie zieht die FDA mit ihrem Computer-Software-Assurance-Ansatz weiter: Der Fokus liegt auf den kritischen Funktionen statt auf Dokumentationsvollständigkeit um ihrer selbst willen.

Das Ergebnis dieser Phase ist ein Validierungsplan (oder Validation Master Plan, je nach Umfang), der Scope, Risikoklassen, Verantwortlichkeiten und Liefergegenstände festlegt. Wird er hier sauber geschnitten, steht das Gerüst für alles Weitere.

Phase 2 (Woche 2–4): URS und Functional Specification

Die User Requirements Specification (URS) beschreibt, was das System aus Anwender- und GxP-Sicht können muss — testbar formuliert, jede Anforderung eindeutig identifizierbar. Eine Anforderung, die Sie nicht testen können, gehört nicht in die URS, sondern in eine Designnotiz. Die URS ist das Rückgrat der späteren Traceability: Was hier nicht steht, lässt sich später schwer belegen.

Die Functional Specification (FS) übersetzt die Anforderungen in konkretes Systemverhalten — wie das System die URS erfüllt. Bei Kategorie-3-Standardprodukten ist sie oft schlank, weil sie auf Lieferantendokumentation aufsetzt; bei konfigurierten oder kundenspezifischen Systemen wird sie umfangreicher. Wichtig ist die Quellenlage: Lieferantendokumentation, Konfigurationsstände und Designentscheidungen müssen verfügbar und freigegeben sein, bevor Sie sie als Validierungsgrundlage verwenden. Quellen zuerst, dann ableiten — nicht umgekehrt.

Phase 3 (Woche 4–7): IQ, OQ und PQ

Jetzt wird getestet. Die drei klassischen Qualifizierungsstufen bauen aufeinander auf:

• Installation Qualification (IQ): Ist das System korrekt und nach Spezifikation installiert? Umgebung, Versionen, Schnittstellen, Konfiguration im dokumentierten Sollzustand.
• Operational Qualification (OQ): Funktioniert das System über den vorgesehenen Betriebsbereich wie spezifiziert? Hier liegt der Schwerpunkt bei GxP-kritischen Funktionen — risikobasiert, nicht flächendeckend.
• Performance Qualification (PQ): Erfüllt das System unter realen Betriebsbedingungen und mit echten Prozessen seinen Zweck? Hier zeigt sich, ob die Validierung den tatsächlichen Anwendungsfall trifft.

Der risikobasierte Ansatz wirkt in dieser Phase am stärksten. Für ein Standardprodukt mit etablierter Lieferantenqualifizierung kann ein gezielter, verifizierender Test ausreichen, während kritische kundenspezifische Funktionen tiefere Prüfung verlangen. Die FDA-CSA-Logik unterstützt unterschiedliche Assurance-Aktivitäten je nach Risiko — von skriptbasiertem Test bis zu unskriptiertem, explorativem Test. Entscheidend ist, dass jede Testanforderung, jedes Ergebnis und jede Abweichung dokumentiert und freigegeben wird, bevor das System in den GxP-Einsatz geht.

Phase 4 (Woche 7–8): Traceability und Review

Eine Validierung ist erst dann intern belastbar vorbereitet, wenn sie lückenlos rückverfolgbar ist. Die Traceability-Matrix verbindet jede URS-Anforderung über die Functional Specification mit dem zugehörigen Testfall und dessen Ergebnis. Ein Inspektor muss von einer beliebigen Anforderung zum Nachweis springen können — und zurück. Lücken in dieser Kette sind die häufigste Schwachstelle, die in Audits und Inspektionen auffällt.

Den Abschluss bildet der Validierungsbericht: Zusammenfassung der Aktivitäten, Bewertung von Abweichungen, Freigabeentscheidung. Davor steht ein menschliches Review durch die Qualitätssicherung — keine Validierung schließt ohne formale QA-Freigabe. Genau hier liegt der Sinn der Taktung: Wenn die vorhergehenden Phasen sauber abgeschlossen wurden, ist das finale Review eine Bestätigung, kein Reparaturmarathon.

Wo KI hilft — und wo der Mensch entscheidet

Der größte Zeitfresser in der CSV ist selten das Denken, sondern das Erzeugen, Querverknüpfen und Konsistenthalten von Dokumenten: URS aus Anforderungen, Testfälle aus der Functional Specification, die Traceability-Matrix über alles hinweg. Genau hier kann KI Entwürfe vorschlagen und Lücken sichtbar machen — sie ersetzt aber weder die fachliche Bewertung noch die Freigabe.

Die Trust-Architektur von traqx ist darauf ausgelegt: Quellen zuerst — Ableitungen entstehen auf Basis freigegebener Dokumente, nicht aus dem Modellgedächtnis. KI als Vorschlag — jeder Entwurf ist ein Vorschlag, kein fertiges Ergebnis. Mensch entscheidet — die QA-Freigabe bleibt Pflicht und liegt bei Ihren Fachleuten. Audit-Trail bleibt — wer was wann auf welcher Grundlage geprüft und freigegeben hat, ist nachvollziehbar. Das ist die einzige Form von Beschleunigung, die in einem regulierten Umfeld trägt: Tempo bei der Erstellung, ohne Abstriche bei Nachvollziehbarkeit und Verantwortung.