GAMP 5 in modernen Softwareprojekten

GAMP 5 hat einen Ruf, den der Leitfaden nicht verdient: schwerfällig, dokumentenlastig, unvereinbar mit moderner Entwicklung. Tatsächlich fordert er das Gegenteil – risikobasiertes Vorgehen, Nutzung dessen, was der Lieferant bereits geprüft hat, und kritisches Denken statt Formularpflege. Der Ruf stammt meist von der Umsetzung, nicht vom Leitfaden.

1. Was GAMP 5 ist

GAMP 5 ist ein Branchenleitfaden der ISPE für die Validierung computergestützter Systeme im GxP-Umfeld. Er ist kein Gesetz und keine Norm: Behörden verlangen nicht „GAMP-Konformität“, sondern beherrschte, dokumentierte Prozesse. GAMP 5 ist eine verbreitete und anerkannte Art, diese Erwartung zu erfüllen – aber eben eine Handreichung, keine Vorschrift.

Die regulatorische Grundlage bleibt anderswo: Annex 11 des EU-GMP-Leitfadens, 21 CFR Part 11 und die jeweiligen nationalen Vorgaben. Der Deep Dive Softwarevalidierung unter GxP beschreibt den Ablauf dazu im Detail.

2. Die Softwarekategorien

Am bekanntesten ist die Einteilung in Softwarekategorien. Ihr Zweck ist nicht Klassifikation um ihrer selbst willen, sondern die Ableitung eines angemessenen Aufwands:

Die praktische Konsequenz ist erheblich und wird oft übersehen: Die Architekturentscheidung beeinflusst den Validierungsaufwand direkt. Was als Konfiguration einer erprobten Plattform abgebildet wird, ist anders – und in der Regel günstiger – nachzuweisen als individuell programmierte Logik. Wer viel selbst baut, kauft sich Nachweisarbeit ein.

3. Risikobasiert statt vollständig

Der zweite Kerngedanke: Nicht jede Funktion wird gleich tief geprüft. Maßstab ist der Einfluss auf Produktqualität, Patientensicherheit und Datenintegrität. Ein praktikables Vorgehen in drei Schritten:

1. Funktionen listen – auf einer Granularität, die fachlich beschreibbar bleibt, nicht auf Methodenebene.
2. Einfluss bewerten – was passiert bei Fehlfunktion, wie wahrscheinlich ist sie, wie sicher wird sie erkannt?
3. Prüftiefe zuordnen – von „reguläre Qualitätssicherung“ bis „dokumentierte Testfälle inklusive negativer Tests“.

Wichtig ist, dass diese Zuordnung vorher festgehalten wird. Nachträglich begründete Prüftiefen wirken in jeder Inspektion wie eine Rechtfertigung.

4. Lieferantenleistung nutzen

GAMP 5 erlaubt ausdrücklich, auf Aktivitäten des Lieferanten aufzusetzen, statt alles zu wiederholen – vorausgesetzt, eine Lieferantenbewertung belegt, dass diese Aktivitäten belastbar sind. Was dabei zählt:

• ein nachvollziehbarer Entwicklungsprozess beim Lieferanten,
• Testnachweise für Standardfunktionen,
• dokumentierte Versionierung und Release-Prozesse,
• ein geregelter Umgang mit Fehlern und Sicherheitslücken,
• Verfügbarkeit der Unterlagen für eine Prüfung.

Für Plattformanbieter heißt das: Belastbare Aussagen über den eigenen Prozess sind wertvoller als Marketingaussagen über Compliance – sie senken beim Kunden real den Aufwand.

5. Iteratives Vorgehen und V-Modell

Das V-Modell ist in GAMP-Darstellungen allgegenwärtig, aber es beschreibt eine Beziehung – jede Spezifikationsebene hat eine zugehörige Prüfebene –, keine zeitliche Reihenfolge. Diese Beziehung lässt sich iterativ genauso herstellen wie sequenziell.

Was bei iterativem Vorgehen zusätzlich zu klären ist:

• Ab welchem Punkt gilt eine Anforderung als „für die Validierung relevant“?
• Wie werden Zwischenstände behandelt, die nie produktiv gehen?
• Wann wird der Validierungsstand aktualisiert – pro Release oder gebündelt?

Antworten darauf gehören in den Validierungsplan. Sind sie dort geregelt, ist iterative Entwicklung kein Widerspruch zu GAMP 5.

6. Automatisierte Tests als Nachweis

Automatisierte Tests sind aus GAMP-Sicht attraktiv: reproduzierbar, protokolliert, bei jeder Änderung erneut ausgeführt. Damit sie als Nachweis taugen, müssen allerdings drei Dinge kontrolliert sein:

• Die Testumgebung – bekannt, versioniert, dokumentiert.
• Die Testdaten – definiert und nachvollziehbar erzeugt.
• Das Testwerkzeug selbst – in seiner Eignung bewertet; der Aufwand dafür richtet sich wiederum nach dem Risiko.

Hinzu kommt die Aufbewahrung: Ein Testlauf, dessen Protokoll nach 30 Tagen verschwindet, ist kein Nachweis. Siehe dazu Evidence by Design.

7. Wo AI-gestützte Entwicklung einzuordnen ist

Ein KI-Werkzeug in der Entwicklung ist zunächst genau das: ein Werkzeug. Es verändert weder die Kategorie der entstehenden Software noch den Umfang der Validierung, weil ausgeliefert wird, was ausgeliefert wird – deterministische Software. Zu ergänzen sind die Fragen aus dem Deep Dive KI und GxP: Datenflüsse, Prüfpflichten, Dokumentation des Werkzeugeinsatzes.

Anders liegt der Fall, wenn ein Modell zur Laufzeit GxP-relevante Entscheidungen beeinflusst. Das ist eine eigene, deutlich anspruchsvollere Fragestellung und gehört gesondert bewertet.

Typische Fehler

• Alles als kundenspezifisch behandeln und damit Standardfunktionen erneut nachweisen.
• Lieferantenbewertung überspringen und dadurch die Erleichterung verlieren, die GAMP 5 ausdrücklich vorsieht.
• Risikobewertung nachträglich schreiben, um die gewählte Prüftiefe zu begründen.
• Das V-Modell als Terminplan lesen statt als Zuordnungsmodell.
• Dokumente statt Nachweise produzieren – Umfang mit Qualität verwechseln.

Checkliste: GAMP 5 praxistauglich anwenden

Fazit

GAMP 5 richtig angewendet reduziert Aufwand, statt ihn zu erzeugen: durch Kategorisierung, Risikobasierung und die Nutzung dessen, was der Lieferant bereits geprüft hat. Der häufigste Fehler ist nicht zu wenig Dokumentation, sondern zu viel – an den falschen Stellen.

Die wirksamste Entscheidung fällt dabei früh und außerhalb der Validierung: Je mehr ein System konfigurierte, erprobte Plattformfunktionalität nutzt, desto kleiner ist der Teil, der individuell nachgewiesen werden muss.