DEV Community

James Whitfield
James Whitfield

Posted on

The missing link: quality events lose their risk rationale before effectiveness review

Last year, a labeling discrepancy reached our final effectiveness review with what looked like a complete record.

The event involved two versions of a label being used during finished-unit release. We contained the affected units, corrected the labeling, strengthened the verification instruction, and retrained the personnel involved. The actions were reasonable. The independent reviewer asked a different question:

“Show me where the original assessment recorded why this event did not introduce a new hazard or alter the intended use.”

That rationale existed. It just was not connected to the final review in a way a reviewer could follow without reconstructing several separate records.

The correction had not disappeared. Neither had the training or effectiveness data. What disappeared was the evidence chain connecting the original event to the final conclusion.

The part I now think gets lost most often

A quality event should not automatically become a CAPA. The preliminary assessment needs to determine whether the event requires correction, investigation, escalation, regulatory evaluation, or formal corrective action. That decision can change as information emerges.

The weak point for me is not the final effectiveness check itself. It is the connective rationale between these stages:

  • The original event description, scope, and source
  • The preliminary severity and risk assessment
  • The reason for escalating—or not escalating—the event
  • The relationship between the investigation findings and existing risk controls
  • The rationale connecting the corrective action to the identified cause
  • The evidence that the action was implemented and produced the expected result

Each of those records may be adequate on its own. Together, they can still tell a different story.

In my experience, this happens most often when a reviewer receives a polished closure summary without direct traceability to the underlying evidence. A summary can explain what happened, but it can conceal the fact that the original risk decision, root-cause analysis, and action rationale were never formally connected.

That is a traceability problem, not merely a writing problem.

What the standard actually requires

ISO 13485:2016 clause 8.5.2 requires corrective action to eliminate causes of nonconformities and prevent recurrence. It also requires the effectiveness of corrective actions to be reviewed.

The standard does not prescribe a particular form, workflow, or number of required documents. That flexibility is useful, but it means the organization must design a defensible connection between the event and its closure.

Clause 8.4 adds the expectation that data are analyzed for indications of nonconformity or other adverse trends. Clause 4.2.5 requires control of records so evidence of conformity is maintained, legible, and readily retrievable. “Readily retrievable” should not mean that an experienced reviewer knows where three people keep them.

ISO 14971:2019 is also relevant when an event provides production or post-production information. The event should feed back into the risk management process rather than remain isolated from it. For electronic records and signatures, 21 CFR Part 11 may add further requirements, although it does not define the CAPA process for us.

The standards do not say that every event needs a CAPA. They do make it difficult to defend a closure when nobody can show why the event entered the process, how its risk was assessed, or how the chosen action addressed the cause.

What we changed after the labeling event

Our first response was to improve the final summary. We created a cleaner one-page closure narrative with consistent headings.

That made the package easier to read, but it did not solve the problem. In fact, it made missing evidence easier to hide. A strong narrative can imply that a connection exists when the underlying process never documented it.

We replaced the summary-first approach with an evidence map. For each formal corrective action, the record now needs to answer five questions:

  1. What exactly was received, and what was the event’s initial scope?
  2. What did the preliminary assessment conclude, and why?
  3. What evidence supports the stated cause?
  4. How does the action address that cause rather than only the immediate symptom?
  5. What specific evidence supports implementation and effectiveness?

The map points back to controlled source records instead of copying their full content. That preserves the original wording, dates, and approvals while making the relationship visible.

We also separated two questions that had started to blur together:

  • Implementation verification: Was the approved action actually completed?
  • Effectiveness verification: Did the action produce the intended control or prevent recurrence?

A training session being completed proves implementation. It does not, by itself, prove effectiveness.

For effectiveness, the review now defines the expected change before judging the result. Depending on the action, that may involve audit performance, observed process adherence, recurrence data, or a combination. We also document the limitations of the evidence. For lower-frequency events, “no recurrence observed” may provide weak assurance simply because the review period or sample was not capable of detecting recurrence.

The effectiveness reviewer should also be someone other than the person who implemented the action. Independence does not mean starting from scratch; it means asking whether the evidence actually supports the claim.

What I would do differently from the start

If I were designing this workflow again, I would capture an event baseline at intake and preserve it throughout the investigation. That baseline would include:

  • The original report, not only the later summary
  • Product, configuration, lot, or serial information
  • The initial impact assessment and decision rationale
  • Any immediate containment
  • Links to relevant risk controls
  • The reason for changing scope or escalating the event

I would not wait until closure to reconstruct that context. By then, the investigator knows what happened, and the reader may not.

I would also require an explicit statement when a conclusion remains uncertain. “Insufficient evidence to establish recurrence” is more reviewable than silently implying confidence. Regulators and notified bodies generally respond better to a clearly bounded uncertainty than to a polished claim unsupported by the record.

The change I value most is simple: treat the event-to-effectiveness connection as evidence that must be built, not context that reviewers are expected to remember.

In your quality-event process, which piece of evidence most often becomes difficult to reconstruct by the time someone reviews effectiveness?

Top comments (0)