ADR-0071: Training Plans — Document Obligations + External Trainings & Certifications¶
- Status: accepted (P-1 settled 2026-07-15 as self-record + confirm after the CAS anecdote; P-2..P-4 confirmed by Nicolas 2026-07-15: "for the record: agree with P2-P4")
- Date: 2026-07-14
- Deciders: Nicolas Burri, design by Claude.
- Relates to: ADR-0070 (questionnaires — the document-training half this aggregates), ADR-0022 (whose "no competence matrices / course management" out-of-scope line this deliberately narrows), ADR-0069 (FILE attachments — certification evidence), ADR-0019 (tasks/notifications — expiry reminders), ADR-0016 (retention/privacy — training records are personal data).
Context¶
ISO 13485 §6.2 wants competence ensured, training provided, effectiveness evaluated, and RECORDS kept. ADR-0070 covers the document side (who must train on what, with evidence). What's missing is the PER-USER view and the world outside the QMS: courses, external seminars, certifications with expiry (e.g. auditor qualifications, first-aid, vendor certificates). Nicolas: training plans "should include both trainings in the QMS and also additional trainings and relevant certifications" — and, as a HARD constraint (2026-07-15): "even a full competence management should be kept simple … I do not want to have to maintain a second HR system. In the end I need a solution that satisfies the auditors and is easy to use for the people working with the system." The Jira predecessor failed exactly there (he had to ask the QMB whether he may resolve his own education tickets — the process model could not answer its own question).
Decision (proposed)¶
- A training plan is a PER-USER, PER-SCOPE view, not a new assignment mechanism: the document-obligation half is DERIVED (addressee policies × the user's roles → which documents, joined with the trained-to-version ledger → status). Nothing is duplicated; the plan cannot drift from enforcement.
- External entries are first-class rows:
training_entry{user, scope, kind (TRAINING | CERTIFICATION), title, provider/issuer, completed/issued date, valid-until (null = non-expiring), evidence attachments (FILE class), notes, recorded-by, timestamps}. Immutable record + narrow correction semantics (same posture as review comments: supersede, don't edit). - Expiry drives tasks: a certification with
valid-untilraises a renewal task/notification to the user (and MANAGE_TRAINING holders) at a configurable lead time (default 90 days). - Visibility is restricted by default: the user themselves + MANAGE_TRAINING holders in the scope. Training records are personal data — broader visibility (e.g. line managers) is a deliberate later decision, not a default.
Decision points (all settled 2026-07-15)¶
- P-1 Who records external entries? (b) users SELF-RECORD their completed trainings (with evidence), MANAGE_TRAINING CONFIRMS — recommendation revised 2026-07-15 after Nicolas's CAS anecdote: the two-step encodes the answer to "may I resolve my own training?" in the system (yes — and the confirmation is the four-eyes attestation auditors want). Alternatives: (a) MANAGE_TRAINING-only (records posture, but recreates the ask-the-QMB friction); © users freely (no attestation).
- P-2 Planned-but-not-done entries: does the plan track PLANNED external trainings (a target date, "needs Auditor course by Q3") or only completed facts? Recommended: yes, a PLANNED status — that is what makes it a plan rather than a logbook; completion converts the row to a record.
- P-3 Role-derived training requirements beyond documents: their Jira system staffs roles per document; do we want "role X requires certification Y" rules (a competence matrix light) that auto-raise gaps in the plan? Recommended: NOT in v1 — keep v1 to derived document obligations + manual external entries; matrix rules are a clean later layer on the same rows.
- P-4 Reporting surface: per-user plan page (always); plus a scope-level training dashboard for MANAGE_TRAINING (status per document/role, expiring certifications)? Recommended: yes, extending the existing ack reporting rather than a new module.
Design constraints (agreed 2026-07-15)¶
- Not a second HR system. The training domain stays a RECORD layer: entries + evidence + derived status. No course catalogs, scheduling, budgets, or org-chart mirroring.
- Evidence vs claim, separated from day one: entries are EVIDENCE; "qualified for X until D" is a derived/asserted CLAIM on top. The future competence matrix (P-3, deferred) layers on the same rows — a design constraint now instead of a migration later.
- Training records are NOT documents in the tree (wrong lifecycle shape, wrong visibility model).
Consequences¶
- New RLS-covered
training_entry(+ evidence via existing FILE attachments on… entries are not documents — evidence blobs need an owner: either (i) entries reference uploaded blobs directly in a small entry-attachment table reusing the content store, or (ii) evidence lives as FILE attachments on a per-user "training file" RECORD document. (ii) reuses everything (retention, disposal, freeze) but bends the document model; (i) is a small honest table. Draft prefers (i). - The per-user plan view joins: derived document obligations (live), questionnaire/ack status (ADR-0070 ledger), external entries, expiry state.
- GDPR/retention: training records retained like other QMS records (ADR-0016); on user offboarding they REMAIN (they are the company's evidence), access narrows to MANAGE_TRAINING.