GAMP 5 1st vs 2nd Edition: Änderungen einordnen

Was zur zweiten Ausgabe belastbar eingeordnet werden kann

Die öffentliche ISPE-Produktseite nennt Juli 2022 als Veröffentlichungsdatum. Der begleitende ISPE-Beitrag vom August 2022 erklärt, dass Grundrahmen, zentrale Konzepte und der an ICH Q9 ausgerichtete Risikomanagementansatz fortbestehen. Die erste Ausgabe wird damit nicht sinnvoll als rein starres, risikofreies Gegenmodell beschrieben.

Der folgende Vergleich konzentriert sich auf öffentlich belegte Schwerpunkte. Er ist kein vollständiger Abgleich jeder Buchpassage. Für eine genaue Änderung Ihrer internen GAMP-Verweise benötigen Sie zusätzlich die tatsächlich zugänglichen Originalausgaben. Ein Inhaltsverzeichnis bestätigt ein Thema, aber nicht dessen vollständige fachliche Aussage.

Quellen: [1] [2] [3]

Fortführung und neue Schwerpunkte unterscheiden

Die Tabelle hilft bei der ersten Sichtung Ihres Vorgehens. Ihre rechte Spalte ist eine eigene Arbeitsfrage, keine von ISPE vorgeschriebene Checkliste. Entscheidend ist, ob ein Schwerpunkt Ihre eingesetzte Architektur oder Ihre tatsächliche Projektmethode betrifft. Ein Unternehmen ohne entsprechende Technik muss keine künstlichen Arbeitspakete erzeugen.

Quellen: [1] [2]

Die eigene SOP auf Entscheidungen statt Überschriften prüfen

Für den Humanarzneimittel-GMP-Einsatz bietet Annex 11 den hier verwendeten regulatorischen Bezug. Die GAMP-Methodik ist davon zu unterscheiden.

Beginnen Sie mit einer tatsächlich angewendeten Validierungs-SOP. Markieren Sie Stellen, die unabhängig vom Risiko immer dasselbe Dokument oder dieselbe Testform verlangen. Fragen Sie anschließend, welchem Nachweiszweck diese Vorgabe dient. Eine Unterschrift bestätigt beispielsweise eine Entscheidung; sie behebt keine fehlende fachliche Bewertung.

Behalten Sie hilfreiche Kontrollen. Ändern Sie eine Vorgabe erst, wenn der alternative Ablauf Anforderungen, Verantwortlichkeit und Prüfbarkeit angemessen erhält. Halten Sie auch Gründe für unveränderte Regeln fest. Das verhindert, dass ein Modernisierungsprojekt nur alte Pflichtfelder durch neue Pflichtfelder ersetzt.

Quellen: [4]

Anbieterbelege nicht pauschal wiederholen oder übernehmen

Prüfen Sie bei einem vorhandenen Testpaket zunächst Gegenstand, Version, Konfiguration, Umgebung und Ergebnis. Ein Nachweis kann Ihre Anforderung vollständig, teilweise oder gar nicht abdecken. Die Entscheidung sollte am Beleg hängen und nicht an der Annahme, Anbieter testeten grundsätzlich nur Standardfunktionen.

Für eine kundenspezifisch konfigurierte Freigaberegel kann beispielsweise ein geeigneter Fremdtest genau den benötigten Fall enthalten. Dann bleibt die Übertragbarkeit zu begründen. Fehlt hingegen die angebundene Schnittstelle, braucht diese Lücke einen eigenen passenden Nachweis. Wiederholung und Übernahme sind beide Entscheidungen mit Begründungsbedarf.

Quellen: [4] [1]

Illustratives Beispiel: Ein neues Statusfeld im laufenden Projekt

Ein fiktiver Hersteller führt ein zusätzliches Sperrkennzeichen in seinem Materialprozess ein. Das vorab festgelegte Soll lautet: Ein gesperrter Datensatz darf über die operative Schnittstelle nicht als verwendbar weitergegeben werden. Der vorhandene Anbietertest prüft die lokale Sperranzeige, aber nicht die angeschlossene Schnittstelle. Das Beispiel beschreibt keinen ausgeführten Produkttest.

Der sinnvolle Anpassungsauftrag ist hier begrenzt: vorhandenen Anzeigebeleg bewerten, Schnittstellenmapping spezifizieren und den Übergang einschließlich Wiederholung prüfen. Eine bloße Umbenennung des Testprotokolls in „Assurance“ bringt dafür keinen zusätzlichen Erkenntnisgewinn.

Quellen: [4]

Bestehende Systeme nach ihrem Zustand beurteilen

Ein bereits betriebenes System benötigt keine neue Begründung allein deshalb, weil eine Buchausgabe erschienen ist. Das bedeutet jedoch nicht, sein validierter Zustand bleibe automatisch erhalten. Änderungen, Nutzung, Vorfälle und vorhandene Kontrolllücken können zusätzliche Aktivitäten erforderlich machen.

Nutzen Sie eine anstehende periodische Bewertung, um den tatsächlichen Stand einzuordnen. Trennen Sie dabei eine redaktionell veraltete Methodenreferenz von einer fehlenden fachlichen Absicherung. Diese Unterscheidung hilft, ein überholtes Deckblatt nicht gleichrangig mit einer ungeprüften kritischen Schnittstelle zu behandeln.

Quellen: [4]

Iterationen brauchen einen erkennbaren Bezugsstand

Für ein iteratives Projekt empfiehlt sich eine eindeutige Verbindung zwischen Anforderung, Konfiguration, Prüfung und dem bewerteten Lieferstand. Ein Test aus dem vorigen Inkrement kann weiter passen. Entscheidend ist, ob die nachfolgende Änderung seine Aussage beeinflusst.

Ein kleines Team kann dafür ein gemeinsames Änderungs- und Nachweisregister verwenden. Darin stehen betroffene Funktionen, vorhandene Evidenz, zusätzliche Prüfung und die Entscheidung zur Nutzung. Dieses Register ist eine Arbeitshilfe; aus der gewählten Methode entsteht kein Zwang zu einem bestimmten Werkzeug oder drei getrennten Akten.

Quellen: [1] [4]

Was Ihr Team vor der Anpassung zusammentragen sollte

QA erklärt die anwendbaren Anforderungen und den internen Freigabeweg. IT und System Owner beschreiben Architektur, Änderungen und Anbieterleistungen. Der Fachbereich entscheidet, welches Verhalten den Prozess tatsächlich schützt. Erst diese Zusammenarbeit macht aus einem allgemeinen Editionsvergleich einen belastbaren Arbeitsauftrag.

Der Aufwand hängt vor allem davon ab, wie gut die heutige Nutzung, die Belege und die Verantwortlichkeiten beschrieben sind. Fehlende Zuordnung verursacht meist mehr Klärungsarbeit als die reine Zahl vorhandener Dokumente. Starten Sie deshalb mit einem abgegrenzten Anwendungsfall und werten Sie die Entscheidung vor einer breiten SOP-Anpassung aus.

• Geltenden Regelbereich und interne Methodenreferenz benennen.
• Eine reale Entscheidung mit unklarem Nachweisumfang auswählen.
• Vorhandene Anforderungen, Risiken und Anbieterbelege bereitstellen.
• Änderungen am Vorgehen mit Verantwortlichem und Einführungsschritt festhalten.
• Wirkung der Anpassung am Nachweiszweck prüfen.

Quellen: [4]