Software Risk Management & probability of occurrence as per IEC 62304

Sravan Manchikanti

Starting to get Involved
#1
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.
 
Elsmar Forum Sponsor

yodon

Staff member
Super Moderator
#2
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.
 

mihzago

Trusted Information Resource
#4
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

Starting to get Involved
#5
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

Quite Involved in Discussions
#6
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

Trusted Information Resource
#7
...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

Starting to get Involved
#8
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
IEC 80002-1 said:
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

Quite Involved in Discussions
#9
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.
 
Thread starter Similar threads Forum Replies Date
J Software for Techfiles and Risk management ISO 14971 - Medical Device Risk Management 1
M CE Marking and use of IEC 80002-1 for Risk Management of Stand Alone Software EU Medical Device Regulations 13
U Product Level Software Risk Management Plan and Report ISO 14971 - Medical Device Risk Management 2
N Minor Concern - Medical Device Software and Risk Management ISO 14971 - Medical Device Risk Management 2
M Risk Management in Software R&D Organization ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 4
N Best Software Program for Risk Management ISO 14971 - Medical Device Risk Management 4
K ISO 62304 Software Risk Management and Medical Device Class IEC 62304 - Medical Device Software Life Cycle Processes 5
Q Books / Literature: Risk Management for Medical Device Software recommendations Other Medical Device and Orthopedic Related Topics 4
Q Risk Management for Medical Software? IEC 62304 - Medical Device Software Life Cycle Processes 15
T Software to Manage Compliance to ISO 14971 (Medical Device Risk Management). ISO 13485:2016 - Medical Device Quality Management Systems 9
J Risk Management Software suggestions? ISO 14971 - Medical Device Risk Management 1
R Medical Device Software Risk Management and ISO 14971:2007 ISO 14971 - Medical Device Risk Management 7
C How is risk management handled in a software-based product ISO 13485:2016 - Medical Device Quality Management Systems 1
silentmonkey Rationalising the level of effort and depth of software validation based on risk ISO 13485:2016 - Medical Device Quality Management Systems 10
A Risk Number for each software requirement IEC 62304 - Medical Device Software Life Cycle Processes 7
B Risk Assessment Checklist for Non product Software IEC 62304 - Medical Device Software Life Cycle Processes 1
MrTetris Should potential bugs be considered in software risk analysis? ISO 14971 - Medical Device Risk Management 5
D Reduction of software class based on multiple external risk controls IEC 62304 - Medical Device Software Life Cycle Processes 5
T Risk analysis of QMS software - Validating software we use for QMS ISO 13485:2016 - Medical Device Quality Management Systems 5
B Software Class A - Lengthy further risk analysis IEC 62304 - Medical Device Software Life Cycle Processes 9
D Software as risk control - Confused on one aspect of IEC 62304 IEC 62304 - Medical Device Software Life Cycle Processes 20
I Medical Device Software Risk Analysis ISO 14971 - Medical Device Risk Management 4
Y Risk Control Implemented in Software IEC 60601 - Medical Electrical Equipment Safety Standards Series 6
A Assessing Risk for Medical Device Software ISO 14971 - Medical Device Risk Management 7
A 5.5.3 - Software Unit Acceptance Criteria (Risk Control Measures) IEC 62304 - Medical Device Software Life Cycle Processes 3
S Software Risk Estimation: Probability of Medical Device Software Anomaly Occuring ISO 14971 - Medical Device Risk Management 9
W Software Tool for Medical Device Risk Analysis - Recommendations please ISO 14971 - Medical Device Risk Management 4
A Software Risk Analysis training - Recommendations wanted Training - Internal, External, Online and Distance Learning 1
Q Risk Analysis of Software - ISO 14971:2007 ISO 14971 - Medical Device Risk Management 29
2 Risk Assessment according to ISO 14971 - Medical Device Software ISO 14971 - Medical Device Risk Management 7
T Software Supplier Risk Assessments General Auditing Discussions 0
K Software Updates in the Field and ISO scope ISO 13485:2016 - Medical Device Quality Management Systems 0
M Recurrent event analysis software (python) General Auditing Discussions 2
Y UL 1998 Standard: software classes Software Quality Assurance 0
P Need a programmer for QVI's VMS software for optical inspection machine Inspection, Prints (Drawings), Testing, Sampling and Related Topics 0
S IEC 62304 software costs and time Medical Device and FDA Regulations and Standards News 2
S IEC 62304 - Software verification cost IEC 62304 - Medical Device Software Life Cycle Processes 3
I Form templates for software (iso9001) Document Control Systems, Procedures, Forms and Templates 0
H Software Interface Translation IVD Regulation EU Medical Device Regulations 0
C 8.5.1.1 Control of Equipment, Tools, and Software Programs - Questions about the extent of control of NC programs AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 5
M IEC 62304 Software changes - Minor labeling changes on the GUI IEC 62304 - Medical Device Software Life Cycle Processes 3
T Do I need a qualified compiler for class B software? IEC 62304 - Medical Device Software Life Cycle Processes 3
S Manufacturing Execution Systems Software Costs Manufacturing and Related Processes 0
E 13485:2016, Sections 4.1.6, 7.5.6 and 7.6 - Validation of Software - Need some Advice please ISO 13485:2016 - Medical Device Quality Management Systems 2
R Medical Device Software Certification IEC 62304 - Medical Device Software Life Cycle Processes 1
S HIPAA-compliant monitoring software (advice needed) Hospitals, Clinics & other Health Care Providers 0
A Software bug fixes after shipping a product EU Medical Device Regulations 3
J Medical software Patient outcome Medical Information Technology, Medical Software and Health Informatics 2
Y We are Looking for EASA LOA TYPE 1 experienced software developer Job Openings, Consulting and Employment Opportunities 0
F Grand Avenue Software, Q-Pulse or Qualio - which for a full eQMS? Medical Information Technology, Medical Software and Health Informatics 1

Similar threads

Top Bottom