Documentation for correction, corrective action, mini CAPA

[psp1234]

Hi,
Correction is an action to eliminate a detected nonconformity; Corrective action is an action to eliminate the root cause. I get that. I think
Is there a "mini corrective action" situation?

example (of a frequent occurrence):
A customer required a CAPA for a part that was found non-conforming. Let's say a screw in the assembly was missing (no risk to a patient, no safety issues etc.). We would do a containment (check warehouse, WIP etc...), get the part back and install the missing screw (correction) , we would also investigate the possible cause (maybe there wasn't a checklist to verify the count of screws to install), for the purpose of this example, the corrective action would be to "create a checklist to verify the count of screws etc." and of course the customer would expect verification of effectiveness. All "elements of corrective actions" are there, But - this corrective action is limited to a specific product and not really looking at possible similar issues in other products (and also the root cause efforts are minimal).
Customers typically are OK with that approach, but I had an auditor commenting about the "narrow" approach.

I do understand that other products may benefit from the same action etc., but it will be an extreme effort to think and implement this line of thinking (even though it sounds good).

In situations where a risk is identified or compliance risk is identified, the corrective action needs to be broad, that is a valid expectation.

Do any of you have experience addressing that? a "mini CA"...or "local CA"... it kind of not aligned with the essence of a CA, but very useful, considering risk vs. efforts. Would something be different in the documentation for it? like a "corrective action" with different levels and added requirements for the "BIG CA"?

Happy to hear other thoughts,
Thanks
Sue

 

[kellylisa]

HI PSP1234

"the corrective action would be to "create a checklist to verify the count of screws etc."

I believe that this is your Preventative Action, rather than your Corrective Action. the corrective is that you have replaced the component and you found during your Root Cause Analysis that it happened due to the lack of a checklist - therefore your checklist is preventing this from happening again in the future.

I think ultimately it is up to you to decide whether you would implement this change elsewhere, and you would have to identify and address where it was/was not necessary (pro's/con's/risks v likelihood etc) and it may be justifiable for you NOT to do this for all products....you just have to make sure that you document it, or it could get pulled up during an audit as having been unnoticed/ignored.
Something along the lines of stating that the risk to product conformity, usability, quality, patient etc is low; no other reports of this nature have been received; will be kept on file for trending and monitoring - then set yourself a 'deadline' to review it in the future during your CAPA reviews along the line and just check that the response is still adequate

hope this makes sense?

 

[AMIT BALLAL]

HI PSP1234

"the corrective action would be to "create a checklist to verify the count of screws etc."

I believe that this is your Preventative Action, rather than your Corrective Action. the corrective is that you have replaced the component and you found during your Root Cause Analysis that it happened due to the lack of a checklist - therefore your checklist is preventing this from happening again in the future.

I think ultimately it is up to you to decide whether you would implement this change elsewhere, and you would have to identify and address where it was/was not necessary (pro's/con's/risks v likelihood etc) and it may be justifiable for you NOT to do this for all products....you just have to make sure that you document it, or it could get pulled up during an audit as having been unnoticed/ignored.
Something along the lines of stating that the risk to product conformity, usability, quality, patient etc is low; no other reports of this nature have been received; will be kept on file for trending and monitoring - then set yourself a 'deadline' to review it in the future during your CAPA reviews along the line and just check that the response is still adequate

hope this makes sense?

Thanks for your reply Kellylisa. But I beg to differ.
Once a problem is occurred, there cannot be any preventive action. Whether it is action against root cause related to occurrence, detection or system, all will become corrective actions since the problem has already occurred and we are trying to prevent recurrence.

psp1234, the purpose of horizontal deployment of corrective actions is to deploy same actions in similar product / process/ systems so that same problem can be prevented there. I understand horizontal deployment cannot be done immediately and will take time, but tracking its implementation and review will help. Develop an approach which helps horizontal deployment easy and practical to your organization in place of skipping it.

 

[qualprod]

The standards says:

In one side
Corrective actions shall be appropriate to the effects of the nonconformities encountered.

So, it is not necessary to do a full analysis for every nonconformance.

For minor ncs, do a simple correction and turn the page.

But if you client asks you a CA with verification of effectiveness, well you have to hear him, even is minor.

Even in this mini CA´s is possible to spread the benefits ti other areas, according tho the standard in 10.2.1, b3

3) determining if similar nonconformities exist, or could potentially occur;

Hope this helps


Why you say mini, because doesn´t cver other nc´s

 

[normzone]

Going down this very road myself at this moment, modifying some outdated process documentation and while I'm at it allowing us to take correction only with analysis of risk when appropriate.

9001:2015 references risk and opportunity, and notes productivity as an opportunity. It's not productive to do a full blown fishbone / 8D / 5 why for all issues when it's neither appropriate or necessary.

Sticking my neck out, two brand new external auditors in the house next week, we'll see how they feel about it.

 

[psp1234]

Hi normzone,
Although I am in the 13485, your audit results will be predictive enough...please do tell if the auditors accepted that approach!

Thanks,
Sue

 

[RoxaneB]

Going down this very road myself at this moment, modifying some outdated process documentation and while I'm at it allowing us to take correction only with analysis of risk when appropriate.

9001:2015 references risk and opportunity, and notes productivity as an opportunity. It's not productive to do a full blown fishbone / 8D / 5 why for all issues when it's neither appropriate or necessary.

Sticking my neck out, two brand new external auditors in the house next week, we'll see how they feel about it.

I have shared several times about a similar approach we employed in my "previous life."

To enable a consistent approach, we developed a document that identified areas and categories of known nonconformances. We identified the situations that would fall into "buckets" of 'Monitor/Track', 'Correction', 'Corrective Action.'

For example, a customer complaint under $X and associated with Product 1, 2, or 6 would fall under Correction. If there was a customer complain for Product 1,2, or 6 and > $X, then it was Corrective Action. There was no Monitoring/Tracking.

For process downtime <X, it was Monitored/Tracked. For process downtime >X but <Y, Correction. For downtime >Y, Corrective Action.

Our values were not arbitrary or selected based on a whim. We used historical data that allowed us to typically focus on 20% of our nonconformances, with this 20% typically being those situations of a more serious nature or larger magnitude.

Every year, as part of our larger management review, an analysis was conducted to determine if the triggers to determine what when into each bucked needed to be tightened. Triggers were never - from my recollection - loosened. That is to say, a corrective action for downtime might occur for all downtime > 2 hours this year. Next year, it could be > 1.5 hours, but it will not be increased to > 2.5 hours, because we are trying to stabilize our processes, not accept more variation.

This approach was not only accepted by our external auditors - ISO 9001, ISO 14001, ISRS - it was embraced by our employees, because it showed we made the standards work for us; we did not bend to fit the standards.

 

[Ninja]

FWIW...and not disagreeing with any of the above (save for trying to prevent what already happened)...

When the error (nonconformance) has already touched the customer, and then back as a complaint, to then include return, rework and re-shipment...I don't see anything "mini" going on.
It may be a simple error, and a simple solution, but there are four separate items here, any one of which would have triggered my CA system.

1. Screw missing yet part approved (approval of NC part)
2. defective (nonconforming) product shipped (quality spill)
3. customer complaint
4. Return of product

I would put it through the CA system...but handle the CA as Roxanne described, based on risk/reward. It is not required that you do it that way...that's just what I would do.

 

[qualprod]

I fully agree with Ninja´s comments

Things have to be managed in a simple way.
I have tried as RoxaneB, suggested and was not as expected as we wanted, the main
problem was was the classification of the Nc´s. It was hard to people to have a full knowledge regarding where the nc fell, there were a lot of confusion for the classification, and frequently there were mistakes, because nc´s were classified in the wrong way.

Maybe there was something missing to be implemented, but that was my experience.

We changed to use a simple common sense to decide what to do, and now works better.

Hope this helps

 

[psp1234]

I fully agree with Ninja´s comments

Things have to be managed in a simple way.
I have tried as RoxaneB, suggested and was not as expected as we wanted, the main
problem was was the classification of the Nc´s. It was hard to people to have a full knowledge regarding where the nc fell, there were a lot of confusion for the classification, and frequently there were mistakes, because nc´s were classified in the wrong way.

Maybe there was something missing to be implemented, but that was my experience.

We changed to use a simple common sense to decide what to do, and now works better.

Hope this helps

Hi Qualprod,
Can you share what you ended up doing?
I am curious and eager to find a simple solution.

Thanks
Sue