Last month, a buyer pinged me: "Why is this incoming-inspection NCR asking me whether the customer filed a complaint?" Fair question. It's because we'd been using the same issue form for every non-conformance, deviation, and complaint that landed in our QMS — and the form was getting worse at all three.
We run a contract manufacturing shop in Bangalore. Components for three global medtech OEMs, about 42 active suppliers of our own (raw materials, sub-assemblies, packaging), and somewhere between 800 and 1,100 supplier COAs a quarter depending on the order book. Our internal QMS is small: two QA people, one RA, plus me wearing multiple hats. So the temptation to "just use one form" is enormous. We gave in. Here's what broke.
ISO 13485 quietly expects them to be different
ISO 13485:2016 does not, strictly, force you to use three templates. But it draws clear lines that a generic form flattens:
- Clause 8.2.2 covers complaint handling as its own process, with its own recording, evaluation, and investigation steps
- Clause 8.3 covers nonconforming product and expects you to identify the affected product, segregate it, and decide on disposition
- Internal process deviations (often sitting under 8.5.6 — validation, and the change-control side of 8.5.6) want a different evidence trail: process parameters, operator, equipment, time of occurrence
When you collapse those into one form, you end up with fields that are meaningless for half the records and mandatory-but-forgotten for the other half. The data starts to rot. Our notified body noticed in the last audit — politely.
The specific friction at a CMO
A supplier-side NCR for an incoming stainless-steel bracket needs:
- Supplier heat/lot number and the COA we received against that lot
- Receiving inspection record (method, sample size, accept/reject criteria)
- Disposition: rework, scrap, use-as-is with concession
- The supplier CAPA trigger and who owns it
It does not need "patient harm indicator" or "complaint source."
An internal process deviation from CNC turning needs:
- The work order, operator, machine, and parameter sheet
- Post-deviation first-article inspection
- Link back to the validated process and any process change ticket
- Engineering sign-off on the containment
It does not need "supplier batch number" or an EU MDR Article 87 reportability flag.
A customer complaint — which for us always comes in from one of our OEM customers about a component we made — needs:
- The OEM's complaint reference, traced down to our internal lot
- A check against MDR reporting timelines (Article 87 for serious incidents)
- A root-cause methodology and a controlled CAPA workflow
- An audit trail of every interaction back to the original reporter
Stuffing all of these into one form gave us an average of nine fields per record that were always blank, two fields that everyone forgot to fill because they only mattered for one record type, and an audit-prep ritual where we'd export to Excel and re-bucket the data just to look at it in a meeting.
What we changed
We split the issue types into three configurable templates. Each one now has:
- A short header the operations team can scan in two seconds — record type, source, affected lot/PO/WO
- The data fields that belong to that issue type, and nothing else
- A mandatory linkage to the parent lot, work order, or supplier
- A disposition step that's relevant to the actual workflow (NCRs go to MRB; deviations go back to engineering; complaints go to the OEM-relationship owner)
- A different SLA and escalation rule
I'll be honest — it wasn't elegant. We did it with a psql schema for the templates, a thin Python middleware to validate inbound records, and about six hours of back-and-forth with the people who'd actually fill these in. The first iteration was over-engineered. The third was the one we kept.
On tooling
If you want a quick walk-through of how a modern eQMS handles per-issue-type schemas, this video is a reasonable watch:
[youtube link]
For the device-maker and SaMD teams we share an industry with, configurable per-type templates are genuinely useful and reduce the audit-prep ritual enormously. For us at the CMO, where many of the records originate at the supplier and we don't control upstream forms, it's about half-useful. We still have to coax suppliers into our schema through the COA. Tools with open API and webhook access (qmsWrapper, for instance, publishes event streams on issue state changes) make that integration tractable; closed-schema tools don't.
I work on qmsWrapper — this is my honest read of where it fits and where it doesn't, especially from a CMO's supplier-quality seat.
Takeaways
Three templates cost us less to build and maintain than one. We didn't need new software or a 40-page procedure. We needed to admit that "issue" was a useless word to a buyer, a CNC operator, and a regulatory lead — and that the fields each one was being asked to fill were, for them, mostly noise.
One small request to anyone reading this: if you've gone the other way and stuck with a single form and made it work somehow, I'd genuinely like to hear what your secret was. And if you split templates — which field did you end up adding or removing in month three that you wish you'd gotten right in week one?
Top comments (0)