FMEA, Failure Mode and Effects Analysis, is a useful technique for medical device startups, but it is not a risk management system. Under MDR, the risk management system is defined by EN ISO 14971:2019+A11:2021. FMEA fits inside that system as one tool among several. Used well, it finds failures a free-form review would miss. Used alone, it produces a spreadsheet that looks compliant and is not. The practical difference matters for notified body audits.

By Tibor Zechmeister and Felix Lenhard.

TL;DR

  • FMEA is a bottom-up technique that enumerates failure modes at component or process-step level, rates their severity, probability, and detection, and prioritises controls.
  • Design FMEA (dFMEA) analyses how a product's components can fail. Process FMEA (pFMEA) analyses how a manufacturing or assembly process can fail. Both are relevant to medical device startups, but at different stages.
  • MDR does not mandate FMEA. MDR Annex I GSPR 3 requires risk management, and EN ISO 14971:2019+A11:2021 is the harmonised standard that defines the process. FMEA is one technique inside that process.
  • FMEA alone is insufficient when the dominant hazards are systemic (requirements errors, interaction effects, ML behaviour), when probability cannot be grounded in data, or when the hazards depend on use context rather than component failure.
  • A credible startup risk file uses FMEA for what it does well, supplements it with hazard analysis techniques for what FMEA misses, and links everything back to EN ISO 14971:2019+A11:2021 clauses and MDR Annex I GSPRs.
  • Tibor's test: if the only risk document is a spreadsheet labelled FMEA, the file is not compliant, regardless of how many rows it has.

Why startups default to FMEA

Felix has watched dozens of medical device startups adopt FMEA as their first and often only risk technique. FMEA templates are freely available, the format looks structured and quantitative, and engineers with automotive or aerospace backgrounds already know it. A spreadsheet with severity, occurrence, detection, and RPN columns feels like progress.

The trouble starts later. Notified body auditors do not read FMEAs looking for RPN numbers. They read them looking for whether the actual hazards of the device have been identified and controlled. When the FMEA covers component failures and skips requirements errors, interaction effects, and use-context hazards, auditors find the gaps quickly.

Tibor recalls an early-career audit at an optical medical device company, past startup stage, that handed over four PowerPoint slides saying do an Excel sheet with a risk analysis, tolerable or not tolerable, done. His assessment was that this represented maybe five percent of what risk management and ISO 14971 actually require. The worst part was not that it had slipped past earlier auditors. It was that the entire company believed this was the correct approach.

What FMEA actually is

FMEA is a structured technique for enumerating failure modes and their effects. The flow is the same across variants: pick a system element (component for dFMEA, process step for pFMEA), list its failure modes, list the effects on the next level up and on the user, rate severity, occurrence, and detection, compute RPN or use a risk matrix, prioritise mitigations, re-rate, and document residual risk.

FMEA is mature and has real strengths. It forces enumeration, prevents the team from mitigating the obvious risks and forgetting the rest, and creates a paper trail that supports audits. It also has documented limitations in regulated medical device work, which is why EN ISO 14971:2019+A11:2021 treats it as one technique inside a larger process rather than as the process itself.

Design FMEA versus process FMEA

Design FMEA (dFMEA) analyses how the product as designed can fail. The inputs are the design outputs: schematics, specifications, architecture documents, component lists, interface definitions. The output is a list of design-related failure modes ranked by risk, and the design changes or verification activities needed to control them.

dFMEA is most valuable at the transition from design input to detailed design. Too early and the design is not specified enough to enumerate failures. Too late and the findings trigger expensive rework. Felix coaches teams to run dFMEA alongside the design verification planning, so each identified failure mode either drives a design change or becomes a verification test.

Process FMEA (pFMEA) analyses how the manufacturing, assembly, packaging, sterilisation, or distribution process can fail. The inputs are the process flow, work instructions, equipment lists, and operator tasks. The output is a list of process-related failure modes and the controls needed, which frequently become part of the process validation under EN ISO 13485:2016+A11:2021.

pFMEA is most valuable just before process validation and at every change that affects the process. A hardware startup that scales from prototype assembly to contract manufacturing gets most of its value from pFMEA at the tech transfer.

Both dFMEA and pFMEA are legitimate techniques inside the EN ISO 14971:2019+A11:2021 process. Neither replaces it.

What MDR actually says about FMEA

MDR never uses the word FMEA. MDR Annex I GSPR 3 requires the manufacturer to establish, implement, document, and maintain a risk management system as a continuous iterative process throughout the entire lifecycle. GSPR 4 requires risks to be reduced as far as possible without adversely affecting the benefit-risk ratio. Annex I §17.2 for software requires development in accordance with the state of the art, taking into account the principles of development lifecycle, risk management, verification, and validation.

The harmonised standard that operationalises GSPR 3 for risk management is EN ISO 14971:2019+A11:2021. That standard presents a process with specific clauses: plan the risk management, identify hazards, estimate and evaluate risks, control them, evaluate overall residual risk, run the risk management review, and maintain the process through production and post-production. FMEA is mentioned as one technique a team may use during hazard identification and risk analysis, alongside techniques such as hazard and operability analysis, fault tree analysis, and preliminary hazard analysis.

The practical consequence: a startup that hands over a FMEA spreadsheet without the plan, the risk management file structure, the overall residual risk evaluation, or the post-production feedback loop is missing most of what EN ISO 14971:2019+A11:2021 expects. The FMEA rows may be correct. The system around them is not a system.

Tibor also flagged a specific trap in the follow-up interview. EN ISO 14971:2019+A11:2021 allows risks initially seen as acceptable to need no further reduction. MDR does not. MDR requires risks to be reduced as far as possible regardless of initial acceptability. Teams that copy the standard verbatim into their QMS without reading Annex Z of the standard miss this and get findings at audit.

A worked example: pFMEA for a small-batch assembly

Consider a startup assembling a Class IIa handheld device in low volume. The assembly has six steps: board preparation, enclosure mounting, cable routing, firmware flashing, functional test, labelling and packaging. The startup runs a pFMEA session with the production, quality, and design leads plus an external reviewer.

Step 3, cable routing. Failure mode: cable pinched under enclosure lid. Effect: intermittent connection loss during clinical use. Severity high, occurrence medium, detection low because the device powers up fine. Mitigations: redesign the cable channel (inherent safety by design), add a pull test in functional test (protective measure), add a visual inspection in work instructions (information for safety, last resort).

Step 4, firmware flashing. Failure mode: wrong firmware version flashed because the tool defaults to the latest file. Effect: device ships with untested firmware. Severity critical. Mitigations: lock the flashing tool to a specific version hash from the build system, add a checksum verification step, add a version readback in functional test.

Step 5, functional test. Failure mode: test passes because the fixture is miscalibrated. Effect: non-conforming devices released. Mitigations: daily golden-sample verification, monthly calibration, fixture validation record attached to each production batch.

The pFMEA forces each step to be examined with the same rigour and becomes part of the process validation evidence. It is still not the whole risk management file. It does not cover design hazards, use-environment hazards, biocompatibility risks, or post-market feedback. Those belong in the rest of the EN ISO 14971:2019+A11:2021 file.

When FMEA alone is insufficient

FMEA falls short as a standalone technique in several situations a startup routinely meets.

Systemic software failures. Software fails because of wrong requirements, unhandled states, or interaction effects. A component FMEA misses these. Hazard analysis at the requirements and use-scenario level catches them.

Interaction effects. FMEA is local. Two components that are individually safe can compose into an unsafe system. Fault tree analysis catches what FMEA misses.

Use-environment hazards. A device safe indoors can be unsafe outdoors. A use specification document and a hazard-related use scenario analysis prompt the questions FMEA does not.

Subgroup and context hazards. ML devices fail because the input distribution shifts or a subgroup is underrepresented. FMEA cannot score this. A dedicated ML hazard analysis handles it.

Benefit-risk framing. FMEA rates risks but does not frame them against benefits. The overall residual risk evaluation in EN ISO 14971:2019+A11:2021 clause 8 and the benefit-risk analysis under MDR Annex I GSPR 1 run alongside the FMEA.

Lifecycle maintenance. FMEA is a snapshot. EN ISO 14971:2019+A11:2021 requires the process to run through production and post-production. The feedback loop does not live in the FMEA.

The Subtract to Ship playbook for FMEA in a startup

Step 1. Set up the EN ISO 14971:2019+A11:2021 risk management file first. Plan, hazard list, risk evaluation, control measures, residual risk evaluation, review, production and post-production information. The file structure exists before the first FMEA row.

Step 2. Run hazard identification at the system level before dropping into component-level FMEA. Ask the systemic questions the FMEA will not ask. Multi-disciplinary: development, clinical, RA, marketing, sales, top management. Tibor's follow-up interview flagged this multi-disciplinary session as the state of the art for credible hazard discovery.

Step 3. Use dFMEA where component-level failure modes matter. Interfaces, single-point-of-failure parts, safety-critical signal paths. Do not force every part onto the spreadsheet. Force the parts where FMEA adds value.

Step 4. Use pFMEA during process validation and at tech transfer. This is where the technique is most cost-effective.

Step 5. Apply the EN ISO 14971:2019+A11:2021 three-step risk control hierarchy to every mitigation: inherent safety by design, protective measures, information for safety. Reject any mitigation that jumps straight to a warning when a design change was available.

Step 6. Link every FMEA row to the corresponding requirement, verification test, and residual risk justification. Traceability is not optional, and it is what an auditor will sample.

Step 7. Update the FMEA when the design or process changes, when post-market data changes probability or severity estimates, and at every risk management review. Freeze the FMEA at certification and it stops being compliant the first time anything changes.

Reality Check

  1. Is there a risk management plan, a hazard list, a residual risk evaluation, and a post-production loop, or is there only a FMEA spreadsheet?
  2. Does your FMEA cover the component-level failures it should and leave the systemic and use-context hazards to a separate hazard analysis?
  3. For each high-severity row, does the control measure sit at the highest level of the EN ISO 14971:2019+A11:2021 hierarchy that the design could realistically support?
  4. Does the FMEA get updated when the design changes, or does it freeze at the first release and drift apart from reality?
  5. Can you trace each FMEA row to a requirement and a verification test, or are the columns disconnected from the rest of the engineering record?
  6. Does your team include non-engineers (clinical, RA, sales) when new hazards are discussed, or do only engineers score the rows?
  7. If your certification was audited tomorrow, would the FMEA hold up alongside the rest of the risk file, or would it be the entire risk file?

Frequently Asked Questions

Is FMEA mandatory for CE marking under MDR? No. MDR mandates risk management under Annex I GSPR 3 and points to EN ISO 14971:2019+A11:2021 as the harmonised standard. EN ISO 14971:2019+A11:2021 presents FMEA as one technique among several. You can comply without using FMEA at all, as long as the hazards are identified and controlled by some technique and the full process is documented.

Do we need both dFMEA and pFMEA? It depends on what you design and how you manufacture. A SaMD-only startup has no pFMEA to run for physical assembly, though it may have one for release and deployment processes. A hardware startup almost always needs both.

How does FMEA relate to ISO 14971 clause 5 hazard identification? EN ISO 14971:2019+A11:2021 clause 5 requires the manufacturer to identify reasonably foreseeable hazards. FMEA is one technique for doing that at the component or process-step level. It is not a substitute for the clause itself, and clause 5 hazards may also come from preliminary hazard analysis, use-scenario analysis, or external data.

Can we use a pure risk matrix without FMEA? Yes, and many medical device startups do. A risk matrix with a strong hazard identification upstream can be more effective than a weak FMEA. The format is less important than the rigour of the hazard identification and the traceability to controls.

What about the RPN number controversy? RPN (severity × occurrence × detection) is mathematically problematic because equal products hide different profiles. A high-severity, low-occurrence risk produces the same RPN as a low-severity, high-occurrence risk, and the two need very different treatment. Felix coaches teams to prioritise by severity and by the hierarchy of controls, not by raw RPN.

How often should the FMEA be updated? At every design or process change, at every risk management review, and whenever post-market information changes probability or severity estimates. FMEA updates should be tied to the change-control workflow in the QMS, not to an annual calendar event.

Sources

  1. Regulation (EU) 2017/745 on medical devices, consolidated text. Annex I GSPR 1, 3, 4; Annex I §17.2; Annex VIII Rule 11.
  2. EN ISO 14971:2019+A11:2021, Medical devices, Application of risk management to medical devices.
  3. EN 62304:2006+A1:2015, Medical device software, Software life cycle processes.
  4. MDCG 2019-11 Rev.1 (October 2019, Rev.1 June 2025), Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 and Regulation (EU) 2017/746.