Design Failure Mode and Effects Analysis (DFMEA)

Design Failure Mode and Effects Analysis (DFMEA) is a structured engineering method that identifies how a product design could fail, evaluates the severity, likelihood, and detectability of each failure, and ranks the results so teams can prioritize design changes that reduce risk before a medical device reaches production.


What is Design Failure Mode and Effects Analysis (DFMEA)?

Design Failure Mode and Effects Analysis (DFMEA) is a proactive, bottom-up technique for examining a design before it is built. The team works through each function, part, or interface, asks how it might fail, then traces what that failure would do to the device and to the patient or user.

It sits early in the device lifecycle and feeds into the design controls and risk management files. DFMEA targets failures rooted in the design itself: a wrong material, an undersized trace, a tolerance stack-up, a software state that was never specified. It is distinct from Process FMEA (PFMEA), which looks at how manufacturing introduces defects.


Why Design Failure Mode and Effects Analysis (DFMEA) matters in medical device development

A design flaw that escapes detection becomes far more expensive and dangerous once a device is in clinical use. Fixing it on paper costs a meeting; fixing it after a recall costs revenue, market access, and patient trust.

For regulated MedTech, the stakes are concrete. Design Failure Mode and Effects Analysis (DFMEA) supports the risk management process required under ISO 14971 and the design controls expected under FDA 21 CFR Part 820.30 and EU MDR 2017/745. Auditors and notified bodies look for evidence that foreseeable design failures were identified, assessed, and controlled. A thin or back-dated DFMEA is a common audit finding and a weak point in a 510(k) or technical file. Done early, it shortens time-to-market by surfacing problems while changes are still cheap.


How the Design Failure Mode and Effects Analysis (DFMEA) process works

A DFMEA is usually built by a cross-functional team and recorded in a structured worksheet. The core steps:

  • Scope the design. Break the device into functions, subsystems, and components. A block diagram or interface analysis keeps the boundaries clear.
  • List failure modes. For each item, state how it could fail to perform its intended function (for example, a sensor reads low, a seal leaks, firmware misses a fault condition).
  • Describe effects. Trace each failure to its consequence at the device and patient level. This is where the link to ISO 14971 harm severity matters.
  • Identify causes. Find the design reasons behind the failure mode, not the symptom.
  • Score the risk. Rate Severity (S), Occurrence (O), and Detection (D), usually on a 1 to 10 scale. Classic DFMEA multiplies these into a Risk Priority Number (RPN); the newer AIAG-VDA approach uses an Action Priority (AP) rating instead.
  • Define and verify actions. Assign design changes or added controls to the high-priority items, then re-score once those actions are verified.

The output is a living document: created at design input, updated through verification and validation, and revisited whenever the design changes. Keep the ratings traceable to your risk acceptance criteria so the analysis aligns with the broader risk management file rather than sitting in a silo.


Common challenges and best practices

The most common mistake is treating DFMEA as a checkbox written the week before an audit. By then, the design is frozen, and the analysis only documents decisions instead of shaping them. Start it at design input and let it drive trade-offs.

Other frequent issues: scoring inflation where everything lands at “medium,” confusing failure modes with causes, and a DFMEA that never reconciles with the ISO 14971 risk file. Detection ratings get gamed too, crediting tests that do not actually catch the failure.

What good looks like: a focused cross-functional team, clear scoring criteria agreed up front, severity tied to real patient harm, and a hard rule that high-severity items get design controls regardless of how rare they seem. Link every action back to a verification record so the closed loop is auditable.


How SJML helps with Design Failure Mode and Effects Analysis (DFMEA)

SJML builds design risk analysis into electromechanical device programs from concept through design transfer. Its engineering teams run DFMEA alongside ISO 14971 risk management and IEC 62366 usability engineering, covering mechanical, electronics, embedded, and software domains within phase-gate development and change control. In-house labs for electrical safety, EMC, reliability, and environmental testing let the team verify that design actions actually work, then feed results back into the analysis. This ties failure-mode analysis to real test evidence rather than leaving it as a standalone worksheet.

Talk to SJML’s engineering team →


Frequently asked questions

What is the difference between DFMEA and PFMEA?

DFMEA examines failures that come from the product design itself, such as a weak structure, a wrong tolerance, or an unhandled software state. PFMEA examines failures introduced by the manufacturing process, such as a missed solder joint or a contaminated fill. Most medical device programs use both DFMEA during design, PFMEA during process development, and validation.

Is DFMEA required by ISO 14971?

ISO 14971 does not mandate DFMEA by name. It requires a documented risk management process, and DFMEA is a widely accepted method that supports it. Teams use DFMEA to identify and analyze design-related failure modes, then feed the severity and risk findings into the ISO 14971 risk file so design and risk activities stay aligned.

When should you start a DFMEA in device development?

Begin a DFMEA at design input, as soon as functions and architecture are defined. Starting early lets the analysis shape design decisions while changes are inexpensive. Update it through verification and validation, and whenever the design changes. A DFMEA written only before an audit documents decisions instead of improving them.

What is a Risk Priority Number (RPN)?

A Risk Priority Number is the product of three 1 to 10 ratings: Severity, Occurrence, and Detection. It gives a relative score for ranking failure modes. Higher numbers signal items needing action first. The newer AIAG-VDA method replaces RPN with an Action Priority rating, which many medical device teams now prefer for clearer prioritization.


Related terms

  • Design Verification
  • Risk Management (ISO 14971)
  • Process FMEA (PFMEA)
  • Design Controls
  • Usability Engineering (IEC 62366)

Table of Contents

Free EU MDR Technical Documentation Compliance Checklist

Understand documentation gaps and use our single-window worksheet to prepare for Notified Body review.

Related Glossaries

Ask Sygma AI

AI-Powered Assistant

SJ Assistant