Audit Trail im EU GMP Annex 11 und EMA Concept Paper zum Annex 11
Im aktuellen EU-GMP Annex 11 findet man zum Audit Trail gerade mal drei Sätze im Abschnitt 9 Audit Trails. Diese wenigen Hinweise haben immer wieder zu Problemen bei der Umsetzung gesorgt. Insofern besteht hier in der Tat Handlungsbedarf für einen neuen Annex 11. Ob die Hinweise im "Concept Paper on the revision of Annex 11 of the guidelines on Good Manufacturing Practice for medicinal products - Computerised Systems" ausreichend sind oder auch sinnvoll, soll im Folgenden erörtert werden.
Weshalb Audit Trails?
Zunächst soll der Sinn und Zweck der Audit Trail Forderung begründet werden. Die Forderung leitet sich aus den Vorgaben für die Papierdokumentation in EU-GMP Kapitel 4 bzw. der AMWHV (Arzneimittel- und Wirkstoffherstellungsverordnung) ab. Schauen wir zunächst in EU-GMP Kapitel 4:
EU-GMP Kapitel 4, 4.9
Jede Änderung einer Eintragung in einem Dokument sollte abgezeichnet und datiert sein. Trotz Änderung sollte die ursprüngliche Information lesbar bleiben. Sofern angezeigt, sollte der Grund für die Änderung protokolliert werden.
Interessant ist hier, dass der Grund der Änderung nicht zwingend notwendig ist. Das hat man im Annex 11 Abschnitt 9 Audit Trail nicht analog umgesetzt.
Eine entsprechende Vorgabe finden wir auch in der AMWHV:
AMWHV § 10 Allgemeine Dokumentation Der ursprüngliche Inhalt einer Eintragung darf nicht unleserlich gemacht werden. Es dürfen keine Veränderungen vorgenommen werden, die nicht erkennen lassen, ob sie bei der ursprünglichen Eintragung oder erst später gemacht worden sind.
Aus diesen Vorgaben heraus benötigen wir also eine Software- Funktionalität, die uns die Umsetzung dieser Vorgaben für die Papierdokumentation bietet (Abbildung 1 auf S. 5).
Der aktuelle Inhalt des EU-GMP Annex 11
Momentan findet man im Zusammenhang mit dem Audit Trail folgende Vorgaben:
9. Audit Trails
Basierend auf einer Risikobewertung sollte erwogen werden, die Aufzeichnung aller GMP-relevanten Änderungen und Löschungen in das System zu integrieren (ein systemgenerierter Audit Trail). Bei der Änderung oder Löschung GMP-relevanter Daten sollte der Grund dokumentiert werden. Audit Trails müssen verfügbar sein, in eine allgemein lesbare Form überführt werden können und regelmäßig überprüft werden.
Hier bereitet uns der erste Satz bei der Interpretation die meisten Probleme. Die beiden anderen Sätze sind eindeutig, reichen aber für eine ausreichende Regulierung nicht aus.
Was mit der Risikobewertung erreicht werden soll, wird immer wieder unterschiedlich interpretiert. Geht es nur um kritische Daten und wenn ja, welche Daten sind kritisch? Oder geht es darum festzulegen, welche Daten GMP-relevant sind? Oder geht es darum, ob es überhaupt die Möglichkeit gibt Daten zu ändern?
Abbildung 1
Keinen Spielraum gibt uns die Formulierung "aller GMP-relevanten Änderungen und Löschungen". Es kann also nicht nur um kritische Daten gehen, wobei GMP-Daten in der Regel sowieso kaum unkritisch sein können. Die Risikobewertung dient dazu zu entscheiden, ob ein Audit Trail überhaupt benötigt wird. In den meisten Fällen wird das letztendlich auch notwendig sein. Auf eine Audit Trail Funktionalität könnte beispielsweise in folgenden Fällen verzichtet werden:
- Eine Datenbank wird genutzt in der man die Daten nicht ändern kann sondern nur gelesen werden können.
- Ein Feldinstrument, dass Daten zu einem anderen System weiterleitet (z.B. MES) und das Instrument nur den Messwert erfasst. Hier wird für das Instrument selbst keine Audit Trail- Funktionalität benötigt für das MES natürlich schon.
- Eine einfache Steuerung ( SPS oder Mikrokontroller) beispielsweise eine Waschmaschine mit drei vorgegebenen Programmen und einem angeschlossenen Drucker, der die Rohdaten liefert.
Seminarempfehlung
Heidelberg14.-17. Mai 2024
Validierung computergestützter Systeme (CV 1) & SPS in der Pharmaindustrie (CV 10)
Ansonsten sollte man bei den heute eingesetzten Systemen und Ausrüstung in der Regel immer auch eine Audit Trail Funktionalität einfordern (URS). Diese Forderung findet man beispielsweise auch in PIC/S PI 041:
9.6 Audit trails for computerised systems
Companies should select software that includes appropriate electronic audit trail functionality.
Companies should endeavour to purchase and upgrade older systems to implement software that includes electronic audit trail functionality.
Ein anderes immer wieder diskutiertes Problem ergibt sich aus den unterschiedlichen Anforderungen für den Audit Trail. EUGMP Annex 11 ist eindeutig. Es geht um das Ändern und Löschen aller GMP relevanter Daten. Hier geht der US FDA Part 11 weiter (21 CFR Part 11 - 11.10(e)). Er fordert auch die Eingabe von Daten (create) im Audit Trail zu erfassen. Aus EU-Sicht ist das nicht erforderlich und macht den Audit Trail auch nicht unbedingt übersichtlicher. Wer welche Daten erfasst, muss natürlich bekannt sein, hat aber nichts mit der Audit Taril Funktionalität zu tun.
Audit Trail vs. System Log
Neben den in Abschnitt 9 geforderten Änderungen und Löschungen können noch viele andere Daten erfasst werden. Dies erfolgt dann im System Log oder in sogenannten Ereignisprotokollen. Beides hat nichts mit dem Audit Trail nach EU-GMP Annex 11 zu tun.
Logdateien (auch Systemprotokolle genannt) enthalten alle möglichen internen Systeminformationen (Betriebssystem oder Software). Unabhängig davon sind Log-Dateien (Logging), die Informationen über Benutzer registrieren und zwar speziell wann sich ein User eingeloggt oder ausgeloggt hat, zu sehen (Log in und Log off). Solche Log-Dateien werden speziell in EU-GMP Annex 11 unter 12.4 gefordert (Abbildung 2).
Abbildung 2
Diesen Hinweis findet man beispielsweise auch in GAMP® Records and Data Integrity Guide:
Der EU-GMP-Anhang 11 [7] fordert auch, dass elektronische Systeme die Identität der Person, die eine elektronische Aufzeichnung erstellt, zusammen mit Datum und Uhrzeit erfassen. Dies ist auch dann erforderlich, wenn kein Audit-Trail existiert.
Auch die GAMP® 5 2nd Edition verweist auf die Unterschiede zwischen Audit Trail und System Log:
Data audit trails, as required by various regulations, record operator actions that create, modify, or delete GMP records during normal operation, and should be clearly distinguished from other system and technical logs.
Audit Trail - Der Grund der Änderung
Der zweite Satz unter 9. Audit Trails fordert die Dokumentation des Grundes:
Bei der Änderung oder Löschung GMP-relevanter Daten sollte der Grund dokumentiert werden.
Hier hat man eigentlich die Vorgabe aus der Papierdokumentation, dass der Grund nur gegebenenfalls zu dokumentieren ist ignoriert (EU-GMP Kapitel 4, 4.9 … Sofern angezeigt, sollte der Grund für die Änderung protokolliert werden). Dies sollte in der Überarbeitung unbedingt angepasst werden.
Die Begründung der Änderung wird auch im AIM der EFG 11 (Aide-Mémoire der EFG 11 - Überwachung computergestützter Systeme) angesprochen:
9-9 Wie wird bei einer Änderung bzw. Löschung die Begründung dokumentiert?
Die Begründung kann in Form eines Freitextes erfolgen. Drop-/Pull-down-Menüs sind auch akzeptabel. In jedem Fall muss die Begründung inhaltlich nachvollziehbar sein. Die Eingabe einer Begründung sollte vom System erzwungen werden.
Audit Trail - Die Abschlussforderung
EU-GMP Annex 11, 9 Audit Trails müssen verfügbar sein, in eine allgemein lesbare Form überführt werden können und regelmäßig überprüft werden.
Daraus ergibt sich, dass die Audit Trails aufbewahrt werden müssen und zwar so, dass man sie auch ausreichend schnell wiederfindet. Das führt nicht an einem Archivierungskonzept vorbei. Audit Trails sind Bestandteile der GMP-Dokumentation. Sinnvollerweise erfolgt eine Archivierung zusammen mit der Chargendokumentation.
Die allgemein lesbare Form zielt auch auf die Inhalte ab. Ein Audit Trail sollte folgende Inhalte haben:
• alter Wert
• neuer Wert
• Zeitstempel (Änderungszeitpunkt)
• Name der Person, die geändert oder gelöscht hat
• Änderungsgrund
Die Forderung nach der regelmäßigen Überprüfung ist allgemein gehalten und stellt uns insbesondere vor zwei Probleme:
Innerhalb welcher Zeitintervalle sollten die Prüfungen durchgeführt werden und wer sollte den Audit Trail prüfen.
Beides ist nicht geregelt. Zu beiden Punkten findet man allerdings etliche Hinweise in den gängigen Guidelines zur Datenintegrität.
PIC/S PI 041-1:
9.6 Critical audit trails related to each operation should be independently reviewed with all other records related to the operation and prior to the review of the completion of the operation (e.g. prior to batch release) so as to ensure that critical data and changes to it are acceptable.
Die Chargenfreigabe spielt sicherlich eine zentrale Rolle. Wenn also beispielsweise mit einem HPLC eine freigaberelevante Gehaltsbestimmung durchgeführt wird, wird man den Audit Trail dieses HPLC vor Chargenfreigabe prüfen. Schwieriger wird es bei allen anderen Audit Trails. Hier sollten die Zeitintervalle über eine Risikobewertung ermittelt werden.
PIC/S PI 041-1:
9.6 Non-critical audit trails reviews can be conducted during system reviews at a pre-defined frequency. This review should be performed by the originating department, and where necessary verified by the quality unit (e.g. during batch release, self-inspection or investigative activities).
Hier stellt sich allerdings die Frage welche Audit Trails unkritische sind, wenn es um das Ändern oder Löschen GMP-relevanter Daten geht.
Hinweise hierzu findet an auch im AIM der EFG 11:
9-11 Wie oft erfolgt die regelmäßige Überprüfung des Audit Trails?
Die Funktionalität ist regelmäßig im Rahmen der periodischen Evaluierung zu bewerten und ggf. zu prüfen. Das Intervall sollte nachvollziehbar unter Berücksichtigung des Prozessrisikos festgelegt werden. Vor der Chargenfreigabe sollten Änderungen oder Löschungen kritischer Daten bewertet werden.
Wer sollte jetzt die Prüfung durchführen? Hierzu gibt es auch einen Hinweis in PIC/S PI 041-1:
This review should be performed by the originating department, and where necessary verified by the quality unit, e.g. during self-inspection or investigative activities. The company's quality unit should establish a program and schedule to conduct ongoing reviews of audit trails based upon their criticality and the system's complexity.
Einen ähnlichen Hinweis findet man im GAMP® GPG zur Datenintegrität:
GAMP® GPG Records and Data Integrity Guide
Audit Trail Review should be performed by an individual who has an understanding of the business process and the impact of the actions recorded. They are an effective means of verifying that changes are made by authorized users an for detecting potential data integrity issues.
Seminarempfehlung
Heidelberg14./15. Mai 2024
Validierung computergestützter Systeme (CV 1)
Wichtig ist hier, dass man grundlegende Hinweise in einer SOP festgelegt hat:
- Wer prüft den Audit Trail (Personen und Bereich: QK, Produktion, QS, System Owner, Process Owner, …)?
- Wo liegen im Detail die Verantwortlichkeiten für die Prüfung?
Concept Paper on the revision of Annex 11
Insgesamt spricht das Concept Paper zum Annex 11 sieben Punkte an und ist damit der umfangreichste Abschnitt im Concept Paper.
18. [9] An audit trail functionality which automatically logs all manual interactions on GMP critical systems, where users, data or settings can be manually changed, should be regarded as mandatory; not just 'considered based on a risk assessment'.
Controlling processes or capturing, holding or transferring electronic data in such systems without audit trail functionality is not acceptable; any grace period within this area has long expired.
Hier hat man offensichtlich die Notwenigkeit einer Risikoanalyse anders (falsch) interpretiert. Dies wurde oben bereits im Detail beschrieben. Nach momentaner Interpretation des aktuellen Annex 11 ist ein Audit Trail immer dann erforderlich, wenn man GMP-Daten ändern oder löschen kann. Ein risikobasierter Ansatz für Audit-Trails bedeutet: Wenn das System dem Bediener/ Benutzer nicht erlaubt Werte zu ändern, ist kein Audit Trail erforderlich. Das Steuern von Prozessen hat nichts mit dem Audit Trail zu tun und ist damit nicht notwendig (im Audit Trail).
19. [9] The audit trail should positively identify the user who made a change, it should give a full account of what was changed, i.e. both the new and all old values should be clearly visible, it should include the full time and date when the change was made, and for all other changes except where a value is entered in an empty field or where this is completely obvious, the user should be prompted for the reason or rationale for why the change was made.
Eigentlich ist das schon ausreichend geregelt. Was jedoch fehlt ist die Notwenigkeit der Angabe eines Grundes. Dies ist bei bei der Papierdokumentation nicht immer notwendig. Siehe EUGMP Kapitel 4, 4.9 … Sofern angezeigt, sollte der Grund für die Änderung protokolliert werden.
20. [9] It should not be possible to edit audit trail data or to deactivate the audit trail functionality for normal or privileged users working on the system. If these functionalities are available, they should only be accessible for system administrators who should not be involved in GMP production or in day-to-day work on the system (see 'segregation of duties').
Die Forderung ist so korrekt und spiegelt eigentlich die Notwendigkeit der Einhaltung der Grundsätze der Datenintegrität wieder. Dies im Annex 11 separat hervorzuheben ist nicht notwendig. Segregation of Duties gilt immer und muss nicht extra erwähnt werden.
21. [9] The concept and purpose of audit trail review is inadequately described. The process should focus on a review of the integrity of manual changes made on a system, e.g. a verification of the reason for changes and whether changes have been made on unusual dates, hours and by unusual users.
Auch hier stellt sich die Frage ob dies in einer Rechtsgrundlage beschrieben werden muss. Eigentlich sollte das Bestandteil einer entsprechenden SOP des Regulated User sein. Siehe hierzu beispielsweise auch PIC/S PI 041-1:
9.8 Procedures should be in place to address and investigate any audit trail discrepancies, including escalation processes for the notification of senior management and national authorities where necessary.
22. [9] Guidelines for acceptable frequency of audit trail review should be provided. For audit trails on critical parameters, e.g. setting of alarms in a BMS systems giving alarms on differential pressure in connection with aseptic filling, audit trail reviews should be part of batch release, following a risk-based approach.
Im Grunde ein wichtiger Hinweis. Aber auch dies sollte eigentlich nicht in der Rechtsgrundlage beschrienem werden. Es ist Sache des Regulated User dies entsprechend in einer SOP zu beschreiben und festzulegen. In eine Rechtsgrundlage gehören keine Beispiele (setting of alarms in a BMS systems giving alarms on differential pressure in connection with aseptic filling).
23. [9] Audit trail functionalities should capture data entries with sufficient detail and in true time, in order to give a full and accurate picture of events. If e.g. a system notifies a regulated user of inconsistencies in a data input, by writing an error message, and the user subsequently changes the input, which makes the notification disappear; the full set of events should be captured.
Es stellt sich die Frage, ob eine Rückverfolgbarkeit von Tippfehlern wirklich notwendig ist. Hier wird über das Ziel hinausgeschossen.
24. [9] It should be addressed that many systems generate a vast amount of alarms and event data and that these are often mixed up with audit trail entries. While alarms and events may require their own logs, acknowledgements and reviews, this should not be confused with an audit trail review of manual system interactions. Hence, as a minimum, it should be possible to be able to sort these.
Grundsätzlich ist das ein wichtiger Hinweis. Viele Systeme erzeugen eine große Zahl von Alarmen und Ereignissen. Diese werden oft mit Audit-Trail-Einträgen vermischt.
Es macht Sinn, Alarme und Ereignisse eigenen Protokollen, Bestätigungen und Überprüfungen zuzuordnen. Diese Prüfungen sollten nicht mit einer Audit Trail Prüfung verwechselt werden. Es sollte zumindest möglich sein, diese zu sortieren.
Es stellt sich allerdings die Frage wie man diese Anmerkung im Text des Annex 11 umsetzt. Denkbar wäre der Hinweis, dass der Audit Trail wirklich nur Änderungen und Löschungen von GMP-relevanten Daten enthalten darf und sonst nichts. Oder als Minimum die Sortierfunktion!
Über den Autor:
Klaus Feuerhelm
... Regierungspräsidium Tübingen, Leitstelle Arzneimittelüberwachung Baden-Württemberg
