Root Cause Analysis with Gemba-RCA

This guide introduces root cause analysis (RCA) — what it is, why it matters, and how to do it properly — and then walks you through using Gemba-RCA v1.4 to work through a structured investigation from problem statement to validated root cause.

Root cause analysis is one of the most misused tools in healthcare improvement. Used well, it is the discipline that separates problems from symptoms, evidence from opinion, and lasting change from firefighting. Used poorly, it produces blame, false certainty, and countermeasures that address the wrong thing. The difference lies not in the tools themselves — Fishbone diagrams, 5 Whys chains, Pareto charts — but in the rigour with which they are applied.

Who is this guide for?

Anyone investigating a recurring problem in a healthcare setting — ward managers, laboratory leads, service improvement practitioners, biomedical scientists, clinical staff, and quality teams. No prior lean or RCA experience is required. If you have a problem you have tried to fix before and it keeps coming back, this guide is for you.

What you will learn

• →Why treating symptoms does not solve problems
• →How to write a problem statement that focuses the investigation
• →How to use a Fishbone diagram to map possible causes across the 6M categories
• →How to use the 5 Whys to drill from possible causes to root causes with evidence
• →How to validate a root cause using the elimination test
• →How to use Pareto analysis to prioritise the vital few causes
• →How to export your findings to Gemba-A3 to complete the problem-solving loop
• →How to use the AI Lean Sensei coaching export for guided reflection

The problem with fixing symptoms

Most healthcare improvement activity targets symptoms rather than root causes — and this is why the same problems recur. A department spends hours tracking down a delayed blood result, contacts the lab, chases the report, and eventually gets the answer. The patient pathway is patched for today. But tomorrow the same delay happens. The process of chasing and patching is itself a form of waste, repeated endlessly because the underlying cause — perhaps a poorly understood handoff point, or a capacity mismatch on Monday mornings — has never been identified and addressed.

Lean thinking describes this as working in the problem rather than on the problem. Root cause analysis is the discipline of stepping back, gathering evidence, and identifying the actual cause rather than the most visible symptom. The goal is a countermeasure that, when implemented, makes the problem go away — not just for this instance, but permanently.

Symptoms vs causes

A symptom is the observable effect: "TAT is too long." A cause is a contributing factor: "Samples arrive at an irregular rate, creating peaks the analyser queue cannot absorb." A root cause is the underlying system condition that, if removed, eliminates the problem: "There is no levelling mechanism between phlebotomy dispatch times and laboratory receipt."

The difficulty is that symptoms present themselves loudly and urgently — they are what staff experience every day. Causes are quieter and require investigation. Root causes are often structural, systemic, and not visible at all without deliberate enquiry.

When to use RCA

RCA is most valuable for problems that are recurring, complex, or costly enough to justify structured investigation. It is appropriate when:

• →The same problem has been "fixed" before without lasting effect
• →The cause is genuinely unknown and multiple hypotheses exist
• →Multiple contributing factors are suspected and need to be organised and prioritised
• →The problem is being escalated through an A3 and root cause evidence is required
• →A significant clinical event or near miss requires structured investigation

When to pause and map first

If you cannot describe where in the process the problem occurs, complete a value stream map with Gemba-VSM first. A VSM will show you the current state of the process, identify where delays and defects cluster, and give you the data to write a sharp problem statement. Starting an RCA with a vague problem statement — "referral process is slow" — produces a vague Fishbone and inconclusive Whys chains. Starting with "post-procedure referral to radiology has a median wait of 4.8 days against a standard of 24 hours, occurring at the handoff between Ward 7 and the radiology booking team" produces a focused, productive investigation.

Gemba-RCA combines three complementary analysis tools that work in sequence. Each answers a different question and builds on the output of the previous one.

The Fishbone diagram (Ishikawa diagram)

The Fishbone — also called the Ishikawa diagram or cause-and-effect diagram after its creator Kaoru Ishikawa — is a structured brainstorming tool. The problem statement sits at the "head" of the fish on the right. The "bones" are categories of possible cause that fan out to the left. Within each category, the team lists specific causes they observe or hypothesise.

The Fishbone is a divergent tool. Its purpose is to cast the net wide — to surface every plausible contributing factor before narrowing down. It prevents the most common RCA mistake, which is investigating only the most obvious cause and missing the actual root. Done well at the gemba, with input from the people who do the work, the Fishbone will generate causes that were invisible from a meeting room.

Gemba-RCA uses the 6M category framework (People, Equipment, Method, Materials, Measurement, Environment — see Appendix A for detailed descriptions). All category labels can be renamed to better fit your context.

The 5 Whys

The 5 Whys is a drilling technique that turns a cause into a root cause by repeatedly asking "Why does this happen?" until the underlying system condition is reached. The "5" is a guideline, not a rule — some chains need three iterations, some need seven. The question to stop asking Why is not "have I asked five times?" but "if I eliminate this cause, does the problem go away?"

Gemba-RCA allows you to select up to three causes from your Fishbone and investigate each with its own Why chain. Each step in the chain records both the answer and the evidence that supports it. This is the critical discipline: every Why answer must be verifiable. If you cannot supply evidence from the gemba, you are hypothesising rather than investigating.

Pareto analysis

The Pareto chart helps you decide which causes to address first. Based on the Pareto principle — roughly 80% of effects come from 20% of causes — the chart orders causes by frequency of occurrence, making it easy to identify the "vital few" that are responsible for the majority of the problem.

In practice, this means counting how many incidents or occurrences can be attributed to each cause. The causes with the highest frequency are the ones whose resolution will have the greatest impact. Pareto analysis is most powerful when you have real observation data from the gemba rather than estimates from a meeting room.

Installing Gemba-RCA

Gemba-RCA is a single HTML file. There is nothing to install in the traditional sense — open it in a browser and it runs. You can add it to your home screen like an app on any phone or tablet.

Once opened, Gemba-RCA works fully offline. All data is stored locally on your device. You do not need a login, a subscription, or any IT approval to use it — though you may wish to brief your information governance lead if you intend to deploy it widely across a team (see the IG section below).

Creating a new RCA session

Tap + New RCA on the home screen. The new project modal asks for:

• 1
  Project / session name — give it a meaningful name that identifies the problem and work area, e.g. Delayed TAT investigation — Haematology. This appears in your project list and on exports.
• 2
  Work area / department — where the problem is occurring.
• 3
  Author and organisation — your name and Trust, for export and sharing.
• 4
  Date — defaults to today; adjust if recording a session from a previous date.
• 5
  Problem statement entry route — choose Standalone to type the problem here, or Import from A3 to load a problem statement from a Gemba-A3 JSON export (see below).

Writing a good problem statement

The problem statement is the foundation of the entire RCA. A weak problem statement produces a sprawling Fishbone that investigates everything and concludes nothing. A sharp problem statement focuses the team on a specific, measurable gap between current and expected performance.

A good problem statement answers four questions: What is happening? Where is it happening? How often / how much? What is the expected standard? For example: "Post-procedure blood cultures are not being dispatched to the laboratory within one hour of collection (standard). On Ward 7, 63% of cultures in the last 4 weeks arrived after 2 hours, with some exceeding 6 hours."

Importing a problem statement from Gemba-A3

If you are running a formal A3 improvement project in Gemba-A3, you can pre-populate the problem statement in Gemba-RCA by importing the A3 JSON file. The RCA tool reads the Section 1 problem statement from the A3 export and loads it automatically. This keeps the problem definition consistent across tools and reduces re-entry errors.

To use this: in the New RCA modal, select Import from A3, tap Select Gemba-A3 JSON file, and choose the exported A3 file from your device. The problem statement will populate automatically.

Information governance

Gemba-RCA has no fields for patient-identifiable data. It focuses entirely on process — causes, evidence, categories, and why chains. All data is stored locally in your browser's localStorage until you explicitly export it. There is no backend, no cloud storage, no user accounts, and no tracking. This design means Gemba-RCA can typically be approved for NHS use without a data processor agreement, as no data ever leaves the device without the user's explicit action.

What the Fishbone tab shows

When you open an RCA session, the Fishbone tab is shown first. At the top sits the problem banner — your problem statement, always visible as a reminder of what you are investigating. Beneath it is the fishbone itself: an SVG diagram with six bones arrayed either side of a central spine, ending at the problem statement head on the right. Below the diagram are six category cards — one for each bone — where you add, manage, and select causes.

The six categories

The default categories are the healthcare-adapted 6M framework. Three sit on the top bones (People, Equipment, Method) and three on the bottom (Materials, Measurement, Environment). See Appendix A for detailed descriptions of each category and healthcare examples. All category labels can be renamed by tapping the pencil icon on any category card — for example, renaming "Equipment" to "Analysers" if you are investigating a laboratory process.

Adding causes

Tap the + Add cause button in any category card. Type a brief, specific cause description and confirm. The cause appears in the category card list and on the corresponding bone in the fishbone SVG diagram. Keep cause descriptions concise but specific — "samples arriving in batches" is more useful than "timing issues".

The best way to populate the Fishbone is at the gemba, with the people who do the work. Run a brief facilitated session: project the Fishbone on a screen or use your phone, and work through each category systematically. Ask the team: "What in this category might cause the problem?" Do not edit or dismiss causes at this stage — this is divergent thinking. The purpose is to get everything on the diagram before you start narrowing down.

Selecting causes for investigation

Once you have populated the Fishbone with candidate causes, the next step is to select the most significant ones for deeper investigation with the 5 Whys. Tap any cause text in a category card to toggle its selection — selected causes highlight in the card and are indicated on the SVG diagram. You can select up to three causes.

The selection counter in the Fishbone toolbar shows how many causes you have selected ("0 of 3 selected"). Choose the causes that, in the team's judgement, are most likely to be significant contributors. You do not need evidence to select causes — you will gather evidence in the 5 Whys chains. But the selection should be based on what the team actually observes, not on opinion about what the problem "should" be.

Renaming categories

Healthcare processes do not always fit neatly into the default 6M labels. If a category name is unhelpful for your context, tap the pencil icon next to any category header to rename it. For example, a community nursing team might rename "Materials" to "Consumables" and "Equipment" to "IT Systems" to better reflect their work. The structure of the Fishbone remains unchanged — only the label changes.

What the 5 Whys tab shows

Once you have selected causes in the Fishbone tab, switch to the 5 Whys tab. Each selected cause appears as a tab — you can work through each chain independently. If no causes have been selected, the tab shows an empty state with instructions to return to the Fishbone and select causes first.

How the 5 Whys works

The 5 Whys is a drilling technique. You start with a cause — something that contributes to the problem — and ask "Why does this happen?" The answer becomes the next cause. You ask "Why does that happen?" again. You keep asking until you reach a condition that is truly systemic: a gap in a standard, a missing process, a structural constraint, or a design flaw in the system. That is the root cause.

Here is an example from a histopathology laboratory context:

Note that this root cause is not "we need more staff." It is a systemic gap: no mechanism exists to match staffing to demand variation. A countermeasure that addresses this root cause — for example, a weekly demand review that adjusts the following week's cover — will solve the problem. Adding a single headcount without addressing the underlying planning gap will not.

Adding Why steps

In each chain panel, tap + Add Why step to add the next level. Each step has two fields:

How deep should you go?

Stop when you reach a cause that satisfies the elimination test: "If we address or remove this cause, does the problem disappear?" If yes, you have found the root cause. If the answer is "it would help but not eliminate it," go deeper or investigate whether there are additional contributing root causes in other Why chains.

Common errors of depth: stopping too soon (at a symptom rather than a root cause — "the team didn't follow the procedure" is rarely a root cause; why didn't they?); and going too deep (beyond the boundary of what the team can influence — "the NHS is underfunded" may be true but is not actionable at ward level).

Checking the logic — Therefore Validation

Once you have built a Why chain, you can check the logical coherence of your reasoning using the ▶ Check logic button in the top-right corner of the chain panel. This switches the panel into Therefore view, which reads your chain bottom-up: deepest cause, therefore the next level, therefore the next, all the way back to the original cause.

This is the "Therefore test" — the complementary direction to the 5 Whys. The 5 Whys asks "Why?" downward (from effect to cause). The Therefore test reads upward (from cause to effect): If this root cause exists, therefore this condition occurs, therefore this higher-level cause occurs, therefore the original problem occurs. If the chain reads logically in this direction, it holds. If a step feels disconnected when read upward, there is a logic gap — often indicating a missing step or insufficient evidence at that level.

In Therefore view, each consecutive pair is displayed with two flag buttons. Tap 👍 Holds if the logical connection is sound. Tap 👎 Gap if the step does not follow cleanly. Flagged gaps are shown as amber ⚠ warnings in the edit view beside the affected Why step, so you can return and strengthen the reasoning or evidence at that level.

Tap ◀ Edit view to return to the standard editing mode. The Therefore view does not change your answers or evidence — it is purely an analytical layer. The Therefore check and the elimination test are distinct and complementary: the elimination test checks whether the deepest cause is truly causal; the Therefore check tests whether the logical path between each level is coherent.

The elimination test

At the bottom of each Why chain is a root cause validation section. This applies the elimination test — sometimes called the "if/then" test — to assess whether the deepest cause you have reached is genuinely causal rather than correlational.

The question is: "If we address or remove this cause, does the problem disappear?"

Tap Yes — Validated if removing this cause would eliminate the problem. The chain is marked Root Cause Validated (green badge). Tap No — revisit if the problem would still occur even if you fixed this cause. The chain is marked Not Validated — revisit Why chain (red badge). If marked not validated, you have either stopped the Why chain too early — go deeper — or the cause you selected from the Fishbone is not a true contributor to the problem.

Multiple root causes

Most real healthcare problems have more than one root cause. You may run three Why chains and validate all three — meaning the problem is produced by three concurrent conditions, each of which must be addressed. This is normal and useful. It explains why single-intervention fixes often fail: they address one root cause but leave the others intact.

Only validated root causes are included when you export to Gemba-A3. This prevents unresolved chains from being imported as though they are conclusions.

What to do when a chain does not validate

A chain that does not validate on the elimination test should be revisited. Ask: have you gone deep enough? Is the cause in the Fishbone actually a contributing factor to this specific problem, or is it a general issue that exists independently? Sometimes a thorough Fishbone generates causes that are real problems in their own right but are not causally related to the problem being investigated. This is useful information — capture it separately — but do not let it dilute the current RCA.

The Therefore logic check

The elimination test asks whether the deepest cause is genuinely causal. The Therefore logic check — accessed via the ▶ Check logic button — asks a different but related question: is the logical path between each level of the chain coherent? These are two distinct validation steps, and both should be applied before closing an investigation.

A chain can pass the elimination test while still containing reasoning leaps between individual Why steps. Conversely, a chain can have coherent step-to-step logic but an insufficiently deep final cause. Logic gaps flagged in the Therefore view are shown as amber ⚠ warnings in the edit view — a prompt to revisit the reasoning or evidence at that specific step.

See Section 6 for a full description of how to use the Therefore Validation feature.

The vital few

Pareto analysis — named after the Italian economist Vilfredo Pareto — applies the observation that a minority of causes typically produce the majority of effects. In process improvement, this is often expressed as "80% of problems come from 20% of causes." The ratios are not precise, but the principle is robust: not all causes contribute equally, and prioritising the most frequent ones will deliver the greatest improvement for a given effort.

The Pareto chart in Gemba-RCA is found in the Pareto & Export tab. It shows causes ranked from highest to lowest frequency, making the vital few immediately visible. Use it after completing your Fishbone and 5 Whys to decide which validated root causes to address in your countermeasures.

Using the Pareto chart

Tap + Add cause in the Pareto section to enter each candidate cause and the number of incidents attributable to it. This data should come from actual observation — incident logs, process observations, defect tallies, or data extracted from your LIMS or EPR system. Estimated frequencies are acceptable when hard data is not available, but note the uncertainty.

The SVG bar chart updates automatically as you enter data, ordering causes by frequency. The pattern to look for is a steep drop-off after the first two or three bars — those are your vital few. Addressing the causes to the left of this "elbow" in the chart will produce the greatest impact.

Pareto and prioritisation

The Pareto chart does not make decisions for you — it informs them. A cause that appears infrequently may still be the most important one to address if it produces severe consequences when it occurs (for example, a rare but high-risk patient safety event). Frequency is one dimension of prioritisation. The others include severity of impact, feasibility of countermeasures, and whether the root cause is within the team's span of control.

Completing the problem-solving loop

Root cause analysis is the investigation phase of a broader improvement cycle. Finding a root cause is not the end — it is the transition point to designing and testing countermeasures, checking whether they work, and standardising the ones that do. This complete cycle is what an A3 captures. Gemba-RCA and Gemba-A3 are designed to connect directly, so findings from an RCA can flow into an A3 without re-entry.

Exporting to Gemba-A3

In the Pareto & Export tab, tap Export for A3. This packages your validated root causes together with the Fishbone SVG diagram into a JSON file formatted for Gemba-A3 import. Only validated Why chains are included — unvalidated chains are excluded automatically.

To import in Gemba-A3: open your A3 project, go to Section 5 (Root Cause Analysis), and use the Import from Gemba-RCA option. The root causes and Fishbone diagram will populate the A3 section automatically, with source attribution so reviewers can see the data came from a structured RCA rather than unstructured brainstorming.

JSON backup export

The Download JSON option exports your complete RCA data — all fishbone causes, all Why chains, all Pareto data — in a format you can re-import to Gemba-RCA on any device. Use this to back up your work after every session, share an RCA with colleagues at other sites, or hand over an investigation to another team member.

Importing from Gemba-A3

If you have an active A3 project and want to start an RCA from it, the Import A3 JSON option reads the problem statement from Section 1 of the A3 and loads it into the RCA problem banner. This ensures the problem definition is consistent between tools.

Print / Save as PDF

The Print / Save as PDF button generates a formatted, governance-ready summary of your RCA directly from the browser. The print view includes your problem statement, every Why chain with its steps and evidence, logic gap flags from the Therefore check, root cause validation status, and an evidence completeness note. Use your browser's print dialog to save as a PDF for inclusion in audit documentation, clinical governance submissions, or A3 appendices. No data leaves the device — the PDF is generated entirely in-browser from your local data.

Evidence completeness indicator

Above the export options, a badge shows how many of your Why steps have evidence recorded. A green badge (✓ Evidence complete — all N steps have evidence recorded) indicates every step has supporting evidence. An amber badge (⚠ Evidence gaps — N of M steps have evidence recorded) indicates steps that still lack evidence and should be revisited before closing the investigation. This is an informational indicator, not a gate — you can export at any time — but it provides a clear signal about the rigour of the investigation for governance purposes.

What it does

The AI Lean Sensei coaching export, found in the Pareto & Export tab, generates a structured coaching prompt containing your full RCA — problem statement, Fishbone causes, Why chains, evidence, and validation status. You can paste this prompt into any AI assistant (Claude, Microsoft Copilot, Gemini, or others) to receive structured coaching on your analysis.

The coaching is deliberately Socratic. A good AI coaching prompt will not tell you the answer — it will ask questions that help you see gaps in your own thinking. Typical questions include: Are there Fishbone categories with suspiciously few causes — what might have been missed? Do the Why chains go deep enough or stop at symptoms? Is the evidence at each step sufficient, or are some steps still hypotheses? Does the elimination test genuinely apply?

What it does not do

The AI Lean Sensei is not a substitute for gemba observation. No AI assistant can tell you whether your evidence is accurate, whether the process you have described reflects what actually happens, or whether the root causes you have identified will hold up when tested. These questions can only be answered at the gemba, with the people who do the work.

Use the AI coaching as a reflective practice tool — a way to stress-test your thinking before you commit to countermeasures — not as a source of root cause conclusions.

These are the patterns that produce ineffective RCAs — investigations that consume time, generate plausible-sounding conclusions, and fail to produce lasting improvement.

The 6M framework (sometimes called 6M, 5M+E, or the Ishikawa categories) organises possible causes into six groups that together cover the main domains of any process. Healthcare adaptations of the original manufacturing categories are used throughout Gemba-RCA.

Gemba-RCA sits at the investigation stage of the lean improvement cycle. Understanding where it fits helps you get the most from each tool and know when to move between them.

The tools are designed to be used discretely — you do not need all of them for every improvement project. For a focused, well-defined problem where the process is already understood, starting directly with Gemba-RCA is entirely appropriate. The inter-tool data exchange (VSM → RCA → A3 → SPC) is available when you need it, not mandatory when you do not.

All data transfers between tools are manual and user-controlled — you export a JSON file from one tool and import it into another. No data moves automatically between tools. This design is deliberate: it keeps each tool operationally independent, supports NHS information governance requirements, and means a connection failure in one tool does not affect the others.