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
K Software Updates in the Field and ISO scope ISO 13485:2016 - Medical Device Quality Management Systems 0
M Recurrent event analysis software (python) General Auditing Discussions 2
Y UL 1998 Standard: software classes Software Quality Assurance 0
P Need a programmer for QVI's VMS software for optical inspection machine Inspection, Prints (Drawings), Testing, Sampling and Related Topics 0
S IEC 62304 software costs and time Medical Device and FDA Regulations and Standards News 3
S IEC 62304 - Software verification cost IEC 62304 - Medical Device Software Life Cycle Processes 3
I Form templates for software (iso9001) Document Control Systems, Procedures, Forms and Templates 0
H Software Interface Translation IVD Regulation EU Medical Device Regulations 0
C 8.5.1.1 Control of Equipment, Tools, and Software Programs - Questions about the extent of control of NC programs AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 5
M IEC 62304 Software changes - Minor labeling changes on the GUI IEC 62304 - Medical Device Software Life Cycle Processes 3
T Do I need a qualified compiler for class B software? IEC 62304 - Medical Device Software Life Cycle Processes 3
S Manufacturing Execution Systems Software Costs Manufacturing and Related Processes 0
E 13485:2016, Sections 4.1.6, 7.5.6 and 7.6 - Validation of Software - Need some Advice please ISO 13485:2016 - Medical Device Quality Management Systems 2
R Medical Device Software Certification IEC 62304 - Medical Device Software Life Cycle Processes 1
S HIPAA-compliant monitoring software (advice needed) Hospitals, Clinics & other Health Care Providers 0
A Software bug fixes after shipping a product EU Medical Device Regulations 3
J Medical software Patient outcome Medical Information Technology, Medical Software and Health Informatics 2
Y We are Looking for EASA LOA TYPE 1 experienced software developer Job Openings, Consulting and Employment Opportunities 0
F Grand Avenue Software, Q-Pulse or Qualio - which for a full eQMS? Medical Information Technology, Medical Software and Health Informatics 1

Similar threads

Top Bottom