Where does FMEA fit in your ISO 14971 Risk Management process?

[Marcelo]

Therefore I am happy that in the 2019 revision this will be fixed.

Not totally fixed, unfortunately :-(.

 

[Jean_B]

I disagree that FMEA should be removed, nor renamed. We're not in marketing-land where changing such things makes the underlying issue goes away while maintaining the benefit. Besides this, it seems many still want to do the activities and see the value in having the outputs associated with that method.

My preference would be to eliminate FMEAs entirely from the 14971 RM process.
First, they do not address the normal condition. Second, it seems they are rarely performed well--compare typical results and online examples (e.g. 'component failure' is listed as a failure mode) to the stipulations of and samples in IEC 60812:2018 or :2006.
However, given their pervasivenss, FMEAs can be useful as a familiar means to associate fault conditions and their consequences.

Naturally they do not address the normal condition; there is no single method which adequately covers all modes of operation, conditions and subjects. A lack of adequate execution of a method is also no reason to void the validity of the method; it would be an indication to look at the manner in which the associated competencies are attained, assessed and enforced per case. The FMEA (and any other) method should not and cannot cover for the underlying assumptions that they are performed by competent personnel. An FTA by a team which lacks necessary competence or resources will fair just as badly, just in a different way.

From my experience in two of the companies I've worked at, FMEA is to further break down your hazard analysis. Start with a preliminary hazard analysis (or PHA) to give you a sense of where the hazards are. From there, you do a much more in-depth analysis through an FMEA, to find the causes, the hazardous situations that give rise to the hazards, and the harm. FMEA requires team work and it's better to gather all your design people in one room and brain storm. Finally, for each risk identified, you decide what type of mitigation measure should be conducted. Let me know if this is clear. Anyone else has better suggestions, I would be interested to know.

While the brief summary is correct for what it describes (exception being that hazards do not arise from hazardous situations; harm might arise from hazards through hazardous situation), it stops a bit early. FMEA's are iterative projects that initiate changes on specified inputs and associated mattters. A common and crucial mistake comes from the lack of splitting recommended action and its associated follow-up (selection, implementation, effectiveness verification) from the confirmed end state. Once you complete those iterations it will be anchored.

Also, it's important to get the vocabulary right. I have read instances where people do not know the difference between a hazard and a hazardous situation.

While important, this is a matter of competence that applies at all times. It's not an argument to remove a specific method. Even then, I love the source of harm definition with all its faults, as interpretations may still vary from naturalistic aspects (electricity, gravity, heat, abrasion), to parts/components which incorporate or exhibit such aspects, to symptoms of such matters (sharpness, hot surfaces) and which to include or not. If something is a source something needs to be a sink, and there's a channel inbetween.

I like this discussion as this reflects my experience in that field.
I would agree that the term FMEA should be eliminated in the context of Risk Management. It is often used as a synonym for the risk analysis, however, if the Risk Management File only includes documents like dFMEA, pFMEA, etc. I already would judge that this Risk Management process is not well understood.

I couldn't conclude that. Consciuous choices by competent but resource-constrained people might well understand the process and deem it minimal compliant. Another concious choice that could be made is to integrate aspects or exclude matters (remember! Risk management includes determining scope for detailed risk analysis based on preliminary assessments). Do not mistake an excel layout for the method. A specialised FMEA software solution may very well show a hybrid of BOM-based FMEA, Process-extended BOM-based for pFMEA and HACCP variants for contaminant consideration, FTA in linking those failure modes for risk in multi-fault conditions and risk calculation for fault propagation, HAZOP in assessing subvariants and even normal conditions further extended by consideration of interaction through usability/human factors, utility analysis for risk-benefit calculations, acceptability criteria based on risk-iso curves, etc all aided by facilitation techniques such Brainstorming, Delphi, expert-decision systems, etc; and because we're human, shown summarized (perhaps with lots of underground calculations based on all those interrelations) in that most ubiquites and intuitive of formats: the component based FMEA row.

The basic principle is that at least two methods should be used (a bottom-up and a top-down method). In practice, you should look from the hazard-perspective (e.g., which hazards are relevant for my product, which hazardous situations could occur) and from the sequence of events perspective (how is the product being used, what can go wrong or what can happen if nothing goes wrong). This would ensure sufficient coverage of the risks.

And once again, the use of those two methods, when miss-applied doesn't guarantee adequate risk management coverage. If your scope is too narrow going up or down, you're too narrow either way. If your missing a hazard going down, you might as well miss it going up as it might be related to the team selected for either instead of the method.

I agree with what was said about the vocabulary. This is one of the significant issues that the terms hazard, hazardous situation, and harm are not considered when performing the risk analysis.
Even the examples for hazards in the current ISO 14971 are always compatible with the definition. E.g., the hazards related to labeling are from my perspective not in line with the definition. Therefore I am happy that in the 2019 revision this will be fixed.

I know of no standard that integrates these general concepts (including risk) in the specific verbiage within the method (most likely due to legacy reasons), and neither do I know of any attempt to standardize this across all of them (the irony). We'll probably be a few decades before that is viable.
As such the field of (medical device) risk management tries to solve as much that of which it suffers, and it is probably due to the same reasons: differences in alignment of interpretation due to experience (we're getting there!, just some more iterations), differences in alignment of necessity due to culture (In that sense I love the risk-based ABC necessity principle of the IEC 62304, which could expedite alignment here by at least converging the levels into one standard instead of overlapping competing standards), lack of urgency (global and local societies are generally experiencing the current efforts as currently sufficient, give or a take government politics having to deal with some major incidents), more value seen in execution than in preparation (addressing lack of competency/training is foregone for early results), lack of available resources for development (work within the system or on the system; short term benefits versus long-term potential benefits).

 

[Achilleas]

My understanding is that the results of FMEA activity do not necessarily have to be linked with ISO 14971 risk records, but here are some approaches that you could consider:

FMEA on complex systems can be performed in a hierarchical manner, starting from subsystems and moving up to system level. The effects identified during FMEA of a low-level subsystem are the failure modes to be analyzed during FMEA on the next level subsystem.

The results of the top-level FMEA can be used as risk records according to ISO 14971 and be linked with hazardous situations, harms, P1, P2, etc.

An alternative approach is to establish traceability between the results of the top-level FMEA and the outcome from other top-down risk analysis activities like FTA. This will ensure the thoroughness of the top-down analysis, making sure that there a no high-level risks & sequence of events that have not been considered and also support the estimation of P1.

 

[Achilleas]

You can also check the approach proposed in the book Safety risk management for medical devices by Bijan Elahi. It includes several great concepts that can be adopted partially or as a whole to your risk management process.