Konformität 21 CFR Part 11 & EU-GMP Annex 11
Wofür ist diese Seite?
Diese Seite ist die Konformitätsmatrix von LiteLog für regulierte Umgebungen (GxP). Sie ordnet jeder Anforderung aus FDA 21 CFR Part 11 und EU-GMP Annex 11 die LiteLog-Funktion zu, die sie erfüllt, und nennt die Evidenz, mit der Sie das im Rahmen Ihrer Validierung prüfen können: Felder des Signatur-Manifests, Ereignisse des Sitzungsprotokolls und die automatisierten Tests im Quellcode. Punkte, die noch nicht umgesetzt sind, stehen ehrlich als geplant.
LiteLog ist kein vorvalidiertes System; die Validierung (IQ/OQ/PQ) führt der Betreiber im Rahmen seines Qualitätssystems durch. Diese Seite ist die Supplier-Evidenz dafür — zusammen mit dem Audit-Trail, der Digitalen Signatur und der Änderungskontrolle.
:::info Paket Digitale Signatur und revisionssicherer Audit-Trail gehören zum Zusatzprodukt Compliance (im Enterprise-Vertrag enthalten) — siehe Paket wählen. Die Grundsätze der Datenhaltung (serverseitige Zeitstempel, unveränderliche Originale, Korrektur statt Überschreiben) gelten in jedem Paket. :::
Wie Sie die Evidenz lesen
| Evidenz-Art | Was es ist | Wo Sie es finden |
|---|---|---|
Signatur-Manifest (signature_events) | Eine unveränderliche Zeile je Signatur und je fehlender Pflicht-Signatur. Felder: Signierer (signer_name, signer_username, account_id), Zeitpunkte (signed_at = Signaturmoment auf dem Gerät, received_at = Eingang auf dem Server), method (Passwort, PIN, NFC-Chip, QR-Code), meaning (Einreichung / Archivierung), verification (verifiziert, abgelehnt, fehlend) mit failure_reason, payload_hash (SHA-256 der signierten Daten), Gerät (device_unique_id), IP, meta (z. B. Offline-Prüfung). Ohne Fremdschlüssel — überlebt das Löschen von Datensatz und Konto. | Detailansichten von Bericht, Meldung und Aufgabe („Digital signiert" / Abweichung), Formular-PDF (Signatur-Abschnitt), Schnittstelle GET /esignature/events |
Sitzungsprotokoll (account_session_log) | Append-only-Protokoll der Konto-Ereignisse: Anmeldung, Abmeldung, Fehlversuche, Passwort geändert, Zwei-Faktor, SSO-Verknüpfung, Sperren/Entsperren — und für die Signatur: esignature (jede Prüfung von Passwort oder PIN im Signaturmoment, mit Ergebnis und Grund) sowie pin_changed (PIN gesetzt, geändert oder zurückgesetzt; meta.source self_service / admin_reset, meta.channel App / Portal, meta.first_setup, meta.pin_version). | Verlauf → Quelle Sitzungen, Anmelde-Historie des Kontos |
| Automatisierte Tests | Unit- und Integrationstests im Quellcode von LiteLog, die bei jeder Änderung laufen. Dateinamen unten sind Pfade im Repository (api/…). | Bestandteil jedes Releases; auf Anfrage als Testprotokoll |
| Handbuch | Diese Dokumentation (versioniert, jede Änderung nachvollziehbar). | docs.litelog.de |
21 CFR Part 11 — Subpart B: Elektronische Aufzeichnungen
§11.10 Kontrollen für geschlossene Systeme
| § | Anforderung (Kurzfassung) | LiteLog-Funktion | Evidenz | Status |
|---|---|---|---|---|
| 11.10(a) | Validierung des Systems auf Genauigkeit, Zuverlässigkeit, konsistente Leistung und Erkennen ungültiger Datensätze | Der Betreiber validiert (IQ/OQ/PQ). LiteLog liefert Supplier-Evidenz: diese Matrix, automatisierte Tests je Release, Release-Testplan, Signatur-Manifest mit Prüfstatus (ungültige Signaturen werden als rejected/missing sichtbar, nie still angenommen). | alle Testdateien dieser Seite; api/tests/integration/esignature-verify-block.integration.test.ts (11 Fälle: gültig / fremder Chip / abgelaufenes Ticket / fehlende Signatur) | erfüllt (Supplier-Anteil) |
| 11.10(b) | Erzeugung genauer und vollständiger Kopien in lesbarer und elektronischer Form | Formular-PDF mit Signatur-Abschnitt, Berichte und Verlauf als PDF/CSV-Export, Manifest-Zeilen über GET /esignature/events, Daten-Export | Daten & Berichte, Verlauf | erfüllt |
| 11.10(c) | Schutz der Aufzeichnungen über die Aufbewahrungsfrist | Signatur-Manifest ist datenbankseitig unveränderlich (Trigger lehnt UPDATE, DELETE und TRUNCATE ab), ohne Fremdschlüssel — überlebt das Löschen von Objekt und Konto; Originale werden nie überschrieben (Korrektur = neuer Datensatz); tägliche Backups | Migration api/src/db/migrations/1836200000000-SignatureEventsImmutable.ts; Sicherheit & Datenschutz → Backups; Datenintegrität | erfüllt — geplant: derselbe Datenbank-Trigger für das Sitzungsprotokoll (heute append-only als Code-Konvention, monatlich partitioniert) |
| 11.10(d) | Zugang nur für autorisierte Personen | Anmeldung mit Benutzername + Passwort, optional Zwei-Faktor (TOTP) oder Microsoft-Entra-SSO; in der App zusätzlich NFC-Chip / QR-Code; Rollen und Rechte je Konto; Objekt-Scope für Objektleiter und Kundenzugänge; Signatur-Schnittstellen nur für Mandanten mit aktivem Compliance-Paket | Zwei-Faktor-Anmeldung, Anmeldung mit Microsoft, Rollen & Rechte; api/tests/integration/access-audit.integration.test.ts; Paket-Gate-Tests api/src/router/app-routes/__tests__/package-gates.routes.test.ts | erfüllt |
| 11.10(e) | Sicherer, computergenerierter, zeitgestempelter Audit-Trail; Änderungen verdecken frühere Einträge nicht | Serverseitiger Eingangszeitstempel unabhängig von der Geräteuhr; Änderungen an Zeiteinträgen, Rollen, Arbeitszeitmodellen, Regeln und Konten werden mit Benutzer, Zeitpunkt und Pflicht-Änderungsgrund protokolliert; Archivierung statt Löschen; Signatur-Manifest und Sitzungsprotokoll append-only | api/tests/integration/config-audit-tx.integration.test.ts, worktime-audit.integration.test.ts, account-audit-tx.integration.test.ts, access-audit.integration.test.ts, record-archive.integration.test.ts (8 Fälle) | erfüllt |
| 11.10(f) | Betriebliche Systemprüfungen zur Einhaltung der zulässigen Schrittfolge | Der Server erzwingt die Signatur vor der Annahme: ein signaturpflichtiger Vorgang ohne gültige Signatur wird im Portal und über Schnittstellen abgelehnt (Antwort „Esignature required" mit den am Objekt erlaubten Methoden); Änderungskontrolle: Antrag → Entscheidung einer zweiten Person → Wirksamkeit | api/tests/integration/esignature-form-response-enforcement.integration.test.ts, esignature-task-completion.integration.test.ts, change-control.integration.test.ts (7 Fälle) | erfüllt |
| 11.10(g) | Berechtigungsprüfung: nur autorisierte Personen dürfen signieren, Datensätze ändern oder Funktionen nutzen | Rechteprüfung je Aktion und Objekt; Manifest-Zeilen sieht nur, wer das Objekt sehen darf; Vier-Augen-Prinzip der Änderungskontrolle (eigener Antrag ist nicht freigebbar); Signatur nur durch das angemeldete Konto (fremder Chip/QR wird abgelehnt und protokolliert) | change-control.integration.test.ts; esignature-verify-block.integration.test.ts (Fälle chip_mismatch, qr_mismatch, ticket_account_mismatch); api/src/service/esignature/esignature-attempt.test.ts | erfüllt |
| 11.10(h) | Geräteprüfungen zur Gültigkeit der Datenquelle | Gerätekennung (device_unique_id) im Manifest und im Sitzungsprotokoll; die Offline-Freigabe der PIN wird nur an registrierte App-Geräte ausgestellt und nur im Synchronisierungs-Pfad der App akzeptiert — Portal und Schnittstellen erhalten keine Freigabe und können keine einlösen | api/src/service/esignature/offline-pin-grant.test.ts (6 Fälle: Konto-, Mandanten-, PIN-Versions-Bindung, Ablauf); esignature-verify-block.integration.test.ts | erfüllt |
| 11.10(i) | Ausbildung, Schulung und Erfahrung der Personen | Betreiber-Pflicht. LiteLog unterstützt mit diesem Handbuch und mit Hinweisen im Signatur-Dialog (Signierer, Bedeutung, Verbindlichkeit). | Digitale Signatur | Betreiber |
| 11.10(j) | Schriftliche Regelungen, die Personen für ihre elektronische Signatur verantwortlich machen | Betreiber-SOP. LiteLog zeigt bei jeder Signatur den Verbindlichkeitssatz (Gleichstellung mit der handschriftlichen Unterschrift) und den Hinweis auf Nicht-Weitergabe der PIN. | Digitale Signatur → Signieren im Portal | Betreiber — geplant: protokollierte Bestätigung beim ersten Einrichten der PIN (pin_changed.meta.acknowledged_at) |
| 11.10(k) | Kontrolle der Systemdokumentation (Verteilung, Zugriff, Änderungshistorie) | Handbuch und technische Dokumentation sind versioniert; jede Änderung ist mit Zeitpunkt und Urheber nachvollziehbar; veröffentlichte Version entspricht dem ausgelieferten Release | docs.litelog.de; Änderungshistorie des Dokumentations-Repositories | erfüllt |
§11.30 Kontrollen für offene Systeme
LiteLog wird als geschlossenes System betrieben (Zugang nur für Personen, die der Betreiber angelegt hat; Transportverschlüsselung TLS; Verschlüsselung der Daten im Ruhezustand). Die zusätzlichen Maßnahmen für offene Systeme sind deshalb nicht einschlägig — siehe Sicherheit & Datenschutz.
§11.50 Signatur-Angaben
| § | Anforderung | LiteLog-Funktion | Evidenz | Status |
|---|---|---|---|---|
| 11.50(a)(1) | Gedruckter Name des Signierers | signer_name und signer_username werden zum Signaturzeitpunkt im Manifest gestempelt (überleben Umbenennung oder Löschung des Kontos); der Dialog zeigt vor der Eingabe „Sie signieren als …" | Manifest-Felder; Detailansichten; Formular-PDF | erfüllt |
| 11.50(a)(2) | Datum und Uhrzeit der Signatur | signed_at (Signaturmoment auf dem Gerät, relevant im Offline-Fall) und received_at (Server-Eingang, unabhängig von der Geräteuhr); der Dialog weist auf den Server-Zeitstempel hin | Manifest-Felder | erfüllt |
| 11.50(a)(3) | Bedeutung der Signatur | meaning: Einreichung (Formular-Antwort, Meldung, Aufgaben-Erledigung, „Nicht durchführbar", Tour-Abschluss) oder Archivierung/Freigabe (Entscheidung der Änderungskontrolle); der Dialog nennt die Bedeutung vor der Eingabe | Manifest-Feld meaning; Änderungskontrolle | erfüllt — geplant: feinere Bedeutungen (Erledigung, Nicht durchführbar, Tour-Abschluss) auch im Manifest |
| 11.50(b) | Angaben sind Teil jeder lesbaren Form der Aufzeichnung | Signatur-Status in den Detailansichten, eigener Signatur-Abschnitt im Formular-PDF, Manifest-Zeilen über die Schnittstelle | Digitale Signatur → Nachweis | erfüllt |
§11.70 Verknüpfung von Signatur und Aufzeichnung
| § | Anforderung | LiteLog-Funktion | Evidenz | Status |
|---|---|---|---|---|
| 11.70 | Signatur ist untrennbar mit dem Datensatz verknüpft und kann nicht ausgeschnitten, kopiert oder übertragen werden | payload_hash = SHA-256 des kanonisierten Datensatzes im Manifest; Zuordnung über object_type + object_uuid; Manifest datenbankseitig unveränderlich; Signatur-Ticket ist an Konto, Methode und Mandant gebunden und läuft nach 10 Minuten ab | api/src/service/esignature/esignature.service.test.ts (computePayloadHash: deterministisch, reihenfolgeunabhängig); api/src/service/token/auth-token-service.test.ts (7 Fälle: Ticket ≠ Access-Token, Bindung, Laufzeit); Migration 1836200000000-SignatureEventsImmutable.ts | erfüllt — geplant: Einmalnutzung des Tickets (jti), damit ein Ticket innerhalb seiner 10 Minuten nicht zweimal verwendet werden kann |
21 CFR Part 11 — Subpart C: Elektronische Signaturen
§11.100 Allgemeine Anforderungen
| § | Anforderung | LiteLog-Funktion | Evidenz | Status |
|---|---|---|---|---|
| 11.100(a) | Signatur ist einer Person eindeutig zugeordnet und wird nie wiederverwendet oder neu zugewiesen | Benutzername je Mandant eindeutig; jedes Konto hat eine interne Kennung, die nie neu vergeben wird; die Signatur-PIN legt ausschließlich die Person selbst fest — die Verwaltung kann sie nur löschen, nie setzen oder einsehen; NFC-Chip und QR-Code sind an das Konto gebunden | api/tests/integration/esignature-pin.integration.test.ts (8 Fälle); Sitzungsprotokoll pin_changed mit meta.source | erfüllt |
| 11.100(b) | Identitätsprüfung vor Zuweisung der Signatur | Betreiber-Pflicht beim Anlegen des Kontos (Onboarding). LiteLog protokolliert Anlage, Einladung und Objekt-Zuweisung des Kontos. | api/tests/integration/account-invite-audit.integration.test.ts, account-property-assignment-audit.integration.test.ts | Betreiber |
| 11.100(c) | Zertifizierung gegenüber der FDA, dass elektronische Signaturen rechtsverbindlich sind | Betreiber-Pflicht (Schreiben an die FDA). LiteLog zeigt bei jeder Signatur den Verbindlichkeitssatz. | — | Betreiber |
§11.200 Komponenten und Kontrollen der Signatur
Interpretation von LiteLog zu §11.200(a)(1): Die elektronische Signatur besteht aus zwei Komponenten. Die erste Komponente ist die angemeldete Sitzung — Benutzername + Passwort, optional mit Zwei-Faktor oder Microsoft-SSO; in der LiteLog-App auch NFC-Chip oder QR-Code als Anmeldemittel. Die zweite Komponente ist die geheime Signatur-Komponente im Signaturmoment: die Signatur-PIN (oder das erneut eingegebene Passwort). Im Portal läuft eine Sitzung nach 20 Minuten Inaktivität ab (Zugriffs-Token); die App-Sitzung ist an das registrierte Gerät gebunden und lässt sich sperren.
| § | Anforderung | LiteLog-Funktion | Evidenz | Status |
|---|---|---|---|---|
| 11.200(a)(1)(i) | Erste Signatur in einer Sitzung mit allen Komponenten, Folgesignaturen mit mindestens einer | LiteLog ist strenger: jede Signatur verlangt die geheime Komponente (PIN oder Passwort); die Sitzung (erste Komponente) ist Voraussetzung für jeden Aufruf. Ein Signatur-Ticket gilt 10 Minuten, nur für dieses Konto und diese Methode. | esignature-pin.integration.test.ts; auth-token-service.test.ts | erfüllt |
| 11.200(a)(1)(ii) | Signaturen außerhalb einer durchgehenden Sitzung mit allen Komponenten | Nach Ablauf der Sitzung ist eine neue Anmeldung nötig; die Offline-Freigabe der PIN in der App ersetzt nur die Server-Prüfung, nicht die PIN-Eingabe — und sie erlischt bei Abmeldung, PIN-Änderung oder Zurücksetzen | offline-pin-grant.test.ts | erfüllt — geplant: Login-Methode der Sitzung im Manifest (meta.session_amr) |
| 11.200(a)(2) | Nur der rechtmäßige Inhaber kann die Signatur verwenden | PIN nur durch die Person selbst setzbar (Passwort-Bestätigung), nie im Klartext gespeichert (Hash), Verwaltung kann nur löschen; NFC-Chip/QR-Code müssen zum angemeldeten Konto gehören; Sperre nach 5 Fehlversuchen für 15 Minuten | esignature-pin.integration.test.ts; api/src/service/account/pin-lockout.test.ts; esignature-verify-block.integration.test.ts | erfüllt |
| 11.200(a)(3) | Missbrauch erfordert die Mitwirkung von mindestens zwei Personen | Die Verwaltung kennt die PIN nicht und kann sie nicht setzen; ein Zurücksetzen ist protokolliert (pin_changed, admin_reset, mit handelndem Konto) und erzwingt die Neuanlage durch die Person; Verbindlichkeits- und Nicht-Weitergabe-Hinweis im Dialog | Sitzungsprotokoll; Digitale Signatur → PIN einrichten | erfüllt |
| 11.200(b) | Biometrische Signaturen | Nicht verwendet. | — | nicht einschlägig |
§11.300 Kontrollen für Identifikationscodes und Passwörter
| § | Anforderung | LiteLog-Funktion | Evidenz | Status |
|---|---|---|---|---|
| 11.300(a) | Eindeutigkeit der Kombination aus Kennung und Passwort | Benutzername je Mandant eindeutig; Passwörter als bcrypt-Hash; PIN als Hash mit Versionszähler (pin_version) | Sicherheit & Datenschutz | erfüllt |
| 11.300(b) | Regelmäßige Überprüfung, Erneuerung oder Widerruf | Passwort und PIN jederzeit durch die Person änderbar (jeweils mit Passwort-Bestätigung); Verwaltung kann Passwort zurücksetzen, PIN löschen, Zwei-Faktor zurücksetzen, Konto sperren oder archivieren; alle Vorgänge im Sitzungsprotokoll. Eine erzwungene Rotation regelt der Betreiber per SOP. | Sitzungsprotokoll (password_changed, password_reset, pin_changed, mfa_reset) | erfüllt (Rotation: Betreiber) |
| 11.300(c) | Verfahren bei Verlust oder Kompromittierung | Passwort-Reset per E-Mail-Link; PIN vergessen → Neuanlage mit Passwort; PIN kompromittiert → sofort ändern oder durch Verwaltung löschen (Offline-Freigaben erlöschen); NFC-Chip neu zuweisen; Zwei-Faktor über Wiederherstellungscodes oder Verwaltung | Digitale Signatur → Häufige Fragen, Zwei-Faktor-Anmeldung | erfüllt |
| 11.300(d) | Schutz vor unbefugter Nutzung mit Erkennung und Meldung | Signatur-PIN: Sperre nach 5 Fehlversuchen für 15 Minuten je Konto (online und offline); Anmeldung: Konto-Sperre nach 10 Fehlversuchen für 15 Minuten; Signatur-Schnittstellen zusätzlich IP-gedrosselt; jeder Fehlversuch im Sitzungsprotokoll (esignature mit Grund, login_failed); abgelehnte Signaturversuche in der App (fremder Chip) werden als Manifest-Zeile rejected gemeldet | pin-lockout.test.ts; esignature-attempt.test.ts (8 Fälle); Sitzungsprotokoll | erfüllt — geplant: Konto-Sperre auch für die Passwort-Signatur (heute IP-Drossel + Protokoll) |
| 11.300(e) | Prüfung von Geräten, die Codes tragen (Token, Karten) | NFC-Chips und QR-Codes werden bei jeder Signatur serverseitig gegen das Konto geprüft; ein Chip kann nur einem Konto zugewiesen sein; Austausch über die Verwaltung | Digitale Signatur, esignature-verify-block.integration.test.ts | erfüllt |
EU-GMP Annex 11 — Computergestützte Systeme
| § | Anforderung | LiteLog-Funktion | Evidenz | Status |
|---|---|---|---|---|
| 9 Audit Trails | Aufzeichnung aller GMP-relevanten Änderungen und Löschungen mit Grund, Zeitpunkt und Person; regelmäßige Überprüfung | Pflicht-Änderungsgrund bei Korrektur und Löschung von Zeiteinträgen; Archivierung statt Löschen; Konfigurations-Audit (Vorlagen, Regeln, Rollen, Arbeitszeitmodelle); serverseitige Zeitstempel; Verlauf mit Filtern und Export zur Überprüfung | siehe §11.10(e); Verlauf | erfüllt |
| 12 Sicherheit | Physische und logische Zugangskontrolle, Protokollierung von Zugriffen und Änderungen, Verwaltung der Benutzerrechte | Rollen und Rechte, Zwei-Faktor, SSO, Objekt-Scope; Sitzungsprotokoll für Anmeldung, Abmeldung, Fehlversuche und Credential-Änderungen; Hosting in der EU mit Verschlüsselung | siehe §11.10(d); Sicherheit & Datenschutz | erfüllt |
| 14 Elektronische Signatur | Gleiche Wirkung wie die handschriftliche Unterschrift, dauerhafte Verknüpfung mit dem Datensatz, Datum und Uhrzeit | Verbindlichkeitssatz im Dialog; payload_hash und Unveränderlichkeit des Manifests; signed_at / received_at | siehe §11.50, §11.70 | erfüllt |
Offene Punkte (geplant)
Diese Punkte sind in der Planung und werden mit kommenden Releases umgesetzt. Bis dahin sind sie im Rahmen Ihrer Risikobewertung zu berücksichtigen:
- Einmalnutzung des Signatur-Tickets — Ein Ticket gilt heute 10 Minuten für Konto und Methode; eine Kennung je Ticket (
jti) soll die Wiederverwendung innerhalb dieser Zeit ausschließen. - Konto-Sperre für die Passwort-Signatur — Fehlversuche der Passwort-Signatur werden protokolliert und IP-gedrosselt; die Sperre je Konto (wie bei PIN und Anmeldung) folgt.
- Datenbank-Trigger für das Sitzungsprotokoll — Das Sitzungsprotokoll ist in der Anwendung ausschließlich schreibend; der harte Datenbank-Schutz gegen Änderung und Löschung (wie beim Signatur-Manifest) folgt.
- Einwilligungsnachweis beim ersten Einrichten der PIN — Eine protokollierte Bestätigung der Verbindlichkeit (
acknowledged_at) beim ersten Setzen der PIN. - Login-Methode der Sitzung im Manifest — Welche erste Komponente (Passwort, Zwei-Faktor, SSO, NFC, QR) der Sitzung zugrunde lag.
- Feinere Bedeutungen im Manifest — Erledigung, „Nicht durchführbar" und Tour-Abschluss als eigene Werte neben Einreichung und Archivierung.
Häufige Fragen
Ist LiteLog „Part-11-validiert"?
Nein — kein Hersteller kann ein System für Sie validieren. Die Validierung (IQ/OQ/PQ) ist Teil Ihres Qualitätssystems und bezieht sich auf Ihren konkreten Einsatz. LiteLog liefert die Supplier-Evidenz: diese Konformitätsmatrix, automatisierte Testnachweise, den Audit-Trail und das Signatur-Manifest.
Woher bekomme ich die Testnachweise?
Die genannten Testdateien sind Teil des LiteLog-Quellcodes und laufen bei jeder Änderung. Für Ihre Validierungsakte stellt Ihnen das LiteLog-Team auf Anfrage ein Testprotokoll des eingesetzten Releases zur Verfügung.
Reicht die Signatur mit PIN allein — oder muss es das Passwort sein?
Beide sind gleichwertige geheime Signatur-Komponenten; die PIN ist für den mobilen Einsatz gedacht (schnell, offline-fähig). Welche Methoden an einem Objekt zulässig sind, legen Sie unter Manipulationsschutz fest. Für Konten, die sich per SSO anmelden und kein LiteLog-Passwort haben, ist die PIN die Signatur-Komponente.
Verwandte Seiten
- Digitale Signatur — Einrichtung, Signieren in App und Portal, Signatur-PIN, Offline-Verhalten
- Datenintegrität & ALCOA+ — Grundsätze der Datenhaltung
- Änderungskontrolle (Change Control) — Vier-Augen-Freigabe für Korrekturen, Archivierung und Einstellungen
- Sicherheit & Datenschutz — Hosting, Verschlüsselung, Backups
- Verlauf (Aktivitätsprotokoll) — Sitzungs-Ereignisse einsehen und exportieren
- Zwei-Faktor-Anmeldung — zweiter Faktor für die Anmeldung