Calculating Risk Estimation

Jen Kirley

Quality and Auditing Expert
Leader
Admin
I agree it is useful to look past the fact that a medical device is not an automobile, as the principles for FMEA are the same and in medical device we do point to AIAG training in these topics because there is no medical device industry equivalent to the Core Manuals.

Please be patient while I run through the basic points:
1) The criteria for assigning risk levels in each category should be well defined and well understood so there will be less risk of escapes.
2) High Severity should be given at least equal consideration as high overall RPN, based on the cost of getting it wrong and harming end users.
3) RPN is very often relied on to prioritize, but a business could bleed to death from reputation degradation resulting from low-level failures. Business decisions for taking action on lower RPN results should be allowed based on known customer wants.
4) Do revisit the FMEA from time to time, especially after unanticipated failures are discovered (it is difficult to anticipate everything) over time. This is why auditors ask if FMEA was reviewed after a nonconformity occurred.
 

Tidge

Trusted Information Resource
With respect... this is the ISO 14971 subforum for Medical Device Risk Management. Medical devices are a VERY DIFFERENT industry with radically different worldwide regulatory concerns than automobiles.

"Degradation of reputation" is not a recognized harm in the 14971 sense. Nor are "OSHA" concerns... perhaps that can give you some idea of how particular 14971 is about patient/user/stakeholder risks. The general FMEA/RPN advice is perfectly appropriate in other areas; for medical device manufacturers bringing these sorts of points up are essentially trying to pick a fight from a position that was lost a decade+ ago. As someone with familiarity with what Ford Motor Company was doing in the late 1990s and early 2000s... and saw how a medical device manufacturer tried to implement a similar FMEA-based scheme... the results were VERY UGLY as soon as the first serious 14971-related audit occurred.
 

Jen Kirley

Quality and Auditing Expert
Leader
Admin
Thank you Tidge, you are of course quite right that this is the ISO 14971 subforum and there are portions of the Core Manual that don't apply to medical instruments.

All that being true, please note that I said the principles are the same. Of course it is better to use ISO 14971:2019, but should we omit business risk because it isn't listed in there?

I haven't seen medical device equivalents to AIAG's Core Manual trainings, am I missing something?
 

Tidge

Trusted Information Resource
All that being true, please note that I said the principles are the same. Of course it is better to use ISO 14971:2019, but should we omit business risk because it isn't listed in there?

I haven't seen medical device equivalents to AIAG's Core Manual trainings, am I missing something?

One (potentially major) issue with considering business risk in the context of a 14971-compliant RM files is that there are requirements to estimate overall residual risk, and to conduct a benefit-risk analysis of the overall residual risk. If the RM file includes business risk (and occupational safety issues of assemblers) it becomes incredibly difficult to pass a 'red-faced test' when asked if those identified risks are directly influencing the overall risk analysis when it comes to patients and users. Another potentially big issue is that It doesn't matter how well-motivated those lines of analysis may be in a holistic business sense, they simply confuse the RM files for medical devices and there becomes a real possibility that efforts that are supposed to be spent on patient/use safety (e.g. periodic risk reviews) are being spent maintaining/evaluating lines that don't contribute to that mission.

In my experience: FMEA are particularly vulnerable to becoming overwhelmed by the "trivial many" problem, for two immediate reasons. The first is that there is no practical limit to the number of ways things can fail. In medical device risk management, we simply don't have the luxury to NOT reduce all risks to the point of acceptability (blah, blah, "as far as possible", fishcakes) so the "trivial many" must take as much effort as the "vital few". The second vulnerability is that the "trivial many" can lead to a distorted sense of overall acceptability... I'm not saying I've seen this in practice, but it could be tempting to make an FMEA look "more acceptable" (in an overall sense) by increasing the fraction of "low RPN" lines. I want to believe that most seasoned professionals would see right through this, but I am not convinced that casual practitioners would... if their first instinct was to satisfy 14971 through only an analysis of failure modes.

IMO, avoiding these sorts of vulnerabilities requires more effort that and more overhead that ultimately just confuse the original (and accepted) purpose of FMEA.... which is why so many of us 14971 practitioners may appear to be butting heads with others who don't routinely work in this space.

Annex B of TR 24971 has information relating to different techniques that support a 14971-compliant risk analysis; FMEA and FMECA point to (the general purpose) 60812. FTA points to 61025 (also general purpose). ETA points to 62502. HAZOP points to 61882.
 

MrTetris

Involved In Discussions
FMEA can and actually should include Detection. The problem is that using FMEA is not sufficient to be compliant with ISO 14971, as this standard defines risk as a combination of probability and severity. Moreover, FMEAs topically focus on failures, while the ISO standard requires to consider potential misuse as well. Therefore, FMEA can be used in the medical industry, but just as a “back-end” risk analysis behind the ISO 14971 risk charter. To answer the original question, I believe that option A is the correct to follow, as a preliminary version of the risk analysis must be carried on in the first steps of the design, and assuming that some inherent control “will be there” is not correct.
 

MrTetris

Involved In Discussions
FMEA can and actually should include Detection. The problem is that using FMEA is not sufficient to be compliant with ISO 14971, as this standard defines risk as a combination of probability and severity. Moreover, FMEAs topically focus on failures, while the ISO standard requires to consider potential misuse as well. Therefore, FMEA can be used in the medical industry, but just as a “back-end” risk analysis behind the ISO 14971 risk charter. To answer the original question, I believe that option A is the correct to follow, as a preliminary version of the risk analysis must be carried on in the first steps of the design, and assuming that some inherent control “will be there” is not correct.
Moreover, pragmatic thought: if you already include inherent design controls in the first risk evaluation, you might end up with no-controlled risks, which might not be accepted (or difficult to be justified) in Europe, as MDR requires a AFAP approach in risk control.
 

Enghabashy

Quite Involved in Discussions
My product design already has the inherent risk control because I already planned it in the Product requirements document (origin of the requirement is the basic knowledge of the engineer), so when I am calculating my risk (probability of occurrence of the hazardous situation) should I consider the control I already planned in my design?
For Example:
Hazard- electric shock,
Hazardous situation- wire is exposed which can cause electric shock
Harm- The user can get a mild electric shock
Probability- option A: 4 (because wire getting exposed is high chances without the control)
option B: 2 (because my inherent design consists of insulating coating on the wire which reduces the probability)

PS: I am making my risk file in the product design phase itself.
The Q. is : should I consider the control I already planned in my design?
Answer : Yes , the status before & the status of after adding the controls should be documented in the FMEA , after adding the controls & monitoring we shall see that the severity is reduced , the detection , the error proof & alerts could reduce also the relevant score also , the received data of complaint or field failure could be measured also & found that they are reduced ,,,, all these historical data could be useful as basic of studying another process or similar design
 

Enternationalist

Involved In Discussions
A point of clarification: severity is rarely (never) reduced; the probability of occurence is reduced.
Severity can be eliminated if the failure/effect or hazard/harm is eliminated…Controls and mitigation are intended to reduce the occurence

To add to this discussion, I've found that severity can be "reduced" usefully in the context of branching sequences of events. For example, let's say we have a situation where a patient is on a moving platform and could hit their head during the movement - and let's say that's a serious severity. For our risk controls, maybe we reduce the maximum speed of the platform and ask the patient to wear a helmet. For the worst-case severity, let's argue it could still be "serious" but the probability is dramatically reduced - the worst case "risk" may now be the much more likely probability of a quite low severity outcome - some bruising and dissatisfaction, maybe.

This allows us to reflect the fact that, in a practical sense, we are reducing the severity of harm that will occur in most cases. I like to think of it as reducing the severity of a proportion of the possible outcomes. Yes, the maximum possible harm will very rarely change, but l don't want to get that twisted with an idea that we never reduce the severity of harms in a real sense; we do, fairly often, and in many cases the lower-severity case will be so much more probable that it can be considered the worse risk in both a real sense and in calculated "risk number" sense - even if we still keep track of "serious" harms that can occur.
 

Enternationalist

Involved In Discussions
@agrpyl I think people struggle a lot with the idea of "pre-control" and "post-control" risk, and a lot of people seem to end up artificially coming up with an imaginary "pre-control" device with unrealistically poor performance and features. This gets a lot more natural if you think of risk control measures as elements you add in to your sequence of events - an additional step that further reduces probability or the severity of harm.

When elements are already part of your design, you've simply included them in your sequences of events already - theoretically, they should already be design requirements that have their implementation verified, and their effect in the sequence of events should be backed with some evidence or analysis - which could be considered evidence of effectiveness. You already have most of what the standard asks of a risk control measure, so you may as well list it as such formally.

If you're honest with yourself in this way, I don't think there's really a conflict with the standard if you just document what you have now appropriately and keep it updated going forward. List the sequences of events as they exist now, and include risk control measures that are already in place - going back to imagine what a hypothetical design would have been like without them is, to me, wasted effort that doesn't actually make anything safer (other than what the standard already asks you to do, like considering the hazards the controls introduce).
 
Top Bottom