# 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

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

Staff member
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.

Reduction of software class based on multiple external risk controls IEC 62304 - Medical Device Software Life Cycle Processes 5
Information for safety EN ISO 14971:2012 - Customer Risk Reduction ISO 14971 - Medical Device Risk Management 6
Proactive efforts to reduce risk - PFMEA risk reduction activities IATF 16949 - Automotive Quality Systems Standard 8
Risk Analysis and Risk Reduction requirements in 7.2.2.2 IATF 16949 - Automotive Quality Systems Standard 8
FMEA Risk Priority Number Reduction Worksheet ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 17
AS9102 - 3D printing a special tool required for assembly (counterfeit risk?) AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 10
Defining risk control measures IEC 62304 - Medical Device Software Life Cycle Processes 13
Supply risk management Manufacturing and Related Processes 4
Biological Evaluation (10993) & Risk Management ISO 14971 - Medical Device Risk Management 9
Cybersecurity and Risk Management: Loss of confidentiality IEC 62304 - Medical Device Software Life Cycle Processes 4
FMEA and Risk assessment in Microsoft Access FMEA and Control Plans 6
Realization processes input into overall risk ISO 14971 - Medical Device Risk Management 2
Need Help With Information Security Asset Risk Register IEC 27001 - Information Security Management Systems (ISMS) 2
Post Market/Production Risk Assessment ISO 14971 - Medical Device Risk Management 0
Risk Management Review ISO 14971 - Medical Device Risk Management 4
Low risk IVD study in the UK, do I need MHRA approval? UK Medical Device Regulations 1
Risk Management and other Files ISO 14971 - Medical Device Risk Management 8
Overall Benefit/Risk Analysis - Risk Management VS Clinical Evaluation ISO 14971 - Medical Device Risk Management 3
ISO 27001 for Jumb Burger - Risk Assessment sheet IEC 27001 - Information Security Management Systems (ISMS) 11
Risk Assessment Tools ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 3
Examples to mitigate risk from Covid ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 5
Risk of stopping your customer's line IATF 16949 - Automotive Quality Systems Standard 4
Risk Matrix vs FMEAs ISO 14971 - Medical Device Risk Management 11
IVD risk class II devices for Brazil and MDSAP Other Medical Device Regulations World-Wide 0
ISO 14971:2019: Criteria for overall residual risk ISO 14971 - Medical Device Risk Management 11
ISO14971:2019 - Verification of implementation and effectiveness of risk control ISO 14971 - Medical Device Risk Management 3
Medical Device Cybersecurity Risk Management IEC 27001 - Information Security Management Systems (ISMS) 2
Traceability of requirements to design and risk Design and Development of Products and Processes 3
Risk control measures as per ISO 14971 ISO 14971 - Medical Device Risk Management 6
Deciding whether or not pre-market clinical investigation is required for low risk device EU Medical Device Regulations 5
The term "Benefit Risk Ratio" in EU MDR, do I need to present benefit risk analysis as a RATIO Risk Management Principles and Generic Guidelines 4
Security Risk Assessment Tool IEC 27001 - Information Security Management Systems (ISMS) 0
21 CFR 820 - Risk Management - Looking for some guidance US Food and Drug Administration (FDA) 3
Contract Review and risk managment AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 2
Risk Analysis using Monte Carlo Simulation instead of Scoring and Heat Map Risk Management Principles and Generic Guidelines 2
Software Risk Management & probability of occurrence as per IEC 62304 IEC 62304 - Medical Device Software Life Cycle Processes 8
Normal Condition Hazards in Risk Analysis ISO 14971 - Medical Device Risk Management 3
Rationalising the level of effort and depth of software validation based on risk ISO 13485:2016 - Medical Device Quality Management Systems 10
Risk assessment on IT containers and the information they contain IEC 27001 - Information Security Management Systems (ISMS) 4
Threat/Vulnerability Catalogue for risk assessment IEC 27001 - Information Security Management Systems (ISMS) 4
Opportunity For Improvement vs Opportunity (Positive Risk) ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 18
FOD Risk Assessment - What tools would you recommend for assessing FOD risk? AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 1
Identify Medical Device characterstics as Annex C of ISO 14971 Risk Management ISO 14971 - Medical Device Risk Management 5
ISO 14971 PFMEA Manufacturing Risk ISO 14971 - Medical Device Risk Management 2
Example of the Risk Template Document Control Systems, Procedures, Forms and Templates 1
Overall residual risk according to ISO 14971:2019 ISO 14971 - Medical Device Risk Management 5
Risk Number for each software requirement IEC 62304 - Medical Device Software Life Cycle Processes 7
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
Importing a general wellness low risk product Other US Medical Device Regulations 3
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