GAMP5 ohne Über-Engineering: Pragmatische Validierung für KMU

GAMP5 hat einen seltenen Doppelruf. In großen Pharmaunternehmen gilt es als ehrwürdiges, manchmal schwerfälliges Rahmenwerk. Im pharmazeutischen Mittelstand gilt es dagegen oft als undurchschaubar – und wird entweder stillschweigend ignoriert oder so überdimensioniert angewendet, dass die Validierung zur Nebenbeschäftigung eines ganzen Quartals wird.

Beides ist unnötig. GAMP5 ist explizit als risikobasiertes Rahmenwerk konzipiert: Die Validierungsanstrengung soll im Verhältnis zum tatsächlichen Risiko des Systems stehen. Für eine kleine Großhandlung mit konfigurierter Standard-Warenwirtschaft sieht das strukturell anders aus als für eine konzernweite ERP-Einführung – nicht weniger regelkonform, aber deutlich schlanker.

Worum es bei GAMP5 wirklich geht

GAMP5 – Good Automated Manufacturing Practice – ist ein Rahmenwerk der International Society for Pharmaceutical Engineering (ISPE), aktuell in der zweiten Auflage von 2022. Es ist selbst kein Gesetz und kein behördlicher Standard. Zur Pflicht macht die Validierung computerisierter Systeme EU-GMP Annex 11 – GAMP5 ist die in der Praxis anerkannte Methodik, wie diese Pflicht strukturiert erfüllt wird.

Der Kern ist ein V-Modell: Auf der einen Seite stehen die Anforderungen – User Requirements Specification, funktionale und Konfigurationsspezifikation. Auf der anderen Seite deren Testgegenstücke – Installation, Operational und Performance Qualification (IQ, OQ, PQ). Die zweite Säule ist die Risikoklassifizierung: GAMP5 unterscheidet vier aktive Software-Kategorien, und welche davon auf Ihre Warenwirtschaft zutrifft, entscheidet über die Tiefe der Validierung.

Die Kategorien – und was davon Sie betrifft

Kategorie 1: Infrastruktur-Software. Betriebssysteme, Datenbank-Engines, Middleware. Hier reicht in der Regel die Dokumentation der installierten Version, ein Eintrag im Validierungs-Inventar und die Aufnahme in den laufenden Patch-Management-Prozess. Eine eigene Validierungsdokumentation ist nicht erforderlich.

Kategorie 2 existiert seit der zweiten Auflage (2022) nicht mehr als eigene Kategorie. Sie umfasste früher nicht-konfigurierbare Firmware auf Geräten und Instrumenten; die ISPE hat sie aufgelöst, weil sich jedes betroffene System sauber entweder als Kategorie 1 oder Kategorie 3 einordnen lässt.

Kategorie 3: Nicht-konfigurierte Produkte. Standard-Software, die ohne Konfiguration genutzt wird – etwa ein einfaches Auswertungs-Tool, das nicht in den GxP-Kernprozess eingreift. Hier reicht typischerweise eine risikobasierte Funktionsprüfung; eine vollständige IQ/OQ/PQ ist bei niedrigem Risiko nicht notwendig.

Kategorie 4: Konfigurierte Produkte. Hier liegt fast jede pharmazeutische Warenwirtschaft. Standard-Software, die für den eigenen Betrieb konfiguriert wird – mit Stammdaten, Workflows, Berechtigungen, Schnittstellen. Eine Kategorie-4-Validierung verlangt eine User Requirements Specification, eine Konfigurationsspezifikation, eine Risikoanalyse und IQ/OQ/PQ-Protokolle. Wichtig: Bei konfigurierter Software ersetzt die Konfigurationsspezifikation die klassische Design-Spezifikation. Sie müssen nicht dokumentieren, wie der Code funktioniert – sondern, wie das System für Ihren Betrieb konfiguriert ist.

Kategorie 5: Custom-Software. Vollständig individuell entwickelte Lösungen oder erhebliche kundenspezifische Erweiterungen. Hier ist der gesamte Lebenszyklus mit Design-Spezifikation, Code-Review, Unit- und Integrationstests vorgesehen. Kategorie 5 ist in der KMU-Warenwirtschaftslandschaft selten – außer in Form von „kleinen Programmiererweiterungen", die in eine Kategorie-4-Konfiguration eingebettet sind und dann wie Kategorie 5 behandelt werden müssen. Diesen Punkt unterschätzen viele Betriebe.

Die Dokumente, die Sie wirklich brauchen

Für eine konfigurierte Standard-Warenwirtschaft (Kategorie 4) im KMU-Segment ergibt sich eine überraschend kompakte Dokumentenkette – tragfähig für eine GDP-Inspektion, mit angemessener Disziplin von einem kleinen Team in einigen Wochen erstellbar.

Validation Master Plan. Beschreibt, welche Systeme welcher Kategorie zugeordnet sind, welche Methodik gilt, wer verantwortlich ist und wie Periodic Reviews ablaufen. Wird einmal erstellt und periodisch aktualisiert.

User Requirements Specification. Was soll das System fachlich können? Hier fließen die Anforderungen aus GDP, EU-GMP Annex 11, securPharm, MSV3, ggf. MedCanG ein. Wichtig: Die URS muss von Ihnen kommen, nicht vom Lieferanten – sie ist die Brücke zwischen regulatorischer Anforderung und technischer Lösung.

Risikoanalyse. Welche Funktionen sind GxP-kritisch, welche Risiken hat ein Fehlverhalten, welche Kontrollen greifen? Eine FMEA-ähnliche Tabelle reicht in der Regel aus.

Konfigurationsspezifikation. Wie ist das System tatsächlich konfiguriert – Mandanten, Lagerzonen, Auftragsarten, Schnittstellen, Benutzergruppen, Berechtigungen? Diese Spezifikation lebt: Jede Konfigurationsänderung mit Auswirkung auf GxP-Funktionen gehört nachgezogen.

Lieferantenbewertung. Ein Bericht, der den Software-Anbieter bewertet: Existiert ein QMS, eine Test-Strategie, eine dokumentierte Versionsverwaltung? Eine ausführliche Vor-Ort-Auditierung ist nicht zwingend – eine schriftliche Lieferantenanfrage mit belegter Antwort reicht in vielen Fällen. Die Systematik dahinter deckt sich mit der Qualifizierung anderer Geschäftspartner, die die gute Vertriebspraxis verlangt – siehe Lieferanten- und Kundenqualifikation nach GDP.

IQ-Protokoll. Nachweis, dass das System gemäß Spezifikation installiert wurde: Version, Datenbank, Server, Konfiguration, Schnittstellen. Eine Checkliste mit Belegen reicht aus.

OQ-Protokoll. Nachweis, dass die Kernfunktionen wie spezifiziert arbeiten – getestet gegen die URS. Sie müssen nicht jede Funktion prüfen, sondern die GxP-kritischen: Wareneingang mit Quarantäne, Freigabe-Workflow, Chargenverbuchung, Audit-Trail-Integrität, Schnittstellenverhalten.

PQ-Protokoll. Nachweis, dass das System unter realen Bedingungen leistet, was es soll – oft als dokumentierter Probebetrieb über mehrere Wochen. GAMP5 erlaubt ausdrücklich, IQ, OQ und PQ als kombinierten Test zu führen, was in der KMU-Praxis häufig der wirtschaftlichere Weg ist.

Periodic Review. Eine regelmäßige Überprüfung, ob der validierte Zustand noch passt – etwa alle 12 bis 24 Monate, mit Bericht.

Diese Kette ist nicht trivial, aber auch nicht das, was manche Beratungsangebote unter „GAMP5-Validierung" verstehen. Wer zehn Ordner mit jeweils hunderten Seiten anbietet, hat selten den Mittelstand im Kopf.

Was eine Compliance-by-Design-Architektur an der Kategorie-4-Bürde spart

Der Umfang der Konfigurationsspezifikation und der OQ hängt direkt davon ab, wie viele GxP-kritische Funktionen selbst konfiguriert oder über Add-ons zusammengeführt werden müssen. Ist Quarantäne im Datenmodell ein primärer Bestandsstatus statt eines separat konfigurierten Moduls, ist der Audit-Trail ein einziger durchgehender Strom statt mehrerer Teilprotokolle je Komponente, und laufen securPharm-Verifikation und temperaturgeführte Lagerplatz-Logik nativ statt über Schnittstellen Dritter – dann verkürzt das die Zahl der Testfälle, die eine eigene OQ überhaupt erst prüfen muss. Wie stark eine fragmentierte Architektur diesen Aufwand umgekehrt aufbläht, zeigt Warenwirtschaft mit Add-ons vs. Compliance by Design.

Ein zweiter, oft übersehener Gradmesser ist die Kooperationsbereitschaft des Lieferanten selbst. Ein Anbieter, der auf Wunsch ergänzende Information zu Systemarchitektur und Entwicklungsprozess bereitstellt – als optionale Unterstützung, nicht zwingend als Standardumfang –, macht die eigene Erst- und Folgevalidierung tendenziell leichter. Ein Anbieter, der dazu grundsätzlich nicht in der Lage oder bereit ist, ist intern mit einem entsprechend höheren Compliance-Risiko zu bewerten.

Drei Anti-Muster, die KMU regelmäßig in die falsche Richtung schicken

Erstens: „Wir validieren lieber zu viel als zu wenig." Über-Validierung ist nicht risiko-neutral. Sie bindet Ressourcen, macht jedes Update aufwändig und führt am Ende dazu, dass die Validierung nicht mehr gelebt wird. Ein Periodic Review, der Wochen dauert, wird einmal gemacht und danach nicht wiederholt.

Zweitens: „Wir validieren alles selbst, weil wir dem Lieferanten nicht trauen." Reicht das Vertrauen nicht aus, um Lieferanten-Tests dokumentiert einzubinden, ist das eher ein Signal, den Lieferanten zu wechseln, als jede Standardfunktion parallel selbst zu testen. Reicht es, sollte die eigene Arbeit auf das beschränkt bleiben, was nur der eigene Betrieb prüfen kann: die eigene Konfiguration und den Live-Betrieb.

Drittens: „Validierung ist Aufgabe der IT." Die GxP-Verantwortung liegt bei der Verantwortlichen Person, nicht bei der IT. Eine Validierung, die ohne Einbindung von VP, Qualitätssicherung und Fachabteilungen entsteht, ist im Audit angreifbar – auch wenn sie umfangreich ausfällt. Wie sich diese Kontinuität auch über einen Systemwechsel hinweg halten lässt, behandelt Systemwechsel im regulierten Großhandel.

Fazit

GAMP5 ist für den Mittelstand machbar – es ist sogar so konzipiert, dass kleinere Betriebe mit konfigurierter Standard-Software einen pragmatischen, risikobasierten Weg gehen können. Was es verlangt, ist Disziplin: dokumentieren, was tatsächlich getan wird, nachvollziehbar machen, warum, und dafür sorgen, dass die Dokumentation lebt statt in einer Schublade zu altern.

Was es nicht verlangt, ist Über-Engineering. Eine realistische Validierung für eine pharmazeutische KMU-Warenwirtschaft umfasst eine überschaubare Dokumentenmenge, einen klaren Risiko-Fokus und eine ehrliche Lieferantenbewertung. Das ist es, was Inspektoren sehen wollen – eine knappe Strecke mit Substanz, nicht zehn Ordner mit Volumen.