In an accredited hospital, what typically triggers a formal root cause analysis, and what does The Joint Commission expect afterward?
Choose an answer, then check it.
Health Administration · Quality and Safety
Root Cause Analysis
On this page 9 sections
In 30 seconds
Root cause analysis (RCA) A structured, retrospective investigation that works backward from a serious event to the underlying system conditions that produced it, in order to prevent recurrence. Full entry → is a structured, retrospective investigation of a serious event that asks not who erred but how the system allowed the error. Triggered by sentinel events, it reconstructs a timeline and uses tools like the 5 Whys A drill-down technique, attributed to Taiichi Ohno of the Toyota Production System, that repeatedly asks 'why?' about an answer until it reaches a process cause the team can act on. Full entry → and Ishikawa's fishbone diagram to trace latent, system-level causes. It ends in corrective actions ranked by strength, and its goal is preventing recurrence, not assigning individual blame.
Why this matters
Administrators own the systems in which care is delivered, so when a patient is seriously harmed the organization must be able to learn from the event rather than punish the nearest person. RCA is the method accreditation expects: The Joint Commission has looked for a credible root cause analysis after a Sentinel event A patient safety event, not primarily due to the patient's underlying illness, that reaches the patient and causes death, permanent harm, or severe temporary harm, signaling a process problem that could recur. Full entry → since 1997, and boards, regulators, and payers increasingly ask what actually changed afterward. Done well, RCA converts a single tragedy into durable process improvement. Done badly, it produces a binder of 'retrain and remind' actions that change nothing. Knowing which corrective actions truly hold is the difference between a safer system and a repeat event.
The college version
What RCA is and when it is triggered
Root cause analysis is a structured, retrospective method for learning from a serious event by working backward from the harm to the conditions that produced it. It did not originate in medicine; it was adapted from industrial accident investigation and is now a standard error-analysis tool in health care. In a hospital, the usual trigger is a sentinel event, which The Joint Commission defines as a patient safety event, not primarily related to the natural course of the patient's illness, that reaches the patient and results in death, permanent harm, or severe temporary harm. The word 'sentinel' signals that the event is a warning of a process problem that could recur. Since 1997 The Joint Commission has expected an accredited organization to respond to such an event with a credible analysis of its root causes and a corrective action plan; the widely cited expectation is that this analysis and plan be completed within roughly 45 business days of the event becoming known. Organizations also run RCAs voluntarily on serious near misses, because a near miss reveals the same latent weaknesses without the harm. The point is not to produce a report but to change the system before the next patient is exposed to the same hazard.
A systems method, not a blame hunt
The defining commitment of RCA is that it looks past the individual at the sharp end to the system that shaped their actions. Safety scholarship, notably James Reason's work, distinguishes active failures, the unsafe acts at the human-system interface, from latent conditions, the upstream weaknesses built into staffing, equipment, procedures, and design that lie dormant until an active error activates them. A good RCA acknowledges the active error but treats it as a starting point, not a verdict, and keeps asking what conditions made that error likely and hard to catch. This is why the RCA2 guidance explicitly warns teams to focus causal statements on system-level issues and not to assign blame to individuals, and why it excludes deliberately unsafe or criminal acts, which belong to human-resources and legal processes instead. The practical payoff is honesty: staff who expect to be scapegoated hide the information an investigation needs, while a systems focus surfaces the real chain of events. Distinguishing a direct cause, the contributing causes, and the underlying root cause keeps the team from stopping at the obvious and lets it name the conditions it can actually change.
The core tools: timelines, the 5 Whys, and the fishbone
An RCA team, usually multidisciplinary, first reconstructs what happened by gathering records and interviewing people involved, then lays the sequence out as a timeline or event flow so the group reasons from a shared picture rather than from memory. On that foundation it applies analytic tools. The 5 Whys is the simplest: starting from the problem, the team asks 'why did this happen?' and, rather than stopping at the first answer, asks 'why?' again and again until it reaches a cause it can act on. The technique is attributed to Taiichi Ohno of the Toyota Production System, the origin of Lean, and its discipline is to push past symptoms to a process cause. The Ishikawa or fishbone diagram, a cause-and-effect diagram introduced by Kaoru Ishikawa, complements it by branching: the harm is the fish's head, and the team groups possible causes along major bones, commonly people, methods, equipment, materials, measurement, and environment. Where the 5 Whys drills down a single chain, the fishbone spreads a whole team's ideas across categories so no domain is overlooked. Real events rarely have a single root cause, and using both tools together guards against the trap of naming one and quitting.
From causes to actions: the RCA2 action hierarchy
An analysis that identifies causes but produces weak fixes accomplishes little, which is why the National Patient Safety Foundation renamed the process RCA2, Root Cause Analyses and Actions, to stress that action is the point. Its central tool for the output is the Action hierarchy An RCA2 ranking of corrective actions by strength, from stronger system changes that do not rely on memory, through intermediate aids, to weaker actions like training and policy. Full entry →, adapted from the VA National Center for Patient Safety, which ranks corrective actions by how much they depend on human memory and vigilance. Stronger actions change the system so the error becomes difficult or impossible: architectural and physical changes, forcing functions and engineering controls, simplifying or removing steps, and standardizing equipment. Intermediate actions include checklists and cognitive aids, software prompts, eliminating look-alike and sound-alike items, read-backs, and reducing workload or distractions. Weaker actions rely on people trying harder: double checks, warnings and labels, a new policy or memo, and training or education. Weaker actions are not worthless, and are sometimes the only thing available immediately, but the guidance is blunt that when used alone they rarely produce sustained improvement, and it recommends at least one strong or intermediate action for every RCA. A finished action item also names who is responsible, sets a completion date, and is monitored to confirm it worked.
RCA versus FMEA: learning after versus preventing before
RCA is reactive by design: it begins after something has already gone wrong and reasons backward. Its natural counterpart is Failure mode and effects analysis (FMEA) A prospective method that maps a high-risk process and evaluates how each step could fail, how likely and detectable each failure is, and its impact, to reduce risk before any harm occurs. Full entry →, which is proactive: it begins before any harm, maps every step of a high-risk process, and asks at each step how that step could fail, how likely each failure is, how likely it is to be caught, and how bad the consequences would be, often combining those into a priority score so the team can fix the riskiest steps first. FMEA looks forward at a process that has not failed yet, such as programming an infusion pump or preparing an intravenous medication; RCA looks back at a specific event that already caused harm. A mature safety program uses both, and they reinforce each other: the latent weaknesses an RCA discovers after one event are exactly the kind of failure modes a prospective FMEA tries to catch before the first patient is harmed. Neither replaces the everyday work of quality improvement; RCA and FMEA are the focused analytic methods that feed the improvement cycle when the stakes are highest.
Eli explains
The same idea, in plain words
Explain it like I’m 10
When something goes badly wrong, the easy thing is to find one person to blame and move on. Root cause analysis does the opposite. A team sits down after a serious mistake and slowly rebuilds exactly what happened, step by step, like replaying a game to see where it went wrong. Then they keep asking 'why did that happen?' over and over, because the first answer is usually just a symptom. The trick is that they are not hunting for a bad person; they are hunting for a broken part of the system, like a confusing label, a missing checklist, or one shared computer that made shortcuts tempting. Once they find it, they pick a fix. A weak fix is 'tell everyone to be more careful,' which almost never lasts. A strong fix changes the setup itself, so the mistake becomes hard or impossible to make again, no matter how tired or busy people are.
Picture it like this
It is like figuring out why you keep missing the school bus. 'I overslept' is the first answer, but if you stop there you will oversleep again. Keep asking why: the alarm was too quiet, because it was buried under a pillow, because your phone charges across the room, because there is no charger by the bed. The strong fix is a loud alarm clock bolted to your nightstand, not a sticky note reminding you to 'try harder to wake up.'
Where the picture stops working
The bus analogy has one person and one simple chain, but a real hospital event usually has several tangled causes across many people and departments at once, and the harm can be permanent, which is why the process is formal, team-based, and far more careful than a personal habit fix.
Worked example
A hospitalized patient receives a duplicate dose of insulin. The RCA team builds a timeline and applies the 5 Whys. Why the second dose? A second nurse gave it because the first dose was not shown as given. Why not shown? The first nurse had not yet charted it in the electronic record. Why not? Documentation was batched at the end of rounds rather than done at the bedside. Why batched? The unit had a single shared workstation, so real-time charting was impractical. Why only one? No process linked device provisioning to safe medication workflow. The root cause is a system gap, not a careless nurse. A weak action would be reminding nurses to chart promptly; a strong action is barcode medication administration with bedside devices, a near-forcing function that blocks a duplicate dose regardless of when charting happens.
Key takeaway
Root cause analysis is the structured, retrospective way an organization learns from a serious event: it traces the harm past the individual to the system's latent causes and ends in corrective actions ranked by strength, favoring durable fixes over 'retrain and remind.'
Quick check
3 questions here, of 5 in this lesson’s practice set. Answers stay hidden until you check.
Why is root cause analysis described as a systems method rather than a tool for assigning blame?
Choose an answer, then check it.
A patient gets a duplicate insulin dose. Using the 5 Whys, the team finds the second dose was given because the first was not yet charted, charting was batched at a single shared workstation, and the unit lacked bedside devices. What does this best illustrate?
Choose an answer, then check it.
Study tools & related lessonsYou’ll learn to · Common mistakes · Easily confused · Key vocabulary · Related
You’ll learn to
- Define root cause analysis and identify what triggers a formal RCA in a healthcare organization.
- Explain why RCA is a systems method aimed at latent process causes rather than at assigning individual blame.
- Apply the 5 Whys to trace a hypothetical event from its immediate cause to a system cause.
- Distinguish corrective actions by strength using the RCA2 action hierarchy.
- Distinguish RCA from FMEA as a reactive versus a proactive safety method.
Common mistakes
Treating RCA as a way to identify who to discipline.
RCA is a systems method; it deliberately looks past the individual to the latent conditions, and truly blameworthy or criminal acts are handled through human-resources and legal channels, not RCA.
Stopping at the first answer to 'why.'
The first answer is usually a symptom; the 5 Whys works only if the team keeps asking until it reaches a process cause it can actually change.
Ending the RCA with 'retrain the staff' or 'remind everyone' as the fix.
Those are weaker actions that rely on memory and vigilance; RCA2 recommends at least one stronger or intermediate action, such as a forcing function or a simplified process, for every analysis.
Confusing RCA with FMEA.
RCA is retrospective, run after a specific event has caused harm; FMEA is prospective, run on a process before any harm to find failure modes in advance.
Assuming a serious event has exactly one root cause.
Complex events typically have several contributing and latent causes, which is why teams pair the 5 Whys with a fishbone diagram that spreads causes across categories.
Easily confused
Root cause analysis (RCA) vs. Failure mode and effects analysis (FMEA)
RCA is reactive and retrospective, analyzing an event that already caused harm; FMEA is proactive and prospective, mapping how a process could fail before harm occurs.
The 5 Whys vs. Ishikawa (fishbone) diagram
The 5 Whys drills down a single chain of causation; the fishbone spreads many candidate causes across categories such as people, methods, and equipment so no domain is missed.
Active failure vs. Latent condition
An active failure is the unsafe act at the sharp end; a latent condition is the upstream system weakness that made the act likely and hard to catch, and it is the RCA's real target.
Stronger action vs. Weaker action
A stronger action changes the system so the error is hard or impossible regardless of vigilance (forcing functions, physical redesign); a weaker action relies on people remembering (training, warnings, policy).
Key vocabulary
- Root cause analysis (RCA)
- A structured, retrospective investigation that works backward from a serious event to the underlying system conditions that produced it, in order to prevent recurrence.
- Sentinel event
- A patient safety event, not primarily due to the patient's underlying illness, that reaches the patient and causes death, permanent harm, or severe temporary harm, signaling a process problem that could recur.
- Latent condition
- An upstream weakness built into staffing, equipment, procedures, or design that lies dormant until an active error triggers it; the main target of an RCA.
- Active failure
- An unsafe act committed at the point where a person interacts with the system, distinguished from the latent conditions that made it likely.
- 5 Whys
- A drill-down technique, attributed to Taiichi Ohno of the Toyota Production System, that repeatedly asks 'why?' about an answer until it reaches a process cause the team can act on.
- Ishikawa (fishbone) diagram
- A cause-and-effect diagram introduced by Kaoru Ishikawa that arranges possible causes of an effect along branches by category, such as people, methods, equipment, materials, measurement, and environment.
- Action hierarchy
- An RCA2 ranking of corrective actions by strength, from stronger system changes that do not rely on memory, through intermediate aids, to weaker actions like training and policy.
- RCA2 (Root Cause Analyses and Actions)
- The National Patient Safety Foundation's updated framework that adds the word 'Actions' to emphasize that an RCA must produce durable corrective actions, not just findings.
- Failure mode and effects analysis (FMEA)
- A prospective method that maps a high-risk process and evaluates how each step could fail, how likely and detectable each failure is, and its impact, to reduce risk before any harm occurs.
Sources & references
- Root Cause Analysis (Patient Safety Primer) — Agency for Healthcare Research and Quality (AHRQ), Patient Safety Network (PSNet)
- Patient Safety Essentials Toolkit: Action Hierarchy (part of RCA2) — Institute for Healthcare Improvement (IHI)
- Patient Safety Essentials Toolkit: 5 Whys - Finding the Root Cause of a Problem — Institute for Healthcare Improvement (IHI)
- Patient Safety Essentials Toolkit: Cause and Effect Diagram — Institute for Healthcare Improvement (IHI)
- Quality Tools and Techniques (Fishbone Diagram, Pareto Chart, Process Map) — StatPearls Publishing (NCBI Bookshelf, NBK607994)
- Medical Error Prevention and Root Cause Analysis — StatPearls Publishing (NCBI Bookshelf, NBK570638)
- Application of failure mode and effects analysis (FMEA) to improve medication safety in the dispensing process - a study at a teaching hospital, Sri Lanka — BMC Public Health / PubMed Central (PMC8293514)
- DOE-NE-STD-1004-92, DOE Guideline: Root Cause Analysis Guidance Document — U.S. Department of Energy, Office of Nuclear Energy
EliExplains lessons are original prose written from the open, credible references above. See Copyright & Licensing.
Researched 2026-08-19
Educational content only. It is not medical, legal or professional advice. Found an error? Tell us.