I update procedures and Technical File documents every week. The tricky part isn’t the wording — it’s changing something in a live procedure without losing the audit trail, confusing your users, or triggering an avoidable CAPA weeks later. To be fair, MDR and ISO demands are clear enough: documentation must be controlled, changes traceable, and the Technical Documentation kept up to date (see Annex II of MDR). In practice this means your editing workflow needs predictable versioning, enforced review, and a permanent record of why a change happened.
Below is a practical walkthrough I use with our file app (short demo video if you prefer a quick visual: https://www.youtube.com/watch?v=aB1X3LB097U). This is a practitioner-level checklist — not a feature spec. Adapt it to your eQMS, but keep the principles.
Before you edit: create the record of intent
If the change is anything but a pure typographical fix, open a Change Request (CR) first.
- Title the CR clearly: “Procedure XYZ — scope clarification / role name change / flow update”.
- Link the CR to impacted items: procedure ID, associated SOPs, Device Master Record (if applicable).
- Do a quick risk check: will wording change affect device safety, user actions, or labelling? If yes, add a brief risk assessment and consider whether this triggers PMCF/PSUR or a corrective action.
- If the change arose from an event (customer complaint, audit finding), link the CAPA or non-conformance record. In my team we try to avoid separate, unlinked tasks — connected workflow is lifesaving when an auditor asks “show me the chain.”
Why this matters: auditors (and notified bodies) will expect to see rationale and traceability from problem → change → verification. Having the CR in place is the single best piece of documentation to preserve later.
Check out, edit, and preserve the working history
Use the file app’s built-in edit/check-out mechanism rather than downloading local copies.
- Check out the file (or create a working draft in the app). This prevents “two people saving over each other” problems.
- Use tracked changes or a delta log inside the file. If your file format doesn't support redlines reliably, maintain a short change-summary document.
- Every save should attach metadata: user, timestamp, and a short “reason for change” entry. If your app supports it, include a checksum or content hash as part of the audit trail.
Practical tip: don’t use filenames like Procedure_v3_FINAL_reallyFINAL.docx. That destroys traceability and confuses training assignments. Use semantic versioning instead (see next).
Safer versioning — a simple, enforceable scheme
We needed something engineers would follow without a training course. Our scheme:
- Major.Minor.Revision
- Major = substantive process change with potential safety impact (e.g., step removed, responsibilities changed).
- Minor = editorial clarifications, reordering, non-substantive wording.
- Revision = metadata updates, typo fixes, formatting.
- Every approved release gets a new number and a release note: who approved, effective date, short summary of change, and CR/CAPA reference.
In practice this means an editorial fix goes 2.1.3 → 2.1.4; a role change goes 2.1.4 → 3.0.0. The file app should enforce version increments at publication — if yours does not, add it to the workflow as a required field.
Why this helps: auditors will ask to see version history and to understand what changed between the version they inspected and the one you currently use. A clear numbering scheme + release notes answers that at a glance.
Review, approval, and e-signature
Don’t shortcut approvals because the update feels small.
- Route the draft via the app’s review task: at least one subject-matter expert and one QA approver.
- Collect comments in the app (not email). This preserves context.
- Use an e-signature or approval action that writes reviewer name, date/time, and a short approval comment into the audit trail.
- If your change affected training, trigger a training assignment automatically at publication.
To be fair, reviewers hate busywork. Keep review windows tight (48–72 hours) and provide a one-line summary of the risk impact to speed decisions.
Publishing, distribution, and post-publication checks
Once approved:
- Publish the document as “Approved” and set an effective date.
- Archive the previous version as read-only; keep it discoverable for investigations.
- Assign training or an acknowledgement task to affected users. Small teams often skip this — granted — but then expect follow-ups when staff don’t follow the new process.
- Verify implementation: a quick read-back or sampling audit within 2–4 weeks helps catch misunderstandings.
The audit trail you need should include: who edited, what changed, who approved, when it became effective, and what training was assigned. If your app’s audit log includes content diffs, even better.
Linking changes to CAPA and risk
Editing procedures isn’t isolated. I link every substantive change back to either a CR or CAPA, and to any updated risk assessment.
- If a change came from a complaint, show the link.
- If the change required an updated hazard analysis, attach that file to the CR.
- If an automated CAPA was created from a monitoring trigger, make sure the CAPA notes reference the procedure version where corrective actions are documented.
This avoids the “we changed the procedure but didn’t fix the problem” critique that some auditors raise.
Short checklist to run before closing the change
- CR linked to procedure and device(s)
- Drafted in-app (no local-only copies)
- Change summary in file metadata
- Reviewer approvals and e-signature recorded
- Previous version archived and accessible
- Training assigned and evidence scheduled
- Risk assessment updated where required
Final thoughts
I’ve seen audits where a single missing approval comment delayed the entire review and forced rework. Tools help — the file app makes check-out, metadata, and audit logs straightforward — but the discipline of linking CRs, risk, and training is the real safeguard. Also: automated CAPAs and AI-supported suggestions are useful for surfacing impacted documents, but keep the final decision human and reviewable.
How do you version and publish procedure updates in your organisation — do you separate “editorial” from “substantive” in practice, or is everything treated the same?
