To be fair, "we have a QMS" is the easiest checkbox in a notified‑body audit. The hard part is that regulators, auditors and — most importantly — frontline engineers do not care about your checkbox. They care about whether your system prevents a bad device from reaching a patient tomorrow.
I see this every quarter in Technical File reviews and surveillance audits under MDR 2017/745: companies start with control (policies, SOPs, folders). Auditors nod. Then a change request lands, a supplier fails a test, or a vigilance form is needed — and the paperwork suddenly doesn't help because the people doing the work cannot find the connection between an incident, the risk assessment, the change control and the device documentation. Control is necessary. It is not sufficient.
Control is the foundation, not the ceiling
Standards and regulations are explicit about the "what": ISO 13485 requires documented processes; the MDR requires risk management and post‑market surveillance as ongoing obligations (see Article 10 and Annexes I/II). But they say less about the "how" for everyday use. In my experience:
- A documented process that lives in a drawer is evidence in a binder; it is not protection on the shop floor.
- Traceability is the single most recurring gap auditors raise: "Show me where the risk control change is linked to the device brochure and the clinical evaluation." If you can't show it within minutes, you will be asked for corrective evidence.
- Change control should be governance, not overhead. If engineers see change control as bureaucracy, they will bypass it.
So start with control, yes — but design your control with use in mind.
What "turning control into practice" actually looks like
Practically, this means three shifts in how you design and run your QMS.
-
Design for discoverability
- Make trace links easy to follow: from complaint → investigation → CAPA → risk assessment → product master.
- Use configuration that surfaces impacted documents automatically when a change is proposed. In practice this means an eQMS where the Change Impact Mapping tab is not an afterthought but the first screen engineers see.
-
Make tasks part of daily workflow
- Move the "QMS step" to the engineer's workflow, not the QMS back office. E.g., require a short risk note in the commit message when a design file is updated; have the system auto‑create a change record that the engineer completes in a minute.
- Automate reminders and link them to reviewability of evidence, so documented acceptance isn't just a signature — it's a recorded check.
-
Keep risk visible across artefacts
- CAPA-driven risk assessment, not the other way round: when a non‑conformance arises, assess residual risk and map to clinical impact immediately.
- Make the link between CAPA and clinical follow‑up (PMCF) explicit. Notified bodies increasingly ask for that bridge during audits.
Small wins that compound
You don't need to overhaul everything. A few practical fixes I found effective:
- Replace long free‑text CAPA templates with a short, structured flow: observed issue → immediate containment → suspected root cause (options) → planned action → verification. This encourages timely entries and supports automated CAPAs without losing human judgement.
- Enforce a one‑click traceability check in change approval: approvers must confirm impact on applicable risk controls, clinical data, and labelling. If any box is ticked, the system routes to a checklist.
- Use "controlled assistance" for drafting: allow AI‑assisted summaries of investigation evidence, but require human approval and a rationale field for auditors. AI proposes, a human approves and signs — safe assistance that keeps responsibility clear.
These are not glamorous. They do, however, convert governance into behaviour.
When notified bodies test your "daily practice"
From interactions with TĂśV and other notified bodies, the recurring theme is evidence of routine practice. They will ask for:
- Examples of recent changes and the trace from the change to risk mitigation and labelling updates.
- Evidence that CAPAs result in closed, verified improvements — not just plans.
- That PMS and PMCF data actually informed decisions (Annex III/Annex XIV themes).
If your QMS produces those lines quickly and repeatedly, you pass. If you have to invent context on the spot, you won't. The real audit‑winning artefact is not perfect paperwork. It's repeatable practice.
What I changed in my team last year
A year ago we had three recurring failures: change control backlogs, CAPAs left unverified, and engineers bypassing processes for rapid fixes. We implemented:
- A connected workflow so a change request auto‑pulls related risk files and previous investigations.
- A weekly CAPA triage meeting with the responsible engineer presenting a one‑slide summary (containment, root cause, next action). This forced succinctness and accountability.
- A "reviewability" requirement: any automated summarisation or proposed action must be traceable to source documents; review trails are part of the record, not an add‑on.
Granted, it wasn't instant. We still have backlog days. But the number of times we had to reconstruct a decision from scratch dropped materially. Auditors noticed the difference between a control performed and a control used.
Final thought
Control is where you start; practice is where the patient is protected. The regulatory texts (ISO 13485, MDR) demand both — but they reward the team that embeds the QMS into everyday work. Designing for discoverability, enforceable but light‑touch workflows, and explicit links between CAPA, risk and clinical data will get you from "we have a QMS" to "we use a QMS."
What single small change could you make this month that would make compliance part of your engineers' normal day, not an audit panic?
