Interactive guide · 6 methods · about 74 min, or jump to what you need
Root Cause Analysis for MedTech Quality Events
CAPA procedures were the most cited section on FDA device inspection reports in every year from FY2021 to FY2025.[1] A CAPA only holds up if the investigation finds the real cause. This guide shows you how, with a working tool for each method.
What do you need to do?
Not sure which fits? Answer four questions in the method finder →
Part 1 of 7 · Field guide · 12 min read
Root Cause Analysis in MedTech: A Field Guide for Quality Investigations
Start here: what regulators expect, how to tell a real root cause from a symptom, and how to choose a method.
Why root cause analysis gets so much scrutiny
Corrective action only works if it addresses the actual cause. Fix a symptom and the problem comes back, often in a different lot, product line or customer site, and now there's a recurring issue on record that an investigator can trace through your CAPA history.
That's why CAPA is consistently the most cited area in FDA device inspections. In every fiscal year from 2021 to 2025, the last full year under the old Quality System Regulation, inadequate CAPA procedures (21 CFR 820.100(a)) were the most cited device regulation section on Form 483s.[1]
Chart
Most cited FDA device inspection observations, by fiscal year
Number of times each regulation section was cited on device Form 483s, summed across all citation variants FDA uses for that section. Top 10 per year (ties included). Covers 483s generated in FDA’s electronic inspection system, not manually prepared ones. Hover or tap a bar for detail. Source: FDA Inspection Observations spreadsheets, Devices tab, FY2021–FY2025.[1]
Since February 2, 2026, 21 CFR Part 820 is the Quality Management System Regulation (QMSR), which incorporates ISO 13485:2016 by reference.[2][3] The section numbers changed. The expectation didn't: you have to find out why a nonconformity happened before you decide what to do about it.
Where the requirement lives
ISO 13485:2016 §8.5.2 (Corrective action) requires a documented procedure for corrective action. Among other steps, you have to review nonconformities (complaints included) and find out what caused them, and the action you take has to be in proportion to the effect of the problem.[4]
ISO 13485:2016 §8.5.3 (Preventive action) applies the same logic to potential nonconformities and their causes.[4]
FDA QMSR (21 CFR 820, effective Feb 2, 2026) adopts ISO 13485:2016 by reference. FDA retired QSIT the same day and now inspects under Compliance Program 7382.850.[3][5][6]
EU MDR Article 10(9) and IVDR Article 10(8) require the quality management system to cover corrective and preventive action and verification of its effectiveness.[7][8]
ISO 14971:2019 §10 requires production and post-production information to be reviewed for relevance to safety. Investigation findings belong in the risk management file, not just in the CAPA.[9]
What a root cause is, and what it isn't
Neither ISO 13485 nor 21 CFR 820 defines "root cause," but the working definition most quality teams use is: the most fundamental reason a problem occurred that, if removed, would prevent it from happening again.[10] It's useful to separate four layers that investigations often blur together:
What you observed. Adhesive bonds on Lot 2291 failed pull-strength testing.
The physical mechanism. The curing oven ran 12 °C below its validated temperature.
Why the mechanism was possible. A technician replaced the oven's temperature controller during a repair, and the new controller was never set up or checked against the validated profile.
Why the gap existed in the system. Equipment repairs are handled as routine maintenance, outside change control, so nobody is prompted to ask whether a repair affects a validated process.
Fixing the symptom means scrapping the lot. Fixing the direct cause means correcting the oven's temperature. Fixing the root cause means requalifying the oven after the repair. Fixing the systemic cause means every repair to equipment that runs a validated process, on any oven, sealer or bonder, goes through change control. The deeper you go, the more problems you prevent, which is the point of the "preventive" in CAPA.
Quick quiz
Symptom, direct cause or root cause?
Statement 1 of 7
The investigation funnel
The six methods in this guide aren't competitors. Each one is strongest at a particular stage of an investigation, narrowing from "we have a lot of problems" to "we know why this one happened and have proven it." Click a stage to see what it's for.
Try it
Five stages, six methods
Find the right method for your problem
Answer four questions about the problem you're investigating. The finder suggests where to start, what to use next and whether you need a formal framework around it.
Method finder
What should I use?
Your recommendation appears here once all four questions are answered.
The six methods side by side
Here's how the methods compare on the things that matter when you're planning an investigation.
| Method | Best for | Effort | Needs data? | What you get | Watch out for |
|---|---|---|---|---|---|
| Pareto | Choosing which problem to investigate first | Yes, counts or costs | A ranked list of categories | Ranking by count alone and ignoring severity | |
| Is / Is Not | Vague or intermittent problems | Yes, facts on where and when | A sharp problem statement and a test for candidate causes | Filling it with assumptions instead of checked facts | |
| Fishbone | Exploring many possible causes as a team | Not to start | A map of candidate causes to verify | Treating the diagram as the answer | |
| 5 Whys | Drilling down a single cause chain | Evidence at each step | A cause chain ending in a system gap | Stopping at a person or at the first plausible answer | |
| Fault tree | Failures that need several conditions together; safety-critical systems | Helpful, for probabilities | The logic of how failures combine, plus cut sets | Assuming events are independent when they share a cause | |
| 8D | Cross-functional or supplier problems needing a formal record | Yes, throughout | A complete, team-owned report from containment to prevention | Filling in the form without doing the analysis |
Six tests for a real root cause
Before you write the root cause into the record, check it against these tests. Tick each one your candidate passes. If it doesn't pass most of them, you've probably found a symptom or a direct cause.
Self-check
Is it really the root cause?
How deep should you go?
ISO 13485 asks for corrective action in proportion to the effect of the problem[4], and the same principle applies to the investigation. A cosmetic label smudge caught at incoming inspection doesn't need a fault tree. A field failure that could injure a patient needs more than a 5 Whys written by one person. A simple risk-based guide:
| Potential effect | Typical investigation | Evidence expected |
|---|---|---|
| Low No safety or performance impact, caught in-house | Correction plus a short 5 Whys; trend it, don't necessarily open a CAPA | Record of the correction and the cause; included in trending |
| Medium Performance impact, repeat issue or reached a customer | Is / Is Not to scope it, then Fishbone and 5 Whys with a small team | Data or test results confirming the cause; scope check across lots and products |
| High Potential patient or user harm, reportable event or field action | Cross-functional team, multiple methods (often 8D with fault tree), formal cause verification | Reproduction or designed testing; risk file updated; regulatory reporting assessed; effectiveness criteria set before closure |
Seven ways investigations go wrong
"Operator error" as the root cause
People make mistakes in every system. The question is why the system allowed the mistake to matter. Was the instruction ambiguous? Was the step easy to skip? Was there no check downstream? Human error is where the analysis starts, not where it ends.
Retraining as the corrective action
If the fix is "retrain," the implied root cause is "they didn't know." Was that verified? If the person knew the procedure and still deviated, retraining won't change anything. Investigators look for this pattern specifically.
Stopping at the first plausible answer
The first cause someone suggests is usually the most visible one, not the most fundamental. Keep asking why until you reach something in the system (a procedure, design, specification or control) that you can change.
Consensus instead of evidence
A cause the team agrees on in a meeting is a hypothesis. A cause confirmed by data, test results, reproduction or records is a finding. Write down which one you have.
Scope that stops at the failed lot
If the cause is a gap in a PM procedure, every machine maintained under that procedure is exposed. Ask where else the root cause could exist: other lots, products, sites, suppliers and equipment.
No link back to risk management
A failure mode that wasn't in your risk analysis, or one occurring more often than estimated, means the risk file is out of date. ISO 14971 expects that feedback loop to be closed.
Effectiveness checks that measure activity
"Procedure revised and training completed" shows you did something. "Zero bond failures across the next 30 lots, against a prior rate of 2.1%" shows it worked. Set the measure when you plan the action, not when you close the CAPA.
Part 2 of 7 · Pareto · 9 min read
Pareto Analysis: Finding the Vital Few in Your Complaints and Nonconformances
Most quality teams have more open problems than people to investigate them. Pareto analysis is how you decide where to start: rank the problems, find the few categories that drive most of the pain, and point your investigation there. It takes an afternoon, it's easy to defend in a management review, and it's easy to get subtly wrong.
What Pareto analysis is
The idea is usually traced to the economist Vilfredo Pareto, who around the turn of the 20th century is said to have noticed that a fifth of Italy's people held roughly four-fifths of its land. Decades later, the quality pioneer Joseph Juran saw the same lopsided pattern in defects and named it the principle of the "vital few and the trivial many" (he later preferred "useful many").[11] In most processes, a small number of causes produce most of the problems.
A Pareto chart makes that pattern visible. Bars show each category, sorted largest first. A line shows the cumulative percentage. Where the line crosses roughly 80%, everything to the left is your vital few.[12]
80/20 is a rule of thumb, not a law. Sometimes it's 70/30, sometimes 90/10. Sometimes there's no vital few at all, and that tells you something too.
Where it fits in the QMS
ISO 13485:2016 §8.4 (Analysis of data) requires you to analyze data from feedback, product conformity, process and product trends, suppliers, audits and service reports, and to determine the appropriate methods, including statistical techniques. Pareto is one of the most common of those techniques, and a common way to decide which trends warrant a CAPA.[4]
EU MDR Article 88 and IVDR Article 83 require reporting of statistically significant increases in the frequency or severity of incidents that aren't otherwise reportable, where the increase could significantly affect the benefit-risk analysis.[7][8] Consistent coding and regular Pareto review are what let you see those increases.
Build one: the interactive Pareto
Pick a data set or type in your own. Edit any count or severity and the chart redraws. Bars in navy are the vital few, the smallest set of categories that together reach the threshold.
Try it
Pareto builder
Edit the data, or type in your own (severity 1 = negligible, 5 = could cause serious harm)
| Category | Count | Severity |
|---|
Frequency is not risk
Go back to the complaints data set and switch to Rank by count × severity. "Device overheating" jumps from seventh place to third, and into the vital few. It's rare, but a patch that runs hot while worn against the skin for days can burn the patient. Ranked by count alone, it would never get investigated.
This is the most important judgment call in Pareto analysis. A count-only Pareto tells you what annoys customers most often. A severity-weighted Pareto gets closer to what matters for safety. Run both, and treat any high-severity category as a candidate for investigation regardless of where it ranks.
Tip
Use the severity scale already defined in your risk management file, so a Pareto ranking and a risk assessment never disagree about how bad a failure is. Multiplying by a simple 1–5 score is a screening tool, not a risk evaluation. Anything with a credible path to serious harm gets reviewed no matter where it lands.
Drill down with a second-level Pareto
A first-level Pareto tells you which category to investigate. It rarely tells you enough to start a root cause analysis. The next move is to split the top bar by another dimension, such as location on the device, lot, production line, shift or customer site, and run Pareto again.
Try it
Split “Early detachment” complaints by…
Notice how the "By wear site" split is flat but "By where it lifts" isn't. A flat split rules that dimension out, which is useful evidence in itself. Here, three of four detachments start around the electrode pads, which points the next step (an Is / Is Not analysis) at one specific bond in the patch.
Step by step on your own data
Define the question and the window
"Which complaint types drove the most reports for product family X over the last 12 months?" Fix the time window and the population before you pull data.
Use consistent categories
Categories only work if the same problem is always coded the same way. For complaints, the IMDRF adverse event terminology (Annex A device problem codes) gives you an internationally recognized list.[13] For NCs, use a controlled defect-code list rather than free text.
Count, sort and accumulate
Count each category, sort descending, and calculate each category's cumulative share of the total.
Weight by what matters
Add a severity-weighted or cost-weighted view. If production volume changed during the window, compare rates (per 10,000 units, say) rather than raw counts.
Pick the vital few, then drill down
Take the top categories, plus any high-severity ones, and split them by a second dimension until the problem is specific enough to investigate.
Re-run it after the fix
A before-and-after Pareto with the same categories and window length is one of the clearest pieces of CAPA effectiveness evidence you can show. The target bar should shrink, and nothing else should grow to replace it.
Common mistakes
An "Other" bar that's one of the biggest
If "Other" or "Unknown" is in your top three, your coding scheme isn't working. Fix the coding before you trust the ranking.
Categories that overlap
"Early detachment" and "Adhesive failure" may be the same event coded two ways. Each event should land in exactly one category for a given chart.
Raw counts when volume changed
If you doubled production, complaints doubling isn't a trend. Normalize by units sold or built.
Treating the chart as the root cause
Pareto tells you what to investigate. It never tells you why. "Early detachment is our top complaint" is a starting point for the methods in the rest of this series.
Part 3 of 7 · Is / Is Not · 10 min read
Is / Is Not Analysis: Detective Work for Quality Engineers
"Some patches are falling off" isn't a problem statement. It's the start of an argument. Is / Is Not analysis replaces guesswork with a precise specification of the problem: what it is, and just as important, what it could be but isn't. Done well, it rules out most candidate causes before anyone opens a fishbone, and it tells you exactly which lots you need to contain.
The idea: compare, don't guess
The technique comes from Charles Kepner and Benjamin Tregoe's problem analysis method, published in The Rational Manager in 1965.[14] The insight is simple. For every fact about where the problem appears, find the closest place it could appear but doesn't. The difference between the two, the distinction, is where the cause is hiding.
You work through four dimensions:
What
Which product, part, model or defect? What could be affected but isn't?
Object and defectWhere
Where on the device? Which line, site or region? Where in the process is it seen?
LocationWhen
When was it first seen? When in the lifecycle or process? Any pattern by shift, lot or season?
TimingExtent
How many units? How big is each defect? Getting better, worse or stable?
Magnitude and trendThen, following Kepner and Tregoe, you ask two questions of every distinction: what's unique about the "is" side? and what changed in, on or around that, and when? Most problems that appear suddenly are caused by a change. Is / Is Not helps you find which one.[10]
Look at the data first
In Part 2, a second-level Pareto showed that most early-detachment complaints on a wearable ECG patch started around the electrode pads. Before filling in the Is / Is Not table, plot the complaint rate over time, split by anything you can split by. Here it's the two assembly lines that build the patch, Lines 1 and 3 (Line 2 builds a different product).
Chart
Early-detachment complaints per 1,000 units, by build week
Illustrative data. Hover or tap a point for values. The shaded band marks weeks 11–12, when a new laminator was installed on Line 3, which the investigation team found in the equipment change log.
A chart like this answers half the Is / Is Not table on its own: it's Line 3, not Line 1, and it started around week 12. It also tells you the scope for containment. Units built on Line 1, and Line 3 units built before week 12, look unaffected, though you still need evidence before you treat them that way.
Worked case: early detachment on a wearable ECG patch
Here's the completed table. The facts come from complaint records, returned-unit analysis, production records and the change log. Click Show to reveal what the team concluded was distinctive about each pair, and try to work it out first.
Try it
Problem: adhesive lifting around the electrode pads of WP-200 wearable ECG patches
| Is | Is not | What’s distinctive? |
|---|
Test the candidate causes
The team brainstormed five possible causes. This is where Is / Is Not pays off: a true cause must explain every fact in the table, including every "is not." Pick a candidate to test it against the facts.
Detective game
Which cause survives every fact?
The most probable cause still needs proof
Surviving the table makes the laminator the most probable cause, not a confirmed one. The team verified it by measuring the nip roller pressure (it was 30% below the validated setting after the new unit's default parameters were loaded), then building patches at both settings and running a 72-hour simulated-wear peel test. Only the low-pressure patches separated. That's the evidence that goes in the CAPA.
Your own Is / Is Not worksheet
Use this on a live investigation. Fill in what you know, leave blanks where you need data, and copy the result into your NC or CAPA record. Nothing you type leaves your browser.
Worksheet
Is / Is Not
Tips from real investigations
"Is: Line 3. Is not: our other factory in another country" tells you very little. "Is not: Line 1, which builds the same model from the same components" tells you a lot. The more alike the two sides, the sharper the distinction.
Every cell should be traceable to a record, a measurement or an observation. If you're not sure, write "unknown, check returned units" rather than a guess. Assumptions in the table will quietly eliminate the real cause.
Equipment changes, supplier notifications, document revisions, new personnel, software updates and environmental excursions in the window before the problem started. Most sudden problems trace back to one of them.
The "is not" side is your evidence for what's not affected. That supports a defensible decision about which lots to hold and which to release, which matters as much to the business as finding the cause.
Is / Is Not works best when a problem has a clear "before" and "after" or a clear "here" and "there." For problems that have always existed at a low level, with no sharp boundary, start with a fishbone instead.
Part 4 of 7 · Fishbone · 10 min read
Fishbone (Ishikawa) Diagrams for Medical Device and IVD Investigations
The fishbone diagram is the most recognizable tool in root cause analysis, and probably the most misused. Drawn well, it gets a cross-functional team to consider causes no single person would think of, then forces each one to be checked against evidence. Drawn badly, it's a wall of guesses that gets attached to a CAPA and never looked at again. Here's how to draw it well.
What a fishbone diagram is
The cause-and-effect diagram was popularized by Kaoru Ishikawa, the Japanese quality pioneer, and it's named after him and its shape.[15] You write the effect you're investigating on the right, draw one long line leading into it, and angle a handful of category lines off that main line. Candidate causes go on the category lines, with finer detail branching off them in turn.
Its job is breadth. Other methods, like the 5 Whys, go deep down one path. The fishbone makes sure you've looked at all the paths before you pick one. That's why it works best as a team exercise, early in an investigation, after the problem has been precisely described.[10]
A fishbone is a list of hypotheses. Every cause on it is a suspect until evidence clears it or confirms it.
The six categories, adapted for MedTech
The classic manufacturing categories are the "6Ms": Man, Machine, Method, Material, Measurement and Mother Nature. Most teams now say People and Environment. Pick a category to see the questions worth asking in a device or IVD investigation.
Prompt cards
Questions to ask on each bone
The categories are a prompt, not a rule. Service and software investigations often use different ones: for software, requirements, design, code, configuration, data, environment and test. Use whatever set makes your team look in places they otherwise wouldn't.
Build a fishbone: interactive diagram
The example is loaded: QC release testing for an ELISA kit that started failing its precision specification. Click any cause on the diagram to change its status as evidence comes in. Then clear it and build one for your own problem.
Try it
Fishbone builder
In the example, evidence cleared most suspects. Rerunning the same kit lots on a second plate washer brought the CV back within spec, which told the team the kits were fine and the lab's test system was the problem. A flow check then found two nozzles partly blocked, so uneven washing left unbound conjugate in some wells. That's a verified direct cause, but not yet a root cause. The next question is why the nozzles could clog without anyone noticing, and that's a job for the 5 Whys.
Running the session
Start from a precise problem statement
"QC release runs for kit lots 24-031 onward fail precision, CV 9–12% against a spec of ≤8%" is a fish head. "Precision issues" isn't. An Is / Is Not analysis gives you this.
Invite the people who do the work
Include the analyst who runs the assay, the technician who maintains the equipment and someone from the supplier quality side, not only engineers and QA. Five to eight people is about right.
Brainstorm silently first
Give everyone five minutes to write causes on their own before anyone speaks. It stops the most senior person's theory from anchoring the room.
Place, merge and ask "why" once
Put each cause on a bone, merge duplicates, and for the strongest ones ask one level of why to add a sub-cause. Keep each cause specific enough to check.
Plan how to check each suspect
Next to each cause, write the record, measurement or experiment that would confirm or clear it. This turns the diagram into an investigation plan.
Update it as evidence arrives
Mark causes verified or ruled out, with a reference to the evidence. The finished fishbone in the CAPA should show what you cleared and why, which is exactly what an auditor wants to see.
What separates a useful fishbone from a wall of guesses
| Weak cause | Why it’s weak | Stronger version |
|---|---|---|
| “Materials” | A category, not a cause. You can’t check it. | Coating antibody lot 7731 has lower affinity than lot 7690 |
| “Operator error” | Blames a person and stops the analysis. | Pipetting technique for the 50 µL step isn’t defined in the SOP |
| “Need better training” | A solution written as a cause. | Analysts hired after March weren’t trained on the revised wash procedure |
| “Equipment issue” | Too vague to point at anything. | Washer nozzles partly clogged, giving uneven dispense and aspiration across the plate |
| “Temperature” | Which temperature, where, how far off? | Lab exceeds 25 °C on afternoons when the HVAC cycles |
The test for every cause on the diagram: could someone go and check this tomorrow? If not, rewrite it until they could.
Part 5 of 7 · 5 Whys · 10 min read
The 5 Whys, Done Right: Getting Past "Operator Error"
The 5 Whys is the simplest root cause method there is: state the problem, ask why, and keep asking until you reach something you can fix. It's also the method most likely to end at the wrong answer, usually a person's name or the word "retrain." This guide shows how to keep it honest, with a worked example and a builder that flags weak answers as you type.
Where the 5 Whys comes from
The technique is associated with Sakichi Toyoda and was made famous by Taiichi Ohno as part of the Toyota Production System.[16][17] Ohno's own example: a machine stopped because a fuse blew; the fuse blew because the bearing was under-lubricated; the pump wasn't pumping enough oil; its shaft was worn; and there was no strainer, so metal scrap got in. Replacing the fuse fixes today. Adding the strainer fixes the problem.[17][18]
Don't take the five literally. A simple failure might bottom out at the third why, a messy one at the seventh. What matters is refusing to stop at the first answer that sounds good enough.
You've reached a root cause when the next "why" leads outside what your organization can control, or when the answer is a gap in a procedure, design or control you can actually change.
Worked example: from clogged nozzles to a system gap
In Part 4, a fishbone narrowed an ELISA precision failure to one verified cause: partly clogged plate washer nozzles. Here's the 5 Whys the team ran from there. Step through it and notice that every answer comes with evidence.
Walk-through
Problem: QC release runs for ELISA kit lots 24-031 onward fail precision (CV 9–12% vs. ≤8%)
Look at where a weaker investigation might have stopped. At Why 2, the fix would have been "clean the nozzles," and it would have recurred in a month. At Why 4, "analysts didn't rinse the washer" sounds like a people problem, and the CAPA would have said "retrain." But the analysts were following the procedure exactly. The procedure was what was wrong.
Three legs: occurrence, detection and system
A single chain explains why the problem happened. For any problem that reached a customer, or nearly did, expect auditors and investigators to ask why it wasn't caught. Many teams run three short chains, sometimes called a three-legged 5 Whys:
Try it
The three legs, for the ELISA case
Build your own 5 Whys
Type your problem and work down the chain. The builder checks each answer for the patterns that usually mean an investigation stopped too early, and when you're done, reads the chain back to you in reverse so you can test the logic. Nothing you type leaves your browser.
Builder
5 Whys with live checks
Rules that keep it honest
Every answer needs evidence
Write down what supports each step: a record, a measurement, an observation, a test. If nobody can point to proof for a step, treat it as a guess, and remember that every why below it inherits that weakness.
Never stop at a person
If an answer names a person or a role, the next question is why the system let that action cause a problem. Was the step unclear, hard to do correctly, or missing a check? This is the single most common weakness investigators find in CAPA records.
Branch when there's more than one cause
If an answer is "A and B," split the chain and follow both. Real failures often have contributing causes, and a strictly linear 5 Whys will quietly drop one of them. If you're branching a lot, a fault tree may be the better tool.
Read it backward
Start at the root cause and read up the chain with "therefore" between each step. If any step doesn't follow, the chain has a gap.
Do it with the people who know
A 5 Whys written alone at a desk reflects one person's assumptions. Ask the people who run the process, and go and look at it. In lean terms, go to the gemba.
Part 6 of 7 · Fault tree · 12 min read
Fault Tree Analysis: Top-Down Logic for Complex Device Failures
Some failures don't have a single cause. A patient is harmed only when a fault occurs and the safeguard that should catch it also fails. The 5 Whys follows one chain and can miss that. Fault tree analysis models how failures combine, shows which combinations matter most, and gives you a map for eliminating causes one by one during an investigation.
How a fault tree works
Fault tree analysis was developed at Bell Laboratories in the early 1960s to evaluate the Minuteman missile launch control system, and it's standardized today in IEC 61025.[19][20] You start with one undesired top event and work downward, asking at each level: what must happen for this to occur? The answers are connected with logic gates until you reach basic events, failures you can't or don't need to break down further.[21]
OR gate
The event above occurs if any input occurs. Probabilities roughly add. A single point of failure sits under an OR gate.
P ≈ P₁ + P₂AND gate
The event above occurs only if all inputs occur together. Probabilities multiply. This is what redundancy and safeguards look like.
P = P₁ × P₂Basic event
A component failure, software fault or human action at the bottom of the tree, with an estimated probability if you’re quantifying.
LeafStandards
IEC 61025:2006 defines fault tree symbols, construction and analysis. ISO/TR 24971:2020, the guidance to ISO 14971, describes FTA among the risk analysis techniques in its Annex B. In design, the tree supports risk analysis. After a failure, the same tree becomes an investigation tool.[20][22]
A live fault tree: electrosurgical burn
This simplified tree shows three ways an electrosurgical generator could cause an unintended burn. Drag the sliders to change each basic event's probability per procedure, or try the design changes. The top event and every gate recalculate as you go. The numbers are illustrative, not data for any real generator.
Try it
Top event probability:
Click a basic event in the tree to jump to its slider.
Design what-ifs
Basic event probabilities (per procedure)
Cut sets: the combinations that matter
A minimal cut set is a combination of basic events that is enough on its own to produce the top event, where removing any one of them breaks the chain. Cut sets are what the tree is really for. A cut set with one event is a single point of failure. A cut set with two events is a fault plus a failed safeguard. Ranking cut sets by probability shows where a design change, or a corrective action, buys the most safety.
Live results
Minimal cut sets and event importance
| Cut set | Events | Probability | Share of top event |
|---|
Sensitivity: how the top event moves with one basic event
Log–log scale. The dot marks the current value. A steep line means the top event is sensitive to this event; a flat line means improving it changes little.
With the starting values, the unintended-activation path dominates. Making the output stage or power sensor more reliable would barely move the top event, while raising the minimum activation-tone volume would cut it by almost two-thirds. Tick that what-if and watch the ranking change: the return-pad path becomes the next one to work on. That's the kind of conclusion that's hard to reach by intuition and easy to defend with a tree.
Using a fault tree in an investigation
After a real burn report, you don't need probabilities. You need to know which path actually happened. Switch the tree into elimination mode: as evidence comes in from the generator log, the returned generator and handpiece, and the clinical record, mark each basic event confirmed or ruled out. Cut sets that contain a ruled-out event can't explain the report.
Elimination mode
Which path explains the report?
Click each event to cycle: open → ruled out → confirmed. The evidence column suggests what a real team would check.
Cautions
AND gates multiply only if the events are independent. A shared power supply, a common software module, the same supplier lot or the same busy surgical team can make two "independent" failures happen together. Look for these common-cause failures explicitly, or the tree will be optimistic.
Putting a credible number on the chance of a software fault is hard, and opinions differ on whether it can be done well. IEC 62304 doesn't rely on one when classifying software safety, and IEC/TR 80002-1 covers how to handle software in risk analysis. Many teams treat software events qualitatively and lean on the hardware or independent safeguards that sit with them under an AND gate.[23][24][25]
A top event probability shown to three significant figures looks authoritative. It's only as good as the basic event estimates. Use field data, supplier reliability data and published human error rates where you can, and say where you guessed.
If an investigation finds a path that wasn't in the design fault tree or the FMEA, or a basic event happening far more often than estimated, update the risk management file. That's the feedback loop ISO 14971 clause 10 requires.[9]
Part 7 of 7 · 8D · 11 min read
8D Problem Solving: A Team Discipline for CAPA and SCAR
The other methods in this guide are analysis tools. 8D is the frame you put them in. Its eight disciplines take a cross-functional team from the first alarm through containment, root cause, corrective action and prevention, and leave a record anyone can audit. It's the format most suppliers already know, which makes it the natural language for supplier corrective action requests.
Where 8D comes from, and why MedTech uses it
Ford Motor Company published the Eight Disciplines in its Team Oriented Problem Solving manual in 1987.[26] A preparation and emergency-response step, D0, was added later.[27] It spread through the automotive supply chain, and since many component suppliers serve automotive, aerospace and medical customers at once, it's now one of the most common formats for supplier corrective actions in MedTech.
8D doesn't replace your CAPA procedure. It's a structure for running one. Its strengths are that it forces containment before analysis, it makes you explain both how the defect was made and how it got past your checks, and it ends with preventing recurrence elsewhere rather than only fixing this instance.
Where it fits in the QMS
ISO 13485:2016 §8.5.2 requires the corrective action steps that 8D walks through: review, cause determination, action, verification that the action doesn't adversely affect the ability to meet regulatory requirements or the device's safety and performance, and review of effectiveness. §7.4.1 requires you to monitor suppliers and take action, proportionate to risk, when they don't meet purchasing requirements. That's where a SCAR, often answered as an 8D, comes in.[4]
The disciplines, step by step
Click through each discipline. Every step lists what it's for, what it should produce, what's specific to medical devices, and a short checklist. Tick items as you go if you're using it on a live problem.[28][7]
Try it
8D walkthrough and checklist
Containment is not correction: the chart
One of the most useful ideas in 8D is the difference between D3 and D6. Interim containment (sorting, 100% inspection, holds) stops bad parts reaching the customer. It doesn't stop them being made. Only the permanent corrective action changes the defect rate. Toggle between the two measures to see it.
Chart
Defects reaching the customer, per 1,000 parts
Illustrative weekly data for a supplier-molded component. The effectiveness target and verification window were set in D5, before the action was implemented.
Reviewing a supplier's 8D
When a supplier sends back an 8D in response to your SCAR, someone has to decide whether to accept it. Tick anything you see in the response. The reviewer tells you whether it's ready to accept.
Reviewer’s checklist
Red flags in a SCAR response
How 8D maps onto your CAPA
If your CAPA form uses its own stages, here's how the disciplines line up, so a supplier's 8D can be filed against your record without re-writing it.
| 8D discipline | Typical CAPA stage | Analysis tools in this guide |
|---|---|---|
| D0 Plan and respond | Initiation, risk assessment, reportability decision | — |
| D1 Form the team | Owner and team assignment | — |
| D2 Describe the problem | Problem statement, scope | Pareto, Is / Is Not |
| D3 Contain | Containment and correction, impact assessment | Is / Is Not for scope |
| D4 Root cause and escape point | Investigation | Fishbone, 5 Whys, Fault tree |
| D5 Choose and verify actions | Action plan with effectiveness criteria | — |
| D6 Implement and validate | Implementation, often through change control | Pareto before and after |
| D7 Prevent recurrence | Preventive action, systemic and read-across actions | — |
| D8 Close and recognize | Effectiveness review and closure | Run chart against target |
That's the end of the guide. If you only take one idea from it: a root cause is a claim, and every claim needs evidence. The methods are just structured ways of finding that evidence. Go back to the method finder in Part 1 on your next investigation.
References
- U.S. FDA, Inspection Observations: Form 483 observation spreadsheets by fiscal year, Devices tab, FY2021–FY2025. www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/inspection-references/inspection-observations
- 21 CFR Part 820, Quality Management System Regulation. Electronic Code of Federal Regulations. www.ecfr.gov/current/title-21/chapter-I/subchapter-H/part-820
- U.S. FDA, Quality Management System Regulation (QMSR). www.fda.gov/medical-devices/postmarket-requirements-devices/quality-management-system-regulation-qmsr
- ISO 13485:2016, Medical devices — Quality management systems — Requirements for regulatory purposes. International Organization for Standardization. www.iso.org/standard/59752.html
- U.S. FDA, Quality Management System Regulation: Frequently Asked Questions. www.fda.gov/medical-devices/quality-management-system-regulation-qmsr/quality-management-system-regulation-frequently-asked-questions
- U.S. FDA, Compliance Program 7382.850, Inspection of Medical Device Manufacturers (effective February 2, 2026). PDF. www.fda.gov/media/80195/download
- Regulation (EU) 2017/745 on medical devices (MDR). EUR-Lex. eur-lex.europa.eu/eli/reg/2017/745/oj
- Regulation (EU) 2017/746 on in vitro diagnostic medical devices (IVDR). EUR-Lex. eur-lex.europa.eu/eli/reg/2017/746/oj
- ISO 14971:2019, Medical devices — Application of risk management to medical devices. International Organization for Standardization. www.iso.org/standard/72704.html
- ASQ, “What is Root Cause Analysis (RCA)?” www.asq.org/quality-resources/root-cause-analysis
- Juran Institute, “Pareto Principle (80/20 Rule) & Pareto Analysis Guide”. www.juran.com/blog/a-guide-to-the-pareto-principle-80-20-rule-pareto-analysis/
- ASQ, “What is a Pareto Chart?” asq.org/quality-resources/pareto
- IMDRF Adverse Event Terminology Working Group, IMDRF terminologies for categorized Adverse Event Reporting (AER), IMDRF/AE WG/N43 FINAL:2020. PDF. www.imdrf.org/docs/imdrf/final/technical/imdrf-tech-200318-ae-terminologies-n43.pdf
- Kepner-Tregoe, Problem Solving & Decision Making (the method introduced in C. H. Kepner and B. B. Tregoe, The Rational Manager, 1965). kepner-tregoe.com/training/problem-solving-decision-making/
- ASQ, “Fishbone Diagram” (cause-and-effect / Ishikawa diagram). asq.org/quality-resources/fishbone
- Toyota Motor Corporation, “Toyota Production System”. global.toyota/en/company/vision-and-philosophy/production-system/
- T. Ohno, Toyota Production System: Beyond Large-Scale Production. Productivity Press, 1988 (the fuse-and-strainer example).
- Lean Enterprise Institute, Lean Lexicon: “5 Whys”. www.lean.org/lexicon-terms/5-whys/
- EBSCO Research Starters, “Fault tree analysis (FTA)” (origins at Bell Laboratories for the Minuteman program). www.ebsco.com/research-starters/social-sciences-and-humanities/fault-tree-analysis-fta
- IEC 61025:2006, Fault tree analysis (FTA). International Electrotechnical Commission. webstore.iec.ch/publication/4311
- U.S. Nuclear Regulatory Commission, NUREG-0492, Fault Tree Handbook. www.nrc.gov/reading-rm/doc-collections/nuregs/staff/sr0492/index
- ISO/TR 24971:2020, Medical devices — Guidance on the application of ISO 14971 (Annex B, risk analysis techniques). www.iso.org/standard/74437.html
- IEC 62304:2006+AMD1:2015, Medical device software — Software life cycle processes. International Electrotechnical Commission. webstore.iec.ch/en/publication/22794
- IEC/TR 80002-1:2009, Guidance on the application of ISO 14971 to medical device software. webstore.iec.ch/en/publication/7488
- Johner Institute, “Probability of software defects: What does IEC 62304 require?” blog.johner-institute.com/iec-62304-medical-software/probability-of-software-defects/
- C. Roser, “The History of the Eight Disciplines Problem Solving (8D)”, AllAboutLean. www.allaboutlean.com/8d-history/
- ASQ, “Eight Disciplines (8D)”. asq.org/quality-resources/eight-disciplines-8d
- 21 CFR Part 803, Medical Device Reporting. Electronic Code of Federal Regulations. www.ecfr.gov/current/title-21/chapter-I/subchapter-H/part-803
Case data in Parts 2 to 7 (complaint counts, detachment rates, the ELISA case, generator probabilities and supplier data) is illustrative and does not describe any real product.