FDA软件器械（SaMD & SiMD）注册文档要求(详细)

MedWheat

随着独立软件器械（SaMD）和含软件器械（SiMD）对现代医疗的不断改变，美国FDA等监管机构对这些医疗器械的上市前所提交的文档制定了严格的要求。

文档要求

在向美国FDA提交软件相关医疗器械（SaMD/SiMD）的注册文档时，需涵盖基础七项文件，同时根据产品的风险等级（关注级别，LoC）补充额外材料。以下是这两部分的具体介绍：

1.关注级别(Level of Concern, LoC)说明

关注级别LoC是决定FDA提交中所需文档程度的关键因素。它评估了软件故障可能对用户造成的危害。FDA设定了三种关注级别：

• 轻度(Minor)：故障不太可能导致伤害；
• 中度(Moderate)：故障可能会导致轻微伤害；
• 重大(Major)：故障可能导致严重伤害或死亡。
  
  

在提交文件时，需明确说明器械的LoC，并解释软件如何影响、控制或减轻潜在的风险。

2.软件描述

软件描述文档应提供软件的全面概述，包括其功能、操作环境及与医疗器械的集成方式。内容应包括：

• 软件功能和特性；
• 预期用途；
• 编程语言和操作系统；
• 硬件平台；
• 使用的现成软件（如果适用）。
  
  

提示：为避免冗余，最好交叉引用软件需求规格说明书(SRS)。

3.器械危害分析

危害分析用于识别和评估与软件相关的潜在风险。您的风险管理必须符合ISO 14971:2019标准。文档应包含以下内容：

• 危害事件及其原因；
• 每种危害的严重性；
• 风险控制措施；
• 控制措施的验证；
• 纠正措施。
  
  

FDA强调必须考虑所有可能的误用场景，无论是有意的还是无意的。

4.软件需求规格说明书(Software Requirements Specification, SRS)

SRS概述了所有的软件需求，包括功能、性能、接口和开发限制。根据LoC的不同，所需的SRS文档详细程度也有所不同：

• 轻度(Minor)：简明版本即可；
• 中度(Moderate)、重大(Major)：提交详细的SRS。
  
  

SRS应包括硬件、接口和性能规格，并确保与软件描述一致，避免信息不匹配。

5.验证与确认测试

验证(Verification)确保软件符合设计规格，而确认(Validation)则确保最终产品满足用户需求。根据LoC，验证与确认文档的要求如下：

• 轻度：系统级测试、总结结果、通过/失败标准；
• 中度：所有验证与确认活动的总结、可追溯性、通过/失败文档；
• 重大：完整的测试文档、测试失败、修改和重测结果。
  
  

6.可追溯性分析

可追溯性矩阵链接了用户需求、设计输入、风险和测试结果，确保每个需求都得到验证和确认。示例如下：

(SRS: Software Requirements Specification)

(SDS: Software Design Specification)

7.版本变更历史

记录所有软件版本的变更，以展示开发控制过程。这对于理解软件的演变及任何修改对安全性和有效性的影响至关重要。变更历史应包括：

• 变更日期；
• 版本号；
• 变更描述；
• 对安全性和有效性的影响评估。
  
  

对于FDA提交，必须清楚解释测试版本与发布版本之间的差异。

根据FDA对软件医疗器械（SaMD/SiMD）的监管要求，除上述7项基础文档外，还可能需根据产品特性、关注级别（LoC）或特殊场景提交以下额外文档：

a. 网络安全文档（Cybersecurity Documentation）

适用情况：所有联网或含数据交互的软件器械（尤其是中/高LoC）。
要求内容：

• 网络安全风险分析：基于ISO/IEC 27001、NIST框架或FDA指南（如《Cybersecurity in Medical Devices》），识别潜在威胁（如数据泄露、拒绝服务攻击）。
• 安全控制措施：加密算法、身份验证机制、数据完整性保护等。
• 漏洞管理计划：包括漏洞监测、响应流程及用户通知策略。
• 补丁更新机制：说明如何推送安全更新（如远程升级）。
  
  

b. 人因工程与可用性报告（Human Factors Engineering, HFE）

适用情况：含用户交互界面的软件（尤其是中/高LoC）。
要求内容：

• 用户界面设计验证：符合FDA指南《Applying Human Factors and Usability Engineering to Medical Devices》；
• 使用场景分析：识别关键任务（如报警设置、剂量计算）及潜在误操作；
• 可用性测试结果：模拟用户操作中的错误率及改进措施。
  
  

c. 算法透明度文档（Algorithm Transparency）

适用情况：含AI/ML算法的软件（如诊断辅助、影像分析）。
要求内容：

• 算法原理说明：技术白皮书或科学文献支持其临床有效性；
• 数据来源与训练集描述：数据多样性、偏差控制方法；
• 性能评估：敏感性、特异性、ROC曲线等（参考FDA AI/ML行动计划）；
• 锁定机制（如适用）：防止算法在部署后未经验证的自我更新。
  
  

d. 互操作性与接口文档（Interoperability）

适用情况：需与其他设备/系统（如EHR、医院网络）交互的软件。
要求内容：

• 接口协议标准（如HL7、DICOM、FHIR）；
• 兼容性测试报告：与目标系统的数据交换验证；
• 故障隔离措施：避免因接口问题导致主系统崩溃。
  
  

e. 临床评估报告（Clinical Evaluation）

适用情况：中/高LoC软件，尤其是涉及诊断或治疗决策的SaMD。
要求内容：

• 临床数据：PMS（上市后监测）数据、文献综述或临床试验结果；
• 性能目标vs. 实际结果的对比分析；
• 不良事件报告（如适用）。
  
  

f. 数据管理计划（Data Governance）

适用情况：处理患者数据（如云存储、大数据分析）的软件。
要求内容：

• 数据隐私合规性：符合HIPAA、GDPR等法规；
• 数据生命周期管理：存储、传输、销毁的流程；
• 匿名化/去标识化方法（如适用）。
  
  

g. 现成软件（OTS）文档

适用情况：使用第三方组件（如开源库、商用SDK）。
要求内容：

• OTS清单及版本：包括许可证类型（如GPL、Apache）；
• 风险评估：OTS漏洞对整体安全性的影响；
• 供应商审计报告（如适用）。
  
  
  
  

h. 应急恢复计划（Disaster Recovery）

适用情况：关键医疗软件（如重症监护系统）。
要求内容：

• 备份与恢复流程：数据丢失容忍度及恢复时间目标（RTO）；
• 冗余设计：如服务器集群、故障自动切换。
  
  

i. 真实世界证据（RWE）计划

适用情况：FDA数字健康试点项目或持续学习型AI软件。
要求内容：

• RWE收集方案：如何利用真实临床数据验证性能；
• 迭代更新控制：FDA的“Predetermined Change Control Plan”（PCCP）框架。
  
  

xqliu

学习了，谢谢提供分享。