QMS CAPA Tracker

Overview

Draft and validate CAPA (Corrective and Preventive Action) reports for medical device quality management systems. Standardizes root cause analysis using 5 Whys or Fishbone (Ishikawa) methods, enforces Effectiveness Check completeness, and validates CAPA structure against ISO 13485 and FDA 21 CFR Part 820 requirements.

A missing or poorly documented Effectiveness Check is the #1 CAPA audit finding worldwide — across ISO 13485, FDA QSR, and MDSAP audits. This skill targets the three areas that generate the most regulatory citations:

• Root cause analysis depth — Guides 5 Whys or Fishbone (Ishikawa) investigations and rejects shallow root causes like “operator error” without systemic analysis.
• Effectiveness Check enforcement — Validates that the Effectiveness Check phase exists, has measurable acceptance criteria, and has a logically sequenced deadline (after implementation, before closure, with adequate data collection time).
• CAPA phase completeness — Checks all 9 required phases per ISO 13485 §8.5.2/§8.5.3 and FDA 21 CFR 820.90, including management review input and risk assessment linkage.

Getting Started

Add any existing CAPA documentation, nonconformity records, complaint files, or audit findings to the project workspace. Then activate the QMS CAPA Tracker skill. The agent will guide you through CAPA creation from problem identification through root cause analysis, action planning, effectiveness verification, and closure — or validate an existing report for completeness.

Example Conversation

Below is an example of how a typical CAPA elaboration session unfolds. The agent scopes the problem, guides root cause analysis, builds the report, and validates it for closure readiness.

You: We received three customer complaints this quarter about our Class II infusion pump — the flow rate alarm triggers at the wrong threshold. Lot numbers are 2025-0412, 2025-0419, and 2025-0423. We need to open a CAPA.

Agent: I’ll guide you through the CAPA report following ISO 13485 §8.5.2 and FDA §820.90 requirements. Let me confirm a few details:

1. Source data: Are all three complaints documented in your complaint handling system? I’ll need the complaint record numbers to link in the CAPA.
2. Risk level: Has the incorrect alarm threshold caused any patient harm or near-miss events? This determines whether we need to flag a reportable event and update the ISO 14971 risk file.
3. Scope: Is the alarm threshold set in firmware, configured during manufacturing, or user-adjustable? This helps determine whether the CAPA scope is design, process, or both.

You: Yes, complaints CR-2025-087, CR-2025-091, and CR-2025-094. No patient harm reported — the alarm triggers too early (at 80% of set rate instead of 95%), so it’s a nuisance alarm, not a safety issue. The threshold is configured during firmware flashing at final assembly.

Agent: Good — nuisance alarm with no patient harm. I’ll classify this as a Major (non-critical) CAPA. Since the threshold is set during firmware flashing, the investigation will focus on the manufacturing process.

I’ve created the CAPA report from the template at output/capa-report.md with the administrative information and complaint linkage filled in. Now let’s investigate the root cause. Given that three lots are affected, this could be a systemic issue — I recommend the 5 Whys method since the failure chain appears to be singular (firmware parameter → alarm behavior).

Problem statement: Infusion pump flow rate alarm triggers at 80% of set rate instead of the specified 95% threshold, affecting lots 2025-0412, 2025-0419, and 2025-0423.

Why 1: Why does the alarm trigger at 80% instead of 95%?

You: The alarm threshold parameter in the firmware configuration file was set to 0.80 instead of 0.95.

Agent: Why 2: Why was the parameter set to 0.80?

You: The operator used an outdated firmware configuration file (v2.3 instead of v2.5). Version 2.5 changed the threshold from 0.80 to 0.95 based on the design change order from last year.

Agent: Why 3: Why was the operator using the outdated configuration file?

You: Both file versions were stored in the same shared drive folder with similar filenames. There’s no version control system for firmware config files — operators select the file manually.

Agent: Why 4: Why is there no version control or selection check for firmware configuration files?

You: The firmware flashing SOP (WI-MFG-042) doesn’t specify which configuration file version to use — it just says “load the appropriate configuration file.” There’s no verification step to confirm the file version matches the device’s design history record (DHR).

Agent: That’s a strong root cause at the systemic level. Let me verify:

Root cause: SOP WI-MFG-042 lacks specificity for firmware configuration file selection — no version identifier tied to the DHR and no verification step after flashing. This allowed an outdated configuration file (v2.3 vs. required v2.5) to be used without detection.

This points to a process/documentation gap, not operator error. I’ve documented the full 5 Whys analysis with evidence fields in the report. Now I’ll draft the corrective and preventive actions.

Corrective actions:

1. Reflash all in-field units from affected lots with correct firmware configuration v2.5 (field correction)
2. Revise WI-MFG-042 to specify configuration file by version number linked to DHR, add post-flash verification step with documented check

Preventive actions:

1. Implement version-controlled firmware configuration repository with check-out/check-in process
2. Add automated firmware parameter verification to the final test protocol (compare flashed values against DHR specification)

For the Effectiveness Check, I recommend:

• Criteria: Zero alarm threshold nonconformities for 90 days after SOP revision and system implementation
• Date: 90 days after implementation completion, with weekly monitoring during the period

Shall I finalize these in the report?

You: Yes, that looks good. Finalize and validate.

Agent: I’ve completed the report and run both validation tools. The capa_structure_validator shows 9/9 CAPA phases covered. The capa_closure_enforcer shows the effectiveness check is properly sequenced — 90 days after implementation with measurable criteria. One warning: management review input date is still a placeholder. Once you fill that in and the effectiveness period completes, this CAPA will be ready for closure.

Sample Output Excerpt

Below is a representative excerpt from a CAPA validation report, showing phase coverage and root cause analysis results — the first things an auditor checks during a CAPA review.

CAPA Structure Validation — Infusion Pump Alarm Threshold

CAPA phases covered: 9 / 9 RCA methodology: 5 Whys Regulatory references: ISO 13485, FDA 21 CFR Part 820, ISO 14971

CAPA Phase Coverage

Effectiveness Check & Timeline

Result: PASS — CAPA report covers required phases and the effectiveness check timeline is properly sequenced.

Built-in Validation Tools

The skill includes two extension tools that automate the most audit-sensitive validations in CAPA review.

What the tools check

Severity levels

• ERROR — A missing CAPA phase, absent effectiveness check, or illogical deadline that must be resolved before CAPA closure or regulatory audit.
• WARNING — A potential gap such as missing regulatory references, short effectiveness window, or absent management review input that should be reviewed.
• INFO — Unfilled placeholders, detected RCA methodology, informational notes about timeline adequacy.

Example validation output

======================================================================
CAPA CLOSURE ENFORCEMENT REPORT
ISO 13485 / FDA 21 CFR Part 820
======================================================================
Document: output/capa-report.md
Content size: 12,450 chars
Dates found: 8

--- EFFECTIVENESS CHECK & TIMELINE ---
  [INFO] Effectiveness Check date found: 2025-09-15 (line 142).
  [INFO] Effectiveness window: 92 day(s) between implementation
         and effectiveness check — adequate.
  [INFO] Effectiveness Check date is before CAPA closure date
         (2025-09-30) — PASS.

--- COMPLETENESS ---
  [WARNING] Effectiveness Check section exists but no results/outcomes
            documented. If the effectiveness check has been performed,
            document the results and conclusion.

--- SUMMARY ---
  Dates found:  8
  Errors:   0
  Warnings: 1
  Info:     3

RESULT: REVIEW NEEDED — address warnings to strengthen the CAPA
        record before closure.
======================================================================

The agent runs both tools sequentially — first the capa_structure_validator for phase completeness and regulatory compliance, then the capa_closure_enforcer for effectiveness check and timeline verification — and surfaces findings inline so you can resolve issues before audit.