The path from nonconformity - design change to CAPA

We are a small company for a class IIa medical device. Whenever we find an issue or receive a complaint from the user, there is most likely a hot-fix or it ends up with a design change (can be hardware or software).

So, when we think about the flowchart of problem resolution, let me give you an example of one-time happening issues.

We start with registering the complaint and handle it as a nonconformity. -> A Problem Report

1. Do an investigation to find the causes and the root cause. Let's say the cause was a faulty component and the root cause was poor QC procedure.
   • Eliminate the issue with a correction: Probably replacing the component
   • To eliminate the root cause, we need to update this specific QC procedure. This happens a lot in individual small issues. It is always just adding one step to a QC procedure since it is not possible to find out the problem during assembly.
2. Let's say the cause was again a faulty component but the root cause was a design problem on the software side.
   • Eliminate the issue with a correction: replace the component
   • To eliminate the root cause, we need to fix the bug and release the new version.

Click to expand...

In theory, the actions that were taken to eliminate the root causes are CAPAs. Then we need to file a CAPA for each individual QC procedure change, and it should be considered as PMS-CAPA according to Article 83 point 4 of MDR. This means we need to inform CA and NB. This looks a lot to me since adding one more control point is a common action we take.
It is a bunch of thoughts. Can you please help me to clarify when to file CAPAs regarding a PMS complaint?

If you don't add one more control will the issue stop occurring?

If it is happening regularly that you face issues and as a root cause you define your QC procedures then you need to re-evaluate your procedures and system as a whole and apply necessary lessons learned.

Any specific example by your side, would be helpful.

In my experience many complaints are design related. It is unlikely that you are going to obtain the resources to modify the design for every complaint. The reality is complaints are likely to recur, because modifying the design to address every complaint is unrealistic and unwarranted. I would suggest utilizing the risk management file. If the complaints exceed the severity or frequency of occurrence identified in the risk management file, then a CAPA may be warranted. If the risk related to the complaint is not in the risk management file, then the file needs to be updated.

Good option would be to request design change , for the upcoming phase/ release of the product. This could take years, but in the long-term it could save the company a lot of money. In order to succeed with this approach you have to keep this on track and probably send necessary reminders to the people involved in the project, especially if the company you work for is big.

toniriazor said:

Good option would be to request design change , for the upcoming phase/ release of the product. This could take years, but in the long-term it could save the company a lot of money. In order to succeed with this approach you have to keep this on track and probably send necessary reminders to the people involved in the project, especially if the company you work for is big.

Click to expand...

Depending upon the complaint, the design change may not save the company any money at all. Addressing every complaint with a design change may not actually result in an increase in sales. The most common instance that I had with this was with new product launches. Users would complaint that the new system wasn't just like the old one they are used to. With time they became accustomed to the new system. It's hard to make improvement and keep everything the same. Also, patents restrict the ability to exactly duplicate the competitors systems.

Chrisx said:

Depending upon the complaint, the design change may not save the company any money at all. Addressing every complaint with a design change may not actually result in an increase in sales. The most common instance that I had with this was with new product launches. Users would complaint that the new system wasn't just like the old one they are used to. With time they became accustomed to the new system. It's hard to make improvement and keep everything the same. Also, patents restrict the ability to exactly duplicate the competitors systems.

Click to expand...

Of course each case should be treated differently