When finishing a task is itself a quality event
A supplier clicks "shipped" in our supplier portal, and a quality record opens on my desk without anyone touching a form. That stopped sounding like marketing about eighteen months ago, when our CAPA backlog quietly halved and I could finally explain why.
At a contract manufacturer with three global medtech OEMs and forty-plus suppliers of our own, quality events used to live in two separate worlds. People did their actual work — booked inspections, released lots, signed off documents — and then, separately, somebody had to remember to log it. The two worlds were held together by goodwill and a laminated reminder above the inspection station.
The friction nobody admits on paper
If you have ever run a QMS in a plant, you know the pattern. A dimension goes out of spec on a CMM. The operator calls the supervisor. The supervisor makes a call. Somewhere, if you are lucky, a paper NCR gets opened the same shift. If you are not lucky, the NCR opens on Friday afternoon, written from memory, two days after the event.
ISO 13485:2016 §8.3 does not care when you write the NCR down, only that you do. But auditors do care, because the gap between "event happened" and "record exists" is where investigations get shallow. We were not bad at this. We were human at this.
What I noticed across QA, manufacturing, and the supplier-quality desk was that quality events were not rare — they were simply under-recorded. Every shop floor has hundreds of micro-decisions a week that could be quality events. Almost none of them became ones, because filling out the form required context-switching away from the work in front of you.
What auto-triggering actually changes
Auto-triggered QMS events work the other way around. Instead of asking the operator to stop and classify, you let the system observe the outcome of normal workflow tasks and react:
- An incoming inspection marked "fail" on a critical characteristic opens an NCR record automatically, pre-populated with the lot, supplier, part number, and the inspection record it came from.
- A document revision that goes through three approval cycles without resolution escalates and generates a quality event with the full approver trail attached.
- A supplier COA that fails a configured rule — out-of-range value, missing field, mismatched part number — flags the inbound record for QA review before the goods are received into stock.
The quality record is no longer something someone has to go and make. It is a side-effect of doing the work correctly, or incorrectly, in the workflow they were already using.
That subtlety matters for ISO 13485 §4.1.6 too. Once your workflow tool is creating quality records on its own, it is part of your QMS software, and you have to treat the rule that triggers the event like any other validated process. The first time an auditor asks "show me the validation evidence for this rule," you want an answer ready.
What I tried, and what I would do differently
We rolled this out in three slices: incoming inspection first, document control second, complaints last. Incoming inspection was the easy win — the inspection record already existed, the acceptance criteria already lived in a master file, and the failure path was unambiguous. Document control was harder, because "stuck in approval" is a fuzzier trigger than "out of spec on a dimension." We had to write more careful rules and accept that we would over-trigger at first.
Things I would handle differently next time:
- Start with a one-page rule catalogue. Write down every trigger, what it fires, and which ISO clause it satisfies. Future-you will need this during the audit, and so will your OEM customers.
- Decide upfront whether over-triggering is acceptable as a transitional state. We chose yes; some of our OEM contracts would not have.
- Treat the trigger rules as living documents under change control. The day you edit a rule in a hurry, without a CR, is the day you lose traceability on the very records the rule was supposed to create.
The thing nobody tells you about CAPA-driven risk assessment is that it becomes much sharper when the upstream events are complete. If every NCR has the actual supplier, the actual lot, and the actual inspection record linked, then the risk review at the CAPA stage is not archaeology. It is reading.
Where this leaves the human
The fear I hear from QA managers is that auto-triggering will bury them in noise. In practice the opposite happened for us, because every record that came through already had the context. I spent less time chasing missing fields and more time reading substance — reviewability improved because the trail was already there.
The fear I hear from operators is surveillance. That one I take more seriously. The point of workflow-integrated quality is not that every click is monitored. It is that the things that genuinely matter — a failed inspection, a stuck approval, a customer complaint — leave a trace without someone having to volunteer to write it down later.
If you are running a QMS where your CAPA queue keeps you up at night, the question I would ask is not "which tool." It is: which of your quality events are you still relying on someone to remember?
Top comments (0)