Nach einem Entwicklungsversuch wird ein Rezept geändert, doch der Bericht erhält nur den Zyklusnamen. Der nächste Lauf endet ohne Alarm und die Charge wird mit einem PDF verknüpft, das keine Version nennt. Die Maschine kann ihre Logik korrekt ausgeführt haben; trotzdem fehlt die Verbindung zwischen genehmigten Parametern, tatsächlicher Konfiguration und behandeltem Material. Genau diese Verbindung muss Automatisierung überprüfbar machen.
1. Die Grenze des computergestützten Systems bestimmen
Das System umfasst mehr als die PLC. HMI, unabhängigen Schreiber, Historian, Server, Datenbank, Benutzerverwaltung, Zeitsynchronisation, Sicherung und Schnittstellen zu MES oder Qualitätssystemen berücksichtigen. Identifizieren, wo Daten entstehen, verändert und aufbewahrt werden. Ein Datenflussdiagramm muss auch unterbrochene Kommunikation und zeitweise eigenständigen Betrieb beschreiben, damit Fehlerzustände nicht außerhalb der dokumentierten Systemgrenze bleiben.
Prozesssteuerung und Dokumentenverwaltung unterscheiden. Ein im Qualitätssystem genehmigtes Rezept beweist nicht, dass dieselben Parameter in der PLC aktiv sind. Eine richtige PLC-Aufzeichnung beweist nicht, dass beim Export sämtliche Ereignisse erhalten blieben. Schnittstellen gehören zur vorgesehenen Verwendung und müssen bewertet werden. Gerade an Systemübergängen entstehen häufig unbemerkte Lücken zwischen organisatorischer Freigabe und technischer Ausführung.
[REGULATORY REQUIREMENT] EU GMP Annex 11 verlangt einen risikobasierten Lebenszyklusansatz für computergestützte Systeme in GMP-Tätigkeiten. Zum Prüfzeitpunkt führt EudraLex die Fassung von 2011 als geltenden Text. Überarbeitungsvorschläge dürfen nicht als bereits wirksame Anforderungen dargestellt werden. Das Projekt muss erkennen lassen, welche gültigen Vorgaben und welche zusätzlichen Empfehlungen seine Entscheidungen begründen.
2. Prozessstrategie in prüfbare Zustände übersetzen
Die Sequenz als Zustände und Übergänge beschreiben: bereit, Beladung identifiziert, Konditionierung, Exposition, Trocknung oder Abkühlung, abgeschlossen, Störung und Stillstand. Für jeden Übergang Voraussetzungen, Zeitüberwachung, gespeicherte Ereignisse und Ausgangszustände definieren. Das Verhalten muss ohne Lesen des Quellcodes verständlich sein. Diese Beschreibung schafft eine gemeinsame Grundlage für Engineering, Produktion und spätere Funktionsprüfungen.
Der Übergang zur Exposition muss die validierte Strategie widerspiegeln. Hängt er von mehreren Messwerten ab, den Umgang mit fehlenden oder ungültigen Werten klären. Signalverlust darf nicht versehentlich als erfüllte Bedingung gelten. Dasselbe gilt für Zyklusende, Entnahmefreigabe und Übergang in einen kritischeren Bereich. Die Fehlerbehandlung ist Teil der Funktion, keine nachträgliche Ergänzung.
[GEP] Für kritische Verriegelungen und Alarme eine Ursache-Wirkungs-Matrix verwenden. Ereignis, Phase, Aktion, sicheren Zustand und Wiederherstellungsbedingungen dokumentieren. Sie unterstützt Entwicklung, Prüfung und Tests und reduziert Unterschiede zwischen Funktionsspezifikation, Programm und Verfahren. Änderungen an einer dieser Ebenen müssen auf die anderen zurückgeführt werden, damit die Beschreibung aktuell bleibt.
3. Rezepte kontrolliert verwalten
Jedes Rezept braucht Identität, Version, Status und Nutzungsbereich. Entwicklungs-, Prüf- und Produktionsrezepte trennen und unbeabsichtigte Verwendung nicht genehmigter Konfigurationen verhindern. Festlegen, welche Parameter unveränderlich, auswählbar oder innerhalb autorisierter Grenzen anpassbar sind. Auch die Berechtigung zur Übertragung eines Rezepts in den Produktionsbereich gehört zu dieser kontrollierten Verwaltung.
Die Prüfung muss alte und neue Inhalte, Begründung, Auswirkungen und erforderliche Genehmigungen vergleichen. Der Zyklusdatensatz identifiziert die tatsächlich ausgeführte Version und erhält die zur Rekonstruktion benötigten Werte. Nur „Komponentenzyklus“ zu speichern unterscheidet keine verschiedenen Konfigurationen mit gleichem Namen. Ein Versionsverweis muss dauerhaft auf den damals gültigen Inhalt auflösbar bleiben.
Den Zeitpunkt des Ladens in den Controller berücksichtigen. Wird während eines laufenden Zyklus eine Änderung genehmigt, muss klar sein, welche Version diesen Lauf steuert. Prüfen, dass Aktualisierung und Synchronisation aktive Parameter nicht stillschweigend verändern. Der Beginn einer neuen Rezeptgültigkeit sollte sowohl technisch als auch in den Aufzeichnungen eindeutig erkennbar sein.
4. Zugriffe an Verantwortlichkeiten ausrichten
Rollen für Bedienung, Aufsicht, Wartung, Administration und Prüfung definieren. Notwendige Rechte zuweisen und Zyklusausführung von Konfigurationsänderung unterscheiden. Bei kritischen Tätigkeiten Aufgabentrennung unter Berücksichtigung der Standortorganisation und dokumentierter Ersatzkontrollen bewerten. Eine Rollenliste genügt nicht, wenn die tatsächlichen Berechtigungen wesentlich weiter reichen als die beschriebenen Aufgaben.
Konten müssen Handlungen autorisierten Personen zuordnen lassen. Gemeinsame Zugangsdaten schwächen diese Fähigkeit und verlangen eine konkrete Bewertung der Systemgrenzen. Lieferantenzugriff benötigt Zweck, Autorisierung, Dauer und Aufzeichnung gemäß Standortverfahren. Technischer Support sollte nicht unbeabsichtigt dauerhafte Möglichkeiten zur Änderung kritischer Einstellungen erhalten, die außerhalb der üblichen Prüfung bleiben.
Erstellung, Änderung, Deaktivierung und Ablauf von Zugängen zusätzlich zum normalen Login prüfen. Untersuchen, was mit einer offenen Sitzung nach Rechteentzug geschieht und wie nicht mehr verwendete Konten behandelt werden. Administrative Funktionen gehören in die Verifikation, weil sie Kontrollen verändern können, auf denen das Vertrauen in Prozess und Daten beruht.
5. Den Audit Trail nutzbar machen
Der Audit Trail muss erkennen lassen, wer wann an welchem Element mit welchem Ergebnis handelte. Für relevante Änderungen vorherige und neue Werte sowie erforderliche Begründungen erhalten. Die Aufzeichnungskonfiguration schützen und für prozess- oder datenrelevante Funktionen prüfen. Eine vorhandene Tabelle mit Ereignissen beweist noch nicht, dass alle entscheidenden Änderungen tatsächlich erfasst werden.
Einträge haben unterschiedliche Bedeutung. Rezeptänderung, deaktivierter Alarm, Uhrumstellung und fehlgeschlagener Login unterstützen verschiedene Bewertungen. Festlegen, welche Ereignisse je Zyklus, periodisch oder sofort geprüft werden. Die Häufigkeit aus Risiko und Verwendung begründen. Auch die Verantwortung für Untersuchung und Abschluss auffälliger Einträge sollte eindeutig sein, damit Prüfung zu einer nachvollziehbaren Handlung führt.
Exporte müssen Reihenfolge, Identität und Kontext erhalten. Filter, Seitenaufteilung und Zeitbereiche prüfen, damit eine vollständig wirkende Ausgabe keine Ereignisse auslässt. Den Zugriff auf Originaldaten bewahren; ein Bildschirmfoto ist kein allgemeiner Ersatz für elektronische Aufzeichnungen. Die gewählte Darstellung muss den vorgesehenen Prüfzweck erfüllen und ihre Grenzen erkennen lassen.
6. Alarme, Abbruch und Neustart verbinden
Ein Abbruch unterbricht die Sequenz oder bringt sie in einen definierten sicheren Zustand. Neustart kann Fortsetzung, neuen Ablauf oder ein Fortsetzungsverbot bedeuten. Diese Regeln während Entwicklung festlegen und validieren. Sie dürfen nicht erst im Störungsfall von einer Bedienpräferenz abhängen. Auch die notwendige Entscheidung über die vorhandene Beladung gehört zur Beschreibung.
Festlegen, welche Ereignisse den Leistungsnachweis unmöglich machen, auch wenn kein mechanischer Schaden entsteht. Verlust kritischer Daten, falsches Rezept oder ungeprüfte Voraussetzung können andere Maßnahmen verlangen als ein Hinweis. Die Abschlussmeldung muss den Zustand richtig wiedergeben und darf frühere Ereignisse nicht auslöschen. Der Bericht muss die tatsächliche Geschichte des Laufs erhalten.
Nach Stromverlust muss das System den unterbrochenen Zyklus erkennen und erhaltene Informationen bereitstellen. Prüfungen sollten verschiedene Phasen abdecken. Ein erfolgreich gestarteter Controller beweist technische Verfügbarkeit, nicht Konformität der während des Ausfalls vorhandenen Beladung. Diese Unterscheidung muss sowohl in der Softwareanzeige als auch im betrieblichen Verfahren verständlich bleiben.
7. Originalaufzeichnung und Kopien definieren
Festlegen, welche Daten für die GMP-Entscheidung erforderlich sind und wo sie liegen. Beladungsidentität, Rezeptversion, tatsächliche Werte, Ereignisse, Metadaten und relevante Genehmigungen einschließen. Bei verteilten Aufzeichnungen Verbindungen und Aufbewahrungsverantwortung dokumentieren. Die Vollständigkeit muss über alle beteiligten Systeme hinweg beurteilt werden, nicht nur innerhalb der jeweils bequem zugänglichen Anwendung.
Ein PDF kann eine nützliche Prüfkopie sein, benötigt aber den Nachweis, dass es die für seinen Zweck erforderlichen Informationen erhält. Dynamische Daten, Audit Trail und nicht exportierte Details können das Ursprungssystem oder ein geeignetes Archiv erfordern. Die Entscheidung begründen und nicht ausschließlich auf einfache Druckbarkeit stützen. Auch spätere Untersuchungen müssen möglich bleiben.
Vollständigkeit und Genauigkeit der Übergabe an Historian oder MES prüfen. Duplikate, Verzögerungen, falsche Reihenfolge und vorübergehenden Netzverlust berücksichtigen. Abgleichregeln müssen Probleme sichtbar machen und verhindern, dass ein Bericht trotz fehlender Daten als vollständig gilt. Die Wiederübertragung darf dabei nicht unbemerkt zusätzliche oder widersprüchliche Datensätze erzeugen.
8. Wesentliche Prüfszenarien
| Funktion | Szenario | Erwarteter Nachweis |
|---|---|---|
| Rezept | Genehmigte Änderung vor und während eines Laufs | Eindeutige kontrollierte Version |
| Zugriff | Unberechtigte kritische Änderung | Verhinderung und relevante Aufzeichnung |
| Alarm | Kritischer Messverlust während Exposition | Spezifikationsgerechte Reaktion und Daten |
| Kommunikation | Verbindung zwischen PLC und Aufzeichnung unterbrochen | Erkannte Lücke und abgeglichene Wiederherstellung |
| Sicherung | Wiederherstellung autorisierter Konfiguration | Lesbare, vollständige und nutzbare Daten |
| Uhr | Autorisierte Änderung oder Synchronisationsverlust | Rekonstruierbare zeitliche Reihenfolge |
Diese Szenarien sind eine praktische [GUIDEGXP RECOMMENDATION], keine vollständige normative Liste. Der Plan muss systemspezifische Risiken und vorab festgelegte Kriterien enthalten. Ein erfolgreicher Test zeigt das geforderte Verhalten, nicht nur das Ausbleiben einer Fehlermeldung. Die Dokumentation sollte Ausgangszustand, ausgeführte Handlung und beobachtete Folgen miteinander verbinden.
9. Sicherung, Wiederherstellung und Kontinuität
Sicherungen müssen die für Wiederherstellung benötigten Daten und Konfigurationen umfassen. Je nach Architektur Rezepte, Programme, Parameter, Benutzer, Zertifikate und relevante Komponenten identifizieren. Kopien schützen und die Funktion des Sicherungsprozesses prüfen. Eine Datei im Zielordner beweist nicht, dass sich der erforderliche Zustand vollständig und korrekt wiederherstellen lässt.
Wiederherstellungstests müssen Nutzbarkeit sowie vollständige, lesbare Aufzeichnungen zeigen. Bedingungen so festlegen, dass die Prüfung die Produktion nicht beeinträchtigt. Version, Umgebung, Beispieldaten, Ergebnis und Testgrenzen dokumentieren. Eine erfolgreiche Teilwiederherstellung kann nützlich sein, darf aber nicht ohne Begründung als Nachweis für sämtliche Systemfunktionen und Datenbestände gelten.
Der Kontinuitätsplan muss den Umgang mit nicht verfügbarem elektronischem System erklären. Ein zeitweiliges manuelles Verfahren ist nur geeignet, wenn es vorgesehen ist und notwendige Kontrollen erhält. Keine unbelegten rückwirkenden Einträge zur Schließung einer Datenlücke erzeugen. Entscheidungen müssen erkennen lassen, welche zeitnahen Nachweise tatsächlich vorhanden sind und welche Informationen fehlen.
10. Beispiel eines vollständig wirkenden Berichts
In einem illustrativen Fall meldet das PDF einen erfolgreichen PLC-Zyklus, während der Historian in einer kritischen Phase seine Verbindung verlor. Der Controller besitzt einige lokale Daten, doch der Druckbericht zeigt keine Lücke. Das Team setzt automatische Annahme aus und bewertet die verfügbaren Originalnachweise, bevor es über das Material entscheidet.
Die Untersuchung trennt physische Leistung von Aufzeichnungsvollständigkeit und prüft, ob lokale Daten eine zuverlässige Rekonstruktion erlauben. Die Korrektur umfasst sichtbare Meldung unvollständiger Übertragungen und ein Abgleichverfahren. Folgeprüfungen enthalten Verbindungsverlust, Wiederherstellung und Duplikatvermeidung. Die Lösung muss die Ursache adressieren und darf nicht lediglich das Layout des Berichts verändern.
Ein Bericht darf keine größere Vollständigkeit vermitteln, als die Daten besitzen. Abschlussstatus und Ausnahmen müssen sichtbar sein. Das Qualitätssystem entscheidet über Material anhand tatsächlicher Nachweise, nicht anhand eines professionell gestalteten Dokuments. Diese Regel ist besonders wichtig, wenn mehrere Systeme unterschiedliche Teilinformationen zu demselben Zyklus liefern.
11. Validierung und Lieferantenmanagement
Kompetenz, Entwicklungsprozesse, Versionsverwaltung und Unterstützung des Lieferanten bewerten. Herstellerunterlagen und Tests können nach angemessener Prüfung beitragen. Die Verantwortung des Standorts für den GMP-Einsatz wird nicht durch den Kauf eines „validierten“ Pakets übertragen. Das Projekt muss zeigen, wie die gelieferten Nachweise das tatsächliche vorgesehene System und seine Nutzung abdecken.
[GUIDANCE] GAMP 5, zweite Ausgabe von 2022, bietet einen Rahmen guter Praxis für computergestützte Systeme. Es handelt sich weder um Gesetz noch automatische Softwarezertifizierung. Der Nachweisumfang muss Risiko, vorgesehener Verwendung und Systemkenntnis entsprechen. Eine Produktbeschreibung mit dem Begriff GAMP ersetzt keine begründete Prüfung kritischer Funktionen.
URS, Spezifikationen, Risikoanalyse, Tests und Abweichungen verbinden. Freigabekriterien und Verantwortung für den Erhalt des validierten Zustands festlegen. Eine Liste ausgeführter Prüfungen genügt nicht, wenn ihre Anforderungsabdeckung und verbleibende Risiken unklar sind. Offene Punkte benötigen eine bewertete Bedeutung für den Einsatz und eine autorisierte Entscheidung.
12. Änderungen und regelmäßige Bewertung
Softwareupdates, Patches, Hardwarewechsel, Migration und Schnittstellenänderungen können Steuerung oder Daten beeinflussen. Änderungskontrolle muss Auswirkungen, Tests, Rückkehrplan und Dokumentation bewerten. Gleichwertigkeit anhand relevanter Eigenschaften begründen, nicht nur anhand einer Modellbezeichnung. Auch eine technisch kleine Änderung kann wichtig sein, wenn sie Zeitverhalten, Messverarbeitung oder Aufbewahrung verändert.
Regelmäßige Bewertung umfasst Vorfälle, Zugänge, Leistung, Sicherungen, Änderungen, Dokumentation und Unterstützbarkeit. Externe Abhängigkeiten und nicht mehr unterstützte Komponenten einschließen. Modernisierung planen, bevor dringender Ersatz Entscheidungen ohne ausreichende Nachweise erzwingt. Bekannte Lebenszyklusrisiken sollten mit Verantwortlichen und Maßnahmen versehen werden, statt nur auf einer unverbindlichen Wunschliste zu stehen.
Warnsignale sind unkontrollierte gemeinsame Konten, unversionierte Rezepte, nicht prüfbarer Audit Trail, nie wiederhergestellte Sicherungen und Berichte mit verdeckten Lücken. Gute Automatisierung zeigt die Beziehung zwischen genehmigter Konfiguration, Benutzeraktionen, ausgeführtem Prozess und erhaltenen Daten. Diese Beziehung muss während des gesamten Lebenszyklus verständlich und überprüfbar bleiben.
13. Übergabe an die Produktion
Vor Freigabe Übereinstimmung zwischen installierter und geprüfter Konfiguration sowie genehmigte Produktionsrezepte bestätigen. Verfahren, Schulung, Störungsmanagement und administrative Zuständigkeit prüfen. Offene Abweichungen brauchen dokumentierte Auswirkungsbewertung und autorisierte Entscheidung. Eine Restpunkteliste darf keine kritische, noch unbewiesene Funktion hinter allgemeinen Projektaufgaben verbergen.
Eine wiederherstellbare Ausgangskonfiguration von Software und Einstellungen mit Versions- und Prüfverweisen übergeben. Der Standort muss Unterstützung erhalten können und wissen, welche Lieferanteneingriffe vorherige Autorisierung verlangen. Auch festlegen, wie unerwartete Änderungen nach Fernzugriff oder Wartung erkannt werden. Die Übergabe umfasst damit technische Unterlagen und klare Regeln ihrer weiteren Nutzung.
Mit Nutzern einen praktischen Ablauf demonstrieren: Beladung auswählen, starten, Datensatz lesen, Ausnahme behandeln und archivierte Daten abrufen. Das zeigt, ob das System nach den Verfahren nutzbar ist. Es ersetzt keine Validierung, kann aber organisatorische Lücken vor Produktionsbeginn sichtbar machen. Solche Erkenntnisse sollten in Schulung und Anweisungen zurückgeführt werden.
Quellen und weitere Inhalte
Quellen geprüft am 23. September 2026: EU GMP Annex 11, gelistete geltende Fassung, und Annex 15; ISPE GAMP 5, zweite Ausgabe 2022. Die Matrizen sind eigenständig erstellt und reproduzieren keine geschützten Verfahren.
Weitere Inhalte: Sterilization & Depyrogenation Systems, Zyklusüberwachung, Qualifizierung und Automation & Digital Systems.
