IEC 62304 Amd 1 2015 - Figure 3 – Assigning Software Safety Classification

kreid

Involved In Discussions
#1
How do people interpret Figure 3 in Section 4.3 Software safety classification?

I find the middle decision box particularly confusing:
'Does the failure of the software result in unacceptable risk?'

Surely every risk management report concludes that there are no unacceptable risks?
If so, why would there ever be a Yes answer to the middle desicion box in the flow diagram, and hence, when would anyone classify there software as anything other than Class A?
 
Elsmar Forum Sponsor

Marcelo

Inactive Registered Visitor
#2
First, the initial definition shall of the safety class be performed without risk control measure applied.

Then, you can perform an evaluation again after risk control measures have been implemented (for example, in hardware), and then change the safety classification.

This is explained in the text:

"For a SOFTWARE SYSTEM initially classified as software safety class B or C, the MANUFACTURER may implement additional RISK CONTROL measures external to the SOFTWARE SYSTEM (including revising the system architecture containing the SOFTWARE SYSTEM) and subsequently assign a new software safety classification to the SOFTWARE SYSTEM."
 
#3
I would venture further and ask what does "failure of the software" mean. Does this mean that if the CPU overheated causing the software to crash, that this is a failure of the software? Does it mean that there was a software bug? I think we all need clarification of the term "failure of the software".
 

rothlis

Involved In Discussions
#4
kreid,
I found myself asking a similar question after looking at the amendment, but I then realized that there are two important items to take note of:
1) Only external (i.e., independent) risk controls can be accounted for in the determination of 'acceptable risk', and
2) The safety classification is based on whether the software can contribute to a hazardous situation - this includes software as both cause and control (per clause 7.2.2b).

Once these two elements are taken into account I think we can see how a classification in a medical device can easily rise above Class A.

mikezv,
I have always understood a "failure of the software" to only include those faults which can occur with normally operating hardware - which would exclude processor overheating but would include those rare memory bit corruptions that are inherent to RAM (and are less rare than previously thought).
 

glork98

Involved In Discussions
#5
1) Only external (i.e., independent) risk controls can be accounted for in the determination of 'acceptable risk'
I don't quite understand what you're getting at here.

Once these two elements are taken into account I think we can see how a classification in a medical device can easily rise above Class A.
I've found it to be the other way: if the device poses any risks, it's hard to avoid having software that is not Class A.
 

rothlis

Involved In Discussions
#6
glork98,
My first statement was just highlighting the guidance in the standard which says that only external controls can be considered. So if you are doing the evaluation to determine whether the software has any unacceptable risks, you can't account for risk reductions due to any risk controls that are implemented in the same software that is the source of the risk (though the definition of "same software" is subject to your interpretation and partition definitions).

By "rise above Class A" I meant "Class B or Class C". The OP was asking how you would ever not have Class A software (due to an unacceptable risk) if risk evaluations always show that everything is acceptable in the end. I was pointing out how the classification is not just drawing from the final evaluation.
 

MediKit

Starting to get Involved
#7
I am actually still confused with Figure 3. How can you possibly go from Class C to Class B based on the flow chart? Example:

Harm - Burn

1) Can a hazardous situation arise from a failure of the software?
Yes, software controls heater and failure can cause burn - serious injury

2) Evaluate effectiveness of risk control external to SW
- Thermal Cutout

3) Does failure of the SW result in unacceptable risk?
Now two possibilities:
a) if we treat Thermal Cutout as extremely reliable and has 1 in 1000000 failure rate, then the answer is No, so according to Figure 3, our software is class A
b) if we treat Thermal Cutout to be reasonable reliable e.g. 1 in 1000 failure rate, then the answer is Yes so go to 4)

4) What severity of injury is possible? So now we go back to 1) which is burn - serious injury, and software class remains class C

So how can we possibly get a class B software when the default is class C? The only possible way is if we treat Thermal Cutout as a reduction in severity of harm to non-serious injury, but that sounds wrong to me. Now, I am confused about whether a risk control reduces severity vs probability...

Am I missing something?
 
Last edited:

glork98

Involved In Discussions
#8
You could get a "B" if, for example, the mitigation was a physical guard that allowed contact with a 75C surface instead of a 500C surface.

Perhaps the example is flawed but consider a mitigation that reduces the severity and not just the likelihood.
 

MediKit

Starting to get Involved
#9
You could get a "B" if, for example, the mitigation was a physical guard that allowed contact with a 75C surface instead of a 500C surface.

Perhaps the example is flawed but consider a mitigation that reduces the severity and not just the likelihood.
Hi glork98,

Yes, but that doesn't sound right as it implies that only risk control that reduce severity is effective to protect against software failure.

Furthermore, in my opinion, only inherently safe design can reduce severity - e.g. use a lower power heater so it can only heat up to 75C instead of 150C, replace a sharp corner with a rounded one etc. Any protection measures such as guard can be viewed as reducing probability, as there is always a possibility that the protective measure can fail.
 

rothlis

Involved In Discussions
#10
MediKit,
Your response to glork98 is forgetting the "Does the failure of the software result in unacceptable RISK?" decision point in Figure 3. If you reduce the probability enough, then that kicks in and you go to Class A. But I think it is correct to observe that the only way for risk controls to move you from Class C to Class B is by reducing severity.
 
Thread starter Similar threads Forum Replies Date
K IEC 62304 - Testing Independance IEC 62304 - Medical Device Software Life Cycle Processes 5
K IEC 62304 - Functional and performance requirements for SOUP items IEC 62304 - Medical Device Software Life Cycle Processes 2
K IEC 62304 compliance - Code reviews as part of verification strategy IEC 62304 - Medical Device Software Life Cycle Processes 5
M Risk Analysis Flow - Confusion between ISO 14971 and IEC 62304 IEC 62304 - Medical Device Software Life Cycle Processes 8
D IEC 62304 Risk Classification - With and without hardware control IEC 62304 - Medical Device Software Life Cycle Processes 2
M IEC 62304 Class A Project IEC 62304 - Medical Device Software Life Cycle Processes 15
B Clause 5.1.12 of Technical Standard IEC 62304/A1 IEC 62304 - Medical Device Software Life Cycle Processes 5
P IEC 62304 - evaluation of integration and system testing IEC 62304 - Medical Device Software Life Cycle Processes 4
P Risk acceptability alignment between ISO 14971 and IEC 62304 IEC 62304 - Medical Device Software Life Cycle Processes 6
D Required Checklist Showing Compliance to IEC 62304 IEC 62304 - Medical Device Software Life Cycle Processes 11
P Proposed revision of IEC 62304 - 2019 IEC 62304 - Medical Device Software Life Cycle Processes 6
S Relationship between IEC 62304 problem resolution and ISO 13485 IEC 62304 - Medical Device Software Life Cycle Processes 8
P IEC 62304:2006 A1:2015 - Software from the early 1990s IEC 62304 - Medical Device Software Life Cycle Processes 4
B IEC 62304:2015 vs IEC 62304:2006 + AMD1 IEC 62304 - Medical Device Software Life Cycle Processes 4
F IEC 62304 - Segregation and communication between software items IEC 62304 - Medical Device Software Life Cycle Processes 1
B Class IIB Device - IEC 62304 Software Classification IEC 62304 - Medical Device Software Life Cycle Processes 13
B IEC 62304 - Update Checklist IEC 62304 - Medical Device Software Life Cycle Processes 2
L Connection between IEC 62304 and Chapter 14 of IEC 60601-1 IEC 60601 - Medical Electrical Equipment Safety Standards Series 2
M IEC 62304 - Develop an Architecture for the Interfaces of Software Items IEC 62304 - Medical Device Software Life Cycle Processes 8
S Does IEC 62304 require documenting unresolved anomalies for all safety classes? IEC 62304 - Medical Device Software Life Cycle Processes 4
A SOP for software validation of software in medical device IEC 62304 IEC 62304 - Medical Device Software Life Cycle Processes 5
T I need to make test reports according IEC 62304 & IEC 62366 IEC 62366 - Medical Device Usability Engineering 2
D Changing software classification via software - IEC 62304 IEC 62304 - Medical Device Software Life Cycle Processes 3
D Software as risk control - Confused on one aspect of IEC 62304 IEC 62304 - Medical Device Software Life Cycle Processes 20
K Trying to figure out what satisfies a few aspects of IEC 62304 IEC 62304 - Medical Device Software Life Cycle Processes 2
Y IEC 62304 Section 4.3(a) - 100% probability of failure IEC 62304 - Medical Device Software Life Cycle Processes 3
Y Application of IEC/EN 62304 at an advanced stage of software development IEC 62304 - Medical Device Software Life Cycle Processes 4
T Is there any requirement to be compliant with IEC 62304 while implementing ISO 13485 ISO 13485:2016 - Medical Device Quality Management Systems 5
L Documentation Planning - IEC 62304 Clause 5.1.8 IEC 62304 - Medical Device Software Life Cycle Processes 2
C Software for Medical Devices - Requirements Content for compliance with IEC 62304 IEC 62304 - Medical Device Software Life Cycle Processes 1
W CPU BIST IEC 62304 - Embedded code has CPU instruction tests IEC 62304 - Medical Device Software Life Cycle Processes 2
K Risk Reduction by Risk Control: IEC:62304-Class C ISO 14971 - Medical Device Risk Management 15
C Per IEC 62304, are DHF documents Configuration Items? IEC 62304 - Medical Device Software Life Cycle Processes 5
P IEC 62304 AMD1:2015: What's new vs.the 2006 Edition? IEC 62304 - Medical Device Software Life Cycle Processes 4
F FDA PMK 510(k) - IEC 62304 Software Components Segregation Other US Medical Device Regulations 3
M IEC 62304 Applicability - GUI Control Software IEC 62304 - Medical Device Software Life Cycle Processes 3
B Our NB says that IEC 62304 is an ISO 14971 Requirement ISO 14971 - Medical Device Risk Management 1
B Clarification on interpretation of some EN ISO 14971:2012 & IEC 62304:2006 req's ISO 14971 - Medical Device Risk Management 46
H ISO 14971 vs. IEC 62304 vs. 98/79/EC vs. ISO 13485 (Software Medical Device) ISO 14971 - Medical Device Risk Management 1
D A desperate call for help - IEC 62304 software IEC 62304 - Medical Device Software Life Cycle Processes 5
B IEC 62304:2006/AMD1:2015 Changes for Class A Software IEC 62304 - Medical Device Software Life Cycle Processes 3
M IEC 62304, ISO 14971 and FDA Medical Device SW Guidance 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 5
K IEC 62304 - Compliance steps IEC 62304 - Medical Device Software Life Cycle Processes 5
K ISO 14971 and IEC 62304 - Medical Device Software House ISO 14971 - Medical Device Risk Management 9
S Software Test Report including IEC 62304 classification IEC 62304 - Medical Device Software Life Cycle Processes 4
A Mapping of IEC 62304 artefacts (SRS, SAD, etc) to the 820.30 phases IEC 62304 - Medical Device Software Life Cycle Processes 5
W IEC 62304 vs. IMDRF SaMD Guideline Risk Class IEC 62304 - Medical Device Software Life Cycle Processes 5
C New IEC/TR 80002-3 Guidance for IEC 62304 - June 2014 IEC 62304 - Medical Device Software Life Cycle Processes 2
R IEC 62304 was brought up during an FDA Inspection/Audit IEC 62304 - Medical Device Software Life Cycle Processes 6
O Electronic Fever Thermometer - Why not IEC 62304 Class C? IEC 62304 - Medical Device Software Life Cycle Processes 7

Similar threads

Top Bottom