Automatisierung, SCADA und Datenintegrität in Pharmawassersystemen

Um 3:40 Uhr morgens registriert der Rücklauf der WFI-Schleife eine Leitfähigkeitsabweichung, die wenige Minuten dauert und von selbst zurückgeht. Niemand bemerkt sie: Der Alarm ist mit niedriger Priorität konfiguriert und die Anzeige wird beim Schichtwechsel zurückgesetzt. Zwei Wochen später fordert die QA im Rahmen der Untersuchung eines auffälligen mikrobiologischen Ergebnisses die Rohdaten jener Nacht an. Der Historian liefert einen über das Aufzeichnungsintervall gemittelten Wert: Die Spitze existiert nicht mehr. Die Kompressionseinstellung wurde vom Integrator bei der Inbetriebnahme festgelegt, taucht in keiner Konfigurationsspezifikation auf, und kein Audit Trail hält sie fest.

Das ist kein Messtechnikproblem: Die Transmitter waren kalibriert. Es ist ein Problem des computergestützten Systems — was mit welcher Auflösung erfasst wird, wer die Konfiguration ändern darf, wo der Wert zum GMP-Record wird und wie lange er rekonstruierbar bleibt. In Pharmawassersystemen kommt dieser Teil fast immer mit dem Skid, konfiguriert von einem Integrator und als „funktionsfähig“ abgenommen. Der Geltungsbereich von Annex 11 und Part 11 wird jedoch nicht vom Lieferanten geerbt: Er muss vom Standort definiert, begründet und dokumentiert werden.

Wo die Daten entstehen und wo sie zum Record werden

Ein Wassersystem hat vier Ebenen. Die Instrumente erzeugen das Signal: Leitfähigkeit, Temperatur, TOC, Durchfluss, Druck, Restozon. Die SPS (PLC) führt die Logik aus: Regelung, Verriegelungen, Sanitisierungssequenzen, Vergleich mit den Grenzwerten. Das HMI zeigt an und bedient vor Ort. Das SCADA überwacht Alarme, Benutzerkonten, Rezepte und Trends; der Historian bewahrt die Zeitreihe auf und macht sie abfragbar.

Das erste Deliverable eines GMP-Automatisierungsprojekts ist keine Softwarespezifikation, sondern die Datenflusskarte. Für jeden kritischen Parameter muss festgehalten werden, wo er entsteht, wo er verarbeitet wird, wo er dauerhaft gespeichert wird, welche Kopie der Referenzrecord ist und wer sie auf welcher Ebene ändern kann. Sie beantwortet die beiden Fragen, die in einer Inspektion zählen: Was ist das Originaldatum, und wer kann es ohne Spur verändern. Zwei Situationen sind dort zu klären: Liegt der dauerhafte Record im Historian, bestimmt die erzeugende Kette — Abtastintervall, Filter, Kompression —, was dieser Record belegen kann; und TOC-Analysatoren mit eigenem Speicher, eigenen Benutzerkonten und eigenem Audit Trail sind eigenständige computergestützte Systeme und keine Komponenten, die stillschweigend im SCADA-Geltungsbereich aufgehen.

Welche Daten kritisch sind und für welche Entscheidung

Die Frage, die den Geltungsbereich klärt, lautet nicht „unterliegt das System der Part 11?“, sondern: Welche GMP-Entscheidung trifft jemand beim Blick auf dieses Datum? Entscheidet niemand etwas, ist es ein Prozessdatum. Gibt jemand eine Verwendung frei, schließt eine Untersuchung ab oder begründet einen Grenzwert, ist es ein GMP-Record und zieht die Kontrollen nach sich.

Annex 1 von EudraLex Volume 4 macht diese Karte in drei Punkten unverhandelbar. Punkt 6.15 verlangt, dass WFI-Systeme eine kontinuierliche Überwachung wie TOC und Leitfähigkeit umfassen: genau jene Daten, die das computergestützte System integer erfassen und aufbewahren muss. Punkt 6.13 legt fest, dass Alert Level aus den Daten der Erstqualifizierung abgeleitet und durch Requalifizierung, Routineüberwachung und Untersuchungen überprüft werden: Grenzwerte sind damit Konfigurationsparameter, die sich über die Zeit ändern — und kontrolliert ändern müssen. Punkt 6.14 verlangt, dass Alert-Überschreitungen dokumentiert, bewertet und untersucht werden, wobei Einzelereignis und ungünstiger Trend zu unterscheiden sind: Das gelingt nur, wenn die Zeitreihe vollständig und lesbar ist. Die messtechnischen Aspekte behandelt der Artikel zum Online-Monitoring von TOC und Leitfähigkeit.

Der regulatorische Rahmen: was tatsächlich gilt

EudraLex Volume 4, Annex 11 (Computerised Systems). Die geltende Fassung ist die vom Januar 2011, in Kraft seit 30. Juni 2011: Sie ist der Text, an dem heute inspiziert wird. Thematisch abgedeckt sind Risikomanagement, Personal, Lieferanten und Dienstleister, Validierung, Daten, Genauigkeitsprüfungen, Datenspeicherung, Ausdrucke, Audit Trails, Änderungs- und Konfigurationsmanagement, periodische Bewertung, Sicherheit, Vorfallmanagement, elektronische Signatur, Business Continuity und Archivierung.

21 CFR Part 11 ist in Kraft (62 FR 13464 vom 20. März 1997, geändert durch 86 FR 68830 von 2021 und 88 FR 13018 von 2023). Die FDA-Guidance Part 11 – Scope and Application vom September 2003 legt eine enge Auslegung zugrunde und übt in einigen Bereichen Enforcement Discretion, stellt aber ausdrücklich fest, dass "part 11 remains in effect". Die operative Konsequenz ist eindeutig: Die Anwendbarkeit der Part 11 auf ein konkretes Wassersystem ist zu bestimmen und zu dokumentieren — welche Records eine Predicate Rule verlangt, welche elektronisch geführt werden, ob und wo elektronische Signaturen verwendet werden — und nicht aus Gewohnheit anzunehmen oder auszuschließen.

Annex 15 (Revision 2015, in Kraft seit 1. Oktober 2015) regelt die Qualifizierung des Wassersystems, dessen computergestützter Teil eine Komponente und kein Parallelprojekt ist. ASTM E2500-25 liefert den science- and risk-based Ansatz, mit dem Prüfungen aus kritischen Aspekten abgeleitet werden; ICH Q9(R1) (Step 4 am 18. Januar 2023) die Methode, mit der der Umfang der Kontrollen begründet wird. Das PIC/S Aide-Memoire PI 009-4 „Inspection of Utilities“, Rev. 4 in Kraft seit 1. Januar 2021, ist das Dokument, mit dem Inspektoren die Prüfung der Utilities strukturieren.

Keiner dieser Texte legt Backup-Frequenzen, Aufbewahrungsdauern von Logs oder Bewertungsintervalle fest: Das sind Parameter, die der Standort aus dem Risiko ableitet und begründet.

Der Entwurf zur Revision des Annex 11: kein geltender Text

Das muss ausdrücklich gesagt werden, denn es ist derzeit die wichtigste Verwechslungsquelle in Lastenheften. Ein Entwurf zur Revision des Annex 11 wurde gemeinsam mit der Revision von Kapitel 4 und einem neuen Annex 22 zu künstlicher Intelligenz vom 7. Juli 2025 bis 7. Oktober 2025 öffentlich konsultiert. Er wurde nicht verabschiedet, und es ist kein Anwendungsdatum veröffentlicht. Sein Inhalt wird hier nicht wiedergegeben: Er kann sich vor der Verabschiedung ändern, und ihn als Anforderung zu zitieren wäre falsch. Betriebsregel ohne Zwischentöne: Der Entwurf wird nicht als Anforderung in einer URS zitiert, begründet keine Abweichung und erscheint nicht als regulatorische Grundlage in einem Dossier. In der Inspektion gilt der Text von 2011.

Ihn beim Einkauf zu ignorieren wäre dennoch fragwürdig — aus rein technischem Grund: Ein Wassersystem lebt Jahrzehnte, die Software-Infrastruktur wird nur einmal beschafft. Jene Eigenschaften, die ein System gegenüber jeder regulatorischen Entwicklung robust machen — abfragbarer und in offenem Format exportierbarer Audit Trail, Rohdatenexport ohne den Lieferanten, native personalisierte Benutzerkonten und segregierte Rollen, zentrale Zeitsynchronisation, nachweisbarer Restore, Protokollierung von Fernsitzungen, erklärte Support- und Patch-Politik — kosten wenig, wenn sie vor der Bestellung gefordert werden, und werden als Retrofit teuer. Sie gehören jedoch in die URS des Wassersystems als das, was sie sind: Benutzeranforderungen mit Lebenszyklus-Begründung, nicht regulatorische Anforderungen.

Die Kontrollen, die in einer Inspektion tragen

Audit Trail

Annex 11 verlangt auf Basis einer Risikobewertung, dass das System eine Aufzeichnung GMP-relevanter Änderungen und Löschungen erzeugt, die in verständlicher Form verfügbar ist und regelmäßig bewertet wird. Bei einem Wassersystem ergibt sich der Mindestinhalt aus der Datenflusskarte: Alert- und Action-Grenzwerte, Parameter der Sanitisierungszyklen, Verriegelungsüberbrückungen, Deaktivierung eines Alarms oder einer Messstelle, Erfassungskonfiguration, Kalibrierkoeffizienten, Alarmquittierungen, Anmeldungen, Wiederherstellungen aus dem Backup.

Der häufigste Fehler betrifft den Geltungsbereich: Die Aufzeichnung existiert im SCADA, der Parameter ist aber tatsächlich auf SPS-Ebene über die Programmiersoftware veränderbar, wo er keine Spur hinterlässt. Der Audit Trail muss die Ebene abdecken, auf der der Parameter tatsächlich veränderbar ist; ist das nicht möglich, muss der Zugriff auf diese Ebene konstruktiv gesperrt und die Änderung über die protokollierte Ebene geführt werden. Der zweite Fehler betrifft die Lesbarkeit: Eine Aufzeichnung, die nur in einem proprietären Format exportierbar oder nur vom Techniker des Lieferanten interpretierbar ist, funktioniert genau dann nicht, wenn sie gebraucht wird.

Zur Review der Audit Trails legt kein geltender Text eine universelle Frequenz fest. Sie ist vom Standort nach Kritikalität des Parameters zu definieren und zu begründen, typischerweise als Kombination aus ereignisgetriebener Review — jede Untersuchung einer Abweichung prüft, was geändert wurde und von wem — und geplanter periodischer Review. Der Inspektor prüft nicht die Zahl, sondern die Begründung und den Nachweis der Durchführung.

Zugriffsverwaltung

Personalisierte Benutzerkonten, niemals geteilt: Das HMI im Bereich mit dem generischen Konto „Bediener“ bleibt die am leichtesten formulierte und am schwersten zu verteidigende Beanstandung, weil sie jede Zuordnung einer Handlung unmöglich macht. Die Rollen-/Rechtematrix ist ein qualifiziertes Deliverable und keine Werkseinstellung: Sie wird in der URS definiert, in der OQ verifiziert — indem nachgewiesen wird, dass jede Rolle tun kann, was sie soll, und den Rest nicht tun kann — und unter Change Control gehalten. Drei Prinzipien tragen sie. Segregation: Wer Konten administriert, erzeugt und genehmigt keine kritischen Daten. Lebenszyklus des Kontos: Vergabe, Änderung und Entzug an Eintritt, Funktionswechsel und Austritt gekoppelt — aktive Konten ausgeschiedener Personen sind der wiederkehrendste Befund interner Audits. Lieferantenkonten: standardmäßig deaktiviert, auf genehmigte Anforderung und für die Dauer des Einsatzes aktiviert, mit protokollierter Sitzung.

Zeitsynchronisation

SPS, SCADA, Historian, Analysatoren mit eigenem Speicher und LIMS müssen sich auf eine gemeinsame Zeitquelle beziehen. Ohne sie ist die Korrelation zwischen Abweichung, Alarm, Probe, Laborergebnis und ergriffener Maßnahme nicht nachweisbar, und die von Annex 1 6.14 geforderte Untersuchung endet, bevor sie beginnt. Ausdrücklich zu regeln sind Zeitzone und Sommerzeitumstellung — die ohne Vorkehrung doppelte oder fehlende Datensätze erzeugt —, das Zeitstempelformat über die gesamte Kette sowie das eingeschränkte und protokollierte Recht, die Systemuhr zu ändern. Die Verifizierung gehört zur Qualifizierung und wird bei der periodischen Bewertung erneut geprüft.

Alarme

Ein SCADA eines Wassersystems verwaltet ohne Weiteres Hunderte von Tags. Das Problem ist nicht, Alarme zu erzeugen, sondern dass sie beherrschbar sind und jeder zu einer Handlung führt. Die erste Trennung verläuft zwischen Prozess- und Instandhaltungsalarmen und Qualitätsalarmen, also jenen an Alert- und Action-Level für Leitfähigkeit, TOC, Temperatur, Durchfluss und Restozon; ihre Vermischung erzeugt einen undifferenzierten Strom, in dem der Bediener lernt, alles zu ignorieren. Die Konfiguration ist ein formales Deliverable: Tag, Grenzwert, Priorität, Text, Empfänger, erwartete Handlung und Verweis auf die Verfahrensanweisung. Das System muss Alert von Action unterscheiden, den gesamten Lebenszyklus des Ereignisses archivieren — Auslösung, Übernahme, Rückkehr in den Normalzustand, Ergebnis — und die Änderung der Grenzwerte unter Change Control mit Nachweis im Audit Trail erlauben, denn Annex 1 6.13 verlangt die Überprüfung dieser Level. Die zeitweilige Unterdrückung eines Alarms muss eine kontrollierte, protokollierte und befristete Funktion sein, keine aus der Bauphase übernommene Praxis.

Backup und Restore

Zu sichern sind SPS-Programm, SCADA-Konfiguration, Benutzerdatenbank, Zeitreihen, Audit Trail, Rezepte und Zyklusparameter. Entscheidend ist nicht, ob Backups durchgeführt werden, sondern ob der Restore erprobt wurde: eine nie getestete Wiederherstellung ist erklärte, nicht nachgewiesene Kontinuität. Der Test gehört zur Qualifizierung und wird bei der periodischen Bewertung sowie nach wesentlichen Änderungen wiederholt.

Backup-Häufigkeit, Anzahl aufbewahrter Generationen und Aufbewahrungsdauer sind durch keine universelle Zahlenvorgabe festgelegt: Sie werden aus der Kritikalität der Daten, dem maximal akzeptablen Datenverlust für die gestützten Entscheidungen und den am Standort geltenden Aufbewahrungsanforderungen abgeleitet und im Systemrationale dokumentiert. Die Unterscheidung bleibt bestehen zwischen Backup für die betriebliche Wiederherstellung und Archivierung für die Lesbarkeit des Records über die Zeit: Bei einem System, das so lange lebt wie die Schleife, ist die Obsoleszenz von Format und Lesesoftware ein Risiko, das bei der Plattformwahl zu bewerten ist.

Schnittstellen zu anderen Systemen

Ein Wassersystem bleibt selten isoliert: Es tauscht Daten mit dem LIMS (chemische und mikrobiologische Offline-Ergebnisse), mit MES oder ERP, mit EMS oder GLT, mit dem CMMS und mit den in der Product Quality Review genutzten Reporting-Werkzeugen. Für jede Schnittstelle sind festzulegen: ausgetauschtes Datum, Richtung, führendes System für dieses Datum, Prüfungen auf Richtigkeit und Sicherheit der Übertragung, Verhalten bei Nichtverfügbarkeit des Empfängers und Erkennung einer fehlgeschlagenen Übertragung. Annex 11 verlangt gerade, dass Systeme, die Daten elektronisch austauschen, eingebaute Prüfungen für die korrekte und sichere Eingabe und Verarbeitung der Daten enthalten.

Zwei praktische Punkte. Die manuelle Übertragung eines Wertes vom SCADA auf ein Papierformular ist ebenfalls eine Schnittstelle, die unzuverlässigste: Sie ist mit unabhängiger Prüfung zu führen und als Restrisiko zu deklarieren. Und wenn dasselbe Datum in mehreren Systemen lebt, muss entschieden werden, welche Kopie der Record ist — sonst wählt man in der Untersuchung im Nachhinein, welche Version der Wahrheit gilt, was Datenintegrität gerade ausschließt. Dieselbe Logik auf ein Umgebungsmonitoring-System angewandt vertieft der Artikel zur EMS-Software, Annex 11 und Part 11.

Fernzugriff, Cybersecurity und Patching

Die Fernunterstützung des Lieferanten ist der normale Supportweg und zugleich der normale Weg, die Kontrolle über die Konfiguration zu verlieren. Mindestanforderungen für Vertrag und Verfahrensanweisung: nicht permanente, vom Standort initiierte Verbindung, personalisierte Authentifizierung, dokumentierte Freigabe je Einsatz, Aufzeichnung der Sitzung, Bewertung der Änderungen nach Abschluss und Change Control für jeden Eingriff, der Parameter oder Software im validierten Zustand berührt.

In der Cybersecurity ist das Spannungsfeld bekannt: Die Sicherheitslogik verlangt schnelles Patchen, die Validierungslogik, nichts ohne Bewertung zu ändern. Die Antwort ist nicht, eine Seite zu wählen, sondern einen Prozess zu haben: vorab definierte Patch-Kategorien, festgelegte Kriterien zur Bewertung der Auswirkung auf GMP-Funktionen, verhältnismäßige Verifizierung und ein dokumentierter Notfallpfad für kritische Schwachstellen. Auch ein nicht aktualisiertes System ist ein GMP-Risiko: Nichtverfügbarkeit, Verlust historischer Daten und Veränderung von Records sind Qualitätsfolgen. Die Trennung des Automatisierungsnetzes vom Büronetz und vom Internet ist eine Maßnahme der Auslegung. In der URS sind erklärte Supportdauer, Patch-Veröffentlichungspolitik, Versionskompatibilität und Verfügbarkeit der Konfigurationsdokumentation zu fordern: Ein SCADA auf einem nicht mehr unterstützten Betriebssystem löst man mit einem Retrofit, nicht mit einem Patch.

Risikobasierte CSV: wie viel validieren und auf welcher Grundlage

Ausgangspunkt ist eine dokumentierte Festlegung: welche Funktionen GMP-kritisch sind, welche elektronischen Records eine Predicate Rule verlangt, ob und wo elektronische Signaturen verwendet werden. Dieses Assessment legt den Part-11-Geltungsbereich fest und ist mit dem Ansatz der FDA-Guidance von 2003 konsistent. „Das System fällt nicht unter Part 11“ ohne Assessment zu erklären ist nicht verteidigungsfähig; „Alles fällt unter Part 11“ ist teuer und ebenso schwach begründet.

Der Validierungsumfang wird mit der Methode von ICH Q9(R1) am Risiko abgestuft. Die Software eines Wassersystems ist fast immer konfigurierte Software auf einer kommerziellen Plattform: Die wirksame Strategie besteht darin, den Lieferanten zu bewerten — Annex 11 fordert Lieferantenbewertung und Management der Dienstleister —, seine bereits erstellte Entwicklungs- und Testdokumentation dort zu nutzen, wo die Bewertung es erlaubt, und die eigene Verifizierung auf die standortspezifische Konfiguration und die kritischen Funktionen zu konzentrieren.

Die Prüfungen dürfen die Qualifizierung des Wassersystems nicht doppeln: Sie gehören in denselben Plan, mit dem Ansatz von ASTM E2500-25, der jede Verifizierung aus einem identifizierten kritischen Aspekt ableitet. Im Feld geprüft werden typischerweise die Übereinstimmung zwischen dem vom Instrument gelesenen, dem angezeigten und dem bis in den Historian gespeicherten Wert; das Verhalten bei Grenzwertüberschreitung; die tatsächlichen Rechte je Rolle, auch negativ erprobt; die Erzeugung des Audit Trails; der Restore; die Zeitsynchronisation; das Verhalten bei Ausfall von Strom oder Netzwerk. Wie sich diese Tests in FAT, SAT, IQ, OQ und PQ einfügen, behandelt der Artikel zur Qualifizierung des Wassersystems; die Zyklustests, die das System vollständig aufzeichnen muss, jener zur Qualifizierung der Sanitisierungszyklen.

Periodische Bewertung des computergestützten Systems

Annex 11 verlangt, dass computergestützte Systeme periodisch bewertet werden, um zu bestätigen, dass sie im validierten Zustand und konform bleiben. Die Frequenz ist nicht durch eine Zahl vorgegeben: Sie wird nach Kritikalität und Risiko festgelegt, in einer Verfahrensanweisung beschrieben und begründet. Nützlich statt formal wird die Review durch: durchgeführte Änderungen und ihren Change-Control-Status; Abweichungen und Vorfälle; Alarmperformance einschließlich chronischer Alarme und noch aktiver Unterdrückungen; Ergebnis der Audit-Trail-Reviews; Abgleich der Kontenliste mit dem tatsächlichen Personal; Ergebnis der Restore-Tests; Stand von Softwaresupport und Obsoleszenz; Kalibrierrückstand. Sie ist keine separate Übung: Sie betrachtet dieselben Trends wie die periodische Überprüfung des Wassersystems und ist gemeinsam mit ihr zu planen. Die weiteren Lebenszyklusphasen sind im Hub des Clusters Pharmaceutical Water & WFI gesammelt.

Anwendungsbeispiel: Standort Delta

Didaktisches Beispiel, fiktiver Standort. Standort Delta beschafft ein neues WFI-System und behandelt die Automatisierung als Zubehör der mechanischen Lieferung. In der Design Review treten vier Punkte hervor: Der TOC-Analysator hat eigenen Speicher, eigene Konten und einen eigenen, nicht mit dem SCADA integrierten Audit Trail; die Alert-Grenzwerte sind aus der SPS-Programmiersoftware ohne Nachweis im SCADA veränderbar; die Erfassungskonfiguration des Historian wurde vom Integrator festgelegt und taucht in keiner Spezifikation auf; das Backup deckt nur die historische Datenbank ab, und die vorgesehenen Konten werden schichtweise geteilt.

Vor dem FAT vereinbarte Maßnahmen: von Engineering und QA unterzeichnete Datenflusskarte; Liste der kritischen Parameter mit der Ebene, auf der sie liegen, und der Audit-Trail-Anforderung auf dieser Ebene; Änderung der Grenzwerte auf SPS-Ebene gesperrt und über das SCADA mit personalisierten Konten geführt; Historian-Konfiguration als qualifizierter Parameter deklariert und unter Change Control gestellt; vollständiger Restore-Test in der OQ; TOC-Analysator als eigenständiges System behandelt. Die Kosten konzentrierten sich vor der Bestellung, wo sie eine Vertragsklausel sind: Dieselben Änderungen nach dem SAT wären Nachträge zum Lieferantenpreis mit Terminverzug gewesen.

Entscheidungsmatrix: Architektur der Datenhaltung

Die Gewichtsspalte ist bewusst leer: Die Gewichte hängen von der Produktkritikalität, vom Systembestand und von der IT/OT-Reife des Standorts ab und sind vor der Bewertung intern zu vergeben und zu begründen.

Checkliste für Design Review und internes Audit

• Genehmigte Datenflusskarte mit Referenzrecord für jeden kritischen Parameter.
• Dokumentiertes Assessment zur Anwendbarkeit der Part 11 und zur GMP-Kritikalität der Funktionen.
• Audit Trail auf der Ebene aktiv, auf der Parameter veränderbar sind, und ohne Lieferanten exportierbar.
• Historian-Konfiguration deklariert, qualifiziert und unter Change Control.
• Rollen-/Rechtematrix positiv und negativ verifiziert; keine geteilten Konten; Entzug an die Personalprozesse gekoppelt.
• Gemeinsame Zeitquelle; dokumentierter Umgang mit Zeitzone und Sommerzeit.
• Alarmliste mit Priorität und erwarteter Handlung; Alert von Action getrennt; keine dauerhafte Unterdrückung.
• Restore-Test durchgeführt und dokumentiert, nicht nur geplant.
• Fernzugriff des Lieferanten nicht permanent, je Einsatz freigegeben und protokolliert.

Häufige Fehler und Red Flags

• „Das System ist Part 11 compliant“, erklärt vom Lieferanten. Compliance ist eine Eigenschaft der Implementierung und der Nutzung, nicht des Produkts.
• Der Entwurf zur Revision des Annex 11 als Anforderung zitiert. Er ist nicht verabschiedet und hat kein Anwendungsdatum: Es gilt der Text vom Januar 2011.
• Audit Trail nur auf SCADA-Ebene, während Grenzwerte in der SPS veränderbar sind. Die Aufzeichnung deckt den Ort der tatsächlichen Änderung nicht ab.
• Geteilte Konten am HMI im Bereich. Sie machen die Zuordnung einer Handlung zu einer Person unmöglich.
• Kompression oder Aufzeichnungsintervall bei der Inbetriebnahme eingestellt und nie formalisiert. Das für die Untersuchung benötigte Datum kann nicht mehr existieren.
• Regelmäßige Backups und nie erprobter Restore. Erklärte, nicht nachgewiesene Kontinuität.
• Dauerhaft aktive Fernverbindung des Lieferanten. Der validierte Zustand der Konfiguration ist nicht verteidigungsfähig.
• Qualitätsalarme mit Instandhaltungsalarmen vermischt. Sie verhindern die von Annex 1 6.14 geforderte Unterscheidung zwischen Einzelereignis und ungünstigem Trend.
• Nicht synchronisierte Uhren von SPS, SCADA, Analysatoren und LIMS. Die Ereignisabfolge wird unbeweisbar.
• Frequenzen für Backup, Review oder periodische Bewertung von einem anderen Standort kopiert. Sie sind aus dem Risiko des eigenen Systems abzuleiten und zu begründen.

Wenn diese Art der Analyse in Ihrer täglichen Arbeit nützlich ist: The Pragmatic GMP bündelt technische Vertiefungen und regulatorische Updates im selben Stil.

Key Takeaways

• Das Automatisierungssystem ist der Ort, an dem die von Annex 1 6.15 geforderte kontinuierliche Überwachung zum Record wird: Ist der Record nicht rekonstruierbar, belegt die Überwachung nichts.
• Der Geltungsbereich ergibt sich aus der GMP-Entscheidung, die jedes Datum stützt, nicht aus dem Etikett des Lieferanten.
• Anzuwenden ist die Fassung des Annex 11 vom Januar 2011; der bis 7. Oktober 2025 konsultierte Entwurf wurde nicht verabschiedet und wird nicht als Anforderung zitiert.
• Die Anwendbarkeit der Part 11 wird bestimmt und dokumentiert: Die FDA-Guidance von 2003 verengt die Auslegung, bestätigt aber, dass Part 11 in Kraft bleibt.
• Ein Audit Trail auf der richtigen Ebene, personalisierte Konten, eine gemeinsame Uhr und ein erprobter Restore wiegen mehr als jede Konformitätserklärung des Lieferanten.
• Frequenzen für Backup, Review und periodische Bewertung sind nicht durch eine regulatorische Zahl festgelegt: Sie werden aus dem Risiko abgeleitet und begründet.

Referenzen

• EudraLex Volume 4, Annex 11 Computerised Systems — Fassung Januar 2011, in Kraft seit 30. Juni 2011. Revisionsentwurf (mit Kapitel 4 und neuem Annex 22) in Konsultation vom 7. Juli bis 7. Oktober 2025, nicht verabschiedet. health.ec.europa.eu
• EudraLex Volume 4, Annex 1 (C(2022) 5938 final), in Kraft seit 25. August 2023 — Punkte 6.13, 6.14, 6.15. Annex 15, Revision 2015, in Kraft seit 1. Oktober 2015.
• 21 CFR Part 11 — in Kraft. ecfr.gov
• FDA, Part 11 – Scope and Application, September 2003 — enge Auslegung und Enforcement Discretion; "part 11 remains in effect".
• ICH Q9(R1) Quality Risk Management, Step 4 am 18. Januar 2023. ich.org
• PIC/S PE 009-17 und Aide-Memoire PI 009-4 Inspection of Utilities, Rev. 4, in Kraft seit 1. Januar 2021. picscheme.org
• ASTM E2500-25; WHO TRS 1033, Annex 3 (2021). who.int