如何编制医疗器械软件描述文档（附模板）

根据CFDA 2015年8月5日发布的《国家食品药品监督管理总局关于发布医疗器械软件注册技术审查指导原则的通告（2015年第50号）》所有包含软件的第二类、第三类医疗器械产品，软件开发方式无论是自主开发、部分采用现成软件和全部采用现成软件，均应在首次注册时提交软件描述文档。软件描述文档的详略程度、条款要求均因安全性级别和开发方式的不同而有所差异。

• 针对自主研发的医疗器械软件，软件描述文档包括基本信息、实现过程和核心算法（详见附件）。
• 部分采用现成软件

对于部分采用现成软件的方式，三种安全性级别的现成软件的要求相同，制造商均应在软件描述文档相应条款中描述（详见表1）。

表1 部分现成软件框架

安全性级别	A级	B级	C级
软件描述 文档条款	软件标识、结构功能、风险管理、验证与确认、更新历史。	软件标识、结构功能、需求规范、风险管理、生存周期、验证与确认、缺陷管理、更新历史、核心算法。

• 全部采用现成软件

对于全部采用现成软件的方式，三种现成软件的要求有所不同：

1. 成品软件：制造商应提供外购合同复印件或声明、软件描述文档（不适用条款说明理由），成品软件如已在中国上市提供注册证复印件；
2. 遗留软件：制造商应提供遗留软件证明性文件（如YY/T 0664或IEC 62304实施之前的注册证或上市批书复印件）、软件描述文档（不适用条款说明理由）、上市后临床评价资料；
3. 外包软件：制造商应提供外包合同复印件或声明、软件描述文档（不适用条款说明理由）。

附件：
软件描述文档模板（以下模板由瑞旭技术原创）

1.基本信息

1.1产品标识
软件名称：
型号:
版本号：
制造商：
生产地址：

1.2安全性级别
明确软件安全性级别（A级、B级、C级），详述确定理由。

1.3结构功能
本软件是基于Windows平台研发的应用于PC平台的软件，包含XXXXXXXXXX等X个部分。
1.3.1软件体系结构图：
1.3.2用户界面关系图
1.3.3功能描述：
1.3.3.1XXXX模块功能描述
1.3.3.2XXXX模块功能描述
1.3.4外部接口

1.4硬件关系
1.4.1物理拓扑图：
1.4.2关系描述：

1.5运行环境
1.5.1网络布局
1.5.2服务器硬件配置
1.5.3客户端配置要求

1.6适用范围

1.7禁忌症

1.8注册历史
中国情况：
国外情况：

2.实现过程

2.1 开发综述
开发语言：
开发工具：
管理工具：
开发人员数量：
开发时间：
工作量：
代码行总数：
控制文档总数：

2.2 风险管理
详见资料8《安全风险分析管理报告》

2.3 需求规范
详见《软件需求说明书》。

2.4 生存周期
2.4.1软件开发策划：

1. 从经济、技术以及风险管理进行可行性分析，制定软件的开发计划书；
2. 确认软件开发方法和工具；
3. 软件控制文档策划；

2.4.1.1 软件配置管理计划
对所开发的软件规定各种必要的配置管理条款，以保证所交付的软件能够满足项目委托书中规定的各种原则需求，能够满足本项目总体组制定的且经领导小组批准的软件系统需求规格说明书中规定的各项具体需求。

2.4.1.2 软件配置管理流程

2.4.1.2.1 配置标识

1)文档
所有为本项目编制的文档，都要符合GB 8567中的规定。软件系统及其所属的各个子系统所编写的文档数目，可根据GB 8567的规定作适当的剪裁。剪裁方案由技术组提出建议，报总体组批准。

2)程序
所有属于本项目的程序、分程序、模块和程序单元，都要按照由项目技术组制订，且经总体组批准的软件系统的命名约定的规定来标识。

3)各类基线
所有属于本项目及其各子系统的各类基线，首先要按照任务书、软件需求规格说明书的规定确定其技术内容，然后按照软件系统的上述命名约定的规定来标识。

2.4.1.2.2 配置控制
软件配置的更改管理适用于本项目的所有文档和代码，其中包括本项目的各个运行软件，也包括为本项目专门开发的支持软件。

2.4.1.2.4 配置状态审计
利用软件问题报告单和软件修改报告单对项目子系统及其支持软件的配置状态进行追踪。对软件问题报告单和软件修改报告单的追踪应由软件配置管理工具自动实现，用户可通过该软件系统对其进行查询。

2.4.2 软件需求分析
根据软件的预期用途、软件功能和使用范围确定软件需求，形成软件需求分析规格书并形成软件的风险分析报告；

2.4.3 软件设计
根据软件的需求分析制定软件的体系结构图和详细的软件单元功能描述，指导整个软件系统开发，供程序员进行开发参考。开发完成后提供相关测试说明需求供其他相关人员参考了解和测试本软件系统；

2.4.4编码
根据体系结构图，并结合软件单元功能描述设计完成模块的代码编写和软件单元的功能实现，将代码进行备案；

2.4.5软件测试
软件单元集成的测试并进行软件的系统测试，形成软件测试报告，并对剩余风险进行再评价后按照初始版本号进行发行。

2.4.6软件维护
2.4.6.1软件维护计划
首先建立一个维护组织，组织里包括变化授权人，维护管理员和系统管理员。每个维护要求都通过维护管理员交给相应的系统管理员去评价（系统管理员是指定去熟悉一部分产品程序的技术人员）。系统管理员对维护任务作出评价后，再由变化授权人决定应该进行的活动。在有了维护组织后，就要用标准化的格式表达所有软件维护要求，对于适应性或完善性的维护要求，也要提出一个简短的需求说明书。

2.4.6.2软件维护流程

1. 使用者因为各种原因需要对软件进行修改，提出维护申请。
2. 提出申请部门负责人需要对情况进行核实并确认。
3. 维护工程师（一般由软件开发组专人负责）接收到确认后的维护请求，分析并提出修改方案。
4. 技术部门负责人对方案进行审核，确保方案的安全性和正确性。
5. 如需要，对系统进行备份。（具体操作由方案确定）
6. 如需要，对维护操作进行模拟验证。（具体操作由方案确定）
7. 维护工程师（一般指方案提出者本人）按照方案进行修改操作。完成维护后，需通知用户验证。
8. 维护申请提出用户对维护结果进行反馈和评价。

2.5 验证与确认
2.5.1 系统测试：
测试的系统环境

软件环境

1.操作系统：

2.支持软件：

硬件环境

CPU:

内存：

显存：

磁盘空间：

显示器：

6.网络环境：

测试使用的工具：

工具名称	用途	生产厂商	版本

测试方法：性能测试、安全性和访问控制测试、故障转移和恢复测试、配置测试、安装测试。
通过准则：与软件需求规格一致，且并未产生潜在剩余风险；
结果：通过软件参数的配置并对其进行多次测试、重复测试，验证软件完全达到预期开发要求。

2.5.2用户测试：
测试条件：用户实例
测试工具：？？？？
测试方法：实例运行
通过准则：输出结果判断
结果：对用户测试采用缺陷管理进行备案，供程序员进行系统修复。

2.6缺陷管理流程

2.6.1 缺陷管理工具
缺陷管理工具为：

2.6.2缺陷管理流程:

1. 测试中报告新的软件缺陷；
2. 分配给相关开发人员处理；
3. 开发人员按设计说明书设计，修正缺陷；
4. 开发人员完成修正后，经测试人员验证；
5. 错误被修复。

2.6.3缺陷总数和剩余缺陷数
发现缺陷总数：X条。
剩余缺陷数：X

2.6.4已知剩余缺陷情况

2.7 更新历史
2.8 临床评价
临床评价资料详见资料7《申报产品相关信息与<目录>所述内容对比表》及《申报产品与目录中已获准境内注册医疗器械对比表》。

3. 核心算法

3.1名称：
类型：成熟算法或全新算法
算法来源：
用途：
临床功能：