关于 capa-officer
面向质量管理体系的 CAPA 管理技能,覆盖问题调查、根因分析、行动规划和有效性验证。它还提供 CAPA 指标跟踪与状态报告,帮助质量团队管理问题直至关闭。
主要功能
- 01指导 CAPA 调查流程
- 02按问题特点选择根因分析方法
- 03制定纠正与预防行动计划
- 04规划有效性验证并判断结果
- 05统计周期、逾期及复发指标
- 06生成 CAPA 状态与老化报告
适用场景
- 01调查客户投诉或审计发现
- 02分析重复不合格的根本原因
- 03为纠正措施设定负责人和期限
- 04检查行动效果并汇总 CAPA 状态
安装
复制下面的命令,在终端中运行。
npx skills add https:/ / github.com/ borghei/ claude-skills --skill capa-officer安装后在 Claude Code 中输入/capa-officer确认已加载。
包含的文件
除 SKILL.md 外,安装时一起下载的参考资料和脚本。
references/effectiveness-verification-guide.mdrca-methodologies.mdscripts/capa_tracker.py详细介绍
CAPA 专员
质量管理体系中的纠正和预防措施(CAPA)管理,重点关注系统性根因分析、措施实施和有效性验证。
目录
先澄清
开始 CAPA 调查前,请先确认以下输入信息。如果缺少某项信息或描述含糊,且会影响结果,请询问;如果不会影响结果,则采用合理的默认值,并说明所用默认值。
- **触发事件和客观证据:**发生了什么、何时何地发生,以及有哪些记录(决定问题陈述和 RCA 范围)。
- **严重程度分类:**严重、主要或次要(决定调查团队组成、措施深度和验证时间表)。
- **来源:**投诉、审核发现、重复发生的 NC 或趋势(决定是否需要 CAPA 以及相关法规要求)。
针对当前请求,只询问最重要的两三项信息,而非整份清单。如果用户希望立即获得结果,请直接给出,并在开头说明所作假设。
CAPA 调查工作流
从启动到关闭,系统地开展 CAPA 调查:
- 使用客观证据记录触发事件
- 评估重要性并确定是否需要 CAPA
- 组建具备相关专业知识的调查团队
- 系统地收集数据和证据
- 选择并应用适当的 RCA 方法
- 根据支持性证据确定根因
- 制定纠正和预防措施
- **验证:**根因能够解释所有症状;若根因已消除,问题就不会再次发生
CAPA 必要性判定
| 触发类型 | 是否需要 CAPA | 判定标准 |
|---|---|---|
| 客户投诉(安全) | 是 | 任何涉及患者/用户安全的投诉 |
| 客户投诉(质量) | 评估 | 根据严重程度和频率判定 |
| 内部审核发现(主要) | 是 | 系统性失效或要素缺失 |
| 内部审核发现(次要) | 建议 | 个别疏漏或部分实施 |
| 不合格(重复发生) | 是 | 同一类型的 NC 发生 3 次以上 |
| 不合格(个别发生) | 评估 | 根据严重程度和风险判定 |
| 外部审核发现 | 是 | 所有主要和次要发现 |
| 趋势分析 | 评估 | 根据趋势的重要性判定 |
调查团队组成
| CAPA 严重程度 | 必需团队成员 |
|---|---|
| 严重 | CAPA 专员、流程负责人、QA 经理、主题专家、管理层代表 |
| 主要 | CAPA 专员、流程负责人、主题专家 |
| 次要 | CAPA 专员、流程负责人 |
证据收集清单
- 问题描述及具体细节(内容、地点、时间、人员、数量)
- 导致问题的事件时间线
- 相关记录和文档
- 相关人员的访谈记录
- 照片或实物证据(如适用)
- 相关投诉、NC 或之前的 CAPA
- 流程参数和规格
根因分析
根据问题特征选择并应用适当的 RCA 方法。
RCA 方法选择决策树
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 个为什么分析
适用情形:单一原因问题、因果关系呈线性的问题,以及失效点明确的流程偏差。
模板:
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]
示例 — 校准逾期:
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.
鱼骨图分类(6M)
| 分类 | 关注领域 | 典型原因 |
|---|---|---|
| 人员(People) | 培训、能力、工作量 | 技能差距、疲劳、沟通问题 |
| 机器(设备) | 校准、维护、使用年限 | 磨损、故障、产能不足 |
| 方法(流程) | 程序、作业指导书 | 步骤不明确、缺少控制措施 |
| 材料 | 规格、供应商、存储 | 不符合规格、性能劣化、污染 |
| 测量 | 校准、方法、结果解读 | 仪器误差、方法错误 |
| 自然环境 | 温度、湿度、清洁度 | 环境偏差 |
有关方法和模板的完整详情,请参阅 references/rca-methodologies.md。
根本原因验证
开始制定行动计划前,请验证根本原因:
- 根本原因可通过客观证据验证
- 如果消除根本原因,问题将不会再次发生
- 根本原因在组织的控制范围内
- 根本原因能够解释所有已观察到的症状
- 没有其他尚未处理的重要原因
纠正措施规划
制定有效措施,处理已识别的根本原因:
- 确定即时围堵措施
- 制定针对根本原因的纠正措施
- 为类似流程确定预防措施
- 分配职责和资源
- 制定包含里程碑的时间表
- 定义成功标准和验证方法
- 记录在 CAPA 行动计划中
- **验证:**措施直接针对根本原因;成功标准可衡量
措施类型
| 类型 | 目的 | 时间安排 | 示例 |
|---|---|---|---|
| 围堵 | 阻止即时影响 | 24-72 小时 | 隔离受影响的产品 |
| 纠正 | 修复具体问题 | 1-2 周 | 返工或更换受影响的物品 |
| 纠正措施 | 消除根本原因 | 30-90 天 | 修订程序、增加控制措施 |
| 预防措施 | 防止其他区域出现类似问题 | 60-120 天 | 将解决方案扩展到类似流程 |
行动计划组成部分
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: _______
措施有效性指标
| 指标 | 目标 | 风险信号 |
|---|---|---|
| 措施范围 | 完全处理根本原因 | 仅处理症状 |
| 具体性 | 可衡量的交付成果 | 承诺含糊不清 |
| 时间安排 | 紧凑但可实现 | 没有截止日期或安排不切实际 |
| 资源 | 已确定并分配 | 未说明 |
| 可持续性 | 永久解决方案 | 临时修复 |
有效性验证
验证纠正措施是否实现预期结果:
- 留出足够的实施时间(至少 30-90 天)
- 收集实施后的数据
- 与实施前的基线进行比较
- 根据成功标准进行评估
- 确认验证期内未再次发生
- 记录验证证据
- 确定 CAPA 的有效性
- **验证:**所有标准均有客观证据支持;未观察到复发
验证时间安排指南
| CAPA 严重程度 | 等待期 | 验证周期 |
|---|---|---|
| 严重 | 30 天 | 实施后 30-90 天 |
| 重大 | 60 天 | 实施后 60-180 天 |
| 轻微 | 90 天 | 实施后 90-365 天 |
验证方法
| 方法 | 适用情况 | 所需证据 |
|---|---|---|
| 数据趋势分析 | 可量化的问题 | 实施前后比较、趋势图 |
| 流程审计 | 程序遵循问题 | 审计清单、访谈记录 |
| 记录审查 | 文档问题 | 抽样记录、合规率 |
| 测试/检验 | 产品质量问题 | 测试结果、通过/失败数据 |
| 访谈/观察 | 培训问题 | 访谈记录、观察记录 |
有效性判定
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)
详细流程请参阅 references/effectiveness-verification-guide.md。
CAPA 指标与报告
通过关键指标监控 CAPA 计划的绩效。
关键绩效指标
| 指标 | 目标 | 计算方式 |
|---|---|---|
| CAPA 周期时间 | 平均 <60 天 | (关闭日期 - 开启日期)/ CAPA 数量 |
| 逾期率 | <10% | 逾期 CAPA 数量 / 未关闭 CAPA 总数 |
| 首次验证有效率 | >90% | 首次验证有效的数量 / 已验证总数 |
| 复发率 | <5% | 问题复发数 / 已关闭 CAPA 总数 |
| 调查质量 | 100% 根本原因经验证 | 经验证的根本原因数 / CAPA 总数 |
老化分析类别
| 时长区间 | 状态 | 所需行动 |
|---|---|---|
| 0-30 天 | 进展正常 | 监控进度 |
| 31-60 天 | 需监控 | 检查是否存在延迟 |
| 61-90 天 | 警告 | 升级至管理层 |
| >90 天 | 严重 | 需要管理层介入 |
管理评审输入
每月 CAPA 状态报告包括:
- 按严重程度和状态统计的未关闭 CAPA 数量
- 含负责人的逾期 CAPA 清单
- 周期时间趋势
- 有效性比率趋势
- 来源分析(投诉、审核、不合格项)
- 改进建议
参考文档
根本原因分析方法
references/rca-methodologies.md 包含:
- 方法选择决策树
- 5 Why 分析模板和示例
- 鱼骨图类别和模板
- 用于安全关键问题的故障树分析
- 用于人员相关原因的人因分析
- 用于主动风险评估的 FMEA
- 混合方法指南
有效性验证指南
references/effectiveness-verification-guide.md 包含:
- 验证计划要求
- 验证方法选择
- 有效性标准定义(SMART)
- 按严重程度划分的关闭要求
- 无效 CAPA 流程
- 文档模板
工具
CAPA 跟踪器
# 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
可计算并报告:
- 汇总指标(未关闭、已关闭、逾期、周期时间、有效性)
- 状态分布
- 严重程度和来源分析
- 按时长区间划分的老化报告
- 逾期 CAPA 清单
- 可执行的建议
CAPA 输入示例
{
"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"
}
]
}
法规要求
ISO 13485:2016 第 8.5 条款
| 子条款 | 要求 | 关键活动 |
|---|---|---|
| 8.5.2 纠正措施 | 消除不合格的原因 | 不合格项评审、原因判定、措施评估、实施、有效性评审 |
| 8.5.3 预防措施 | 消除潜在不合格 | 趋势分析、原因判定、措施评估、实施、有效性评审 |
FDA 21 CFR 820.100
CAPA 必需内容:
- 实施纠正和预防措施的程序
- 分析质量数据来源(投诉、不合格项、审核、服务记录)
- 调查不合格的原因
- 确定纠正并防止问题复发所需的措施
- 验证措施有效且不会对器械造成不利影响
- 提交相关信息供管理评审
常见 FDA 483 观察结果
| 观察结果 | 根本原因模式 |
|---|---|
| 反复发生的问题未启动 CAPA | 未进行趋势分析 |
| 根本原因分析流于表面 | 调查培训不足 |
| 未验证有效性 | 没有验证程序 |
| 措施未解决根本原因 | 治疗症状而非消除原因 |
故障排除
| 问题 | 可能原因 | 解决方案 |
|---|---|---|
| 根本原因分析只得出症状 | 调查过早停止,或使用了错误的根因分析方法 | 应用根因分析方法选择决策树;确保至少追问 5 层“为什么”,且每一层都有证据 |
| CAPA 有效性验证屡次失败 | 纠正措施针对的是症状,而不是真正的根本原因 | 重新开展调查,考虑采用混合根因分析方法(例如,鱼骨图 + 5 个为什么),并邀请更多主题专家参与 |
| CAPA 周期持续超过 60 天的目标 | 分配的资源不足,或职责归属不明确 | 在管理评审中升级处理;指定专职 CAPA 协调员;将复杂的 CAPA 拆分为分阶段行动 |
| 逾期 CAPA 比例超过 10% | 缺少自动跟踪或提醒系统 | 通过 QMS 软件实施自动提醒;每周运行 python scripts/capa_tracker.py --capas capas.json,识别积压事项 |
| 审核员指出“根本原因分析浮于表面” | 根因分析方法培训不足 | 为调查团队开展根因分析方法培训;使用 references/rca-methodologies.md 中的模板;要求分析的每一步都提供证据 |
| CAPA 关闭后问题仍反复出现 | 预防措施未扩展到类似流程 | 在行动规划期间,明确评估所有类似流程;添加针对系统性原因的预防措施,而不只是针对特定事件 |
| 利益相关者对 CAPA 严重程度分类存在分歧 | 未采用标准化的严重程度标准 | 一致使用 CAPA 必要性判定表和严重程度定义;用客观证据记录分类理由 |
成功标准
- 首次有效率超过 90% —— 通过实施后的数据收集进行验证,确认在验证期内没有复发
- CAPA 平均周期少于 60 天 —— 按所有严重程度等级,以开启日期至关闭日期之间的时间衡量,并通过
capa_tracker.py指标跟踪 - 逾期率保持在 10% 以下 —— 通过积压分析进行监控,并在达到 61 天和 90 天阈值时触发升级处理
- 100% 的根本原因均通过客观证据验证 —— 每个根本原因都通过验证清单(解释所有症状、消除该原因可防止复发、属于组织的控制范围)
- 所有严重和主要 CAPA 均包含预防措施 —— 纠正措施针对特定事件,预防措施则将解决方案扩展到类似流程
- 管理评审每月收到 CAPA 状态报告 —— 报告包括按严重程度划分的未关闭数量、逾期清单、周期趋势和有效率趋势
- 复发率低于 5% —— 跟踪已关闭的 CAPA,监控同类问题是否在关闭后 12 个月内再次出现
范围与限制
范围内:
- 从触发事件到结案的 CAPA 调查工作流
- 使用 5 Why、鱼骨图(6M)、故障树分析、人因分析和 FMEA 方法进行根本原因分析
- 纠正和预防措施的规划、实施跟踪及有效性验证
- CAPA 指标计算、逾期时长分析和管理报告
- 符合 ISO 13485:2016 第 8.5 条和 FDA 21 CFR 820.100 要求
范围外:
- 此技能不能替代经过验证的 eQMS(电子质量管理系统)来跟踪生产中的 CAPA——它提供分析模板和指标计算
- 需要专用 SPC 软件的统计过程控制和高级趋势分析
- 监管申报准备(对于与申报相关的 CAPA,请使用
fda-consultant-specialist或mdr-745-specialist) - 超出内部调查范围的供应商 CAPA 管理(供应商资格认定请使用
quality-manager-qms-iso13485) - 需要程序性指导之外的医学或科学专业知识的临床调查 CAPA
重要说明:
- 根据 FDA QMSR(2026 年 2 月 2 日生效),CAPA 要求与 ISO 13485:2016 第 8.5 条保持一致,而非沿用旧版 21 CFR 820.100 的结构——此技能涵盖这两个框架
capa_tracker.py工具使用 JSON 输入,不会连接实时 QMS 数据库;请从 eQMS 导出数据以供分析
集成点
| 技能 | 集成方式 | 使用时机 |
|---|---|---|
quality-manager-qms-iso13485 | CAPA 发现结果用于改进 QMS 流程和供应商纠正措施 | 根本原因涉及 QMS 流程缺陷或供应商不符合项时 |
qms-audit-expert | 审核发现是 CAPA 的主要来源;CAPA 结案证据可支持审核跟进 | CAPA 源自内部或外部审核发现时 |
risk-management-specialist | CAPA 结果用于更新风险评估;FMEA 结果可能触发预防性 CAPA | 根本原因分析揭示出先前未评估的风险时 |
fda-consultant-specialist | FDA 483 观察项和警告信要求正式的 CAPA 回复 | CAPA 源自 FDA 检查发现时 |
mdr-745-specialist | EU MDR 警戒报告和 FSCA 可能触发 CAPA;CAPA 数据会反馈至 PMS/PSUR | 上市后监督发现安全或性能问题时 |
quality-documentation-manager | 因 CAPA 措施而进行的文件控制更新;电子 CAPA 记录须符合 21 CFR Part 11 | 纠正措施需要修订 SOP 或新建文件时 |
工具参考
capa_tracker.py
跟踪 CAPA 状态、计算指标、识别逾期事项,并生成管理评审报告。
| 标志 | 必填 | 描述 |
|---|---|---|
--capas <file> | 是(除非使用 --interactive 或 --sample) | 包含 CAPA 记录的 JSON 文件路径 |
--interactive | 否 | 启动交互模式,以手动录入 CAPA |
--output <format> | 否 | 输出格式:json 表示机器可读格式;默认输出为人类可读文本 |
--sample | 否 | 将示例 CAPA JSON 文件生成到标准输出,供用作模板 |
计算指标:
- CAPA 总数、未结数、已结数和逾期数
- 平均周期时间(从开启到关闭的天数)
- 首次验证有效率(首次验证有效数 / 已验证总数)
- 状态分布、严重程度细分和来源分析
- 按 0-30、31-60、61-90 和 90+ 天分组的逾期时长报告
- 逾期 CAPA 清单,包含负责人和超过目标日期的天数
示例:
# 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