Root cause analysis for deviations and CAPA that holds up at audit
When to use 5 whys, a fishbone diagram, a fault tree or a timeline, how to get past "human error", and how to write a root cause statement an inspector will accept.
The deviation is contained, the batch is on hold, and the investigation field on the form is still blank. Someone has to decide why it happened, and whatever goes in that field will drive the CAPA, the batch disposition and, sooner or later, an inspector's opinion of your quality system. This article gives you a practical way to choose a root cause analysis method for the problem in front of you, a set of questions that get an investigation past "human error", a format for the root cause statement, and a short worked example from a fictional packaging line.
What regulators expect from root cause analysis in GMP
The EU GMP Guide is specific about this. Chapter 1 of EudraLex Volume 4, paragraph 1.4(xiv), says that an appropriate level of root cause analysis should be applied during the investigation of deviations, suspected product defects and other problems, and that the level can be set using quality risk management principles. Where the true root cause cannot be determined, you should identify and address the most likely root cause. And where human error is suspected or identified as the cause, that conclusion should be justified, having taken care that process, procedural or system-based errors have not been overlooked. Paragraph 1.8(vii) adds that significant deviations are investigated with the objective of determining the root cause, with appropriate corrective and preventive action implemented.
Medical device manufacturers meet the same idea in ISO 13485:2016 clause 8.5.2, where determining the causes of nonconformities is a required step of corrective action.
Two phrases in 1.4(xiv) deserve attention. "Appropriate level" lets you scale the effort: a mislabelled sample tube does not need the investigation a sterility failure gets. "Most likely root cause" means an inconclusive investigation is acceptable when you show the work, rank the candidate causes and act on the most probable. Inspectors object to investigations that stopped early, which is a different thing.
The MHRA inspectorate's blog post on investigations in the GMDP environment lists the failures inspectors keep finding, including root causes based on assumption rather than evidence and root cause analysis pushed into a CAPA so the deviation can close on time. It also states that human error should only be cited as the root cause once system and process variables have been ruled out.
Start every investigation with a timeline
Before choosing any analytical tool, write down what happened in order. The timeline is the least glamorous method and the one most often skipped. List each event with a time and a source: the batch record entry, the equipment audit trail, the alarm log, the shift handover note, the badge reader, the interview. Mark where a source is missing or where two sources disagree.
It separates observed facts from reconstruction, so you can see which parts of the story rest on memory. It exposes timing that matters: a restart ten minutes after a shift change, a calibration that expired the day before, a label roll changed mid-batch. And it gives every later tool something solid to work from. If your 5 whys contradicts your timeline, the 5 whys is wrong. Keep the timeline in the investigation record.
Choosing a root cause analysis method: 5 whys, fishbone or fault tree
No single method suits every deviation. Pick by the shape of the problem.
| Method | Use it when | Watch out for |
|---|---|---|
| Timeline | Always, and especially when several people, shifts or systems were involved | Filling gaps from memory without saying so |
| 5 whys | One failure with a fairly linear chain of causes | Following one path and missing parallel causes; stopping where the team's knowledge stops |
| Fishbone (Ishikawa) | Several plausible causes and no obvious front runner | Treating the diagram as the answer instead of a list of hypotheses to test |
| Fault tree | Complex failures where causes combine, such as device failures and recurring complaints | Effort; it needs people who understand the process in depth |
5 whys
The 5 whys suits a contained, single-thread problem such as a missed line clearance step. Keep asking why until you reach something the organisation controls and can change. Five is a convention; some chains end at three, some need seven.
Its weakness is that it produces one chain, and real failures often have two or three causes acting together. Guard against that by requiring evidence for every answer (a record, an observation, a test result) and by asking at each level whether anything else could also explain the step. If the answer is yes, you need a fishbone or a fault tree.
Fishbone diagram for quality investigations
The fishbone diagram, or Ishikawa diagram, is a brainstorming structure. The effect goes at the head; the bones are categories of cause. Most GMP teams use some version of the 6Ms: people, methods, machines, materials, measurement and environment. Its value is breadth: it makes the team consider materials and measurement when everyone is already convinced the operator made a mistake.
The output is a list of candidates, each of which must be confirmed or eliminated with evidence, and the record should show how. A fishbone with twenty sticky notes and no follow-up tests only tells an inspector that the team brainstormed.
Fault tree analysis
A fault tree starts from the failure at the top and works down through the combinations of events that could produce it, joined by AND and OR logic. ICH Q9(R1), Annex I.4, describes fault tree analysis and notes that it can be used to investigate complaints or deviations to fully understand their root cause, and to check that the intended improvement will resolve the issue without creating a different one. The same annex lists cause and effect (Ishikawa) diagrams among the basic facilitation methods.
Use a fault tree when a single cause cannot explain the event, such as a device that fails only when a particular component lot meets a particular sterilisation load. The AND gates show which combination of conditions has to be broken.
Getting past "human error" in a deviation investigation
Human error is a description of what happened at the last step. It is almost never the reason it was able to happen. When an investigation lands on an operator, keep asking questions about the system around that person:
- Was the procedure clear, current and available at the point of use, and does it match how the task is really done?
- Was the person trained on this revision, and did the training include the step that went wrong?
- Did the design of the task make the error easy: similar-looking labels, manual transcription, a calculation done by hand, two screens that disagree?
- Was there a check that should have caught it, and why did it not?
- What were the conditions: staffing, time pressure, interruptions, shift length, a change introduced that week?
- Has the same or a similar error happened before, elsewhere on site or with other people?
That last question matters most. If several people have made the same slip, the cause is in the process. If one person made it once, under conditions nobody else faced, a people-focused action may be justified, and the record should show why. Retraining on its own is rarely an effective CAPA, and an effectiveness check usually exposes it; see how to check CAPA effectiveness.
It also helps to name the type of error. A slip or lapse (the wrong action while intending the right one, or a forgotten step) responds to design changes such as interlocks, prompts and second checks. A mistake (the intention itself was wrong) points at training, procedures or the information available. A deliberate departure from procedure points at culture, supervision or a procedure that cannot be followed as written.
How to write the root cause statement
The root cause statement is the sentence an inspector reads first and the one the CAPA has to answer. A useful structure is: the event, the mechanism that produced it, and the system condition that allowed it, followed by the evidence.
Write it so that it is specific to this event, names something within your control, and leads directly to an action. "Operator error during set-up" fails all three tests. "The expiry date was entered incorrectly because the procedure requires the operator to calculate it by hand and type it as free text, with no verification against an approved value before printing" passes them. If a CAPA owner reading the statement cannot tell what to change, the statement is not finished.
Separate the root cause from contributing factors, which made the event more likely or harder to detect (a new starter on shift, a poorly lit inspection bench) but whose removal alone would not have prevented it. Record them and keep them out of the root cause sentence. For where this sits in the full report, see how to write a deviation report.
Worked example: an expiry date printed wrong
This example is fictional.
During routine packaging of a tablet product on Line 3, QA's end-of-batch check finds that cartons from the first two hours carry an expiry date one year later than the approved date. The line is stopped and the affected cartons are quarantined.
The timeline shows the overprinter set up at 06:10. The batch record states the manufacturing date and a 24-month shelf life; the operator calculated the expiry date and typed it in. The second-person check at 06:25 confirmed the print was legible and correctly positioned, signed against a checklist step headed "Coding verified". The error was found at 08:30.
The 5 whys: the cartons carried the wrong date because the wrong date was entered. It was entered wrongly because the operator added 36 months instead of 24, having packed a 36-month product on the same line the day before. That was possible because the procedure requires a manual calculation and free-text entry. It was not caught because the "Coding verified" step does not say what to verify against, and in practice checkers confirmed print quality only.
A fishbone exercise ruled out the printer (its audit trail showed the value as typed), the carton stock and the batch record. Deviation records showed two earlier coding errors on other lines in the past year, by different operators.
Root cause statement: the incorrect expiry date was printed because the coding procedure requires operators to calculate the expiry date and enter it as free text, and the second-person check does not specify verification of the printed date against the approved value in the batch record. Evidence: printer audit trail, batch record, checklist wording, two prior similar deviations. Contributing factor: changeover from a product with a different shelf life the previous day.
The CAPA follows directly: print the expiry date into the batch record so nobody calculates it, change the checklist to require a character-by-character comparison against that value, and look at whether the printer can receive the value electronically.
The takeaway
Build the timeline first, choose the tool by the shape of the problem, test every candidate cause against evidence, and treat "human error" as the start of a question. Then write a root cause statement that a CAPA owner could act on without asking anyone what it means. For the wider process around the investigation, see the deviation management guide.
If you want investigations, root causes and their linked actions recorded together with an append-only audit trail, see how InnoQualis handles deviation management.
