thebench.bio #1 Ecosystem for the Bio-Tech Industry
All CAPA questions

Question 20 of 20 Intermediate Practical

When would you use fault tree analysis instead of a fishbone diagram in an investigation?

Short answer

Use a fishbone diagram to brainstorm possible causes by category. Use fault tree analysis when you need the logic of how causes combine, with AND and OR gates, for example when a failure needs two things to go wrong together, or when you must show an action closes every path to the failure.

Why

ICH Q9(R1) lists cause and effect diagrams, also called Ishikawa or fishbone diagrams, among basic facilitation methods. They organize ideas under headings such as people, methods, materials, machines, measurement and environment, which is ideal early in an investigation when the team needs breadth. They do not show how causes relate.

Fault tree analysis starts from the failure at the top and works down through the events that could produce it, joined by logical operators. Q9(R1) describes it as evaluating failures one at a time while combining multiple causes through causal chains, and says it can establish the pathway to root cause, investigate complaints or deviations, and help check that improvements resolve the issue without creating another. The AND and OR gates are the point.

If contamination of a vial requires both a breach in a filter AND a failed integrity test, the controls on each branch matter differently than if either one alone (OR) could cause it. An action on one input of an AND gate breaks that path, while an OR gate needs every branch covered. Fault trees take longer and rely on expert process understanding, so a wrong assumption in the tree propagates to the conclusion.

They suit high-severity or complex failures, while a fishbone plus evidence is enough for most routine deviations.

How to work it through

  1. Define the top event precisely, such as a nonsterile unit released.
  2. Break it into the immediate events that could cause it and choose AND or OR for how they combine.
  3. Continue down each branch until you reach basic events you can test or control.
  4. Mark each basic event as confirmed, excluded or untested using the evidence.
  5. Check which paths the proposed actions close and which remain open.
  6. Review the tree with process experts to challenge its assumptions.

An example

A tablet batch fails dissolution. A fishbone lists twelve candidate causes. The team builds a fault tree: failure occurs if granule hardness is high OR lubricant is overblended.

High hardness requires excess binder AND long granulation time. Records show binder was correct, which closes that AND path. Blender logs show 14 minutes of lubrication against a 3 minute target because a timer was reset.

The confirmed branch is overblending, and the action adds a blender interlock while the tree shows the hardness branch is already controlled.

Where the answer stops holding

A fault tree is only as good as the team's process knowledge, and missing branches stay invisible. Building trees for every deviation wastes effort. Quantifying probabilities on the tree needs data that many sites do not have, so most use it qualitatively.

A strong answer covers

  • Fishbone for breadth and brainstorming
  • Fault tree for logical combination of causes
  • AND versus OR gates change which actions suffice
  • Checks that actions close every path
  • Reserve for complex or high-severity failures

Common mistakes

  • Treating a fishbone diagram as proof of root cause.
  • Drawing a fault tree without AND and OR logic, which makes it just a list.
  • Building trees from assumptions without checking each branch against evidence.