You don't get a polite email in the middle of the night that says "quality has failed." You get a user on the phone, frustrated, trying to improvise a fix in theatre, or you get a distributor asking for guidance you don't have. Over the last few years — between notified-body audits, PSUR reviews, and more than one recall — I've learned what end-users notice first when a manufacturer's quality system is fraying. To be fair, regulators see the formal evidence; users see the operational consequences, genau.
The first signals: what users tell you before regulators do
Users rarely frame their feedback as "we have a non-conformity." They describe operational pain:
- "The labelling on my kit doesn't match the tray — which one do I open?"
- "The instructions are out of date; the step they show doesn't exist on our software."
- "We've run out of spare parts, and no one's told us how to proceed."
In practice this means frontline staff are creating workarounds. A clinician's workaround is a patient-safety risk and a signal that SOPs, inventory control, or supplier management has failed. Those phone calls are often the first reliable quality signal you get.
Recalls and field safety corrective actions — the visible tip
Recalls, FSNs and device advisories are the highly visible end of a downward slope. Users notice three things quickly:
- Timeliness: they expect rapid, clear guidance. A delayed or vague field safety notice amplifies frustration.
- Practicality: they need immediate, actionable steps ("stop using" is only helpful if an alternative is provided).
- Traceability: they want to know which lots/devices are affected; if your distribution records can't produce that list quickly, users feel abandoned.
If your PMS plan (per MDR Annex III and your post-market surveillance obligations under Article 10) doesn't connect complaint intake to CAPA and distribution records, your ability to support users during a recall is compromised. Granted, running a recall well is a heavy lift — but running it badly costs trust.
Guidance gaps: when the IFU doesn't help
Users open an IFU expecting a map to safe use. When the IFU fails, you see:
- Clinicians improvising: they skip steps they consider irrelevant or impossible in context.
- Increased support calls: helpdesks get flooded with questions your usability file should have answered.
- Informal local SOPs: hospitals document their own "how we use X device safely" — those local procedures then diverge from your Technical File.
This is why usability engineering must be treated as design control, not compliance overhead (see MDR Annex I and IEC 62366). If your usability file is out of sync with training and the IFU, users will default to local practices. So ist das halt.
Broken SOPs and internal processes — what users see externally
Users don't see your CAPA board, but they see its effects:
- Inconsistent service: one engineer replaces a part one way, another uses a different method because "that's how we were trained."
- Slow fixes: repeated breakdowns because the root cause analysis never completed.
- Conflicting advice: different support reps give different instructions.
Those are symptoms of poor change control and ineffective CAPA. If your eQMS doesn't link CAPA to change impact analysis and the controlled documents that change, the right hand won't know what the left hand has approved. Automated CAPAs and connected workflow can make the signal visible and reviewable — to be clear, it's assistance, not a miracle cure.
Documentation vs reality — the credibility gap
I've sat in audits where the Technical File and the workshop looked like two different products. Users notice inconsistency quickly:
- Packaging lists a component that's not in the box.
- Software screenshots in the IFU differ from the UI they see.
- Service manuals refer to spare parts that weren't ordered.
Per MDR Annex II, your technical documentation must reflect the device as placed on the market. If it doesn't, users will lose trust, and your notified body will rightly ask for corrective action. In practice this means regular system-level verification: simulate an end-user interaction, follow the IFU, run a service case from complaint to closure.
Downstream effects on clinical practice and PMCF/PSUR
When quality drifts, clinical practice adapts — and your PMCF data shifts with it. Workarounds obscure the true performance profile of your device, making PSURs and PMCF analysis harder. You might conclude a risk is lower than it is because users mitigated it with an undocumented workaround. That undermines the integrity of your post-market surveillance (per MDR requirements) and complicates future risk management decisions.
Practical things we do (that actually help)
From field experience, these are the interventions that buy you time and credibility:
- Link complaint intake to distribution records immediately, so you can target advisories accurately.
- Run "follow the process" exercises: a quality person follows an IFU in situ and reports gaps.
- Make change control visible to engineering and service — change impact analysis should be a required field on every change request.
- Treat usability and training as living documents; schedule them in your document-control system, not as one-off artefacts.
- Close the CAPA loop with documented verification; "we fixed it" needs a check that the fix works in the field.
Connected workflow and traceability are not marketing buzzwords here — they let the engineer creating a change see which IFUs, SOPs, and parts lists will be impacted. Automated CAPAs can reduce turnaround on paperwork, but they must be controlled and reviewable.
Final note
Quality failures show up first as friction for users: missing guidance, inconsistent service, and improvisation. Regulators see the paperwork; users live the consequences. If your next audit is months away, start from the user problems rather than the checklist — follow a user call to its root cause. You'll find the real gaps quickly.
What's the single user complaint your team gets most often, and how would you trace it back through your CAPA/change workflow?
Top comments (0)