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

sagai

Quite Involved in Discussions
#11
Cheers man ! ;)

So , okay.

How would probability change if:
1., Light bulb is always on, software switches off all time when there is no signal of power loss
2., hardware watchdog implemented and software constantly interact with that to indicate software still running fine
3., readback signal form light bulb comming back and evaluated if works as intended.

More other approaches by design can reduce the probabiliy by growing new brunches on that fall (Lol, fault) tree.

Regards
 
Elsmar Forum Sponsor

david316

Involved In Discussions
#12
Its not entirely clear how the software is controlling the light bulb, but I do agree that hardware watchdog, code partitioning, etc will reduce the probability of the software failing. What is not clear is does 63204 require you to assume software can always fail with 100% probability? If this is the case how can any risk control mitigator that requires software to work, be used to justify a reduction in probability of harm occurring?

I might have missed something because I found the light explanation hard to follow.
 

sagai

Quite Involved in Discussions
#13
62304 is the medical device industry specific ‘implementation’ of the software related content of IEC 61508.
I think it’s misleading to use 62304 in isolation. Software always runs on something ( microcontroller, cpu, FPGA, etc. ). Further software always interact with our world by interfaces those are hardwares.

So, i think:
Q1: yes 100% for me.
Q2: utter nonsense (sorry) to claim that SW reduce that probability.

So I would advocate to have a look on IEC 61508 to put this 62304 into proper context.

Regards :rolleyes:
 

david316

Involved In Discussions
#14
I will look at IEC 61508 thanks. In reference to your answer to Q2.... so if I have an embedded device that has an independent processor that's sole purpose is to monitor via the software the presence of a power out signal from some appropriate electronics, and then via software control the output to a speaker, (and this independent processor also has an hardware watchdog)..... as this alarm system is critically dependent on software (which is assumed to have 100% probability of failure) this system will not increase the detectability of a power out situation and hence will not reduce the probability of harm? Seems like utter nonsense (sorry) .

:)
 

sagai

Quite Involved in Discussions
#15
No worries ... :D

For this scenario I do not really understand why to have software involved, rather than for example a relay/transistor that kicked in to initiate a signal sending to that speaker.

So, yes, it is for me an exposure on software errors.
Watchdog is not for seeing if software running as intended.

I was reading your post carefully, so if that sw works unintended, this system unlikely will fulfill it is intended purpose.

Regards
 
#16
The risk you define is about your system, without any of the mitigations. If this aspect of your system fails, then what happens? Someone dies, someone is injured or someone gets a minor injury or someone is scared out of his wits but essentially unharmed. For these types of risky conditions you can determine acceptability through probability So is 1 death in the lifetime of the device OK for the intended use of this device? Like for an emergency response system where chances of survival are already slim and application of the device might save or kill a patient (like the application of current with a heart start device), this might be OK, but for a bloodpressure measurment device we'd never get it approval. So you also need to take a look at the competition. How acceptable is the risk? We accept X-ray in order to get a better view of a broken bone or to perform life saving surgical operation on the heart. But it isn't harmless. You need to define the DIRECT contribution of the failure to the nasty situation. If you have done that, you know what kind of failure your mitigation will have to prevent or will allow for. And with software assume that the chance of failure is 100%. So then for your mitigation and if you go towards a software only solution, that means you might end up having to accept that your software will not sufficiently reduce the risk for it to become acceptable and you might still have to look at a hardware solution. In order to design such a safeguarding system you need to look at other standards. There are many and all have their perks. Most can be found in the particulars of the 60601 or the 80801 series. Like for warning systems there are standards like for example IEC61508, and there are a lot more. So check the IEC 60601 series or the IEC 80601 series for specifics about your system, the safety and essential performance requirements and compliance to them, or go through the IEC 16142-1 for an idea on where to look. There are several series and standards on the subject of safety systems, warning and alerting systems. You need to find the right one. After you have defined how important it is for this software (and hardware system) that guards your medical device to not fail, you can then define requirements as to the allowed failure rate, durability, operational safety, etc. And that will then determine how redundant stuff needs to be designed, how stringent you need to monitor and how carefull you need to be with updates in order to meet the specified criteria.
 

Mark Meer

Trusted Information Resource
#17
...
So, i think:
Q1: yes 100% for me.
Q2: utter nonsense (sorry) to claim that SW reduce that probability.
...
Great discussion guys! :agree1:

I've always been confused of the policy of assuming 100% probability of failure for software. Sure, I understand that software in this day and age can be complex and prone to inevitable bugs, but surely there must be more nuance...

Take, for example, firmware who's only purpose is to turn on an LED (illustrative example only - yes, in practice you'd design differently, I know...). It would be a single line of code. Is it reasonable to assume that the probability of failure is 100% in this case?

I'm also unclear how this risk approach translates to software that is a medical device (SaMD). How could you possibly carryout risk management assuming that the probability that your device (software) fails eventually is always 100%?
 

david316

Involved In Discussions
#18
If you have done that, you know what kind of failure your mitigation will have to prevent or will allow for. And with software assume that the chance of failure is 100%. So then for your mitigation and if you go towards a software only solution, that means you might end up having to accept that your software will not sufficiently reduce the risk for it to become acceptable and you might still have to look at a hardware solution. In order to design such a safeguarding system you need to look at other standards. There are many and all have their perks. Most can be found in the particulars of the 60601 or the 80801 series. Like for warning systems there are standards like for example IEC61508, and there are a lot more.
I am coming to a similar the conclusion. If you have a system that creates unacceptable risk (as defined by your risk acceptability criteria), according to 62304, you cannot use a risk control that contains software as a critical aspect to lower the probability of risk. Hence if the risk is deemed unacceptable and you cannot make it acceptable with other risk mitigators, you need to do a risk vs benefit analysis. Part of this will be showing the risk is as low as possible which includes conforming to relevant particular standards for your device as will as having similar risk to other state of the art devices. I don't necessary agree with this approach but it seems to be what the standard dictates.
 

david316

Involved In Discussions
#19
Actually after talking to a test house about this topic their guidance was essentially below although they are going to spend more time thinking about it:

In terms of 63204, clause 4.3 requires you to determine your software classification class for all software that could lead to patient harm. This includes software that controls the device as well as software that is contained in risk control measures (e.g. alarms). Once you have determined your software class you develop your software inline with 63204. Post development of the software with the appropriate processes, you are not required to assume your software will fail with 100% certainly and can make a more reasonable estimate.
 

sagai

Quite Involved in Discussions
#20
"
Take, for example, firmware who's only purpose is to turn on an LED (illustrative example only - yes, in practice you'd design differently, I know...). It would be a single line of code.
"

It might be my ignorance, however I have never really seen a working source file that has a single line of code.
Even if you are coding in Assembly, it is not a single line of code.
Nor in C, neither of the C source that is couple of lines of header file references, variable definitions, main function, called turnon whatever function, exit values, etc. .
After preprocessing that includes all header files and called function, the pure preprocessed C file roughly 30+ lines of code.
And it is not even compiled to binaries of the platform to.

For me there is no such think like software only medical device.
Software always running on hardware (unless you are doing a turing machine with a paper and pencil method) and interact with our world by hardwares (those also mostly have software on it).

:bigwave:
 
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
Q Software as a medical device vs software not sold as medical device: local regulations for sale? EU Medical Device Regulations 4
Y Software updates considered servicing (7.5.4) ISO 13485:2016 - Medical Device Quality Management Systems 4
S How to perform verification of the Statistical Analysis Software? Qualification and Validation (including 21 CFR Part 11) 2
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 5
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

Similar threads

Top Bottom