You are likely aware of the CAPA process overall and how it fits in to the quality management system for a medical device manufacturer or supplier. Just the name itself, corrective and preventive action, describes one of the core values of quality management. Surely we are all motivated to identify and correct problems and issues and to further implement changes to process and methods to prevent recurrence of any problems or issues. If not, you are in the wrong business!
The US regulation for CAPA is 21 CFR 820.100 which requires seven elements related to CAPA (and by extension, to Software CAPA):
- Analyzing processes, work operations, concessions, quality audit reports, quality records, service records, complaints, returned product, and other sources of quality data to identify existing and potential causes of nonconforming product, or other quality problems. Appropriate statistical methodology shall be employed where necessary to detect recurring quality problems;
- Investigating the cause of nonconformities relating to product, processes, and the quality system;
- Identifying the action(s) needed to correct and prevent recurrence of nonconforming product and other quality problems;
- Verifying or validating the corrective and preventive action to ensure that such action is effective and does not adversely affect the finished device;
- Implementing and recording changes in methods and procedures needed to correct and prevent identified quality problems;
- Ensuring that information related to quality problems or nonconforming product is disseminated to those directly responsible for assuring the quality of such product or the prevention of such problems; and
- Submitting relevant information on identified quality problems, as well as corrective and preventive actions, for management review.
Of course, ISO 13485 addresses CAPA in clause 8.5.
What’s the big deal with software CAPA?
The challenge with software CAPA comes up at several points in the CAPA process. One pitfall can occur with the analysis of software design related defects or suspected defects. Software defects are not always obvious – in fact, many times the software defect may manifest in a system behavior that appears to be hardware related or maybe even use-error related. Customer service staff may not recognize software defects or even the potential for a software defect for a very long time. Another difficulty with analysis is that software defects can be difficult to reproduce and determine the conditions necessary for the software defect to result in an out-of-spec system behavior. The manufacturer may use scripted or structured methods to test and try to reproduce the error – and never able to reproduce, leading to a growing backlog of “cannot duplicate” complaints.
A second area of concern with software CAPA is related to the issues above – but the manufacturer may lack or not assign appropriate staff to investigate reported issues. It takes special skills to investigate software defects and perform adequate root cause analysis. And even when appropriate staff are involved, appropriate methodologies must be employed to maintain records and trends to assure root cause identification. Another common pitfall is that the investigation does not explore variants and branches.
IEC 62304 requires that problem issues, when corrected, be verified that the fix was effective. This is a common pitfall – inadequate verification and lack of records to show all the necessary verification was performed. With software CAPA, the simple one or two step verification/closure is very rarely adequate because of the reasons pointed out above.
Very often software CAPA will involve other types of software – not simply the software that executes in the product – and extend into development, testing, and production software tools. Many of the same issues arise for this quality system type of software.
What should you do?
Re-visit your CAPA procedures and process. Add specific instructions for software for all post-market surveillance activities to ensure appropriate methods will be used for potential software defects and that appropriate trending analysis will be performed.
See our previous post on an article our founder, Alan Kusinitz, wrote on software CAPA: Journal Article on Software CAPA
Also, let one of our expert consultants review your current QMS process for appropriate software CAPA activities.
