ADR-0014: Electronic Signatures (Part 11 / Annex 11-Capable)¶
- Status: accepted
- Date: 2026-06-17
- Deciders: Nicolas Burri
- Relates to: ADR-0001, ADR-0003, ADR-0011, ADR-0013; GAP-04
Context¶
ISO 13485 requires controlled records but does not itself define electronic signatures. Many medical-device makers also fall under FDA 21 CFR Part 11 and/or EU Annex 11, which do. As a QMS tool meant to serve such customers, LQMS should be capable of compliant electronic signatures (configurable per deployment), without forcing the ceremony where it is not needed. Approvals already capture user/role/timestamp append-only (REQ-LC-008); signatures add meaning, manifestation, content linking, and re-authentication.
Decision¶
An approval/transition becomes an electronic signature when the review policy marks the step as signed — not a parallel mechanism (consistent with ADR-0003).
- Signature record captures: the signer (individual identity, ADR-0013), the
meaning (from a defined set:
AUTHORED,REVIEWED,APPROVED,RELEASED), the timestamp, the bound version and its content hash (ADR-0001), and proof of authentication at signing (method/assurance, e.g. OIDCacr/amr). Signatures are immutable, append-only, and part of the version's permanent record and audit trail. - Manifestation (Part 11 §11.50): any human-readable rendering and export of a signed record shows, per signature, the signer's name, date/time, and meaning.
- Record linking (§11.70): the signature is bound to the exact content via its hash, so it cannot be transferred to other content without detection.
- Re-authentication — continuous-session model: step-up re-authentication at the start of a signing session (via the IdP, possibly MFA); within a configurable window further signatures require only intent confirmation; re-authentication again after the window, on idle, or in a new session. Matches Part 11's continuous-session allowance and keeps routine work usable (STR-007).
- Configurable: which steps require a signature (and with which meaning) and the re-authentication window are configured per review policy / document type. Steps that do not require a signature use the plain approval record (REQ-LC-008).
- Uniqueness / non-repudiation: each signature is uniquely attributable to one individual (ADR-0013, no shared accounts); re-authentication plus the audit trail provide non-repudiation.
Consequences¶
- Schema: a
signaturetable (version, content hash, signer, meaning, signed-at, auth method/assurance, session/assertion reference); review policy gains per-step "signature required + meaning" and a re-auth-window setting. - Re-authentication uses OIDC step-up (
max_age/acr_values/prompt=login), capturingacr/amras proof of assurance. - Manifestation must be implemented in UI rendering and in PDF/exports.
- Out of scope: biometric signatures, and binding handwritten signatures to electronic records.
- Deployments with no Part 11/Annex 11 obligation simply leave signing unconfigured and use plain approvals.
Requirements¶
Introduces STR-019 and the REQ-SIG group (pending requirements baseline v1.1).