liberoMANAGER validieren: vollständige Sendungsdaten nachvollziehbar bewerten

1. Von der Transportinformation zur konkreten Entscheidung

ELPRO beschreibt liberoMANAGER als webbasierte SaaS-Lösung für Kühlketten- und Sendungsdaten. Die Plattform kann PDF-basierte und Echtzeitwege zusammenführen. Für Ihren Nachweis zählt jedoch nicht nur die zentrale Ablage: Welche Sendung, welche Produkte und welcher Transportabschnitt werden beurteilt, und welche anschließende Entscheidung stützt sich darauf?

Im Vertrieb von Humanarzneimitteln sind die GDP-Leitlinien der konkrete Ausgangspunkt. Kapitel 9 behandelt Transportbedingungen und den Umgang mit Abweichungen; Abschnitt 3.3.1 beschreibt Nachweise für computergestützte Systeme vor ihrer Nutzung. Eine GMP-bezogene Verwendung in der Humanarzneimittelherstellung wird gesondert anhand von Annex 11 eingeordnet. GDP und GMP sind unterschiedliche Geltungsbereiche, auch wenn derselbe Datenbestand mehrere Prozesse unterstützt.

Beschreiben Sie deshalb zuerst den fachlichen Zweck. Eine temperaturbezogene Beurteilung ist nicht automatisch eine vollständige Produktfreigabe. Ebenso wenig beweist eine unauffällige Kurve, dass alle vorgesehenen Transportinformationen erfasst wurden. Die zuständigen Personen benötigen eine nachvollziehbare Grundlage für genau die Entscheidung, die Ihr Verfahren vorsieht.

Quellen: [1] [10] [8] [7]

2. Handbuch, API und tatsächliche Loggerwege unterscheiden

Die Herstellerankündigung vom Juli 2025 beschreibt Version 3.0 mit Gx-Echtzeitintegration neben Cx-USB-/Bluetooth-Loggern. Das öffentliche Benutzerhandbuch bezeichnet sich ebenfalls als Version 3.0. Die Pub/Sub-Dokumentation nennt dagegen API 1.2.0 für Zielrelease 3.1.0. Das sind unterschiedliche Versionsaussagen; keine davon bestätigt allein Ihren aktiven Kundenbuild.

Im beschriebenen PDF-Weg liest der Empfänger den Logger aus und übermittelt den Originalbericht. Für Gx beschreibt das Handbuch einen laufenden Datenstrom statt eines erforderlichen manuellen Uploads am Ziel. Daraus sollten keine identischen Zeitpunkte der Datenverfügbarkeit abgeleitet werden. Erfassen Sie die tatsächlich verwendeten Geräte, Übertragungswege und Einstellungen.

Legen Sie ein kompaktes Konfigurationsblatt an: Instanz, Release, Gerätevarianten, Workflow, verwendete Auswertungsparameter, Rollen und angebundene Systeme. Ordnen Sie Herstellerunterlagen jeweils dem passenden Baustein zu. Eine allgemeine Beschreibung der aktuellen Produktfamilie ersetzt keine Prüfung, ob Ihre konkrete Kombination unterstützt und angemessen nachgewiesen ist.

Quellen: [2] [3] [4] [8] [10]

3. Die fünf Fragen an eine verwendbare Sendungsbewertung

Die Produktseite beschreibt eine Prüfung eingehender ELPRO-PDFs auf unveränderten Originalzustand sowie eine Prüfung der Konto-Zuordnung. Das ist ein wichtiger Teil der Datenannahme. Es beantwortet aber nicht automatisch alle fachlichen Fragen Ihrer Sendung. Ein korrektes Dateiformat und ein erfolgreicher Eingang sind andere Nachweise als die Zuordnung zum richtigen Produkt und Zeitraum.

Die folgende eigene Arbeitsmatrix trennt diese Fragen. Ergänzen Sie im Projekt konkrete Datenfelder, Verantwortliche und Prüfkriterien. So wird erkennbar, welche Lieferantenfunktion eine Anforderung unterstützt und wo zusätzliche fachliche oder technische Kontrollen erforderlich sind.

Quellen: [1] [3] [10] [8]

4. Vollständigkeit vor der Auswertung fachlich definieren

Bestimmen Sie, welche Logger und Zeiträume für die geplante Entscheidung benötigt werden. Diese Festlegung kann von Sendungsaufbau, Messkonzept und Transportweg abhängen. Die Zahl eingegangener Dateien ist dafür kein ausreichender Ersatz. Ein doppelt eingereichter Bericht ergänzt keine andere fehlende Quelle.

Unterscheiden Sie außerdem einen vollständig eingegangenen Datensatz von einem fachlich vollständig abgedeckten Transport. Ein Logger kann einen lückenlosen Bericht erzeugen, der erst nach Beginn des relevanten Abschnitts startet. Bei Echtzeitdaten ist zusätzlich zu klären, ob noch Informationen ausstehen. Wie die Anwendung solche Zustände anzeigt oder behandelt, muss zur konkreten Version und Konfiguration belegt werden.

Planen Sie gezielte Gegenfälle: fehlender Logger, falsche Sendungsnummer, verspäteter Eingang oder ein unpassender Startzeitpunkt. Schreiben Sie vor dem Test auf, welche Information für die Entscheidung fehlt und wie damit umzugehen ist. Daraus folgt keine universelle technische Sperre jeder unvollständigen Sendung, sondern eine überprüfbare Anforderung an Ihren vorgesehenen Prozess.

Quellen: [3] [1] [10] [8]

5. Illustrativer Sollfall: drei Logger, aber noch keine vollständige Grundlage

Für dieses ausdrücklich illustrative Beispiel sind drei unterschiedliche Logger L1, L2 und L3 für dieselbe Modellsendung vorgesehen. Jeder soll den Abschnitt von 08:00 bis 14:00 Uhr abdecken. Alle Zeiten haben dieselbe Zeitbasis. Das ergibt sechs Stunden je Logger und zusammen 18 Loggerstunden. Diese Hilfsgröße prüft nur die zeitliche Abdeckung, weder Temperaturqualität noch eine softwareseitige Vollständigkeitsformel.

Die Tabelle enthält unabhängige Teilfälle. Vor jedem Fehlerfall wird der genannte Ausgangszustand wiederhergestellt. Angenommen werden durchgehende Zeitintervalle ohne innere Lücken; die Anzahl diskreter Messpunkte wird nicht berechnet. Alle Loggerbezeichnungen und Reaktionen sind eigene Testannahmen, keine ausgeführten liberoMANAGER-Ergebnisse.

Quellen: [1] [3] [10] [8]

6. Bewertungsgrundlage und Entscheidungsbefugnis nachvollziehbar halten

liberoMANAGER wird mit konfigurierbaren Workflows und temperaturbezogener Bewertung angeboten. Für Ihr Projekt ist festzulegen, welche Produktparameter, Zeiträume und fachlichen Regeln verwendet werden dürfen. Die öffentliche Funktionsbeschreibung belegt keinen universell geeigneten Algorithmus und keine für jedes Arzneimittel passende Stabilitätsberechnung.

Prüfen Sie einen geeigneten Sollfall mit unabhängig festgelegter Erwartung. Verändern Sie anschließend gezielt eine relevante Voraussetzung, etwa Produktzuordnung oder ausgewählten Zeitraum. Die Bewertung sollte im erforderlichen Umfang erkennen lassen, welche Grundlage verwendet wurde. Ein später aktualisierter Parametersatz darf nicht unbemerkt die Erklärung einer früheren Entscheidung ersetzen.

Regeln Sie außerdem, wer Daten einsehen, bewerten und über die weitere Verwendung entscheiden darf. Die Support-FAQ beschreibt organisationsbezogene Zugangsrechte; die konkrete Rollen- und Workflowkonfiguration bleibt zu bestimmen. Daraus entsteht weder eine universelle QA-Unterschrift für jeden Bericht noch die Erlaubnis, jede positive Softwarebewertung ohne den vorgesehenen fachlichen Kontext zu verwenden.

Quellen: [1] [5] [8] [10] [9]

7. Originaldaten, Bewertungsbericht und Aufbewahrung unterscheiden

Das Handbuch führt unterschiedliche Dateitypen auf, darunter Original-Logger-PDF, Bewertungs- und Sendungsberichte sowie Exporte. Diese Bezeichnungen zeigen bereits, dass nicht jede Datei dieselbe Funktion erfüllt. Bestimmen Sie, welche Aufzeichnungen die Herkunft der Daten, die gewählte Bewertung und die spätere Entscheidung gemeinsam verständlich machen.

Ein Export sollte auf den vorgesehenen Zweck geprüft werden. Sind Loggeridentität, Zeitraum, relevante Parameter und Bewertungsstand enthalten oder verlässlich verbunden? Können berechtigte Personen den benötigten Zusammenhang später lesen? Ein PDF ist damit weder generell ungeeignet noch allein aufgrund seines Formats vollständig. Die erforderliche Dokumentation richtet sich nach dem konkreten Prozess.

Für GDP sind Datenkontrolle, Verfügbarkeit, Sicherung und Störungsverfahren in Abschnitt 3.3.1 ausdrücklich behandelt. Im GMP-Scope ergänzen Annex 11 und Kapitel 4 die entsprechenden Anforderungen. Legen Sie die anwendbare Aufbewahrung fest und prüfen Sie Wiederherstellbarkeit sowie Datenbeziehungen. Öffentliche Hosting- oder Backupangaben ersetzen keine Klärung des vereinbarten Umfangs.

Quellen: [3] [1] [10] [8] [9]

8. API-Ausgabe und Datenbestand sind unterschiedliche Nachweise

Die Pub/Sub-Dokumentation für API 1.2.0 und Zielrelease 3.1.0 beschreibt Nachrichtenrouting nach Organisation, Partition und Nachrichtentyp. Der empfangene Ausschnitt hängt damit von der tatsächlichen Konfiguration ab. Prüfen Sie vor einer Integration, welche Informationen ein angeschlossenes System für seine Aufgabe benötigt und ob der eingerichtete Weg sie tatsächlich bereitstellt.

Für die beschriebenen Nachrichten nennt die Dokumentation eine Lebensdauer von drei Tagen. Das ist keine regulatorische Aufbewahrungsfrist und keine Aussage, dass nach drei Tagen die Messdaten der Plattform gelöscht werden. Nach einer längeren Empfangsunterbrechung muss geklärt sein, wie das Zielsystem seine Vollständigkeit prüft und fehlende Informationen gegebenenfalls auf geeignetem Weg wiederbeschafft.

Bewerten Sie Änderungen an Filtern, Workflow, Datenmodell und Release gemeinsam mit dem betroffenen Prozess. Ein erfolgreicher technischer Verbindungsaufbau beweist noch keine vollständige fachliche Übernahme. Ebenso wenig muss jede Anpassung sämtliche bisherigen Tests entwerten. Ordnen Sie vorhandene Belege zu und ergänzen Sie gezielt die geänderten Übergänge.

Quellen: [4] [8] [10]

9. Welche Mitwirkung ein überschaubares Projekt braucht

Bereiten Sie eine reale Beispielsendung als Prozessbeschreibung vor: Produkte, Transportabschnitte, erforderliche Logger, Datenwege und vorgesehene Entscheidungen. Ergänzen Sie Instanz- und Versionsinformationen sowie bestehende Arbeitsanweisungen. QA und Logistik sollten erklären können, welche Daten sie tatsächlich benötigen; IT und Lieferant ergänzen Konfiguration und Schnittstellen.

Aufwand entsteht besonders durch gemischte PDF- und Echtzeitwege, mehrere Empfängerorganisationen, individuelle Bewertungsregeln und externe Integrationen. Fehlende Zuordnungen oder uneinheitliche Arbeitsweisen können mehr Klärung verlangen als eine größere Zahl gleichartiger Sendungen. Eine belastbare Planung sollte deshalb die unterschiedlichen Abläufe und Ausnahmen betrachten, nicht allein das Transportvolumen.

Nutzen Sie Lieferantenbelege, soweit ihr Stand und Umfang zu Ihren Anforderungen passen. Ergänzende Prüfungen können sich auf Ihre Produktparameter, Rollen, Datenannahme und Entscheidungswege konzentrieren. Welche Arbeiten intern oder durch Partner ausgeführt werden, ist vertraglich und organisatorisch zu regeln. Pauschale Zeit-, Preis- oder Ergebniszusagen lassen sich aus dem Produktnamen nicht ableiten.

Quellen: [1] [8] [10]

10. Checkliste vor der Verwendung einer Sendungsbewertung

Die folgende eigene Arbeitshilfe bündelt die wichtigsten Nachweise. Prüfen Sie die Punkte für den tatsächlich vorgesehenen Prozess und dokumentieren Sie offene Fragen mit ihrer Auswirkung. Ein vollständig ausgefüllter Bildschirm ersetzt keinen geklärten fachlichen Entscheidungsweg.

• Instanz, Release, Loggerarten, Übertragungswege und externe Empfänger sind erfasst.
• GMP-, GDP- oder anderer konkreter Geltungsbereich ist bestimmt.
• Erforderliche Logger, Sendungszuordnung und Zeiträume stehen vor der Bewertung fest.
• Originalität, Doppelimport, fehlende Quelle und falsche Zuordnung sind passend geprüft.
• Produktparameter, Auswertungsgrundlage und vorgesehene Entscheidung sind nachvollziehbar.
• Zugriffs- und Entscheidungsbefugnisse entsprechen dem tatsächlichen Workflow.
• Benötigte Originaldaten, Berichte und Beziehungen bleiben über die maßgebliche Frist verfügbar.
• API-Filter, Empfangsausfälle, Wiederanlauf und Änderungen werden kontrolliert bewertet.

Quellen: [10] [8] [9]