首页 > 服务领域

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

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

文档要求

在向美国FDA提交软件相关医疗器械(SaMD/SiMD)的注册文档时,需要申请人先结合器械的预期用途等相关因素来评估器械软件风险,根据风险等级,提交的文档可分为:一般基础软件文档(Basic Documentation),以及增强型软件文档(Enhanced Documentation),以下是具体文档要求:

1. 风险等级说明文档

通过风险等级的明确,选择适用的软件技术文档类型,风险等级的核心区分界限是:

是否存在严重伤害(serious injury),严重伤害(serious injury)的定义是,是否有以下情形之一:

1)危及生命;

2)导致身体机能永久性损伤或身体结构永久性损害;

3)需通过医疗或手术干预以防止身体机能或结构永久性损伤。永久性定义为不可逆的身体结构或功能损伤,不包括轻微损伤。

如果软件医疗器械功能风险包含上述的任一严重伤害的情形,需提交增强型软件技术文档案(Enhanced Documentation)。

2.软件描述文档

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

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

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

3.器械危害分析

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

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

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

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

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

  • 不存在严重伤害:简明版本即可;
  • 存在严重伤害:提交详细的SRS

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

5.验证与确认测试

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

  • 不存在严重伤害:系统级测试、总结结果、通过/失败标准、所有验证与确认活动的总结、可追溯性、通过/失败文档;
  • 存在严重伤害:完整的测试文档、测试失败、修改和重测结果。

6.可追溯性分析

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

用户需求

SRS

SDS (Software Design Specification)

危害

验证和确认

UND-001

SRS-003

SDS-003

HAZ-004

TC-003

UND-002

SRS-002

SDS-004

HAZ-001

TC-001






7.版本变更历史

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

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

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


根据FDA对软件医疗器械(SaMD/SiMD)的监管要求,除上述7项基础文档外,还可能需根据产品特性、风险等级或特殊场景提交以下额外文档:


a. 网络安全文档(Cybersecurity Documentation

适用情况:所有联网或含数据交互的软件器械(尤其是存在严重伤害)。

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


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

适用情况:含用户交互界面的软件(尤其是存在严重伤害)。

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


c. 算法透明度文档(Algorithm Transparency

适用情况:含AI/ML算法的软件(如诊断辅助、影像分析)。
要求内容
  • 算法原理说明:技术白皮书或科学文献支持其临床有效性。
  • 数据来源与训练集描述:数据多样性、偏差控制方法。
  • 性能评估:敏感性、特异性、ROC曲线等(参考FDA AI/ML行动计划)。
  • 锁定机制(如适用):防止算法在部署后未经验证的自我更新。


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

适用情况:需与其他设备/系统(如EHR、医院网络)交互的软件。
要求内容
  • 接口协议标准(如HL7DICOMFHIR)。
  • 兼容性测试报告:与目标系统的数据交换验证。
  • 故障隔离措施:避免因接口问题导致主系统崩溃。


e. 临床评估报告(Clinical Evaluation

适用情况:存在严重伤害软件,尤其是涉及诊断或治疗决策的SaMD
要求内容
  • 临床数据PMS(上市后监测)数据、文献综述或临床试验结果。
  • 性能目标 vs. 实际结果的对比分析。
  • 不良事件报告(如适用)。


f. 数据管理计划(Data Governance

适用情况:处理患者数据(如云存储、大数据分析)的软件。
要求内容
  • 数据隐私合规性:符合HIPAAGDPR等法规。
  • 数据生命周期管理:存储、传输、销毁的流程。
  • 匿名化/去标识化方法(如适用)。


g. 现成软件(OTS)文档

适用情况:使用第三方组件(如开源库、商用SDK)。
要求内容
  • OTS清单及版本:包括许可证类型(如GPLApache)。
  • 风险评估OTS漏洞对整体安全性的影响。
  • 供应商审计报告(如适用)。


h. 应急恢复计划(Disaster Recovery

适用情况:关键医疗软件(如重症监护系统)。
要求内容
  • 备份与恢复流程:数据丢失容忍度及恢复时间目标(RTO)。
  • 冗余设计:如服务器集群、故障自动切换。


i. 真实世界证据(RWE)计划

适用情况FDA数字健康试点项目或持续学习型AI软件。
要求内容
  • RWE收集方案:如何利用真实临床数据验证性能。
  • 迭代更新控制FDA的“Predetermined Change Control Plan”(PCCP)框架。
ceshi 显示
test text! 测试文字!