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. Die FDA beschreibt mit Computer Software Assurance eine vergleichbare risikobasierte Logik, jedoch für Software in der Medizinprodukteproduktion oder im Quality Management System nach 21 CFR Part 820. Für diesen pharmazeutischen CSV-Leitfaden dient sie nur als methodische Orientierung; eine 1:1-Geltung folgt daraus nicht.

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. In ihrem Medical-Device-Produktions-/QMS-Scope beschreibt die FDA-CSA-Guidance unterschiedliche Assurance-Aktivitäten je nach Risiko — von skriptbasiertem Test bis zu unskriptiertem, explorativem Test. Außerhalb dieses Scopes ist das methodische Orientierung; maßgeblich bleiben die jeweils anwendbaren Anforderungen. 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 mit der zugehörigen Spezifikation sowie der Prüfung oder begründeten Bewertung, die sie abdeckt. So wird die in EU-GMP-Annex 11 § 4.4 geforderte Rückverfolgbarkeit über den Lebenszyklus belegbar. Fehlt diese Verbindung, bleibt der Nachweis unvollständig.

Den Abschluss bildet der Validierungsbericht: Zusammenfassung der Aktivitäten, Bewertung von Abweichungen und abschließende Empfehlung zum Ergebnis. Im EU-GMP-Kontext werden Validierungsdokumente durch die im pharmazeutischen Qualitätssystem festgelegten geeigneten Personen genehmigt und autorisiert; eine formale Freigabe zur nächsten Stufe autorisieren die zuständigen Verantwortlichen. Ob QA dabei eine Freigaberolle übernimmt, bestimmt das jeweilige pharmazeutische Qualitätssystem. 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 — Review und Freigabe bleiben bei den in Ihrem pharmazeutischen Qualitätssystem benannten Verantwortlichen. 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.

Häufige Fragen

Ist eine CSV in acht Wochen garantiert?

Nein. Acht Wochen beschreiben hier eine mögliche Taktung, kein verbindliches Liefer- oder Ergebnisversprechen. Die reale Dauer hängt unter anderem von Scope, GxP-Risiko, Systemkategorie, Lieferanten und der Verfügbarkeit der Fachrollen ab.

Was macht eine CSV planbarer?

Ein klarer Scope, risikobasierte Testtiefe, feste Review-Gates und durchgängige Traceability machen Abhängigkeiten früh sichtbar. So wird das Abschlussreview eher zur Bestätigung als zur Reparaturrunde.

Wo kann KI in der CSV unterstützen?

KI kann quellgebundene Entwürfe, Konsistenzprüfungen und Traceability-Vorschläge vorbereiten. Review und Freigabe bleiben bei den im pharmazeutischen Qualitätssystem benannten menschlichen Verantwortlichen.