elproMONITOR validieren: vom Messwert zur rechtzeitigen Reaktion

1. Den überwachten Prozess und seinen Regelwerksbezug bestimmen

elproMONITOR ist ELPROs Software für Raum- und Geräteüberwachung. Beschrieben werden angeschlossene Messmodule, zentrale Anzeige, Alarmwege und Benutzerverwaltung. Die konkrete Systemgrenze reicht deshalb über den Server hinaus: Sie umfasst die verwendeten Sensoren, Kommunikationsmodule, Netzwerke, Benachrichtigungsdienste und den geregelten Umgang mit Meldungen. Eine Lagerfläche und ein Produktionsgerät können dieselbe Software mit unterschiedlichen Anforderungen nutzen.

Für Humanarzneimittelherstellung unter EU-GMP ist Annex 11 die einschlägige Leitlinie für computergestützte Systeme. Im Humanarzneimittelgroßhandel sind die GDP-Leitlinien eigenständig zu berücksichtigen. Deren Abschnitt 3.3.1 beschreibt geeignete Validierungs- oder Verifikationsnachweise vor der Nutzung. GDP ist damit kein bloßes Synonym für EU-GMP, auch wenn sich konkrete Nachweise sinnvoll verbinden lassen.

Formulieren Sie den Zweck aus Sicht des Betriebs: Welche Abweichung muss erkannt werden, wer benötigt die Information und welche Handlung soll rechtzeitig möglich bleiben? Erst daraus ergeben sich geeignete Grenzen, Reaktionszeiten und Fehlerfälle. Der Produktname oder eine allgemeine Complianceaussage beantwortet diese Fragen nicht.

Quellen: [1] [7] [9] [6]

2. 3.3.x, Cloud und tatsächliche Konfiguration auseinanderhalten

Die offizielle Dokumentation enthält eigene Bereiche für elproMONITOR 3.3.x und Cloud sowie ältere Versionszweige. Ein Handbuchtitel ist jedoch keine Bestätigung Ihres aktiven Builds. Erfassen Sie Anwendung, Module, Firmware, Identitätsverwaltung und Betriebsform. Halten Sie auch fest, welcher konkrete Dokumentstand für eine Anforderung oder einen Test verwendet wurde.

ELPRO beschreibt für Cloud und On-Premises vergleichbare Kernfunktionen, zugleich aber angepasste Funktionen, Oberflächen und Abläufe. Eine Bedienregel aus dem 3.3.x-Handbuch darf daher nicht ungeprüft als identische Cloud-Funktion vorausgesetzt werden. Bestehende Hardware soll beim Wechsel auf ihre Kompatibilität geprüft werden. Ein funktionierender Sensoranschluss allein belegt noch nicht sämtliche Alarm- und Datenwege.

Ordnen Sie vorhandene Lieferantenbelege den tatsächlich genutzten Funktionen zu. Passende Installations- und Funktionstests können einen wichtigen Teil abdecken. Ergänzende Nachweise betreffen beispielsweise Ihre Alarmprofile, Empfänger, Rechte, Standortverbindungen und Ausfallmaßnahmen. Die Nutzung vorhandener Unterlagen setzt eine nachvollziehbare Passungsprüfung voraus, keinen pauschalen Neuaufbau aller Dokumente.

Quellen: [2] [5] [1] [7]

3. Gespeicherte Werte und wirksame Alarmierung getrennt bewerten

Der Cloud-Handbuchabschnitt zum Deaktivieren beschreibt einen besonders wichtigen Unterschied: Messdaten werden weiter aufgezeichnet, während Grenzwertalarme unterdrückt und die Daten nicht in der Statistik berücksichtigt werden. Für Wartungsarbeiten kann ein solcher Zustand vorgesehen sein. Er braucht jedoch einen klaren Zweck, passende Befugnisse und einen nachvollziehbaren Abschluss.

Die folgende eigene Arbeitsmatrix hilft, scheinbar widersprüchliche Anzeigen fachlich zu lesen. Prüfen Sie die tatsächliche Konfiguration, statt aus einer vorhandenen Kurve oder einer leeren Alarmansicht bereits auf einen ungestörten Betrieb zu schließen.

Quellen: [4] [3] [5] [7]

4. Alarmprofile, Empfänger und Zeitbezug konkret prüfen

Beginnen Sie mit den tatsächlichen Alarmprofilen. Für jeden relevanten Zustand sollten fachliche Grenze, gegebenenfalls Verzögerung, Empfänger und erwartete Reaktion verständlich sein. Ein Temperaturereignis ist ein anderer Fall als eine fehlende Verbindung oder ein Batteriehinweis. Das 3.3.x-Handbuch unterscheidet entsprechende Meldearten. Ihre Priorität und Behandlung ergeben sich aus der vorgesehenen Verwendung.

Prüfen Sie einen vollständigen Weg bis zum erreichbaren Empfänger. Eine erzeugte E-Mail ist noch kein Nachweis dafür, dass der Bereitschaftsdienst sie erhält und zuordnen kann. Berücksichtigen Sie reale Verteiler, Schichtwechsel, ausgeschiedene Nutzer und ausgefallene Übertragungsdienste. Welche dieser Fälle getestet werden, begründen Sie anhand ihrer möglichen Auswirkung.

Verwenden Sie bei Zeitvergleichen eine gemeinsame Zeitbasis. Das 3.3.x-Handbuch beschreibt Anzeigen entsprechend der gewählten Benutzerzeitzone. Für Ihren Nachweis sollten Ereignis, Benachrichtigung und Reaktion deshalb eindeutig vergleichbar sein. Dokumentieren Sie Abweichungen zwischen vorgesehenem und beobachtetem Ablauf, statt lediglich eine erfolgreiche Meldungsanzeige abzuhaken.

Quellen: [3] [1] [7] [9]

5. Illustrativer Sollfall: Messwerte vorhanden, Meldung zu spät

Der folgende Modellfall ist ausdrücklich illustrativ und kein ausgeführter elproMONITOR-Test. Alle Zeiten verwenden dieselbe Zeitzone. Eine Überschreitung beginnt um 12:00 Uhr und endet um 12:07 Uhr. Für diesen frei gewählten Testprozess soll der zuständige Empfänger spätestens fünf Minuten nach Beginn informiert sein. Diese Frist ist keine Arzneimittelspezifikation und keine allgemeine regulatorische Vorgabe.

Zusätzlich wird eine unterbrochene Fernverbindung von 12:01 bis 12:10 Uhr angenommen. Die Modellrechnung setzt eine Fernnachricht um 12:11 Uhr und eine erste Reaktion um 12:13 Uhr an. Sie beschreibt bewusst einen zu bewertenden Fehlerfall, keine zugesagte Produktlatenz. Ein lokaler Ersatzweg wäre getrennt nachzuweisen.

Quellen: [5] [7] [9]

6. Quittierung und fachliche Bearbeitung nicht verwechseln

Im 3.3.x-Handbuch beeinflusst die Einstellung MustConfirmAlarms, wie unquittierte Meldungen in der entsprechenden Ansicht behandelt werden. Die dokumentierte Quittierung enthält Zeit und Benutzer. Außerdem werden Varianten mit und ohne elektronische Signatur beschrieben. Bei der Signaturvariante ist die erforderliche Zahl der quittierenden Benutzer konfigurierbar.

Leiten Sie daraus keine allgemeine Zweipersonenpflicht ab. Legen Sie fest, welche Bedeutung eine Quittierung in Ihrem Prozess hat: Empfang bestätigt, Ursache untersucht oder Maßnahme abgeschlossen sind verschiedene Aussagen. Eine technische Bestätigung sollte nicht unbemerkt als umfassende fachliche Entwarnung verwendet werden. Auch ein wieder normaler Messwert entscheidet nicht allein über die betroffenen Produkte.

Prüfen Sie die relevanten Ansichten und Filter mit unterschiedlichen Zuständen. Eine Meldung kann aus einer Arbeitsansicht verschwinden, ohne gelöscht zu sein. Für spätere Bewertungen muss der notwendige Zusammenhang aus Ereignis, Benutzeraktion, Kommentar und Maßnahme auffindbar bleiben. Welche Signaturanforderungen tatsächlich gelten, ist am konkreten Verfahren zu bestimmen.

Quellen: [3] [7] [9]

7. Kalibrierung, Auswertung und Aufzeichnungen zusammenhalten

Ein Kalibriernachweis beantwortet Fragen zur messtechnischen Eignung des betreffenden Geräts. Er beweist nicht, dass ein Alarmprofil richtig zugeordnet ist oder der zuständige Empfänger erreicht wird. Der Cloud-Handbuchabschnitt beschreibt einen eigenen Kalibrierzustand sowie das Deaktivieren und Aktivieren der Überwachung. Prüfen Sie, wie diese Vorgänge in Ihrem vorgesehenen Betrieb kontrolliert werden.

Für stationäre GDP-Überwachung nennt Abschnitt 3.3 definierte Kalibrierintervalle auf Basis von Risiko und Zuverlässigkeit. Daraus sollte keine universelle Jahresfrist für sämtliche Messstellen abgeleitet werden. Geräteart, Einsatz und passende Anforderungen sind konkret zu berücksichtigen. Die angemessene Systemprüfung und die messtechnischen Nachweise können zusammenwirken, bleiben aber unterschiedliche Aufgaben.

Bestimmen Sie außerdem, welche Aufzeichnungen die spätere Bewertung tragen: Messdaten, relevante Profile, deaktivierte Zeiträume, Meldungen und Bearbeitungsinformationen. Im GMP-Scope helfen Annex 11 und Kapitel 4 bei der Abgrenzung von Änderungsnachweisen und Dokumentation. Ein einzelner PDF-Bericht beweist nicht automatisch, dass alle benötigten Beziehungen erhalten bleiben.

Quellen: [4] [9] [7] [8]

8. Cloud-Betrieb und Änderungen an ihrer Wirkung bewerten

Die Cloud-FAQ beschreibt lokale Behandlung und spätere Synchronisation bei Verbindungsunterbrechung ausdrücklich abhängig von der Konfiguration. Klären Sie daher die tatsächliche Hardware, Pufferung, lokalen Alarmwege und Rückkehr in den Normalbetrieb. Allgemeine Aussagen zur Cloud-Verfügbarkeit beantworten nicht, ob Ihre konkrete Meldung während eines Netzwerkausfalls rechtzeitig zugestellt wird.

Trennen Sie Sicherung, Wiederherstellung und fachliche Aufbewahrung. Benötigte Daten sollen über den maßgeblichen Zeitraum verwendbar bleiben; beim Wiederherstellen zählt auch ihr Zusammenhang mit Konfiguration und Bearbeitung. Vereinbaren Sie Zuständigkeiten und geeignete Nachweise mit den beteiligten Dienstleistern. Öffentliche Hostingwerbung ersetzt keine konkrete Leistungs- und Wiederherstellungsvereinbarung.

Bewerten Sie Änderungen nach ihren Auswirkungen: neues Alarmprofil, andere Empfänger, geänderte Identitätsverwaltung, Hardwaretausch oder Cloud-Migration können unterschiedliche Tests erfordern. Geeignete vorhandene Belege dürfen weitergenutzt werden. Eine vollständige Neuvalidierung bei jedem Update ist ebenso wenig pauschal begründet wie die Annahme, eine Lieferantenaktualisierung decke automatisch Ihren gesamten Prozess ab.

Quellen: [5] [1] [7] [9]

9. Welche Vorbereitung den Aufwand für KMU bestimmt

Für eine belastbare Vorbereitung benötigen Sie eine Messstellen- und Komponentenliste, Alarmprofile, Empfängerwege und vorhandene Nachweise. Benennen Sie fachliche Verantwortliche für Grenzen und Maßnahmen sowie Ansprechpartner für IT und Bereitschaftsdienst. Ein überschaubarer Modellfall sollte den wichtigsten betrieblichen Entscheidungsweg zeigen und nicht nur die schönste Softwareansicht.

Aufwand entsteht insbesondere durch unterschiedliche Standorte, mehrere Alarmdienste, alte Hardware, individuelle Rechte und ungeklärte Ausfallmaßnahmen. Viele ähnliche Sensoren können einfacher zu bewerten sein als wenige Messstellen mit völlig verschiedenen Reaktionswegen. Ein Projektumfang allein nach Sensorzahl greift deshalb häufig zu kurz; konkrete Zeit- oder Kostenzusagen brauchen eine genauere Bestandsaufnahme.

Fragen Sie den Lieferanten gezielt nach passenden Versionsunterlagen und ausgeführten Tests. Legen Sie anschließend fest, welche kundenspezifischen Übergänge ergänzend geprüft werden. Fachbereich und QA erläutern die Verwendung und ihre Risiken, IT die technischen Abhängigkeiten. Aufgaben und Entscheidungsbefugnisse werden passend zur Organisation geregelt, nicht aus einer starren allgemeinen Rollenliste übernommen.

Quellen: [1] [7] [9]

10. Checkliste für den nachweisbaren Überwachungsbetrieb

Verwenden Sie die folgende eigene Arbeitshilfe für Ihre Nutzungsentscheidung und spätere Änderungen. Ein Punkt gilt erst als geklärt, wenn die relevante Information oder ein bewerteter Nachweis vorliegt. Offene Befunde benötigen einen Verantwortlichen und eine Entscheidung über ihre Auswirkung auf den vorgesehenen Betrieb.

• Betriebsform, Softwarestand, Module und Kommunikationswege sind eindeutig erfasst.
• GMP-, GDP- oder anderer konkreter Einsatz und betroffene Entscheidungen sind abgegrenzt.
• Alarmprofile, Zeitbezug, Empfänger und erforderliche Reaktion sind fachlich festgelegt.
• Deaktivierung, Kalibrierung und Wiederaktivierung sind kontrolliert und nachvollziehbar.
• Verbindungsunterbrechung und Ausfall eines Benachrichtigungswegs sind angemessen geprüft.
• Ereignisende, Quittierung und fachliche Bearbeitung besitzen eindeutige Bedeutung.
• Benötigte Daten, Änderungen und Berichte bleiben für den vorgesehenen Zweck nutzbar.
• Lieferantenbelege, Wiederherstellung und Änderungsbewertung passen zur realen Konfiguration.

Quellen: [7] [9] [8]