SBS - The best value in QMS software

Software as risk control - Confused on one aspect of IEC 62304

david316

Involved In Discussions
#1
Hello,

I am a little confused on one aspect of 62304. If I have a class C system and I use software as part of a risk control (e.g. an alarm due to loss of some critical function), I need to develop the software item in accordance with Clause 5. Assuming I develop the software item according to the requirements of 62304, when completing a post mitigation risk assessment, can I assume my software risk control works or do I need to assume it never works (i.e. probability of failure is 1).

For example, maybe consider an alarm with software involved that detects a loss of mains power to a device. When looking at whether the software has successfully helped make the risk acceptable can I assume it works 100% of the time or do I need to assume it never works (which seems silly) or is there some middle ground? The standard isn't very clear on this.

Thanks
 
Elsmar Forum Sponsor

sagai

Quite Involved in Discussions
#2
Probability of software fails is 100% for me.
It's even worst ( :bonk:could it be? ) because the hardware that it is running on also could fail on a way that it looks that software failed.

For arguement, I am happy to listent of the resolution of the Halting problem first :D

Regards
Szabolcs
 

glork98

Involved In Discussions
#3
..can I assume my software risk control works or do I need to assume it never works (i.e. probability of failure is 1).
(Alternate position!)

Yes. The 100% failure is raw code without any testing, inspection or other quality practices. Code developed under good practices will have a lower defect rate compared to what would be produced with no practices. This can appropriately be reflected in the risk analysis.

So... It is up to the SW staff to work with Quality Assurance to establish how the Risk Analysis is done. Impress on them that applying B & C practices decrease defect rates and is itself a mitigation.

What may help is to find studies that show defect discovery for each level of practice and then use that. In a dFMEA I drop the occurrence from a "Frequent" to a "Occasional" (5 of 5 to a 3) and see if more mitigation is needed.

Without this, it becomes impossible to actually make a product that has an intrinsic patient risk using software for control functions. The new layers of (mostly) hardware mitigations create their own risks and there simply can't be mitigations for all software problems without creating an analog computer.

You're welcome.
 

david316

Involved In Discussions
#4
Is a conservative approach that to say, even if we assume the alarm fails with 100% probability due to software, its state of the art as we follow IEC 62304. We also follow the appropriate particular standard, we have other risk mitigators in place (e.g. a warning to have a backup device available), etc. The risk is as low as practically possible. In this case, even if the risk is deemed unacceptable, as we assume the alarm never works, and the other risk mitigators don't make the risk acceptable, then via a risk vs benefit analysis the risk is acceptable.
 

sagai

Quite Involved in Discussions
#5
So, coming back to this power loss alarm.

My opinion ...
Software does not detect power loss.
It is the electronics that in a micro secund timescale can detect the unacceptable degradation of the current that probably will lead to power loss in future. Than it signals it to micro controller/processor or to logic unit. So a software that runs on it or the logic gate array sits on it kicks in and triggers an alarm/signal/whatever that indicates the current degradation on power board/logic unit.
Therefore I would do FMEDA (diagnostic FMEA) for the section of the electronics that is for indicating current degradation, FTA for this function.
So than you will see the reliability of this particular safety related function.

So it is not the software I think in this case.

Regards
Szabolcs
 

david316

Involved In Discussions
#6
The software doesn't detect the loss of power but surely you need to consider the fact that the software will be responsible for displaying the alarm on the device and controlling the output to the speaker, etc. If the software in the alarm system fails there will be no alarm.
 

sagai

Quite Involved in Discussions
#7
So, software is solely one of the many leaves on the fault tree of the funtion of indicating power loss. Probability of failure of this leaf that is for software piece 100%.
There are many other leaves of this fault tree for electronics function block where probability determined by FMEDA.

Reasoning of risk acceptance is incomplete without building and evaluating this fault tree first.

Regards
 

david316

Involved In Discussions
#8
Sure, although the software is like the trunk. If you assume that the software in the alarm system fails 100% of the time, none of the other probabilities matter...the alarm will not function 100% of the time.
 

sagai

Quite Involved in Discussions
#9
Slowly, we are getting there. :)

It should not be like that.
It should not be that software functions demolish the reliability of your safety function ( in this particular case to indicate if there is a potential of unacceptable power loss).

Fault tree brunches with leaves ( leaf = probabilities of the identified failure event ) having “AND” relations multiplies the probabilities (less than 100% if there are other event than software function), therefore if your system architecture built up or re-designed on such a way that either your software one of many parallel events those lead to failure or you are having diagnostic function next to the main function, then your safety function will have better than ‘always and any time’ may fail characteristics.

Hoping this helps ...

Regards
 

david316

Involved In Discussions
#10
Maybe we are getting there .... but still not at the desired destination :). In terms of probability of harm to a patient if you did a fault tree you could end up with one of the nodes being something like:

Probability of serious harm to patient (one possible node) =
Probability of power plug accidentally pulled from socket (0.01) *
probability of not being noticed (0.5) *
probability of alarm failing to operate (1.0) *
probability alarm not acted on (1.0) *
probability that loss of therapy would result in serious harm to patient (0.1)

Admittedly this is based on my understanding of fault trees rather than having experience doing them :). The thing is, in this example if you assume software will fail with 100% of the time then the alarm is useless. The only solution is not having any software involved in the alarm system which seems unpractical. Even if you put the alarm system in its own dedicated processor if you have to assume 100% probability of failure I can't see how this would help.... Hopefully I will have a light bulb moment at some point.....I'm not sure what I am missing...

Actually, I have realised that the power out alarm is probably not the best example for my initial post because its had to think of a software fault that would cause a power out. A better example might be

Probability of serious harm to patient (one possible node) =
Probability of software bug cause device to shut-down (1.0) *
probability of device shutdown not being detected by user (0.5) *
probability of alarm system which detects device shut down failing to operate (1.0) *
probability that loss of therapy would result in serious harm to patient (0.1)

As before the alarm is useless if we need to assume 100% probability that the software as part of the alarm system fails which means the alarm is pointless which doesn't seem right.
 
Last edited:
Thread starter Similar threads Forum Replies Date
Y Risk Control Implemented in Software IEC 60601 - Medical Electrical Equipment Safety Standards Series 6
A 5.5.3 - Software Unit Acceptance Criteria (Risk Control Measures) IEC 62304 - Medical Device Software Life Cycle Processes 3
Sravan Manchikanti Software Risk Management & probability of occurrence as per IEC 62304 IEC 62304 - Medical Device Software Life Cycle Processes 8
silentmonkey Rationalising the level of effort and depth of software validation based on risk ISO 13485:2016 - Medical Device Quality Management Systems 10
A Risk Number for each software requirement IEC 62304 - Medical Device Software Life Cycle Processes 7
B Risk Assessment Checklist for Non product Software IEC 62304 - Medical Device Software Life Cycle Processes 1
MrTetris Should potential bugs be considered in software risk analysis? ISO 14971 - Medical Device Risk Management 5
D Reduction of software class based on multiple external risk controls IEC 62304 - Medical Device Software Life Cycle Processes 5
T Risk analysis of QMS software - Validating software we use for QMS ISO 13485:2016 - Medical Device Quality Management Systems 5
J Software for Techfiles and Risk management ISO 14971 - Medical Device Risk Management 1
B Software Class A - Lengthy further risk analysis IEC 62304 - Medical Device Software Life Cycle Processes 9
I Medical Device Software Risk Analysis ISO 14971 - Medical Device Risk Management 4
A Assessing Risk for Medical Device Software ISO 14971 - Medical Device Risk Management 7
M CE Marking and use of IEC 80002-1 for Risk Management of Stand Alone Software EU Medical Device Regulations 13
U Product Level Software Risk Management Plan and Report ISO 14971 - Medical Device Risk Management 2
S Software Risk Estimation: Probability of Medical Device Software Anomaly Occuring ISO 14971 - Medical Device Risk Management 9
W Software Tool for Medical Device Risk Analysis - Recommendations please ISO 14971 - Medical Device Risk Management 4
N Minor Concern - Medical Device Software and Risk Management ISO 14971 - Medical Device Risk Management 2
M Risk Management in Software R&D Organization ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 4
N Best Software Program for Risk Management ISO 14971 - Medical Device Risk Management 4
K ISO 62304 Software Risk Management and Medical Device Class IEC 62304 - Medical Device Software Life Cycle Processes 5
Q Books / Literature: Risk Management for Medical Device Software recommendations Other Medical Device and Orthopedic Related Topics 4
A Software Risk Analysis training - Recommendations wanted Training - Internal, External, Online and Distance Learning 1
Q Risk Analysis of Software - ISO 14971:2007 ISO 14971 - Medical Device Risk Management 29
Q Risk Management for Medical Software? IEC 62304 - Medical Device Software Life Cycle Processes 15
2 Risk Assessment according to ISO 14971 - Medical Device Software ISO 14971 - Medical Device Risk Management 7
T Software to Manage Compliance to ISO 14971 (Medical Device Risk Management). ISO 13485:2016 - Medical Device Quality Management Systems 9
J Risk Management Software suggestions? ISO 14971 - Medical Device Risk Management 1
R Medical Device Software Risk Management and ISO 14971:2007 ISO 14971 - Medical Device Risk Management 7
C How is risk management handled in a software-based product ISO 13485:2016 - Medical Device Quality Management Systems 1
T Software Supplier Risk Assessments General Auditing Discussions 0
S How to perform verification of the Statistical Analysis Software? Qualification and Validation (including 21 CFR Part 11) 1
I Document Control Software Document Control Systems, Procedures, Forms and Templates 2
E Software maintenance Process Software maintenance Process to IEC 6204? IEC 62304 - Medical Device Software Life Cycle Processes 3
L Micro-Vu InSpec Software Program Qualification and Validation (including 21 CFR Part 11) 6
A For software change - New Channel of interoperability CE Marking (Conformité Européene) / CB Scheme 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
C SharePoint Contract Management Software General Information Resources 0
gramps What do you think about automated QA testing For software app industry? Misc. Quality Assurance and Business Systems Related Topics 5
V Software as medical device (SaMD) replicated for multiple clients through APIs IEC 62304 - Medical Device Software Life Cycle Processes 4
U API Spec Q1 - 5.6.1.2 C (3) - Design software Oil and Gas Industry Standards and Regulations 3
B Complaint Records - Accessing records on Easy Track Software Records and Data - Quality, Legal and Other Evidence 3
GreatNate Master Control QMS software Quality Tools, Improvement and Analysis 0
GreatNate Anyone using the Intellect QMS software? Quality Assurance and Compliance Software Tools and Solutions 1
S DHF/DMR/MDF for a software-only, cloud-based, single-instance device Medical Information Technology, Medical Software and Health Informatics 2
H Software Validation for FFS Packaging Machine Qualification and Validation (including 21 CFR Part 11) 1
E Any sample of a full software life cycle IEC 62304 report ( any class )? IEC 62304 - Medical Device Software Life Cycle Processes 1
Q ISO 13485 7.5.6 Validation - Off the shelf Software ISO 13485:2016 - Medical Device Quality Management Systems 3
M ERP / QMS related software standards for Validation IEC 62304 - Medical Device Software Life Cycle Processes 6

Similar threads

Top Bottom