What's wrong with DFMEA? shows an excerpt of an FMEA risk table

What’s Wrong with DFMEA?

Leave a Comment / Risk Management, V2025 / By

This article is based on my LinkedIn post from 7/22/25 that received a large number of comments. I’ve added many of the comments at the end since they expand on the article and capture the complexity of this topic (there is no simple recipe for risk assessment). Readers who are new to FMEA methodology may want to start with this introductory information: What is FMEA? (ASQ).

Serious Shortcomings

Many medical device development teams still rely on Design Failure Modes and Effects Analysis (DFMEA) as their primary and only risk assessment tool. DFMEA is a well-established method used in many industries. However, there are serious shortcomings to this method for medical device risk management:

  1. Hazardous situations and harms can occur without any hardware or software failures (for example, due to use errors). Therefore, even a very detailed DFMEA is not by itself comprehensive.
  2. Typical DFMEA methods (per the IEC 60812 standard) focus on single point failures and do not capture sequences leading to harm. 
  3. DFMEA depends on details of hardware and software design that may not be available until later stages of development so there is a strong incentive to wait until later before beginning risk analysis.
  4. DFMEA doesn’t align well with the requirements of the ISO 14971 medical device risk management standard. DFMEA analyzes the reliability of a system, which may or may not cause Harm in a medical device. And RPN values used in a DFMEA can be misleading if they depend on detectability for reducing risk.
  5. In a complex, software-intensive medical device there are many, many potential hardware/software failures but only a fraction of them may lead to serious Harm (it’s easy to lose focus in a large set of data).
  6. DFMEA is an inefficient way to support complaint handling because users tend to complain about hazardous situations but not failures of hardware and software.

I’m not saying there’s no role for DFMEA in medical device risk management, just that it shouldn’t be the first and primary method of risk assessment. Instead, I recommend starting early in product development with a top-down, high-level, comprehensive approach such as a System Hazard Analysis (sometimes called Preliminary Hazard Analysis) or Fault Tree Analysis (FTA) or similar method. This initial high-level analysis quickly produces a broad picture of the new product’s risk profile and can point to areas that deserve detailed bottom-up analysis with one or more focused DFMEAs. By starting early in development with a high-level risk analysis and following it with one or more DFMEAs, the product team makes the best use of complementary risk analysis tools.

Integrating DFMEA into a broader set of processes for risk management

To better suit the needs of medical device safety risk management, it’s important to consider carefully the standard FMEA methodology and format. Traditional FMEA defines the effects of failures and therefore focuses on system reliability. The ISO 14971 risk management standard focuses on Harm (primarily to patients and users). Therefore, when an FMEA is used for medical device risk management there needs to be a way to connect a system effect with a Harm. A simple way to do this is to add columns for Hazardous Situation and Harm to the FMEA table to align with the ISO 14971 risk model. But that’s not the only way–there are multiple other ways to integrate the output of an FMEA to the overall processes for risk management. The important thing is to accept that a traditional FMEA methodology and format alone is not sufficient for medical device safety risk management.

Another area of concern with FMEA is with calculations of RPN (Risk Priority Number). Typically, RPN is the product of the Severity x Probability x Detectability. This approach has two main drawbacks for medical device risk analysis:

  1. Detectability can easily be overestimated for a fault condition, resulting in an inappropriately low RPN. For example, to an engineer, a device that beeps with a red flashing light is clearly detectable. However, if that device is in a crowded operating room in a hospital, with lots of beeping equipment, the fault condition may not be detectable at all to the surgical staff.
  2. There are often ‘corner  cases’ in the set of all possible permutations of Severity, Probability, and Detectability that lead to inappropriate RPN values. Some companies make complex weighting and algorithmic formulas to overcome this problem.

Because of these issues, I recommend dropping RPN calculations altogether and just using a simple lookup table based on Severity and Probability of Harm to determine a Risk Level (often represented as a red-yellow-green matrix in risk documents). The exception to this recommendation is for Process FMEA where detectability can be realistically estimated in the controlled environment of a manufacturing line.

Links to more detailed discussions of misuse of DFMEA

For more in-depth discussions of these issues, I recommend these free resources:

Non-DFMEA Risk Assessment Methods

Since I stated that DFMEA should not be the only method of risk assessment for medical devices, here is a list of common risk assessment methods that are complementary to a DFMEA. Note that there is no one perfect method for risk assessments.  It’s the combination of methods that’s most effective for ensuring medical device safety.

A good place to start in learning about alternatives to FMEA is the TIR24971:2020 guidance. This guidance, that accompanies the ISO 14971 risk management standard, is full of useful information. In Annex B it lists four risk assessment methods in addition to FMEA:

  • Preliminary Hazard Analysis (PHA) is a technique that can be used early in the development process to identify the hazards, hazardous situations, and events that can cause harm when few of the details of the medical device design are known.
  • Fault Tree Analysis (FTA) and Event Tree Analysis (ETA) are especially useful in safety engineering, early in the development process, for the identification and prioritization of hazards and hazardous situations and possible risk control measures as well as for analyzing the consequences of adverse events.
  • Hazard and Operability Study (HAZOP) is typically used in the early stages of the development process to study deviations from the intended performance.
  • Hazard Analysis and Critical Control Point (HACCP) is typically used in the later stages of the development process to verify and then optimize design concepts or changes.

Note that FMEA is described in Annex B as “a technique by which effects or consequences of individual components are systematically identified and is more appropriate as the design matures and the failure modes are better understood.”

Here are additional risk assessment methods mentioned in comments on LinkedIn:

  • Safety Assurance Cases are structured arguments, supported by evidence, that demonstrate a device’s safety for its intended use. They are used to justify claims about a device’s safety, effectiveness, and performance, and to provide a clear and organized presentation of the rationale and evidence behind those claims.
  • Parameter Diagram (P-Diagram) is a structured tool that identifies the inputs to a system and relates those inputs to the desired system outputs, while considering the controlled and uncontrolled factors. It is useful in brainstorming and documenting, and helps the FMEA team understand and make visible the robustness of the design that is being analyzed. It can provide important input to System and Design FMEAs.
  • Functional safety per the IEC 61508 standard which provides functional safety standards for the lifecycle of electrical, electronic, or programmable electronic (E/E/PE) systems and products. It addresses those parts of a device or system that perform automated safety functions including, for example, sensors, control logic, actuators, and micro-processors. It provides a rigorous quantitative approach to risk reduction and can be applied across many industries.

 

Commentary and Discussion

When I first wrote a LinkedIn post on this topic in July 2025, many risk management experts provided detailed comments that expanded on what I wrote. I’ve summarized their comments below. Note that even though the ISO 14971 risk management standard has been around for over two decades, there are still debates (as there should be) about the best ways to comply with the standard.

Thank you to everyone who commented on the post, especially the following LinkedIn readers for their insightful comments:

FMEAs, Harms, and Normal Use

Joe Martin: One of the things I point out regarding FMEAs and risk is that FMEAs don’t take into consideration harms related to normal use. Getting an X-Ray or receiving chemotherapy both have direct harms related to normal use that are unavoidable but must be taken into consideration when weighing benefit vs risk.

LeeAnn Fox: FMEAs aren’t the place to evaluate harm. They evaluate failures. The Risk Management Matrix (some call it a hazard analysis) is where harms, including ones related to “normal” use should be evaluated. The “end user affect” from the dFMEA, if it is classified as a “critical to safety” failure, directly translates into the hazard in the hazard analysis (e.g. device shuts down is the end user effect in the dFMEA and the hazard would be “loss of function”).

Joe Martin: LeeAnn Fox, you’re absolutely right. Thanks for elaborating. The point I was trying to make was some manufacturers are so FMEA focused they lose track of the larger risk management picture.

Aaron: That’s right. A classical FMEA is focused on reliability whereas medical device risk management is focused on harm. The approach you describe is one I’ve seen with some companies but is not the only way to “connect” FMEAs with overall risk management (per ISO 14971). An alternative approach is to include Hazardous Situation and Harm directly in the FMEA as additional columns (which some people like and some people hate). There are multiple approaches that can work for medical device risk management as long as the people involved understand the limitations of FMEA.

Edward B: Just to add more depth to your first bullet:  Hazardous situations and harms can occur without any hardware or software failures, or use errors. Therefore, even a very detailed design FMEA is not comprehensive. This is where side-effects come from, from the normal conditions of use. E.g. an endotracheal tube placed in the throat. Everything could be fine in terms of design, manufacture, clinical placement etc. When that tube is removed, X% of patients will have a sore throat or cough. The body does not feel great about having a plastic tube getting in the way. No failure modes, just the body’s reaction to this foreign object.

Two-Tiered Approach

Mohammed Gamal: In our team’s experience, shifting to a two-tiered approach was transformative:

  1. Early SHA/PHA: Starting concept-phase with System Hazard Analysis forced cross-functional alignment on clinical harm scenarios before design froze.
  2. Targeted DFMEAs: Only for SHA-flagged high-risk subsystems, using modified templates:

Added ISO 14971-aligned “Hazardous Situation” & “Harm” columns and traced failures to use conditions (not just component reliability). The game-changer? Linking SHA outputs to DFMEA via traceability matrices. When a complaint hits, we now map user-reported hazardous situations directly to pre-analyzed harm pathways. Would love your thoughts on integrating UFMEA earlier to address those use-error gaps DFMEA can’t see.

Aaron: Those are great points and illustrate the benefits of combining different risk analysis methods. Regarding how to integrate UFMEA earlier, that’s a tricky one because user interfaces/user workflows tend to change a lot with software-intensive devices. I like to include use error in the SHA which provides an early high-level view of areas of concern but not the necessary details. Regular formative usability testing during development will provide a practical view of usability risks but I don’t know of a way to avoid many revisions to a UFMEA during development.

 

Nicola Wheeler-Thorn: Do you ever recommend doing both? And using the FMEA as an input document to hazardous failures that should be reassessed for risk?

Aaron: Yes, I consider a top-down hazard analysis and a bottom-up DFMEA to be complementary and they can identify different types of risks and therefore different risk controls. I always recommend starting with the hazard analysis, because it doesn’t require detailed design, then following with DFMEA later in development. But you’re right that the outputs of the DFMEA can often feed back into revisions of the hazard analysis. 

Eric Henry: Nicola Wheeler-Thorn , in my view, that’s exactly how it should work. FMEAs will have both safety-related and non-safety-related risks in them. I recommend a flag in the FMEA worksheet noting if it is a safety-related failure mode, in which case there would be a reference to the line in a safety risk analysis that addresses the failure mode as a hazardous situation and in terms of the likelihood and probability of harm and the mitigations that would reduce either/both. The mitigations for an FMEA and a safety risk analysis for the same risk may be the same or not, but the purpose is different. Mitigations for an FMEA are intended to reduce the technical effect of the failure mode, where mitigations in a safety risk analysis reduce the risk of harm.

Nicola Wheeler-Thorn: Eric Henry Absolutely! This is how we approach it for our clients and it seems to work well across different teams as well. FMEA is familiar as a starting point for engineering teams but hazard analysis accounts for much detail and fits better with overall quality and risk management teams. What are the risks you see about doing it this way around?

Nicola Wheeler-Thorn: Aaron Joseph Couldn’t agree more. We sometimes start the FMEA in cases where the design has been completed within concept testing or coming out of research institutes where the dev phases can be slightly different. This is mainly to engage the smaller teams in risk, and then move to wider risks in the hazard analysis.

Eric Henry: Nicola Wheeler-Thorn , I actually don’t make a big deal about starting with either the FMEA or the safety risk analysis. If it is a new product, often the user-oriented community within the organization gets first crack and will be in a position to do an early version of the safety risk analysis. For most changes, in my experience, the engineers often get to think about it first, and they go with their dFMEAs first. So long as there is a bi-directional feedback loop between them, it really doesn’t matter. Both sets of documents will be iterated repeatedly throughout the product lifecycle.

Nicola Wheeler-Thorn: Eric Henry Very true, and that’s why your recommendation on traceability between the two and the flag makes that bi-directional element part of the process effortlessly (well almost effortlessly haha)

Safety Assurance Cases

Dave Pouliot: The framework is ok, just drop the”D” and include sections or separate docs for all vectors of risk (System level, interfaces, cyber threat, human factors,etc).  Fubin Wu has some great tools for capturing and managing this info and presenting to regulators. I like to start with Safety assurance and then support it, ensuring all your docs are adding value.

Fubin Wu: I completely agree that effective risk management must ultimately serve its primary purpose—ensuring safety assurance. When applying the safety assurance case method, which relies on a logically structured, top-down argument to demonstrate that risks are adequately identified and controlled, the limitations of traditional DFMEAs become clear. A massive FMEA spreadsheet—spanning thousands of lines—does little to convince regulators that risks are completely identified and effectively controlled; in fact, it often raises more confusion and questions.

Our software tools (see GessNet) address this challenge by supporting both top-down analyses (e.g., SHA and FTA) and bottom-up approaches (e.g., FMEAs). Even if you start with only FMEAs, the tool can automatically transform them into a top-down view, offering valuable insights into gaps and inconsistencies.

Accessibility and Usability for Risk Analysis methods

Guy Criscenzo: What a great discussion. I think it’s revealing how many perspectives and takes there are on Risk Management, especially for an area so well documented and mandatory, for most. It also seems the discussion doesn’t include the human factor in implementing Risk Management. While just about everyone who is a stakeholder in Risk Management agrees having a well defined processes, effective training, and good participation and tools, is only a good thing, effectiveness in reducing risk suffers if you don’t apply risk management with a team who appreciates and is genuinely interested in reducing risk, and is allowed the time, early and during the product life cycle, to facilitate safety by design, even if that means sometimes putting the tool down as taking a step back to apply common sense and experience. “a poor craftsman blames tools”

 

Jean Blom: Though sensible advice when first coming to grips with the issue, it does not address the reasons. The reason for widespread FMEA use is that, by itself, it’s seen as the most comprehensible 20 effort/80 result solution touching ‘significant’ risk. For resource-constrained persons, regardless of level of knowledge, that makes it the first choice.

Yet its usability is its risk, leading to overly brief information due to cells, and other typical excel issues. Normal mode risk is often assumed to become part of overall residual risk, and presumed to be more up to the choice to use than to be managed. Expert bias/blindness feeds this.

Another major contributor to the issue are figures 1/B.1 of ISO 14971. People first visit/often go back to visuals. However, these pretend to display one process, but the system isn’t. You cannot comprehend the dataflows from it. Besides this, the standard lacks a data architecture view showing interrelations; and missing extensions with the processes for where data is first generated (preliminarily) and then appended or amended from. It also doesn’t show tight/loose couplings needs/allowances to make it work. In summary, we have not applied our own usability philosophy to our own risk management system.

Aaron: You bring up some interesting points, especially around the usability of risk analysis methods. As you say, the ISO 14971 risk mgmt standard does not describe how to perform risk analysis; it only defines broad requirements at the process level. If we want companies to adopt non-DFMEA risk analysis methods, we need to make those methods easy to find and straightforward to implement. I think dedicated risk management software tools (i.e., not Excel) can play a big role in helping people understand non-DFMEA risk analysis methods. A few software tools are mentioned in the comments below by multiple readers. I like the idea of emphasizing usability / human factors for risk analysis methods (actually for everything in a QMS for that matter). It’s a consideration that is often overlooked in quality system procedures when we’re 100% focused on compliance. Training can play an important role, of course, but making methods straightforward to follow is the most important. I think there’s a lot of promise in the Risk Management Maturity Model (RMMM) project led by Fubin Wu at GessNet. I’m curious if there are other projects or resources to improve the usability and standardization of best practices in risk management.

ISO 13485 and Risk Management

Edwin Bills:  I agree with Richard Matt, that Aaron Joseph has done an excellent job summarizing quite a few points here on the use and misuse of DFMEA in medical device risk management. Going beyond his points I would add that because FMEA needs Design Output to conduct it comes late in the game and as the article states there is much more value in other tools. Additionally, if your quality system complies with ISO 13485:2016 you need to meet the requirement of Clause 7.3.3 c) and start Risk Management before Design Input. PHA is a tool that helps accomplish that. You can also follow ISO TR 24971:2920 Annex A on identication of hazards, and Annex E on the use of standards. Both work with PHA to do early hazard identification and can be used to advance the risk analysis further.

Richard Matt: Re “if your quality system complies with ISO 13485:2016 you need to meet the requirement of Clause 7.3.3 c) and start Risk Management before Design Input.”: This quote takes the video to the next level.

  • The inputs to FMEAs are design outputs.
  • The inputs to design outputs are design inputs.
  • The inputs to design inputs includes risk management (Per ISO 13495, 7.3.3 c).
  • So, using FMEAs as your only tool to identify risks is not compliant with ISO 13485. 

Richard Matt: I hope no one ever tells you to not use dFMEAs and will argue against such statements if anyone ever does. On the flip side, I think it is critical to understand that ISO 13495 requires medical device companies to do better than to use FMEAs as their only tool to identify risks.

What’s the alternative to using FMEAs as your only tool to identify risks? A few of the many alternative tools are identified in TR 24971, Annex B – Techniques that support risk analysis. Also, per C.1 of ISO 14971, “it could be useful to [identify risks] by starting with the harm that the medical device might cause and work backwards to the hazardous situations, hazards and initiating causes.”

More Risk Analysis Tools + Free Templates

Anders Emmerich: As Sven Schaumann and Dave Pouliot mention, FMEA is a perfectly decent framework for a part of the risk analysis work. I don’t believe there is a ‘one-size-fit’s-all’ solution and we often see customers setting up multiple risk analysis approaches, including a top-down Preliminary Hazard Analysis, DFMEA, Cyber Risk Analysis or even a dedicated approach for Usability risks. Making it a lot easier for the developers to consider different aspects of risks which is exactly what 14971 is asking for.

Aaron: Yes, that’s a good way to view the issue. DFMEA is a robust, proven method for risk analysis, with its strengths and weaknesses. The problem comes when companies treat it as the only method for risk analysis. Product teams need to use a combination of methods to ensure the safety of new medical devices.

Anders Emmerich: I totally agree! Here you can find some good resources on different aspects of Risk Management that we have collected over the years:  Aligned Elements – risk analysis articles.

Aaron: That’s an impressive list of articles on risk analysis, including risk analysis for software (another area of widespread confusion), and free templates. Thanks for sharing!

Leave a Comment

Your email address will not be published. Required fields are marked *