Failure Mode and Effects Analysis (FMEA) shows up in nearly every medical device quality system — but it is frequently misunderstood. Quality teams apply it as a standalone checklist rather than integrating it into the broader risk management process required by ISO 14971. The result is an FMEA that looks thorough on paper but does not actually drive design decisions or satisfy what FDA inspectors and notified bodies expect to see.
This walkthrough covers how to conduct a Design FMEA for a medical device, how it connects to ISO 14971, what the RPN number means and where it falls short, and what a well-documented FMEA record looks like from an auditor’s perspective.
FMEA and ISO 14971: how they relate
ISO 14971:2019 is the international standard for risk management of medical devices, recognized by FDA under QMSR and required by EU MDR. It defines a systematic process for identifying hazards, estimating and evaluating risk, implementing risk controls, and monitoring residual risk across the product lifecycle.
FMEA is one of several risk analysis techniques that ISO/TR 24971:2020 — the technical report supporting ISO 14971 — describes as appropriate tools for medical device risk analysis. Other methods include fault tree analysis (FTA) and hazard analysis and critical control points (HACCP). FMEA is widely used because it is structured, scalable, and produces a record format that integrates well with design documentation.
The relationship between FMEA and ISO 14971 is methodological, not equivalent. FMEA is a tool for risk identification and analysis. ISO 14971 is the framework that tells you what to do with what FMEA finds — including how to evaluate risk against acceptability criteria, how to implement controls, how to verify controls worked, and how to document the entire chain. An FMEA without an ISO 14971-compliant risk management file around it does not satisfy regulatory requirements.
Types of FMEA used in medical device development
Three types of FMEA appear most often in medical device QMS documentation:
Design FMEA (dFMEA)
Analyzes potential failure modes in the device design itself — materials, components, interfaces, functional requirements — and evaluates how those failures could affect patient safety or device performance. Conducted during design development, before design freeze.
Process FMEA (pFMEA)
Analyzes potential failures in the manufacturing process — assembly steps, inspection checkpoints, sterilization, packaging — and their effects on device quality and safety. Conducted before the manufacturing process is finalized and validated.
Use FMEA (uFMEA)
Sometimes called Human Factors FMEA or Use-Related Risk Analysis. Analyzes potential use errors — how users might misuse the device, fail to follow instructions, or encounter situations the design did not anticipate. Required when use error is a significant risk driver, and closely related to the usability engineering requirements of IEC 62366.
This article focuses on Design FMEA, as it is the most commonly required analysis for initial device submissions and the most frequently examined in FDA inspections and notified body audits.
Step-by-step: how to conduct a Design FMEA
Step 1: Define the scope and assemble the team
Start by defining what the FMEA covers: the device system, the specific subsystem or component level, and the design stage. A dFMEA conducted at system level will look very different from one conducted at the component level. For complex devices, both are needed.
FMEA is a team exercise. The team should include engineers from design, manufacturing, and quality — plus clinical input if the failure modes have patient contact implications. A dFMEA produced by one engineer in isolation will miss failure modes that cross functional boundaries.
Step 2: Identify functions and potential failure modes
For each element in scope, define its intended function. Then identify how it could fail to perform that function. These are failure modes. A single function can have multiple failure modes.
Be specific. “Component fails” is not a failure mode. “Luer lock connector fails to maintain watertight seal under 50 psi pressure” is a failure mode. Specificity at this step determines the quality of everything that follows.
Common failure mode sources: design verification test data, field complaint history for similar devices, literature on failure modes for the same technology, and experience from manufacturing process development.
Step 3: Determine potential effects
For each failure mode, identify the effect on the patient, user, or device performance. Effects are typically described at three levels: local effect (on the component or subsystem), system effect (on the device as a whole), and end effect (on the patient or user).
The end effect is what connects to your ISO 14971 hazardous situation analysis. Keep your language consistent between the FMEA and the risk management file — auditors look for this alignment.
Step 4: Rate severity
Assign a severity score to each failure effect. ISO 14971 uses qualitative or semi-quantitative categories: catastrophic, critical, marginal, and negligible — or numerical equivalents (commonly 1–10). Your risk management procedure should define what each severity level means in clinical terms.
Example severity criteria for a Class II implantable device:
- 10 (Catastrophic): patient death
- 8–9 (Critical): serious irreversible injury
- 5–7 (Moderate): reversible injury requiring medical intervention
- 2–4 (Minor): discomfort or temporary impairment, no medical intervention needed
- 1 (Negligible): no patient impact
Step 5: Identify causes
For each failure mode, identify the potential causes — design deficiencies, material properties, dimensional tolerances, process variation, use error. This is where root thinking begins. Each failure mode may have multiple causes, and each cause may have a different probability and different mitigation options.
Step 6: Assess occurrence (probability) before controls
Rate the likelihood of each failure cause occurring, before any controls are applied. This is the initial risk estimate. In ISO 14971 terms, this is the unmitigated probability. Use historical data, test data, field data from similar devices, or expert judgment — and document the basis for your estimate. FDA investigators ask how you arrived at probability ratings.
Step 7: List current design controls and rate detectability
Identify what design controls currently exist that would prevent the failure cause or detect it before it reaches the user. Design controls include design specifications, validation tests, inspections, and verification activities. Rate the effectiveness of these controls in detecting the failure before it causes harm.
Note: in many ISO 14971-aligned FMEA approaches used in medical devices, detectability scoring is secondary to the severity/probability risk evaluation. Some organizations use RPN; others use a two-dimensional risk matrix. Both are acceptable if your risk management procedure defines the methodology consistently.
Step 8: Calculate the Risk Priority Number (RPN) and evaluate
The traditional FMEA RPN = Severity × Occurrence × Detection. Higher RPNs indicate higher priority for risk control. However, RPN has known limitations in medical device risk management: two failure modes with very different severity levels can produce the same RPN, which can lead to under-prioritizing high-severity, low-frequency failures.
ISO 14971 requires evaluating risk using a risk acceptability matrix — defined in your risk management plan — that accounts for severity and probability together, not as a product score. Many manufacturers use RPN for prioritization within the FMEA while also applying the ISO 14971 risk matrix for formal acceptability determination. Both methods should be documented consistently.
Step 9: Identify and implement risk controls
For failure modes that exceed your risk acceptability criteria, identify risk controls. ISO 14971 prioritizes controls in this order: (1) design changes that eliminate the hazard or inherently reduce risk, (2) protective measures in the device or manufacturing process, (3) information for safety (labeling, warnings, instructions for use).
Document what control was implemented, who implemented it, and when. The dFMEA should reference the design output records where the control is documented — not just describe it abstractly.
Step 10: Re-evaluate residual risk after controls
After implementing controls, re-score the FMEA. The residual risk — the risk that remains after controls — must be evaluated against your acceptability criteria. If residual risk is still unacceptable, additional controls are required or the design must change.
ISO 14971 also requires a residual risk evaluation at the system level — summing all residual risks from individual failure modes to assess overall residual risk and whether the overall benefit-risk profile remains favorable.
Common FMEA mistakes that fail audits
Using “operator error” as a failure mode
Use error is a cause or a contributing factor, not a failure mode. “The user connects the catheter to the wrong port” is a use scenario. The failure mode is that your device design allows the wrong connection. Address the design — don’t just label it user error and accept the risk.
Not linking FMEA to the Design History File
Your FMEA is part of your design controls. It should reference — and be referenced by — design inputs, design outputs, verification and validation records, and the risk management file. Auditors look for this cross-referencing. An FMEA that exists as a standalone document not integrated into the DHF is a gap.
Severity scores that are not calibrated
If your severity scale is not defined in your risk management procedure, auditors will ask how you assigned severity scores. “Based on experience” is not sufficient. Define severity criteria explicitly, document them in your risk management plan, and apply them consistently across all products.
Not updating the FMEA after design changes
Every design change should trigger a review of the dFMEA to assess whether the change introduces new failure modes, changes probability or severity of existing modes, or affects the effectiveness of existing controls. A dFMEA that does not reflect the current design is not a current document.
Treating FMEA as complete after first pass
The dFMEA is a living document. It is updated during design verification, when manufacturing yields reveal unexpected failure modes, when field data from similar devices surfaces new hazards, and during post-market surveillance. FDA’s risk-based approach under QMSR expects risk management to continue throughout the product lifecycle — not stop at design freeze.
Managing FMEA in your QMS
FMEA records that live in spreadsheets create several problems: version control is unreliable, cross-referencing to design outputs and test records is manual, and there is no automatic notification when the FMEA needs review after a design change or adverse event.
Cloudtheapp’s risk management applications let you build and maintain your dFMEA within the same platform as your design controls, CAPA, and post-market surveillance. When a design change is proposed, the system flags linked risk records for review. When a complaint or adverse event is logged, it can be linked to the relevant FMEA failure mode — creating the closed-loop risk management record that FDA and notified bodies expect to see.
Want to see how Cloudtheapp connects design controls, FMEA, and risk management in a single compliant record? Book a demo to walk through the system with a specialist.
Summary
A Design FMEA done well is a design tool, not a compliance exercise. It forces your team to systematically ask what can go wrong, assess how bad the consequences are, evaluate what is in place to prevent it, and decide whether that is good enough. That thinking — documented and connected to your design decisions — is what regulators and auditors are looking for. The form it takes matters less than whether it actually reflects the device you built and the risk controls you implemented.
Cloudtheapp supports 60+ quality and compliance applications including risk management, design controls, CAPA, and post-market surveillance. Schedule a demo to see how regulated medical device companies use the platform to manage FMEA across the product lifecycle.
]]>
