eLabJournal validieren: vom Protokoll zum nachvollziehbaren Experiment

Forschung und GMP-Einsatz anhand der Entscheidung trennen

Beginnen Sie mit einem konkreten Versuch und seinem Ergebnisempfänger. Dient die Aufzeichnung der explorativen Forschung, einer Methodenentwicklung oder einer qualitätsrelevanten Entscheidung im geregelten Betrieb? Auch innerhalb eines Labors können diese Zwecke nebeneinander bestehen. Beschreiben Sie, welche Daten später weiterverwendet werden und an welcher Stelle eine fachliche Bewertung erfolgt.

Dieser Artikel verwendet Humanarzneimittel-GMP als abgegrenzten regulatorischen Anwendungsfall. Der aktuelle EudraLex-Index führt hierfür Annex 11 und Kapitel 4 in der Fassung von Januar 2011. Annex 11 ist eine GMP-Leitlinie für computergestützte Systeme. GLP, klinische Forschung und Medizinprodukte benötigen eine eigene Einordnung; Herstellerhinweise auf diese Bereiche ersetzen sie nicht.

Eine sinnvolle erste Anforderung lautet beispielsweise: Der Prüfer kann feststellen, welche Probe nach welcher Vorgabe untersucht wurde und welche Originaldaten das berichtete Ergebnis stützen. Daraus entwickeln Sie Ihre Prüfung. Ob das Laborbuch dabei führendes Aufzeichnungssystem, ergänzende Dokumentation oder Empfänger von Ergebnissen ist, verändert Umfang und Prioritäten deutlich.

Quellen: [1] [2] [3]

Produktlinie, Releasekanal und verwendete Bausteine festhalten

Die frühere eLabNext-Webadresse führt heute zu SciSure. Die Fachhilfe verwendet weiterhin eLabNext und beschreibt die eLabJournal-bezogenen ELN-Funktionen. Behalten Sie die Bezeichnung Ihres tatsächlich eingesetzten Produkts im Systeminventar bei. Der gemeinsame Anbieterrahmen macht eLabJournal und Labfolder weder funktional identisch noch zu austauschbaren Validierungsgegenständen.

Die Release Notes dokumentieren V2.92.0 für EU- und US-Cloud am 30. September 2026. Die dort genannten Q4-Termine für Dedicated Installations liegen am Artikelstand noch in der Zukunft. Diese Angaben belegen deshalb keinen einheitlichen aktuellen Stand aller Installationen. Erfassen Sie Ihre tatsächliche Version einschließlich Add-ons und Betriebsform.

SciSure beschreibt Cloud, Private Cloud und On-Premises. Klären Sie für Ihren Vertrag, wer Updates, Sicherung, Wiederherstellung und Zugriffsverwaltung übernimmt. Die folgende eigene Matrix hilft, den benötigten Nachweis aufzuteilen. Sie ist keine behauptete Standardlizenz und keine vollständige Produktstückliste.

Quellen: [4] [5] [6]

Protokollvorlage und Durchführung sind verschiedene Objekte

Die Hilfe beschreibt neue Protokolle zunächst als Entwurf. Erst nach der Finalisierung können sie geteilt oder als Vorlage verwendet werden. Für Ihren Betrieb ist zusätzlich zu bestimmen, wann eine solche Vorlage fachlich verwendet werden darf. Die technische Aktion Finalize ist nicht automatisch mit Ihrer internen Genehmigung gleichzusetzen.

Beim Einfügen einer Procedure Section entsteht ein Bezug zur verwendeten Protokollversion. Änderungen in dieser Sektion betreffen das aktuelle Experiment und verändern laut Hersteller nicht die Originalvorlage. Gerade diese Trennung ist prüfrelevant: Eine Abweichung in einem einzelnen Versuch darf nicht als unveränderte Ausführung der Vorlage erscheinen.

Planen Sie einen Versuch mit Version 1, ändern Sie danach die Vorlage kontrolliert und starten Sie einen zweiten Versuch. Vergleichen Sie beide Bezüge. Prüfen Sie getrennt die Restart-Funktion, mit der dynamische Werte erneut gesetzt werden können. Legen Sie zuvor fest, wann ein Neustart fachlich zulässig ist und wie bereits dokumentierte Durchführung und Korrektur nachvollziehbar bleiben sollen.

Quellen: [7] [8] [3]

Used Samples, Generated Samples und Bestand auseinanderhalten

Eine Sample Section kann verwendete oder im Experiment erzeugte Proben verknüpfen. Der Hersteller unterscheidet Used Samples und Generated Samples; die Probe zeigt umgekehrt ihre zugeordneten Experimente. Damit lässt sich ein Zusammenhang dokumentieren. Ob die richtige Probe gewählt und die Richtung zutreffend angegeben wurde, bleibt Teil der fachlichen Prüfung.

Archivieren und Entfernen aus einer Sektion sind unterschiedliche Aktionen. Die Herstellerhilfe erklärt ausdrücklich, dass eine archivierte Probe weiterhin in der Sample Section erscheint. Prüfen Sie diese Unterscheidung mit einer bereits dokumentierten Durchführung: Ein späterer Bestandsstatus darf die historische Probenidentität nicht unverständlich machen.

Aus dem Verknüpfen einer Probe folgt keine belegte automatische Verbrauchsbuchung. Wenn Mengen relevant sind, benennen Sie das führende Mengenfeld oder das getrennte Bestandsverfahren. Prüfen Sie Einheiten, Teilentnahmen und wiederholte Eingaben. Dasselbe gilt für erzeugte Proben: Eine Relation allein beweist weder physische Herstellung noch analytische Eignung oder Freigabe.

Quellen: [9] [2]

Originaldaten, Experimentlog und Sektionshistorie verbinden

Ordnen Sie einer Ergebnisangabe die tatsächlich benötigten Ausgangsdaten zu. Das können eine Gerätemessdatei, eine Auswertung und ergänzende Beobachtungen sein. Benennen Sie ihren führenden Speicherort und den Weg ins Laborbuch. Ein eingefügtes Bild kann die Darstellung erleichtern, beweist aber nicht für jeden Zweck, dass alle auswertungsrelevanten Daten erhalten sind.

Die Herstellerhilfe trennt das Experimentlog für allgemeine Änderungen, etwa Beteiligte und Status, vom Log einzelner Sektionen. Für bestimmte Sektionstypen beschreibt sie außerdem eine Versionshistorie. Eine wiederhergestellte Version wird als neuer Stand mit entsprechendem Zeitstempel behandelt. Übertragen Sie diese Beschreibung nicht ungeprüft auf jeden Dateityp oder Zusatzbaustein.

Ein geeigneter eigener Prüffall korrigiert eine zunächst falsch zugeordnete Datei. Der Prüfende soll erkennen können, welcher Bezug ursprünglich bestand und wie die richtige Zuordnung hergestellt wurde. Prüfen Sie Inhalt und Bedeutung, nicht allein die Anzahl der Logzeilen. Die gewünschte Nachvollziehbarkeit reicht dabei bis zum System, in dem die ursprüngliche Messung und gegebenenfalls ihre Auswertung entstanden.

Quellen: [10] [11] [3]

Illustratives Sollbeispiel: zwei Entnahmen aus einer Probe

Dieses Beispiel ist vollständig konstruiert und kein ausgeführter Produkt- oder Kundentest. Probe A-17 enthält zu Beginn 120 µl. Experiment E-17 verwendet Protokoll P-4 Version 1 und dokumentiert nacheinander Entnahmen von 30 µl und 20 µl. Die zugehörigen Messdateien heißen E17-1 und E17-2. Beide müssen als unterschiedliche Messungen dem richtigen Experiment zugeordnet bleiben.

Das unabhängig berechnete Mengensoll beträgt 120 − 30 − 20 = 70 µl. Eine Eingabe von 0,02 ml entspricht 20 µl. Die nachstehende Prüfung setzt keine eingebaute automatische Abbuchung voraus: Sie kontrolliert den tatsächlich eingerichteten Mengenweg, ob innerhalb des Systems, über eine Schnittstelle oder durch einen geregelten manuellen Schritt.

Für jeden Fehlerfall wird derselbe dokumentierte Ausgangszustand wiederhergestellt oder ein eigener eindeutig gekennzeichneter Datensatz angelegt. Protokollvorlage, Rechte und Dateiinhalte bleiben dabei kontrolliert. Ein passender Abschluss erklärt nicht nur, ob 70 µl angezeigt werden, sondern auch, ob Probe, Durchführung, Messungen und Mengenänderungen inhaltlich zusammenpassen.

Quellen: [8] [9] [2]

Berechtigung und Signaturbedeutung am Prozess festlegen

Benennen Sie, wer Versuche anlegt, Daten ergänzt, Ergebnisse beurteilt und Konfigurationen ändert. In einem kleinen Labor können Personen mehrere Aufgaben übernehmen. Entscheidend ist, welche unabhängige Prüfung Ihr Verfahren benötigt und welche Interessenkonflikte oder unzulässigen Änderungen verhindert werden sollen. Eine bloße Rollenbezeichnung liefert diesen Nachweis noch nicht.

Das Signature-workflow-Add-on beschreibt projektbezogene Signatur- und Witness-Abläufe mit ausgewählten Personen oder Rollen. Prüfen Sie dessen tatsächliche Installation und Konfiguration. Legen Sie für jede verwendete Bestätigung fest, ob sie etwa die Durchführung, fachliche Prüfung oder eine weitere Entscheidung ausdrückt. Eine Schaltfläche ersetzt diese Bedeutung nicht.

Testen Sie einen zulässigen Bearbeiterwechsel, einen unzulässigen Bestätigungsversuch und einen entzogenen Zugriff. Untersuchen Sie zusätzlich den Umgang mit einer nachträglich erforderlichen Korrektur. Elektronische Signaturanforderungen ergeben sich aus dem konkreten Prozess und Regelbereich. Weder benötigt jede Forschungsnotiz pauschal eine elektronische Signatur, noch befreit die Bezeichnung Forschung einen tatsächlich regulierten Nachweis von seinen Anforderungen.

Quellen: [12] [2]

Exportfähigkeit mit dem benötigten Datenumfang prüfen

Definieren Sie vor dem Export, was später nachvollziehbar sein muss: Durchführung, Protokollbezug, verwendete und erzeugte Proben, relevante Dateien, Korrekturen und Bewertungen. Ein lesbarer Abschlussbericht kann dafür ein Bestandteil sein. Ob zusätzlich strukturierte Daten oder ursprüngliche Dateien benötigt werden, hängt von ihrer Bedeutung und den vorgesehenen späteren Prüfungen ab.

Die Release Notes zu V2.92.0 nennen eine Korrektur für wissenschaftliche Sonderzeichen in XML- und JSON-ELN-Exporten. Daraus entsteht ein konkreter eigener Test: Verwenden Sie beispielsweise µl und einen wissenschaftlichen Bezeichner mit griechischem Zeichen, und vergleichen Sie Darstellung sowie Bedeutung vor und nach dem vorgesehenen Export. Ein bloß vorhandenes Exportfile reicht dafür nicht.

Prüfen Sie den Zugriff mit der vorgesehenen späteren Leserrolle und geeigneten Werkzeugen. Regeln Sie auch, was beim Vertragsende oder beim Ausscheiden des ursprünglichen Bearbeiters passiert. Der erforderliche Aufbewahrungsumfang folgt aus Ihrem Aufzeichnungszweck und anwendbaren Vorgaben; eine Produktfunktion bestimmt weder automatisch die Frist noch die ausreichende Archivlösung.

Quellen: [5] [3] [2]

Anbieterbelege und Änderungen auf Ihren Nachweisweg beziehen

Fordern Sie Belege für den tatsächlich eingesetzten Stand und Umfang an. Ordnen Sie Anforderungen, abgedeckte Funktionen, Konfiguration, Testbedingungen, Ergebnisse und bekannte Grenzen einander zu. Ein geeignetes Herstellerpaket kann verwendbare Nachweise enthalten. Es deckt aber weder kraft seines Namens alles ab noch ist es pauschal auf unkonfigurierte Standardfunktionen beschränkt.

Priorisieren Sie verbleibende eigene Prüfungen an den Übergängen Ihres Labors. Ein Add-on, ein geänderter Probenfeldtyp oder ein neuer Exportweg kann andere Folgen haben als eine reine Darstellungsänderung. Beschreiben Sie betroffene Daten und Fehlerszenarien, bevor Sie den nötigen Testumfang festlegen. Eine pauschale Vollrevalidierung nach jedem Update ist daraus nicht abzuleiten.

Für bestehende Installationen helfen ein nachvollziehbarer Konfigurationsstand und ausgewählte historische Datensätze. Vergleichen Sie offene und abgeschlossene Experimente sowie typische Korrekturen. Dokumentieren Sie, welche Lücken behoben werden müssen und welche Betriebsentscheidung daraus folgt. Die öffentliche Hilfe ersetzt hierbei keinen Nachweis über Ihre tatsächliche Einrichtung.

Quellen: [5] [6] [2]

Mit Labor, QA und IT einen arbeitsfähigen Start schaffen

Der Fachbereich muss den Versuch, seine Daten und die spätere Entscheidung erklären können. QA klärt den zutreffenden Regelbereich und die erforderlichen Kontrollen; IT und Systemverantwortliche liefern Betrieb, Rechte, Schnittstellen und Wiederherstellungsweg. Der Anbieter ergänzt versionsbezogene Informationen. Vereinbaren Sie außerdem, wer fachliche Akzeptanz und verbleibende Einschränkungen entscheidet.

Bei einer Einführung steht ein klarer Pilotprozess im Vordergrund. Im Bestand kommen historische Nachweise und eingerichtete Sonderwege hinzu. Bei einer Änderung ist der betroffene Ausschnitt entscheidend. Aufwand und Dauer hängen besonders von Vorlagenvielfalt, Add-ons, Rohdatenwegen und bereits brauchbaren Belegen ab. Ohne diese Informationen ist eine pauschale Zeit- oder Kostenzusage wenig belastbar.

• Konkreten Laborprozess und zulässige Verwendung der Ergebnisse benennen.
• Produktstand, Hosting, Add-ons und verantwortliche Betreiber festhalten.
• Protokollversionen und Regeln für lokale Änderungen bereitstellen.
• Probenidentitäten, Mengenwege, Einheiten und Originaldateien erklären.
• Rollen sowie Bedeutung von Prüfungen und Signaturen vereinbaren.
• Testdatensätze mit Ausgangszustand und unabhängigem Soll vorbereiten.
• Anbieterbelege zu eigenen Anforderungen und offenen Punkten zuordnen.
• Export, Wiederherstellung, Änderung und späteren Zugriff einplanen.

Quellen: [2] [6]