GAMP 5 Kategorie 4 für probabilistische Entscheidungs-Engines — warum "konfigurierbar" die richtige Klassifizierung ist

1. Zusammenfassung

GAMP 5 — Good Automated Manufacturing Practice Version 5, herausgegeben von der ISPE — ist der De-facto-Industriestandard für die Computersystemvalidierung (CSV) in regulierten pharmazeutischen Umgebungen. Sein Kategorierahmen (1 bis 5) bestimmt Tiefe und Umfang der Validierungstätigkeit. Probabilistische Entscheidungs-Engines für pharmazeutische Abläufe sind eine neue Softwareklasse, die sich nur schwer in die bestehenden Kategorien einfügt: Sie sind weder einfache parametrisierte Werkzeuge (Kat 3) noch vollständig maßgeschneiderte Entwicklungen (Kat 5).

Dieses Papier argumentiert, dass Kategorie 4 — konfigurierbare Software — die korrekte Klassifizierung für Engines wie Synlogicas GRIP ist, bei der die deterministische Regelschicht (SOP, GxP-Gates) und die probabilistischen Modellparameter (Arrhenius-Koeffizienten, Bayesian-Priors, Monte-Carlo-Verteilungen) mandantenspezifisch konfigurierbar sind, die zugrunde liegende Engine — die probabilistische Mathematik, der Regelausführungsgraph, das Format des Entscheidungspakets — jedoch einmal vom Anbieter qualifiziert und von jedem Kunden unverändert genutzt wird.

Die Klassifizierung ist wichtig, weil sie den Validierungsaufwand abgrenzt. Eine Klassifizierung als Kat 5 (kundenspezifisch) würde vom Kunden verlangen, die Interna der Engine gegen seine spezifischen Anforderungen zu validieren (typischerweise 200–400 Personentage Aufwand). Eine korrekte Kat-4-Klassifizierung begrenzt die kundenseitige Validierung auf die Konfigurationsschicht (typischerweise 40–80 Personentage) und akzeptiert die Qualifizierung der Engine selbst durch den Anbieter.

2. GAMP 5 Kategorien — eine Auffrischung in 90 Sekunden

GAMP 5 Second Edition (2022) beschreibt fünf Kategorien computergestützter Systeme, jeweils mit einem empfohlenen Validierungsansatz:

(Kategorie 2 wurde in der Second Edition entfernt; die Nummerierung 1, 3, 4, 5 wird zur Rückwärtsreferenz beibehalten.) Der Rahmen ist risikobasiert: Der Validierungsaufwand sollte dem GxP-Einfluss, der Komplexität und der Neuartigkeit des Systems entsprechen.

Kategorie 4 verdient besondere Aufmerksamkeit, weil sie betrieblich am wichtigsten ist: Sie umfasst die Systeme, die Pharma-Teams tatsächlich täglich nutzen (ERP, LIMS, MES) und nun zunehmend auch die darauf aufsetzenden Entscheidungssysteme.

3. Die Klassifizierungsherausforderung für probabilistische Engines

Probabilistische Entscheidungs-Engines erschweren die übliche Diskussion zwischen Kat 3, Kat 4 und Kat 5 auf drei Weisen:

3.1 Die Engine ist dieselbe; die Parameter sind es nicht

Jeder Kunde von Synlogica Terminus nutzt dieselbe GRIP-Engine-Version — der Monte-Carlo-Sampler, die Bayesian-Update-Logik, der Arrhenius-Integrator sind über alle Mandanten hinweg bit-identisch. Was sich unterscheidet, ist die Konfiguration: mandantenspezifische Arrhenius-Parameter für das API-Portfolio, mandantenspezifische Bayesian-Priors für die Lieferantenelastizität, mandantenspezifische Monte-Carlo-Eingangsverteilungen für das Lane-Risiko. Dies ist das Lehrbuchmuster für Kat 4.

3.2 Probabilistische Ausgaben sind über Läufe hinweg nicht bit-identisch (beabsichtigt)

Eine mit einem zufälligen Anfangszustand initialisierte Monte-Carlo-Simulation erzeugt von Lauf zu Lauf statistisch gleichwertige, aber nicht bit-identische Ausgaben. Auf deterministische Software geschulte Inspektoren werten dies manchmal als Nicht-Reproduzierbarkeit, was eine Part-11-Problematik wäre. Die korrekte Antwort: Die Engine initialisiert die Simulation pro Entscheidung deterministisch (z. B. mittels SHA-256 der Eingangsdaten-Herkunft), sodass jede Entscheidung bit-genau wiederholt werden kann, auch wenn sich zwei voneinander unabhängige Läufe unterscheiden würden.

3.3 Die Entscheidungs-Policy-Schicht ist Risikotoleranz-Konfiguration, kein kundenspezifischer Code

„Freigabe empfehlen, wenn die Wahrscheinlichkeit einer Schwellenüberschreitung unter 5 % liegt UND die Charge nicht steril ist UND die Produktklasse Klasse B ist“ sieht aus wie kundenspezifische Logik, ist aber die Konfiguration einer generischen Policy-DSL. Solange die DSL selbst qualifiziert ist und die Konfiguration wie jede Kat-4-Konfiguration validiert wird, ist dies kein Kat 5.

Das Risiko einer Fehlklassifizierung ist symmetrisch: Unterklassifizierung (z. B. Kat 3) und der Inspektor fragt nach fehlenden Validierungsnachweisen; Überklassifizierung (Kat 5) und das Team verbringt Personenjahre damit, zu validieren, was der Anbieter bereits qualifiziert hat.

4. Warum Kategorie 4 (konfigurierbar) die richtige Wahl ist

Die Eignung von Kategorie 4 beruht auf drei Beobachtungen:

4.1 Das Produkt existiert unabhängig von einem einzelnen Kunden

GRIP wird von Synlogica als Produkt entwickelt und qualifiziert. Jeder Kunde erhält dieselbe Engine-Binärdatei, dieselben Algorithmus-Implementierungen, dasselbe Format des Entscheidungspakets. Dies ist der definitorische Test für Kategorie 4 gegenüber Kategorie 5: Ein Kat-5-System wird für einen einzelnen Kunden gebaut; ein Kat-4-Produkt wird einmal gebaut und von vielen genutzt.

4.2 Die Konfigurationsoberfläche ist strukturiert, nicht beliebig

Kunden konfigurieren GRIP über eine definierte Oberfläche: Regelsätze (deklariert in einer strukturierten DSL), Modellparameter (typisierte Eingaben mit Validierungsregeln), Policy-Konfigurationen (ausgewählt aus einem dokumentierten Satz von Policy-Vorlagen mit Risikotoleranz-Parametern), Datenintegrations-Endpunkte (über eine Konnektorschicht abgebildet). Sie schreiben keinen Code in GRIP. Sie verändern die Interna der Engine nicht.

4.3 Anbieter-Qualifizierungspakete existieren und sind auditfähig

Der Anbieter (Synlogica) pflegt für GRIP eine GAMP-5-Kategorie-4-Qualifizierungsdokumentation — Design-Qualifizierung, Code-Review-Aufzeichnungen, Unit- und Integrationstestberichte, Qualifizierungsprotokolle, Release Notes je Version. Diese werden Kunden unter DPA als Teil des Trust Packs zur Verfügung gestellt. Der Validierungsaufwand des Kunden baut auf diesen Nachweisen auf, statt sie zu duplizieren.

Die Kombination — Produktklasse-Software, strukturierte Konfigurationsoberfläche, Anbieter-Qualifizierungsnachweise — ist genau das Muster, für das Kategorie 4 definiert wurde.

5. Was sich gegenüber Kategorie 5 (kundenspezifisch) ändert

Die praktischen Unterschiede zwischen den Aufwandsniveaus von Kat 4 und Kat 5 sind erheblich:

Der Kat-4-Ansatz ist nicht „weniger rigoros“; er ist „Rigorosität zwischen Anbieter und Kunde aufgeteilt“. Die Rigorosität des Kunden konzentriert sich auf die Konfigurationsvalidierung (die der Anbieter nicht für ihn übernehmen kann), und die Rigorosität des Anbieters konzentriert sich auf die Qualifizierung der Engine (die je Kunde zu duplizieren verschwenderisch wäre).

6. Validierungsleistungen, die ein Kunde erwarten sollte

Vom Anbieter (als Teil des Trust Packs):

• Lieferanten-Audit-Dossier — einschließlich ISO-9001-/ISO-27001-Status, Dokumentation des Entwicklungslebenszyklus, Code-Review- und Change-Control-Aufzeichnungen.
• GRIP-Qualifizierungsprotokoll und -bericht — Design-Qualifizierung, Unit-Test-Abdeckung, Integrationstest-Abdeckung, Performance-Qualifizierung.
• Release Notes je Version — was sich in der Engine geändert hat, was sich in der Regel-DSL geändert hat, was sich in der Policy-DSL geändert hat, was sich im Format des Entscheidungspakets geändert hat. Versioniert nach SemVer.
• Traceability-Matrix — Anforderung → Design → Code → Test, gepflegt für jedes Release.
• Risikobewertung für probabilistische Ausgaben — abdeckend den Mechanismus der deterministischen Initialisierung (Seeding) und die Konvergenzgarantien für Monte-Carlo-/Bayesian-Updates.

Vom Kunden (mit Anbieterunterstützung erstellt):

• User Requirements Specification (URS) — auf den bestimmungsgemäßen Gebrauch zugeschnitten: welche Geschäftsentscheidungen mit Terminus getroffen werden.
• Funktionale Risikobewertung — GxP-Einfluss je Entscheidungsklasse, Kontrollen je Einflussstufe.
• Konfigurationsspezifikation — die spezifischen Regeln, Parameter und Policies des Kunden, mit Begründung.
• IQ / OQ Skripte — fokussiert auf die Konfigurationsschicht und die Integration in bestehende Systeme (eQMS, ERP, TMS).
• PQ (Performance Qualification) — End-to-End-Szenarien, die bestätigen, dass das konfigurierte System die beabsichtigten Geschäftsentscheidungen unterstützt.
• Validierungs-Abschlussbericht — schließt den Validierungslebenszyklus ab und autorisiert die Produktivnutzung.

7. Validierung probabilistischer Logik — die spezifischen Herausforderungen

7.1 „Gleiche Eingabe, gleiche Ausgabe“ — der Reproduzierbarkeitstest

Probabilistische Systeme können auf bit-genaue Reproduzierbarkeit validiert werden, indem der Zufalls-Sampler deterministisch initialisiert wird. Der Test: Ein Entscheidungspaket, das gegen dieselbe Engine-Version mit denselben Eingaben wiederholt wird, muss dieselbe Ausgabe erzeugen. GRIP erreicht dies durch SHA-256-abgeleitete Initialisierung. Der Validierungsnachweis ist ein Reproduzierbarkeitsprotokoll, das N Produktionsentscheidungen wiederholt und identische Ausgaben bestätigt.

7.2 „Was passiert, wenn Eingaben sich verschlechtern?“ — der Robustheitstest

Probabilistische Engines benötigen explizite Tests dafür, was passiert, wenn Eingangsdaten fehlen, verrauscht sind oder außerhalb der erwarteten Bereiche liegen. Das erwartete Verhalten ist die kontrollierte Verweigerung einer Empfehlung statt einer Empfehlung auf Basis angenommener Eingaben. GAMP-5-OQ-Skripte für probabilistische Systeme sollten negative Tests enthalten, die Datennichtverfügbarkeit, Sensoranomalien und Parameterdrift abdecken.

7.3 „Woher wissen wir, dass das Modell richtig ist?“ — der Kalibrierungstest

Abzugrenzen von der Validierung im regulatorischen Sinne. Bei der Kalibrierung geht es darum, ob die Vorhersagen des Modells mit der Realität übereinstimmen (z. B. ob Sendungen, die als zu 95 % wahrscheinlich pünktlich klassifiziert werden, tatsächlich in 95 % der Fälle pünktlich ankommen). Dies ist eine fortlaufende Aufgabe des Performance-Monitorings, getrennt von der Validierung. Die Validierungsfrage lautet „setzt das System das beabsichtigte Modell korrekt um“; die Kalibrierungsfrage lautet „ist das beabsichtigte Modell selbst für unsere Abläufe genau“.

7.4 „Was ändert sich, wenn die Engine-Version aktualisiert wird?“ — der Auswirkungstest

Wenn der Anbieter eine neue Engine-Version veröffentlicht, benötigt das Validierungsteam des Kunden eine Auswirkungsbewertung: Hat sich das algorithmische Verhalten geändert, hat sich die Semantik der Regel-DSL geändert, hat sich das Format des Entscheidungspakets geändert? Die GRIP-Versionierung folgt SemVer: Patch-Versionen sind für gültige Eingaben bit-äquivalent, Minor-Versionen erweitern ohne Bruch, Major-Versionen können die Semantik ändern und eine kundenseitige Revalidierung der betroffenen Konfigurationen auslösen.

8. Laufende Kontrollen und Change Management

Kat-4-Systeme erfordern fortlaufende Validierungsdisziplin:

• Change Control — jede Konfigurationsänderung (neue Regel, modifizierter Parameter, aktualisierte Policy) durchläuft die Change Control mit Risikobewertung, Testplan, Freigabe und Verifizierung nach der Änderung.
• Periodische Überprüfung — typischerweise jährlich; bestätigt, dass die Konfiguration weiterhin zweckmäßig ist, die Benutzerliste aktuell ist, die Integrationen gültig bleiben.
• Incident Management — jede Anomalie eines Entscheidungspakets wird protokolliert, untersucht und auf ihre Grundursache zurückgeführt. Anomalien, die auf die Konfiguration zurückgehen, liegen kundenseitig; Anomalien, die auf die Engine zurückgehen, liegen anbieterseitig und lösen eine Support-Eskalation aus.
• Anbieter-Änderungsbenachrichtigung — der Anbieter informiert über jedes Release. Das Validierungsteam des Kunden bewertet die Auswirkung und entscheidet über den Umfang der Revalidierung.
• Kontinuierliches Performance-Monitoring — Kalibrierungsmetriken (vorhergesagt vs. tatsächlich) werden periodisch berichtet; eine signifikante Drift löst eine Neujustierung der Konfiguration aus.

Der größte Fehler in der laufenden Validierung von Kat 4 besteht darin, sie als einmaliges Ereignis zu behandeln. Das System wird bei Go-live qualifiziert; laufende Kontrollen halten es über Änderungen hinweg qualifiziert. Die Validierungsreife bemisst sich an der Disziplin dieser laufenden Kontrollen, nicht an der Tiefe der ursprünglichen Qualifizierung.

9. Kernaussagen

1. GAMP 5 Kategorie 4 (konfigurierbar) ist die korrekte Klassifizierung für probabilistische Entscheidungs-Engines wie GRIP, bei denen die Engine vom Anbieter qualifiziert wird und Kunden Regeln, Parameter und Policies konfigurieren.
2. Eine Überklassifizierung als Kat 5 (kundenspezifisch) erhöht den Validierungsaufwand um das 3–5-Fache, ohne Compliance-Mehrwert für Produktklasse-Software mit strukturierten Konfigurationsoberflächen zu schaffen.
3. Anbieterseitige Qualifizierungsdokumentation (Lieferantenaudit, Qualifizierungsprotokoll, Release Notes, Traceability) muss unter DPA verfügbar sein und von kundenseitigen Validierern als Nachweis vertraut werden.
4. Probabilistische Logik erfordert spezifische Validierungsmuster: deterministische Initialisierung (Seeding) für die Reproduzierbarkeit, negative Tests für die Verschlechterung von Eingaben, versionskontrollierte Engine-Releases mit dokumentierter SemVer-Semantik.
5. Kalibrierung (Modellgenauigkeit im Produktivbetrieb) ist von der Validierung (korrekte Umsetzung) getrennt; beide sind wichtig, erfordern aber unterschiedliche Kontrollen.
6. Laufende Kontrollen — Change Control, periodische Überprüfung, Incident Management, Anbieter-Änderungsbenachrichtigung — sind der Maßstab für die Reife von Kat 4.