Assessing Risk for Medical Device Software

[Agent J]

I’m working to update my company’s risk management procedures for our medical device software. I’ve reviewed IEC 80002-1 and I’m not certain how to best integrate the guidance from 4.4.3 Probability.

In our current procedure, we estimate the severity and probability each on a scale of 1-5 and compare the results to a chart to determine if the risk requires risk controls. The higher the probability the less tolerant we are of a given severity. When considering the risk of an anomaly, IEC 80002-1 states that the risk should be considered based on severity alone. Is it common to base the judgment of severity as we might if the probability were the maximum, the minimum, or somewhere in between?

 

[Marcelo]

In our current procedure, we estimate the severity and probability each on a scale of 1-5 and compare the results to a chart to determine if the risk requires risk controls. The higher the probability the less tolerant we are of a given severity. When considering the risk of an anomaly, IEC 80002-1 states that the risk should be considered based on severity alone. Is it common to base the judgment of severity as we might if the probability were the maximum, the minimum, or somewhere in between?

IEC 80002-1 4.4.3 talks about different probabilities, and I think you might be confusing them.

The "focus on severity alone" is only applicable if other probabilities in the sequence of events, after the software failure, are not possible to estimate. If they are, the final probability P1 would be different than 1, and after estimating P2, the probability of occurrence of harm (P1xP2) could be estimated.

The scale you mention is probably the scale of P1xP2, not of P1 only.

 

[Agent J]

Thank you for the clarification, Marcelo.

 

[Frodeno]

Hi Everyone,

I have some follow-on questions from this. So I understand that Prob of Occurance of harm (POH) POH= P1 X P2 and that for software usually P1 cannot be estimated and becomes 1. In a situation where P2 can be estimated then great, one can determine POH. However, when severitiy is used then is it acceptable to use risk controls that reduce severity?

Secondly, in the same context, 80002-1 says on page 11:

"RISK acceptance criteria for RESIDUAL RISK where probability cannot be estimated should take into account the RISK CONTROL measures that have been implemented and the effectiveness of those RISK CONTROL measures in reducing the probability of occurrence of HARM. RISK CONTROL measures should be a combination of all reasonable practicable measures, fulfill applicable standards and regulations, and be state of the art (see Annex D.4 of ISO 14971:2007)."

So, does this mean that eventhough one can estimate Risk based on severity alone that risk reduction can be through a reduction of POH? if this is true can someone help me understand this...this sounds very subjective if it is the case.

Cheers,

Frodo

 

[Marcelo]

So I understand that Prob of Occurance of harm (POH) POH= P1 X P2 and that for software usually P1 cannot be estimated and becomes 1

Nope. The software failure (which is part of the sequence of events that leas to a hazardous situation) usually cannot be estimated, and the probability of this failure usually cannot be estimated and becomes 1. This does not mean that P1 becomes 1 - for example, if there are other events in the sequence of events besides the failure (which is usually the first event).

So, does this mean that eventhough one can estimate Risk based on severity alone that risk reduction can be through a reduction of POH? if this is true can someone help me understand this...this sounds very subjective if it is the case.

As mentioned above, you can have other events in the sequence of events after the software failure, with related probabilities, meaning that P1 won't be 1.

 

[Frodeno]

Aha thanks Marcelo...so in actual fact the P1 = Pa......Pz (potentially) and P2 is probability of a hazardous situation leading to a harm..

It does make me wonder through, at what point does it become appropriate to set P1 to 1 and to what lengths does one go to try to determine the other components of P1...especially if you have 100s of potential hazards to analyze.

 

[Marcelo]

It does make me wonder through, at what point does it become appropriate to set P1 to 1 and to what lengths does one go to try to determine the other components of P1...especially if you have 100s of potential hazards to analyze.

The problem of assuming P1 = 1 is that usually this mean that your device will fall under class C, if they have any possibility of serious injury/death.

As the idea of the safety classification was to enable the manufacturer to reduce the paperwork related to compliance with IEC 62304 if possible, assuming P1 = 1 is a worst case that may create more burden than clearly analyzing P1.

 

[Marcelo]

Anyway, as a general guidance, identifying the probabilities o the sequence of events is more obvious when you have risk control measures external to the software, as they are the only ones that can be counted as feasible. We did made this clear in the 62304 amendment (both IEC 62304 and IEC 80002-1 are not that clear on this regard).