Software eines Environmental Monitoring System: Annex 11, Part 11 und Datenintegrität

Die Software eines Environmental Monitoring System ist der Teil, der die Aufzeichnung erzeugt — und damit der Teil, auf den die meisten Inspektionsfragen zielen. Wer darf einen Grenzwert ändern, wer darf ein Datum ungültig setzen, wie weist man nach, dass ein Wert nicht verändert wurde, wer prüft den Audit Trail und nach welchen Kriterien, wo liegen die Daten von vor fünf Jahren und wer kann sie noch lesen: Das sind Fragen der Softwarekonfiguration und -führung, nicht der Qualität der Messgeräte.

Die Grundregel lautet: Data Integrity wird geplant, nicht nachgerüstet. Rollen, Berechtigungen, Nachvollziehbarkeit und Aufbewahrung sind vor der Konfiguration festzulegen: Nach der Inbetriebnahme erfordert jede strukturelle Korrektur Change Control, Nachverifizierung und häufig Eingriffe in bereits erzeugte Daten. Die zweite Regel: präzise unterscheiden, was eine im eigenen Kontext anwendbare regulatorische Anforderung ist und was Unternehmensentscheidung. Wer beides vermischt, investiert dort, wo es nicht nötig ist, und entdeckt Lücken dort, wo es nötig gewesen wäre.

Warum die Software der exponierteste Teil des Systems ist

Ein computergestütztes Umgebungsmonitoring-System bündelt drei Funktionen, die auf Papier getrennt wären: Es erfasst die Daten, verarbeitet und speichert sie und ermöglicht ihre Überprüfung. Wer die Software kontrolliert, kontrolliert potenziell alle drei. Diese Bündelung macht Kontrollen über Zugriff, Aufgabentrennung und Änderungsnachvollziehbarkeit notwendig.

Der zweite Grund ist die Dauer. Geräte werden ersetzt; Daten bleiben über die gesamte anwendbare Aufbewahrungsfrist und müssen lesbar und rekonstruierbar bleiben, auch wenn das erzeugende System nicht mehr existiert. Heutige Entscheidungen zu Formaten, Exportierbarkeit und Archivierung bestimmen, ob in Jahren eine Frage zu einer heute hergestellten Charge beantwortet werden kann.

Der regulatorische Rahmen: was tatsächlich gilt

Technische Anleitung

Benutzerrollen und Segregation of Duties

Die Rollenmatrix wird vor der Konfiguration festgelegt, nicht aus den Standardprofilen des Lieferanten übernommen. Die Prinzipien:

• Eindeutige Identifizierung: Jeder Nutzer hat persönliche, nicht geteilte Zugangsdaten; generische Abteilungskonten gehören zu den häufigsten Beanstandungen.
• Minimalprinzip: Jede Rolle hat nur die für ihre Funktion erforderlichen Berechtigungen.
• Aufgabentrennung: Wer das System konfiguriert, sollte nicht dieselbe Person sein, die die erzeugten Aufzeichnungen prüft; wer bedient, sollte die Parameter, die seine eigene Tätigkeit steuern, nicht ändern können.
• Systemadministration: Administratorrechte auf wenige Personen begrenzen, vorzugsweise außerhalb der operativ nutzenden Funktion, mit protokollierter Tätigkeit.
• Lebenszyklus der Konten: Anlegen, Ändern, Sperren und Deaktivieren folgen einem definierten, an Personalbewegungen gekoppelten Prozess.
• Lieferantenzugänge: befristet, einzeln autorisiert, protokolliert und nach dem Einsatz entzogen.

Audit Trail: Inhalt und Überprüfung

Ein nützlicher Audit Trail beantwortet für jedes relevante Ereignis vier Fragen: wer, was, wann und warum. In Spezifikation und Qualifizierung zu prüfen:

• Abdeckung relevanter Ereignisse: Erstellen, Ändern und Ungültigsetzen von Aufzeichnungen, Konfigurations- und Grenzwertänderungen, Alarmbehandlung, Zugriffsereignisse;
• Unmöglichkeit der Deaktivierung oder Veränderung durch Nutzer, Administratoren eingeschlossen;
• Angabe des Änderungsgrunds, wo Änderungen zulässig sind;
• Lesbarkeit in verständlicher Form ohne Werkzeuge des Lieferanten;
• Möglichkeit, effizient zu filtern und zu prüfen: Ein technisch vollständiger, praktisch aber nicht prüfbarer Audit Trail erfüllt seinen Zweck nicht;
• Aufbewahrung über die gesamte für die zugehörigen Aufzeichnungen geforderte Frist.

Die Audit-Trail-Überprüfung ist risikobasiert zu planen: welche Ereignisse geprüft werden, durch wen, in welcher Frequenz und mit welchem Nachweis. Die Frequenz folgt keiner allgemeinen Regel, sondern der Kritikalität der Daten und des Prozesses — und ist schriftlich zu begründen.

Elektronische Aufzeichnungen, Signaturen und Datenmanagement

• Definition des Rohdatums: Festzulegen, was das Originaldatum ist und wo es liegt, ist die Voraussetzung jeder weiteren Kontrolle.
• Metadaten: Die Aufzeichnung ist nicht nur der Wert; sie umfasst die Informationen, die Interpretation und Rekonstruktion ermöglichen.
• Elektronische Signaturen: Werden sie eingesetzt, sind die signaturpflichtigen Vorgänge, die Bedeutung der Signatur und die zugehörigen Kontrollen zu definieren. Verlangt der Kontext sie nicht, ist die Entscheidung dagegen zu dokumentieren.
• Umgang mit auffälligen Daten: Das Ausschließen oder Kommentieren eines Datums ist per Verfahren zu regeln, mit erfasster Begründung und vollständiger Nachvollziehbarkeit. Das Löschen von Rohdaten ist keine zu konfigurierende Funktion.
• Exporte und Berichte: Sie sind Teil der Qualifizierungsprüfung; ein Bericht, der Daten unvollständig oder irreführend darstellt, ist ein Systemproblem, kein Anwendungsproblem.

Konfiguration, Anpassung und Validierung

Der Validierungsaufwand hängt davon ab, wie weit das System vom Standardprodukt abweicht. Ein mit herstellerseitig vorgesehenen Parametern konfiguriertes System bedeutet einen anderen Aufwand als ein System mit kundenspezifischen Entwicklungen. Das operative Kriterium: Jedes konfigurierte oder entwickelte Element ist zu dokumentieren, zu begründen und zu verifizieren, und die Konfigurationsdokumentation ist als Teil des Systems aktuell zu halten, nicht bei Projektabschluss abzulegen.

Die Lieferantenbewertung — Entwicklungskompetenz, Versionsmanagement, Support, verfügbare Dokumentation — gehört zum Rahmenwerk und ist zu dokumentieren; ihr Ergebnis beeinflusst legitim die Tiefe der eigenen Verifizierung.

Aufbewahrung, Archivierung und Migration

• Aufbewahrungsfrist: konsistent zu den Anforderungen an die betroffenen Aufzeichnungen festgelegt.
• Lesbarkeit über die Zeit: Das Archivformat muss auch nach Außerbetriebnahme interpretierbar bleiben; die ausschließliche Abhängigkeit von einem proprietären Format ist ein ausdrücklich zu bewertendes Risiko.
• Migration: Jede Übertragung historischer Daten erfordert einen Plan, Kriterien zur Prüfung von Vollständigkeit und Richtigkeit sowie einen Ergebnisnachweis.
• Exit-Strategie: Wie nach Vertrags- oder Supportende auf die Daten zugegriffen wird, ist eine Frage für die Ausschreibung, nicht für die Außerbetriebnahme.

Periodic Review des computergestützten Systems

Das System ist periodisch zu überprüfen, um zu bestätigen, dass es weiterhin im Zustand der Beherrschung ist: erfolgte Änderungen, erfasste Störungen, Abweichungen, Ergebnis der Audit-Trail-Prüfungen, Zugriffsverwaltung, Support- und Obsoleszenzstatus, durchgeführte Restore-Tests. Die Periodic Review ist keine Wiederholung der Qualifizierung: Sie ist der dokumentierte Nachweis, dass die Annahmen, auf denen die Qualifizierung beruhte, weiterhin gelten.

Arbeitsmittel: Data-Integrity-orientierte Konfigurationscheckliste

Praxisszenario

An einem Standort, den wir Site Delta nennen — realistisch, aber fiktiv — konfiguriert das Projektteam das EMS mit den Standardbenutzerprofilen des Lieferanten, um den Start nicht zu verzögern. Das Profil für Schichtverantwortliche enthält aus Bequemlichkeit die Möglichkeit, Alarmgrenzwerte zu ändern.

Die Qualifizierung schließt ohne Befund: Das System tut genau das, wofür es konfiguriert wurde. Das Problem zeigt sich bei der ersten Periodic Review, als der Audit Trail Grenzwertänderungen durch operatives Personal während der Produktion ausweist. Keine dieser Änderungen war nach der Konfiguration unzulässig; alle waren unvereinbar mit dem Prinzip der Trennung zwischen denen, die bedienen, und denen, die die steuernden Parameter festlegen.

Die Korrektur — Rollenmatrix neu definieren, Berechtigungen umkonfigurieren, nachverifizieren, die bereits erfolgten Änderungen rückblickend bewerten und ihre Auswirkung dokumentieren — erfordert deutlich mehr Aufwand, als die Matrix vorab zu definieren gekostet hätte. Der klassische Fall, in dem anfangs gesparte Zeit mit Zinsen zurückgezahlt wird.

Häufige Fehler und Warnsignale

• Die Standardbenutzerprofile des Lieferanten übernehmen. Sie spiegeln eine generische Organisationsannahme, nicht die Aufgabentrennung des Standorts.
• Geteilte oder generische Konten. Sie machen Zuordenbarkeit unmöglich — das erste Data-Integrity-Prinzip.
• Audit Trail aktiv, aber nie geprüft. Protokollierung ohne Prüfung erzeugt keine Kontrolle; das Fehlen eines begründeten Prüfplans ist ein häufiger Befund.
• Den Annex 11 in Revision als geltende Anforderung zitieren. Anwendbar bleibt die Fassung von Januar 2011; ein Konsultationstext ist keine Pflicht.
• Annehmen, Part 11 gelte immer. Die Anwendbarkeit ist zu bestimmen und zu dokumentieren; sie ohne Analyse anzunehmen führt zu unbegründeten Kontrollen, sie ohne Analyse zu verneinen führt zu Lücken.
• Das Rohdatum nicht definieren. Ohne diese Definition bleibt jede Diskussion über Integrität und Aufbewahrung mehrdeutig.
• Die Möglichkeit zum Löschen von Daten konfigurieren. Auffällige Daten werden über nachvollziehbare Kommentierung behandelt, nicht durch Entfernen.
• Exportierbarkeit und Migration vernachlässigen. Genau daran scheitert Jahre später der Systemwechsel oder wird sehr teuer.
• Die Periodic Review als Formalie behandeln. Sie ist das Mittel, mit dem der fortbestehende Zustand der Beherrschung nachgewiesen wird.

Wie zu dokumentieren ist

• Anwendbarkeitsbewertung: welche Anforderungen für das System gelten und warum, welche nicht und mit welcher Begründung.
• Genehmigte Rollen-Berechtigungs-Matrix mit der Begründung der Aufgabentrennung.
• Konfigurationsspezifikation als lebendes Dokument gepflegt.
• Audit-Trail-Prüfplan mit begründeter Frequenz und zugewiesenen Verantwortlichkeiten.
• Definition von Rohdatum, Metadaten und Aufbewahrungsfrist.
• Lieferantenbewertung und ihr Einfluss auf die Verifizierungsstrategie.
• Qualifizierungsbericht der computergestützten Komponente, rückverfolgbar zu den Anforderungen.
• Aufzeichnungen der Periodic Review und daraus folgende Maßnahmen.

Kernaussagen

• Data Integrity wird vor der Konfiguration geplant: danach kostet jede Korrektur weit mehr.
• Die anwendbare Fassung des Annex 11 ist die Revision von Januar 2011; ein Konsultationstext ist keine Anforderung.
• Die Anwendbarkeit von Part 11 ist zu bestimmen und zu dokumentieren, nicht anzunehmen.
• Ein praktisch nicht prüfbarer Audit Trail erfüllt seinen Zweck nicht.
• Aufgabentrennung ist eine organisatorische Entscheidung, die in Konfiguration übersetzt wird — nicht umgekehrt.
• Exportierbarkeit, Archivierung und Exit-Strategie werden in der Ausschreibung verhandelt, nicht bei der Außerbetriebnahme.

Häufige Fragen

Welche Fassung des Annex 11 ist anwendbar?

Die Revision von Januar 2011 bleibt die anwendbare Fassung. Ein Konsultationstext darf zur Orientierung langfristiger Entscheidungen herangezogen werden, ist aber stets als solcher zu deklarieren und kann nicht als Akzeptanzkriterium in der Qualifizierung dienen.

Gilt 21 CFR Part 11 für unser EMS?

Das hängt vom Kontext ab: Es gilt für elektronische Aufzeichnungen und Signaturen im Geltungsbereich FDA-regulierter Produkte und ihrer Predicate Rules. Die Bestimmung erfolgt im Einzelfall und wird in einer genehmigten Anwendbarkeitsbewertung dokumentiert.

Wie oft ist der Audit Trail zu prüfen?

Eine universelle Frequenz gibt es nicht. Sie wird risikobasiert nach Kritikalität der Daten und des Prozesses festgelegt und zusammen mit Prüfumfang und Verantwortlichkeiten schriftlich begründet.

Dürfen Abteilungskonten genutzt werden, wenn mehrere Bediener wechseln?

Nicht, wenn Aufzeichnungen einer Person zuordenbar sein müssen. Zuordenbarkeit ist eines der Grundprinzipien der Data Integrity; operative Anforderungen an Schnelligkeit werden mit technischen Authentifizierungslösungen gelöst, nicht durch geteilte Zugangsdaten.

Wer sollte Alarmgrenzwerte ändern dürfen?

Nicht diejenigen, die unter diesen Grenzwerten arbeiten. Die konkrete Ausgestaltung hängt von der Organisation ab, das Prinzip der Trennung von Ausführung und Parameterfestlegung ist jedoch einzuhalten und in der Rollenmatrix zu dokumentieren.

Was geschieht mit den Daten beim Systemwechsel?

Sie müssen über die gesamte Aufbewahrungsfrist lesbar und rekonstruierbar bleiben. Die Optionen — Migration in das neue System, Archivierung in einem unabhängigen Format, Weiterbetrieb des alten Systems im Lesemodus — sind mit einem dokumentierten Plan zu bewerten. Das Thema knüpft an den Ersatz bestehender Systeme an, behandelt im Beitrag zum Retrofit eines EMS.

Regulatorische und technische Referenzen

• EudraLex Volume 4 — EU Guidelines for Good Manufacturing Practice (Europäische Kommission): Annex 11 (Revision Januar 2011), Annex 15 (in Kraft seit 1. Oktober 2015), Annex 1 (anwendbar seit 25. August 2024).
• 21 CFR Part 11 — Electronic Records; Electronic Signatures (eCFR).
• PIC/S — Guides and Guidance Documents, einschließlich der Guidance zur Data Integrity in regulierten Umgebungen.
• ICH Quality Guidelines — ICH Q9(R1) Quality Risk Management.

Den Projektweg fortsetzen

Dieser Beitrag ist Teil des GuideGxP-Pfads Environmental Monitoring Systems, der den Lebenszyklus eines EMS-Projekts von der Anforderungsdefinition bis zum laufenden Betrieb begleitet.

• Davor: die URS des Systems und die Netzwerk- und Stromversorgungsinfrastruktur.
• Danach: FAT, SAT, IQ, OQ und PQ des Systems und Betriebsführung.
• Regulatorische Grundlagen von GuideGxP: Data Integrity, ALCOA+ und Audit Readiness nach Annex 11.

Analysen wie diese direkt per E-Mail? Abonnieren Sie The Pragmatic GMP, den GuideGxP-Newsletter für alle, die täglich mit GMP, Qualifizierung und Data Integrity arbeiten.