Compliance-Frameworks sind das, wofür ein LIMS existiert. Wenn Ihre Proben in einem Gericht, im Postfach einer Aufsichtsbehörde oder in einem Akkreditierungs-Audit landen, muss das LIMS drei Fragen in Sekunden beantworten können: Wer hat was, wann getan, und lässt es sich reproduzieren?
SENAITE wurde mit dieser Annahme als Grundlage gebaut, nicht als Nachgedanke. Dieser Beitrag ordnet konkrete SENAITE-Features den Klauseln der beiden Frameworks zu, die die meisten Labore betreffen: ISO/IEC 17025:2017 für Prüf- und Kalibrierlabore und 21 CFR Part 11 für Labore unter FDA-Zuständigkeit.
Nicht jede Klausel ist per Software lösbar. Ein LIMS kann Ihr Personal nicht qualifizieren, Ihre Instrumente nicht validieren und keine Vorgesetzte zwingen, die Verifikations-Queue tatsächlich zu lesen. Was es kann: ganze Risikoklassen aus dem manuellen Prozess entfernen. Diese Grenze zieht dieser Beitrag.
ISO/IEC 17025:2017
Klauselverweise in diesem Abschnitt beziehen sich auf die Revision 2017 der Norm.
Klausel 7.5 — Technische Aufzeichnungen
“Technische Aufzeichnungen … für jede Tätigkeit, die das Ergebnis beeinflusst … in einer Weise, dass Änderungen an den technischen Aufzeichnungen zu vorherigen Fassungen oder zu den ursprünglichen Beobachtungen zurückverfolgt werden können.”
Die Antwort von SENAITE ist das Workflow-Übergangsprotokoll
auf jeder Probe und jeder Analyse. Jeder Statuswechsel schreibt
einen Eintrag mit ausführender Nutzerin, Zeitstempel (Serverzeit,
nicht Browserzeit), durchgeführtem Übergang und einem etwaigen
Kommentar. Dieses Protokoll ist über die UI append-only —
es gibt keinen Bearbeiten-Button, keinen Lösch-Button. Ergebnisse
können zurückgezogen werden (ein formaler Übergang, der die
Analyse in einen retracted-Zustand führt und die Rücknahme im
Protokoll dokumentiert); sie können nicht still überschrieben
werden.
Verifizierte und veröffentlichte Ergebnisse sind für die
Bearbeitung gesperrt. Die
Dispose- und Dispatch-Workflows
erweitern diese Sperrung auf abgeschlossene Proben über das
ILockingState-Marker-Interface, sodass eine Integration die
Ergebnisse einer archivierten Probe nicht mehr über die JSON-API
verändern kann.
Klausel 7.11 — Management der Daten und Informationen
“Ein Labor-Informationsmanagementsystem, das zur Erfassung, Verarbeitung, Aufzeichnung, Berichterstattung, Speicherung oder zum Abruf von Daten verwendet wird, muss auf Funktionsfähigkeit validiert sein … Jede Änderung … ist vor Umsetzung zu genehmigen, zu dokumentieren und zu validieren.”
SENAITE wird offen auf GitHub entwickelt. Jede Änderung ist ein Pull Request mit Reviewer, Beschreibung, Tests und Merge-Commit. Diese Commit-Historie ist Ihr Change-Control-Nachweis. Eine Aufsichtsbehörde, die fragt “Wann hat sich das Analyse- Sperrverhalten geändert und wer hat es freigegeben?”, bekommt den Link auf einen konkreten PR mit der Antwort.
Für die Validierung liefert SENAITE die Bausteine, die ein Validierungsprogramm braucht — aber kein Validierungspaket in einer Box. Reproduzierbare Builds über gepinnte Versionen, ein Enterprise-VM-Image mit gleicher Härtung jedes Mal, und Quellcode, den Sie im Beweis zeilengenau referenzieren können. Die IQ-, OQ- und PQ-Dokumente selbst sind Scope-of-Work im Engagement — gegen die tatsächliche Umgebung der Kundin, ihre tatsächliche Konfiguration und ihre tatsächlichen Akzeptanzkriterien — nicht etwas, das wir vorgefertigt ausliefern.
Klausel 6.2 — Personal und 7.7 — Methodenverifikation
Personalberechtigung (6.2.5) und Methoden-Freigabe (7.7) verlangen beide einen Nachweis darüber, wer autorisiert ist, was zu tun, und dass sie es tatsächlich getan haben.
Die Antwort von SENAITE ist ein Rollen- und Permission-Modell
feingranular pro Objekt, Übergang und Feld. Rollen wie
Analyst, Verifier, LabManager und Publisher bilden
direkt Laborfunktionen ab, und der Workflow erzwingt die
Zuordnung. Eine Analystin darf ein Ergebnis einreichen; nur eine
Verifiziererin (eine andere Nutzerin) kann es nach verified
überführen. Ein veröffentlichtes Ergebnis kann nur eine
Labormanagerin invalidieren.
Die volle Zuordnung von Rolle zu Übergang, Zustand für Zustand, wird in jedem Workshop erarbeitet und bekommt einen eigenen Referenz-Beitrag.
Klausel 7.8 — Berichtserstattung von Ergebnissen
“Prüfberichte und Kalibrierscheine müssen genau, klar, eindeutig und objektiv ausgegeben werden.”
SENAITEs Report-Vorlagen sind pro Kunde und pro Berichtstyp konfigurierbar. Die Reporting-Engine handhabt laborspezifische Logos, benutzerdefinierte Papierformate und Batch-Reports. Unterschriften auf Berichten sind an den SENAITE-User-Account gekoppelt, der sie veröffentlicht hat, und die veröffentlichte PDF wird an der Probe abgelegt, sodass genau das Dokument, das die Kundin erhalten hat, Jahre später wieder auffindbar ist.
21 CFR Part 11
Die FDA-Regel Part 11 deckt elektronische Aufzeichnungen und elektronische Signaturen in regulierten Branchen ab. Strikt verpflichtet sind nur Labore, die FDA-regulierte Produkte unterstützen — Part 11 ist aber auch das Referenz-Framework, an dem sich GxP-nahe Labore messen.
Dieser Abschnitt ist ehrlich beim Scope. SENAITE liefert eine belastbare Maschinerie für elektronische Aufzeichnungen. Es liefert keine Part-11-Signatur-Primitive out of the box. Ein Labor unter Part-11-Verpflichtung sollte SENAITE als Audit-Trail-Fundament behandeln und die Signatur-Schicht sowie das formale Validierungsprogramm separat planen.
§11.10(c) — Aufzeichnungsschutz
“Schutz der Aufzeichnungen zur Sicherstellung von genauem und bereitem Abruf über den gesamten Aufbewahrungszeitraum.”
SENAITE speichert jede Probe, Analyse, jedes Worksheet und jeden
Report in einer einzelnen ZODB-Datei (Data.fs), mit binären
Anhängen in einem paarigen Blobstorage-Verzeichnis. Ein
Aufbewahrungszeitraum von zehn Jahren, zwanzig Jahren oder “auf
unbestimmte Zeit bis der Kunde etwas anderes sagt” ist ein
Verzeichnis-Kopie-Problem, kein Datenbank-Migrations-Problem.
Unser Managed Hosting fährt tägliche
Offsite-Backups mit monatlicher Restore-Verifikation, und der
Storage-Schicht ist es egal, ob die Probe gestern oder 2015
veröffentlicht wurde.
§11.10(d) — Systemzugriff
“Beschränkung des Systemzugriffs auf autorisierte Personen.”
Dasselbe Permission-Modell, das ISO-17025-Klausel 6.2 beantwortet. Nutzerinnen werden in SENAITE oder über ein externes Verzeichnis verwaltet; das Plone-LDAP-Plugin läuft out of the box, andere SSO-Wege brauchen abgestimmte Integrationsarbeit. Rechte sind rollenbasiert und pro Objekt.
§11.10(e) — Audit-Trails
“Verwendung sicherer, computer-generierter, zeitgestempelter Audit-Trails, die Datum und Uhrzeit von Bediener-Eingaben und -Aktionen, die elektronische Aufzeichnungen erstellen, ändern oder löschen, unabhängig aufzeichnen.”
Zwei Mechanismen antworten hier zusammen.
Das Workflow-Übergangsprotokoll aus dem ISO-17025-Abschnitt
protokolliert jeden Statuswechsel mit Nutzerin und Zeitstempel.
Darüber hinaus führt SENAITE ein Snapshot-Audit-Log, das von
Subscribers auf ObjectInitializedEvent, ObjectModifiedEvent
und ObjectTransitionedEvent geschrieben wird
(senaite.core.subscribers.auditlog). Jedes Ereignis serialisiert
den vollständigen Feldbestand des Objekts nach JSON, hängt einen
Metadaten-Block an (Nutzerin, Rollen, review_state,
active-Flag, Serverzeit-Zeitstempel, Remote-Adresse,
User-Agent, Referer, Kommentar) und legt ihn in eine
Per-Objekt-PersistentList-Annotation ab
(senaite.core.snapshots). Snapshots werden in einem eigenen
AUDITLOG_CATALOG indiziert, damit sie über das
Audit-Log-Kontrollpanel abgefragt, verglichen und durchgeblättert
werden können.
Der Audit-Trail wird server-generiert, ist nicht
nutzer-editierbar, und jeder Eintrag trägt die ausführende
Person und den Serverzeit-Zeitstempel. Wird ein Objekt gelöscht,
wird sein Snapshot-Log über den IDoNotSupportSnapshots-Marker
eingefroren — kein nachträgliches Umschreiben, auch nicht
durch Personal mit Löschberechtigung.
§11.10(a), §11.10(g), §11.50, §11.70, §11.100, §11.200 — die ehrliche Lücke
Diese Klauseln decken Validierung (§11.10(a)), Autoritätsprüfungen (§11.10(g)), Signatur-Darstellung (§11.50), Signatur-Aufzeichnungs-Bindung (§11.70), Signatur-Eindeutigkeit (§11.100) und nicht-biometrische Zwei-Komponenten-Signatur (§11.200) ab. Zusammen definieren sie, was eine Part-11-Signatur wirklich ist: ein eigenständiger Signaturakt zum Zeitpunkt einer kritischen Transition, mit expliziter Passwort-Neuabfrage, erklärter Signaturbedeutung (“Ich verifiziere diese Ergebnisse”) und einer permanenten, untrennbaren Verknüpfung zum Datensatz.
Nichts davon liefert SENAITE aus. Was SENAITE liefert, ist Session-basierte Authentifizierung, Workflow-Übergänge mit Nutzer-Metadaten und das Snapshot-Audit-Log. Diese Konstellation ist ein Audit-Trail, keine Part-11-Signatur. Sie erfüllt §11.10(e). Sie erfüllt die Signatur-Klauseln oben nicht out-of-the-box.
Für ein Part-11-Labor ist das eine Scope-Konversation, kein Blocker. Das Audit-Trail-Fundament ist der harte Teil und ist fertig. Eine Part-11-Signaturschicht — Passwort- Neuabfrage bei kritischen Transitions, Bedeutungsdeklaration, nicht-abstreitbare Bindung an den Snapshot — ist wohl-definierte Custom-Arbeit auf der Workflow-Engine von SENAITE, und das Gesamtsystem wird dann formal als eines gegen ein geschriebenes Protokoll validiert. Planen Sie beides explizit ein oder wählen Sie ein vertikales LIMS, das Part 11 vor-validiert ausliefert. Planen Sie nicht mit Out-of-the-Box-Part-11-Konformität auf SENAITE.
Was SENAITE nicht für Sie erledigt
Compliance ist ein Prozess. Software ist ein Input in diesem Prozess. SENAITE wird nicht:
- Ihre Instrumente qualifizieren. IQ/OQ/PQ des Instruments selbst ist Ihr Problem. SENAITE erfasst die Ergebnisse; die Qualifikation des Instruments ist getrennt.
- Ihr Personal schulen. Rollenzuweisungen in SENAITE nehmen an, dass das zugewiesene Personal tatsächlich kompetent ist. Schulungs-Aufzeichnungen und Kompetenz-Bewertungen leben ausserhalb des LIMS.
- Eine SOP ersetzen. Standard Operating Procedures sind Dokumente, keine Software. SENAITE-Workflows können erzwingen, dass eine SOP befolgt wird; sie können die SOP nicht schreiben.
- Ein Part-11-Signatur-Primitive ausliefern. Das Audit-Trail-Fundament ist real. Der eigenständige Signaturakt mit Passwort-Neuabfrage und Bedeutungsdeklaration ist es nicht. Wenn Sie Part-11-E-Signaturen brauchen, planen Sie eine Custom-Schicht darauf.
- Sich selbst validieren. SENAITE ist validierbar, nicht selbst-validierend. Ein geschriebenes Protokoll, ausgeführt gegen Ihren tatsächlichen Server, Ihre Konfiguration und Ihren Datenbestand, ist das Artefakt, das die Aufsichts- behörden wollen. Es muss erzeugt werden.
Was wir drumherum tun
Wenn Ihre Compliance-Verpflichtungen am strengeren Ende liegen — FDA-regulierte klinische Studien, Umweltmonitoring für regulatorisches Reporting, Wasserqualität nach EU- Trinkwasserrichtlinie — werden die obigen Fragen nicht mehr theoretisch.
Wir sind das Core-Team hinter der Audit-Trail-Maschinerie, die oben zitiert wird. Braucht Ihr Projekt eine Part-11- Signaturschicht, ein formales Validierungsprogramm oder eine Abbildung Ihrer konkreten regulatorischen Verpflichtungen auf SENAITE-Features mit markierten Lücken, ist das ein gescope-tes Engagement, nicht etwas, das wir in der Grundinstallation ausliefern. Setzen Sie sich mit uns in Verbindung, und wir sagen Ihnen, welche Form so ein Engagement unter Ihren Randbedingungen hat.
Alles hier ist im Code verifizierbar. Nichts davon ist ein Verkaufsversprechen — SENAITE ist Open Source, der Code liegt auf GitHub, und jeder in diesem Beitrag genannte Mechanismus lässt sich auf eine konkrete Datei greppen.
