FMEAFailure Mode and Effects Analysis

Failure Mode and Effects Analysis is a structured, bottom-up risk analysis technique. A cross-functional team walks the design, the process or the system one element at a time, identifies every plausible failure mode for that element, determines the local and end effects of each failure, identifies the current controls that prevent the failure or detect it before it reaches the patient or customer, and scores the resulting risk so the team can prioritise where to put preventive effort.

FMEA originated in US military reliability work (MIL-P-1629, 1949) and was scaled by NASA, then adopted by automotive (AIAG, VDA), aerospace (SAE ARP5580), medical devices (ISO 14971 cites FMEA as a primary technique), pharmaceuticals (ICH Q9(R1) Annex I), and software (IEC 60812 Annex C). The 2019 AIAG-VDA Handbook unified the two dominant automotive variants into a single seven-step framework, and the 2018 IEC 60812 revision aligned the international standard with the same modern practice.

A medical device program typically runs a DFMEA per major sub-system, a use-related FMEA (uFMEA, often called application FMEA) for use-error scenarios per IEC 62366, and a PFMEA per manufacturing line. These feed the overall ISO 14971 risk file but each has its own owner, frequency and review cadence.

1. Planning and preparation — define the scope, the boundary, the team, the timeline and the assumptions. Done before any failure analysis.
2. Structural analysis — break the design or process into its hierarchical structure (parts, sub-functions, steps).
3. Function analysis — for each structural element define the intended function and its requirements.
4. Failure analysis — for each function identify the failure modes, the effects of each failure, and the causes.
5. Risk analysis — for each failure score Severity (S), Occurrence (O) and Detection (D); compute Action Priority (AP) under AIAG-VDA or RPN (S × O × D) under classical IEC 60812.
6. Optimisation — for high-AP / high-RPN items, define mitigations (design change, process change, additional control), re-score and demonstrate the improvement.
7. Results documentation — issue the FMEA report, link to the design history file or process validation package, and define the trigger conditions for re-evaluation.

Classical FMEA computes the Risk Priority Number RPN = S × O × D, where each axis is rated 1–10 against an organisation-specific calibration scale. The team prioritises by RPN and may set a threshold above which mitigation is mandatory. The mathematical problem: an RPN of 200 from (S=10, O=4, D=5) is treated identically to (S=4, O=10, D=5), but the first is a catastrophic-effect failure with low detection and the second is a low-consequence failure that happens constantly with low detection — utterly different risk profiles.

AIAG-VDA 2019 replaced single-number RPN with an Action Priority (AP) lookup table: High / Medium / Low priority is read off a three-axis cube where Severity dominates. A Severity 10 failure is automatically High AP regardless of Occurrence and Detection. This is the same principle ISO 14971 has always used — severity is non-trade-off-able.

FMEA is a team sport. Effective teams have: a process or design owner (the chair), a quality engineer (the facilitator), the operators or users who actually perform the work (the ground truth), a representative from the downstream customer of the process, and where relevant, a regulatory or risk-management lead. Single-author FMEAs miss failure modes the team would catch; FMEAs run by external consultants without operator presence miss the failure modes the operators see every day.

Re-evaluation is event-driven and time-driven. Event triggers: any design change, any process change, any deviation that exposed an unscored failure mode, any post-market signal (complaint, vigilance, recall), any change-control package. Time triggers: typically annual review for active programs, quinquennial for legacy programs in steady state.

1. FMEA exists but is not living — last updated three years ago, no link to current change-control activity.
2. Failure modes scoped to component-level only — system-level failure modes (interface, timing, mode-of-operation) missing.
3. Detection scores assigned generously to drive RPN below threshold, no traceable evidence of detection effectiveness.
4. Use-related failure modes (per IEC 62366) absent from device FMEA — only mechanical and software failures considered.
5. Mitigations identified but not tracked to closure in CAPA — recommendations sit in the FMEA spreadsheet with no due date or owner.
6. Severity 9 or 10 failure modes without justified preventive control — relying on Detection 1 alone is not acceptable under ISO 14971 §6.
7. FMEA disconnected from the ISO 14971 risk file — duplicate but inconsistent risk artefacts.
8. Re-scoring after mitigation done by the original author without independent review.

• FMEA is a versioned, signed object — not a spreadsheet attached to a folder.
• Each failure mode line links to the structural and function items it covers; renaming a process step propagates without losing traceability.
• AIAG-VDA Action Priority lookup is built in; classical RPN remains available for legacy programs.
• Mitigations create CAPA tasks with owners and due dates; closure of the CAPA re-opens the FMEA line for re-score.
• Change control packages auto-flag the affected FMEA lines for re-evaluation before the change can be approved.
• Post-market signals (complaints, deviations, vigilance) feed back into the FMEA — a complaint flagged as 'failure mode not previously identified' generates an FMEA-update ticket.
• Annual review cadence is tracked at the asset level — overdue FMEAs surface on the management-review dashboard.