IEC 62304 Section 4.3(a) - 100% probability of failure

yodon

Leader
Super Moderator
We have had an interesting internal discussion. Section 4.3(a) if 62304 says, when addressing the safety classification, “If the HAZARD could arise from a failure of the SOFTWARE SYSTEM to behave as specified, the probability of such failure shall be assumed to be 100 percent.”

The discussion arose about how this translates into the risk analysis. We're using an FMEA-type approach with severity / likelihood scales of 1..5.

In one school of thought, the failure WILL (100%) occur but the likelihood of it failing can still be considered (pre-controls). So a likelihood of occurrence of '1' (on the 1..5 scale) means that it WILL occur (thus meeting the 100% requirement) but it's still quite unlikely to occur over the life of use.

The other school of though is that, prior to mitigation, the likelihood must be 5 (to meet the 100% requirement) since it will occur at any given instance (and thus considering it occurring at the worst possible time).

We recognize that the root of the difference is the view (over the life -v- any given point in time).

Curious how others are approaching this. Maybe there's an entirely different method other than the FMEA approach that would be more suitable?
 

Marcelo

Inactive Registered Visitor
Maybe there's an entirely different method other than the FMEA approach that would be more suitable?

Sure, and the approach is to follow ISO 14971.

A failure is one of the events in a sequence of events that might lead to a hazardous situation (which comprise P1). If the failure occurs (is 100 %) it does not mean that other events in the sequence of events will also be 100 %). Other events might have a different probability. So it means that P1 is not necessarily 100 %.

The failure has nothing to do with P2, so it also means that P2 is not necessarily 100 %.

Which means that the hazardous situation (P1 x P2) is not necessarily 100 %, too.

See the amendment to IEC 62304 and IEC 80002-1 for more info.
 

mihzago

Trusted Information Resource
As Marcelo stated, there is a difference between a failure, and the failure resulting in harm to the user/patient. Make sure you define whether by failure you mean a defect in the software or an event that causes actual harm.

FMEA is not the best tool for a complete risk assessment because it focuses on the failure of the system rather than physiological harm*, and does not include normal use that may also cause or lead to harm.

(*ISO14971 also includes property and environment.)
 

glork98

Involved In Discussions
This has come up a few times with the different organizations I've worked with. The basic problem is that is the failure rate is 100% and the harm is severe, or even moderate, then the product most likely does not have a benefit that outweighs the risk. This leads to a conclusion that a device that can do harm can not have SW in it.

I've taken two approaches:

The practical approach is to say that a failure is 100% initially and without any quality practices. That is, it's written and used and will fail. If this leads to an initial classification of B or C for the item, then apply the appropriate quality practices and that decreases the likelihood. Then reassess the failure for the need for further mitigation(s).

If the other staff (like SW quality) don't agree that quality practices reduce a defect's likelihood then add detectability to the evaluations. The RPN is then frequencyxdetectabilityxseverity. Use that failures are found by other SW and in test. (Also, ask why to do code reviews and unit tests if they don't decrease failures.)
 
Top Bottom