FMEA for Medical Devices: Design, Process & Use Risk Analysis Explained

What Is FMEA?

Failure Mode and Effects Analysis (FMEA) is a systematic, bottom-up risk analysis method that identifies potential failure modes in a product or process, evaluates their effects, and prioritizes them for corrective action. It is one of the most widely used engineering tools in the medical device industry.

FMEA does not replace ISO 14971 risk management. It complements it. ISO 14971 takes a top-down approach — starting from hazards and working toward causes. FMEA takes the opposite direction — starting from components, process steps, or use scenarios, and working up to understand the consequences of each possible failure.

The distinction matters because it determines when and how you use each tool. Hazard analysis under ISO 14971 can begin early, when you know only the device's intended use and general concept. FMEA requires more detail — you need to know the design architecture, the manufacturing process steps, or the user interface elements before you can meaningfully analyze how they might fail.

Why FMEA Matters for Medical Devices

Medical devices operate in safety-critical environments. A software glitch in an infusion pump can deliver a lethal overdose. A coating failure on a guidewire can cause embolisms. A mislabeled IVD reagent can produce a false-negative cancer diagnosis.

FMEA helps engineering teams catch these failure scenarios before they reach patients. It forces structured thinking about what can go wrong, how bad the consequences would be, how likely the failure is, and whether existing controls are sufficient to detect it.

The method is recognized across the medical device regulatory landscape:

• ISO/TR 24971:2020 (guidance for ISO 14971) lists FMEA as one of the risk analysis techniques in Annex B
• IEC 62304 (software lifecycle) expects FMEA-like analysis for software risk
• IEC 60601-1 (medical electrical equipment) references failure analysis for basic safety
• FDA QMSR (effective February 2, 2026) incorporates ISO 13485, which requires risk-based approaches to design, production, and process validation
• EU MDR Annex I requires risk analysis throughout the design and manufacturing process

FMEA vs. ISO 14971: Understanding the Difference

The most common source of confusion in medical device risk management is conflating FMEA with ISO 14971. They are not the same thing. Using FMEA alone does not satisfy ISO 14971, the EU MDR, or the IVDR.

Here is why:

Dimension	ISO 14971 Risk Management	FMEA
Approach	Top-down: starts with hazards	Bottom-up: starts with components/process steps
Starting point	Intended use, hazard identification (Annex C of ISO 14971)	Design architecture, process flow, user interface
When it can begin	Very early — with only intended use defined	Later — after design architecture or process steps are defined
Scope of failures	Includes normal use, fault conditions, side effects, use errors	Primarily fault conditions (single failures)
Sequences of events	Considers sequences and combinations of events	Typically considers single-point failures only
Severity measure	Severity of harm to patient/user	Severity of effect on device performance
Objective	Create a safe medical device	Create a reliable device and process
Regulatory status	Required by EU MDR, IVDR, referenced by FDA	Not required by name; useful as a supporting tool

A concrete example illustrates the gap: a guidewire with a coating that can flake off. FMEA might classify coating delamination as a low-severity failure mode because the device still functions — the wire still guides the catheter. But ISO 14971 would consider the patient harm (potential embolism from coating particles in the bloodstream) and rate the severity as high. The FDA issued a Class I recall for exactly this scenario.

This does not mean FMEA is unimportant. It means FMEA is one tool in a broader risk management toolkit. Use it for what it does well: granular, component-level failure analysis. Use hazard analysis (ISO 14971) for the big picture of device safety.

Types of FMEA in Medical Devices

Medical device manufacturers typically use four types of FMEA, each addressing a different aspect of the product lifecycle.

Design FMEA (DFMEA)

DFMEA analyzes potential failures in the device's design — hardware, software, and system architecture. It evaluates how each design element might fail and what the downstream effects would be.

When to start: Early in the design and development phase, once the design architecture is defined. DFMEA should begin when you have enough design detail to identify functions, components, and their interactions — typically during design inputs or early design outputs.

What it covers:

• Mechanical failures (fracture, fatigue, deformation)
• Electrical failures (short circuit, open circuit, power surge)
• Software failures (logic errors, timing failures, data corruption)
• Material failures (degradation, biocompatibility issues)
• Interface failures between subsystems

Example: For a rechargeable wearable insulin pump, a DFMEA might identify the failure mode "battery management IC provides incorrect state-of-charge reading." The effect: the pump displays "full battery" when the battery is nearly depleted, leading to unexpected insulin delivery interruption. The cause: firmware bug in the battery gauge algorithm.

Process FMEA (PFMEA)

PFMEA analyzes potential failures in manufacturing and assembly processes. It evaluates how each process step might go wrong and what the effect would be on the finished device.

When to start: During process development, before process validation. PFMEA should evolve as the manufacturing process matures and should be updated with production data after design transfer.

What it covers:

• Assembly errors (misaligned components, missing fasteners)
• Process parameter failures (incorrect temperature, pressure, time)
• Material handling failures (contamination, mix-ups)
• Inspection failures (missed defects, incorrect measurements)
• Labeling and packaging errors

Example: For a sterile surgical instrument, a PFMEA might identify the failure mode "incorrect UDI barcode printed on product label." The effect: wrong device traceability, potential patient mismatch. The cause: label template not updated after design change. The control: barcode verification step during packaging inspection.

Use FMEA (UFMEA)

UFMEA analyzes potential failures in how users interact with the device. It focuses on use errors — situations where the user does something different from what the manufacturer intended, not because the device failed, but because the interface, instructions, or workflow led them astray.

When to start: During early usability planning, in conjunction with IEC 62366-1 activities.

What it covers:

• Incorrect operation sequence
• Misinterpretation of displays or alarms
• Omitted steps in a procedure
• Incorrect connections or assembly by the user
• Errors arising from the use environment (lighting, noise, distractions)

Example: For an auto-injector, a UFMEA might identify the failure mode "user removes device from injection site before drug delivery is complete." The effect: incomplete dose delivered to patient. The cause: no audible or tactile signal indicating when delivery is finished.

Software FMEA (SFMEA)

SFMEA applies FMEA methodology specifically to software components. It is increasingly important as medical devices incorporate more software, firmware, and connectivity.

When to start: During software architecture design, as part of IEC 62304 software lifecycle activities.

What it covers:

• Algorithm failures (incorrect calculation logic)
• Communication failures (data loss, corruption, latency)
• Security failures (unauthorized access, data breach)
• State machine errors (unexpected transitions, deadlock)
• Resource failures (memory exhaustion, stack overflow)

Example: For a cloud-connected glucose monitoring app, an SFMEA might identify the failure mode "encryption failure during data transmission." The effect: patient health data exposed in transit. The cause: expired TLS certificate not automatically renewed.

The 10-Step FMEA Process

Step 1: Define the Scope

Before starting any FMEA, clearly define what you are analyzing:

• For DFMEA: Which subsystem, assembly, or component? What lifecycle phases?
• For PFMEA: Which manufacturing process? Which line or facility?
• For UFMEA: Which user task or use scenario?
• For SFMEA: Which software module, function, or interface?

Review the device specifications, design documents, intended use, user profiles, and regulatory requirements. You need a crystal-clear understanding of the system before you can analyze how it might fail.

Step 2: Assemble the Team

FMEA is not a solo exercise. The quality of the analysis depends on the diversity and expertise of the team. A typical FMEA team includes:

• Design engineers who understand the architecture and failure physics
• Quality engineers who understand inspection methods and failure history
• Manufacturing engineers who understand process capabilities and controls
• Regulatory affairs specialists who understand compliance expectations
• Clinical or medical experts who understand patient impact
• Software engineers (for SFMEA) who understand code-level failure modes

Include representatives from post-market surveillance or complaint handling — they bring real-world failure data that is more valuable than any theoretical brainstorming.

Step 3: Identify Functions and Requirements

Break the system into its constituent functions. For each element being analyzed, document:

• What it is supposed to do (functional requirements)
• Performance specifications and tolerances
• Regulatory requirements and standards
• Safety requirements
• User interface requirements

Create functional block diagrams or process flow diagrams to visualize the system and identify interactions between elements.

Step 4: Identify Potential Failure Modes

For each function or process step, brainstorm all the ways it could fail. A failure mode is a specific way the function or step does not meet its requirement:

• Does not perform the function at all
• Performs the function intermittently
• Performs the function incorrectly (wrong output, wrong timing, wrong sequence)
• Performs the function degraded (below specification)
• Performs an unintended function

Use multiple sources to identify failure modes:

• Brainstorming sessions with the team
• Historical data from similar devices and complaints
• Published failure databases (FDA MAUDE, literature)
• Previous FMEA analyses and lessons learned
• Test results and validation data

Step 5: Determine Effects of Each Failure

For each failure mode, describe what happens when that failure occurs. Evaluate effects at multiple levels:

• Local effect: What happens to the specific component or process step
• Next-level effect: What happens to the subsystem or downstream process
• System-level effect: What happens to the overall device
• End effect: What happens to the patient, user, or environment

Include clinical perspective when evaluating patient-level effects. An engineer might describe a failure as "display shows incorrect value," but the clinical effect is "clinician makes treatment decision based on wrong information."

Step 6: Assess Severity

Rate the severity of each failure effect on a defined scale. Most medical device FMEAs use a 1–10 scale, where:

Severity Rating	Meaning
1	No effect — the failure is unnoticed
2–3	Minor inconvenience — cosmetic or nuisance effect
4–5	Moderate — device performance degraded but still functional
6–7	Significant — device function compromised; potential for minor injury
8–9	Critical — device non-functional; potential for serious injury
10	Catastrophic — potential for death or life-threatening harm

Important: severity should reflect the worst credible effect of the failure mode, assuming no controls are in place. If the failure could lead to patient death under reasonable circumstances, the severity is 10 — even if controls make that outcome unlikely.

Step 7: Assess Occurrence

Rate the likelihood of the failure mode occurring on a defined scale:

Occurrence Rating	Meaning
1	Remote — failure is unlikely; less than 1 in 1,000,000
2–3	Very low — isolated failures expected
4–5	Low — relatively few failures
6–7	Moderate — occasional failures
8–9	High — repeated failures likely
10	Very high — failure is almost inevitable

Base occurrence ratings on data whenever possible: historical process data, field return rates, published reliability data, or engineering judgment informed by experience with similar designs.

Step 8: Assess Detectability

Rate the ability of current controls to detect the failure mode before the device reaches the user (or before the effect occurs):

Detectability Rating	Meaning
1	Almost certain detection — current controls will reliably catch this failure
2–3	High detection probability
4–5	Moderate detection probability
6–7	Low detection probability — controls may miss this failure
8–9	Very low detection probability — controls unlikely to catch this failure
10	No detection — there are no controls capable of detecting this failure

Note that detectability is scored inversely: a rating of 10 means the failure is undetectable, which is the worst case. This is different from severity and occurrence, where 10 is also worst case but the scales run in the same direction.

Step 9: Calculate Risk Priority Number (RPN)

The Risk Priority Number is the product of the three ratings:

RPN = Severity × Occurrence × Detectability

This produces a score between 1 and 1,000. Higher RPNs indicate higher-priority risks that need attention.

However, RPN has well-known limitations:

• A severity-10, occurrence-1, detectability-1 failure (RPN = 10) looks the same as a severity-1, occurrence-10, detectability-1 failure (RPN = 10). The first could kill a patient; the second is trivial.
• RPN does not capture the interactions between failure modes or the compounding effects of multiple failures.

Best practice: use RPN as a prioritization aid, but always review high-severity failures regardless of their RPN. Never use an RPN threshold as the sole criterion for whether to take action.

Some organizations use an alternative approach: the Risk Matrix (severity × occurrence), which is more aligned with ISO 14971's risk acceptability framework, and then consider detectability separately.

An Alternative: Action Priority (AP) Method

The AIAG & VDA FMEA Handbook (1st edition, 2019) introduced the Action Priority (AP) method as a replacement for RPN. Rather than multiplying the three ratings into a single number, AP uses a lookup table that considers all 1,000 possible combinations of severity, occurrence, and detectability and assigns one of three priority levels:

• High (H): Action to improve prevention and/or detection controls is required, or justification that current controls are adequate must be documented
• Medium (M): Action to improve prevention and/or detection controls should be considered, or justification documented
• Low (L): Action to improve prevention and/or detection controls could be considered

The AP method addresses the core limitation of RPN by always giving highest priority to high-severity failures, regardless of occurrence and detectability scores. While the AP method was developed for the automotive industry, some medical device manufacturers have adopted it as a more nuanced alternative to RPN. Whether you use RPN, AP, or a risk matrix, the key principle remains: never use a numerical threshold as the sole basis for action decisions.

Step 10: Recommend and Implement Actions

For each high-priority failure mode (based on RPN, severity, or other criteria), the team should:

• Identify recommended actions to reduce risk
• Assign responsibility and target dates
• Implement the actions
• Re-score severity, occurrence, and detectability after controls are implemented
• Document the results

Risk reduction strategies follow a hierarchy:

1. Eliminate the failure mode through design change (most effective)
2. Reduce the occurrence through design or process changes
3. Increase detection through improved inspection, testing, or monitoring (least effective)

After actions are implemented, verify their effectiveness. If a design change was made, verify it through testing. If a process control was added, verify it through process validation. Document the verification in the FMEA worksheet.

How FMEA Fits into the Product Lifecycle

FMEA is not a one-time activity. It evolves with the device throughout its lifecycle.

During Design and Development

DFMEA begins during design inputs and evolves through design outputs, design verification, and design validation. The initial DFMEA is based on engineering judgment and analysis of similar devices. As testing data becomes available, the DFMEA is updated to reflect actual performance.

DFMEA outputs feed directly into:

• Design verification — test protocols should verify that high-priority failure modes are adequately controlled
• Design transfer — critical failure modes and their controls must be communicated to manufacturing
• Risk management file — FMEA worksheets become part of the risk management file

During Manufacturing

PFMEA begins during process development and continues through process validation and routine production. It is updated when:

• New failure modes are discovered in production
• Process changes are introduced
• Nonconformances reveal previously unidentified risks
• CAPA investigations identify root causes linked to process failures

During Post-Market Surveillance

FMEA should be reviewed and updated based on post-market data:

• Complaint data may reveal failure modes not previously identified
• Trend analysis may indicate that occurrence or severity ratings need adjustment
• Field corrections or recalls should trigger FMEA review

This is where the connection to ISO 14971 becomes most concrete: production and post-production data feed back into risk management, which may require updating the FMEA.

Common FMEA Mistakes

1. Starting Too Late

The most common and consequential mistake. FMEA is a preventive tool — its value is in catching problems before they are baked into the design or process. Starting FMEA after design freeze means you can identify problems but changing the design is expensive and slow.

2. Doing FMEA Alone

FMEA by a single engineer in a spreadsheet is not FMEA — it is an engineering opinion. The value of FMEA comes from the structured confrontation of different perspectives. The design engineer may not consider manufacturing realities. The quality engineer may not know about clinical use scenarios. The team approach is what makes FMEA effective.

3. Treating FMEA as ISO 14971

FMEA alone does not satisfy the requirements of ISO 14971, EU MDR, or IVDR. It does not cover hazards that arise from normal use, sequences of events, or use errors that occur without any device failure. It must be used alongside hazard analysis, not as a replacement for it.

4. Focusing Only on RPN Thresholds

Setting a blanket RPN threshold (e.g., "address all RPNs above 100") without considering severity independently leads to under-responding to low-frequency catastrophic failures and over-responding to high-frequency trivial ones. Always review severity-8+ failure modes regardless of RPN.

5. Making FMEA Too Large

Trying to FMEA an entire complex system in one worksheet leads to exhaustion, superficial analysis, and a document no one reads. Break the system into manageable subsystems and analyze each one with appropriate depth.

6. FMEA as a Compliance Checkbox

Updating the FMEA spreadsheet once during design and never touching it again misses the entire point. FMEA is a living document. It should be updated with test results, production data, complaint trends, and design changes throughout the device lifecycle.

FMEA Documentation Requirements

Your FMEA documentation should include:

• FMEA worksheet with columns for: item/function, failure mode, effect, severity rating, cause, occurrence rating, current controls, detectability rating, RPN, recommended actions, responsibility, target date, actions taken, and revised ratings
• Team membership and qualifications
• Scoring criteria (the scales used for severity, occurrence, and detectability)
• Assumptions and boundaries of the analysis
• Cross-references to related documents (design specifications, process procedures, risk management file)

Everything must be documented. The FMEA is part of your risk management file and will be examined during audits and regulatory submissions. Undocumented risk analysis is the same as no risk analysis.

Key Standards and References

Standard / Document	Relevance
IEC 60812:2018	The international standard for FMEA methodology — defines the FMEA process, terminology, and documentation
ISO 14971:2019	Risk management for medical devices — the overarching framework within which FMEA operates
ISO/TR 24971:2020	Guidance on applying ISO 14971 — Annex B lists FMEA as a risk analysis technique
ISO 13485:2016	Quality management systems — requires risk-based approaches to design, production, and process validation
IEC 62304:2006+AMD1:2015	Software lifecycle processes — expects failure analysis for software risk
IEC 62366-1:2015+AMD1:2020	Usability engineering — UFMEA supports use-related risk analysis
MDCG 2023-3	EU MDR vigilance guidance — post-market data should feed back into FMEA
FDA QMSR (21 CFR 820)	Effective February 2, 2026 — incorporates ISO 13485 by reference

Summary

FMEA is a powerful engineering tool for systematically analyzing potential failure modes in medical device designs, manufacturing processes, user interfaces, and software. It provides granular, quantitative risk analysis that complements the broader hazard analysis approach of ISO 14971.

Key takeaways:

• FMEA is not a substitute for ISO 14971 risk management — it is a supporting tool within it
• Use DFMEA for design analysis, PFMEA for process analysis, UFMEA for use-error analysis, and SFMEA for software analysis
• Start early, involve a multidisciplinary team, and keep the FMEA updated throughout the product lifecycle
• RPN is a useful prioritization tool but should not be the sole basis for risk decisions
• FMEA documentation is part of your regulatory submission and will be examined in audits