Concept Paper Revision Annex 11 – das Wichtigste im Überblick

27. April 2023

Eine Beitrag von Dr. Stephan Müller, Senior Consultant, DHC Dr. Herterich & Consultants GmbH

Im September 2022 wurde von der EMA und PIC/S das Concept Paper zur Revision von Annex 11 Computerised Systems zu den Leitlinien der guten Herstellungspraxis veröffentlicht.

Obwohl der geplante Termin für die Implementierung der neuen Version von Annex 11 erst Juni 2026 ist, will ich hier einige Änderungsvorschläge und deren mögliche Auswirkungen diskutieren. Bis 2026 ist zwar noch etwas Zeit, aber die neue Version des Annex 11 ist in Arbeit, und es ist auch noch möglich, auf die finale Formulierung Einfluss zu nehmen. Nach der bisherigen Zeittafel ist für Dezember 2024 eine Version zur Konsultation geplant, zu der bis März 2025 Kommentare abgegeben werden können.

Ziel der Revision ist es unter anderemn die regulatorischen Anforderungen an die digitale Transformation zu definieren und neue Technologien zu berücksichtigen.

Im Folgenden stelle ich einige aus meiner Sicht wichtige Punkte des Konzeptpapiers vor.

Externe Dienstleister (einschließlich Cloud Dienstleistungen)

Im Punkt 3.1 der aktuellen Version des Annex 11 steht sinngemäß: „Wenn Dritte in die Bereitstellung und / oder den Betrieb eines computergestützten Systems involviert sind, muss eine formale Übereinkunft zwischen reguliertem Unternehmen und Dienstleister existieren, die unter anderem die Verantwortlichkeiten klar definiert. IT-Abteilungen sollen wie externe Dienstleister betrachtet werden.“

Abbildung 1: Punkt 7 aus dem Konzeptpapier

Das Konzeptpapier sagt nun, dass eine formale Übereinkunft nicht ausreicht. Hier wird gefordert, dass das regulierte Unternehmen Zugang zur vollständigen Dokumentation zur Validierung/Qualifizierung und zum sicheren Betrieb des Systems haben muss. Diese Dokumentation muss bei regulatorischen Inspektionen präsentiert werden können.

Das bedeutet, dass der Dienstleister diese Dokumentation erstellen und pflegen muss. Dabei ergibt sich die Herausforderung, dass die Dienstleister in der Regel zwar dokumentieren, diese Dokumentation aber meist nicht in der traditionellen Form von Dokumenten aus dem V-Modell erfolgt. Hier muss begründet werden, dass die Dokumentation den regulatorischen Ansprüchen genügt.

Oft werden die Aktivitäten in lokalen Systemen (z.B. ITSM-Tools) beim Dienstleister dokumentiert. Um die Anforderung zu erfüllen, diese Dokumentation während einer Inspektion präsentieren zu können, muss der Zugang zu diesen Informationen für das regulierte Unternehmen geregelt sein. Das kann beispielsweise dadurch realisiert werden, dass ein Mitarbeiter des Dienstleisters während der Inspektion verfügbar ist, der Zugriff auf die Dokumentation hat.

Agile Entwicklungsmethoden

In Punkt 4.4 fordert die aktuelle Version von Annex 11, dass Benutzeranforderungen vorhanden sind und dass diese über den gesamten Lebenszyklus zurückverfolgt werden können.

Abbildung 2: Punkt 11 des Konzeptpapiers

Diese Anforderung wird im Konzeptpapier erweitert: Benutzeranforderung oder ähnliche Dokumente, die die gesamten implementierten und geforderten GMP kritischen Funktionen beschreiben, sollten die Basis für jegliche Qualifizierung oder Validierung des Systems sein unabhängig davon, ob das regulierte Unternehmen oder der Lieferant diese durchführt. Diese Benutzeranforderungen sollten über den gesamten Lebenszyklus aktuell gehalten werden. Es sollte eine dokumentierte Traceability zwischen den Benutzeranforderungen, eventuell vorhandenen funktionalen Spezifikationen und Testfällen geben.

Im folgenden Punkt sagt das Konzeptpapier, dass Akzeptanzkriterien für die Artefakte von agilen Entwicklungsprozessen in der neuen Revision von Annex 11 definiert werden sollen. Diese Artefakte müssen dann die oben gestellten Anforderungen an die User Requirements erfüllen (aktuell über den gesamten Lebenszyklus, Traceability über Anforderungen, Spezifikationen und Testfällen).

Ich bin nicht sicher, ob die im Rahmen von agilen Entwicklungen erstellten Artefakte, wie Use Cases, Testskripte immer alle diese Anforderungen erfüllen. Insbesondere sehe ich eine Herausforderung darin, eine über den Lebenszyklus aktuelle Beschreibung der Systemanforderungen zu erhalten und dafür die dokumentierte Traceability zu gewährleisten.

Man kann jedenfalls gespannt sein, wie diese Akzeptanzkriterien definiert werden. Dabei sollte der Ansatz aus GAMP 5 2nd Edition berücksichtigt werden.

Abbildung 3: GAMP 5 2nd Edition (C) 28.3.1 Agile Basics

Audit Trail

Viele Punkte des Konzeptpapiers beziehen sich auf das Thema Audit Trail und Audit Trail Review. Ein wichtiges Statement ist: „Any grace period within this has long expired” (Annex 11 Revision 2 wurde 2011 veröffentlicht und 21 CFR Part 11 wurde 1997 veröffentlicht.). Es wird nochmal klar gefordert, dass der Audit Trail enthalten muss, wer, wann und was (alter Wert/neuer Wert) gemacht hat und warum das gemacht wurde (wenn es nicht offensichtlich ist).

Abbildung 4: Punkt 23 des Konzeptpapiers

Weiterhin werden Details für den Inhalt des Audit Trails vorgeschlagen (z.B., wenn das System aufgrund einer inkonsistenten Eingabe eine Fehlermeldung zeigt und der User darauf die Eingabe korrigiert, soll dies im Audit Trail erfasst werden). Da bin ich mir relativ sicher, dass die wenigsten Audit Trail Implementierungen so weit gehen. Aus meiner Sicht ist diese Detailtiefe auch nicht notwendig. Ich bin auch mal gespannt, wie Betriebsräte mit dieser Detaillierung beim Audit Trail umgehen.

Für den Audit Trail Review sollen Vorgaben für die Häufigkeit und den Inhalt gemacht werden. Es wird auch vorgeschlagen, dass der Audit Trail Review im Rahmen der Chargenfreigabe gemacht werden soll.

Weiterhin soll es möglich sein, Systemalarme oder Systemevents von den Audit Trail Daten zu trennen, um den Audit Trail Review einfacher zu machen.

IT Security

Abbildung 5: Punkt 26 des Konzeptpapiers

Während die aktuelle Version von Annex 11 sich nur auf die Beschränkung des Systemzugangs für berechtigte Personen fokussiert, wird für die neue Revision ein Abschnitt vorgeschlagen, der sich mit dem Thema IT-Sicherheit befasst, wie sie in der ISO 27001 definiert ist. Dabei soll der Fokus auf die Themen Vertraulichkeit, Integrität und Verfügbarkeit gelegt werden. Weiterhin sollen die erwarteten Tools, wie beispielsweise Multi-Faktor Authentifizierung, Firewalls, Plattformmanagement, Sicherheitspatches, Virenscanner und Intrusion Detektion/Prevention benannt werden.

Das kann darauf hinauslaufen, dass ein IT-Sicherheitsmanagement nach der ISO 27001 gefordert wird (mit oder ohne Zertifikat).

Sinnvoll sind diese Anforderungen auf jeden Fall, wenn man bedenkt, welchen Schaden kriminelle Angriffe auf die Computersysteme anrichten können und welche Bedeutung die Versorgung mit medizinischen Produkten für die Bevölkerung hat. Die Erfahrung zeigt, dass selbst renommierte Unternehmen nicht sicher sind vor Ransomware angriffen, die den IT-Betrieb und damit den gesamten Betrieb über mehrere Tage stilllegen können.

Weitere Anforderungen verlangen die Berücksichtigung der Prinzipien von

„Segregation of duties“

Rollenabhängige Berechtigungen: Administrator kann keine Funktionen des täglichen Betriebs eingeben, Konfiguration von Messungen ist getrennt von Ausführung von Messungen, Ausführung von Messungen ist getrennt von Prüfung und Freigabe

„least privilege principle“

Ein User hat nur so viele Berechtigungen, wie er wirklich braucht.

Der Nachweis, dass diese Anforderungen bei der Implementierung eines Systems berücksichtigt sind, kann abhängig vom System zu einer Herausforderung werden.

Dann wird auch gefordert, dass der Systemzugriff kontinuierlich verwaltet wird und beispielsweise das Ausscheiden von Personen zeitnah berücksichtigt wird. Zusätzlich soll der Systemzugriff regelmäßig geprüft werden, um sicherzustellen, das vergessene und unerwünschte Zugriffe entfernt werden. Damit kann man verhindern, dass beispielsweise ein Trainee, wenn er alle Abteilungen durchlaufen hat, auch die maximal mögliche Menge an Berechtigungen hat.

Weitere Punkte

Es sollte Bezug auf die aktuelle Version der ICH Q9 Risikomanagement genommen werden.
Es werden die Anforderungen an Backup und Archivierung genauer spezifiziert. Dabei wird auf die Lesbarkeit von Daten über die gesamte Aufbewahrungszeit Wert gelegt.
Weiterhin sollen die regulatorischen Anforderungen und Erwartungen an die Verwendung von Künstlicher Intelligenz und Maschinenlernen in kritischen GMP-Anwendungen definiert werden.
Schließlich soll auch berücksichtigt werden, welchen Einfluss der Draft Guidance der FDA zur Computer Software Assurance hat.

Die hier vorgeschlagenen Änderungen können großen Einfluss auf die Validierung und den Betrieb von computergestützten Systemen und den damit verbundenen Aufwand haben.

Daher empfiehlt es sich, den Fortgang der Entwicklung der neuen Revision von Annex 11 im Auge zu behalten. Insbesondere ist geplant, dass im Dezember 2024 eine Version vorhanden ist, zu der Kommentare abgegeben werden können. Bis März 2025 wäre dann Zeit, nochmals Einfluss auf die endgültige Formulierung der neuen Revision zu nehmen.

Zu der neuen Version sollen auch Diskussionen mit interessierten Parteien stattfinden. Zu den interessierten Parteien gehören auch die pharmazeutische Industrie, internationale Gesellschaften und Interessengruppen in der pharmazeutischen Industrie, wie beispielsweis ISPE GAMP.

Das Konzeptpapier finden Sie im Internet unter

GAMP5 2nd Edition können Sie erwerben unter: https://ispe.org/publications/guidance-documents/gamp-5-guide-2nd-edition

Zu den Neuerungen in GAMP 5 2nd Edition haben wir im Jahr 2022 eine Websession durchgeführt. Die Aufzeichnung dieser Websession können sie bei uns anfordern: Websession-Podcasts anfordern | DHC Consulting (dhc-consulting.com)