# QMS CAPA Tracker > 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. Tags: Healthcare, Quality Management, Regulatory, ISO 13485, FDA, Compliance ## Example Prompts - Create a CAPA report for a nonconformity found during incoming inspection - Perform a 5 Whys root cause analysis on a customer complaint about device malfunction - Validate our CAPA report for closure readiness before the next audit URL: https://rakenne.app/skills/qms-capa-tracker/index.md Try this skill: https://rakenne.app/a/?skill=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 | Phase | Regulatory Ref. | Status | |-------|----------------|--------| | Problem Identification / Description | ISO §8.5.2(a) / FDA §820.90(a)(1) | ✓ | | Source Data / Input Sources | ISO §8.5.2(b) / FDA §820.90(a)(2) | ✓ | | Investigation / Root Cause Analysis | ISO §8.5.2(c) / FDA §820.90(a)(3) | ✓ | | Corrective Action(s) | ISO §8.5.2(d) / FDA §820.90(a)(4) | ✓ | | Preventive Action(s) | ISO §8.5.3(d) / FDA §820.90(b)(4) | ✓ | | Implementation / Action Execution | ISO §8.5.2(e) / FDA §820.90(a)(5) | ✓ | | Effectiveness Check / Verification | ISO §8.5.2(f) / FDA §820.90(a)(6) | ✓ | | Management Review Input | ISO §5.6.2 / FDA §820.90(a)(7) | ✓ | | CAPA Closure / Sign-off | ISO §4.2.4 / FDA §820.90 | ✓ | #### Effectiveness Check & Timeline | Check | Result | |-------|--------| | Effectiveness Check section present | PASS | | Effectiveness date (2025-09-15) after implementation (2025-06-15) | PASS — 92 days | | Effectiveness date before closure date (2025-09-30) | PASS | | Measurable acceptance criteria defined | PASS — "zero recurrences within 90 days" | **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 | Check Category | `capa_structure_validator` | `capa_closure_enforcer` | |---------------|:-------------------------:|:----------------------:| | **CAPA phase coverage (9 phases)** | All required phases per ISO 13485 §8.5.2/§8.5.3 and FDA §820.90 | — | | **Root cause methodology detection** | 5 Whys, Fishbone/Ishikawa, FMEA, Fault Tree, Pareto, 8D | — | | **Regulatory references** | ISO 13485, FDA 21 CFR 820, ISO 14971, ICH Q10 | — | | **Risk assessment linkage** | Risk level, ISO 14971 risk file reference | — | | **Document control fields** | CAPA number, report identifier | — | | **Effectiveness Check presence** | — | Section exists with date and criteria | | **Timeline logic** | — | Effectiveness date after implementation, before closure | | **Effectiveness window adequacy** | — | ≥30 days (warns if too short for meaningful data) | | **Extended lifecycle detection** | — | Flags CAPAs open >12 months | | **Effectiveness results** | — | Results documented (effective / not effective) | | **Recurrence monitoring** | — | Post-implementation recurrence tracking | | **Unfilled placeholders** | Flags remaining markers | Flags remaining markers | ### 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. --- Back to [Skill Library](https://rakenne.app/skills/index.md)