Warum Gamp-5-Validierung neu gedacht werden muss

In vielen Pharmaunternehmen ist Validierung de facto ein Dokumentationsprojekt: Protokolle werden erstellt, Testfälle abgehakt, Berichte geschrieben. Das System wird freigegeben. Bis zur nächsten Änderung. Dann beginnt der Zyklus von vorn. Der Aufwand ist erheblich – und der Erkenntnisgewinn über die tatsächliche Systemleistung bleibt oft gering.

Typisch ist dabei: Hunderte OQ‑Tests decken Standardfunktionen ab, während kritische Pfade wie Freigabeentscheidungen, Stammdaten‑Governance, Rollen/Rechte und Schnittstellenrisiken nicht gezielt vertieft werden. So entstehen Nachweise über Aktivität – aber nicht automatisch über Kontrolle.

Dabei ist Gamp 5 – der von der ISPE herausgegebene Best-Practice-Leitfaden – genau gegen dieses Muster geschrieben. Ob Validierung zum Qualitätsinstrument wird oder zur Compliance-Übung, entscheidet sich daran, wie der Leitfaden gelesen wird.

Das Missverständnis sitzt tief

Gamp 5 ist kein Dokumentationsregelwerk. Es ist ein risikobasiertes Denkmodell. Der Leitfaden stellt nicht die Frage, wie viel dokumentiert werden muss, sondern welche Systemfunktionen tatsächlich kritisch sind und wie der Validierungsaufwand diesem Risiko angemessen gestaltet werden kann.

Die Leitfragen sind klar: Kann ein Fehler in diesem Prozess die Patientensicherheit gefährden? Beeinflusst das System GMP-relevante Entscheidungen? Werden regulatorisch relevante Daten erzeugt oder verändert? Je nach Antwort variiert der erforderliche Prüfumfang erheblich. Funktionen mit geringem Einfluss auf diese drei Kriterien können mit deutlich reduziertem Aufwand qualifiziert werden – ohne Abstriche bei der Compliance.

In der Praxis wird dieser Spielraum selten genutzt. Stattdessen werden Testpakete nach Schemata erstellt, die formal vollständig sind, aber nicht zwingend die tatsächlichen Risiken im Betrieb adressieren. Das Ergebnis: maximaler Aufwand, nicht immer maximale Wirkung. „Wirkung“ bedeutet hier: belastbare Kontrolle der kritischen Use-Cases – inklusive Datenintegrität, Audit‑Trail‑Review und wirksamer Zugriffskontrollen.

Wo klassische Validierungsstrukturen an ihre Grenzen stoßen

Die Struktur aus Installationsqualifizierung (IQ), Funktionsqualifizierung (OQ) und Leistungsqualifizierung (PQ) ist weiterhin anerkannt und erfüllt eine wichtige Funktion. Sie gerät jedoch unter Druck, sobald Systeme nicht mehr statisch sind.

Moderne Software wird kontinuierlich weiterentwickelt. Cloudbasierte Architekturen, regelmäßige Releases, modulare Systemlandschaften – das ist heute Standard, auch in regulierten Umgebungen. Klassische, projektorientierte Validierungsansätze sind jedoch auf das Gegenteil ausgelegt: stabile Systeme, seltene Änderungen, klar abgegrenzte Einführungsprojekte.

Dieser strukturelle Widerspruch hat konkrete Folgen. Validierung arbeitet langsamer als Entwicklung und Betrieb. Änderungen stauen sich. Der validierte Status hinkt der tatsächlichen Systemnutzung hinterher. Wenn Releases quartalsweise kommen, aber Requalifizierung monatelang dauert, entsteht ein Validierungsstau – und der validierte Status entfernt sich von der realen Systemnutzung. Und jede Anpassung – ob Konfigurationsänderung, Softwareupdate oder Prozessanpassung – löst erneut Dokumentationsaufwand aus, der nicht immer proportional zum tatsächlichen Risiko der Änderung ist.

Nicht IQ/OQ/PQ sind dabei das Problem – sondern ihre schematische Anwendung ohne klare Risikodifferenzierung und ohne Verzahnung mit Change‑ und Release‑Management.

Risikobasiert bedeutet: Differenzieren, nicht reduzieren

Der Ausweg liegt nicht darin, Validierungsanforderungen pauschal zu senken. Er liegt darin, sie konsequent zu differenzieren. Gamp 5 empfiehlt dafür eine systematische Risikobewertung vor der Testplanung – nicht danach. Bewährt sind Methoden wie die FMEA-Methode (Failure Mode and Effects Analysis): Potenzielle Fehlerquellen werden identifiziert, ihre Auswirkungen bewertet, der Prüfumfang daraus abgeleitet. Das Ergebnis ist keine willkürliche Reduktion, sondern eine begründete, dokumentierte und auditierbare Entscheidung darüber, was mit welchem Aufwand getestet wird.

Wer so vorgeht, testet kritische Funktionen gründlicher – und unkritische Funktionen schlanker. Das ist kein Kompromiss bei der Compliance. Es ist das, was Gamp 5 fordert.

Validierung endet nicht mit der Systemfreigabe

Ein weiteres strukturelles Problem: Validierung wird oft als Einmalprojekt verstanden. System einführen, validieren, freigeben – fertig. Bis zur nächsten Änderung.

Gamp 5 denkt Validierung anders: als kontinuierliche Aufgabe über den gesamten Lebenszyklus eines Systems. Jede Änderung muss bewertet werden – nicht pauschal revalidiert, aber systematisch geprüft, ob und in welchem Umfang sie den validierten Status beeinflusst. Änderungsmanagement ist damit kein nachgelagerter Prozess, sondern integraler Bestandteil der Validierungsstrategie.

Die FDA treibt diese Entwicklung mit der Computer-Software-Assurance-Initiative (CSA) weiter voran. CSA verschiebt den Fokus weg von der Vollständigkeit der Dokumentation hin zum risikoorientierten Nachweis der tatsächlichen Systemleistung. Entscheidend ist nicht mehr primär, ob alle Tests formal durchgeführt wurden, sondern ob ein System im kritischen Anwendungskontext zuverlässig funktioniert. Explorative Testansätze und automatisierte Verfahren gewinnen dabei an Bedeutung – weil sie Systeme unter realitätsnahen Bedingungen bewerten und schneller auf Änderungen reagieren können.

CSA ist kein Freibrief zur Reduktion von Compliance‑Nachweisen, sondern ein Ansatz, Nachweise stärker risikoorientiert und nutzungskontextbezogen zu erbringen.

Was das für Pharmaunternehmen konkret bedeutet

Der Wandel von projektbezogener zu kontinuierlicher Validierung ist keine akademische Debatte. Er hat praktische Konsequenzen für die Art, wie Qualitätsmanagement und IT-Betrieb zusammenarbeiten.

Validierungsdokumentation, die parallel zum System gepflegt wird – in separaten Ordnern, Tabellen oder Dokumenten –, ist fehleranfällig und schwer aktuell zu halten. Systeme, die Audit-Trail, Zugriffsrechte und Prozessdokumentation nativ abbilden, schaffen eine belastbarere Grundlage: Die Dokumentation entsteht im laufenden Betrieb, nicht als nachträgliche Rekonstruktion.

Ebenso empfiehlt Gamp 5 ausdrücklich, die Erfahrung des Softwarelieferanten aktiv zu nutzen. Ein Lieferant mit nachgewiesener Validierungserfahrung in regulierten Umgebungen bringt erprobte Protokolle, strukturierte Projektmethodik und Kenntnis der regulatorischen Anforderungen mit – das reduziert den internen Aufwand und erhöht die Qualität der Validierung. Lieferantenevidenz kann Validierungsaufwand reduzieren – die Verantwortung für die Eignung im konkreten Intended Use bleibt jedoch beim Betreiber. Entscheidend ist eine durchgängige Nachvollziehbarkeit: Intended Use/URS → Risikobewertung → Testnachweis → Change‑Impact und erforderliche Regression.