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

K

#### Kleibeuker

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?

#### Marcelo

##### Inactive Registered Visitor
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

Super Moderator
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

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
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

@ 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
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

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
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

Super Moderator
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.