Fault tree analysis is a top-down risk analysis technique that starts with an undesired top event and works downward through combinations of lower-level faults. For medical devices it complements bottom-up FMEA, and a notified body expects founders to explain why they picked one, the other, or both. Neither is mandated by EN ISO 14971:2019+A11:2021, but the standard expects the chosen techniques to be appropriate for the device and traceable to the risks they address.

By Tibor Zechmeister and Felix Lenhard.

TL;DR

  • Fault tree analysis (FTA) is a top-down, deductive technique. It starts with an undesired top event such as "insulin overdose delivered" and decomposes it into contributing faults joined by logic gates.
  • FMEA is bottom-up and inductive. It starts at a component or function and asks what happens when that element fails.
  • EN ISO 14971:2019+A11:2021 does not prescribe a specific technique. ISO/TR 24971 lists FTA, FMEA, HAZOP, PHA and others as examples. The founder picks what fits the device and justifies it.
  • FTA shines when a small number of high-severity top events dominate the risk profile, when multiple failures must combine before harm can occur, and when the team needs to reason about probability.
  • A notified body does not award points for technique choice. It looks for coherence between hazard identification, the analysis technique, the controls, and the residual risk statement in the technical documentation under MDR Annex II.

Why this matters

Most first-time founders treat risk analysis as a single document: a spreadsheet that lists hazards, assigns a probability and severity, and closes out with a colour. Tibor has seen hundreds of those files across fifteen years of notified body audits. In his experience, the weakest ones share a pattern. The team chose a technique without thinking about why. The technique was FMEA, because that is the one they had heard of. And the file surfaces none of the systemic interactions that could actually kill a patient.

Fault tree analysis sits in a different place in the toolkit. It is deductive rather than inductive. It starts at the outcome nobody wants and asks what combinations of faults have to line up for that outcome to occur. For a device where the entire risk argument hinges on a few catastrophic scenarios, an insulin pump delivering a bolus, a ventilator failing to cycle, a laser exposing a non-target tissue, FTA is often the more honest technique. It forces the team to think about dependencies, common-cause failures, and the protective layers between a fault and a patient.

The book on risk management in this series, and the posts on EN ISO 14971:2019+A11:2021 and ISO/TR 24971, cover the wider process. This post is narrower. It answers a specific question founders ask during their first real risk management effort: when should Felix's team reach for fault tree analysis instead of FMEA, and how does Tibor expect them to defend that choice in an audit?

What MDR actually says

The MDR does not mention fault tree analysis by name. It does not mention FMEA either. What MDR (EU) 2017/745 Annex I General Safety and Performance Requirements 1 to 9 requires is that risks are identified, evaluated, eliminated or reduced as far as possible, and that residual risks are acceptable when weighed against the benefit to the patient. Annex II requires the manufacturer to include the risk management file in the technical documentation.

The technique selection question is answered one layer down, in the harmonised standard. EN ISO 14971:2019+A11:2021 is the current harmonised edition. It is the state of the art for risk management of medical devices and the reference the notified body will audit against. The standard establishes a process. It does not lock the manufacturer into a single analysis technique.

ISO/TR 24971 is the accompanying technical report. It is informational, not a harmonised standard, but it is the practical guidance auditors and manufacturers use to interpret EN ISO 14971 in the field. ISO/TR 24971 lists several analysis techniques and describes where each is appropriate. Fault tree analysis, FMEA, HAZOP, preliminary hazard analysis, hazard and operability studies, event tree analysis, and several others all appear. The report treats them as complementary, not as rivals.

One more reference is worth noting. IEC 61025 is the international standard that defines fault tree analysis as a technique. It explains the symbols, the logic, and the maths. A notified body auditor will expect a founder who claims to have done FTA to have done it consistent with IEC 61025, not a loose interpretation.

The plain-language translation: the MDR is outcome-oriented. It asks whether the risks have been identified, controlled, and communicated to the user. EN ISO 14971 asks whether the process was systematic. ISO/TR 24971 offers a menu of techniques that can make the process systematic. The founder picks from that menu and has to explain why.

A worked example

Consider a startup building an insulin patch pump. The device is a wearable, battery-powered, closed-loop delivery system with a mobile app for dose adjustment. The top clinical hazards are well known: severe hypoglycaemia from over-delivery and severe hyperglycaemia from under-delivery or occlusion.

If the team starts with FMEA, they list every component. Battery, pump motor, occlusion sensor, cannula, adhesive, Bluetooth radio, app, cloud backend. For each one, they list failure modes, effects, and current controls. The result is a large spreadsheet. Useful, but the spreadsheet does not answer the question the team actually cares about: what combination of failures leads to a severe hypoglycaemia event?

FTA starts at the other end. The top event is "severe hypoglycaemia caused by device over-delivery". The team asks what immediate causes could produce that top event. One branch is "pump delivers more insulin than commanded". Another branch is "pump delivers the correct amount, but the commanded dose was wrong". A third branch is "pump delivers correctly, commanded correctly, but the patient's physiological state made the dose excessive".

Under the first branch, the team decomposes further. The pump could over-deliver because of a motor control fault, a software loop error, a stuck valve, or a calibration error. Each of those is another level of decomposition. The tree grows downward until every leaf is a fault that can be assigned a probability and a detection mechanism. The logic gates, AND gates where multiple faults must occur simultaneously, OR gates where any one suffices, let the team calculate the probability of the top event from the probabilities of the leaves.

What Felix saw repeatedly when coaching medtech founders through their first serious risk files: the FTA surfaces protective layers that the FMEA missed. The team realises that a motor control fault alone is not sufficient to cause patient harm. A motor control fault AND a missing safety interlock AND an absent redundant delivery check are required. That insight reshapes the design. The team adds a second independent sensor that monitors delivered volume. The probability of the top event drops by an order of magnitude. Tibor's point in the book chapter is simple. FTA changes what the team builds, not just what the team documents.

When is FMEA still the right starting point? For the insulin patch pump, FMEA remains valuable for the long tail of moderate-severity hazards where there is no dominant top event. Adhesive failure, cannula kinking, Bluetooth dropout, app crash. Those are not best analysed by fault tree. They are best analysed by walking the components and asking what happens when each one misbehaves. The mature risk management file for this device uses both. FTA for the catastrophic scenarios. FMEA for the rest. ISO/TR 24971 explicitly supports that combination.

The Subtract to Ship playbook

Felix's coaching rule when a startup founder asks whether to use FTA or FMEA is to refuse the binary. The question is not which technique. The question is what does the device's risk profile actually look like, and which technique surfaces the most insight for the time invested.

Here is the lean sequence Felix and Tibor use with early-stage teams.

Step one. Run a short preliminary hazard analysis first. Not a formal PHA document. A two-hour workshop with development, clinical, usability, and regulatory in the room. List every hazard the team can think of. Group them by severity. If three or four top events dominate the severity landscape, FTA is probably the right deep-dive technique for those. If the severity is spread evenly across dozens of hazards, FMEA is probably the better primary technique.

Step two. For each top event where FTA was chosen, build the tree to at least three levels of decomposition before stopping. Use IEC 61025 symbols. Label AND and OR gates explicitly. Assign probabilities only to leaves that can be estimated from data, supplier specifications, field experience, or literature. Do not invent numbers to fill cells. An incomplete tree with honest uncertainty is more defensible than a complete tree with fabricated probabilities.

Step three. Cross-link the FTA leaves into the FMEA. Every leaf fault in the tree should appear as a row somewhere in the FMEA. Every FMEA row that maps to a top event should have a reference back to the tree. That cross-linking is what makes the file coherent when a notified body auditor asks why the team chose two techniques.

Step four. Write a short technique justification memo, one page, that lives at the front of the risk management file. It explains which techniques were used, why they were appropriate for this device, and how they complement each other. Tibor has never failed to appreciate that memo during an audit. He has seen many teams fail to include it.

Step five. Feed the FTA into the design review agenda, not just the regulatory file. If the tree surfaces a dominant single point of failure, the engineering team should know before the review, not after. FTA that lives only in the RA folder is a wasted artifact.

The subtraction here is not doing less risk analysis. It is doing less redundant risk analysis. A twenty-page FMEA that repeats the same severity assignments across overlapping failure modes is not thoroughness. It is noise. An FTA that isolates the catastrophic scenarios, paired with a focused FMEA that covers the rest, is thoroughness.

Reality Check

Work through these questions with your team before the next risk management review.

  1. Can you name the three to five top events that dominate the severity landscape of your device? If not, your risk file is not yet organised around patient harm.
  2. For each top event, can you trace a path from component-level faults to the top event, and state what protective layers interrupt that path?
  3. Does your current technique choice (FMEA only, FTA only, or both) have a written justification that a notified body auditor could read and understand in under five minutes?
  4. If a supplier datasheet changes tomorrow and a failure rate doubles, does your risk file tell you which top event probabilities need to be recalculated?
  5. Are the probabilities in your FTA leaves traceable to evidence, or were they assigned from intuition?
  6. Does your design review agenda pull insights from the FTA before the design is frozen, or does the FTA document the design after the fact?
  7. When was the last time a technique choice actually changed what the team built, rather than what the team wrote down?

If four or more of these questions make the team uncomfortable, the risk management file is not yet doing the work EN ISO 14971 expects.

Frequently Asked Questions

Does EN ISO 14971:2019+A11:2021 require fault tree analysis? No. The standard requires a systematic process and appropriate analysis techniques. ISO/TR 24971 lists FTA as one example among many. The manufacturer picks based on the device.

Is FTA only for high-risk devices? No, but it is most valuable where severe or catastrophic top events dominate the risk profile. For lower-risk devices, FMEA or preliminary hazard analysis is often sufficient on its own.

Can a notified body reject a risk file that used only FMEA? Not because FMEA was chosen. A notified body can raise a non-conformity if the technique did not surface the risks that matter for the device. That is a technique-fit problem, not a technique-identity problem.

Should the FTA live in the technical documentation under MDR Annex II? Yes. The risk management file is part of the technical documentation. FTA diagrams, calculations, and the cross-link to FMEA all belong in the risk management file referenced from the technical documentation.

Is IEC 61025 harmonised under the MDR? IEC 61025 defines fault tree analysis as a technique. It is not a harmonised medical device standard in its own right, but it is the reference standard for FTA methodology and auditors expect trees to follow its conventions.

Does AI-assisted hazard identification change the picture? Tibor's view is that AI is useful for surfacing hazards humans might miss, particularly in preliminary hazard analysis. It does not replace the structured decomposition that FTA provides. Use AI to expand the hazard list, then use FTA to reason about which combinations lead to harm.

Sources

  1. Regulation (EU) 2017/745 on medical devices, consolidated text. Annex I General Safety and Performance Requirements 1-9, Annex II technical documentation.
  2. EN ISO 14971:2019+A11:2021. Medical devices. Application of risk management to medical devices. Harmonised standard.
  3. ISO/TR 24971. Medical devices. Guidance on the application of ISO 14971. Technical report, informational.
  4. IEC 61025. Fault tree analysis (FTA).