RCA and CAPA in Clinical Research (How Not to Fix the Same Issue Over and Over Again)

Quality Events (QEs) are a fact of life in clinical research. Documents go missing arbitrarily. Temperature excursions for investigational products happen more often than we’d like. People do, well, people-y things. However, what separates a mature, well-appointed quality organization from the perpetually frustrated quality organization is not that one organization has more or fewer events than the other; it’s how well the Root Cause Analysis (RCA) and Corrective and Preventive Actions (CAPAs) are executed.

Before we dive into the meat and potatoes of RCA and CAPA, let’s review the process for how QEs are reported because this sets the stage for how the RCA is performed (and who is included), what CAPAs are (and aren’t) needed, and whether or not and Effectiveness Check (EC) is required.

Below is the typical progression of activities when a QE occurs.

We are going to focus on the three activities in the dashed box: Root Cause Analysis, Corrective Action and Preventive Action, and the Effectiveness Check. When done well, the RCA, CAPA, and EC are powerful tools that strengthen your quality management system, protect patients, and prevent repeat issues which can lead to audit or inspection findings.

Why RCA and CAPA Matter (Not Just Because QA Said So…)

Clinical Quality Assurance exists to protect patient safety, preserve clinical data integrity, ensure compliance with regulatory requirements, and enable reliable decision-making. The first thing an auditor or inspector will ask for will be a list of your quality events, and they first thing they’re going to want to know will not be “who messed up?” but “how did this happen and how will you keep this from happening again?” A well-defined RCA and CAPA process demonstrates that you and your team truly understand why the issue happened, and that you have the correct tools to prevent the issue from happening again.

What is RCA, anyway?

A RCA exercise is a structured process for understanding why a quality event occurred. Not just the very obvious failure of a process or system, but the true underlying cause of that failure. However, it should be noted that RCA activities are not: a blame game, a formality just to “get this whole thing over with faster,” or something that QA has devised to test just how strong your mental fortitude really is.

Some common pitfalls that exist in the RCA space.

• Stopping at the first answer
  • Asking ‘why’ once is a diagnosis, asking it multiple times is an RCA
• Trying to fit all issues into a neat box of root causes
  • Just because an issue may look similar to something that happened in the past, doesn’t mean it necessarily is the same as a previous issue.
• Automatically assigning the cause to an individual instead of the system
  • Personnel function within a system. If more than one person can make the same mistake, the root cause isn’t with the person, it’s with the system.

A solid RCA should:

• Examine process design, not just user behavior
• Consider personnel workload, process clarity, procedural tools, personnel training, and management oversight and accountability
• Identify systemic contributors even if the event has only happened once
• Use structured tools when appropriate

Taking your RCA game from “site staff failed to follow the SOP” to “the SOP lacked clear decision guidance, training did not include practical scenarios, and monitoring oversight did not detect early indicators of process drift”

This is what happens when your quality organization can effectively use the last bullet point.

Tools of the RCA Trade

Depending on the complexity of the issue, a variety of tools are available when conducting a RCA. This is not an exhaustive list, of course, but instead a compilation of the most used tools within the clinical research realm.

1. Five Whys
   1. This is a simple progression of asking “why” until the team is able to move from the symptom of the issue to the actual root cause of the issue.
   2. This tool is best used when the QE is straight-forward, when there is a single cause, or for low-risk issues.
   3. Five whys is easy to use and document with a quick turnaround time and encourages thinking beyond the immediate, obvious cause.
   4. This tool has the potential to oversimplify more complex issues, may stop at the humor error factor if not executed properly, and can be weak if sufficient evidence is not provided.
   5. From a regulatory perspective, this tool is acceptable for low-risk issues, but if the issue becomes systemic or repeats frequently, deeper analysis will be expected.
      
      
2. Fishbone (Iskikawa) Diagram
   1. This is a visual tool that categorizes potential causes into common groups or categories.
   2. This tool is best used when multiple contributing factors are suspected, cross-functional input is needed, and/or the suspected cause is due to the breakdown of a specific process.
   3. Common groups or categories that exist in the GxP space include:
      1. People (training, workload)
      2. Process (Clarity of SOP or handoff process)
      3. Systems (eQMS or CTMS)
      4. Materials (IMP) or data
      5. Environment
      6. Management oversight
   4. This exercise prevents the singling out of one person and encourages systemic critical thinking.
   5. Unfortunately, sometimes contributing causes are not always the true root cause. Additionally, this tool can lead to speculation if not facilitated appropriately.
   6. From a regulatory perspective, this tool is robust and demonstrates strong understanding of the true root cause(s) of the issue.
      
      
3. Fault Tree Analysis (FTA)
   1. This tool is a top-down, logic-based approach that maps how the combination of process or people failures lead to the event.
   2. This tool is best used for high-risk events where patient safety or data integrity could be impacted, or if there are complex system interactions.
   3. While this tool is highly-structured, rigorous, and has strong risk-based justification, its application is time-intensive and requires experienced personnel to execute it cleanly.
      
      
4. Human Factors Analysis (HFA)
   1. This tool focuses on the human factors and how those folks’ interactions with the systems, processes, and environments lead to the event.
   2. HFA is best used when human error is the suspected root cause and is great for documenting errors, procedural usability issues, or potential workload concerns.
   3. When executed properly, this tool can prevent the “retraining” CAPAs that QA “loves,” and can integrate well in a mature quality culture.
   4. From a regulatory perspective, HFA has strong defensibility during an audit as it can demonstrate a thorough understanding of the subjective influence of people on quality.
      
      
5. Failure Mode and Effects Analysis (FMEA)
   1. Commonly used in the pharmaceutical manufacturing space, this tool has applications in clinical research when a deep dive into failure modes and their causes and effects are needed.
   2. This tool is best used for recurrent quality issues or when a quality event reveals a possible process or systemic vulnerability.
   3. From a regulatory perspective, this tool aligns well with ICH E6 (R3), supports preventive actions, not just the correction, and can be linked to the resulting effectiveness check (EC).
   4. Since FMEA is a complex tool, it requires more complex documentation and consistent application of the scoring of effects.

Corrective and Preventive Actions: Where Good Intentions Go to Die

Once you have completed your root cause analysis using one of the nifty tools discussed in the last section, it’s time to develop how the root cause is going to be addressed. If not formulated thoughtfully, every good intention the team has can go straight down the drain if what is broken or ineffective isn’t fixed to prevent recurrence. As you work through your CAPA process, take care not to make these common mistakes.

Implementing ‘retraining only’ CAPAs

Not only is retraining not an effective CAPA and is like nails on a chalkboard to any quality assurance professional, but if every CAPA suggests that retraining is needed, it calls into question the robustness and effectiveness of your organization’s training program. Yes, it is an appealing CAPA: it’s fast, it’s familiar, and it feels safe. However, it screams “Here we don’t fix our systems, we just tell our folks to be careful.” Quality by design is no longer a buzz word in the ‘biz, it’s now an expectation.

Including vague action items

These include wish list items like “increase oversight” and “improve communication.” These are not measurable, lack accountability, and rarely address the root cause of the issue.

CAPAs that do not link directly back to the root cause

If the CAPA that you and the team developed doesn’t link directly and meaningfully back to the root cause, it cannot be effectively corrected and you will inevitably be stuck in the dreaded QE à CAPA à QE cycle.

Failing to utilize the Effectiveness Check (EC)

Implementing a CAPA without going back to verify that it actually worked and addressed the root cause is like making an empty promise to your significant other. A well-formulated EC is defined up front, uses objective, measurable evaluation criteria, and occurs after enough time has passed to be meaningfully assessed.

When CAPAs are strong, well-formulated, and effective, something magical happens. Well, maybe not truly “magical” in the “unicorn prancing over a rainbow” sort of way, but more in a “wow! That’s how this is supposed to work!” kind of way.

Things that strong, effective CAPAs do:

• Address your process design, not just whether or not it is compliant
• Contain specific, measurable, and time-associated action items
• Include preventive actions and not just corrective actions
• Contain a defined effectiveness check and include what will be measured, how it will be measured, and what success looks like

Strong and effective CAPAs also demonstrate to auditors and inspectors your organization understands your processes, the risks, and the impacts on quality when one or more factors in your process break. They also show that you were able to step seamlessly into “Sleuth Mode” and work thoughtfully to fix the system and not just the symptom. Finally, it makes evident that your organization is able to learn from your mistakes, work to prevent recurrence in a meaningful way, and that your quality culture is mature and robust.

The Wrap-up

Quality events are inevitable but repeating them doesn’t have to be. When root cause analysis is treated like an investigation instead of just a check box on a form, CAPA are designed to strengthen your organization’s systems rather than scold your personnel, and quality stops being reactive and starts being strategic. And that is a pretty “magical” place to be.

Author:
Emily Dickinson
Director Quality Assurance
Linical