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
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
S Rationalising the level of effort and depth of software validation based on risk ISO 13485:2016 - Medical Device Quality Management Systems 10
R Risk assessment on IT containers and the information they contain IEC 27001 - Information Security Management Systems (ISMS) 4
B Threat/Vulnerability Catalogue for risk assessment IEC 27001 - Information Security Management Systems (ISMS) 4
R Opportunity For Improvement vs Opportunity (Positive Risk) ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 18
R FOD Risk Assessment - What tools would you recommend for assessing FOD risk? AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 1
R Identify Medical Device characterstics as Annex C of ISO 14971 Risk Management ISO 14971 - Medical Device Risk Management 5
A ISO 14971 PFMEA Manufacturing Risk ISO 14971 - Medical Device Risk Management 2
Q Example of the Risk Template Document Control Systems, Procedures, Forms and Templates 1
K Overall residual risk according to ISO 14971:2019 ISO 14971 - Medical Device Risk Management 5
A Risk Number for each software requirement IEC 62304 - Medical Device Software Life Cycle Processes 7
A IEC 60601 11.2.2.1 Risk of Fire in an Oxygen Rich Environment, Source of Ignition IEC 60601 - Medical Electrical Equipment Safety Standards Series 0
D Importing a general wellness low risk product Other US Medical Device Regulations 3
C Quantifying risk in choosing the number of parts, operators and replicates in a GR&R Gage R&R (GR&R) and MSA (Measurement Systems Analysis) 4
R AQL, Consumer Risk and MA Statistical Analysis Tools, Techniques and SPC 2
M Risk managment report of Surgical Mask Example ISO 14971 - Medical Device Risk Management 14
M Risk Analysis Flow - Confusion between ISO 14971 and IEC 62304 IEC 62304 - Medical Device Software Life Cycle Processes 8
R ECG Risk Analysis Standards ISO 14971 - Medical Device Risk Management 2
N Device Labeling - Medtronic Ventilator Files (Risk Management documents) Coffee Break and Water Cooler Discussions 2
A 5 x 5 Risk Matrix - Looking for a good example Manufacturing and Related Processes 2
F Risk for Quality Assurance Department in a Hospital - Hospital Incident Reporting ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 7
M Should volume of sales be factored into risk probability assessments? ISO 14971 - Medical Device Risk Management 33
T How do you define your Hazards? <a Risk Management discussion> ISO 14971 - Medical Device Risk Management 16
adir88 Documenting Risk Control Option Analysis ISO 14971 - Medical Device Risk Management 8
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
K Identification of hazards and Risk file IEC 62366 - Medical Device Usability Engineering 7
S Risk based internal auditing Internal Auditing 6
Robert Stanley I'm @ RISK of not showing my RISKS! ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 20
M Estimating the benefit-risk ration under MDR EU Medical Device Regulations 1
adir88 Information of safety can reduce risk now? ISO 14971 - Medical Device Risk Management 12
G Any good examples of CAPA forms that include a risk based approach? ISO 13485:2016 - Medical Device Quality Management Systems 8
adir88 MDR requirement: Risk Management Plan for "each device" ISO 14971 - Medical Device Risk Management 5
M Has anyone heard of Run at Risk? Manufacturing and Related Processes 15
Tagin Is SARS-CoV-2/COVID-19 on your risk register? Misc. Quality Assurance and Business Systems Related Topics 11
D IEC 62304 Risk Classification - With and without hardware control IEC 62304 - Medical Device Software Life Cycle Processes 2
J ISO 14971 applied to ISO 13485? Low risk class 1 devices ISO 13485:2016 - Medical Device Quality Management Systems 3
DuncanGibbons Classification of aerospace parts depending on their risk and criticality etc. Federal Aviation Administration (FAA) Standards and Requirements 3
D Performance specification as a Risk Control Measure, EN 14971 ISO 14971 - Medical Device Risk Management 7
M Risk Classification For Supplier - Clinical Research Organisation (CRO) Supply Chain Security Management Systems 3
Sidney Vianna IAQG SCMH explains "positive risk"..........but does it? AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 3
MrTetris Unacceptable risk and information for safety ISO 14971 - Medical Device Risk Management 16
M IATF 16949 (6.1.1 - Planning and Risk Analysis for a remote site) Process Maps, Process Mapping and Turtle Diagrams 5
D Risk Analysis & Technical File - What detail goes in the Risk Management Report ISO 14971 - Medical Device Risk Management 5
C AS9100 Rev D 8.1.1 & APQP - Operational risk management process AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 0
B ATP 5-19 "Risk Management" Misc. Quality Assurance and Business Systems Related Topics 2

Similar threads

Top Bottom