Corrective Action for a scenario where Assignable Cause is not confirmed

[v9991]

by definition,
* CA is ensuring/ arresting the recurrence of problem or root-cause ( process of reacting to product problems, customer
complaints or other non-conformities and fixing them)
* PA is about ensuring other 'potential' recurrence of problems/root-cause. (detecting potential problems or nonconformance's and eliminating
them)

now how to handle CAPA in a scenario where root-cause is NOT- established/assignable.

 

[Pancho]

Re: Corrective Action for a scenario where assignable cause is not confirmed.

Here's my take: Corrective and preventive actions are improvements (desirable modifications) to a process. And vice versa - improvements to a process are CA or PA, whether or not they were done formally (through the CAPA procedure). Conversely, if an action doesn't modify a process then it is not corrective nor preventive. I wish this was clear in the standard. It would eliminate a lot of the confusion.

If a NC exists, then there is a root cause. If the root cause hasn't been established, then dig deeper using one or several problem solving methodologies. Once you've established the root cause, then it may be such that you really can't modify your process to eliminate it, perhaps because it would be too expensive or because no one in your team can think of a way of modifying the process. In that case, you may have to live with inspecting the recurring NCs out of the product. But that, itself, can be your CA, as the healing inspections become part of your process and thereby it is modified for the better.

If no NC exists, and you can't establish a root cause for the first occurrence of a potential NC, then maybe you don't need to take preventive action. That means that you wouldn't modify your process.

 

[PaulJSmith]

Re: Corrective Action for a scenario where assignable cause is not confirmed.

If there is indeed a nonconformance, then there is indeed also a root cause of that nonconformance. Something had to cause it. Just because you haven't yet discovered it doesn't mean it doesn't exist. As Pancho noted, you just need to dig deeper, or maybe in a different direction, until you find it. Not until that point can you turn to the task of developing a corrective action for it.

 

[Sidney Vianna]

now how to handle CAPA in a scenario where root-cause is NOT- established/assignable.

If you can't pinpoint the actual cause, you end up with potential cause(s). You then institute preventive action(s) in such preventive cause(s) and the end result should be the same: no repeat NC's.

 

[v9991]

Re: Corrective Action for a scenario where assignable cause is not confirmed.

Here's my take: Corrective and preventive actions are improvements (desirable modifications) to a process. And vice versa - improvements to a process are CA or PA, whether or not they were done formally (through the CAPA procedure). Conversely, if an action doesn't modify a process then it is not corrective nor preventive. I wish this was clear in the standard. It would eliminate a lot of the confusion.

if you meant the product-process-step, .... there are instances where the process (not the product-itself, but the activity, (business-process-step )might have slipped. (relevant more so, from perpsective of a regulated environment perspective, and also from compliance to standard (s))

If a NC exists, then there is a root cause. If the root cause hasn't been established, then dig deeper using one or several problem solving methodologies. Once you've established the root cause, then it may be such that you really can't modify your process to eliminate it, perhaps because it would be too expensive or because no one in your team can think of a way of modifying the process. In that case, you may have to live with inspecting the recurring NCs out of the product. But that, itself, can be your CA, as the healing inspections become part of your process and thereby it is modified for the better.

If you can't pinpoint the actual cause, you end up with potential cause(s). You then institute preventive action(s) in such preventive cause(s) and the end result should be the same: no repeat NC's.

True, if we dig deep, we will eventually figure out the cause; however,
the time-effort spent for such instance where the root-cause might not be always relevant-pertinent to be established,; viz., even in software, there are bugs which are difficult to reproduce.! ref. another example!
"

Solutions can be re-injected as part of an investigation where a transient equipment malfunction is suspected. Such hypotheses are difficult to prove. However, reinjections can provide strong evidence that the problem should be attributed to the instrument, rather than the sample or its preparation.

"

Investigating Out-of-Specification (OOS) Test Results for Pharmaceutical Production

If no NC exists, and you can't establish a root cause for the first occurrence of a potential NC, then maybe you don't need to take preventive action. That means that you wouldn't modify your process.

i personally feel, that there is an opportunity to see PA as a sub section of continual improvement. ( CI intended to provide positive benefit, and when we see PA as an extension of CI, which eliminates the negative impact of the process.!