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

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.

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 :)

Welcome to The Cove! :bigwave:

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!

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.

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.

:2cents:

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. :)

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.

:)

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. :)

I'm not sure I understand your statement "Our change control process would include review from various functions while the CAPA system only reports and assigns a task." Don't CAs get looked at by affected functions? If not, this may pose a problem. I have always believed there should be ONE and ONLY one way to change a process, a product, or a document, and that would be your change control system. The CAPA process documents WHY the change is being done (when a corrective/preventive action is the reason for change) but having more than one change process can cause problems later when memories fade as to why something was done. Or if crucial stakeholders aren't consulted, etc.

Geoff Withnell

A change request sounds like a document that communicates the need for a change. That is useful in tracking what changes have been asked for, but does nothing for corrective action except to help understand (if the change requests are saved) what kind of changes were needed, why, and how often. It might be nice to know how often software is made with certain kinds of problems. The more critical those problems are, or the more often they occur, the more you would need corrective action.

I would argue that a component that fails a safety test does require corrective action so as to prevent more safety test failures.

I would also raise a CA request to the supplier of faulty components the first time. Wouldn't you want to know the first time a bunch of shipped product was failing during its use?

A change control process is usually for controlling changes to a process or process document. That can happen with or without a corrective action attached to the effort. Change control is usually more of a routine than CAPA.

ISO places importance of CAPA over change control because CAPA is about problem solving and improvements to prevent errors and flawed product/service.

In our company Change Request (we call it Discrepancy Report) directs a CORRECTION. That is fixing the specific bug in our SW product.

Please make a distinction between 'correction' and
CORRECTIVE ACTION which may or may not be started (based on Root Cause Analysis) to change the process (procedures, work instructions, forms) so that similar causes would not produce new similar bugs in future versions.

PREVENTIVE ACTION may be started if we notice e.g. statistically that some type of bug is repeating, or that we do continually fixes to same part of code.

In our company Change Request (we call it Discrepancy Report) directs a CORRECTION. That is fixing the specific bug in our SW product.

Please make a distinction between 'correction' and
CORRECTIVE ACTION which may or may not be started (based on Root Cause Analysis) to change the process (procedures, work instructions, forms) so that similar causes would not produce new similar bugs in future versions.

PREVENTIVE ACTION may be started if we notice e.g. statistically that some type of bug is repeating, or that we do continually fixes to same part of code.

Lifecycle of a non conformance (whether it be software problem, hardware problem, process problem)

Non conformance noted (all details available at time [when, where, who, what etc etc] recorded)

Correction put in place, immediate fix e.g. correct software installed, new part fitted etc etc

Investigation (including impact analysis - see earlier post) record finding of investigation and all data e.g. trend analysis, pareto, cause and effect etc etc

Root Cause identified from analysis - process not followed, training, process incomplete etc etc

CA proposed - Action that will prevent recurrence, process changed, training given, CCP (crittical control point) put in place, process introduced etc etc

CA Agreed - proposal reviewed along with investigation and findings by cross functional team

CA implemented - CA owner implements according to plan and by agreed date

Effectivity Check assigned - criteria put in place to check the CA has been effective, e.g. after 2 months check NC database for similar (do another trend) basically assign criteria for pass e.g. no further occurences = pass and time span required before check

As an easy example

The Quality Train 007 fails to stop at complianceville over shooting station by 300 metres on the 18 Feb 08 at 15:49 GMT

Correction - replace brakes on Quality Train 007

Investigation; shows that service of brakes is due every 12 months, 007 was serviced Aug 07 (approx 6 months ago), but investigation has shown that the Quality Train Fleet (if right word for a group of trains) has doubled its operation now running twice as much since Sept 07. Trending shows this is first occurence.

CA - Whole fleet of Quality Trains to have brakes serviced/replaced after 4 months. check reveals that 3 other Quality Trains will require replacements with this new regime. Implement change to PMM (Preventive Maintenance Manual) to change brakes after 4 months, update all schedules (10 trains affected 001 - 010). Implement change to operation of train schedules so if reduced or increased service requirements are considered - additional box to be added to request form that requires completion prior to agreement of change to operation.

Effectivity - Check after 4 months that schedule is being followed and no further instances of failed stopping has occurred.

Equally the investigation for this could have shown that there was a supplier change to save money on train brakes and the failure happened after this... I guess what I am saying is that only with thorough/good investigation can determine root cause and implement (via change) effective CA's

hope this clarifies a little

cheers Nigel :)

PREVENTIVE ACTION may be started if we notice e.g. statistically that some type of bug is repeating, or that we do continually fixes to same part of code.

Not sure if this is Preventive... IMHO PA is prevention of NC, here the bug has occurred therefore I would not see this as PA.

If you had not experienced a problem with a particular bug yet and discovered that a new piece of software for checking code will highlight and bugs or issues, the implementation of this would be PA, and also a potential cost saving in not having a peer do a code walk through... (after suitable V&V)... struggling a bit because software is not my area

Madannc's description of the lifecycle is very good for hardware. :applause:

But software is confusing... :confused:

Production of SW can be defined as just the replication of CD's. Hence all the work done before that is design process.

So even the smallest bug can not be corrected by fixing production or the one piece of product that was observed defect. It always needs design work. Errors in design work appear as bugs (and they appear in every copy). Bugs can be made less frequent by corrective actions in the process (add certain tests, peer reviews...).

Re preventive action: Each bug may have received the correction + corrective action treatment. However, statistics over a time may show that some type of bugs still appear too often in some certain area. Then, it is time for PA.

I admit, both of these this are areas where wastly different opinions exist. It is basically about level of abstraction you choose (and that you define in your procedures). The principles are in any case very much same.

Generally it is like with root cause analysis. We Quality Pros should always take one more step than a layman would, because our satisfaction comes from making the world a better place.

Re preventive action: Each bug may have received the correction + corrective action treatment. However, statistics over a time may show that some type of bugs still appear too often in some certain area. Then, it is time for PA.


This sounds like it is acceptable or expected to get a number of bugs when producing software and it is also expected that not all bugs will be discovered prior to release...

If statisically monitoring after release to prevent further occurence would this not be a CA?

Or am I reading it wrong and that post release you are finding to many bugs during smoke testing, verification or validation, in which case would it constitute a failure and the correction to the software be part of the project plan and be handled by "Design" NCR?

If a review of the design NCR's shows that a particular bug is recurring to often (suggesting there is an acceptable level?) the remedy of this would still be CA as it is preventing recurrence. However if monitoring an "acceptable" level and you see a trend approaching a breach of this, then putting something in place to prevent this breach would be a PA

To go back to the train example, if the failure was caused due to a software change that caused a delay in brakes being applied, the fix would still be a CA.

Thinking of a PA perhaps with vigilance you became aware of the problems your rival company was having with its brakes and although you have not experienced this issue implementing a review of current software that controls the braking system and subsequent changes would be a PA as this has not occurred and you are truly preventing occurence.

This sounds like it is acceptable or expected to get a number of bugs when producing software and it is also expected that not all bugs will be discovered prior to release...

Wery much so. You don't have much experience in SW, do you? A software which is more complicated than the traditional excercise of printing "Hello world!" will always have bugs, at least the users will use it in another way or another hardware than intended.

When the software has 100000 lines of code, handled data consists of a 3D model of human and the user can interactively adjust a hundred parameters, then "testing has more alternative paths than atoms in universe". We can not have more than statistical confidence that all bugs/risks are sufficiently controlled. We try hard to make it as good as possible but the fact remains that it needs to go out to customers with some remaining issues. Otherwise the customers would not have any tools to do their job as well. Users know it and accept the fact. You probably use standard office software? Don't you accept that it sometimes fails?

Happy to say that despite of some remaining bugs, our product is world #1 for the specific intended use. Both in numbers and in polled customer satisfaction.

I won't join the :argue: of terminology game. But let me reformulate: lets just try take one step deeper in the root cause, no matter how we call the objects and processes. And to make auditors and inspectors happy, lets document our words and processes as we use them.

Cheers
Raimo

You don't have much experience in SW, do you? A software which is more complicated than the traditional excercise of printing "Hello world!" will always have bugs, at least the users will use it in another way or another hardware than intended.

No I don't, but I am learning fast


When the software has 100000 lines of code, handled data consists of a 3D model of human and the user can interactively adjust a hundred parameters, then "testing has more alternative paths than atoms in universe". We can not have more than statistical confidence that all bugs/risks are sufficiently controlled. We try hard to make it as good as possible but the fact remains that it needs to go out to customers with some remaining issues. Otherwise the customers would not have any tools to do their job as well. Users know it and accept the fact. You probably use standard office software? Don't you accept that it sometimes fails?

Image aquisition is something I have a little experience of and 3D (and 4D) reconconstruction of 2D imaging using back projection, although not technically adept at coding I am aware of how these images can be used for treatment planning and the consequences of setting up a treatment plan incorrectly. When my PC freezes or crashes I may lose a report/spreadsheet that although inconvinient will not cause me any health issues. However if being treated for cancer using IGRT (Image Guided Radiation Therapy) and the plan is out non cancerous cells in my body are at risk. I understand that not all bugs are safety issues, but testing vigoursly for safety is a must.

Please note I am not suggesting that you do not perform risk analysis and have RCM's etc I am just trying to show that likening microsoft office to a medical device is not relevant.


Happy to say that despite of some remaining bugs, our product is world #1 for the specific intended use. Both in numbers and in polled customer satisfaction.

Congratulations, definately something to be proud of, is your product in Radiation therapy?

I won't join the :argue: of terminology game. But let me reformulate: lets just try take one step deeper in the root cause, no matter how we call the objects and processes. And to make auditors and inspectors happy, lets document our words and processes as we use them.

Nor would I expect it, I know that sometimes the regs can seem restrictive or archaic but they are there to protect users and patients, and I commend RCA not just for the regs but but for better/safer products.

:agree: :truce:

cheers Nigel

I won't join the :argue: of terminology game. But let me reformulate: lets just try take one step deeper in the root cause, no matter how we call the objects and processes. And to make auditors and inspectors happy, lets document our words and processes as we use them.With all due respect, if you are serving the medical community and have/will be registered to a standard like ISO 13485, it could behoove you to align with their terminology and requirements.

Structured Software Quality Management is pretty new in the QA disciplines, and I am not an expert so I will refer you to NASA (http://satc.gsfc.nasa.gov/assure/agbsec3.txt), MIT (http://acis.mit.edu/acis/sqap/sqap.r1.html), and the FDA (http://www.fda.gov/cdrh/comp/guidance/938.html).

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
A CAPA is not necessarily a change, especially in a software product. A CAPA can be closed after the bug is recorded , analysed and determined how and when to fix it. A change on the other hand would be issued when a new version is to be released, and it may address several bug fixes. So you may have many CAPAs that would all resolve into one change.
Depending on the iindustry,, most software companies won't even have a formal CAPA, they may use in lieu of it a bug tracker tool .New versions (changes) are typically marketing driven and may include functional changes as well. For a critical bug however, there may be need for an immediate new release and if such is the case the CHANGE and the CAPA are the same

:agree: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

Hai


No as per the ford System of problem solving .

The change request is a part of the G8D,and hence any non conformance or customer complaint or customer dissatisfaction .Should be handled with the G8D only.

Whatever you do, don't lose documented traces of both:
1) the correction (intended to get the immediate issue with the PRODUCT straightened at the customer)
2) the corrective action (to chance or fix the PROCESS that produced the issue)

Yes, Jennifer, you are right. One can explain only so much of company legacy terminology (you are stuck with it, usually). The more you use your own names, the more confused the inspector gets and at a point he gets mad :mad: because of that (even if it is not legally wrong).