Audit Trail Review bei Geräten mit "Standard Audit Trail" Funktionen

Problemstellung

Geräte und Ausrüstungen habe oft Standard Audit Trail Funktionen. Es werden unzählige Daten mitgeschrieben (on/off), und nur ein Bruchteil dieser Daten ist kritisch und relevant für Audit Trail Reviews. Wie geht man hier bei einem Review am besten vor?

Lösungsansatz

Gerade im Hinblick auf den Audit Trail hat sich die Sichtweise geändert. Vor der Revision des EU GMP Leitfaden Annex 11 war die allgemeine Sichtweise die der Beweissicherung, um im Falle einer Abweichung weitere Daten zu Verfügung zu haben. Auch Äußerungen der amerikanischen FDA in ihren Dockets: "Audit Trail… we may use it for an useful purpose e.g prosecution" nährten diese Sichtweise. Demzufolge wurde der Schwerpunkt in der Software nicht auf spätere Auswertbarkeit gelegt, sondern auf die Erfassung. Deshalb wurden die Audit Trail Daten einfach sequentiell in Tabellen abgelegt.

Bisher gibt es nur wenige Systeme, welche die neuen Anforderungen vollumfänglich unterstützen. Jetzt, mit der zusätzlichen Forderung auch nach dem Grund der Änderung, ergeben sich weitere Anforderungen an die Systeme und auch weitere Sortierkriterien. Zusätzlich wurde klargestellt, dass der Audit Trail gemäß einem risikobasiertem Vorgehen limitiert werden kann. Hier liegt die Chance in der Beschränkung auf die wesentlichen Daten. Was diese sind, beschreiben sowohl der Annex 11 §9, wie auch das Kapitel 4 des EU-GMP Leitfadens. Weitere Hinweise ergeben sich aus dem im ZLG veröffentlichten "Aide Memoire" (Aide-mémoire 07121202), wo sich folgendes Zitat findet:

S. 26 2.4.5 Audit Trails - "1 - 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"). 2 - Bei der Änderung oder Löschung GMP-relevanter Daten sollte der Grund dokumentiert werden. 3 - Audit Trails müssen verfügbar sein, in eine allgemein lesbare Form überführt werden können und regelmäßig überprüft werden."

Daher bietet es sich an, erst die Definition der relevanten Daten für den Audit Trail von der Definition der Rohdaten abzuleiten, um dann festzulegen, für welche Daten ein Review erfolgen muss und welche Kriterien der Bewertung angelegt werden müssen. Das deckt sich mit den Anforderungen aus Kapitel 4, wo es heißt, dass mindestens die Daten als Rohdaten zu benennen sind, auf denen eine Qualitätsentscheidung beruht.

Da in der Regel die Daten selbst bei den Steuerungen (SPS) und Prozessleitsystemen nicht änderbar sind, kann gegebenenfalls auch argumentiert werden, dass kein Audit-Trail erfolgt, eben da die Daten nicht änderbar sind. Diese Argumentation muss jedoch durch entsprechende Validierung mit dem Nachweis der durch proprietäre Formate oder starken Zugangsschutz geschützten Rohdaten belegt werden. Das heißt, dass es Testfälle geben muss, die nachweisen, dass diese definierten Rohdaten nicht versehentlich oder mit einfachem Aufwand geändert werden können.

Für solche Systeme, die keinen Audit-Trail haben, weist der oben zitierte Aide Mémoire darauf hin, dass bei Altsystemen ohne Audit Trail im Ausnahmefall z.B. durch eine SOP geregelt werden kann, die entsprechende Änderung in einem Logbuch zu dokumentieren und dies von einer zweiten Person verifizieren zu lassen. Hier ist anzumerken, dass als Altsysteme nur solche Anlagen definiert werden, die vor Inkrafttreten des Annex 11 (1992) installiert waren (siehe Aide-mémoire 07121202, Seite 28, lfd. Nr. 2.4.5.9). Dort findet sich auch der Satz: "Zuerst ist zu klären, ob Daten überhaupt änderbar sind (z.B. elektronische Schreiber). Wenn nein, ist kein Audit Trail erforderlich."

Für die Systeme, wo es einen einfachen Audit Trail gibt, sollte mittels eines Berichts-Tools die Abfrage basierend auf der Definition der Rohdaten erfolgen. Es sollten mindestens die Einträge dargestellt werden, die zu Prozesswerten gehören, welche zu einer Qualitätsentscheidung benötigt werden. Wenn die Daten, z.B. Temperaturen, direkt im Zusammenhang mit der Chargenfreigabe stehen, ist zu prüfen, ob auch der dazugehörige Audit Trail zwingend vor der Chargenfreigabe bewertet werden muss. Bei Systemen, die auch den Grund der Änderung erfassen, können Gruppen nach dem Grund sortiert und Häufungen nach Gründen erfasst und bewertet werden. Die Bewertung sollte immer nach dem Risiko für Produkt und damit Patient priorisiert werden. In 2. Instanz dann können auch Häufungen von Gründen Anlass bieten,  technische Mängel zu hinterfragen.

Aus den Gesetzen und Richtlinien selbst lässt sich nicht die Anforderung für einen technischen Audit Trail erschließen, der quasi alle Konfigurationen mit Grund belegt und im Audit Trail erfasst. Für diese Vorgänge gibt es das Änderungskontrollverfahren. Demzufolge werden an dieser Stelle keine Reviews zu diesen Daten erwartet. Allerdings ist diese Sichtweise nicht unumstritten, da viele Unternehmen und auch einige Inspektoren die Forderung auch der Überwachung der Konfiguration (technische Audit Trail) aus den jüngst publizierten Data Integrity Guidances ableiten. Hier muss jedes Unternehmen selbst entscheiden, welches Akzeptanzrisiko eingegangen wird. Es erscheint sinnvoll, auch hier einen risikobasierten Ansatz zu fahren. Da sich eine Konfiguration immer auf die Zukunft auswirkt und keine bereits erfassten Daten verändert, sollte dies als Ansatz dienen, zu entscheiden, wo eine Überwachung der Software selbst erforderlich ist oder nicht. Das ist sicherlich bei einem HPLC anders als bei einer Steuerung. Wenn aber die Konfigurationsparameter (z.B. Grenzwerte und Set Points) bekannt und z.B. mit ausgedruckt sind, so können auch die daraus erzeugten Daten im Kontext bewertet werden. Nicht zu vergessen, dass generell ein rigider Change Control gilt der gegebenenfalls auch mit einem Regressionstest beweist, dass die neue Konfiguration den Anforderungen entspricht. Ein weiterer Aspekt ist, dass sich die Zyklen des Reviews für den technischen Teil sicherlich unterscheiden von Zyklen für den Daten Review, wo unter Umständen der Audit Trail bei jeder Chargenfreigabe betrachtet werden sollte (z.B. MES), je nach Risiko für die Freigabe und damit den Patienten. Ein letzter Hinweis zu diesem Punkt ist, dass viele Systeme insbesondere bei einzelnen Steuerungen den "technischen Audit Trail" zurzeit noch nicht unterstützen. Die gute Nachricht ist, dass hier Änderungen eher selten sind und ein gut laufender, validierter Prozess seltener geändert wird. Die Kontrolle erfolgt hier über eine rigide Änderungskontrolle und dem Periodic Review der auch die Incidents und Logbucheinträge erfasst.

Es sei darauf hingewiesen, dass in den Richtlinien immer von Änderungen von Werten ausgegangen wird und somit die Ersterfassung lediglich mitschreibt, wer es erfasst hat im Sinne eines Handzeichens bei Papierdokumenten. Diese Unterscheidung ist sehr gut im Votum V1100302 beschrieben. Dort heißt es in Abschnitt B, vorletzter Absatz: "Automatische Protokollierungen des Benutzers sind geeignet ein Handzeichen zu ersetzen".

Um der Anforderung nach dem Audit-Trail Review gerecht zu werden, sind zukünftig weitere technische Funktionen notwendig, die z.B. konfigurierbare Auswahlmenüs für den Grund der Änderung erlauben und auch Standardreports und zumindest deskriptive Statistiken bieten.

Quelle:

Aide-Mémoire 07121202 "Überwachung computergestützter Systeme" 

Votum V 1100302