SBS - The best value in QMS software

FDA Software Failure Mitigation

M

maaquilino

#11
#11
Not sure if this will help, but it has helped me in the past in similar circumstances.

https :// www -950.ibm.com/events/wwe/grp/grp004.nsf/vLookupPDFs/IEC%2062304%20presentation/$file/IEC%2062304%20presentation.pdf - DEAD LINK

See page 12 in the above links - IEC 62304 " If the HAZARD could arise from the failure of the SOFTWARE SYSTEM to behave as specified, the probability of such failure shall be assumed to be 100%”.

The FDA looks at this in a similar manner.

http :// www .fda .gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm089543.htm#8 - DEAD LINK
The risk associated with Software Devices varies over a continuum from negligible to very severe. In general, FDA considers risk as the product of the severity of injury and the probability of its occurrence. However, software failures are systemic in nature and therefore the probability of occurrence cannot be determined using traditional statistical methods. Therefore, we recommend that you base your estimation of risk for your Software Device on the severity of the hazard resulting from failure, assuming that the failure will occur. We also recommend that you use risk identification and control techniques described in consensus standards such as ISO 14971

http: //www .fda. gov/downloads/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/UCM073779.pdf - DEAD LINK
The FDA states: On the software engineering side, probabilities of occurrence would normally be based on software failure rates. However, software failures are systematic in nature and therefore their probability of occurrence can not be determined using traditional statistical methods.

Because the risk estimates for hazards related to software cannot easily be estimated based on software failure rates, CDRH has concluded that engineering risk management for medical device software should focus on the severity of the harm that could result from the software failure. Hazard Analysis is defined as the identification of Hazards and their initiating causes [IEC 60601-1-4]. Based on the definition of Risk Analysis in ISO DIS 14971 and EN 1441, hazard analysis is actually a subset of risk analysis; because risk analysis for software cannot be based on probability of occurrence, the actual function of risk analysis for software can then be reduced to a hazard analysis function. Technically speaking, the use of either term risk or hazard analysis is appropriate. However, CDRH has chosen to use the term hazard analysis to reinforce the concept that calculating risk based on software failure rates is generally not justified, and that it is more appropriate to manage software safety risk based on the severity of harm rather then the software failure rates.

Search on Risk here:
http :// www .fda. gov /MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/ucm085281.htm - DEAD LINK
 

Attachments

Last edited by a moderator:
Quickly Organize an Intelligent TDP from DISCUS
Elsmar Forum Sponsor
O

OccamMan

Starting to get Involved
#12
#12
In the past I've assumed that:
- the probability of failure of any given piece of software is 100%
- when software fails, it fails in a totally unpredictable way - anything bad that it can do, it will do
- two independent software executables on relatively independent hardware are unlikely to fail within a short time period if their code is unrelated - the less related (i.e., different language, libraries, etc) the better
 
S

Spazz

#13
#13
maaquilino said:
The FDA states: ... Because the risk estimates for hazards related to software cannot easily be estimated based on software failure rates, CDRH has concluded that engineering risk management for medical device software should focus on the severity of the harm that could result from the software failure.
Click to expand...
If the medical device contains both software and hardware, I've found it's difficult to evaluate risk using the same set of criteria when the probability of some risks are assumed to be 100%. Instead, I use a "detectability" score rather than "probability" when evaluating systematic failures like software. The idea is if the user can detect the failure (and can do something about it), the harm can be reduced.
 
R

robert.beck

Involved In Discussions
#15
#15
good comments. still a difficult issue five years later. the link to the FDA is no longer working, and the IBM link is not either. would you have either or both of those presentations/documents? if so could you attach them as a reply?
 
R

robert.beck

Involved In Discussions
#17
#17
thanks. didn't realize you meant that one. that's the bible for 510(k)s with software, but I'm more interested in the other one because I'm not familiar with it. I posted my full question on another thread earlier today with lots of background information, including some from that guidance documents.
 
Marc

Marc

Hunkered Down for the Duration with a Mask on...
Staff member
Admin
#18
#18
yodon said:
The FDA guidance for premarket submission is here: Content of Premarket Submissions for Software Contained in Med.Devices

(Don't know why they moved things around but I had to update all my bookmarks.)
Click to expand...
They updated their website a while ago and were too cheap to forward old links to current links.

FYI - I was updating a post with some dead links today (post 11 in this discussion thread) and found the document linked to. It is here for download, and is dated 11 May 2005 - Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices ucm089593.pdf.

There were 2 dead links that I couldn't "fix".
 
You must log in or register to reply here.
Thread starter Similar threads Forum Replies Date
Marc FDA: Software Failure Behind 24% of Last Year's Medical Device Recalls Other Medical Device and Orthopedic Related Topics 2
D FDA Guidance on Computer Software Assurance versus 21 CFR Part 11 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 2
O Any info on release date of FDA “Computer Software Assurance for Manufacturing and Quality System Software” document? 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 0
M Informational US FDA – URGENT/11 Cybersecurity Vulnerabilities in a Widely-Used Third-Party Software Component May Introduce Risks During Use of Certain Medical Dev Medical Device and FDA Regulations and Standards News 0
M Informational US FDA Draft Guidance – Clinical Decision Support Software Medical Device and FDA Regulations and Standards News 0
M Informational US FDA Final and update guidances – Software Medical Device and FDA Regulations and Standards News 2
M Informational US FDA – Digital Health Update: Mid-Year Update on Software Precertification Program Medical Device and FDA Regulations and Standards News 0
M Informational USFDA – Digital Health Update: The FDA Announces an Opportunity for Test Case Volunteers for the Test Plan for the Software Precertification Program Medical Device and FDA Regulations and Standards News 0
S Is Software code documentation required for FDA premarket submissions? IEC 62304 - Medical Device Software Life Cycle Processes 2
T FDA proposed labeling standalone software cloud based US Food and Drug Administration (FDA) 4
R FDA Requirements - Printing Equipment Software Validation Qualification and Validation (including 21 CFR Part 11) 1
M Suggestions for Electronic Signature Software (FDA 21 CFR Part 11 Compliant) Qualification and Validation (including 21 CFR Part 11) 12
Y FDA PreCert Program for Software (Companies) - 2017 Other US Medical Device Regulations 1
J PMA Device - Lot # change in New ERP Software - What are the FDA Requirements 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 0
K FDA Premarket Submissions for Embedded Software - Level of Concern Other US Medical Device Regulations 4
F FDA PMK 510(k) - IEC 62304 Software Components Segregation Other US Medical Device Regulations 3
J FDA classification and registration for a software plugin 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 2
M FDA's expectation for validating OTS software updates Other US Medical Device Regulations 8
E Software that may be excluded from FDA Oversight Other US Medical Device Regulations 1
B FDA Product Classification - Self Treatment Software Applications 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 4
N FDA Aspects - No Improvements to 12 Year Old Software ISO 13485:2016 - Medical Device Quality Management Systems 4
E FDA Requirements for Implantable Medical Device Software Validation ISO 13485:2016 - Medical Device Quality Management Systems 5
T How to Report/Notify Medical Device Software Changes to the FDA? US Food and Drug Administration (FDA) 3
A Beta Testing FDA Regulated Medical Device Software vs. Nonconforming product? 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 3
U Manufacturing vs. Production for Medical Device Software in a FDA context 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 6
S FDA and OTC (Over the Counter) Software Use Classification Medical Information Technology, Medical Software and Health Informatics 9
D FDA Compliant QMS Software Recommendation for Small Company Quality Assurance and Compliance Software Tools and Solutions 3
F ISO 13485 & FDA Requirements - What kinds of software require validation? ISO 13485:2016 - Medical Device Quality Management Systems 2
P Software Changes - Is an FDA guidance type of document available from SFDA (China)? China Medical Device Regulations 2
Q Software Validation - FDA Regulations and Requirements US Food and Drug Administration (FDA) 4
M Level of Concern (FDA) vs. Software Safety Classification(IEC) US Food and Drug Administration (FDA) 3
D FDA Establishment Registration for Software Company US Food and Drug Administration (FDA) 8
S SW (Software) Deferred Bug Fix - FDA Requirements IEC 62304 - Medical Device Software Life Cycle Processes 4
S Federal Register - Software Reclassification (MDDS) - Final Decision by FDA yet? Other US Medical Device Regulations 3
S FDA eSubmitter Medical Device Software 510k Filing Other US Medical Device Regulations 8
T IEC 62304 & FDA: Software Development Methodologies for Class II- DICOM device IEC 62304 - Medical Device Software Life Cycle Processes 8
D FDA Approval for Diagnostic Software Clinical / Research US Food and Drug Administration (FDA) 4
T IEC 62304:2006: Medical device software SDLC- CE Vs. Fda 510(k) submission IEC 62304 - Medical Device Software Life Cycle Processes 16
S Software changes (windows 2007 compatible) notification to FDA? 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 5
D FDA Requirements for Combined Software US Food and Drug Administration (FDA) 3
thisby_ FDA, Classification Rules & Medical Software Devices US Food and Drug Administration (FDA) 3
D Has anyone used ExtraView software in FDA regulated industry? Qualification and Validation (including 21 CFR Part 11) 3
F Conversion from Agile - Need cheaper FDA compliant software Qualification and Validation (including 21 CFR Part 11) 7
C Software Validation Procedure per FDA requirement Qualification and Validation (including 21 CFR Part 11) 3
M Microsoft Sharepoint as Document Control Software - FDA Validation Requirements Document Control Systems, Procedures, Forms and Templates 15
J FDA classifying all PACS software devices as Moderate Level of Concern? 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 9
L Understanding FDA requirements for Software Validation Qualification and Validation (including 21 CFR Part 11) 7
S FDA part 820 Software Validation - Can software be retrospectively validated? Qualification and Validation (including 21 CFR Part 11) 10
C Software recommendations for CAPA that will meet the FDA QSR & Part 11 Quality Assurance and Compliance Software Tools and Solutions 4
M CE requirement for software importer / reseller - Class II for FDA and Health Canada EU Medical Device Regulations 1

Similar threads

Top Bottom