Software Medical Device Bug Fixes: Correction or Corrective Action?

A

ariannas

#1
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.
 
Elsmar Forum Sponsor

sagai

Quite Involved in Discussions
#2
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!
 
A

ariannas

#3
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

Quite Involved in Discussions
#4
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

Staff member
Super Moderator
#5
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

Post Responsibly
Staff member
Admin
#6
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.
 

Attachments

Last edited:
Thread starter Similar threads Forum Replies Date
Q Software as a medical device vs software not sold as medical device: local regulations for sale? EU Medical Device Regulations 4
T IVDR Medical device software CE Marking (Conformité Européene) / CB Scheme 8
N ISO 13485 7.3.9 Change control in medical device software ISO 13485:2016 - Medical Device Quality Management Systems 6
V Software as medical device (SaMD) replicated for multiple clients through APIs IEC 62304 - Medical Device Software Life Cycle Processes 5
R Medical Device Software Certification IEC 62304 - Medical Device Software Life Cycle Processes 1
Q Storing and developing SAMD (Software as a Medical Device) in the Cloud IEC 62304 - Medical Device Software Life Cycle Processes 3
MDD_QNA Medical Device Software - Is a Help Button required? IEC 62304 - Medical Device Software Life Cycle Processes 1
F Software as a Medical Device (SaMD) Technical File Requirements Manufacturing and Related Processes 3
A Software as Medical Device (SaMD) definition and its applicability Other Medical Device and Orthopedic Related Topics 4
T First 510(k) submission - Class II software as medical device US Food and Drug Administration (FDA) 4
Z Software Library - could it be a medical device? ISO 13485:2016 - Medical Device Quality Management Systems 5
M Informational TGA – Submissions received: Regulation of software, including Software as a Medical Device (SaMD) Medical Device and FDA Regulations and Standards News 1
D Requirements for the dimensions / color of medical device labels - Software as a Medical Device IEC 62304 - Medical Device Software Life Cycle Processes 2
D Software as an accessory to a Class I medical device EU Medical Device Regulations 4
R Medical device software without user interface Other Medical Device and Orthopedic Related Topics 3
R Validation of Medical Device Hardware containing Software - How many to Validate ISO 13485:2016 - Medical Device Quality Management Systems 1
Ed Panek Rule 11 Question - CE approvals for software as well as the medical device EU Medical Device Regulations 7
D IEC 60601 for a Software only Medical Device? IEC 60601 - Medical Electrical Equipment Safety Standards Series 5
S Software Release Note - Class A stand alone software medical device IEC 62304 - Medical Device Software Life Cycle Processes 2
M Professional Use Medical Software French Labeling for Canada -- Not Considered Medical Device Canada Medical Device Regulations 2
S Medical Device Software Distribution for a CE-marked medical device via a USB memory stick EU Medical Device Regulations 8
M Informational TGA – Webinar: An update on the consultation for the Regulation of Software, including Software as a Medical Device (SaMD) Medical Device and FDA Regulations and Standards News 0
J Qualification of a Software as a Medical Device (SaMD) guidance under MDR EU Medical Device Regulations 9
P Software requirement and design specifications - Medical device contains both hardware and software IEC 62304 - Medical Device Software Life Cycle Processes 2
M Informational TGA Consultation: Regulation of software, including Software as a Medical Device (SaMD) Medical Device and FDA Regulations and Standards News 0
N Medical Device Accessory Classification - Software as a Medical Device Other Medical Device Regulations World-Wide 5
R SaMD - Software as a Medical Device - Software change control form ISO 13485:2016 - Medical Device Quality Management Systems 3
G EU MDR 2017/745 Rule 11 interpretation - Re-classification of a Software as Medical Device Other Medical Device Related Standards 0
M Medical Device News TGA – Regulation of Software as a Medical Device Medical Device and FDA Regulations and Standards News 0
S Two Questions about Medical Device Software 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 3
K Medical Device Software Update in Field of AIMD IEC 62304 - Medical Device Software Life Cycle Processes 1
M Medical Device News Health Canada - Scientific Advisory Panel on Software as a Medical Device (SAP-SaMD) - Record of Proceedings – January 26, 2018 Canada Medical Device Regulations 0
R Online / Cloud Based Software as Medical Device EU Medical Device Regulations 8
S DMR (Device Master Record) for Medical Device Software IEC 62304 - Medical Device Software Life Cycle Processes 3
S Labelling in Medical Device Software IEC 62304 - Medical Device Software Life Cycle Processes 8
S What is considered the complete software medical device? Medical Information Technology, Medical Software and Health Informatics 6
JoCam Medical Device Software - Apps which can control medical devices EU Medical Device Regulations 13
L Software Medical Device - 7.3.8 - Design and Development Transfer ISO 13485:2016 - Medical Device Quality Management Systems 4
A SOP for software validation of software in medical device IEC 62304 IEC 62304 - Medical Device Software Life Cycle Processes 5
K Registering a Software medical device (SaMD) in China China Medical Device Regulations 5
N Medical Device Software - Switch from Waterfall to Agile methodology Medical Information Technology, Medical Software and Health Informatics 4
V Software medical device labelling EU Medical Device Regulations 5
I Medical Device Software Risk Analysis ISO 14971 - Medical Device Risk Management 4
S If a piece of software receives approval as part of a medical device system Canada Medical Device Regulations 5
C Controlling Software Versions that are part of a medical device IEC 62304 - Medical Device Software Life Cycle Processes 2
S Cloud-Based Stand Alone Software - Software Medical Device (Class II) US Food and Drug Administration (FDA) 2
Q QMS Software for Startup Medical Device Company Other Medical Device and Orthopedic Related Topics 7
B CQC oversight of Medical device software? EU Medical Device Regulations 3
H Identifying Guidance on Medical Device Software Level of Concern for the EU EU Medical Device Regulations 2
B Is IEC TR 80002-1:2009 applicable to stand-alone medical device software? ISO 14971 - Medical Device Risk Management 1

Similar threads

Top Bottom