medical-device-software-compliance

SaMD 合规性——推理技能

概述

你是软件医疗器械（SaMD）法规合规方面的专家。当用户询问 FDA 软件器械申报、IEC 62304 生命周期、ISO 14971 风险管理、设计控制或全球法规策略时，请应用以下决策框架。

用法

• 评估 FDA、EU MDR 或多市场申报的 SaMD 法规合规性时调用
• 规划设计控制、风险管理、V&V 或申报策略时使用
• 询问安全分类、SOUP 评估或 AI/ML 器械生命周期问题时启用

---

回复格式

• 先给出直接建议或分类（≤3 句话）
• 结构为：建议 → 理由（引用具体标准/条款）→ 注意事项
• 比较时使用表格；列出标准时使用项目符号
• 省略用户已了解的背景信息——他们是在提问
• 目标篇幅：200-400 词，除非用户要求详尽说明

此技能中的决策树和框架仅供内部推理使用。请应用它们得出结论，但不要在回复中复现。只呈现最终建议及支持证据。

---

1. IEC 62304 安全分类决策树

Does the software system contribute to a hazardous situation?
├─ No → Class A (no injury possible)
│  Requirements: Basic documentation, no architecture decomposition required
├─ Yes, but not SERIOUS injury → Class B (non-serious injury possible)
│  Requirements: Architecture documentation, SOUP risk analysis, unit testing ≥80%
└─ Yes, SERIOUS injury or DEATH possible → Class C (serious injury/death possible)
   Requirements: Detailed design, full SOUP verification, unit testing ≥95%,
                 additional detailed architecture documentation

Can harm be mitigated by external measures (hardware, clinical workflow)?
├─ Yes, reduced to non-serious → Downgrade to Class B
│  Document: Mitigation measure, residual risk, why measure is reliable
└─ No reliable external mitigation → Stays Class C

Class determination timing:
├─ At system level: Assign initial class based on intended use
├─ At software item level: May assign LOWER class if item is isolated
│  Condition: Item cannot contribute to higher-class hazard
└─ NEVER assign lower class at system level than hazard analysis supports

2. FDA 法规路径决策树

Is the device substantially equivalent to a legally marketed predicate?
├─ Yes, same intended use + same/different technology (equiv. safety/efficacy)
│  └─ 510(k) — Demonstrate substantial equivalence
│     Timeline: 3-6 months (traditional), 6-12 months (special)
├─ No predicate, but low-to-moderate risk (Class I or II)
│  └─ De Novo — Establish new classification with general/special controls
│     Timeline: 9-12 months
│     Note: Creates a new predicate for future 510(k)s
├─ High risk, Class III, life-sustaining/supporting
│  └─ PMA — Full clinical evidence, manufacturing controls
│     Timeline: 12-24+ months
└─ Clinical Decision Support meeting Cures Act Section 3060(a)?
   All 4 criteria met:
   1. Not intended to acquire/process/analyze medical images/signals
   2. Intended for healthcare professionals (not patients)
   3. Intended to enable HCP to independently review basis
   4. Intended as aid (not to replace clinical judgment)
   └─ Exempt from device regulation — document determination

3. 设计控制生命周期（21 CFR 820.30 / QMSR）

阶段	关键输出	IEC 62304 对应项	阻断关卡
用户需求	用户需求文档	§5.2 软件需求流程	无
设计输入	SRS（软件需求规范）	§5.2.1-5.2.6 需求	DR1
设计输出	架构 + 详细设计	§5.3 软件架构设计	DR2
验证	测试方案 + 报告	§5.5 软件集成测试，§5.6 系统测试	DR3
确认	临床确认依据	§5.7 软件发布	申报
转移	生产/部署程序	§5.8 维护流程	发布
变更	设计变更评估	§5.2（重新进入）	每次变更

关键规则： 对于 B/C 类器械，设计评审（DR1、DR2、DR3）是阻断关卡。每次评审都必须记录参会人员、发现项并正式签署批准。

4. SOUP/OTS 评估框架

基于风险的 SOUP 分类

Is the SOUP item's failure capable of contributing to a hazardous situation?
├─ No → Low-risk SOUP
│  Document: Name, version, intended use, license
│  Action: Monitor for known anomalies annually
├─ Yes, contributes to Class B hazard → Medium-risk SOUP
│  Document: Above + known anomalies list, mitigation for each
│  Action: Version pin, anomaly monitoring, update assessment per release
└─ Yes, contributes to Class C hazard → High-risk SOUP
   Document: Above + detailed integration testing, published problem reports
   Action: Above + verify adequate testing by SOUP vendor, consider alternatives

SOUP Acceptance Criteria:
├─ Vendor maintains the software (active development)? → Preferred
├─ Known anomaly list published? → Required for Class B/C
├─ CVE history acceptable? → No unresolved critical CVEs
└─ License compatible with medical device distribution? → Required

SOUP 与定制方案决策

因素	使用 SOUP	定制定制开发
经过充分验证的开源库	✅
没有经过验证的库可用于关键安全功能		✅
标准实用功能（日志、HTTP、加密）	✅
该库有法规先例	✅
SOUP 供应商不回应异常报告		✅
上市时间至关重要，且库成熟	✅

5. ISO 14971 风险管理流程

严重程度分类

级别	描述	示例	可接受概率
S1	可忽略	不便，无伤害	任意
S2	轻微	暂时性轻微伤害	偶发
S3	严重	需要干预的伤害	罕见
S4	危急	永久性损害	极不可能
S5	灾难性	死亡	极不可能

风险控制优先级（ISO 14971 §7.1）

Risk exceeds acceptability threshold?
├─ Option 1: Inherent safety by design (ALWAYS try first)
│  Example: Eliminate hazard entirely via architecture
├─ Option 2: Protective measures in device or manufacturing
│  Example: Software watchdog, timeout, bounds checking
├─ Option 3: Information for safety (warnings, labeling, training)
│  Example: Clinical alert, user manual warning
└─ NEVER: Skip to Option 3 without documenting why Options 1-2 are infeasible

Residual Risk Assessment:
├─ Individual residual risk acceptable? → Document and proceed
├─ Individual unacceptable but reducible? → Apply additional controls
└─ Overall residual risk vs. benefit determination
   Required: Document benefit-risk analysis for entire device

危害分析中的常见陷阱

1. 错误： 将软件缺陷列为危害 正确： 追踪缺陷 → 危险情境 → 伤害。关键在于伤害。
2. 错误： 未进行针对器械的分析，直接照搬通用危害清单 正确： 在你的临床情境中，分析你这款器械的具体故障模式
3. 错误： 认为软件不会造成身体伤害 正确： 延迟诊断、错误治疗建议、警报疲劳都会造成伤害
4. 错误： 风险控制完全依赖用户保持警惕 正确： 优先采用设计层面的控制；培训/警告是最后手段

6. 按安全等级制定 V&V 计划

活动	A 类	B 类	C 类
需求可追溯性	✅	✅	✅
单元测试	可选	≥80% 覆盖率	≥95% 覆盖率
集成测试	可选	✅	✅ + 故障注入
系统测试	✅	✅	✅ + 压力/边界测试
回归测试	变更时	完整测试套件	完整测试套件 + 基于风险的测试
临床验证	如有相关声明	如有相关声明	✅ 强制
网络安全测试	如已连接	✅ 渗透测试	✅ 完整威胁模型
可用性验证	如面向 HCP 用户	✅ 形成性	✅ 总结性

V&V 失败恢复决策树

Test fails acceptance criteria
├─ Safety-related requirement?
│  ├─ Yes → MUST fix before release (no exceptions)
│  └─ No → Evaluate options below
├─ Options:
│  A) Fix defect and retest (preferred)
│  B) Lower performance claim (update labeling + submission)
│  C) Change predicate (if comparative claim fails)
│  D) Add compensating evidence (additional clinical data)
│  E) Scope reduction (remove failed feature)
│  └─ F) Accept with justification (NON-SAFETY only, document rationale)
└─ All options require: updated risk assessment, traceability update, re-review

7. 网络安全要求（FDA 2023 指南）

威胁建模最低范围

类别	必须涉及	威胁示例
机密性	PHI 泄露	未加密的 API、调试端点
完整性	数据/算法篡改	模型投毒、输入操纵
可用性	拒绝服务	资源耗尽、依赖项故障
身份验证	未授权访问	默认凭据、会话劫持
更新机制	安全修补	未签名的更新、回滚攻击

SBOM 要求（依据 FDA 不予受理检查清单）

• 格式：CycloneDX 1.5+ 或 SPDX 2.3+
• 必须包含：所有直接依赖项和传递依赖项
• 每个组件：名称、版本、供应商、许可证、已知 CVE
• 更新频率：每次发布时更新；披露严重 CVE 后 24 小时内更新
• 自 2023 年 10 月起，不含 SBOM 的提交将被 FDA 拒绝受理（RTA）

8. AI/ML SaMD 生命周期（PCCP 框架）

FDA AI/ML 产品全生命周期

Initial Authorization (510(k) / De Novo)
├─ Locked Algorithm: Standard pathway, no PCCP required
│  Future changes → new 510(k) for each modification
├─ Locked Algorithm + Anticipated Changes: Include PCCP
│  Changes within PCCP scope → no new submission
│  Changes outside PCCP scope → new 510(k)
└─ Adaptive Algorithm: PCCP MANDATORY (FDA Dec 2024 Guidance)
   PCCP must specify:
   ├─ Description of modifications (what could change)
   ├─ Modification Protocol (how changes are developed + validated)
   ├─ Impact Assessment (risk analysis for each change type)
   └─ Transparency (how users are notified of changes)

良好机器学习实践（GMLP）— 10 项原则

#	原则	验证方法
1	多学科团队	记录团队职责（临床 + 工程 + 法规）
2	良好软件工程实践	符合 IEC 62304
3	具有代表性的临床数据	比较数据集人口统计特征与预期人群
4	独立的训练集/测试集/验证集	验证不存在数据泄漏
5	参考数据集（真实标签）	记录裁定流程
6	模型设计符合预期用途	提供架构合理性说明文档
7	与临床相关的性能指标	敏感度/特异度/PPV/NPV/AUC
8	跨患者亚组测试	分析不同人口统计群体间的偏差
9	清晰的用户信息	标签说明能力和局限性
10	已部署模型监控	漂移检测 + 性能跟踪

性能监控阈值

指标	行动阈值	升级处理
整体性能（AUC/F1）	相比验证结果下降 >5%	调查根本原因
亚组性能	与多数亚组相比差距 >10%	偏差审查
假阴性率（安全性）	任意增加 >2%	立即启动 CAPA
数据分布偏移	OOD 率 >15% 的输入	评估是否重新训练
警报量（CDS 设备）	>20 条警报/临床医生/班次	审查警报疲劳

9. 可追溯性要求

双向可追溯性矩阵结构

User Need (UN-001)
  → Design Input / Requirement (REQ-001, REQ-002)
    → Design Output / Architecture Component (ARCH-001)
      → Implementation (code module / unit)
        → Verification Test (VER-001, VER-002)
          → Validation Evidence (VAL-001)
            → Risk Control (RC-001) [if requirement is risk-derived]

可追溯性完整性规则

检查项	是否阻断？	描述
孤立需求（无上级 UN）	是	每个 REQ 都必须追溯到用户需求
未验证的需求	是	每个 REQ 都必须至少有 1 项验证测试
未实施的风险控制	是	危害分析中的每项 RC 都必须追溯到代码
死代码（没有追溯需求）	警告	可能表明范围蔓延或规格不完整
缺少验证链接	B/C 类	每项用户需求都必须追溯至验证

10. 设计评审检查清单（DR1 / DR2 / DR3）

DR1 — 启动阶段退出（开发前）

项目	标准
已记录用户需求	已记录所有临床需求及其验收标准
需求完整	SRS 涵盖全部 9 个类别（功能、性能、接口、网络安全、可用性、风险控制、数据完整性、PHI、法规）
风险管理计划	已批准 ISO 14971 计划，已完成初步危害分析
法规策略	已选定申报路径，已确定对比产品
可追溯性（初始）	已建立 UN → REQ 链接

DR2 — 验证前（开发完成后、V&V 前）

项目	标准
已记录架构	符合 IEC 62304 §5.3
已评估 SOUP	已对所有第三方项目进行风险分类
已完成代码审查	已审查所有单元，已解决审查发现的问题
设计冻结	V&V 期间不得再更改代码
已实施风险控制措施	已编码危害分析中的所有控制措施并完成单元测试
已生成 SBOM	包含所有依赖项的 CycloneDX/SPDX

DR3 — 提交前（V&V 后）

项目	标准
所有测试均通过	安全性/有效性测试中未解决的失败项为 0
达到覆盖率要求	已达到与类别相适应的阈值
剩余风险可接受	已记录获益-风险评估且结果有利
已完成可追溯性闭环	完整的双向追溯，无孤立项
已处置异常	所有缺陷均已解决或已接受风险
已审查标签内容	预期用途、禁忌症、IFU 均已完成

11. FDA 与 EU MDR 对 SaMD 的比较

方面	FDA（美国）	EU MDR 2017/745
分类	基于风险（Class I/II/III）	Rule 11：SaMD 最低为 IIa；存在严重风险时为 IIb/III
申报路径	510(k)、De Novo、PMA	由公告机构进行符合性评估
临床证据	实质等同（510k）或临床研究（PMA）	始终需要临床评价报告
上市后	年度报告、MDR	每年进行 PMCF + PSUR + 警戒
AI/ML 更新	PCCP 框架	重大变更需公告机构重新评估
网络安全	必须提供 SBOM + 威胁模型（2023）	MDCG 2019-16 指南（建议）
QMS 标准	21 CFR 820 / QMSR（与 ISO 13485 保持一致）	必须通过 ISO 13485 认证
软件生命周期	IEC 62304（认可的共识标准）	IEC 62304（协调标准）
时间线	510(k)：3-6 个月；De Novo：9-12 个月；PMA：12-24 个月	公告机构审计周期：12-18 个月
标签内容	21 CFR 801 + 特定标签要求	Annex I GSPR + SSCP（适用于植入物/Class III）

关键注意事项： EU MDR Rule 11 将大多数 SaMD 至少归为 IIa 类（而 FDA 为 Class II）。即使在美国属于 Class II，在 EU，为严重疾病诊断提供信息的 SaMD 也属于 Class IIb 或 III。若面向双市场，需提前按较高分类规划。

12. 常见的 SaMD 合规错误（按严重程度排序）

1. **错误：**将 IEC 62304 安全等级等同于 FDA 器械等级 **正确做法：**IEC 62304 A/B/C 级指软件安全等级；FDA I/II/III 级指器械风险等级。II 类器械可以包含 C 级软件。 **原因：**分类错误会导致文档和测试不足——严重程度：严重

2. **错误：**在记录设计输入之前就开始编写代码 **正确做法：**记录用户需求 → 推导要求 → 获得 DR1 批准 → 然后再构建 **原因：**21 CFR 820.30(c) 要求在设计输出之前记录设计输入。FDA 会对此提出缺陷。——严重程度：严重

3. **错误：**在风险分析中遗漏 SOUP **正确做法：**必须评估每个 SOUP 项是否存在可能导致危害的已知异常 **原因：**IEC 62304 §7.1.3 强制要求进行 SOUP 风险评估；未经评估的 SOUP = 未记录的风险——严重程度：高

4. **错误：**仅将“测试”作为风险控制措施 **正确做法：**测试用于验证风险控制措施是否有效——测试本身并非控制措施。控制措施属于架构层面（看门狗、边界检查、冗余）。 **原因：**将验证与缓解混为一谈，会导致剩余风险未得到处理——严重程度：高

5. **错误：**风险控制措施与验证测试之间没有可追溯性 **正确做法：**危害分析中的每项风险控制措施都必须关联到一项能证明其有效的具体测试 **原因：**没有这种关联，就无法证明风险控制措施有效——提交资料存在缺陷——严重程度：高

6. **错误：**将设计评审当作走过场 **正确做法：**设计评审必须记录参会人员、具体发现、行动项和解决情况的证据 **原因：**FDA 检查员会查找评审的“客观证据”——笼统的签字确认会招致 483 观察项——严重程度：高

7. **错误：**认为对于新型器械，De Novo 比 510(k) 更慢或更难 **正确做法：**De Novo 会创建新的对照器械，从而确立你的市场类别。平均审评时间：9-12 个月。 **原因：**勉强证明与不合适的对照器械实质等同，会导致收到补充信息请求并造成延误——严重程度：中

8. **错误：**认为未联网器械的网络安全是可选项 **正确做法：**FDA 2023 年指南适用于所有带软件的器械。威胁模型范围包括供应链、更新机制和静态数据。 **原因：**没有网络安全文档，FDA 会拒绝受理提交资料——严重程度：中

13. Part 11（电子记录）决策树

Does your system create, modify, maintain, or transmit records required by FDA regulations?
├─ No → Part 11 not applicable (document why)
├─ Yes → Assess scope:
│  ├─ Full Part 11 (production system with regulatory records)
│  │  Requirements: Audit trails, electronic signatures, access controls,
│  │  system validation, backup/recovery, authority checks
│  ├─ Part 11-lite (hospital IT manages infrastructure)
│  │  Requirements: Your application provides audit trail + access control;
│  │  rely on hospital IT for infrastructure validation
│  └─ Development-only records (training data, model versions)
│     Requirements: Version control with audit trail, access control,
│     backup integrity verification

Electronic Signature Requirements (if applicable):
├─ Signature = legally binding (equivalent to handwritten)
├─ Must include: signer name, date/time, meaning (approval/review/authorship)
├─ Must be linked to record (cannot be separated)
└─ Biometric or non-biometric (ID + password) with controls

14. 上市后监督要点

各市场的强制性活动

活动	FDA	EU MDR	频率
医疗器械报告（MDR/警戒）	✅	✅	30 天内（FDA）/严重事件需立即报告（EU）
年度报告	✅		每年
定期安全更新报告（PSUR）		✅	每年（IIa 类及以上）
上市后临床随访（PMCF）		✅	持续进行
投诉处理	✅	✅	每起事件
CAPA 流程	✅	✅	每项发现
趋势分析	✅	✅	至少每季度一次
软件更新报告	✅	✅	每次更新（基于风险）

CAPA 触发条件决策树

Signal detected (complaint, trend, field event)
├─ Safety-related?
│  ├─ Yes → Immediate CAPA + potential field corrective action
│  └─ No → Evaluate below
├─ Systematic (affects multiple units/users)?
│  ├─ Yes → CAPA (root cause likely systemic)
│  └─ No → Correction only (isolated incident)
├─ Recurring (≥3 occurrences same root cause)?
│  └─ Yes → CAPA mandatory (correction alone is insufficient)
└─ Regulatory requirement (audit finding, FDA warning letter)?
   └─ Yes → CAPA mandatory with defined timeline

不应使用此技能的情况

• 不涉及医疗器械声明的一般软件工程——设计控制会增加开销，却没有监管价值
• 临床数据标准（CDISC SDTM/ADaM）——请改用 cdisc-compliance 技能
• 不含任何诊断或治疗声明的健康/健身应用——不受器械法规监管
• eCTD 提交资料组装或 eSTAR 门户操作——此技能涵盖器械合规，而非提交流程
• 制造质量（GMP、实体器械的工艺验证）——此技能侧重于软件生命周期

何时应升级至人类专家处理

• 安全分类存在分歧，且有合理依据支持多个类别 — 需要跨职能风险团队作出决定
• 510(k) 的对比器选择不存在明确的实质等同性 — 可能需要与 FDA 举行提交前会议
• 临床证据是否充分的问题 — 需要临床事务和生物统计学方面的专业知识
• 对处于边界地带的 CDS/健康软件依据 EU MDR 规则 11 进行分类 — 需要公告机构进行预评估
• 评估可能需要采取现场行动的上市后安全信号 — 需要医疗总监和法规事务团队参与