CAPA Root Cause Analysis: 5 Whys, Fishbone, and Evidence Testing
A practical pharmaceutical guide to defining problems, using 5 Whys and Fishbone diagrams without oversimplification, testing competing hypotheses, managing bias and uncertainty, documenting defensible causes, and linking evidence-based conclusions to effective CAPA.
What is CAPA root cause analysis?
CAPA root cause analysis is a structured, evidence-based investigation used to explain why a pharmaceutical quality problem occurred, why existing controls failed to prevent or detect it, and which controllable causes should be addressed. The 5 Whys and Fishbone diagram generate and organize hypotheses; records, data, experiments, chronology, comparison, and contradiction testing determine which conclusions are supportable.
From event description to causal understanding
Purpose of root cause analysis in pharmaceutical CAPA
Root cause analysis, or RCA, should produce a causal explanation strong enough to support product-impact decisions and lasting action. Its purpose is not to create a convincing story, assign blame, or complete a form. It should reveal how technical, procedural, human, environmental, data, and organizational conditions combined to create the event.
Explain occurrence
Determine the mechanism and conditions that allowed the defect, deviation, failure, complaint, OOS result, audit observation, or adverse trend to occur.
Explain control failure
Identify why prevention, monitoring, alarms, review, segregation, sampling, testing, supervision, or escalation did not stop or detect the problem earlier.
Guide effective action
Link corrective and preventive actions to evidence-supported causes, then define effectiveness measures capable of detecting recurrence or improved control.
Name the causal level correctly
Root cause, direct cause, contributing cause, and symptom
| Term | Practical meaning | Investigation question |
|---|---|---|
| Symptom or observation | What was seen, measured, reported, or detected. It describes the event but does not explain it. | What exactly differed from the approved or expected condition? |
| Failure mode | The way a component, process, method, control, or system failed to perform its intended function. | How did the system fail? |
| Direct or immediate cause | The condition closest to the event that directly produced the failure. | What immediately created the observed outcome? |
| Contributing cause | A factor that increased the likelihood, severity, duration, or poor detectability of the event but may not independently cause it. | What made occurrence more likely or control weaker? |
| Root cause | An evidence-supported, controllable causal condition whose removal or control should prevent or materially reduce recurrence. | Which underlying condition should be changed to break the causal pathway? |
| Escape or detection cause | The reason the failure was not detected, contained, or escalated before creating wider impact. | Why did the control system fail to find the problem sooner? |
| Systemic cause | A weakness in governance, design standards, management systems, resources, knowledge flow, or organizational controls that can affect multiple processes. | Why could this vulnerability exist beyond one event or location? |
| Most probable cause | The explanation best supported by available evidence when a single true root cause cannot be conclusively demonstrated. | Which hypothesis fits the evidence best, what contradicts it, and what uncertainty remains? |
Prepare before asking “why”
RCA prerequisites: containment, problem definition, and scope
Premature cause analysis produces premature conclusions. Before selecting a tool, stabilize risk, preserve evidence, and define the event in language that is factual, measurable, and free of an assumed cause.
Protect and preserve
- Contain affected material, product, data, equipment, areas, and distribution as applicable
- Preserve physical parts, samples, photographs, logs, alarms, audit trails, settings, calculations, and original records
- Record the as-found condition before cleaning, repair, reset, retest, or configuration change where safe and feasible
- Document immediate corrections and interim controls separately from permanent actions
Write a neutral problem statement
- Object: product, material, method, equipment, record, process, or system
- Defect: exact departure from requirement or expected condition
- Where and when: location, step, date, shift, lifecycle stage, and detection point
- Extent: quantity, frequency, batches, results, duration, and known boundaries
- Requirement: approved specification, instruction, validated state, or intended performance
Use Is / Is Not to establish boundaries
| Dimension | Is | Is not | Difference to investigate |
|---|---|---|---|
| What | Localized film-coat shade variation with spray interruption alarm. | No tablet-core defect, picking, or widespread roughness. | Failure may be linked to atomization or spray delivery rather than core quality. |
| Where | Samples aligned with spray gun 3 zone. | Not observed in zones served by guns 1, 2, and 4. | Compare gun-specific parts, settings, flow, cleaning, and assembly. |
| When | After 78 minutes of spraying following one extended hold. | Not during initial spray or previous uninterrupted batches. | Evaluate hold-time behavior, suspension circulation, drying, and restart sequence. |
| Extent | Two trays from one time window; IPC color difference exceeded the alert level. | Other time-point samples met the approved range. | Define exposure window and sampling representativeness. |
Evidence before conclusion
Step-by-step CAPA root cause analysis workflow
Define the decision
State what the investigation must determine: failure mechanism, affected scope, product and patient impact, recurrence risk, and the controls needed for a reliable CAPA decision.
Output: investigation questionsConfirm the problem statement
Describe the object, defect, requirement, time, location, extent, and detection without embedding a cause. Apply Is / Is Not, 5W2H, or a comparable method to establish boundaries.
Output: neutral, bounded problemBuild a verified chronology
Reconcile batch records, laboratory data, alarms, audit trails, equipment and maintenance logs, environmental records, access history, material movement, and interviews into one time sequence.
Output: fact-based timelineCompare expected versus actual
Identify every meaningful difference between approved design or procedure and actual execution. Check successful comparator batches, lines, shifts, methods, components, or time periods.
Output: change and difference listGenerate plausible hypotheses
Use Fishbone, 5 Whys, process mapping, barrier analysis, fault trees, brainstorming, and subject-matter expertise to identify technical, human, environmental, and system explanations.
Output: non-duplicative hypothesesPredict evidence before testing
For each hypothesis, write what should be observed if it is true, what should be observed if false, which records or tests can discriminate between alternatives, and what criteria will support a decision.
Output: hypothesis test planCollect and challenge evidence
Use attributable source data, physical evidence, controlled experiments, validated system data, historical patterns, and interviews. Actively search for contradiction and evaluate evidence reliability.
Output: evidence matrixDetermine causal structure
Separate direct, root, contributing, escape, and systemic causes. Determine whether several necessary conditions combined and whether one action can realistically break each relevant pathway.
Output: causal map and conclusionExtend scope and assess uncertainty
Search other batches, products, equipment, methods, suppliers, documents, sites, and systems that share the causal vulnerability. State evidence gaps, confidence, assumptions, and residual risk.
Output: horizontal and historical scopeLink causes to actions and effectiveness
Map each supported cause or control gap to a proportionate action and to a measure that can demonstrate recurrence prevention, improved detection, and sustained control.
Output: defensible CAPA planSimple questioning, disciplined proof
How to use the 5 Whys in pharmaceutical CAPA
The 5 Whys is a facilitated questioning technique that moves from an observed problem toward deeper causal conditions. “Five” is not a mandatory number: stop when the causal explanation is controllable and sufficiently supported, or branch when several mechanisms are plausible. Continue only while each answer is relevant, specific, and testable.
Best uses
- Relatively simple events with a short, understandable process pathway
- Early exploration before a more formal investigation tool
- Testing whether an apparent direct cause reflects deeper system conditions
- Facilitating discussion with operators and subject-matter experts
- Linking an event, failed barrier, cause, and corrective action
Use caution when
- Several interacting causes or feedback loops may exist
- The process is complex, automated, aseptic, computerized, or poorly understood
- Data integrity, fraud, sterility, cross-contamination, or patient harm is possible
- The sequence is uncertain or evidence has been lost
- The team is anchoring on operator error, training, or the first plausible answer
5 Whys example: recurring low capsule fill weight after changeover
Low capsule fill weights occurred during startup after product changeover, despite the documented machine setup being within the master instruction.
The dosing-disc depth did not provide sufficient powder volume for the actual bulk-density range of the incoming blend. Evidence: measured setup and fill-volume calculation matched the observed shortfall.
The operator selected the single nominal setup value shown on the product setup sheet. Evidence: batch record, equipment setting history, and interview agreed.
The master setup instruction had been copied from the exhibit batch and did not define an approved adjustment range linked to blend bulk density. Evidence: document history and development report comparison.
Technology transfer verified the nominal setup but did not assess how the registered blend-density range affected dosing volume. Evidence: transfer protocol had no requirement or calculation for this relationship.
The transfer risk-assessment template focused on parameter matching and did not prompt evaluation of material-property-to-equipment-setting relationships. Similar omissions were found in two other transferred products.
Direct cause: insufficient dosing depth. Root/systemic cause: the transfer process did not translate known blend variability into an operating range. Contributing cause: the setup sheet presented a single value without a controlled adjustment decision rule. The operator followed the approved instruction; “operator error” is not supported.
Map the full possibility space
How to use a Fishbone diagram for CAPA investigation
A Fishbone, Ishikawa, or cause-and-effect diagram organizes potential causes around a clearly stated effect. The categories are prompts, not conclusions. Use site-relevant headings and convert broad ideas into specific, testable hypotheses.
Knowledge, skill, fatigue, workload, staffing, supervision, communication, handoffs, ergonomics, interface design, usability, and competing priorities.
Design, wear, setup, calibration, maintenance, sensors, alarms, automation, software, access, interfaces, utilities, cleaning, and failure detection.
Sequence, parameters, instructions, hold times, line clearance, sampling, cleaning, changeover, validation, review, escalation, and control strategy.
Identity, variability, supplier, lot, storage, age, moisture, particle size, compatibility, container closure, labels, components, and sampling.
Method suitability, instrument state, sampling bias, calculation, specification, master data, audit trail, metadata, review, trend, and data integrity.
Temperature, humidity, pressure, airflow, contamination, vibration, lighting, space, layout, utilities, cleaning, season, and adjacent operations.
Governance, resources, risk decisions, change control, quality culture, supplier oversight, knowledge transfer, performance metrics, and standardization.
Prevention barriers, in-process controls, alarms, interlocks, review points, reconciliation, access restrictions, segregation, and escalation thresholds.
Similar deviations, complaints, OOS/OOT, maintenance, CAPA, changes, audits, other products, other sites, and recurring weak signals.
Step-by-step Fishbone method
- Place one neutral effect at the “head.” Include the measurable defect, boundary, time, and location—not an assumed cause.
- Select categories that fit the process. The traditional 6M set can be expanded for computerized systems, laboratory work, sterile operations, suppliers, or governance.
- Invite the right knowledge. Include operators, analysts, engineering, maintenance, Quality, validation, IT, supplier, regulatory, and human-factor expertise as relevant.
- Generate possibilities before judging them. Separate brainstorming from evaluation so hierarchy or early criticism does not suppress credible alternatives.
- Make each branch testable. Replace “machine problem” with “gun 3 nozzle orifice is partially obstructed after the extended hold.”
- Remove duplicates and show causal relationships. Some ideas are the same mechanism under different categories; others are contributing or detection causes rather than root causes.
- Prioritize by plausibility and risk. Do not discard a high-severity hypothesis simply because it seems less likely; define the evidence needed to evaluate it.
- Transfer hypotheses to an evidence matrix. Record predictions, sources, test methods, results, contradictions, and decisions outside the diagram.
Choose the tool for the problem
5 Whys vs Fishbone vs evidence testing
| Method | Main purpose | Strength | Limitation | Best practice |
|---|---|---|---|---|
| 5 Whys | Explore a causal chain from event toward underlying conditions. | Fast, intuitive, useful for simple pathways and team dialogue. | Can become linear, subjective, and anchored to the first answer. | Branch when needed and require evidence at every “because.” |
| Fishbone | Generate and organize a broad set of potential causes. | Reduces tunnel vision and supports cross-functional input. | Can become a decorative list with no prioritization or proof. | Convert every serious branch into a specific hypothesis and test plan. |
| Evidence testing | Discriminate among competing hypotheses and support a conclusion. | Creates transparent, reviewable reasoning and exposes contradiction. | Quality depends on available data, test design, and control of bias. | Predict results before testing and preserve disconfirming evidence. |
| Barrier analysis | Explain which preventive, detective, mitigating, or escalation barriers failed. | Connects causes to control strategy and escape mechanisms. | May not explain the technical origin of the initiating failure. | Use alongside mechanism-focused RCA for significant events. |
| Fault tree | Model combinations of conditions that can produce a defined top event. | Useful for complex technical systems and AND/OR relationships. | Requires expertise and a well-defined system boundary. | Base branches and probabilities on evidence, not intuition alone. |
Turn ideas into testable explanations
Evidence testing for root cause confirmation
Evidence testing asks whether a proposed cause predicts the facts better than reasonable alternatives. A strong test distinguishes hypotheses; merely finding information consistent with one idea is not enough if the same information also fits several others.
Seven-part hypothesis test
Claim
Write one specific causal statement with mechanism, object, condition, and effect.
Prediction
Define observable results expected if the hypothesis is true and if it is false.
Sources
Identify reliable records, raw data, parts, samples, comparators, experiments, and experts.
Method
Select a scientifically justified review, measurement, calculation, simulation, or controlled challenge.
Criteria
Set decision thresholds before seeing results to reduce hindsight and confirmation bias.
Contradiction
Seek observations the hypothesis cannot explain and evidence that supports alternatives.
Decision
Classify as confirmed, supported, refuted, or inconclusive with confidence and rationale.
Scope
Apply the supported mechanism to potentially related batches, systems, sites, and time periods.
Evidence qualities to evaluate
Use the best available sources
Pharmaceutical evidence sources for RCA
| Evidence family | Examples | Key checks |
|---|---|---|
| Production and packaging | Executed batch records, IPC data, recipes, yields, reconciliation, line clearance, alarms, stoppages, hold times, interventions, rejects, photographs, video. | Contemporaneous completion, corrections, missing entries, parameter context, review status, and consistency with electronic data. |
| Laboratory | Raw data, chromatograms, spectra, calculations, sample preparation, standards, reagents, instrument logs, sequences, audit trails, method suitability, OOS history. | Sample integrity, method capability, integration, metadata, repeat or retest rationale, analyst actions, and data completeness. |
| Equipment and facility | Calibration, maintenance, work orders, parts, breakdowns, PLC or historian data, utilities, environmental monitoring, BMS, differential pressure, temperature and humidity. | Time synchronization, sensor health, as-found condition, configuration changes, bypasses, alarms, maintenance effects, and data gaps. |
| Materials and suppliers | CoA, incoming tests, supplier deviations, lot genealogy, transport and storage, complaints, change notifications, retain samples, particle size, moisture, bioburden. | Representativeness, supplier method differences, chain of custody, shared lots, aging, excursions, and prior trends. |
| Computerized systems | Audit trails, access logs, master data, configuration, interfaces, time stamps, failed jobs, exception logs, backups, restore records, software changes. | Validated state, permissions, metadata, clock alignment, overwritten values, interface mapping, manual workarounds, and review controls. |
| People and work system | Interviews, observation, training, qualification, work schedule, staffing, handoffs, instructions, visual controls, workload, supervision, ergonomics. | Avoid blame and leading questions; compare recollection with records and evaluate why the system made the action possible. |
| History and comparators | Deviations, CAPA, complaints, returns, OOS/OOT, audits, APR/PQR, change controls, risk assessments, other products, lines, methods, sites, and successful runs. | Search criteria, classification consistency, period, normalization, similarity, weak signals, and previously ineffective actions. |
| Scientific challenge | Bench study, engineering trial, design of experiments, simulation, teardown, microscopy, material characterization, stress test, mock execution. | Approved protocol, safety, representativeness, controls, repeatability, predefined criteria, deviations, and interpretation limits. |
Evidence should follow ALCOA+ principles. An attractive graph, summary table, or interview statement is not reliable if the underlying source is incomplete, altered, poorly controlled, non-representative, or unavailable for review.
Protect the reasoning process
Common investigation bias and how to control it
ICH Q9(R1) recognizes that subjectivity can affect hazard identification, risk estimation, and judgments about risk reduction. RCA teams should make assumptions and potential bias visible rather than pretending that tools eliminate judgment.
| Bias | How it appears in RCA | Control |
|---|---|---|
| Anchoring | The first explanation—often operator error or a material lot—defines the entire investigation. | Generate alternatives before evaluation and have an independent reviewer challenge the initial theory. |
| Confirmation bias | The team collects supporting facts but ignores contradictions or tests that could disprove the favored cause. | Write “if true” and “if false” predictions, assign a devil's advocate, and document disconfirming evidence. |
| Hindsight bias | After the outcome is known, warning signals appear obvious and personnel are judged using information unavailable at the time. | Reconstruct what each person and control knew at each decision point. |
| Availability bias | A recent failure or familiar cause is assumed to explain the current event. | Use event-specific data, history, comparators, and process knowledge rather than memory alone. |
| Authority bias | A senior specialist's opinion is accepted without testing. | Separate expertise from evidence; record the hypothesis, source, assumptions, and objective test. |
| Outcome bias | A batch that passed final tests is assumed to have had no meaningful process failure. | Assess process capability, sampling limitations, validation, control failure, and patient risk independently of final result alone. |
| Search satisfaction | Investigation stops after finding one plausible cause. | Define completion criteria and test whether the cause explains all facts and why controls failed. |
| Groupthink | Cross-functional participants converge quickly to avoid conflict or delay. | Collect independent hypotheses first, use structured facilitation, and encourage dissent without blame. |
Understand the work system
Why “human error” is usually an incomplete root cause
A person may make the final observable action, yet the causal question remains: why did that action make sense, seem possible, escape detection, or occur under the conditions present? EU GMP expects human-error conclusions to be justified after ensuring that process, procedural, and system-based problems were not overlooked.
Task and interface
Complexity, sequence, memory demand, confusing screens, similar connectors, poor labeling, alarm burden, ergonomics, visibility, and error-recovery options.
Work conditions
Staffing, workload, shift pattern, fatigue, time pressure, interruptions, competing priorities, environment, supervision, and communication.
Quality system
Procedure design, training method, qualification, change communication, risk assessment, resources, maintenance, management expectations, and learning from history.
When can training be a valid corrective action?
Training may be appropriate when evidence demonstrates a specific knowledge or skill gap, the task and instruction are fit for purpose, required training was absent or ineffective, and competence can be verified. If trained people repeatedly fail, or the task depends on memory in a high-risk setting, stronger process or engineering controls are usually needed.
Be decisive without overstating certainty
What if the true root cause cannot be confirmed?
Evidence may be missing because a component was discarded, data were not captured, the failure is intermittent, the event cannot safely be reproduced, or several interacting causes fit the facts. An honest most-probable-cause conclusion is stronger than a false certainty.
A defensible most-probable-cause statement includes
- The hypothesis judged most consistent with the complete evidence
- Facts and scientific mechanism supporting it
- Evidence against it and how contradictions were resolved
- Reasonable alternatives and why they are less likely or refuted
- Missing evidence, assumptions, confidence, and residual uncertainty
- Impact of uncertainty on scope, product decision, action strength, and monitoring
Risk controls when uncertainty remains
- Broaden containment or affected-scope assessment
- Improve detection, data capture, alarms, sampling, or retention of failed parts
- Address more than one plausible causal pathway where justified
- Use staged actions or controlled studies to learn while protecting quality
- Set tighter interim monitoring and escalation thresholds
- Reopen the investigation when new evidence emerges
Close the causal loop
Link RCA conclusions to CAPA and effectiveness
An RCA conclusion is useful only if it produces controls that interrupt the causal pathway. Build a traceability matrix so reviewers can see which action addresses which cause and which effectiveness measure demonstrates that the intended outcome occurred.
| Causal finding | Action strategy | Implementation evidence | Effectiveness evidence |
|---|---|---|---|
| Transfer template omitted material-property-to-setting assessment. | Revise the template and governance to require documented linkage of critical material attributes to equipment operating ranges. | Approved change, released template, revised procedure, training and qualification, retrospective product review. | Sample completed transfers for correct analysis; verify related startup deviations decrease without hidden manual workarounds. |
| Setup sheet provided one nominal dosing depth despite an approved density range. | Define a scientifically justified setup range and adjustment decision rule through validated change control. | Approved study, master-document revision, controlled recipe, training, and removal of obsolete copies. | Review startup fill-weight capability across the defined density range and meaningful changeover opportunities. |
| IPC detected low weights only after capsules were produced. | Add a pre-run verification or engineered setup confirmation capable of detecting insufficient dosing volume. | Qualified control, acceptance criteria, revised startup sequence, and user verification. | Challenge the detection function and trend startup exceptions, response time, and recurrence. |
Make the reasoning reproducible
What a GMP-ready RCA report should contain
- Source record, identifiers, requirement, detection, reporter, dates, and investigation authority
- Immediate correction, containment, notification, interim controls, and preserved evidence
- Neutral problem statement with object, defect, location, time, extent, and expected condition
- Initial and updated patient, product, data, compliance, and business-continuity risk
- Investigation scope, exclusions, last known acceptable state, affected window, and decision questions
- Verified chronology reconciled across paper, electronic, physical, and interview evidence
- Expected-versus-actual comparison, successful comparators, changes, and distinctive differences
- RCA tools used, participants, expertise, facilitation method, and reason the tools fit the problem
- Hypothesis list with “if true,” “if false,” sources, methods, criteria, results, and contradictions
- Evidence reliability, sampling and method limitations, missing information, and data-integrity assessment
- Root, direct, contributing, escape, and systemic causes with confidence and scientific rationale
- Alternative causes refuted or unresolved and the evidence supporting each decision
- Historical and horizontal review across batches, products, systems, suppliers, sites, and record types
- Product and patient impact, distributed status, reporting assessment, and authorized disposition linkage
- Cause-to-action-to-effectiveness traceability with change control, validation, training, and owners
- Quality review, approvals, corrections to the record, audit trail, attachments, retention, and closure status
Interactive investigation aid
RCA evidence-strength checker
Select every condition supported by the investigation. This is a coverage aid, not a validated scoring model; it cannot confirm root cause, replace expert review, or determine GMP compliance.
Quality-review checklist
Questions to challenge an RCA before CAPA approval
- Does the problem statement describe the event without blaming a person or assuming a mechanism?
- Were immediate controls applied without destroying evidence needed for the investigation?
- Does the chronology use synchronized, attributable sources and explain gaps or conflicts?
- Did the team compare the failure with successful states and identify what changed or differed?
- Were suitable SMEs involved and were investigators independent enough to challenge local assumptions?
- Were 5 Whys or Fishbone outputs treated as hypotheses rather than proof?
- Does each serious hypothesis have a mechanism, predictions, test method, criteria, and conclusion?
- Was evidence that could refute the favored explanation actively sought and retained?
- Can the chosen cause explain the timing, location, extent, recurrence pattern, and control escape?
- Were sampling, measurement, method, data-integrity, and historical-search limitations assessed?
- Does any human-error conclusion address process, procedure, equipment, interface, workload, and organization?
- Are root, direct, contributing, and detection causes clearly differentiated?
- Were other affected or vulnerable batches, products, systems, suppliers, methods, and sites assessed?
- If only a most probable cause was reached, are uncertainty and residual-risk controls adequate?
- Does every action address a supported cause or control gap rather than only the visible symptom?
- Can the effectiveness check test the causal model under meaningful process opportunities?
Avoid weak investigation patterns
Common RCA mistakes and better practices
| Weak practice | Why it fails | Better practice |
|---|---|---|
| Stopping after exactly five whys | The number is arbitrary; the chain may stop too early or continue into unsupported speculation. | Stop at an evidence-supported, controllable causal level; branch whenever alternatives exist. |
| Fishbone voting selects the cause | Popularity measures opinion, not mechanism or evidence. | Use voting only to prioritize testing; document evidence-based decisions for every serious hypothesis. |
| One interview becomes proof | Memory can be incomplete and influenced by hindsight, pressure, or leading questions. | Reconcile interviews with records, data, observation, physical evidence, and comparators. |
| Absence of recurrence proves cause | The failure opportunity may not have occurred, detection may be weak, or production may be infrequent. | Define meaningful exposure, baseline, detection capability, duration, and acceptance criteria. |
| Operator error plus retraining | System weaknesses remain unchanged and recurrence remains likely. | Investigate the work system and use stronger design or process controls when appropriate. |
| Only confirming evidence is recorded | The conclusion becomes circular and alternatives are never challenged. | Record disconfirming evidence, unresolved facts, and reasons alternatives were refuted. |
| “No root cause” ends the work | Risk remains without improved detection, control, or learning. | Document the most probable cause, uncertainty, broader controls, monitoring, and future evidence capture. |
| Cause label is too broad | Terms such as “procedure,” “machine,” or “training” do not describe a mechanism. | State the specific condition, how it produced the effect, and why controls did not prevent or detect it. |
| Testing into a preferred conclusion | Repeated or selective testing can hide variability and inflate confidence. | Use an approved test plan, predefined criteria, full data reporting, and justified sampling. |
| CAPA action chosen before RCA | The investigation can be shaped to justify an already funded or convenient solution. | Separate hypothesis evaluation from action selection and independently review cause-action linkage. |
AEO quick answers
Frequently asked questions about CAPA root cause analysis
What is root cause analysis in pharmaceutical CAPA?
Root cause analysis is a structured investigation that uses reliable evidence to explain why a quality problem occurred, why controls failed to prevent or detect it, which factors contributed, what scope may be affected, and which controllable causes should be addressed through CAPA.
What is the purpose of the 5 Whys method?
The 5 Whys method explores a causal chain by repeatedly asking why an event or condition occurred. It helps move beyond the immediate symptom, but each answer must be specific and evidence-supported. Five is a guide, not a mandatory stopping point.
Must investigators always ask exactly five whys?
No. Some problems reach a supported causal level after fewer questions, while complex events require more questions and multiple branches. The investigation should stop when the causal explanation is sufficiently supported, controllable, and able to explain occurrence and control failure.
What is a Fishbone diagram in CAPA?
A Fishbone or Ishikawa diagram is a cause-and-effect tool that organizes potential causes into categories such as people, equipment, method, materials, measurement, environment, management, and controls. It generates hypotheses but does not prove which cause is correct.
Which is better: 5 Whys or Fishbone analysis?
Neither is universally better. The 5 Whys is useful for exploring a relatively simple causal pathway. Fishbone analysis is useful when many categories or interacting causes are possible. Complex investigations often use both, followed by evidence testing to support or refute hypotheses.
Is a completed Fishbone diagram proof of root cause?
No. A Fishbone diagram is a structured brainstorming output. Each serious branch should be converted into a specific hypothesis with predicted evidence, reliable data sources, a test method, predefined criteria, contradictory evidence, and a documented decision.
How is a root cause hypothesis tested?
State the causal mechanism, predict what should be observed if it is true and if it is false, select reliable evidence and a discriminating test, define criteria before reviewing results, examine contradictions and alternatives, and classify the hypothesis as confirmed, supported, refuted, or inconclusive.
What evidence is strongest for pharmaceutical RCA?
Evidence strength depends on context, but strong conclusions usually combine independent sources such as contemporaneous raw data, physical evidence, validated-system records, successful-versus-failed comparisons, scientifically controlled testing, and a chronology that aligns the proposed mechanism with the event.
Can an interview establish pharmaceutical root cause?
An interview can provide important context and identify evidence, but it rarely proves root cause by itself. Recollection should be compared with contemporaneous records, electronic data, physical evidence, process observation, history, and scientific testing while avoiding leading or blame-focused questions.
Is human error an acceptable root cause?
Human error may describe a direct action, but it is usually incomplete as a final cause. Investigators should evaluate task design, procedure clarity, interfaces, equipment, training, competence, workload, fatigue, environment, supervision, detectability, and organizational conditions before accepting the conclusion.
What is the difference between root cause and contributing cause?
A root cause is an underlying controllable condition whose removal or control should prevent or materially reduce recurrence. A contributing cause increases the probability, severity, duration, or poor detectability of the event but may not independently produce it.
What is a most probable cause?
A most probable cause is the explanation best supported by the available evidence when the true root cause cannot be conclusively demonstrated. The report should state supporting and contradictory evidence, reasonable alternatives, missing information, confidence, residual uncertainty, and risk controls.
What should be included in an RCA evidence matrix?
An RCA evidence matrix should list each hypothesis, proposed mechanism, expected observations if true and false, evidence sources, test method, predefined criteria, actual results, reliability limitations, contradictions, alternative explanations, decision, confidence, and effect on scope and CAPA.
How can confirmation bias be reduced during RCA?
Generate alternative hypotheses before evaluation, define “if true” and “if false” predictions, set criteria before viewing results, assign independent challenge, seek disconfirming evidence, separate expert opinion from fact, retain contradictions, and document assumptions and uncertainty.
How should RCA results be linked to CAPA?
Each supported cause or control gap should map to a specific corrective or preventive action, accountable owner, implementation evidence, and effectiveness measure. The action should break the causal pathway, while the effectiveness check should test whether recurrence risk and control performance improved.
What happens if no root cause is found?
Document the most probable cause or state that the cause remains inconclusive, explain evidence gaps and alternatives, reassess affected scope and residual risk, strengthen prevention or detection where justified, improve future evidence capture, monitor closely, and reopen the investigation if new information emerges.
Primary regulatory references
.webp)
