Risk Analysis of Software - ISO 14971:2007

Q

QMS eager - 2010

#1
Hello Everyone,

We had our Risk Management Process and Risk Analysis (ISO 14971, software-only medical device, class IIa (MDD)) sent to our Notified Body for pre-revision. We got some comments back which I would appreciate to get some additional thoughts about.:thanks:

Validation as Risk Reduction
We have used validation as a Risk Control Measure, which was not entirely appreciated by the NB as they considered Validation only as a way to confirm that the products benefits outweights the risks. Our software performs volume estimations and we have therefore used validation (perhaps it should be called VERIFICATION?) studies to confirm that the volumes are correctly measured and have considered these validations as a way to reduce the risk of hazardous situations raised by incorrect volume estimations. This now don´t seem to be the way to do it. Does anyone have any suggestion on how we can re-evaluate our thinking?

Probability for Software

In IEC 62304, as well as in other standards, probability are questioned as a tool to estimate the risk in software devices. However, for hazardous situations caused by systematic software errors, we have chosen to estimate the probability as 1 until we have Test Records verifying that the errors are not present, then we have reduced the probability to 0 and henced considered the risk reduced to an acceptable level. This approach was also questioned by the NB, which prefered that risks from systematic/software errors should be based on the Severity ONLY. Then my question is - how can I reduce the severity caused by a systematic error using risk control measures, if testing is not the way of doing it?
Thanks!
 
Elsmar Forum Sponsor
D

danpa

#2
QMS eager,
Good questions that many of us in the software world have.
For validation of risk reduction, it would probably help to trace your mitigation to the requirements that describe how the algorithm for volume estimation works and then be able to trace those requirements to the testing that verifies the requirements. When pointing to requirements make sure that the requirements have been reviewed/apporved by appropriate, qualified people.

I dislike the software error equals "1" probability approach for product risk mgmt. The software cannot harm people, only in the context of a system can software contribute to harm. I think it is more appropriate to analyze the probability of the system (software in use) - even if the product is "software only", there is a person and hardware involved with using the software - the people and hardware can have significant impact on the safe use of the software. With a systems view you do not have the binary probability issue.

If a product reduces severity or probability is more based on the type of product. I have found that a lot of software products deal with analysis, planning and visualization and as such, it is often very difficult to reduce severity in these products, but they can use various approaches to reduce the probability that harm would be caused when using the software. In fact, for my companies software only products we almost never reduce severity during risk analysis.
 
J

jscholen

#4
You can never reduce the severity of a failure. Example: Death of a person will always be the highest of any severity scale.

You can only reduce the occurrence of a failure.
 
K

Kary13

#5
OK... I went through the same principle not so long ago so I'll try to explain the way we did it which so far we get good comment from...

First, when I started the risk analysis, I did it as if it had been done at the beginning of product life-cycle. As a matter of fact, this is where the initial version of the risk analysis should be done (around the architectural/detailed design step), but constant revision of it shall be considered (especially when you have a design change). If you start from that principle, verification/validation cannot really be seen as a way of mitigation since the product has not been built yet! Type of mitigation can be:

  1. Design choice preventing that specific hazards (or reducing the probability of occurance)
  2. Addition of a protective measure
  3. Information on safety/hazards clearly passed on to user (instructions for use)
After product is built, you are right that verification/validation is required to ensure safety and performance of the device, i.e. to verify that the software performs as it was intented to do. Verification/validation should always be performed to verify design requirements, but design requirements should consider the outputs from the risk analysis among other things.

I am not sure it is clear, but this is how I see it... ;-)
Good Luck!
 
A

alexander73

#7
It's useful for the inquirer to investigate AAMI TIR32:2004 "Medical device software risk management". You will find the reply there.
 
D

danpa

#8
jscholen,
I would disagree, sometime, especially with physical devices the severity of an issue can be reduced. For instance, if an injury can be caused by something falling onto a person, we may not be able to reduce the risk that the object will fall, but we be able reduce the weight (by remoting the power supply) of the falling object, thus reducing the severity of the injury caused. Similarly, our chooses of chemicals used in a product can significantly effect the severity of incidents.
 
J

jscholen

#9
That depends on how you define the failure. If your vague in your injury, ie, patient injury due to falling object, then yes. But if your failure is specific, broken toe, laceration, then the severity of injury doesn't change.

IMHO, I would question anyone's risk analysis if failure modes were not very specific. It doesn't show alot of thought.


But if you bring flowers to the funeral.....?
with a check$$$...:yes:
 

Marcelo

Inactive Registered Visitor
#10
"You can never reduce the severity of a failure. Example: Death of a person will always be the highest of any severity scale.

You can only reduce the occurrence of a failure."
You can surely reduce the severity of a failure. This is the principle behind ISO 14971 - reduce likelihood of ocurrence OR reduce severity of harm.

In the "death" case you cited, if the failure which has a death severity, after some control measure, turned out just to cripple :) the subject, the severity would be reduced.

IMHO, I would question anyone's risk analysis if failure modes were not very specific. It doesn't show alot of thought.
This is because everyone generally thinks about risk ANALYSIS and general HAZARDS..when they should be thinking about risk MANAGEMENT and HAZARDOUS SITUATIONS.

This was one of the points made clear in the new edition of ISO 14971...although...i´m still seeing a lot of people that thinks that it´s all the same....
 
Thread starter Similar threads Forum Replies Date
MrTetris Should potential bugs be considered in software risk analysis? ISO 14971 - Medical Device Risk Management 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
I Medical Device Software Risk Analysis ISO 14971 - Medical Device Risk Management 4
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
D Risk Analysis using Monte Carlo Simulation instead of Scoring and Heat Map Risk Management Principles and Generic Guidelines 0
E Normal Condition Hazards in Risk Analysis ISO 14971 - Medical Device Risk Management 3
M Risk Analysis Flow - Confusion between ISO 14971 and IEC 62304 IEC 62304 - Medical Device Software Life Cycle Processes 8
R ECG Risk Analysis Standards ISO 14971 - Medical Device Risk Management 2
adir88 Documenting Risk Control Option Analysis ISO 14971 - Medical Device Risk Management 8
M IATF 16949 (6.1.1 - Planning and Risk Analysis for a remote site) Process Maps, Process Mapping and Turtle Diagrams 5
D Risk Analysis & Technical File - What detail goes in the Risk Management Report ISO 14971 - Medical Device Risk Management 5
M An example of risk analysis of class I MD ISO 14971 - Medical Device Risk Management 36
B Grouping of Products for Risk Analysis ISO 14971 - Medical Device Risk Management 9
A Risk-benefit Analysis - Hazard Analysis (HA) and FMEAs ISO 14971 - Medical Device Risk Management 18
R The difference b/w FMEA & Risk analysis as per iso 14971 ISO 14971 - Medical Device Risk Management 8
K Risk Analysis Updates due to complaints ISO 14971 - Medical Device Risk Management 10
S The Severity of a Medical Device Hazard - Risk Analysis Clarification ISO 14971 - Medical Device Risk Management 6
Ed Panek Transition to IEC 60601 4th Edition - Risk Analysis and test submissions CE Marking (Conformité Européene) / CB Scheme 2
S In a risk analysis, how can we tie mobile app security breach to ISO 14971? 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 4
Q Risk / benefit Analysis in Risk Management Report CE Marking (Conformité Européene) / CB Scheme 12
R IATF 16949 Clause 6.1.2.1 - Lessons Learned and Risk Analysis IATF 16949 - Automotive Quality Systems Standard 6
S Risk analysis 6.1 and contingency plans 6.1.2.3, are they related? IATF 16949 - Automotive Quality Systems Standard 26
W Biocompatibility Risk Analysis for Clinical Practitioner 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 4
F Risk Analysis of a Medical Device Accessory ISO 14971 - Medical Device Risk Management 4
S How we can use risk analysis for suppliers IATF 16949 - Automotive Quality Systems Standard 6
Q Risk Analysis - Same Risk Treatment for Context and Interested Parties ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 7
C Risk Analysis for COTS/OTS Risk Management Principles and Generic Guidelines 4
M IATF 16949 Cl. 8.7.1.4 - Risk analysis for decision making about rework IATF 16949 - Automotive Quality Systems Standard 2
E Risk Analysis - Events which may cause to Data Loss ISO 14971 - Medical Device Risk Management 12
W Risk Benefit Analysis - ISO 14971:2012 Requirements ISO 14971 - Medical Device Risk Management 27
F Medical Device HACCP (Hazard Analysis and Critical Control Point) Risk Management ISO 14971 - Medical Device Risk Management 2
Q Risk Tools in ISO 31010 - Root Cause Analysis vs. Cause-and-effect Analysis ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 1
S Organizing Risk Analysis and Controls for a New Medical Device (ISO 14971) ISO 14971 - Medical Device Risk Management 4
S Please review my Risk Analysis Table ISO 14971 - Medical Device Risk Management 13
K Risk Analysis and "Information for Safety" / Labeling ISO 14971 - Medical Device Risk Management 10
M Risk analysis - ISO/TS 16949 clause 7.2.2.2 IATF 16949 - Automotive Quality Systems Standard 2
C Help with Risk/Benefit Analysis Self-help Device for Diabetics ISO 14971 - Medical Device Risk Management 3
A FTA-Top/Down approach to Risk Analysis ISO 14971 - Medical Device Risk Management 2
A Industry best practice about Post-Market Surveillance and Risk Analysis ISO 14971 - Medical Device Risk Management 6
T Risk Analysis help for CE Marking Class I Medical Device ISO 14971 - Medical Device Risk Management 10
T Risk Analysis for moving manufacturing equipment ISO 14971 - Medical Device Risk Management 17
D Different kinds of Risk Analysis for various Hazards ISO 14971 - Medical Device Risk Management 3
L GHTF/SG3/N15R8 - Process Validation and Risk Analysis ISO 13485:2016 - Medical Device Quality Management Systems 4
R Risk Analysis of Class IIb Disinfectant ISO 14971 - Medical Device Risk Management 6
J Does anyone have an example of Risk-Benefit Analysis per ISO 14971? Other ISO and International Standards and European Regulations 2
P FMEA Risk Analysis Recommended Action Priority FMEA and Control Plans 2
N ISO 14971 Risk Analysis - Sections 4.2 and 4.3 ISO 14971 - Medical Device Risk Management 2
D ISO 14971 - Risk Analysis Best Practices ISO 14971 - Medical Device Risk Management 5

Similar threads

Top Bottom