Hitliste der Mängel 2020 bei Inspektionen von computergestützten Systemen
Betrachtet man die bei Inspektionen gefundenen Mängel (computergestützte Systeme) und versucht, diese verschiedenen Kategorien zuzuordnen, so ergibt sich innerhalb der vergangenen Jahre immer wieder ein neues Bild1. Sah die Hitliste 2015 noch so aus:
1. Liste der computergestützten Systeme
2. Audit Trail
3. Periodische Evaluierung
so war die Situation 2020 folgendermaßen:
Abb. 1: Mängel bei Inspektionen computergestützter Systeme 2020
Sicherlich spielt hier auch eine Rolle, wie man die Schwerpunkte bei den Inspektionen festlegt, doch wird man in der Regel bemüht sein, ein möglichst breites Feld im Rahmen einer Inspektion abzudecken. Stellt man dann bei einzelnen Inspektionen fest, dass sich bestimmte Mängel häufen, so nimmt man dieses Teilgebiet dann bei jeder Inspektion mit in das Programm auf, unter Umständen als Schwerpunktthema.
(Anmerkung: Die Hitliste bezieht sich auf die Inspektionen des Autors)
Systembeschreibung
Es soll an dieser Stelle beispielhaft die Systembeschreibung etwas näher dargestellt werden. Sehen wir hierzu einmal in die Rechtsgrundlage (EU-GMP Annex 11):
Für kritische Systeme sollte eine aktuelle Systembeschreibung vorliegen, welche die technische und logische Anordnung, den Datenfluss sowie Schnittstellen zu anderen Systemen oder Prozessen, sämtliche Hard- und Softwarevoraussetzungen und die Sicherheitsmaßnahmen detailliert wiedergibt.
Der Hinweis auf die kritischen Systeme engt hier auf den ersten Blick die Auswahl etwas ein. Hier stellt sich das Problem "Welche GMP-Systeme sind nicht kritisch?". Es wird schwerfallen, GMP-Systeme als unkritisch zu bewerten, aber es gibt natürlich Systeme, die kritischer als andere sind. Daher sollte man diese Vorgabe so interpretieren, dass wir in der Regel eine Systembeschreibung benötigen. Man kann hier sogar so weit gehen, dass die Systembeschreibung ein eigenes Dokument sein muss und nicht an anderer Stelle (z. B. Validierungsplan) integriert werden kann. Das ergibt sich allein schon durch die Forderung, dass die Systembeschreibung aktuell zu halten ist. Es sei noch angemerkt, dass in der AMWHV Hinweise zu finden sind, welche Systeme kritisch sind:
AMWHV § 2 Begriffsbestimmungen
Im Sinne dieser Verordnung
19. sind kritische Ausrüstungsgegenstände oder Geräte solche, die mit den Produkten in Berührung kommen oder einen anderen Einfluss auf die Qualität oder Sicherheit der Produkte haben können.
Der erste Mangel wäre also, dass die Systembeschreibung als solche nicht vorhanden ist, was in der Tat nicht selten vorkommt.
Seminarempfehlung
Heidelberg4.-6. Juni 2024
Computervalidierungs-Beauftragte/r (CV 7) - Block 1
Weitere Mängel ergeben sich dann aus dem Inhalt, der möglicherweise nicht den Anforderungen nach EU-GMP Annex 11 entspricht. Die Inhalte der Systembeschreibung sind im Annex 11 klar genannt:
- Technische und logische Anordnung der Systeme
- Datenfluss
- Schnittstellen zu anderen Systemen
- Schnittstellen zu anderen Prozessen
- Sämtliche Hard- und Softwarevoraussetzungen
- Sicherheitsmaßnahmen
Bei Inspektionen hat es sich immer wieder gezeigt, dass einzelne Punkte nicht genannt und beschrieben worden sind. Nicht selten fehlt hier eine ausführliche Beschreibung der Sicherheitsmaßnahmen. Was wäre hier wichtig?
- Definierte Verantwortlichkeiten für die Systemsicherheit.
- Benutzermanagement einschließlich Rollenkonzept
- Physische und logische Sicherheit
- Vergabe von Benutzerrechten und Verantwortlichkeiten entspricht der Organisationsstruktur
- Passwortkonzepte
- Schulung der User (Sicherheitskonzepte)
- Verschlüsselung
- Virenschutzkonzept
- u. a.
In diesem Zusammenhang kann unter Umständen auch auf einzelne SOPs verwiesen werden. Dabei kann es unter Umständen auch hilfreich sein, andere Regelwerke oder Guidelines zu Rate zu ziehen, die auch Hinweise zur Systembeschreibung enthalten. Zu nennen wären dafür die GAMP 5 ® Richtlinie und PIC/S PI 011. Beide Guidelines sind jedoch in dieser Beziehung nicht aktuell, da sie sich auf den alten Annex 11 (Version 1992) beziehen, wobei alter Annex 11 und aktueller Annex 11 (Version 2011) hier nicht so sehr voneinander abweichen:
EU-GMP Annex 11 (alt):
Eine ausführliche Beschreibung des Systems sollte erstellt (gegebenenfalls mit Diagrammen) und ständig aktualisiert werden. Diese Beschreibung sollte Grundsätze, Zielsetzungen, Sicherheitsmaßnahmen und Einsatzbereich des Systems umfassen und aufzeigen, wie der Computer eingesetzt wird, und ob Wechselbeziehungen mit anderen Systemen und Verfahren bestehen.
EU-GMP Annex 11 (aktuell):
Für kritische Systeme sollte eine aktuelle Systembeschreibung vorliegen, welche die technische und logische Anordnung, den Datenfluss sowie Schnittstellen zu anderen Systemen oder Prozessen, sämtliche Hard- und Softwarevoraussetzungen und die Sicherheitsmaßnahmen detailliert wiedergibt.
Die alte Version nennt hier noch explizit die Einsatzbereiche, was eigentlich selbstverständlich dazu gehört.
Sehen wir uns einmal den Hinweis in PIC/S PI 011 zur Systembeschreibung an:
PIC/S PI 011
10.4 The regulated user should be able to provide documentation describing the computer system(s) to include logic flow or block diagrams where practical, also giving an indication of hardware layout, networks and interaction. These basic schematics should align with the functional specification and be traceable to the URS.
Hier ist die Vorgabe des alten Annex 11 herauszulesen. Interessant aber der letzte Satz:
These basic schematics should align with the functional specification and be traceable to the URS.
Hier bekommen wir einen Hinweis, wann die Systembeschreibung zu erstellen ist, nämlich unmittelbar nach der DQ.
Vergleichen wir zum Schluss noch die Inhalte von Annex 11 und GAMP 5® zur Systembeschreibung. Dabei ist zu berücksichtigen, dass die Hinweise in GAMP 5® noch auf dem alten Annex 11 beruhen (Abbildung 2).
Interessant ist der letzte Punkt (Elektronische Aufzeichnungen und Unterschriften); dies taucht so im Annex 11 nicht auf, was aber durchaus Sinn macht.
Abb. 2: Systembeschreibung GAMP 5® versus EU-GMP Annex 11
Rohdaten
Wenn wir uns mit Rohdaten befassen, werden wir feststellen, dass in EU-GMP dieser Begriff nicht definiert wird, aber zumindest eine Beschreibung zu finden ist, die Hinweise gibt, was unter Rohdaten zu verstehen ist:
EU-GMP Kapitel 4:
Mindestens solche Daten sollten als Rohdaten festgelegt werden, die für Qualitätsentscheidungen dienen.
Hier geht es also darum, welche besonderen Eigenschaften eine bestimmte Gruppe von Daten hat.
Eine weitere interessante Definition findet man in VDI/VDE 3516 Blatt 5 Validierung im GxP-Umfeld - Arten von Rohdaten:
Rohdaten: festgelegte Daten (aus der Gesamtheit aller verfügbaren Daten), die für die Rekonstruktion und Bewertung der hinsichtlich Patientensicherheit, Studienergebnissen und/oder Produktqualität relevanten Ergebnisdaten notwendig sind.
Auch hier geht es um eine bestimmte Art (Gruppe von Daten). Eine andere Art der Definition von Rohdaten ist in einer Reihe von englischsprachigen Guidelines, z. B. MHRA ('GXP' Data Integrity Guidance and Definitions) oder GAMP® GPG Data Integrity by Design aufgeführt.
Beispiel:
MHRA
Raw data is defined as the original record (data) which can be described as the first-capture of information, whether recorded on paper or electronically. Information that is originally captured in a dynamic state should remain available in that state.
Ob EU-GMP Kapitel 4 genau so etwas gemeint hat, lässt sich nach Auffassung des Autors nicht aus dem GMP-Leitfaden herauslesen. Der Hinweis in EU-GMP Kapitel 4 (für die elektronischen Protokolle sollten die Nutzer festlegen, welche Daten als Rohdaten genutzt werden), deutet eher darauf hin, dass es um eine bestimmte Gruppe oder Art von Daten geht, während die Definition im MHRA Guide oder im GAMP® Guide eher im Zusammenhang mit der Entstehung der Daten zu sehen ist. Beides kann demnach nicht ohne weiteres miteinander verglichen werden.
Allerdings gibt die Definition der MHRA das wieder, was man heute unter Rohdaten versteht. Insofern ergibt sich hier ein gewisser Konflikt zwischen EU-GMP und dem allgemeinen Verständnis, was Rohdaten sind.
Daher sollte der Arzneimittelbetrieb für sich selber entscheiden, was er als Rohdaten versteht. Hierzu sollte es entsprechende SOPs geben, beispielsweise "Rohdaten in der Qualitätskontrolle". Solche SOPs werden immer wieder vermisst.
Eine weitere zu erwähnende Fehlerquelle ist, dass man nicht im Detail beschrieben hat, wie man diese Rohdaten archiviert. Wenn man jetzt Rohdaten im Sinne von MHRA oder GAMP definiert hat, wird man sich unter Umständen im Einzelfall schwer tun.
Ein weiteres Beispiel:
In der Qualitätskontrolle eines Betriebs wird ein Videodokumentationssystem für die Auswertung von Dünnschichtchromatogrammen genutzt. Die Archivierung der Bilder erfolgt auf Papier. Papier wird als führendes System angegeben. Allerdings waren auf bestimmten Ausdrucken nicht alle Informationen zu sehen, die man am Monitor des PCs gesehen hatte. Auf die Frage, was man macht, wenn man den Papierausdruck nicht ausreichend nutzen kann, wurde geantwortet, dass in diesem Fall auf die elektronischen Daten zurückgegriffen wird. Damit sind jedoch die elektronischen Daten die Rohdaten und nicht der Ausdruck; eigentlich sollte daher immer die Bilddatei für Freigabeentscheidungen genutzt werden; dabei ist insbesondere zu regeln, wie diese Bilddateien archiviert werden.
Audit Trail
Die im Rahmen von Inspektionen gefundenen Mängel im Zusammenhang mit dem Audit Trail sind vielfältig. Nicht selten steht der Mangel im Zusammenhang mit der gelieferten Software. Die Softwarelieferanten bzw. Systemlieferanten bieten hier einfach nicht das an, was eigentlich EU-GMP Annex 11 fordert. Es gibt aber durchaus Software, die die Anforderungen nach EU-GMP erfüllt, wenn auch das in der Regel nicht so oft vorkommt.
Zunächst sollte man sich darüber klar werden, woher die Forderung nach der Audit Trail Funktionalität bei einem computergestützten System kommt. Dies ergibt sich aus § 10 der AMWHV:
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.
Eine ähnliche Formulierung finden wir in 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.
Genau diese Forderung muss also in einem computergestützten System in der Audit Trail Funktionalität umgesetzt werden; der Audit Trail ist also eine Funktionalität zur Dokumentation. Diese Hinweise findet man beispielsweise auch im GAMP® Records and Data Integrity Guide:
18.7. Audit Trail Considerations
Audit Trails should be considered part of records.
Was derzeit in der Regel von vielen Lieferanten als Audit Trail angeboten wird, sind sogenannte Ereignisprotokolle, in denen alles Mögliche protokolliert wird; damit erschweren diese einen raschen Review des Audit Trails in erheblichem Umfang.
Mängel im Zusammenhang mit dem Audit Trail sind schon seit längerer Zeit auch bei der US-FDA zu finden.
Beispiele:
Gulf Pharmaceutical Industries Feb 2012 We also note that your SOP does not have provisions for any audit trail reviews to ensure that deletions and/or modifications do not occur.
Sunrise Jan 2010:
In addition, your firm's review of laboratory data does not include a review of an audit trail or revision history to determine if unapproved changes have been made.
Es gibt durchaus aber auch neuere Beispiele:
Strides Pharma Science Limited, India
On 02/04/2019, during the walkthrough of the Control Room where Formulation Plant processes were being monitored using a Building Automation System, we observed that the system was not qualified and had no audit trail capabilities. In addition, when asked about the alarms on the system, the Sr. Assistant Instrumentation group, stated that he would reset and clear the alarms.
Im Folgenden sind nun einige Mängel im Zusammenhang mit dem Audit Trail genannt, die bei Inspektionen gefunden worden sind:
Ein/e Mitarbeiter/in in einem Labor der Qualitätskontrolle hat die Rechte eines Systemadministrators. Er/sie war so beispielsweise in der Lage, bei selbst durchgeführten Analysen nicht mehr erkennbare Änderungen am Audit Trail vorzunehmen bzw. den Audit Trail ein- oder auszuschalten.
Es gab keine beschriebenen Maßnahmen die zu ergreifen sind, wenn bei der Prüfung des Audit Trails Probleme festgestellt werden.
Es war nicht eindeutig geregelt, wer die Audit Trail Funktionalität des Systems XYZ deaktivieren darf, und wie dies dokumentiert wird.
Seminarempfehlung
Vienna, Austria11-14 June 2024
Computerised System Validation
Im Labor wurde eine HPLC-Station zur Ermittlung des Wirkstoffgehalts einer Tablette genutzt. Die Chargenfreigabe erfolgt ohne Review von relevanten Audit Trail-Daten. Eintragungen im Audit Trail könnten auf eine Abweichung hinweisen; diese Abweichung sollte die QP vor der Freigabe kennen. Es gibt keine dokumentierten Vorgaben und Hinweise zum Umgang mit dem Audit Trail.
Hierzu gehören beispielsweise:
- Wie oft und wann ist ein Audit Trail eines bestimmten Systems zu prüfen?
- Wer soll die Überprüfung des Audit Trail durchführen?
- Wie erfolgt die Archivierung des Audit Trail?
- Wann dürfen Audit Trails gelöscht werden?
- Welche Audit Trail-Einträge sind als kritisch zu bewerten?
- Wie werden Audit Trail-Prüfungen dokumentiert?
- Welche Maßnahmen sind zu ergreifen, wenn bei der Prüfung des Audit Trails Probleme festgestellt werden?
Zusammenfassend kann gesagt werden, dass insbesondere folgende Punkte von Bedeutung sind:
- Der Audit Trail ist ein Dokumentationselement.
- Wie bei allen anderen GMP-Dokumenten ist ein Review notwendig.
- Wann ein Review notwendig ist, wird über eine Risikobewertung ermittelt.
- In einem Audit Trail kann eine Abweichung verborgen sein.
- Eine GMP-Entscheidung ist beispielsweise eine Freigabeentscheidung.
Für die Zukunft ist zu wünschen, dass in einer neuen Version des Annex 11 (derzeit in Bearbeitung durch eine Arbeitsgruppe bei der EMA) die Hinweise und Anforderungen zum Audit Trail genauer beschrieben und formuliert werden. Insbesondere die Abgrenzung zwischen Audit Trail und Change Control sollte dort klar geregelt werden.
Autor:
Klaus Feuerhelm
... war bei der Leitstelle Arzneimittelüberwachung Baden-Württemberg im Regierungspräsidium Tübingen tätig.
Fußnoten:
1 Der Autor bezieht sich hier auf die von ihm durchgeführten Inspektionen.
