Software Risk Management & probability of occurrence as per IEC 62304

[Sravan Manchikanti]

Dear Elsmar folks,

Hope you are doing well.

I have a fundamental doubt on the application of risk management as per IEC 62304. Specially in case of SaMD!

Coming to the famous suggestion of IEC 62304, i.e. considering 'probability of occurrence shall be set to 1',

Shall we consider this only in case of software safety classification in to A, B and C?

Or

Is it applicable to risk management that we conduct for the entire software system as well (Ex Software FMEA)? Where in most of the cases risk mitigation is achieved through reduction in the probability of occurrence as the severity generally remains constant. Appreciate your response.

Thanks in advance.

 

[yodon]

62304 doesn't require risk management for Class A. (Not necessarily a bad idea to do it anyway just to make your software more robust!)

The pre-control probability score should be set to the highest value in your approach. This ensures the severity drives the actions. Your controls can certainly reduce the probability score.

 

[Sravan Manchikanti]

Thank you Yodon!

 

[mihzago]

Please remember that the probability of a defect occurring is not the same as the probability of harm resulting from that defect. There's usually a sequence of events before harm occurs, with the defect typically being the initiating event.

 

[Sravan Manchikanti]

Dear Mihzago,

Thanks for the input, my interest here is the application of risk management process to a SaMD.

Please remember that the probability of a defect occurring is not the same as the probability of harm resulting from that defect. There's usually a sequence of events before harm occurs, with the defect typically being the initiating event.

Can you please explain the same with an example. The concept is pretty confusing!

How does this translate in to the risk documentation?

Thanks in advance.

 

[Tidge]

I believe @mihzago is referring to P1 (probability of a hazardous situation occurring) and P2 (probability of a harm occurring because of the hazardous situation). Not everybody uses P1/P2, but even folks that don't use it should be familiar with the concept.

This will come across as simplistic, but for software you should always assume that P1 = 1. Whether you look at this as "the hazard situation is always going to be occur" or (in a software risk analysis context) "the software is always going to have this defect" it really makes no difference. The only way to effectively reduce this P1 is implement requirements to address that risk and perform testing that proves the implemented control (for software this is usually active code, occasionally it is something else) is doing what is required.

There are subtleties, but 62304 explicitly mandates this sort of approach (requirements -> architecture -> implemented design -> testing) whereas other components of medical device design do not. Contrast software with batteries (or most other physical components): a priori, with the design choice of a physical battery it is possible to say that "only occasionally (P1<1) will a specific hazardous situation occur" and so some hazards and hazardous situations might not require controls (or the rigor of testing commensurate with controls). In the absence of (for lack of a better term) "standardized code" with a well-understood set of properties for the code.

Batteries may be too modern of an example, because of somewhat rapid technological changes. If it helps, think of physical components that have accepted industry standards like the flamability ratings of plastics, or the mechanical properties of threaded fasteners.

 

[Mark Meer]

...Can you please explain the same with an example. The concept is pretty confusing...

A common approach is to document "event" -> "hazardous situation" -> "harm" sequences.
For example:

• Event: Device is dropped and breaks
• Hazardous Situation: People exposed to sharp edges
• Harm: Cuts / Lacerations

Given such sequences that can result in harm, when assessing the probability of ultimate harm, you must therefore consider each probability. In this case:

• Probability of the event: "what is the probability that the device is dropped and breaks?"
• Probability of the event leading to the hazardous situation: "what is the probability that the break exposes people to sharp edges?"
• Probability of harm from the hazardous situation: "given the hazardous situation, what is the probability the harm manifests?"

The ultimate probability of harm for this scenario would be the product of the contributing events.

For software, "events" considered might be UI related (e.g. "operator incorrectly configures some setting"), or bug (e.g. "glitch causes software to behave unpredictably"), and in these cases it is prudent to assume a probability of 1 for the event (i.e. an operator will, at some point, err - or an unforeseen bug is inevitable). Given the event->hazardous situation->harm sequence, however, the probability of harm from such "inevitable" events will not necessarily also be inevitable.

 

[Sravan Manchikanti]

Dear Tidge & Mark,

Thank you very much for your helpful inputs.

Not everybody uses P1/P2, but even folks that don't use it should be familiar with the concept.

That's a relief..!!

With multiple readings of the standards like 62304, 14971 and 80002-1 and detailed inputs from you, I could understand that it is very difficult to quantitatively estimate the probability of occurrence of a software failure (as it involves sequence or combination of events leading to a hazardous situation) and hence probability for the software failure occurring should be set to 1 (In practice, it should be given the highest probability in our risk matrix, e.g 'Level 5 - Frequent' for all hazards). That way, the initial risk estimation should be focused on the severity of the harm resulting from the hazardous situation.

The only way to mitigate the risk is with proper risk control measures. Based on the effectiveness of the risk controls, we can reduce the probability to less than 1 (i.e by assigning lower probability levels. E.g As per our probability scale... level 1-Improbable, level 2-Remote, level 3-Occasional or level 4-Probable). However, in most of the cases the initial Harm severity would be the same.

Am I correct in my understanding?

Further, IEC 80002-1 in section 4.4.3 says that

In summary, software RISK ESTIMATION should focus primarily on SEVERITY and the relative probability of HARM if a failure should occur rather than on attempts to estimate the probability of each possible software failure.

NOTE This helps provide distinctions between HAZARDS of the same SEVERITY to allow greater focus on those with higher probability of actual HARM.
.

IEC 80002-1 in section 4.4.3 says uses the term relative probability (which I found only in this standard.. Correct me if am wrong). How does this concept work in practice?

Thanks in advance.

 

[Tidge]

In the P1/P2 approach, P2 is the "probability of a harm (occurring because of the hazardous situation )". In my opinion the word 'relative' in this context should be taken to mean that: within your system of risk estimation, there is some scale of P2s, relative to each other.

A common approach (inspired by Failure Modes and Effects Analysis, no doubt) is to use integers, with the larger values carrying more weight relative to the smaller values.

 

[vspokkuluri]

Risk Management is a reiterative process. That means using Edward Deming's PDCA is exactly what EU MDR (2017/745) refers to the concept of ALAP (As Low As Possible) which has replaced the previous concept of ALARP. Applying the probablity of occurence as defined in common practice with integer that has been assigned randomly is the commencement of the risk identification and analysis cycle.

However, product reviewers (from NB) have chance to raise query how did one assign such trivial number to the probability. So in practice, this will be through regular practice of Plan and when 'Doing' the risk analysis we validate such use considering 'level-1' as improbable, the later iteration of risk analysis PLAN should consider the previous lessons taken onboard. This considers customer complaints, CAPA, internal audits and other process systems. And, in the second or later iterations use of such integer starts to pay for itself why it has been assigned there. If not, the probability will increase and risk controls addressing such risk mitigation and how the later trends on customer complaints have reflected such PDCA iteration will justify reducing or increasing the probability.

This is probably one of the reasons for MDR calling for Risk-Benefit Analysis.