Capa Officer

CAPA Officer

Corrective and Preventive Action (CAPA) management within Quality Management Systems, focusing on systematic root cause analysis, action implementation, and effectiveness verification.

---

Table of Contents

• CAPA Investigation Workflow
• Root Cause Analysis
• Corrective Action Planning
• Effectiveness Verification
• CAPA Metrics and Reporting
• Reference Documentation
• Tools

---

CAPA Investigation Workflow

Conduct systematic CAPA investigation from initiation through closure:

1. Document trigger event with objective evidence 2. Assess significance and determine CAPA necessity 3. Form investigation team with relevant expertise 4. Collect data and evidence systematically 5. Select and apply appropriate RCA methodology 6. Identify root cause(s) with supporting evidence 7. Develop corrective and preventive actions 8. Validation: Root cause explains all symptoms; if eliminated, problem would not recur

CAPA Necessity Determination

Investigation Team Composition

Evidence Collection Checklist

• [ ] Problem description with specific details (what, where, when, who, how much)
• [ ] Timeline of events leading to issue
• [ ] Relevant records and documentation
• [ ] Interview notes from involved personnel
• [ ] Photos or physical evidence (if applicable)
• [ ] Related complaints, NCs, or previous CAPAs
• [ ] Process parameters and specifications

---

Root Cause Analysis

Select and apply appropriate RCA methodology based on problem characteristics.

RCA Method Selection Decision Tree

Is the issue safety-critical or involves system reliability?
├── Yes → Use FAULT TREE ANALYSIS
└── No → Is human error the suspected primary cause?
    ├── Yes → Use HUMAN FACTORS ANALYSIS
    └── No → How many potential contributing factors?
        ├── 1-2 factors (linear causation) → Use 5 WHY ANALYSIS
        ├── 3-6 factors (complex, systemic) → Use FISHBONE DIAGRAM
        └── Unknown/proactive assessment → Use FMEA

5 Why Analysis

Use when: Single-cause issues with linear causation, process deviations with clear failure point.

Template:

PROBLEM: [Clear, specific statement]

WHY 1: Why did [problem] occur?
BECAUSE: [First-level cause]
EVIDENCE: [Supporting data]

WHY 2: Why did [first-level cause] occur?
BECAUSE: [Second-level cause]
EVIDENCE: [Supporting data]

WHY 3: Why did [second-level cause] occur?
BECAUSE: [Third-level cause]
EVIDENCE: [Supporting data]

WHY 4: Why did [third-level cause] occur?
BECAUSE: [Fourth-level cause]
EVIDENCE: [Supporting data]

WHY 5: Why did [fourth-level cause] occur?
BECAUSE: [Root cause]
EVIDENCE: [Supporting data]

Example - Calibration Overdue:

PROBLEM: pH meter (EQ-042) found 2 months overdue for calibration

WHY 1: Why was calibration overdue?
BECAUSE: Equipment was not on calibration schedule
EVIDENCE: Calibration schedule reviewed, EQ-042 not listed

WHY 2: Why was it not on the schedule?
BECAUSE: Schedule not updated when equipment was purchased
EVIDENCE: Purchase date 2023-06-15, schedule dated 2023-01-01

WHY 3: Why was the schedule not updated?
BECAUSE: No process requires schedule update at equipment purchase
EVIDENCE: SOP-EQ-001 reviewed, no such requirement

WHY 4: Why is there no such requirement?
BECAUSE: Procedure written before equipment tracking was centralized
EVIDENCE: SOP last revised 2019, equipment system implemented 2021

WHY 5: Why has procedure not been updated?
BECAUSE: Periodic review did not assess compatibility with new systems
EVIDENCE: No review against new equipment system documented

ROOT CAUSE: Procedure review process does not assess compatibility
with organizational systems implemented after original procedure creation.

Fishbone Diagram Categories (6M)

See references/rca-methodologies.md for complete method details and templates.

Root Cause Validation

Before proceeding to action planning, validate root cause:

• [ ] Root cause can be verified with objective evidence
• [ ] If root cause is eliminated, problem would not recur
• [ ] Root cause is within organizational control
• [ ] Root cause explains all observed symptoms
• [ ] No other significant causes remain unaddressed

---

Corrective Action Planning

Develop effective actions addressing identified root causes:

1. Define immediate containment actions 2. Develop corrective actions targeting root cause 3. Identify preventive actions for similar processes 4. Assign responsibilities and resources 5. Establish timeline with milestones 6. Define success criteria and verification method 7. Document in CAPA action plan 8. Validation: Actions directly address root cause; success criteria are measurable

Action Types

Action Plan Components

ACTION PLAN TEMPLATE

CAPA Number: [CAPA-XXXX]
Root Cause: [Identified root cause]

ACTION 1: [Specific action description]
- Type: [ ] Containment [ ] Correction [ ] Corrective [ ] Preventive
- Responsible: [Name, Title]
- Due Date: [YYYY-MM-DD]
- Resources: [Required resources]
- Success Criteria: [Measurable outcome]
- Verification Method: [How success will be verified]

ACTION 2: [Specific action description]
...

IMPLEMENTATION TIMELINE:
Week 1: [Milestone]
Week 2: [Milestone]
Week 4: [Milestone]
Week 8: [Milestone]

APPROVAL:
CAPA Owner: _____________ Date: _______
Process Owner: _____________ Date: _______
QA Manager: _____________ Date: _______

Action Effectiveness Indicators

---

Effectiveness Verification

Verify corrective actions achieved intended results:

1. Allow adequate implementation period (minimum 30-90 days) 2. Collect post-implementation data 3. Compare to pre-implementation baseline 4. Evaluate against success criteria 5. Verify no recurrence during verification period 6. Document verification evidence 7. Determine CAPA effectiveness 8. Validation: All criteria met with objective evidence; no recurrence observed

Verification Timeline Guidelines

Verification Methods

Effectiveness Determination

Did recurrence occur during verification period?
├── Yes → CAPA INEFFECTIVE (re-investigate root cause)
└── No → Were all effectiveness criteria met?
    ├── Yes → CAPA EFFECTIVE (proceed to closure)
    └── No → Extent of gap?
        ├── Minor gap → Extend verification or accept with justification
        └── Significant gap → CAPA INEFFECTIVE (revise actions)

See references/effectiveness-verification-guide.md for detailed procedures.

---

CAPA Metrics and Reporting

Monitor CAPA program performance through key indicators.

Key Performance Indicators

Aging Analysis Categories

Management Review Inputs

Monthly CAPA status report includes:

• Open CAPA count by severity and status
• Overdue CAPA list with owners
• Cycle time trends
• Effectiveness rate trends
• Source analysis (complaints, audits, NCs)
• Recommendations for improvement

---

Reference Documentation

Root Cause Analysis Methodologies

references/rca-methodologies.md contains:

• Method selection decision tree
• 5 Why analysis template and example
• Fishbone diagram categories and template
• Fault Tree Analysis for safety-critical issues
• Human Factors Analysis for people-related causes
• FMEA for proactive risk assessment
• Hybrid approach guidance

Effectiveness Verification Guide

references/effectiveness-verification-guide.md contains:

• Verification planning requirements
• Verification method selection
• Effectiveness criteria definition (SMART)
• Closure requirements by severity
• Ineffective CAPA process
• Documentation templates

---

Tools

CAPA Tracker

# Generate CAPA status report
python scripts/capa_tracker.py --capas capas.json

# Interactive mode for manual entry
python scripts/capa_tracker.py --interactive

# JSON output for integration
python scripts/capa_tracker.py --capas capas.json --output json

# Generate sample data file
python scripts/capa_tracker.py --sample > sample_capas.json

Calculates and reports:

• Summary metrics (open, closed, overdue, cycle time, effectiveness)
• Status distribution
• Severity and source analysis
• Aging report by time bucket
• Overdue CAPA list
• Actionable recommendations

Sample CAPA Input

{
  "capas": [
    {
      "capa_number": "CAPA-2024-001",
      "title": "Calibration overdue for pH meter",
      "description": "pH meter EQ-042 found 2 months overdue",
      "source": "AUDIT",
      "severity": "MAJOR",
      "status": "VERIFICATION",
      "open_date": "2024-06-15",
      "target_date": "2024-08-15",
      "owner": "J. Smith",
      "root_cause": "Procedure review gap",
      "corrective_action": "Updated SOP-EQ-001"
    }
  ]
}

---

Regulatory Requirements

ISO 13485:2016 Clause 8.5

FDA 21 CFR 820.100

Required CAPA elements:

• Procedures for implementing corrective and preventive action
• Analyzing quality data sources (complaints, NCs, audits, service records)
• Investigating cause of nonconformities
• Identifying actions needed to correct and prevent recurrence
• Verifying actions are effective and do not adversely affect device
• Submitting relevant information for management review

Common FDA 483 Observations

---

Troubleshooting

---

Success Criteria

• First-time effectiveness rate exceeds 90% -- verified through post-implementation data collection showing no recurrence during the verification window
• Average CAPA cycle time under 60 days -- measured from open date to close date across all severity levels, tracked via capa_tracker.py metrics
• Overdue rate maintained below 10% -- monitored through aging analysis with escalation triggers at 61-day and 90-day thresholds
• 100% of root causes validated with objective evidence -- every root cause passes the validation checklist (explains all symptoms, elimination prevents recurrence, within organizational control)
• All critical and major CAPAs include preventive actions -- corrective actions address the specific occurrence while preventive actions extend solutions to analogous processes
• Management review receives monthly CAPA status reports -- including open count by severity, overdue list, cycle time trends, and effectiveness rate trends
• Recurrence rate below 5% -- tracked by monitoring closed CAPAs for reappearance of the same issue type within 12 months of closure

---

Scope & Limitations

In Scope:

• CAPA investigation workflow from trigger event through closure
• Root cause analysis using 5-Why, Fishbone (6M), Fault Tree Analysis, Human Factors Analysis, and FMEA methodologies
• Corrective and preventive action planning, implementation tracking, and effectiveness verification
• CAPA metrics calculation, aging analysis, and management reporting
• Alignment with ISO 13485:2016 Clause 8.5 and FDA 21 CFR 820.100 requirements

Out of Scope:

• This skill does not replace a validated eQMS (electronic Quality Management System) for production CAPA tracking -- it provides analysis templates and metric calculations
• Statistical process control and advanced trend analysis requiring specialized SPC software
• Regulatory submission preparation (use fda-consultant-specialist or mdr-745-specialist for submission-related CAPAs)
• Supplier CAPA management beyond internal investigation (use quality-manager-qms-iso13485 for supplier qualification)
• Clinical investigation CAPAs requiring medical/scientific expertise beyond procedural guidance

Important Notes:

• Under the FDA QMSR (effective February 2, 2026), CAPA requirements align with ISO 13485:2016 Clause 8.5 rather than the legacy 21 CFR 820.100 structure -- this skill covers both frameworks
• The capa_tracker.py tool works with JSON input and does not connect to live QMS databases; export data from your eQMS for analysis

---

Integration Points

---

Tool Reference

capa_tracker.py

Tracks CAPA status, calculates metrics, identifies overdue items, and generates management review reports.

Calculated Metrics:

• Total, open, closed, and overdue CAPA counts
• Average cycle time (days from open to close)
• First-time effectiveness rate (effective on first verification / total verified)
• Status distribution, severity breakdown, and source analysis
• Aging report bucketed by 0-30, 31-60, 61-90, and 90+ days
• Overdue CAPA list with owners and days past target

Example:

# Generate sample data, then analyze
python scripts/capa_tracker.py --sample > sample_capas.json
python scripts/capa_tracker.py --capas sample_capas.json
python scripts/capa_tracker.py --capas sample_capas.json --output json

Effectiveness Verification Guide

CAPA effectiveness assessment procedures, verification methods, and closure criteria.

---

Table of Contents

• Verification Planning
• Verification Methods
• Effectiveness Criteria
• Closure Requirements
• Ineffective CAPA Process
• Documentation Templates

---

Verification Planning

When to Plan Verification

Verification planning must occur BEFORE corrective action implementation:

Verification Timeline Guidelines

Rationale: Waiting period ensures sufficient data collection and accounts for process variation.

Verification Plan Components

VERIFICATION PLAN TEMPLATE

CAPA Number: [CAPA-XXXX]
Problem Statement: [Original issue]
Root Cause: [Identified root cause]
Corrective Action: [Implemented action]

VERIFICATION METHOD:
[ ] Data Trend Analysis
[ ] Process Audit
[ ] Record Review
[ ] Testing/Inspection
[ ] Interview/Observation
[ ] Multiple Methods (specify)

EFFECTIVENESS CRITERIA:
1. [Measurable criterion 1]
2. [Measurable criterion 2]
3. [Measurable criterion 3]

SUCCESS THRESHOLD:
- [Quantitative threshold, e.g., "Zero recurrence for 90 days"]
- [Qualitative threshold, e.g., "Procedure followed correctly 100%"]

DATA COLLECTION:
- Source: [Where data will come from]
- Sample Size: [Number of records/instances to review]
- Time Period: [Start and end dates]
- Responsible: [Who collects data]

VERIFICATION SCHEDULE:
- Implementation Complete: [Date]
- Waiting Period Ends: [Date]
- Verification Start: [Date]
- Verification Complete: [Date]
- Report Due: [Date]

APPROVAL:
CAPA Owner: _____________ Date: _______
Quality Assurance: _____________ Date: _______

---

Verification Methods

1. Data Trend Analysis

Best for: Quantifiable issues with measurable outcomes (defect rates, cycle times, complaint trends)

Procedure: 1. Collect post-implementation data for defined period 2. Compare to pre-implementation baseline 3. Apply statistical analysis if sample size permits 4. Document trend direction and magnitude

Example Criteria:

• Defect rate reduced by ≥50% from baseline
• Zero recurrence of specific failure mode
• Process capability (Cpk) improved to ≥1.33

Evidence Required:

• Pre-implementation baseline data
• Post-implementation trend data
• Statistical analysis (if applicable)
• Trend charts with annotation

2. Process Audit

Best for: Procedure compliance issues, process control failures, systemic problems

Procedure: 1. Develop audit checklist based on corrective action 2. Conduct unannounced process audit 3. Interview operators and supervisors 4. Review records generated since implementation 5. Document compliance percentage

Example Criteria:

• 100% compliance with revised procedure
• All operators demonstrate competency
• No deviations observed during audit

Evidence Required:

• Audit checklist completed
• Interview notes
• Record samples reviewed
• Photos/observations (if applicable)

3. Record Review

Best for: Documentation issues, completeness problems, traceability failures

Procedure: 1. Define sample size based on volume (minimum 10 or 10%, whichever greater) 2. Review records generated post-implementation 3. Evaluate against specified requirements 4. Calculate compliance rate

Example Criteria:

• 100% of records meet completeness requirements
• All required signatures present
• Traceability maintained throughout

Evidence Required:

• List of records reviewed
• Compliance checklist results
• Non-compliance summary (if any)

4. Testing/Inspection

Best for: Product quality issues, equipment failures, specification non-conformances

Procedure: 1. Define test protocol based on corrective action 2. Conduct testing on post-implementation units 3. Compare results to acceptance criteria 4. Document pass/fail rates

Example Criteria:

• 100% of units pass revised inspection criteria
• All test results within specification
• Zero failures of targeted parameter

Evidence Required:

• Test protocol/method
• Test results data
• Pass/fail summary
• Comparison to pre-implementation results

5. Interview/Observation

Best for: Training issues, communication problems, human factors causes

Procedure: 1. Develop structured interview questions 2. Interview representative sample of affected personnel 3. Observe process execution in real-time 4. Document responses and observations

Example Criteria:

• All interviewed personnel demonstrate knowledge
• Observed practices match documented procedure
• No unsafe acts or workarounds observed

Evidence Required:

• Interview questions and responses
• Observation notes
• Training records (supporting)

---

Effectiveness Criteria

Defining Good Criteria

Criteria must be SMART:

Criteria by Issue Type

Sample Size Guidelines

---

Closure Requirements

Closure Checklist

CAPA Closure Prerequisites:

• [ ] All corrective actions implemented
• [ ] Implementation evidence documented
• [ ] Verification waiting period complete
• [ ] Verification activities performed
• [ ] All effectiveness criteria met
• [ ] Verification evidence documented
• [ ] No recurrence during verification period
• [ ] CAPA owner review complete
• [ ] Quality Assurance review complete
• [ ] Documentation complete and filed

Effectiveness Status Determination

EFFECTIVENESS DECISION TREE:

Did recurrence occur during verification period?
├── Yes → CAPA INEFFECTIVE (escalate per ineffective process)
└── No → Were all effectiveness criteria met?
    ├── Yes → Were any related issues identified?
    │   ├── Yes → Open new CAPA if needed, close original
    │   └── No → CAPA EFFECTIVE - proceed to closure
    └── No → How many criteria missed?
        ├── Minor gap (1 criterion, marginal miss) →
        │   Extend verification period OR accept with justification
        └── Significant gap → CAPA INEFFECTIVE

EFFECTIVENESS DETERMINATION:
[ ] EFFECTIVE - All criteria met, no recurrence
[ ] EFFECTIVE WITH CONDITIONS - Minor gap, justified acceptance
[ ] INEFFECTIVE - Significant gaps or recurrence

Closure Documentation

EFFECTIVENESS VERIFICATION REPORT

CAPA Number: [CAPA-XXXX]
Verification Complete Date: [Date]
Verified By: [Name, Title]

VERIFICATION SUMMARY:
| Criterion | Target | Actual | Status |
|-----------|--------|--------|--------|
| [Criterion 1] | [Target] | [Result] | ☑ Met / ☐ Not Met |
| [Criterion 2] | [Target] | [Result] | ☑ Met / ☐ Not Met |
| [Criterion 3] | [Target] | [Result] | ☑ Met / ☐ Not Met |

RECURRENCE CHECK:
- Recurrence during verification period: [ ] Yes  [ ] No
- Related issues identified: [ ] Yes  [ ] No
- If yes, describe: [Description]

EVIDENCE SUMMARY:
[List of evidence documents, record numbers, data sources]

EFFECTIVENESS DETERMINATION:
[ ] EFFECTIVE
[ ] EFFECTIVE WITH CONDITIONS: [Justification]
[ ] INEFFECTIVE: [Reason]

RECOMMENDED ACTION:
[ ] Close CAPA
[ ] Extend verification period to [Date]
[ ] Open new CAPA [CAPA-XXXX] for [Issue]
[ ] Re-investigate (return to root cause analysis)

APPROVALS:
CAPA Owner: _____________ Date: _______
Quality Assurance: _____________ Date: _______
Management (if Major/Critical): _____________ Date: _______

---

Ineffective CAPA Process

Definition of Ineffective

CAPA is ineffective when: 1. Original problem recurs during or after verification period 2. Effectiveness criteria not met 3. Root cause still present 4. Corrective action created new problems

Ineffective CAPA Workflow

INEFFECTIVE CAPA DETECTED
    │
    ├── 1. Immediate Actions
    │   ├── Reopen CAPA (do not close as effective)
    │   ├── Implement containment for recurrence
    │   └── Notify CAPA owner and management
    │
    ├── 2. Root Cause Re-evaluation
    │   ├── Was original root cause correct?
    │   │   ├── No → Conduct new root cause analysis
    │   │   └── Yes → Was corrective action appropriate?
    │   │       ├── No → Develop new corrective action
    │   │       └── Yes → Was implementation adequate?
    │   │           ├── No → Re-implement with improvements
    │   │           └── Yes → Escalate (systemic issue)
    │
    ├── 3. Escalation Criteria
    │   ├── Second ineffective attempt → Management review required
    │   ├── Safety-related recurrence → Immediate escalation
    │   └── Pattern across multiple CAPAs → Systemic CAPA
    │
    └── 4. Documentation
        ├── Document ineffective status with evidence
        ├── Record re-investigation results
        ├── Update CAPA metrics/trending
        └── Include in management review

Preventing Ineffective CAPAs

---

Documentation Templates

Verification Evidence Log

VERIFICATION EVIDENCE LOG

CAPA Number: [CAPA-XXXX]

| Doc/Record # | Description | Date | Reviewed By | Finding |
|--------------|-------------|------|-------------|---------|
| [Number] | [Description] | [Date] | [Reviewer] | [Compliant/Finding] |
| [Number] | [Description] | [Date] | [Reviewer] | [Compliant/Finding] |

SUMMARY:
- Total records reviewed: [Number]
- Compliant: [Number] ([Percentage]%)
- Non-compliant: [Number] ([Percentage]%)

CONCLUSION:
[Statement on whether evidence supports effectiveness]

Trend Analysis Summary

TREND ANALYSIS FOR CAPA VERIFICATION

CAPA Number: [CAPA-XXXX]
Metric: [What is being measured]

BASELINE (Pre-Implementation):
- Period: [Start] to [End]
- Value: [Baseline value]
- Data points: [Number]

POST-IMPLEMENTATION:
- Period: [Start] to [End]
- Value: [Current value]
- Data points: [Number]

CHANGE:
- Absolute change: [Value]
- Percentage change: [Percentage]%
- Target: [Target value/change]
- Status: [ ] Met  [ ] Not Met

TREND CHART:
[Include or reference trend chart showing before/after comparison]

STATISTICAL SIGNIFICANCE (if applicable):
- Method: [t-test, chi-square, etc.]
- p-value: [Value]
- Conclusion: [Statistically significant / Not significant]

Interview Summary Template

VERIFICATION INTERVIEW SUMMARY

CAPA Number: [CAPA-XXXX]
Interviewer: [Name]
Date: [Date]

INTERVIEWEE:
- Name: [Name]
- Role: [Job title]
- Department: [Department]
- Experience: [Years in role]

QUESTIONS AND RESPONSES:

Q1: [Question about awareness of change]
A1: [Response summary]
Knowledge demonstrated: [ ] Yes  [ ] Partial  [ ] No

Q2: [Question about implementation of change]
A2: [Response summary]
Compliance demonstrated: [ ] Yes  [ ] Partial  [ ] No

Q3: [Question about understanding rationale]
A3: [Response summary]
Understanding demonstrated: [ ] Yes  [ ] Partial  [ ] No

OBSERVATION NOTES:
[Any relevant observations during interview]

CONCLUSION:
[ ] Interviewee demonstrates full knowledge and compliance
[ ] Interviewee demonstrates partial knowledge (specify gaps)
[ ] Interviewee does not demonstrate required knowledge

Root Cause Analysis Methodologies

Decision criteria, templates, and implementation guidance for RCA techniques.

---

Table of Contents

• Method Selection Matrix
• 5 Why Analysis
• Fishbone Diagram
• Fault Tree Analysis
• Human Factors Analysis
• Failure Mode and Effects Analysis
• Selecting the Right Method

---

Method Selection Matrix

When to Use Each Method

Quick Selection Decision Tree

Is the issue safety-critical or involves system reliability?
├── Yes → Use FAULT TREE ANALYSIS
└── No → Is human error the suspected primary cause?
    ├── Yes → Use HUMAN FACTORS ANALYSIS
    └── No → How many potential contributing factors?
        ├── 1-2 factors → Use 5 WHY ANALYSIS
        ├── 3-6 factors → Use FISHBONE DIAGRAM
        └── Unknown/Many → Use FMEA (proactive) or Fishbone (reactive)

---

5 Why Analysis

Overview

Simple, iterative technique asking "why" repeatedly (typically 5 times) to drill from symptoms to root cause.

When to Use

• Single-cause issues with linear causation
• Process deviations with clear failure point
• Quick investigations requiring rapid resolution
• Problems where symptoms clearly link to cause

When NOT to Use

• Complex multi-factor problems
• Safety-critical incidents requiring comprehensive analysis
• Issues with multiple interacting causes
• When systemic factors are suspected

5 Why Template

PROBLEM STATEMENT:
[Clear, specific description of what happened, when, where, and impact]

WHY 1: Why did [problem] occur?
BECAUSE: [First-level cause]
EVIDENCE: [Data/observation supporting this cause]

WHY 2: Why did [first-level cause] occur?
BECAUSE: [Second-level cause]
EVIDENCE: [Data/observation supporting this cause]

WHY 3: Why did [second-level cause] occur?
BECAUSE: [Third-level cause]
EVIDENCE: [Data/observation supporting this cause]

WHY 4: Why did [third-level cause] occur?
BECAUSE: [Fourth-level cause]
EVIDENCE: [Data/observation supporting this cause]

WHY 5: Why did [fourth-level cause] occur?
BECAUSE: [Root cause - typically systemic or management system failure]
EVIDENCE: [Data/observation supporting this cause]

ROOT CAUSE VALIDATION:
- [ ] Can the root cause be verified with evidence?
- [ ] If root cause is eliminated, would problem recur?
- [ ] Is the root cause within organizational control?
- [ ] Does the root cause explain all symptoms?

Example: Calibration Overdue

PROBLEM: pH meter (EQ-042) found 2 months overdue for calibration

WHY 1: Why was calibration overdue?
BECAUSE: The equipment was not on the calibration schedule
EVIDENCE: Calibration schedule reviewed, EQ-042 not listed

WHY 2: Why was it not on the calibration schedule?
BECAUSE: The schedule was not updated when equipment was purchased
EVIDENCE: Purchase date 2023-06-15, schedule dated 2023-01-01

WHY 3: Why was the schedule not updated?
BECAUSE: No process requires schedule update at equipment purchase
EVIDENCE: Equipment procedure SOP-EQ-001 reviewed, no such requirement

WHY 4: Why is there no requirement to update the schedule?
BECAUSE: The procedure was written before equipment tracking was centralized
EVIDENCE: SOP-EQ-001 last revised 2019, equipment system implemented 2021

WHY 5: Why has the procedure not been updated?
BECAUSE: Periodic procedure review did not assess compatibility with new systems
EVIDENCE: No documented review of SOP-EQ-001 against new equipment system

ROOT CAUSE: Procedure review process does not assess compatibility
with organizational systems implemented after original procedure creation

---

Fishbone Diagram

Overview

Also called Ishikawa or cause-and-effect diagram. Organizes potential causes into categories branching from the problem statement.

Standard Categories (6M)

Fishbone Template

PROBLEM STATEMENT: [Effect being investigated]

                    ┌── Man ────────────────┐
                    │  ├─ [Cause 1]         │
                    │  ├─ [Cause 2]         │
                    │  └─ [Cause 3]         │
                    │                       │
┌── Machine ────────┤                       ├── Method ──────────┐
│  ├─ [Cause 1]     │                       │  ├─ [Cause 1]      │
│  ├─ [Cause 2]     │     PROBLEM           │  ├─ [Cause 2]      │
│  └─ [Cause 3]     ├───────────────────────┤  └─ [Cause 3]      │
│                   │                       │                    │
├── Material ───────┤                       ├── Measurement ─────┤
│  ├─ [Cause 1]     │                       │  ├─ [Cause 1]      │
│  ├─ [Cause 2]     │                       │  ├─ [Cause 2]      │
│  └─ [Cause 3]     │                       │  └─ [Cause 3]      │
                    │                       │
                    └── Environment ────────┘
                       ├─ [Cause 1]
                       ├─ [Cause 2]
                       └─ [Cause 3]

CAUSE PRIORITIZATION:
| Cause | Category | Likelihood | Evidence | Priority |
|-------|----------|------------|----------|----------|
| [Cause A] | Method | High | [Evidence] | 1 |
| [Cause B] | Man | Medium | [Evidence] | 2 |

ROOT CAUSES IDENTIFIED:
1. [Primary root cause with supporting evidence]
2. [Contributing cause with supporting evidence]

Facilitation Guidelines

1. Assemble cross-functional team (3-8 people) 2. Define problem statement clearly before starting 3. Brainstorm causes without judgment first 4. Organize into categories after brainstorming 5. Drill down on each major cause (sub-causes) 6. Prioritize based on evidence and likelihood 7. Validate top causes with data

---

Fault Tree Analysis

Overview

Top-down, deductive analysis starting with undesired event and systematically identifying all potential causes using Boolean logic (AND/OR gates).

When to Use

• Safety-critical system failures
• Complex system reliability analysis
• Events with multiple failure pathways
• Regulatory-required investigations (FDA, MDR)

FTA Symbols

FTA Template

TOP EVENT: [Undesired event under investigation]

LEVEL 1 (Immediate Causes):
[Top Event]
    │
    └── OR GATE ──┬── [Cause 1.1]
                  ├── [Cause 1.2]
                  └── [Cause 1.3]

LEVEL 2 (Contributing Causes):
[Cause 1.1]
    │
    └── AND GATE ──┬── [Cause 2.1]
                   └── [Cause 2.2]

MINIMAL CUT SETS:
(Combinations of basic events that cause top event)
1. {Basic Event A, Basic Event B}  ← Both required (AND)
2. {Basic Event C}  ← Single point failure (OR)
3. {Basic Event D, Basic Event E}  ← Both required (AND)

CRITICAL PATH ANALYSIS:
Most likely failure pathway: [Description]
Single points of failure: [List]

RECOMMENDATIONS:
- Address single points of failure first
- Add redundancy where AND gates show vulnerability
- Prioritize controls on highest probability paths

Cut Set Analysis

Minimal cut sets identify the smallest combination of basic events causing the top event:

• Single-element cut sets: Single points of failure (highest priority)
• Two-element cut sets: Dual failure scenarios
• Probability calculation: P(Top Event) = Union of P(Cut Sets)

---

Human Factors Analysis

Overview

Systematic analysis of human error focusing on cognitive, physical, and organizational factors contributing to performance failures.

HFACS Categories

Human Factors Analysis and Classification System:

Human Error Types

Human Factors Investigation Template

INCIDENT DESCRIPTION:
[What happened, who was involved, when, where]

UNSAFE ACTS ANALYSIS:
Type of Error: [ ] Slip  [ ] Lapse  [ ] Mistake  [ ] Violation
Description: [Specific action or inaction]
Task Being Performed: [Activity at time of error]
Experience Level: [Novice/Intermediate/Expert]

PRECONDITIONS FOR UNSAFE ACTS:
Cognitive Factors:
- [ ] Task complexity exceeded capability
- [ ] Time pressure
- [ ] Distraction/interruption
- [ ] Mental fatigue

Physical Factors:
- [ ] Physical fatigue
- [ ] Inadequate lighting
- [ ] Noise interference
- [ ] Workspace ergonomics

Team Factors:
- [ ] Communication breakdown
- [ ] Coordination failure
- [ ] Inadequate leadership

SUPERVISORY FACTORS:
- [ ] Inadequate supervision
- [ ] Failed to correct known problem
- [ ] Inappropriate staffing
- [ ] Authorized unnecessary risk

ORGANIZATIONAL FACTORS:
- [ ] Resource management deficiency
- [ ] Organizational process issue
- [ ] Organizational culture/climate

ROOT CAUSE(S):
[Human factors root causes identified]

CORRECTIVE ACTIONS:
| Action | Target Factor | Priority |
|--------|---------------|----------|
| [Action 1] | [Factor addressed] | High |
| [Action 2] | [Factor addressed] | Medium |

---

Failure Mode and Effects Analysis

Overview

Proactive, systematic technique identifying potential failure modes, their causes, and effects before failures occur.

FMEA Types

Risk Priority Number (RPN)

RPN = Severity (S) × Occurrence (O) × Detection (D)

Severity Scale (1-10):

Occurrence Scale (1-10):

Detection Scale (1-10):

FMEA Template

PROCESS/PRODUCT: [Name]
FMEA TEAM: [Members]
DATE: [Date]

| Item/Step | Failure Mode | Effect | S | Cause | O | Controls | D | RPN | Action |
|-----------|--------------|--------|---|-------|---|----------|---|-----|--------|
| [Item 1] | [How it fails] | [Impact] | 8 | [Why] | 4 | [Current] | 6 | 192 | [Action] |
| [Item 2] | [How it fails] | [Impact] | 6 | [Why] | 3 | [Current] | 4 | 72 | [Action] |

RPN THRESHOLD: Actions required for RPN > [threshold]
HIGH SEVERITY RULE: Actions required for S >= 9 regardless of RPN

ACTION PRIORITIZATION:
1. Address all items with S >= 9 first
2. Address items with highest RPN
3. Focus on reducing Occurrence (prevention)
4. Then improve Detection (inspection)

---

Selecting the Right Method

Decision Flowchart

START: Investigation Required
    │
    ├── Is this a proactive assessment (no failure yet)?
    │   └── Yes → Use FMEA
    │
    ├── Is the issue safety-critical?
    │   └── Yes → Use FAULT TREE ANALYSIS
    │
    ├── Is human error the primary concern?
    │   └── Yes → Use HUMAN FACTORS ANALYSIS
    │
    ├── Are there multiple contributing factors (3+)?
    │   ├── Yes → Use FISHBONE DIAGRAM
    │   └── No → Use 5 WHY ANALYSIS
    │
    └── Uncertain? → Start with 5 WHY, escalate to FISHBONE if needed

Hybrid Approach

For complex investigations, combine methods:

1. Initial screening: 5 Why for quick cause identification 2. Detailed analysis: Fishbone to explore all categories 3. Validation: Fault Tree for critical failure paths 4. Systemic factors: Human Factors for people-related causes 5. Prevention: FMEA for future risk mitigation

Documentation Requirements