FMEA Alone Will Not Satisfy ISO 14971, and Most Teams Don't Know Why

# FMEA Alone Will Not Satisfy ISO 14971, and Most Teams Don't Know Why

Back in Module 2, I told you about the Therac-25, a radiation therapy machine that delivered doses hundreds of times what was prescribed. The cause was a software race condition that only fired when a specific operator typed a specific sequence fast enough to land inside a specific timing window. You know the story. What I never showed you is the diagram: the actual formal picture an investigator would draw to explain why it happened.

Here's what that diagram makes visible that the story alone doesn't. The harm didn't come from one thing failing. It came from two things being true at the same moment: an experienced operator typing fast enough to fall inside the timing window, and a race condition sitting quietly in code that had shipped and run without incident for months. Neither of those, on its own, is a broken part. The operator typing fast isn't a failure. The code existing isn't a failure. It was the combination, arriving together, that mattered. Take away either one and nothing happens.

I don't want you to file this away as one strange story about one old machine. Harm from a combination of ordinary conditions, rather than a single broken part, is why aviation investigators build fault trees for a plane that flew exactly as designed into terrain, and why nuclear engineers build them for a reactor where every gauge read normal right up until it wasn't. It's a recognized category in every high-consequence field that takes hazard identification seriously. Medical devices are behind on this. Fault tree analysis has been standard in aviation and nuclear safety for decades; medical device hazard identification, in practice, still leans overwhelmingly on one tool.

The thesis

No failure modes and effects analysis, run by anyone, no matter how careful, would have found the Therac-25 combination. Not because the engineers doing it would have been sloppy, but because of how the technique itself works. FMEA is structurally the wrong shape of tool for a hazard that comes from two things that both work exactly as intended, arriving together. If your hazard identification stops at FMEA, there is a whole category of risk in your device you have never actually looked for.

ISO 14971 Clause 5.4 requires you to identify hazards and the sequences of events that could lead to a hazardous situation. It doesn't name a specific technique, but "systematic" implies more than one. Most engineers only really know one: failure modes and effects analysis, the one taught in every quality certification and Six Sigma course. Search for FMEA tutorials and you'll find some of the most-watched risk content online, genuinely well made. Search for fault tree analysis applied to a medical device, and you'll find almost nothing.

I'm Dave Saunders. I've spent more than 30 years commercializing technology, almost 20 of them in medical devices and regulatory affairs, including several surgical robots, a good part of it in audit rooms. The finding I've seen most often isn't a bad probability estimate. It's a hazard analysis that only ever ran one technique, and missed an entire class of risk because nobody went looking for it a second way.

This is Module 5 of a twelve-module masterclass building a complete ISO 14971 risk management file from scratch, using one running device: WearPump, a wearable subcutaneous insulin pump for Type 1 diabetes. Module 4 gave WearPump its three inputs: an intended use statement, a foreseeable-misuse list, and a safety-characteristics table. This module turns those three inputs into hazards, using two techniques that run in opposite directions.

Two directions

FMEA runs forward, from the part: what could fail? Fault tree analysis runs backward, from the harm: what combination of conditions causes it? Both belong in a systematic hazard identification. Neither replaces the other.

FMEA has a simple spine: failure mode (how could this part fail), local effect (what happens right where it happens), and downstream effect (what happens all the way to the patient, which is where a hazardous situation lives). It comes in two flavors: design FMEA, for the device itself, and process FMEA, for how it gets made. Each failure mode gets scored on severity, occurrence, and detection, and every score needs a documented reason. A shrug is a finding waiting to happen. Run it as a team exercise, not solo: pull in engineering, clinical, and manufacturing perspectives, and walk the safety-characteristics table row by row.

Running FMEA on WearPump

That's a real, useful table, and it's fair to say what FMEA is good at: forward, part-by-part, it will find most of a device's single-point-failure risk.

But look at the shape of the question it asks: how could this one thing fail, while everything else is assumed to be working normally? That's not a flaw in how carefully someone runs the analysis. It's built into the structure of the technique, and it means FMEA can't reach two categories of hazard. The first: hazards that arise when nothing fails at all, when every part does exactly what it was designed to do (we named these normal-condition hazards back in Module 2). The second is the one that got the Therac-25 patient: hazards that require two or more things to be true at the same time, where none of them, alone, is a failure. FMEA looks at one failure mode against a normal backdrop. It was never built to ask what happens when two normal things collide.

Fault tree analysis, working backward

Fault tree analysis starts from a specific harm, the top event, and works backward through logic gates to the basic events that could cause it. An OR gate means any one branch alone is enough; an AND gate means every branch underneath it has to be true at the same time. The AND gate is the one that reaches what FMEA cannot, because it can trace a harm back to a combination of ordinary conditions, none of them a failure.

Picking which harms get a tree is a judgment call: start from the worst outcomes in your severity table, and build a tree for each one worth the effort. A basic event you trace back to is a minimal cut set, the smallest combination sufficient to trigger the top event on its own.

Here's the Therac-25's actual tree. Top event: patient receives a massive radiation overdose. Underneath it, a single AND gate with two basic events: a race condition present in the code, dormant on most days, AND an operator entering the sequence fast enough to hit the timing window. Neither branch alone reaches the top event. Only their combination does, and that's exactly what makes it invisible to a technique that only ever asks "what could fail?"

Running FTA on WearPump

WearPump's tree starts from the same top event as its worst FMEA finding: severe, undetected hypoglycemia from an unintended bolus. Underneath sits an OR gate with three branches. Branch one is the motor driver failure FMEA already found. Branch two is the dosing algorithm double-count FMEA also found. Branch three is where fault tree analysis earns its keep: an AND gate requiring an occlusion in the tubing (foreseeable, not a failure), the alarm set to silent or vibrate (a normal setting), and the patient asleep or otherwise unable to notice it. Three ordinary conditions form a minimal cut set, and none of them is a broken part.

The arithmetic explains why a combination like this is rare even though every condition inside it is common: for an AND gate you multiply the branch probabilities, you don't add them. An occlusion on roughly one wear cycle in 20, an alarm left silent on roughly one cycle in 10, a patient asleep for roughly a third of a cycle, multiplied together, lands around one in 600, not one in 20. Walk back through how FMEA works and ask which of those three would ever show up as a failure mode: none of them. An occlusion isn't a pump failure. A silent alarm is a feature working as designed. A sleeping patient isn't a failure at all. Only an AND gate, traced backward from the harm, was ever going to surface that branch. The same backward tracing turns up a second AND-gate entry (extended wear plus water exposure degrading the adhesive seal) and a third, OR-gate entry on the connectivity path (a DIY loop command, or a mid-command Bluetooth drop).

Where both techniques converge

Assembled, WearPump's hazard traceability matrix now has 11 entries: the four original ones from Module 2, four more FMEA found today (motor driver, dosing algorithm, reservoir seal, Bluetooth radio), and three more fault tree analysis found working backward (the silenced-alarm combination, the moisture combination, the connectivity path). Finish the pass, running FMEA across every remaining part and fault tree analysis backward from every harm category in the characteristics table, and the real count lands at a dozen or more, exactly what Module 3 promised, not because the device is unusually dangerous, but because that's what a device has once you stop looking with only one tool.

Both the FMEA table and every fault tree belong in the risk management file as records, not scratch work you discard once the matrix is populated. When an auditor asks how you arrived at a hazardous situation, you hand them the diagram; you don't reconstruct your thinking from memory.

The practical rule

Run FMEA thoroughly, part by part, function by function. It's the right tool for single-point failures and will find most of a device's risk. Then run fault tree analysis backward from every serious harm you can name, specifically hunting for the combinations FMEA's one-failure-at-a-time structure cannot reach. Neither replaces the other. Running only one leaves a specific, predictable, nameable gap in your hazard analysis, whether or not anyone ever notices it.

Every entry in that expanded matrix now has a hazard, a sequence of events, a hazardous situation, and a harm. What it doesn't have yet is a real number. Module 6 takes this table and assigns actual probability and severity to every row, against the five-by-five matrix built in Module 3, and finds out which hazardous situations demand a control.

If this was useful, Module 6 is next. More on product strategy, roadmaps, and fractional CPO work at baserealitygroup.com, and I write more broadly for founders too, in a newsletter called The Build, at davesaunders.net.

Dave Saunders is the founder of Base Reality Group and a Fractional CPO for hard-tech founders. He was a founder and operator at Galen Robotics, where the surgical-robotics platform earned FDA De Novo authorization in 2023, and he managed a 35-patent portfolio licensed from Johns Hopkins. He wrote Founders Who Finish and publishes The Build. More about Dave →