Field Complaint to Design Change: A CAPA Loop

The question an audit can’t quite answer

Most of what matters about a contract manufacturer can be checked. You can verify the certificates, walk the lines, read the SOPs. The harder question is what the factory actually does when something goes wrong in the field. Every quality manual has a CAPA procedure. Whether it runs as written only shows on the day a complaint comes in.

So instead of describing our procedure, here’s one real event from our factory, anonymized. Category details, customer, and model stay confidential. The decision chain is exactly as it happened.

One unit, or a population?

The report came in from the field: a home-use electronic device showed scorch marks on its base. One unit, one complaint.

The cheapest response would’ve been to treat it as an isolated case. Apologize, replace, close the ticket. Our intake rule points the other way: a single complaint gets handled as a potential lot problem until the data says otherwise. So the first question wasn’t how to make this customer whole. It was whether we were looking at one unit or a population.

A second rule kicks in just as early: no softening the picture. The people who decide, on our side and the customer’s, hear the facts first. And when a quality event touches a customer’s medical device quality system, it escalates to their QA right away and runs jointly from there. Bad news doesn’t get better with time. Waiting just burns the window when containment is still cheap.

Following the why chain past the symptom

The scorched part was the base, so the tempting fix was a new base. That’s a repair, not an answer. Working the why chain, the damage traced upward. The base hadn’t burned on its own; the heat came from the USB Type-C connector above it, which had overheated and melted into the base material. The connector was the cause. The base just took the damage.

Stop at the base and you’re replacing bases indefinitely while the real failure keeps firing. Root cause analysis exists to break that loop: keep asking why until the answer is something you can redesign. A part you can swap doesn’t count as an answer yet.

The design change

The correction went into the design itself. We issued an ECN that moved the connector from a 26-pin part to a simplified 6-pin design, and added current-detection protection so the device cuts power on an abnormal draw before heat can build. The first change takes complexity out of the part that failed. The second assumes something may still go wrong someday and puts a guard in front of it.

The step that usually gets skipped

Fixing one product doesn’t mean the product line is clear. After the ECN, we checked every other model on the same platform for the same weakness, one by one. One sibling model had used a 6-pin design from the start; we confirmed it was unaffected and documented that too. “Confirmed clear” is worth writing down.

In our experience this step, horizontal deployment, is the one most often missing from CAPA files. The failure gets fixed where it showed up, and the same weakness sits untouched in every sibling product. When you audit a supplier, this is the seam to press on. Ask to see a real CAPA and look for the horizontal deployment record. Our factory audit checklist has it on the list.

Traceability turns panic into arithmetic

The remaining question was scope: how many units, and where. Because ISO 13485 requires lot traceability, the records could tell us exactly which production lots contained the old connector and how many units each held. We won’t publish the figures here, and honestly they’re beside the point. What matters is that the question had an answer. Without lot traceability, containment defaults to the worst case, where everything in the market is potentially affected. With it, the incident became bounded and countable. What the standard requires in practice is covered in our ISO 13485 guide.

Every SOP is a patch

The principle behind all of this, in the words we use internally: every SOP is a patch from an incident. A quality system that’s just a stack of documents written to pass audits doesn’t help anyone. When it works, it’s closer to scar tissue. Lessons get cut into procedure so the next person doesn’t have to relearn them the hard way. So closing an event takes more than “is it solved.” We also ask whether the same thing can still happen the same way. An event closes when the preventive mechanism is inside the system, so the next similar signal meets a different process than the last one did.

Generalized, the loop runs: intake, containment, root cause (5-Why), correction, prevention, horizontal deployment, closure review. Nothing on that list is exotic. The difference between factories is whether the loop still runs when running it costs something.

Production, R&D, and quality assurance have shared one site in Daya, Taichung since 1996, certified to ISO 13485:2016 and ISO 9001:2015. That’s part of why root-cause work moves fast here: the engineer, the line, and the records are all in one building. If you’d like to judge for yourself, send an inquiry and ask us to walk your team through a CAPA end to end, under NDA. You’ll have an initial response within two business days.

FAQ

What should a complete CAPA record contain?

At minimum: the intake decision and risk assessment, containment actions, a root cause backed by evidence rather than the first failed part someone found, the corrective change with its ECN, horizontal deployment across sibling products, and verification that the fix actually works. A file with a cause and a correction but no horizontal deployment is a common gap, and a telling one.

How do I check a supplier’s CAPA process before placing an order?

Ask them to walk you through one real, anonymized case end to end. Listen for three things: whether the root cause lands at design level or stops at a swapped part, whether sibling products were checked, and whether lot traceability bounded the affected population. A factory that has actually run the loop can narrate it without preparation.

What’s the difference between a correction and a corrective action?

A correction deals with the affected units: replacing a scorched base. A corrective action removes the cause: changing the connector design so bases stop scorching. A complaint file that only contains corrections is just a repair log.