Risk Reduction by Risk Control: IEC:62304-Class C

K

Kleibeuker

#1
For example,
We have an unaceptable risk (before mitigation) and is in the software
(eg due to a bug/stall/whatever)
From IEC:62304 we conclude that we need to develop according Class C.

During the the initial risk assessment the probability was set to 100% because for software we cannot judge the probability properly
Asume no other hardware Risk Controls are possible.

The question is if we can apply some risk reduction for our residual risk
based on the following Risk Control: IEC:62304-Class C

Basically we have to alliviate the probability from 100% to let ssay 10 or 1%

What is the best approach here and what is the amount of risk reduction?
 
Elsmar Forum Sponsor

Marcelo

Inactive Registered Visitor
#2
Re: Risk reduction by IEC:62304?

During the the initial risk assessment the probability was set to 100% because for software we cannot judge the probability properly
Which probability you set to 100 %? Please note that the 100 % related to software failure, which is part of P1.
 

yodon

Staff member
Super Moderator
#3
The question is if we can apply some risk reduction for our residual risk
based on the following Risk Control: IEC:62304-Class C
Maybe I'm misunderstanding but are you asking if developing according to Class C requirements is a legitimate control? If that's the question, then no. You can write some pretty crappy software under rigorous controls.

You (always) need to be able to demonstrate that the controls implemented are effective at the time needed.

Circling back a little. You said you had an unacceptable risk and therefore chose the Class C path. I don't think that's the correct way to look at the classification. Class C is indicated when death or serious injury is possible. You could easily have an unacceptable risk with class B software (non-serious injury is possible).

Anyway, to reduce the risk, you'll have to define some tangible controls. How can you prevent the situations that cause the stall / whatever?
 
K

Kleibeuker

#4
Re: Risk reduction by IEC:62304?

The P1, an error in the sw result in a hazardous situation.
Whether the sw is a portion in the secquense of events if not really relevant for the question.
 

Marcelo

Inactive Registered Visitor
#5
The P1, an error in the sw result in a hazardous situation.
Whether the sw is a portion in the secquense of events if not really relevant for the question.
If there's other events in the sequent of events leading to the hazardous situation besides the software failure, P1 won't be 1. Surely it's relevant, and in fact that's exactly why we modified the requirement in Amendment 1 (as people did not see to understand this concept).
 
K

Kleibeuker

#6
@ Yodon,
Not to complicate the question too much, presume a piece of sw that need to be developed according class B or C.

the question was if we just develop accordingly (B or C) could we reduce the risk?
And likely the probability part...
The more I think we need to define (functional) risk controls, even if in that particular piece(unit/item) of sw. Based on that we avoid the question of lowering the probability (thus risk) by applying the Class-C process.
Note that these risk controls does not lower the sw safety classificaiton only the risk level or more precise the robablity of that particular risk.

I agree none of the 62304 prevent crappy code.
Demonstration of effectiveness is done by verification (also required by 62304)
 

Marcelo

Inactive Registered Visitor
#7
Risk reductions is performed by the 3 options of ISO 14971. Using a safety classification of IEC 62304 (which was created simply to define which requirements of the standard would apply so that less riskier devices did not need to follow all the requirements) is not an option to reduce risk.

On the other hand, following a controlled development process do reduce, in some way, the probability of harm in a more general way, but it's not possible to quantify that, in particular, if you implement risk controls measures as defined in ISO 14971.

But in the end, it will all depend on the risk acceptance criteria and on how you can demonstrate that the risk control measures implemented do reduce the risk to an acceptable level.
 
K

Kleibeuker

#8
Thanks for the insights, my reason for asking the question in the first place is that i got confrontated that colleagues claim you can reduce the risk by 3 steps (eg from Frequent -> Remote) just by doing Class C, and it was claimed that this was proposed by an expert.
This does not make much sense, due to what I mentioned before (for example, how would you numerically characterize to justify this reduction?). ALso, this goes back to the problem that I mentioned in this and in other threads about risk acceptability.


>>Risk reductions is performed by the 3 options of ISO 14971.
I presme you mean 1) by design 2) by protective measures and 3) by information.
Yes

Although the latter may not be used as reduction by Annex ZA.
This is not exactly what the deviation says (it says that the residual risk declaration cannot be used to reduce risk, which is not information for safety - the 3rd risk control option).

Wrt the first Amd on the 62304 I noticed the change from a severity based classification into a risk based classification. I think which is good, but one part in the flow diagram (Clause 4.3.a Fig. 3) I dont understand is the question "What severity of injury is possible?" after the question "Does failure of software result in unacceptable RISK?"
This goes back to the way you define your acceptability criteria. In practice, a risk can be unacceptable, even with a low severity.


Here still a mixure of risk and severity. Is the sw failure results in a unacceptabel risk why could you endup in non-serious injury (Class:B) Only of you probability is high...
I think you are confusing some concepts. Serious or non serious injury are defined by the manufacturer.

I was wandering why the sw safety classifications was not mapped all the way to risk levels like:
Acceptable Risk (the green zone) -> Class A
Significant Risk (the orange zone) -> Class B
Unacceptable Risk (the red zone) -> Class C
I think again part of the problem is related to an understanding of risk acceptability, which is not related to "zones" (or risk matrices).
 
Last edited by a moderator:

Marcelo

Inactive Registered Visitor
#9
Let me try to give in example without going to too much detail because this is a complex issue.

If your risk acceptability criteria defines, between other criteria, that the application of IEC 62304 (being an international standard, which is part of the elements of the risk acceptability criteria) can be used as a good practice argument to show that the risks in which software failure is part of the sequence of events leading to hazardous situations are reduced to an acceptable level (this is based on the ALARP principle), then during risk evaluation you could argument, after evaluating compliance with IEC 62304, that the risk is acceptable. This has nothing to do with zones, matrices, or the like.
 

Peter Selvey

Staff member
Super Moderator
#10
To the basic question: can writing software that complies with Class C requirement be enough as a risk control? The answer is maybe, at the end of the day to comply with ISO 14971 someone will have to assign a probability of harm in the formal records, and take responsibility for it.

That's very much context based, as Yodon said you would not normally trust code in a high risk situation, regardless of how well written, but as Marcelo said there could be other factors in the sequence of events that make Class C controls alone enough.

In practice if a situation is high enough risk you never place reliance on a single system regardless of whether it is hardware, software, mechanical or otherwise. It is just basic engineering sense to implement an independent protection system. This structure can also be implemented purely in software and with care can even be done in a single CPU.

If independent protection feels like overkill, chances are there are other factors in the sequence of events external to the software system.
 
Thread starter Similar threads Forum Replies Date
D Reduction of software class based on multiple external risk controls IEC 62304 - Medical Device Software Life Cycle Processes 5
Q Information for safety EN ISO 14971:2012 - Customer Risk Reduction ISO 14971 - Medical Device Risk Management 6
B Proactive efforts to reduce risk - PFMEA risk reduction activities IATF 16949 - Automotive Quality Systems Standard 8
P Risk Analysis and Risk Reduction requirements in 7.2.2.2 IATF 16949 - Automotive Quality Systems Standard 8
A FMEA Risk Priority Number Reduction Worksheet ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 17
T IEC 62304 : Risk control for SaMD IEC 62304 - Medical Device Software Life Cycle Processes 8
Thee Bouyyy Risk Assessment and Management Misc. Quality Assurance and Business Systems Related Topics 0
P Scenario based risk assessment IEC 27001 - Information Security Management Systems (ISMS) 1
Q KPI risk assessment - Criteria for the given score IATF 16949 - Automotive Quality Systems Standard 3
S Foreign Risk Notification Canada Medical Device Regulations 2
J HELP NEEDED ! Risk Management Exercise ISO 14971 - Medical Device Risk Management 12
O Should a Covid vaccine and testing policy be included as part of ISO9001 or AS9100 risk management? ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 6
M Does 4.5 - Alternative RISK CONTROL apply to the Particular Standards? IEC 60601 - Medical Electrical Equipment Safety Standards Series 3
Q Measurement Equipment Revocation - Looking for a Disposal Form with Risk Assessment IATF 16949 - Automotive Quality Systems Standard 10
B ISO13485 Risk managment implementation for suppliers ISO 14971 - Medical Device Risk Management 2
Moncia Chemical risk assessment / COSHH Manufacturing and Related Processes 5
E Supply chain main policies ,scope, risk assessments & relavant KPI Supply Chain Security Management Systems 2
D Use Error Risk Controls and Control Verification ISO 14971 - Medical Device Risk Management 6
J Risk Assessment of Lithium Ion Batteries FMEA and Control Plans 3
Melissa Risk Management Process, How far do I need to go? ISO 14971 - Medical Device Risk Management 13
D Does Risk Management apply to re-labeler (MDR) EU Medical Device Regulations 1
H Risk Management Plan in agile process ISO 14971 - Medical Device Risk Management 14
H Risk Analysis and Probability of Occurrence ISO 14971 - Medical Device Risk Management 3
B Risk analysis for defective measuring or measuring equipment out of calibration General Measurement Device and Calibration Topics 2
P Benefit risk analysis on pFMEA ISO 14971 - Medical Device Risk Management 9
B AS9102 - 3D printing a special tool required for assembly (counterfeit risk?) AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 12
K Defining risk control measures IEC 62304 - Medical Device Software Life Cycle Processes 14
U Supply risk management Manufacturing and Related Processes 4
T Biological Evaluation (10993) & Risk Management ISO 14971 - Medical Device Risk Management 9
D Cybersecurity and Risk Management: Loss of confidentiality IEC 62304 - Medical Device Software Life Cycle Processes 5
Q FMEA and Risk assessment in Microsoft Access FMEA and Control Plans 6
I Realization processes input into overall risk ISO 14971 - Medical Device Risk Management 2
M Need Help With Information Security Asset Risk Register IEC 27001 - Information Security Management Systems (ISMS) 2
thisby_ Post Market/Production Risk Assessment ISO 14971 - Medical Device Risk Management 0
S Risk Management Review ISO 14971 - Medical Device Risk Management 4
D Low risk IVD study in the UK, do I need MHRA approval? UK Medical Device Regulations 1
S Risk Management and other Files ISO 14971 - Medical Device Risk Management 8
silentmonkey Overall Benefit/Risk Analysis - Risk Management VS Clinical Evaluation ISO 14971 - Medical Device Risk Management 3
N ISO 27001 for Jumb Burger - Risk Assessment sheet IEC 27001 - Information Security Management Systems (ISMS) 11
C Risk Assessment Tools ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 3
qualprod Examples to mitigate risk from Covid ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 7
G Risk of stopping your customer's line IATF 16949 - Automotive Quality Systems Standard 4
C Risk Matrix vs FMEAs ISO 14971 - Medical Device Risk Management 12
S IVD risk class II devices for Brazil and MDSAP Other Medical Device Regulations World-Wide 0
M ISO 14971:2019: Criteria for overall residual risk ISO 14971 - Medical Device Risk Management 11
M ISO14971:2019 - Verification of implementation and effectiveness of risk control ISO 14971 - Medical Device Risk Management 5
Aymaneh Medical Device Cybersecurity Risk Management IEC 27001 - Information Security Management Systems (ISMS) 2
S Traceability of requirements to design and risk Design and Development of Products and Processes 3
R Risk control measures as per ISO 14971 ISO 14971 - Medical Device Risk Management 6
D Deciding whether or not pre-market clinical investigation is required for low risk device EU Medical Device Regulations 5

Similar threads

Top Bottom