Der Retrofit eines Umgebungsmonitoring-Systems ist ein schwierigeres Projekt als eine Neuanlage — und wird fast immer so angegangen, als wäre er einfacher. Die Unterschiede sind erheblich: Man arbeitet an einem Standort im laufenden Betrieb, mit Zutritts- und Stillstandsrestriktionen; es gibt eine Datenhistorie, die zu bewahren und vergleichbar zu halten ist; es gibt eingespielte Verfahren, Gewohnheiten und Erwartungen; und es gibt Entscheidungen aus früheren Jahren, getroffen von Personen, die sie oft nicht mehr erläutern können.
Die Betriebsregel ist einfach: Bevor entschieden wird, was geändert werden soll, ist genau festzustellen, was das bestehende System nicht leistet — und warum. Ein ohne strukturiertes Gap Assessment gestarteter Retrofit erzeugt fast immer ein neues System mit denselben Problemen wie das alte, weil die Probleme in der Monitoringstrategie, in der Konfiguration oder in der Führung lagen — nicht in der Technologie.
Woraus ein Retrofit-Projekt entsteht
Typischerweise gibt es fünf Auslöser, die zu unterschiedlichen Maßnahmen führen. Sie ausdrücklich zu trennen lohnt sich, denn ihre Vermischung ist die erste Ursache eines falschen Umfangs:
- Technische Obsoleszenz: Supportende der Software, fehlende Ersatzteile, nicht mehr aktualisierbare Betriebssysteme. Eine externe Randbedingung mit Frist.
- Data-Integrity-Lücken: kein adäquater Audit Trail, geteilte Konten, Aufzeichnungen ohne Lieferanten nicht prüfbar. Betrifft Bauweise und Konfiguration des Systems.
- Abdeckungslücken: Messstellen nicht mehr konsistent mit dem Risk Assessment, veränderte Bereiche, neue Linien. Betrifft die Strategie, nicht das System.
- Inspektionsbefund oder Auditergebnis: mit Frist und einem durch die Beobachtung gesetzten Umfang, zu beantworten mit einer gezielten, nachprüfbaren Maßnahme.
- Prozessentwicklung: neue Betriebsanforderungen, Integrationen, mehr Messstellen. Ein Erweiterungsprojekt, nicht zwingend ein Ersatz.
Die Auslöser können zusammen auftreten, müssen aber getrennt erkannt werden: Die Antwort auf eine Strategielücke ist kein neues System, und die Antwort auf Softwareobsoleszenz ist keine Überarbeitung der Messstellenkarte.
Der regulatorische Rahmen
| Ebene | Was sie zu Eingriffen an bestehenden Systemen festlegt |
|---|---|
| Regulatorische Anforderung (EudraLex Volume 4, Annex 15) | Verlangt, dass Änderungen über Change Control gesteuert werden, mit Auswirkungsbewertung auf den qualifizierten Zustand und risikobasiert festgelegtem Requalifizierungsumfang. |
| Regulatorische Anforderung (Annex 11, Revision Januar 2011) | Gilt für die geänderte oder ersetzte computergestützte Komponente, einschließlich Datenmigration und Lesbarkeit über die Zeit. |
| Regulatorische Anforderung (EudraLex Volume 4, Annex 1) | Verlangt, dass das Monitoringprogramm konsistent mit dem Risk Assessment und der Contamination Control Strategy bleibt: Jede Änderung der Abdeckung ist darauf zurückzuführen. |
| Regulatorische Anforderung (Datenaufbewahrung) | Historische Daten bleiben den anwendbaren Aufbewahrungspflichten unterworfen, auch nach Außerbetriebnahme des erzeugenden Systems. |
| Gute Ingenieurpraxis | Planung von Arbeiten im klassifizierten Bereich, Steuerung der Koexistenz von Systemen, Minimierung von Stillständen und Hüllenöffnungen. |
| Operative Empfehlung GuideGxP | Das Gap Assessment vor der Umfangsdefinition durchführen und jede Lücke nach Natur klassifizieren — Strategie, Konfiguration, Technologie, Führung —, denn nur Technologielücken lassen sich durch Beschaffung schließen. |
Wie das Gap Assessment durchgeführt wird
Das Gap Assessment vergleicht das bestehende System mit den Anforderungen, die es heute erfüllen sollte — nicht mit jenen, gegen die es beschafft wurde. Die Abfolge:
1. Aktuelle Anforderungen rekonstruieren
Bevor das System betrachtet wird, ist zu definieren, was heute gebraucht wird: aktualisierter Intended Use, GMP-Entscheidungen, die auf den Daten beruhen, Bereiche und Messstellen, die das aktuelle Risk Assessment rechtfertigt, anwendbare Data-Integrity-Anforderungen, Integrationsbedarf. In vielen Fällen ist dies der nützlichste Teil der gesamten Übung, weil die ursprüngliche URS — sofern vorhanden — einen inzwischen veränderten Kontext abbildet.
2. Den tatsächlichen Systemzustand erheben
Nicht den dokumentierten, sondern den tatsächlichen. Tatsächlich installierte Messstellen und ihre Übereinstimmung mit der genehmigten Karte; aktuelle Konfiguration gegenüber der Baseline; eingesetzte Softwareversionen und Supportstatus; aktive Konten und vergebene Berechtigungen; Verhalten des Audit Trail; Kalibrierstatus der Geräte; verfügbare und aktuelle As-built-Dokumentation; bestehende Serviceverträge. Der Unterschied zwischen Dokumentiertem und Vorgefundenem ist für sich genommen bereits ein Ergebnis.
3. Jede Lücke nach Natur klassifizieren
| Natur der Lücke | Beispiel | Art der Lösung |
|---|---|---|
| Strategie | Messstellen nicht konsistent mit dem aktuellen Risk Assessment | Überarbeitung der Probenahmestrategie; kann ohne Eingriff am System auskommen |
| Konfiguration | Geteilte Konten, nicht getrennte Berechtigungen, von Bedienern änderbare Grenzwerte | Umkonfiguration, Nachverifizierung und Verfahrensaktualisierung |
| Führung | Audit Trail nie geprüft, überfällige Kalibrierungen, Backup nie wiederhergestellt | Verfahren und Betriebsführungsplan |
| Technologie | Audit Trail konstruktiv nicht vorhanden, Export unmöglich, Support beendet | Ersatz oder Upgrade der Komponente |
| Dokumentation | As-built nicht verfügbar, Qualifizierung unvollständig | Dokumentarische Rekonstruktion und Feldverifizierung |
Die Klassifizierung ist der Kern der Methode: Nur Technologielücken lassen sich durch Beschaffung schließen. Ein Projekt, das Führungslücken mit einem Kauf beantwortet, erzeugt ein neues, gleich geführtes System — und damit dieselben Befunde.
4. Kritikalität und Priorität bewerten
Jede Lücke ist nach Auswirkung auf die Produktqualität und auf die Belastbarkeit der Daten sowie nach Dringlichkeit zu bewerten. Ergebnis ist eine Prioritätenfolge, die unterscheidet, was sofort zu lösen ist, was in das Projekt gehört und was mit dokumentierter Begründung akzeptiert werden kann.
Entscheidungswerkzeug: Nachbesserung, Retrofit oder Ersatz
| Kriterium | Spricht für gezielte Nachbesserung | Spricht für Teil-Retrofit | Spricht für Ersatz |
|---|---|---|---|
| Überwiegende Natur der Lücken | Führung und Konfiguration | Technologie in Systemteilen | Technologie der zentralen Plattform |
| Supportstatus des Lieferanten | Aktiv | Aktiv mit Einschränkungen | Beendet oder Ende angekündigt |
| Erfüllbarkeit der Data-Integrity-Anforderungen | Ja, durch Umkonfiguration | Teilweise | Nein, wegen konstruktiver Grenzen |
| Konsistenz der Abdeckung mit dem Risk Assessment | Wiederherstellbar | Mit Ergänzungen wiederherstellbar | Erfordert Neuplanung |
| Verfügbarkeit der Dokumentation | Ausreichend | Rekonstruierbar | Nicht rekonstruierbar |
| Produktionshorizont des Bereichs | Beliebig | Mittel | Lang |
| Auswirkung auf die Produktion | Minimal | Phasenweise beherrschbar | Erheblich, zu planen |
Die wirtschaftliche Bewertung ist über den gesamten Lebenszyklus vorzunehmen, nicht nur über die Erstinvestition: Eine günstige Nachbesserung, die das System ohne Support lässt, verschiebt das Problem nur um wenige Monate. Das Thema wird im Beitrag zu den Gesamtbetriebskosten eines EMS vertieft.
Den Eingriff im laufenden Betrieb führen
- Monitoringkontinuität: Für jede Phase ist zu definieren, wie das geforderte Monitoring während der Arbeiten sichergestellt wird. Provisorien werden für den vorgesehenen Zweck qualifiziert, nicht improvisiert.
- Koexistenz der Systeme: Bestehen alt und neu nebeneinander, ist festzulegen, welches für jede Messstelle und jeden Zeitraum maßgeblich ist — mit exakten, dokumentierten Daten.
- Arbeiten im klassifizierten Bereich: Jede Hüllenöffnung, jede neue Durchführung, jeder Zutritt externen Personals erfordert eine Bewertung der Kontaminationsauswirkung, Planung und, falls nötig, Requalifizierung des betroffenen Bereichs.
- Historische Daten: Die Strategie wird zu Beginn entschieden — Migration, Archivierung in unabhängigem Format, Weiterbetrieb des alten Systems im Lesemodus — mit Prüfplan für Vollständigkeit und Richtigkeit und Augenmerk auf die Lesbarkeit über die gesamte Aufbewahrungsfrist.
- Trendvergleichbarkeit: Ein System- oder Methodenwechsel unterbricht die Kontinuität der Reihen; wo der Vergleich nötig ist, ist eine Überlappungsphase einzuplanen.
- Schulung: Das Personal bedient ein neues System nach aktualisierten Verfahren; die Schulung ist vor dem Go-live abzuschließen, nicht danach.
- Change Control: Der gesamte Eingriff ist eine Änderung, mit vorab definierter Auswirkungsbewertung und Qualifizierungsumfang.
Praxisszenario
An einem Standort, den wir Site Delta nennen — realistisch, aber fiktiv — stellt ein internes Audit fest, dass der Audit Trail des Monitoringsystems ohne Mitwirkung des Lieferanten nicht prüfbar ist. Die unmittelbare Reaktion des Projektteams: Ersatz des gesamten Systems einleiten.
Das Gap Assessment zeichnet ein anderes Bild. Fünf Lücken werden festgestellt: der nicht eigenständig prüfbare Audit Trail ist eine konstruktive Grenze der Software (Technologie); geteilte Konten in zwei Bereichen sind ein Konfigurationsproblem; das Fehlen eines Datenprüfplans ist ein Führungsproblem; zwei Messstellen entsprechen nach einer Layoutänderung nicht mehr dem aktualisierten Risk Assessment (Strategie); die As-built-Dokumentation ist für einen Anlagenzweig unvollständig (Dokumentation).
Nur die erste erfordert einen Eingriff an der Plattform. Die übrigen vier werden über Umkonfiguration, Verfahren, Überarbeitung der Messstellenkarte und dokumentarische Rekonstruktion gelöst — in weit kürzerer Zeit und zu weit geringeren Kosten. Die Entscheidung von Site Delta lautet auf einen Teil-Retrofit: Upgrade der Softwarekomponente bei Beibehaltung der Feldinfrastruktur, begleitet von einem Maßnahmenplan für die nicht-technologischen Lücken.
Die Pointe des Szenarios ist nicht, dass ein Ersatz stets unverhältnismäßig wäre — mitunter ist er der einzig gangbare Weg. Sie ist, dass die Entscheidung, um belastbar zu sein, auf einer ausdrücklichen Klassifizierung der Lücken beruhen muss — und dass diese Klassifizierung wenige Wochen kostet gegenüber einem Projekt, das viele beansprucht.
Häufige Fehler und Warnsignale
- Den Umfang vor dem Gap Assessment festlegen. Führt dazu, die Lösung für ein Problem zu kaufen, das nicht das eigentliche war.
- Das System mit der ursprünglichen URS statt mit den heutigen Anforderungen vergleichen. Der Kontext hat sich geändert: Maßstab ist das Heute.
- Den dokumentierten statt den tatsächlichen Zustand erheben. Der Unterschied zwischen beiden ist oft die bedeutsamste Lücke.
- Führungslücken mit einem Kauf beantworten. Das neue System erbt dieselbe Führung und damit dieselben Befunde.
- Die Strategie für historische Daten nicht zu Beginn festlegen. Eine Entscheidung erst bei der Außerbetriebnahme verengt die Optionen drastisch.
- Die Koexistenz der Systeme unterschätzen. Ohne datierte Festlegung der maßgeblichen Quelle werden spätere Untersuchungen mehrdeutig.
- Die Auswirkung der Arbeiten auf den klassifizierten Bereich vernachlässigen. Ungeplante Öffnungen und Durchführungen erzeugen Nacharbeit und unvorhergesehene Requalifizierungen.
- Die Schulung auf die Zeit nach dem Go-live verschieben. Der direkteste Weg zu Bedienfehlern in den ersten Wochen.
- Akzeptierte Lücken nicht formal schließen. Eine bewusst nicht behobene Lücke wird mit Begründung und Genehmigung dokumentiert, nicht einfach aus dem Umfang gelassen.
Wie zu dokumentieren ist
- Gap-Assessment-Bericht: aktuelle Anforderungen, vorgefundener Zustand, Lückenliste mit Natur, Kritikalität und Priorität.
- Entscheidungsdokument: bewertete Optionen (Nachbesserung, Retrofit, Ersatz), Kriterien, Begründung der Wahl und der Ausschlüsse.
- Change Control für den Eingriff, mit Auswirkungsbewertung und definiertem Qualifizierungsumfang.
- Plan zur Monitoringkontinuität während der Arbeiten, mit Provisorien und deren Qualifizierung.
- Plan für historische Daten: Strategie, Prüfungen auf Vollständigkeit und Richtigkeit, Lesbarkeit über die Zeit.
- Datierte Festlegung der maßgeblichen Quelle je Messstelle während der Koexistenz.
- Maßnahmenplan für nicht-technologische Lücken, mit Verantwortlichkeiten und Terminen.
- Erfassung akzeptierter Lücken mit Begründung und Genehmigung.
Kernaussagen
- Das Gap Assessment geht der Umfangsdefinition voraus, nicht umgekehrt.
- Verglichen wird mit den heutigen Anforderungen, nicht mit den ursprünglichen.
- Nur Technologielücken lassen sich durch Beschaffung schließen; die übrigen brauchen Konfiguration, Verfahren oder Strategie.
- Die Strategie für historische Daten wird zu Projektbeginn entschieden.
- Während der Koexistenz braucht es eine datierte Festlegung, welches System maßgeblich ist.
- Bewusst nicht behobene Lücken werden dokumentiert und genehmigt, nicht ignoriert.
Häufige Fragen
Womit beginnt ein Retrofit-Projekt?
Mit der Rekonstruktion der aktuellen Anforderungen und der Erhebung des tatsächlichen Systemzustands — nicht mit der Angebotsanfrage. Der Umfang wird nach der Klassifizierung der Lücken definiert.
Wann ist Ersatz besser als Upgrade?
Wenn die dominierenden Lücken technologischer Natur an der zentralen Plattform sind, wenn der Support beendet oder sein Ende angekündigt ist, wenn Data-Integrity-Anforderungen wegen konstruktiver Grenzen nicht erfüllbar sind, oder wenn die Dokumentation nicht rekonstruierbar ist. Die Bewertung erfolgt über den gesamten Lebenszyklus.
Was geschieht mit den Daten des alten Systems?
Sie bleiben den anwendbaren Aufbewahrungspflichten unterworfen. Die Optionen — Migration, Archivierung in unabhängigem Format, Weiterbetrieb im Lesemodus — sind mit einem dokumentierten Plan zu bewerten, der Prüfungen auf Vollständigkeit und Richtigkeit sowie die Lesbarkeit über die gesamte Frist einschließt.
Braucht es nach einem Retrofit eine vollständige Requalifizierung?
Nicht zwingend. Der Umfang ergibt sich risikobasiert aus der Auswirkungsbewertung im Change Control: Manche Änderungen erfordern nur die Prüfung der betroffenen Funktionen, andere eine breitere Requalifizierung. Die Kriterien werden im Beitrag zu FAT, SAT, IQ, OQ und PQ des Systems behandelt.
Wie wird das Monitoring während der Arbeiten sichergestellt?
Durch einen phasenweisen Kontinuitätsplan, der je Phase festlegt, wie das geforderte Monitoring sichergestellt wird. Etwaige Provisorien werden für den vorgesehenen Zweck qualifiziert und als solche dokumentiert.
Erfordert ein Retrofit ein neues Risk Assessment?
Es ist zumindest erneut zu prüfen: Haben sich Layout, Prozess oder Bereiche seit der ursprünglichen Fassung geändert, ist die Messstellenkarte auf die aktualisierte Bewertung zurückzuführen. Die Methode ist im Beitrag zur risikobasierten Probenahmestrategie beschrieben.
Regulatorische und technische Referenzen
- EudraLex Volume 4 — EU Guidelines for Good Manufacturing Practice (Europäische Kommission): Annex 1 (anwendbar seit 25. August 2024), Annex 11 (Revision Januar 2011), Annex 15 (in Kraft seit 1. Oktober 2015).
- ICH Quality Guidelines — ICH Q9(R1) Quality Risk Management.
- ISO 14644-1 — Cleanrooms and associated controlled environments: Klassifizierung der Luftreinheit nach Partikelkonzentration.
- PIC/S — Guides and Guidance Documents.
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 Probenahmestrategie und die URS des Systems.
- Verwandt: Betriebsführung, Lieferantenauswahl und Budget und TCO.
- Regulatorische Grundlagen von GuideGxP: Data Integrity, ALCOA+ und Audit Readiness.
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.
