GCP · Blog
Back to journal

Root Cause Analysis in Clinical Trials: How to Reach a Systemic Cause Your CAPA Can Actually Prevent

If you have an open protocol deviation or a repeat finding and you are quietly wondering whether your RCA will survive an inspection, this is for you. The honest answer in most cases is: not yet, because the RCA stopped one level too early.

GCP 11 min read
A

Aileen

Aileen writes practical guidance for clinical trial teams at GCP Blog.

On this page · 10 sections
  1. 01 At a glance
  2. 02 RCA vs CAPA vs symptom: the three things teams collapse into one
  3. 03 The proportionality gate: let impact set RCA depth
  4. 04 Picking the technique: a decision table, not a religion
  5. 05 The “human error, retrain” trap
  6. 06 The “deep enough” stop test
  7. 07 Why deviations recur: the symptom you treated and the signal you missed
  8. 08 Documenting RCA for inspection
  9. 09 Worked example: one protocol deviation, trigger to verified cause
  10. 10 Sources

At a glance

  • Root cause analysis (RCA) is not a tool you pick off a shelf. It is a discipline that has to terminate at a verifiable, process-level cause that a corrective and preventive action (CAPA) can actually prevent.
  • RCA, CAPA, and the symptom are three different things. RCA is the gate that decides whether your CAPA is valid; if the RCA stops at the symptom, the CAPA is built on sand.
  • “Human error, retrain the CRC” is the single most common failure mode and almost always a red flag. An individual mistake that a process allowed is a process problem.
  • ICH E6(R3) ties the depth of your response to a deviation’s impact on participant safety and data reliability. Proportionality is the rule, not a flat ritual on every event.
  • The recurrence test is brutal and simple: if the same deviation comes back after your CAPA, your RCA named a symptom, not a cause.
  • Document the investigation so an inspector can follow trigger, analysis, cause, and verification without a tour guide.

If you have an open protocol deviation or a repeat finding and you are quietly wondering whether your RCA will survive an inspection, this is for you. The honest answer in most cases is: not yet, because the RCA stopped one level too early.

RCA vs CAPA vs symptom: the three things teams collapse into one

These three get blended into a single paragraph in most deviation reports, and that blending is exactly why findings recur.

The symptom is what you observed: a missed eligibility assessment, an out-of-window visit, an unblinded record. It is the trigger, not the cause.

Root cause analysis is the investigation that walks from that symptom back to the systemic reason it was possible. ICH E6(R3) is explicit that when noncompliance significantly affects, or has the potential to significantly affect, the rights, safety, or well-being of participants or the reliability of results, the sponsor should perform a root cause analysis, implement appropriate corrective and preventive actions, and confirm their adequacy (ICH E6(R3) §3.12.2). Notice the sequence: analysis first, then action, then confirmation. The CAPA is downstream of the RCA.

The CAPA is the action you take and the action you put in place to stop recurrence. It is only as good as the cause it targets. Under the GCP principles, sponsors should implement strategies to avoid, detect, address, and prevent recurrence of serious noncompliance (ICH E6(R3) §6.3). “Prevent recurrence” is the operative phrase, and you cannot prevent recurrence of a cause you never named.

So the chain is: symptom triggers RCA, RCA identifies the systemic cause, CAPA treats that cause, and you then confirm the CAPA was adequate. Collapse any step and the whole thing fails quietly until the deviation comes back.

The proportionality gate: let impact set RCA depth

Not every deviation warrants the same investigative weight, and pretending otherwise wastes the effort you need for the deviations that matter. ICH E6(R3) builds quality management on a proportionate, risk-based approach, where risk control should be proportionate to the importance of the risk to participants’ rights, safety, and well-being and the reliability of trial results (ICH E6(R3) §3.10.1.3). The same logic governs how hard you investigate.

Start by classifying. The sponsor should set trial-specific criteria for classifying protocol deviations as important, where important deviations are the subset that may significantly impact the completeness, accuracy, or reliability of trial data or significantly affect a participant’s rights, safety, or well-being (ICH E6(R3) §3.9.3). That classification is your depth dial. A minor, low-impact deviation may need a brief, documented assessment. An important deviation that touches a critical-to-quality factor needs a full RCA.

This is where ICH E8(R1) reframes the work. The quality-by-design approach focuses on critical to quality factors, the attributes whose integrity is fundamental to protecting participants and to the reliability and interpretability of results (ICH E8(R1) §3.2). When a deviation hits one of those factors, depth is not optional. ICH E8(R1) also warns that critical to quality factors should be clear and not cluttered with minor issues (ICH E8(R1) §3.2), which is the same instinct applied in reverse: do not drown a safety-critical deviation in the same shallow template you use for a late lab draw of no consequence.

ISO 31000 gives the underlying mechanic. Risk analysis can be undertaken with varying degrees of detail and complexity depending on the purpose of the analysis and the information available (ISO 31000:2018 §6.4.3). RCA is a form of risk analysis applied after the fact, and the standard’s own guidance is that the depth scales with what is at stake.

Picking the technique: a decision table, not a religion

The technique matters far less than where it terminates, but matching the technique to the deviation’s shape saves you from forcing a multi-factor failure through a single linear chain.

Deviation patternSuitable techniqueStop criterion
Single, linear failure chain (one missed step led to one outcome)5 WhysYou reach a process or system condition that, if changed, removes the chain; not a person’s name
Multi-factor failure (several contributing conditions: people, process, environment, tools, materials)Ishikawa / fishboneEach branch resolves to a controllable systemic factor; the dominant contributor is identified and treated
Recurring or cross-site pattern, or a safety-critical eventStructured RCA with trend/aggregate reviewCause is process-level and explains the cluster, not just the latest instance

ISO 31000 supports the multi-factor instinct directly: an event can have multiple causes and consequences and can affect multiple objectives (ISO 31000:2018 §6.4.3). If your investigation keeps surfacing more than one contributing condition, a linear 5 Whys will hide that complexity, and a fishbone is the more honest tool. The standard also lists what to consider when identifying risk sources, including causes and events, vulnerabilities and capabilities, and the effectiveness of existing controls (ISO 31000:2018 §6.4.2). That checklist is a usable prompt set for any RCA, whatever diagram you draw.

The “human error, retrain” trap

Here is the conclusion that ends more RCAs than any other, and the one inspectors have learned to distrust on sight: “Root cause: human error. CAPA: retrain the coordinator.” It is fast, it is comfortable, and it is almost always a symptom dressed up as a cause.

The test is mechanical. Ask whether a different, fully trained person could have made the same mistake under the same conditions. If yes, the cause is not the person; it is the condition that let a trained person fail. A confusing source-document layout, an SOP that contradicts the protocol, an eligibility checklist that does not match the inclusion criteria, a system that lets you save an out-of-window visit without a flag: these are systemic causes. “Retrain” treats the person as the defective component and leaves the condition in place, which is why the next person trips over the same thing.

ISO 31000 frames effective treatment as removing the risk source or changing the likelihood of the event (ISO 31000:2018 §6.5.2). Retraining one individual rarely removes the source; the source is still sitting there for everyone else. ICH E8(R1) reinforces this at the cultural level, encouraging a culture that values critical thinking and open dialogue, going beyond sole reliance on tools and checklists (ICH E8(R1) §3.3.1). A blame-the-individual reflex is the opposite of that culture, and it is corrosive to the open reporting you need to catch problems early.

Retraining can be a legitimate part of a CAPA, but only when the RCA has shown a genuine competence or knowledge gap, and usually alongside a process fix, never as the whole answer.

The “deep enough” stop test

How do you know you have hit a true root cause and not just a deeper symptom? Three conditions, all of which must hold:

  1. Process-level. The cause is a feature of the process, system, or environment, not a one-off act by one person.
  2. Controllable. The organization can actually change it. A cause you cannot influence is context to manage, not a root cause to treat.
  3. Preventive sufficiency. A CAPA aimed at this cause would have prevented the original event. Run the counterfactual: if the fix had been in place last month, does the deviation still happen? If yes, keep going.

ISO 31000 describes risk treatment as an iterative process that includes assessing the effectiveness of that treatment and deciding whether the remaining risk is acceptable, and if not, taking further treatment (ISO 31000:2018 §6.5.1). That iteration is your permission to not stop at the first plausible answer. ICH E6(R3) closes the loop from the regulatory side by requiring the sponsor to confirm the adequacy of corrective and preventive actions (ICH E6(R3) §3.12.2). “Confirm adequacy” is not a signature; it is evidence that the cause was correctly identified and the action actually neutralized it.

Why deviations recur: the symptom you treated and the signal you missed

When the same deviation returns, there are usually two reasons, and both trace to a shallow RCA.

First, the RCA named a symptom, so the CAPA never touched the cause. The fix addressed the instance, not the condition, and the condition produced the next instance on schedule.

Second, you treated the event in isolation and missed the aggregate signal. A single out-of-window visit looks like an individual slip. Ten of them across three sites is a process telling you something. ICH E6(R3) expects monitoring to examine data trends, such as the range, consistency, and variability of data within and across sites (ICH E6(R3) §3.11.4.5.4). ISO 31000 likewise treats monitoring and review as a planned part of the process whose purpose is to assure and improve effectiveness (ISO 31000:2018 §6.6). RCA on the single event without the trend view will keep producing CAPAs that fix one tree in a forest of the same problem.

There is a genuine tension worth naming here, and you should not smooth it over. ICH E6(R3)‘s proportionality rule (ICH E6(R3) §3.10.1.3) tells you not to over-investigate low-impact events, while the recurrence and trending logic tells you that a pattern of individually minor deviations can itself be a high-impact signal. These pull in opposite directions on any single event. The resolution is not to pick one: judge the individual event proportionately, but let trend and aggregate review reclassify a cluster of minor events as an important signal that earns a deeper RCA. Hold both, and decide at the cluster level, not just the event level.

Documenting RCA for inspection

An inspector does not grade your diagram. They reconstruct your reasoning. The investigation record has to let them walk from trigger to verified cause without you in the room.

ICH E6(R3) requires the investigator to document all protocol deviations (ICH E6(R3) §2.5.3), and it treats records that document deviations detected and the implementation of corrective and preventive actions as essential records to be retained (ICH E6(R3) Appendix C, §C.3.1). The records exist because they are the evidence trail. ISO 31000 adds that the influences on a risk analysis, including assumptions, exclusions, and limitations, should be considered, documented, and communicated to decision makers (ISO 31000:2018 §6.4.3). Your RCA write-up should expose its own reasoning, not just its conclusion.

A defensible RCA record contains:

  • Trigger and description. What happened, when it was detected, and how.
  • Classification and impact assessment. Important or not, and which critical-to-quality factor, participant right, safety, or data-reliability dimension it touches.
  • The analysis itself. The technique used and the actual chain or contributing factors, not a bare conclusion.
  • The identified systemic cause. Stated as a process or system condition, passing the three-part stop test.
  • The CAPA. Corrective action for the instance, preventive action for the cause, with owners and dates.
  • Adequacy confirmation. The evidence that the CAPA worked and the deviation did not recur, satisfying the §3.12.2 requirement to confirm adequacy.

If the record shows “human error / retrain” with no analysis behind it, you have handed the inspector their finding.

Worked example: one protocol deviation, trigger to verified cause

Trigger. During monitoring, a CRA finds that a participant was randomized despite a screening lab value outside the protocol’s inclusion range. A data trend review (ICH E6(R3) §3.11.4.5.4) shows two similar near-misses at the same site in the prior eight weeks.

Classification. Eligibility is a critical-to-quality factor (ICH E8(R1) §3.2); a participant enrolled against inclusion criteria affects both safety and data reliability, so this is an important deviation (ICH E6(R3) §3.9.3) and warrants a full RCA at proportionate depth (ICH E6(R3) §3.10.1.3).

Analysis. Because the trend suggests more than one contributing factor, the team uses a fishbone, consistent with the principle that an event can have multiple causes (ISO 31000:2018 §6.4.3). Branches surface three contributors: the eligibility checklist did not include this specific lab parameter, the lab result arrived after the randomization window opened, and the system permitted randomization without a hard eligibility confirmation.

Stop test. “The coordinator missed it” fails all three criteria: a trained coordinator would plausibly miss it again (not process-level), and retraining would not change the checklist, the timing, or the system gate (not preventive). The team keeps going to the controllable, process-level causes: an incomplete checklist and a missing system control.

CAPA. Correct the checklist to include the parameter; add a system rule requiring eligibility confirmation before randomization unlocks; this removes the risk source rather than merely changing one person’s behavior (ISO 31000:2018 §6.5.2).

Confirm adequacy. Over the following review cycle, monitor eligibility confirmations and check for recurrence, then document the result, satisfying the requirement to confirm the adequacy of the actions (ICH E6(R3) §3.12.2) and the standard’s expectation to assess treatment effectiveness (ISO 31000:2018 §6.5.1).

That is the difference between an RCA that closes a finding and one that closes the gap. The first stops at the symptom and the same deviation returns. The second stops at a systemic cause your CAPA can prevent, which is the only kind of RCA worth writing.

For the adjacent mechanics, see the companion pieces on protocol deviation classification, CAPA writing, and deviation trending and aggregate review, which sit alongside this guide under the RBQM and quality-management-system pillar.

None of this certifies compliance, and no process or system makes a sponsor compliant on its own. These regulations set what must be required and prevented; the sponsor remains responsible for designing the RCA discipline that meets them.

Sources

A

Written by

Aileen

Aileen writes practical guidance for clinical trial teams at GCP Blog.