Fishbone Diagram in Healthcare: Categories for a Hospital RCA (With a Worked Example)

A fishbone (Ishikawa) diagram sorts the possible contributing causes of a patient safety event into a small set of categories, so a root cause analysis team can brainstorm broadly before narrowing down — but the classic industrial categories (Man, Machine, Method, Material, Measurement, Mother Nature) map awkwardly onto a hospital process, and hospitals that borrow them unmodified tend to produce thin, generic bones. This guide covers the category set hospitals commonly adapt instead, how to run the diagramming session itself, and a full worked example that carries one event through all six branches to a usable causal statement.

This guide is written for hospital patient-safety officers, quality directors, risk managers, and infection preventionists who facilitate or sit on RCA teams. It assumes the team-composition and timeline-building groundwork from our companion guide on root cause analysis in healthcare — this page goes deep specifically on the fishbone technique itself, which that guide deliberately treats as a facilitation tool rather than covering in depth.

What a Fishbone Diagram Is (and Isn’t)

A fishbone diagram, also called an Ishikawa diagram or cause-and-effect diagram after its originator Kaoru Ishikawa, puts the event or problem at the head of a horizontal spine, then branches off a fixed set of category “bones” running into it. Under each category bone, the team lists specific factors that may have contributed, then keeps asking why each factor existed until the branch reaches something a corrective action could actually target. The output is a visual map of the causal landscape a team is willing to consider — not a ranked list of what actually caused the event, and not itself a causal statement.

That distinction matters more in a hospital RCA than the tool’s origin suggests. A fishbone diagram is a divergent, brainstorming step: its job is to keep the team from anchoring on the first plausible explanation by forcing it to check several categories of cause before settling on one. The convergent step — deciding which branches the timeline and interview evidence actually supports, and writing those into a defensible causal statement — is separate work, covered in the causal-factors section of our root cause analysis in healthcare guide. A fishbone diagram populated with vague, unsupported entries in every bone is not a stronger RCA than one with fewer, better-supported branches; it just produces a more crowded diagram.

Why the Classic Six Categories Don’t Fit a Hospital Process

Ishikawa’s original manufacturing categories — often shortened to “the 6 M’s” — are Man, Machine, Method, Material, Measurement, and Mother Nature (environment). They were built for a factory floor, and several of them translate poorly to a clinical process:

• “Machine” and “Material” conflate medical devices, IT systems, supplies, and pharmaceuticals into two very different categories that a hospital usually wants to investigate separately — a smart-pump programming issue and a look-alike vial packaging issue call for different people in the room.
• “Measurement” originally meant instrument calibration and inspection error on a production line. In a hospital, the analogous idea (a monitor reading incorrectly, a lab result reported wrong) is real but narrow, and the label doesn’t obviously cover it for a team unfamiliar with the manufacturing original.
• There’s no category for the patient. Comorbidities, acuity, language or communication barriers, and identification factors (two patients with similar names on the same unit) are frequently causal in a healthcare event in a way that has no equivalent on a factory floor, and forcing them into “Man” or “Environment” tends to bury them.
• Policy and procedure get flattened into “Method.” A hospital often needs to distinguish a policy that was poorly designed (an “independent double-check” requirement that never specified how independence is verified) from a procedure that was correctly designed but not followed in practice — those two failures call for different corrective actions.

A Healthcare-Adapted Category Set

There’s no single mandated replacement for the 6 M’s in healthcare — different hospitals and quality-improvement programs adapt Ishikawa’s structure differently, and some fold two of the categories below into one or add a seventh for communication specifically. The set below is a common, workable adaptation that keeps the categories a hospital RCA team actually needs separate:

• People. Staffing levels and skill mix at the time, training and competency, fatigue and workload, handoff and communication between roles. Covers frontline staff, but also anyone upstream whose action or omission fed into the event.
• Policy. The written rule itself — whether it exists, whether it’s current, and whether it’s specific enough to be followed consistently (a double-check policy that doesn’t define what “independent” means is a policy gap, not a compliance failure).
• Procedure. How the policy is actually carried out step by step, and where the as-practiced workflow diverges from the as-written one — including workarounds staff have adopted because the written procedure doesn’t fit real conditions.
• Place. The physical and organizational environment: unit layout, room adjacency, lighting and noise, interruptions, and where in the physical space a step is actually performed versus where the policy assumes it happens.
• Equipment. Devices, IT systems, and supplies — malfunction, poor usability, alarm design, and whether a known equipment problem had a defined fallback process or was just worked around silently.
• Patient. Factors specific to the patient involved: acuity, comorbidities, identification risk (similar name, same room number pattern), communication or language barriers, and anything about the patient’s presentation that made the event more likely or harder to catch.

Six categories is a starting point, not a requirement to fill every bone equally. A given event might turn out to have real, evidence-backed branches under only three or four categories — that’s a sign the team found where the actual latent conditions live, not a sign the diagram is incomplete.

Running the Diagramming Session

1. State the event precisely at the head of the diagram. Use the same neutral, specific description the team is building for the timeline — “a near-miss anticoagulant administration” rather than “a medication error,” which is too broad to organize causes against.
2. Draw the spine and label the six category branches before any brainstorming starts, so the categories anchor the discussion instead of the discussion drifting toward whichever cause someone raises first.
3. Brainwrite before discussing. Have each team member silently write possible contributing factors under each category first, then share them, rather than opening with open discussion. This is the same anchoring problem the timeline-building step in a full RCA runs into: whoever speaks first tends to set the frame for everyone after them.
4. For each factor raised, ask why it existed — the same repeated-why discipline used in a standalone five-whys analysis — until the branch reaches a system-level factor rather than stopping at a restatement of the event or at an individual’s action. “The nurse was tired” is a leaf; “the unit had been running two nurses short for eleven consecutive shifts” is a branch worth keeping.
5. Don’t let one person draw every branch. A fishbone session run by a single facilitator populating all six bones from their own judgment reproduces the same blind-spot problem a single-investigator RCA has — the same multidisciplinary composition covered in the team-building section of our root cause analysis guide applies here: pharmacy, nursing, biomedical engineering, and whichever other roles the event touched should each be populating the branches closest to their own expertise.

Worked Example: An Anticoagulant Near-Miss

This is a deliberately composite, illustrative scenario built to show how the six categories are used — it is not a report of an actual event at any specific institution.

A nurse was about to hang a therapeutic-dose heparin infusion when an independent double-check caught that the infusion bag had been prepared for a different patient with a similar last name in an adjacent room; the infusion was stopped before administration and no harm occurred. Because the event reached the point of near-administration, the patient-safety office triaged it for a full RCA rather than a lighter apparent-cause review. Mapped onto the six bones:

• People: the covering nurse was managing an additional patient assignment outside their usual unit that shift, and had not worked with either patient before.
• Policy: the hospital’s high-alert medication policy required an “independent double-check,” but didn’t specify that the second checker had to verify patient identity separately from the first checker rather than simply confirming the first checker’s read of the label.
• Procedure: bedside barcode scanning, which would have flagged the mismatch automatically, was skipped because the scanner assigned to that room had been reported non-functional three days earlier and no backup scanner or fallback verification step had been defined while the repair ticket was open.
• Place: the two patients with similar last names had been admitted to adjacent rooms, and the unit’s whiteboard and EHR patient list both displayed the names in a format that made the similarity easy to miss at a glance.
• Equipment: the broken scanner had been logged as a facilities ticket but not escalated as a patient-safety risk, so nothing in the unit’s workflow treated “scanner down” as a condition requiring a defined manual fallback.
• Patient: both patients were on anticoagulation therapy, which is precisely the situation a name-similarity error is most dangerous in, and neither the ordering system nor the unit’s admission workflow flagged the same-unit name-similarity pairing when the second patient was admitted.

No single bone explains the near-miss on its own. The causal statement the team eventually wrote — consistent with the specific, neutral, non-blame language a defensible causal statement needs — was that the event reached the point of near-administration because a scanner outage with no defined fallback verification step coincided with a name-similarity pairing the admission workflow had no mechanism to flag, and because the double-check policy didn’t specify what “independent” verification actually required. The corrective actions that followed targeted those three latent conditions directly: a mandatory manual-verification fallback whenever bedside scanning is unavailable, a name-similarity alert added to the admission workflow, and a revised double-check policy that defines independent verification as a separate identity check, not a second read of the same label. “The nurse almost gave the wrong patient’s medication” describes what happened; treating it as the root cause and stopping at re-training would have left every one of those three conditions in place for the next scanner outage.

From Bones to a Causal Statement

A completed fishbone diagram is an input to the analysis, not its conclusion. Not every branch the team wrote down during brainstorming survives contact with the evidence gathered while reconstructing the timeline — some will turn out to be plausible but unsupported by the record review and interviews, and should be dropped rather than carried into the final report because they were on the diagram. The branches that do hold up get written into the same kind of causal statement described in our root cause analysis in healthcare guide: specific rather than vague, stated as a cause-and-effect relationship rather than a description of what happened, and traced past any individual’s action to the system-level factor that made the action likely. From there, grading the strength of each proposed corrective action — rather than defaulting to retraining or a reminder memo — is what our RCA2 action hierarchy guide covers in detail.

Common Mistakes with a Healthcare Fishbone Diagram

• Filling every bone to make the diagram look thorough. A branch with no evidentiary support behind it is noise the final report has to sort back out later; it’s better to leave a category sparse than to pad it.
• Vague, non-actionable entries. “Communication breakdown” and “staff error” describe a symptom, not a cause a corrective action can target — keep pushing the why question until the entry names something specific enough to fix.
• Treating the diagram as the whole RCA. A fishbone session is one facilitation step inside a larger process that still needs an accurate timeline, a multidisciplinary team, and a documented causal chain — it doesn’t replace any of those.
• Building it before the timeline is settled. A team that brainstorms causes before agreeing on what actually happened tends to anchor the diagram around whichever narrative was already forming, rather than around the reconstructed sequence of events.
• One person drawing the whole diagram alone. Reproduces the same blind-spot risk a single-investigator RCA has — see the facilitation guidance above.

Frequently Asked Questions

What is a fishbone diagram used for in healthcare?

A fishbone (Ishikawa) diagram is a brainstorming tool used during a root cause analysis to sort the possible contributing causes of a patient safety event into a fixed set of categories, so the team considers several categories of cause — not just the first plausible one — before narrowing down to a supported causal statement.

What are the healthcare-adapted fishbone categories?

There’s no single mandated set, but hospitals commonly adapt Ishikawa’s original six manufacturing categories (Man, Machine, Method, Material, Measurement, Mother Nature) to People, Policy, Procedure, Place, Equipment, and Patient — a set that separates policy design from procedural adherence and adds an explicit patient-factors category the manufacturing original has no equivalent for.

Is a fishbone diagram required for a Joint Commission root cause analysis?

No specific diagramming technique is mandated. A fishbone diagram and a five-whys analysis are both commonly used facilitation tools for organizing a team’s thinking during an RCA; what’s expected is a comprehensive systematic analysis and corrective action plan, not a specific diagram format.

How is a fishbone diagram different from a five-whys analysis?

A five-whys analysis follows one causal chain by repeatedly asking why, which works well when a team already has a strong hypothesis about where to start. A fishbone diagram is broader by design — it forces the team to check multiple categories in parallel before committing to one chain, which helps when the starting cause isn’t obvious. Many teams use both: fishbone categories to surface candidate causes, then a five-whys push down whichever branches the evidence supports.

Can a fishbone diagram be used for a near-miss, not just a sentinel event?

Yes. The technique doesn’t depend on whether harm reached the patient — a near-miss investigated with the same rigor as a sentinel event often surfaces the same latent conditions before they cause an actual injury, which is exactly the value of investigating near misses rather than waiting for harm to occur.