Customer Complaint leading to Corrective Action vs. Change Request

[Hrobot]

Hi,

If a customer complaints about a non-conforming device, should I then assign a Corrective action to fix this problem or should I raise a change request? The device is a software and at the moment any problems detected by the customer, we will record in a customer feedback form, raise a CAPA, then raise a change note which I dont think should be the right process. When does an action on a device considered a change and when is it considered a corrective action? It seems that CAPA and change control runs parallel to each other, please correct me if I'm wrong.

Thanks for your feedback
hrobot

[Miner]

You can split hairs on this topic all day, but ultimately you should do what works and is effective.

The purpose of a formal corrective action is typically twofold. First to drive the actual corrective action to solve an issue. Second, it maintains a record of the issue and the actions taken to resolve it.

Many formal corrective action processes assume that the solution is not obvious and the corrective action process leads you through discovery of root cause, etc. When the solution is obvious and requires a formal change, the change process is a viable alternative.

IMO you can go either route as long as your procedure clearly provides for this option, and as long as your customers do not require the CAPA.

[Ajit Basrur]

In this scenario, I would prefer to have a Corrective Action first and would link the Change Proposal as a Preventive Action.

Again, as referred by Miner, the choice is yours and what your SOPs say

[Jennifer Kirley]

Welcome to The Cove!

The purpose of a corrective action is to correct the problem's cause so it will not repeat and cause a burden.

If a different item is made every single time, and a unique process is used for each, a change request seems okay.

However, if a repeated process produces an undesirable outcome, the process should be addressed. A change request to change a document can be a part of it. If there was rewritten code in software to solve the customer's specific problem, I'd call it rework.

The same thing works for a widget. I am making marionettes (puppets) for customers. Each one is uniquely featured, but in one of them the strings are too short on one side. The marionette is lopsided. The puppet is returned. I rework the puppet by fixing the strings. That is rework. But it is also sensible to address the question of why one had short strings on one side. That is the corrective action. Once done, even though my marionettes are still going to be turned out unique in some way, they will all still have the desired fit and function.

I hope this helps!

[Mark R.]

This is going to depend on what your procedures require, but I would generate a corrective action to address the issue, and then a change order would be my action to prevent recurrence.

Hope this helps.

[madannc]

Originally Posted by Ajit Basrur

In this scenario, I would prefer to have a Corrective Action first and would link the Change Proposal as a Preventive Action.

Again, as referred by Miner, the choice is yours and what your SOPs say

MHO is rasie a CA, where it documents what's happened, a correction has been put in place (immediate fix), an investigation has identified route cause, and a CA (not PA, as this has occurred) has been put in place to prevent recurrence.

As mentioned the CA process is just that a process for addressing failings in products/systems. Part of the CA in all likely hood will involve Change Control.

You may want to perform an impact assessment as part of the CA as the feeder was a customer Complaint e.g.

Severity - What is the worst that will happen to users with this fault

Detectability - how easy to find this failing (bearing in mind it has already reched the customer you may well as part of your CA want to put something in place to detect this prior to release)

Occurrence - has this happened before (or similar) trending on previous complaints/CA's etc

This may well have been done by your complaints dept and could be included as part of your investigation.

[Hrobot]

Thank you all for the usefull suggestions. Part of the reason I was asking is to find a process which suits our small sized start up company. The same person who raises the customer feedback form will investigate it, raise a corrective action based on the investigation and raise a change order to correct the issue. It just seems to be too much processes when the problem have been identified right form the start when he investigates the complaint.

e.g A customer identifies that the image on the screen is not matching the real item it is tryong to visualize. so we need to fix the bug in the software.
This will need a change request.not a CA

e.g. A non conforming product requires a part replacement because the old part did not pass electrical safety testing. This will need a change request.not a CA

e.g. A supplier provides faulty components. Raise a non conformance. If this occurs again(there is a trend) raise a CA to evaluate supplier.

Our change control process would include review from various functions while the CAPA system only reports and assigns a task. Tha is why I am in favour of change over CAPA. But ISO 13485 seems to place CAPA process above others.

Thanks for your input.

[madannc]

Originally Posted by Hrobot

It just seems to be too much processes when the problem have been identified right form the start when he investigates the complaint.

e.g A customer identifies that the image on the screen is not matching the real item it is tryong to visualize. so we need to fix the bug in the software.
This will need a change request.not a CA

e.g. A non conforming product requires a part replacement because the old part did not pass electrical safety testing. This will need a change request.not a CA

e.g. A supplier provides faulty components. Raise a non conformance. If this occurs again(there is a trend) raise a CA to evaluate supplier.

Our change control process would include review from various functions while the CAPA system only reports and assigns a task. Tha is why I am in favour of change over CAPA. But ISO 13485 seems to place CAPA process above others.

Thanks for your input.

You are right the problem has been identified, however the CA would help provide the solution, the change only implements the solution.

I am curious, in the change request that you would use to implement the solution does it require a rational as to why the change is being implemented.... as an approver if I saw replace this code with that code or part failed safety testing I would also want to see if the problem had been investigated and why implementing the change will prevent recurrence, in the examples you quoted this would be part of the CA so I could see that this had happened, if you did not go through CA process where would the investigation (the foundation for the solution) be? do you do this as part of the ECR/ECO?

It is relatively easy to implement a correction (correct the issue) but without additional supporting work not easy to prevent it from happening again.