Software Medical Device Bug Fixes: Correction or Corrective Action?

[ariannas]

Hello all,

This is (slightly) a double post -- my first question in this vein was posted in the Quality Assurance area of Elsmar. But I also want to get the point of view from those who live under the FDA regulatory umbrella.

Do you all agree that a software bug fix (in a software-only medical device) would be a correction as far as the FDA is concerned? Or would it be a corrective action?

I've combed through parts 803 and 820, including the Federal Register preambles; but there's very little guidance on how these concepts relate to software.

Your insights and opinions would be much appreciated.

 

[sagai]

Hello there,
I do not think that sw bugs have anything to do with CAPA unless their origin is coming from customer complaints. So their is already another angle on this subject to see what does your company actually consider as a complaint.
I am still not quite sure what exactly you are asking for, so there is a chance that I have misunderstood some part of it.
Cheers!

 

[ariannas]

I do not think that sw bugs have anything to do with CAPA unless their origin is coming from customer complaints.....

Actually - you nailed it. It is specifically bugs identified as a part of customer complaints (i.e., bugs found in released software) that I am wondering about.

I've gotten at least one opinion that a bug fix for released software would be a correction but not a corrective action. I can see it either way so I am hoping the collective wisdom at Elsmar can help me understand which, and why...

(lets assume that NO risk to patient harm is involved....)

 

[sagai]

ohh, okay, getting there.
I see the benefit of having a corrective action to be honest. Apart from fixing the particular bug, I could foresee the benefit of having a more holistic discussion with the stakeholders about the particular complaint and apart from that one of the corrective action is to fix the bug I could see a benefit of applying other actions as well like development/V&V process related process correction/improvement if necessary.
Cheers!

 

[yodon]

While I certainly don't disagree with a holistic assessment, it seems like raising a software bug to a CAPA could be a slippery slope. Why would you do it in one case versus making just a correction in another case.

Obviously, there are many types of bugs. If it's an implementation error then I'm not sure how efficient managing the change as a CAPA would be. If it's something on the order of a design / architecture error, then maybe that's closer to justifying managing it as a CAPA. Remember that with CAPAs, you have to find the root cause(s), identify corrections as well as corrective actions, and then show the effectiveness of the corrective actions. The software folks I know don't really work under that paradigm so in addition to being challenging from a regulatory perspective, it may be challenging getting internal support.

Not saying it's a bad idea; just saying that there ARE implications that need to be considered. If you have a well-documented decision tree and internal buy-in, then there's a better chance at success. If it's arbitrary and low added value, it's going to be very much an uphill struggle.

 

[Sidney Vianna]

Hello all,

This is (slightly) a double post -- my first question in this vein was posted in the Quality Assurance area of Elsmar. But I also want to get the point of view from those who live under the FDA regulatory umbrella.

Do you all agree that a software bug fix (in a software-only medical device) would be a correction as far as the FDA is concerned? Or would it be a corrective action?

I've combed through parts 803 and 820, including the Federal Register preambles; but there's very little guidance on how these concepts relate to software.

Your insights and opinions would be much appreciated.

If the issue (bug) was reported by an external party, it falls in the FDA definition of a complaint. The FDA QSR Guidance stipulates:

Complaint Handling System

An effective complaint handling system is an extremely important part of any quality system. Even manufacturers who have not received complaints should be prepared to receive and process them. Manufacturers should understand that any complaint received on a product shall be evaluated and, if necessary, thoroughly investigated and analyzed, and corrective actions shall be taken. The results of this evaluation should lead to a conclusion regarding whether the complaint was valid, what the cause of the complaint was, and what action is necessary to prevent further occurrences. Complaints cannot be ignored. They are an excellent indicator of problems with the use, design, and/or manufacture of a product. A single complaint that is thoroughly investigated may lead a company to take remedial or corrective action. It may also take an ongoing analysis of numerous complaints before a trend is spotted that causes a company to initiate changes in their product, labeling, packaging or distribution.
Using written procedures for handling complaints increases confidence that all complaints will be handled properly. Written procedures should be provided to employees to facilitate communication, maintain consistency, and reduce quality problems. Written procedures for the receiving, reviewing and evaluating of complaints by a formally designated unit shall be established and maintained in accordance with 820.198, Complaint Files, and 820.40, Document Controls, respectively. The procedures should include the need for complaints to be evaluated in accordance with 820.100, Corrective and Preventive Action.
The complaint files shall be maintained in accordance with the general record keeping requirements of 820.180. All complaint files are to be retained for a period of time equivalent to the design and expected life of the device, but in no case less than 2 years from the date of release for commercial distribution bythe manufacturer. The written procedure should specify: authority; responsibilities; and the process to follow in receiving, reviewing, and investigating complaints. However, for very small manufacturers where division of work is minimal, and authorities and responsibilities are obvious, the GMP requirements as detailed in 820.198 in conjunction with appropriate forms may be sufficient as a protocol for handling complaints.