Quality failures in clinical research rarely surface without early warning signs. Delegation logs remain unsigned for weeks. Investigational products get dispensed outside approved storage windows. The same data entry discrepancy appears again during monitoring, even after previous corrective steps. Every issue leads to documentation, internal discussions, and sometimes formal findings. In many cases, identical operational gaps continue repeating across sites, studies, or departments.
Corrective and Preventive Action (CAPA) management exists to stop that cycle. Structured CAPA processes turn quality events into documented, investigated, verified, and fully resolved outcomes. It captures what went wrong, investigates why, defines what will change, confirms those changes worked, and closes the record with evidence. So, every step is traceable, and every decision is accountable.
AQ’s CAPA management guide covers:
- What CAPA management is and why it matters in clinical research
- The full CAPA lifecycle — stage by stage
- Who uses CAPA and what each role does within the process
- Root cause analysis methods used in clinical trials
- How CAPA connects to deviations, audits, QMS, and inspection readiness
- What a CAPA system needs to do to be fit for regulated research
- How AQ CAPA works and what makes it built for clinical operations
What Is CAPA Management?
CAPA stands for Corrective and Preventive Action. In clinical research, it is the formal process for identifying, investigating, resolving, and preventing recurrence of quality events: deviations, audit findings, document non-conformances, risk signals, and inspection observations.
Corrective action addresses what already happened. It fixes the specific gap, process failure, or oversight breach that caused the event.
Preventive action addresses what could happen again. It changes the conditions that made the event possible in the first place — the SOP that was ambiguous, the training that was never verified, the oversight step that had no owner.
A robust CAPA process does both. Corrective action without preventive action repairs the damage without changing the system. Preventive action without corrective action changes the system without addressing the immediate harm. Effective CAPA management requires both, documented together, with evidence that each was executed and that the outcome was verified before the record closes.
In practice, CAPA management is the mechanism through which clinical research organisations demonstrate they can identify problems, understand them properly, resolve them systematically, and confirm the resolution held. Regulators do not expect perfection. They expect control and a functioning CAPA programme is evidence of it.
Clinical trials operate within tightly controlled environments where protocol deviations, data discrepancies, and procedural gaps carry direct consequences for participant safety, data integrity, and regulatory acceptance. CAPA management creates the operational structure required to identify issues, investigate root causes, implement corrective actions, and maintain long-term quality oversight across study operations.
MHRA inspection teams regularly assess CAPA programmes during sponsor and site audits. Well-documented CAPA records demonstrate operational control, accountability, and effective quality management. Repeated deviations without traceable resolution often signal deeper oversight failures.
ICH-GCP E6(R3) places clear expectations around quality issue management and effectiveness evaluation, which CAPA processes support through:
- Root cause identification and investigation
- Corrective action tracking with assigned ownership
- Preventive action implementation across future operations
- Effectiveness verification with supporting evidence
- Traceable documentation for audits and inspections
- Defensible quality oversight across sites, studies, and vendors
The CAPA Lifecycle — Stage by Stage
Every CAPA record follows a structured sequence of stages. Each stage builds on the last. No stage can be skipped. The integrity of the process depends on each gate being completed before the next opens.
Stage 1 — Initiation
A CAPA record opens when a quality event is identified. The record captures the event description, its source (deviation, audit finding, inspection observation, risk signal, or complaint), the risk level (Low, Medium, High, or Critical), and the assigned owner. A CAPA number is generated automatically — in the format CAPA-YYYY-NNNN — and the lifecycle clock starts.
Risk level determines the response timeline:
| Risk Level | Target Closure |
|---|---|
| Low | 90 days |
| Medium | 60 days |
| High | 30 days |
| Critical | 30 days — dual sign-off required |
Source linkage is established at initiation. If the CAPA originates from a deviation record or audit finding, the source record ID is captured and a reciprocal link is created — the CAPA shows where it came from, and the source record shows which CAPA was raised against it. During an inspection, either record can be used to navigate to the other.
A QA Lead reviewing a deviation can answer two questions immediately: has a CAPA been raised, and what stage is it at. That traceability does not exist in a spreadsheet-based process.
Stage 2 — Investigation
The assigned investigator documents the findings and context of the quality event. The objective at this stage is to gather sufficient information to conduct a meaningful root cause analysis — not to jump to conclusions about what caused the problem before the evidence has been examined.
Good investigation documentation captures: what was found, when it was found, which study and site are affected, which records or processes are implicated, what the immediate impact on subject safety or data integrity was, and what supporting evidence has been gathered.
Evidence is attached directly to the investigation record — not emailed separately, not stored in a shared folder, not referenced in a note that says “see attached.” Every file uploaded is timestamped, attributed to the uploader, and locked after upload. The investigation record and its evidence are a single unit.
When the investigation is complete, the investigator submits for Root Cause Analysis. The CAPA advances to the next stage.
Stage 3 — Root Cause Analysis
Root cause analysis is the most consequential stage of the CAPA process. A superficial RCA produces an action plan that addresses the symptom rather than the cause. An action plan built on a superficial RCA will produce an action completed on time, evidence uploaded, and a CAPA closed — followed by the same quality event six months later.
Two structured methods are used in clinical trial CAPA programmes:
5-Why Analysis
Start with the observed problem and ask why it occurred. Take the answer and ask why that occurred. Repeat until the answer reveals a process, system, or governance failure rather than an individual’s error. A minimum of three iterations is required. The method is well-suited to process-related failures with a clear causal chain.
Example: A monitoring finding identifies a consent form signed after the participant’s first study visit.
- Why? The coordinator obtained consent at the wrong visit.
- Why? The coordinator was unaware the consent process required completion before any study procedure.
- Why? The site initiation training did not include a specific module on consent timing requirements.
- Why? The training plan was configured before the protocol amendment that changed the consent window, and was never updated.
- Why? There was no process for reviewing training content when protocol amendments were approved.
Root cause: Absence of a systematic review process for training content following protocol amendments.
A corrective action fixes the specific consent records. A preventive action introduces a protocol amendment review trigger into the training management process.
Fishbone (Ishikawa) Analysis
The Fishbone method maps potential causes across six clinical-specific categories: People, Process, Equipment/Technology, Environment, Measurement/Data, and Materials/Documentation. Each category is examined for contributing causes. The method is well-suited to complex events with multiple potential contributing factors across different operational areas.
Example: Repeated out-of-window visits at a multi-cohort study site.
- People: Coordinator unfamiliar with cohort-specific visit windows after a staff change
- Process: Visit window rules held in a separate spreadsheet, not reflected in the scheduling system
- Equipment/Technology: Scheduling system did not enforce window validation
- Environment: High participant volume during trial recruitment peak
- Measurement/Data: No automated alert for visits approaching window limits
- Materials/Documentation: Protocol visit schedule and the scheduling tool were maintained independently
Root cause: Visit window rules were maintained outside the scheduling system with no validation enforcement and no cross-referencing process after staff changes.
After the RCA method is complete, the analyst writes a root cause statement — a synthesis in plain language of what the analysis revealed. The root cause statement is the bridge between the analysis and the action plan. A QA Lead reviewing the record should be able to read the root cause statement and understand exactly what needs to change.
RCA content is submitted to the QA Lead for review. The QA Lead approves or returns with comments. Action planning does not begin until the RCA is approved.
Stage 4 — Action Planning
An approved RCA feeds directly into the action plan. Each action item is defined with a type (Corrective, Preventive, or Both), a detailed description, an assigned owner, and a due date on or before the CAPA target closure date.
Action items must be proportionate to the root cause. An action plan that responds to “absence of a systematic review process for training content” with “coordinator to retrain on consent requirements” has addressed the symptom, not the cause. The preventive action should introduce the missing review process — not repeat the training that the missing process allowed to go stale.
Contributing factors documented in the RCA inform the preventive actions. If the Fishbone analysis identified that a staff change exposed a gap in knowledge transfer processes, a preventive action targeting that knowledge transfer gap is expected — not optional.
For Critical CAPAs, the action plan requires dual approval: the QA Lead approves first, then the QA Director counter-signs. Dual approval ensures the most serious quality events receive senior oversight before implementation begins.
Stage 5 — Implementation
Action item owners execute their assigned tasks and upload evidence of completion against their specific item. Evidence is not a general note in the CAPA record — it is a file attached to the action item it documents.
An action item marked Complete without attached evidence or a documented explanation for why documentary evidence is unavailable fails basic data integrity requirements. The record needs to show that the action was taken, not just that someone believes it was.
The system monitors due dates and sends automated reminders at seven days, three days, and on the day of the deadline. If an action item is not completed by its due date, it is automatically flagged as Overdue. Overdue status triggers immediate notifications to the action owner and QA Lead, and the CAPA appears in the overdue column on the programme dashboard.
When all action items are Complete (or formally waived with QA Lead approval and documented justification), the CAPA advances to Effectiveness Verification.
Stage 6 — Effectiveness Verification
Completing all actions is not the same as resolving the problem. Effectiveness verification confirms that the actions worked — that the root cause has been addressed and the quality event is unlikely to recur.
A verification plan is created before verification begins. The plan defines measurable criteria for what ‘effective’ looks like, specifies the verification method (re-inspection, data review, record review), names the assigned verifier, and sets the scheduled verification date.
Verification criteria must be specific and measurable. “No further issues identified” is not a criterion. “Zero consent timing deviations identified in the 60-day post-action monitoring review, with training completion records confirmed for 100% of site staff with consent responsibilities” is a criterion. The difference matters under inspection: the first is subjective, the second is verifiable.
The verifier must be independent — specifically, a different person from the CAPA owner. The system enforces this. A QA Director who owns the CAPA cannot verify its own effectiveness.
Three outcomes are possible:
Pass — the actions were effective. The CAPA advances to Closure.
Fail — the actions were insufficient, or the root cause was misidentified. The CAPA automatically reopens at the Investigation stage. A new investigation note is created referencing the failed verification. The CAPA displays a ‘Reopened — Effectiveness Failure’ label and is counted separately in the repeat-finding rate metric on the programme dashboard.
Partial — some criteria were met but gaps remain. The QA Lead decides within five business days whether to add further action items or reclassify the outcome as Fail.
A failed effectiveness check is not a process failure. A failed effectiveness check that is quietly reclassified as a pass to close the record is.
Stage 7 — Closure and Electronic Signature
A Pass verification outcome opens the Closure stage. The QA Lead writes a closure summary that documents: what actions were taken, what effectiveness evidence was reviewed, and a confirmation that the root cause has been addressed. The summary must be substantive — a reader who has never seen the CAPA before should be able to understand the full story from the closure summary alone.
Closure is applied by electronic signature. The QA Lead re-authenticates (password confirmation — a session cookie is insufficient), selects a signature meaning statement, and confirms. The system records the signer’s full name, role, timestamp in UTC, meaning statement, and an SHA-256 checksum of the entire CAPA record at the moment of signing.
For Critical CAPAs, the QA Director counter-signs. Once all required signatures are applied, the CAPA status changes to Closed. No field in the record can be modified after closure. The SHA-256 checksum binding between the signature and the record state satisfies 21 CFR Part 11 §11.70 — signatures are linked to their records and cannot be transferred or detached.
A closed CAPA can be reopened, but only by a QA Director with explicit permission, a mandatory written justification, and a full audit trail entry recording who reopened it and why.
Who Uses CAPA Management and What Each Role Does
CAPA management is a cross-functional process. Multiple roles contribute at different stages, and the integrity of the outcome depends on each role performing its function within the system.
QA Specialist
The QA Specialist is the primary operational user of the CAPA process. Responsibilities include: raising the CAPA record, conducting the investigation, building and submitting the RCA, defining action items, and managing the implementation tracking phase. In many organisations, the QA Specialist also serves as the primary contact for action item owners who need guidance on evidence requirements.
QA Lead
The QA Lead holds the approval and oversight responsibilities within the CAPA process. Responsibilities include: reviewing and approving (or returning) the RCA, approving the action plan, reviewing implementation evidence, defining the effectiveness verification plan, and applying the closure e-signature. The QA Lead is the quality gatekeeper at every stage where the process advances.
QA Director
The QA Director carries senior accountability for the CAPA programme. For Critical CAPAs, the QA Director counter-signs the action plan approval and the closure signature. The QA Director also holds the authority to reopen a closed CAPA and to assign a verification verifier when the standard verifier is unavailable. At programme level, the QA Director monitors the dashboard metrics — on-time closure rate, repeat-finding rate, overdue CAPA count — and is accountable for programme health to sponsors and regulators.
Action Item Owners
Action item owners are the individuals responsible for executing specific actions within the approved plan. They may be QA staff, site coordinators, investigators, training managers, or process owners — whoever is best placed to complete the specific task. Their responsibilities are: update the action item status as work progresses, upload evidence of completion against their item, and meet their assigned due date.
Investigators and Site Staff
Site staff are frequently the source of the quality events that generate CAPAs and are often involved as action item owners when the corrective action requires changes to site practice, training, or procedure. Site coordinators in particular are critical to the implementation stage — the quality of their evidence uploads determines whether the closure record is defensible.
Sponsors and Sponsor Oversight Teams
Sponsors receive visibility into CAPA programme health as part of ongoing oversight. For CAPAs originating from monitoring visits or sponsor audits, sponsors may have direct review rights to the CAPA record. The programme dashboard and exportable PDF reports give sponsor oversight teams what they need for governance review without requiring access to every individual record.
Regulatory Affairs Managers
Regulatory Affairs teams use CAPA records when preparing inspection response packages. A formal inspection observation response that can point to a specific CAPA number, show the root cause identified, list the actions completed with evidence, and confirm effectiveness verified and closure signed — with a full audit trail — is a materially stronger response than one assembled from emails and meeting notes.
CAPA and Root Cause Analysis in Clinical Trials
Root cause analysis in clinical research carries specific operational constraints that generic RCA frameworks do not account for.
Clinical trials run across multiple sites with different staffing, training levels, and local procedures. A root cause identified at one site may reflect a systemic issue across all sites, or may be site-specific. The RCA needs to be sensitive to this distinction — an action plan calibrated to one site’s practice gap will fail effectiveness verification if the underlying cause is a protocol-level ambiguity affecting all sites.
Clinical trials also operate under protocol constraints. Some findings reflect protocol design issues rather than operational failures. A consent window that is operationally difficult to achieve generates deviations at every site. A root cause analysis that attributes repeated consent deviations to “coordinator error” when the protocol window is genuinely unworkable produces action plans that train coordinators to perform an impossible task — and fail effectiveness checks repeatedly.
The most important discipline in clinical trial RCA is separating the stated cause from the structural cause. A delegation log gap is stated as “coordinator failed to update the log.” The structural cause may be that the delegation log lives in a separate system from the visit schedule, nobody owns the task of updating it after each visit, and there is no automated prompt when a new activity is performed. Correcting the individual log entry without addressing the structural cause produces another gap at the next visit.
Contributing factors matter separately from the root cause. A staff change, a site recruitment peak, a technology limitation, an SOP that has not been reviewed since the protocol amendment — each may be a contributing factor rather than the primary cause. Preventive actions targeted at contributing factors reduce the risk of recurrence even when the root cause is addressed, because contributing factors lower the threshold for the same type of failure.
How CAPA Connects to Deviations, Audits, and the QMS
CAPA management does not operate in isolation. In a structured quality programme, CAPA is the resolution layer that connects directly to the systems that identify quality events.
CAPA and Deviations
Protocol deviations are the most common source of CAPAs in clinical research. A Minor deviation may be managed and documented without a formal CAPA. A Major or Critical deviation should generate a CAPA. The CAPA record is linked to the deviation record — the deviation shows which CAPA was raised, and the CAPA shows which deviation prompted it.
For high-severity deviations, the linkage is bidirectional and traceable. An inspector reviewing a Critical deviation can navigate directly to the CAPA. An inspector reviewing a CAPA can verify that the source deviation exists, was properly classified, and is accurately described in the CAPA initiation record.
CAPA and Audit Findings
Audit findings — from internal QA audits, sponsor audits, or external regulatory inspections — generate CAPAs when the finding warrants formal corrective or preventive action. The audit finding record links to the CAPA, and the CAPA response forms part of the audit closeout evidence.
Inspectors and auditors routinely track findings across audit cycles. An organisation that raises a CAPA for an audit finding, completes the actions, verifies effectiveness, and closes the record with evidence demonstrates that audit findings are resolved — not merely acknowledged.
CAPA and the QMS
The Quality Management System controls document governance, SOP control, training management, and quality oversight processes. CAPA management is the resolution component of the QMS — the process through which quality events identified within the QMS are formally addressed.
Preventive actions frequently involve QMS elements: updating an SOP, adding a training module, revising a quality procedure, or creating a new oversight check. When a preventive action modifies a controlled document, that modification should be processed through the QMS document control workflow — not handled outside the system and referenced in the CAPA as “SOP updated.”
In a connected quality programme, the CAPA that identifies an SOP gap triggers the QMS document control process that produces the updated SOP, and the updated SOP is evidenced in the CAPA implementation record. Every step is in the same system. Every step is traceable.
What a CAPA System Needs to Do in Regulated Research?
A spreadsheet can record CAPA activity. A shared folder can store CAPA documents. An email thread can constitute an approval record. None of these satisfy the requirements for a controlled, inspection-ready CAPA programme.
A CAPA system built for regulated clinical research needs to meet specific operational and regulatory requirements.
Enforced lifecycle gates. Each stage of the CAPA lifecycle must be a genuine gate — not a label change that the user controls. The RCA section should be locked until the investigation is submitted. The action plan should be locked until the RCA is approved. Effectiveness verification should be inaccessible until all actions are complete. The system should enforce these gates, not rely on the user to follow the process.
Field-level audit trails. Every change to every field must be logged — what changed, from what to what, by whom, and when. The audit trail must be tamper-evident and accessible to inspectors without requiring the QA team to export and compile records manually.
Structured RCA tools. An RCA that lives in a Word document attached to the CAPA record is a document, not a system. The 5-Why chain and the Fishbone diagram should be built inside the CAPA record, with each iteration and each cause category logged as structured data — not as free text in an attachment that the system cannot interrogate.
Role-based workflow routing. Approvals, reviews, and counter-signatures should route automatically to the right person based on their role and the CAPA risk level. A QA Lead approval that is obtained by emailing a PDF and waiting for a reply is not a system-controlled approval — it is a manual process with no enforcement.
Electronic signatures aligned to 21 CFR Part 11. Closure signatures must capture signer identity, role, timestamp, meaning statement, and a record integrity checksum. Re-authentication at the point of signing is required. Signatures must be bound to the record state at the time of signing in a way that cannot be detached or transferred.
Dashboard and programme metrics. The CAPA programme produces meaningful metrics only if the data is structured and the system calculates them automatically. On-time closure rate, repeat-finding rate, overdue CAPA count, average closure time, and CAPA distribution by stage and risk level should be available without manual calculation.
Exportable inspection-ready records. A closed CAPA should be exportable as a complete PDF — all stages, all evidence, all signatures, all audit trail entries — watermarked and dated, suitable for inclusion in an inspection response package without manual compilation.
CAPA Management vs Spreadsheet-Based Tracking
Many clinical research organisations still manage CAPAs in spreadsheets. The operational and compliance limitations are structural, and they compound as the programme grows.
| Aspect | CAPA Management System | Spreadsheet Tracking |
|---|---|---|
| Lifecycle gates | System-enforced — stages unlock when conditions are met | Manual — dependent on user discipline |
| Audit trail | Field-level, tamper-evident, automatic | None — version history at best |
| RCA tools | Structured 5-Why and Fishbone built into the record | Free text or attached document |
| Approval workflow | Routed automatically to the correct approver by role | Email-based, no enforcement |
| Electronic signatures | 21 CFR Part 11 aligned with re-authentication and record checksum | No signature capability |
| Overdue alerts | Automatic, escalating notifications | Manual calendar reminders |
| Programme metrics | Calculated automatically from live data | Manually compiled from individual records |
| Evidence management | Attached directly to action items, timestamped, locked | Separate folder, no attribution |
| Inspection readiness | Exportable complete record at any time | Manual compilation from multiple files |
| Scalability | Multi-study, multi-site, multi-CAPA without performance loss | Degrades rapidly with volume |
The compliance risk in a spreadsheet-based programme is cumulative. Each individual record may appear complete. The programme cannot demonstrate, across the full portfolio, that every CAPA was gated correctly, that every approval was obtained before implementation began, and that every closure was signed before the target date.
CAPA in Inspection Scenarios — What Regulators Ask
MHRA inspectors, FDA investigators, and sponsor audit teams ask specific questions about CAPA programmes. The answers need to come from the system, not from the QA team’s memory.
“Show me the CAPA raised for the consent deviation identified during the last monitoring visit.”
The system should navigate directly from the deviation record to the linked CAPA, or from the CAPA to the source deviation. Both records display the reciprocal link. The inspector should be able to verify the linkage without the QA team explaining it.
“Who approved this action plan and when?”
The approval history shows the QA Lead approval with name, role, timestamp, and — for Critical CAPAs — the QA Director counter-signature. The audit trail records each approval event independently.
“Was the root cause analysis ever returned for revision?”
The audit trail shows every RCA submission event, every return event with the reviewer’s comment, and every resubmission. The history of the RCA development is part of the record.
“How do you verify that the corrective action was effective?”
The verification plan shows the criteria, the method, the scheduled date, and the assigned verifier. The verification outcome shows the observations, the evidence, and the outcome selected. For a Pass, the record shows why the team concluded the action worked. For a Fail, the record shows that the CAPA was reopened.
“Can the person who owned the CAPA also verify its effectiveness?”
The system blocks this. The verifier cannot be the CAPA owner. The inspector can confirm this is a system control, not a convention.
“What is your on-time closure rate for the last 12 months?”
The dashboard calculates and displays the metric for any selected date range. The export produces a PDF report stamped with the date, applied filters, and calculation basis — suitable for inclusion in the inspection response.
How AQ CAPA Works?
AQ CAPA is the issue resolution module within the AQ clinical research platform. It provides a structured, gated workflow for the full CAPA lifecycle — from initiation through investigation, RCA, action planning, approval, implementation, verification, and closure — with every stage built into the system rather than managed around it.
The AQ CAPA Interface
Every CAPA record in AQ displays the full lifecycle stepper at the top of the record. The current stage is highlighted. Completed stages show a green tick. Future stages are locked until their gate conditions are met. QA staff can see exactly where a CAPA sits in its lifecycle at a glance — no status meetings required.
The Activity Log panel is visible on the right side of every CAPA record throughout the lifecycle. Every action — field change, submission, approval, evidence upload, status transition — is recorded in real time with the actor’s name and timestamp. The full programme audit log captures the same data across all CAPA records in a searchable, filterable view.
AQ CAPA Dashboard
The CAPA Dashboard gives QA Directors and QA Leads a real-time portfolio view:
- Open CAPA count — active workflows across all stages
- Overdue CAPA tile — CAPAs past their target closure date, flagged for immediate attention
- Closed CAPA (this quarter) — quarterly closure performance
- Avg Closure Time — rolling 90-day average from creation to closure
- CAPA Created vs Closed (30 Days) — line chart showing whether the programme is resolving CAPAs faster than new ones are raised
- Overdue vs On-Time donut chart — proportion of closures meeting their target date
- CAPA by Stage — count of open CAPAs at each lifecycle stage
Filters apply across all dashboard widgets simultaneously — by risk level, status, source type, and date range. The dashboard exports to PDF on demand, stamped with the exporting user, applied filters, and timestamp.
AQ CAPA List
The CAPA List is the full registry of all active records. Every CAPA is visible with its ID, title, source, risk level, status badge, owner, and creation date. The list is searchable, sortable by any column, and filterable by risk level, status, source type, and personal scope (My CAPAs only). Export to Excel is available from the Actions dropdown for data analysis.
The Removed CAPA List preserves every removed record with a full removal audit trail — who removed it, when, and with what justification. CAPA numbers are never reused. Every number ever generated is accountable, either in the active list or in the removed list with a documented reason.
Investigation Stage
The assigned investigator documents findings and context using a rich text editor. Evidence is attached directly to the investigation — not stored separately. Every uploaded file is timestamped, attributed, and locked after upload. The SHA-256 checksum of each file is stored at upload time and can be recalculated on demand to verify the file has not been altered.
Root Cause Analysis in AQ CAPA
The 5-Why tool and Fishbone diagram are built directly into the CAPA record. Neither is an attached document — both are structured data within the system.
The 5-Why tool supports a minimum of three iterations and a maximum of seven, with branching capability for causes that split into parallel pathways. Each ‘why’ is a text entry, and the chain structure is preserved in the record.
The Fishbone tool provides six clinical-specific cause categories: People, Process, Equipment/Technology, Environment, Measurement/Data, and Materials/Documentation. Cause statements are added to any category. The categories are fixed — ensuring consistent structure across all CAPA records and enabling analysis across the programme.
The root cause statement is a separate mandatory field. The system does not auto-populate it from the RCA tool output. The analyst writes the synthesis. The discipline of writing the root cause statement in plain language is part of the analytical process.
RCA content is submitted to the QA Lead for review. The full RCA — 5-Why chain, Fishbone entries, root cause statement, and contributing factors — is included in the approval snapshot and is locked once approved. Any post-approval amendment creates a new RCA version and preserves the original.
Action Planning and Approval
Action items are created within the CAPA record with type, description, owner, and due date. The system validates due dates against the CAPA target closure date and warns if an action item deadline exceeds it.
Approval routing is risk-level dependent and automatic. Low, Medium, and High CAPAs route to the QA Lead for single approval. Critical CAPAs route to the QA Lead first, then to the QA Director for counter-signature. If the QA Director counter-signature is not completed within five business days, an escalation notification is sent automatically.
Implementation Tracking
Action item owners receive task notifications when the plan is approved. AQ’s My CAPA Tasks view gives every user a personal queue of all assigned action items across all CAPAs, with due dates, status, and direct links to the parent records.
Automated reminders fire at seven days, three days, and on the due date. If the item is not completed by its due date, the system marks it Overdue at 00:05 UTC the following day and sends immediate notifications to the owner and QA Lead. Overdue status cannot be manually cleared — it clears only when the item is marked Complete.
Evidence is attached directly to the action item it documents. QA Leads can review evidence without navigating away from the CAPA record.
Effectiveness Verification
AQ enforces the independence requirement at the system level — the verifier cannot be the CAPA owner. The verification plan is created before verification is executed, with specific criteria, a named method, an assigned verifier, and a scheduled date.
Verification outcome choices are Pass, Fail, and Partial. A Fail outcome automatically reopens the CAPA at the Investigation stage, creates a new investigation note referencing the failed verification, and flags the CAPA with a ‘Reopened — Effectiveness Failure’ banner. Reopened CAPAs are tracked separately in the repeat-finding rate metric.
Closure and Electronic Signature
Closure signatures in AQ capture signer name, role, timestamp in UTC, selected meaning statement, and SHA-256 checksum of the full CAPA record at the moment of signing. Re-authentication is required at the point of signing — a session cookie is not sufficient. After five failed authentication attempts, the user session is locked.
Once all required signatures are applied, the CAPA record is immutably closed. The full-record PDF export is available at any time — watermarked with the closure date, containing all stages, evidence, and signatures, with the SHA-256 record integrity checksum included. The PDF is suitable for direct inclusion in inspection response packages.
AQ CAPA and Connected Quality Operations
AQ CAPA is one module within the AQ clinical research platform. CAPAs raised from deviations within AQ CTMS carry the source linkage automatically. CAPAs connected to document non-conformances link to AQ eISF or ePSF records. Preventive actions that modify controlled documents connect to AQ QMS workflows. Delegation log gaps identified through AQ Digital DoA feed into CAPAs with source attribution already in place.
The control chain — CTMS → eISF → ePSF → QMS → CAPA → Digital DoA — means that quality events arising anywhere in the clinical research workflow trace back through the system to their origin. An inspector following the thread from a site audit finding to the CAPA to the QMS document change to the updated training record stays within one platform throughout. There is no gap in the chain where a document lives outside the system and its connection to the quality event has to be explained rather than demonstrated.
Why Does AQ CAPA Stands Out?
The majority of CAPA tools are generic quality management applications adapted for clinical research. But… AQ CAPA is designed around the specific workflows, regulatory requirements, and operational realities of clinical trials.
Gated lifecycle enforcement. Every stage transition is a system gate, not a status label. The RCA section is locked until the investigation is submitted. Action planning is locked until the RCA is approved. Verification is locked until implementation is complete. The system enforces the process — user discipline is not the control.
Clinical-specific RCA structure. The Fishbone categories are clinical trial-specific: People, Process, Equipment/Technology, Environment, Measurement/Data, Materials/Documentation. Generic quality tools use manufacturing-derived categories that do not map to clinical research root causes. AQ’s categories reflect the operational environment where the causes actually occur.
Source linkage with reciprocal visibility. CAPAs raised from other AQ modules carry automatic bidirectional linkage. The source record and the CAPA record are permanently connected. An inspector can navigate in either direction. The linkage is not a text reference — it is a system relationship that survives record updates, module changes, and archive events.
21 CFR Part 11 aligned closure. The SHA-256 checksum binding satisfies §11.70’s requirement for signatures that are linked to their records and cannot be excised, copied, or transferred. The meaning statement, re-authentication requirement, and denormalised signer identity fields satisfy §11.50. The signature architecture is documented in the system CSV documentation and Platform Validation Summary Report.
Programme-level visibility. The dashboard gives QA Directors the metrics that matter — on-time closure rate, repeat-finding rate, overdue CAPA count, average closure time — calculated automatically from live data. For an inspection, the programme health report is a PDF export, not a manual compilation exercise.
Connected to the quality programme. AQ CAPA does not operate as a standalone tool. Resolved issue state feeds into QMS, audit, and governance oversight. A CAPA that changes a controlled document updates the QMS record. A CAPA that modifies a training requirement updates the training record. The quality programme reflects the resolution — because the resolution happened within the programme, not outside it.
Summary
CAPA management in clinical research is the difference between a quality programme that records problems and one that resolves them. A well-structured CAPA process captures quality events at source, investigates them properly, defines actions that address root cause rather than symptom, confirms those actions were executed with evidence, and verifies the outcome before the record closes.
It should be clear that clinical research regulators do not expect organisations to run perfect trials. In fact, they expect organisations to maintain control — to identify what went wrong, understand why, fix it properly, and demonstrate that the fix held. A functioning CAPA programme is the evidence of that control.
AQ CAPA gives quality teams the system infrastructure to run that programme: structured lifecycle enforcement, built-in RCA tools, role-based approval routing, implementation tracking with automated oversight, independence-enforced verification, and 21 CFR Part 11 aligned closure. All connected to the full AQ clinical research platform so that every quality event traces back through the system to its source.
Request a live demo to see how AQ CAPA supports structured issue resolution, connected quality oversight, and inspection-ready traceability across your clinical research programme.
