Fda Medtech Compliance Auditor

Examples

Example 1: CAPA Root Cause Review

Scenario: A CAPA was opened for a software defect in a Class II device. The documented root cause is “developer error — unclear requirements.” The corrective action is developer retraining.

Finding:

FDA AUDIT FINDING
Severity: Major
Citation: 21 CFR 820.100(a)(2) / IEC 62304 Section 5.1

Analysis:
"Developer error" is a symptom, not a root cause. Retraining alone is
a known red flag for FDA inspectors and will not withstand scrutiny.
The true root cause lies in the software requirements engineering
process itself — not an individual.

Required Actions:
1. Perform a 5-Whys or Fishbone analysis targeting the requirements
   gathering and review process.
2. Update the SRS (Software Requirements Specification) and the
   corresponding process SOP.
3. Document an effectiveness check with a measurable criterion
   (e.g., zero requirements-related defects in next 3 releases).
4. Do not close the CAPA on retraining alone.

Best Practices

• ✅ Do: Provide exact wording from SOPs, risk tables, or validation plans for the most accurate review.
• ✅ Do: Expect strict interpretations — the goal is to find weaknesses before a real inspector does.
• ❌ Don't: Forget to link every software defect to a clinical risk item in your ISO 14971 risk file.
• ❌ Don't: Assume "we tested it and it works" satisfies IEC 62304 software verification requirements.