医疗器械软件注册申报资料指导原则
前言
本指导原则旨在为申请人准备医疗器械软件注册申报资料提供具体建议,并规范医疗器械软件的技术审评要求。
本指导原则是对医疗器械软件的一般性要求,申请人应依据医疗器械软件的特性对注册申报资料的内容进行充实和细化。申请人还应依据医疗器械软件的特性确定其中的具体内容是否适用,若不适用,需具体阐述其理由及相应的科学依据。
本指导原则中不包括行政审批要求,不作为法规强制执行。应在遵循相关法规的前提下使用本指导原则。
本指导原则基于现行法规和标准体系以及当前认知水平进行制定,同时参考了相关的国际标准、国外法规要求与技术指导文件。随着法规和标准的不断完善,以及科学技术的不断发展,本指导原则相关内容也将进行适时的调整。
本指导原则针对软件的特殊性,在现行法规框架下进一步明确了医疗器械软件的监管要求,特别是对医疗器械软件更新、软件版本的监管要求。同时,本指导原则是医疗器械软件的通用指导原则,其他含有软件医疗器械的指导原则可在本指导原则基础上进行有针对性的调整、修改和完善。
一、适用范围
本指导原则适用于医疗器械软件的注册申报,包括进口医疗器械和国产III类医疗器械的注册申报,适用的软件开发方式包括自主开发、部分采用现成软件和全部采用现成软件。
医疗器械软件包括独立软件和软件组件:
1)独立软件:作为医疗器械或其附件的软件;
2)软件组件:作为医疗器械或其部件、附件组成的软件。
独立软件同时满足以下三个条件:具有一个或多个医疗用途,无需医疗器械硬件即可完成预期用途,运行于通用计算平台。独立软件包括通用型软件和专用型软件,其中通用型软件基于通用数据接口与多个医疗器械产品联合使用,如PACS、中央监护软件等;而专用型软件基于通用、专用的数据接口与特定医疗器械产品联合使用,如Holter数据分析软件、眼科显微镜图像处理软件等。
软件组件同时满足以下两个条件:具有一个或多个医疗用途,控制(驱动)医疗器械硬件或运行于医用计算平台。软件组件包括嵌入式软件和控制型软件,其中嵌入式软件(即固件)运行于医用计算平台,控制(驱动)医疗器械硬件(可兼有处理功能),如心电图机所含软件、脑电图机所含软件等;而控制型软件运行于通用计算平台,控制(驱动)医疗器械硬件(可兼有处理功能),如CT图像采集工作站软件、MRI图像采集工作站软件等。
专用型独立软件可以单独注册,也可以随同医疗器械产品注册(此时视为软件组件)。
二、基本原则
软件是无形的产品,没有物理实体,在开发和使用过程中人为因素影响无处不在,软件测试由于时间和成本的限制不能穷尽所有情况,所以软件缺陷无法避免。同时,软件更新频繁且迅速,轻微更新也可能导致严重后果,而且还具有退化问题(即每修复若干个缺陷就会产生一个新缺陷),所以软件缺陷无法根除。因此,软件缺陷可以视为软件的固有属性之一,软件的质量问题不容忽视。
鉴于软件的特殊性,医疗器械软件只有结合风险管理、质量管理和软件工程的要求才能保证安全性与有效性。采用基于风险的方法对医疗器械软件进行监管已是业内共识。
软件风险水平应根据软件安全性级别(YY/T 0664《医疗器械软件 软件生存周期过程》)进行确定,软件安全性级别基于软件损害严重度分为:
A级:不可能对健康有伤害和损坏;
B级:可能有不严重的伤害;
C级:可能死亡或严重伤害。
软件安全性级别应结合软件的预期用途、使用环境和核心功能(软件在预期使用环境完成预期用途所必需的功能)进行判定。其中预期用途主要考虑软件的临床用途(如诊断、治疗、监护、筛查等)和重要程度(如重要作用、辅助作用、补充作用等),使用环境主要考虑软件的使用场所(如医院、家庭等)、疾病类型(如严重性、紧迫性、传染性等)、患者人群(如成年人、儿童、老年人、女性等)和用户类型(如专业用户、普通用户、患者等),核心功能主要考虑软件的功能类型(如控制驱动、处理分析等)、实现方法(如CT图像重建采用滤波反投影算法还是迭代算法,异常识别采用常规图像处理算法还是人工智能算法等)和复杂程度(如算法规模、参数数量、运算速度等)。
软件安全性级别也可以根据风险管理所确定的风险等级进行判定,安全性级别与风险等级的分级可以不同,但二者存在对应关系,因此可以根据风险等级来判定安全性级别。
申请人应结合自身的质量管理体系,建立与软件风险水平相匹配的软件生存周期过程,包括软件开发过程、软件维护过程、配置管理过程、风险管理过程和问题解决过程。同时,申请人还应保证软件的信息安全,确保健康信息的保密性、完整性和可得性。
申请人应基于软件安全性级别提交相应的注册申报资料。注册申报资料均源于软件生存周期过程所形成的文档资料,详尽程度取决于软件安全性级别和软件复杂程度,安全性级别和复杂程度越高注册申报资料越多。
尽管独立软件和软件组件在结构和功能上有所不同,风险情况也存在差异,但软件生存周期过程要求基本一致,注册申报资料的整体要求相同,但在具体要求上有所区别。
三、软件描述文档
软件描述文档基于YY/T 0664《医疗器械软件 软件生存周期过程》制定,用于自主开发医疗器械软件的产品注册。软件描述文档包括基本信息、实现过程和核心算法(详见表1),具体要求如下:
(一)基本信息
1、软件标识
描述软件的名称、型号规格、发布版本、申请人和生产地址。软件组件为申请人内部质量控制所用的软件标识。
2、安全性级别
明确软件安全性级别(A级、B级、C级),并详述确定理由。
3、结构功能
依据软件设计规范(SDS)提供体系结构图和用户界面关系图。
体系结构图用于图示组成模块之间、组成模块与外部接口之间的关系,依据体系结构图描述组成模块(注明选装、版本)的功能、模块关系和外部接口。
用户界面关系图用于描述用户界面之间的关系,依据用户界面关系图描述临床功能模块(注明选装、版本)的功能、模块关系和外部接口。
4、硬件拓扑
依据软件设计规范(SDS)提供物理拓扑图,图示和描述软件(或组成模块)、通用计算机、医疗器械硬件相互之间的物理连接关系。
5、运行环境
描述软件运行所需的硬件配置、软件环境和网络条件。其中硬件配置包括处理器、存储器和外设器件,软件环境包括系统软件、支持软件和安全软件,网络条件包括网络架构(BS、CS)、网络类型(广域网、局域网、个域网)和带宽要求。
6、适用范围
独立软件描述软件的适用范围,软件组件描述医疗器械产品的适用范围。进口医疗器械软件描述原产国注册所批准的适用范围。
7、禁忌症
独立软件描述软件的禁忌症或使用限制,软件组件描述医疗器械产品的禁忌症或使用限制。进口医疗器械软件描述原产国注册所批准的禁忌症或使用限制。
8、注册历史
列明软件在中国的注册情况,包括历次注册的版本和注册证号。同时列明软件在原产国历次注册的日期、版本和管理类别,在其他主要国家和地区的注册历史也可提供。
软件组件描述医疗器械产品的注册历史。
(二)实现过程
1、开发概述
描述软件开发所用的语言、工具和方法,其中工具描述支持软件(含开源软件)和应用软件(第三方软件)的名称、版本和申请人。同时给出开发人员数量、开发时间、工作量(人月数)和代码行总数。
2、风险管理
依据风险管理相关标准提供软件风险管理资料,风险管理资料应另附原始文件。软件组件提供医疗器械产品的风险管理资料。
3、需求规范
A级提交软件需求规范关于软件功能的相应内容,B级和C级提供软件需求规范全文。需求规范应另附原始文件。软件组件如无单独的需求规范文档,可提供医疗器械产品的需求规范文档。
4、生存周期
A级提供软件开发生存周期计划摘要,描述各阶段的划分情况和工作任务。B级在A级基础上提供配置管理计划摘要和维护计划摘要,描述相应的工具和流程。C级在B级基础上提供设计历史文件(DHF)的文档索引表。
生存周期也可提交申请人软件生存周期过程控制文档、YY/T 0664《医疗器械软件 软件生存周期过程》等标准的核查表,用于替代相应描述。
5、验证与确认
验证是指通过提供客观证据来认定软件某开发阶段的输出满足输入要求,包括代码检查、设计评审、测试等质量保证活动。确认是指通过提供客观证据来认定软件满足用户需求,通常是指在真实或模拟使用环境的测试。可追溯性分析是指追踪需求规范、设计规范、源代码、测试、风险管理之间的关系,分析已识别关系的正确性、一致性、完整性和准确性。
A级提供系统测试、用户测试的计划和报告摘要,描述测试的条件、工具、方法、通过准则和结果。B级提供系统测试、用户测试的计划和报告,并概要介绍各个阶段的验证活动,描述相应的工具、方法和任务。C级在B级基础上提供可追溯性分析报告。
系统测试和用户测试的计划和报告应另附原始文件,测试报告关于测试记录的内容可以提供一个测试记录样例和完整的测试记录清单。验证活动也可以提交申请人软件质量保证文件,用于替代相应描述。
6、缺陷管理
A级描述缺陷管理的工具和流程,给出开发阶段所发现的缺陷总数和已知剩余缺陷数。B级和C级在A级基础上列明已知剩余缺陷情况。已知剩余缺陷情况可另附原始文件。
7、更新历史
所有级别软件均应描述软件版本命名规则,明确软件版本的全部字段及字段含义,确认软件的完整版本和发布版本。
A级列明软件在本次注册时(即本次申报版本与原产国前次注册版本之间)历次软件更新的版本、日期和类型(完善型、适应型、纠正型、预防型)。B级在A级基础上详述本次注册时历次软件更新的具体内容。C级列明软件在原产国历次注册时历次软件更新的版本、日期、类型和具体更新内容。更新历史可另付原始文件。
8、临床评价
临床评价资料包括临床文献资料、临床经验数据和临床试验报告。临床评价资料应另附原始文件。
(三)核心算法
依据软件设计规范(SDS)和使用说明书列明核心算法的名称、类型、用途和所对应的临床功能。
核心算法是指实现软件核心功能所必需的算法,包括成像算法、后处理算法和人工智能算法。其中成像算法是指用于获取医学图像或数据的算法,后处理算法是指改变原始医学图像或数据而产生新临床信息的算法,人工智能算法是指采用人工智能技术进行医学图像或数据分析处理的算法。
算法类型包括公认成熟算法或全新算法。其中公认成熟算法是指源自公开文献专利标准、原理简单明确、上市多年且无不良事件的算法,全新算法是指源自临床研究、科学研究的新算法。
核心算法详尽程度取决于安全性级别和算法类型。当安全性级别为A级时,公认成熟算法和全新算法均需列明算法的名称、类型、用途和临床功能。当安全性级别为B级和C级时,公认成熟算法需列明算法的名称、类型、用途和临床功能,全新算法在公认成熟算法基础上还应提供安全性与有效性验证资料。
表1:软件描述文档内容框架
描述文档 | A级 | B级 | C级 | ||
基本信息 | 软件标识 | 描述软件名称、型号规格、发布版本、申请人和生产地址 | |||
安全性级别 | 描述软件安全性级别,详述安全性级别确定理由 | ||||
结构功能 | 依据体系结构图描述软件的组成模块,依据用户界面关系图描述软件的临床功能模块 | ||||
硬件拓扑 | 依据物理拓扑图描述软件、通用计算机和医疗器械硬件的物理连接关系 | ||||
运行环境 | 描述软件运行所需的硬件配置、软件环境和网络条件 | ||||
适用范围 | 描述软件的适用范围,进口软件描述原产国的情况 | ||||
禁忌症 | 描述软件的禁忌症或使用限制,进口软件描述原产国的情况 | ||||
注册历史 | 描述软件在中国和原产国的注册情况 | ||||
实现过程 | 开发概述 | 描述开发语言、工具、方法,提供人员、时间、工作量、代码行数 | |||
风险管理 | 提供风险管理资料 | ||||
需求规范 | 需求规范的功能要求 | 需求规范全文 | |||
生存周期 | 开发生存周期计划摘要 | 开发生存周期计划、配置管理计划和维护计划的摘要 | 开发生存周期计划、配置管理计划和维护计划的摘要,提供设计历史文件的文档索引表 | ||
验证与确认 | 系统测试和用户测试的计划与报告摘要 | 概述开发各阶段的验证活动,提供系统测试和用户测试的计划与报告 | 概述开发各阶段的验证活动,提供系统测试和用户测试的计划与报告,提供可追溯性分析报告 | ||
缺陷管理 | 描述缺陷管理流程,给出缺陷总数和剩余缺陷数 | 描述缺陷管理流程,给出缺陷总数和剩余缺陷数,列明剩余缺陷情况 | |||
更新历史 | 描述版本命名规则,列明本次注册时历次软件更新的版本、日期和类型 | 描述版本命名规则,列明本次注册时历次软件更新的版本、日期、类型和具体内容 | 描述版本命名规则,列明历次注册时历次软件更新的版本、日期、类型和具体内容 | ||
临床评价 | 提供临床评价资料 | ||||
核心算法 | 列明算法的名称、类型、用途和临床功能 | 公认成熟算法列明算法的名称、类型、用途和临床功能, 全新算法在公认成熟算法基础上提供验证资料 |
四、软件更新
(一)基本考量
医疗器械软件更新是指申请人在整个软件生存周期过程中对软件所做的修改。软件更新类型从不同角度出发有不同划分方法。从更新的结果和影响角度出发,软件更新可分为:
1)重大更新:影响到医疗器械安全性或有效性的软件更新;
2)轻微更新:不影响医疗器械安全性和有效性的软件更新。
从更新的目的和范围角度出发,软件更新可分为增强类更新和纠正类更新,其中增强类更新又可分为完善型更新和适应型更新,而纠正类更新又可分为纠正型更新和预防型更新(改自GB/T 20157《信息技术 软件维护》):
1)完善型更新:医疗器械软件交付后,为改变性能、维护性或其他软件属性而进行的软件更新;
2)适应型更新:医疗器械软件交付后,为适应新的运行环境而进行的软件更新;
3)纠正型更新:医疗器械软件交付后,为修正软件已知缺陷而进行的软件更新;
4)预防型更新:医疗器械软件交付后,为修正软件潜在未知缺陷以避免出现运行故障而进行的软件更新。
同时,还有两种特殊情况需要考虑:
1)内部构建(Build):符合软件更新的定义,通过质量管理体系进行控制,申报资料要求与纠正类更新相同。下文如无特别说明,纠正类更新均包含内部构建;
2)涉及召回的软件更新:包括软件更新导致医疗器械召回、召回处理措施所引发的软件更新,这两种情况均属于重大更新,应按照医疗器械召回的相关法规处理,不属于本指导原则讨论范围。
本指导原则关注软件的安全性与有效性,将软件更新划分为:
1)重大软件更新:影响到医疗器械安全性或有效性的增强类更新,即重大增强类软件更新(含重大完善型更新、重大适应型更新);
2)轻微软件更新:不影响医疗器械安全性或有效性的增强类更新和纠正类更新,包括轻微增强类软件更新(含轻微完善型更新、轻微适应型更新)和纠正类软件更新(含纠正型更新、预防型更新和内部构建)。
医疗器械软件发生重大软件更新应进行许可事项变更,而发生轻微软件更新应通过质量管理体系进行控制,无需进行许可事项变更,待到下次注册(注册变更或延续注册)时提交相应申报资料。
软件生存周期过程模型发生改变(如瀑布模型改为V模型)视为软件的重新开发,应按照医疗器械产品注册的要求提交申报资料。
(二)重大软件更新
根据重大软件更新的定义,凡是影响到医疗器械安全性或有效性的软件更新均为重大软件更新。具体而言,软件更新如影响到医疗器械的预期用途、使用环境或核心功能均视为重大软件更新。
本指导原则所述重大软件更新包括下列情形之一:
1)适应型软件更新:软件运行平台跨越互不兼容的计算平台(含硬件和软件),如操作系统软件由Windows变为iOS,32位计算平台变为64位计算平台、常规计算平台变为移动计算平台等,而系统软件和支持软件的补丁一般不视为重大软件更新,除非影响到医疗器械的安全性与有效性。
2)完善型软件更新:影响到用户临床决策(包括决策能力、决策结果、决策流程和用户临床行动),或者影响到人员安全(包括患者、用户和其他相关人员),包括但不限于:
— 临床功能改变,如新增临床应用、新增运行模式、采用新核心算法等;
— 软件输出结果改变,如医学图像或数据质量改变、用户界面增加临床信息等;
— 用户使用习惯改变,如用户原有临床工作流程改变、用户界面布局改变等;
— 影响到患者安全,如采用新的软件安全标准、用户界面增加报警信息等。
而核心算法运算速度的单纯性提高、临床工作流程的可配置化(即用户可以保留原有临床工作流程)、用户界面的文字性修改一般不视为重大更新,除非影响到医疗器械的安全性与有效性。
3)其他软件更新:软件的安全性级别、体系结构、用户界面关系和物理拓扑发生改变。
重大软件更新的范围会随着认知与技术水平的提高、不良事件与召回事件的分析进行动态调整。
(三)软件更新要求
软件发生增强类更新应提交简化软件描述文档,包括基本信息、实现过程和核心算法,要求详见表2。
表2:简化软件描述文档内容框架
软件描述文档 | 资料要求 | |
基本信息 | 软件标识 | 描述软件本次申报版本情况,如改变应详述更新内容 |
安全性级别 | 描述软件本次申报版本情况,如改变应详述更新理由,并按更新后的安全性级别提交资料 | |
结构功能 | 描述软件本次申报版本情况,如改变应详述更新内容 | |
硬件拓扑 | 描述软件本次申报版本情况,如改变应详述更新内容 | |
运行环境 | 描述软件本次申报版本情况,如改变应详述更新内容 | |
适用范围 | 描述软件本次申报版本情况,如改变应详述更新内容 | |
禁忌症 | 描述软件本次申报版本情况,如改变应详述更新内容 | |
注册历史 | 描述软件本次申报版本情况 | |
实现过程 | 开发概述 | 描述软件本次申报版本情况,如改变应详述更新内容 |
风险管理 | 针对更新进行的风险管理资料,包含对整体的影响分析 | |
需求规范 | 更新部分的需求规范 | |
生存周期 | 软件维护和配置管理流程 | |
验证与确认 | 针对更新进行的验证与确认资料,包含对整体影响的确认 | |
缺陷管理 | 缺陷管理流程,软件当前剩余缺陷情况 | |
更新历史 | 软件版本命名规则,前次注册至本次申报版本的更新内容 | |
临床评价 | 针对更新进行的临床评价资料 | |
核心算法 | 更新部分的核心算法 |
软件发生纠正类更新应提交简化软件申报资料,包括软件更新情况说明、回归测试计划与报告、新增剩余缺陷的风险管理资料。
软件同时发生多种类型的软件更新,应按照风险从高原则提交申报资料,即同时发生重大软件更新和轻微软件更新则按照重大软件更新提交申报资料,同时发生增强类软件更新和纠正类软件更新则按照增强类软件更新提交申报资料。
五、软件版本
(一)基本考量
软件是无形的,只能通过状态管理来保证质量,而软件版本用于标识软件状态,控制软件更新,进而保证软件质量,因此软件版本与软件是相互对应的表里关系,即软件版本是软件标识不可或缺的组成部分,也是实现医疗器械软件可追溯性的重要工具。
申请人无论采用何种名称和形式(如修订号、构建号、发布日期等),只要用于标识软件状态均视为软件版本。申请人制定软件命名规则除了考虑医疗器械自身特点、质量管理体系的要求之外,还要考虑监管的要求,即软件版本命名规则能区分软件更新的类型,可以明确软件的完整版本和发布版本:
1)软件完整版本:体现重大增强类更新、轻微增强类更新、纠正类更新和内部构建(如适用);
2)软件发布版本:仅体现重大增强类更新。
软件发布版本发生改变应进行许可事项变更,软件完整版本发生改变但发布版本未变无需进行许可事项变更。例如,软件版本命名规则为X.Y.Z.B,其中X表示重大增强类更新,Y表示轻微增强类更新,Z表示纠正类更新,B表示内部构建,则软件完整版本为X.Y.Z.B,而软件发布版本为X,此时X发生变化应进行许可事项变更,而Y、Z和B发生变化无需进行许可事项变更。
软件版本命名规则同样适用于风险从高原则,即不能区分重大软件更新和轻微软件更新则按照重大软件更新处理,不能区分增强类软件更新和纠正类软件更新则按照增强类软件更新处理。
(二)软件版本要求
软件版本命名规则真实性声明应明确软件版本的全部字段及字段含义,确认软件的完整版本和发布版本。
对于独立软件(含专用型独立软件视为软件组件的情况)和控制型软件组件,申请人应在登录界面、主界面等界面体现软件发布版本,在“关于”、“帮助”等界面体现软件完整版本,注册检测报告应提供软件完整版本界面和软件发布版本界面的照片。
同时,进口独立软件(含专用型独立软件视为软件组件的情况)应在原产国主管部门出具的上市证明材料中体现软件发布版本,如CFG证书、EC符合性声明、出口证明等。
六、现成软件
(一)基本考量
随着信息技术的快速发展,医疗器械使用现成软件的情况越来越普遍,但是现成软件不能完全满足医疗器械的预期功能,而且申请人也未对现成软件进行完整生存周期控制,因此使用现成软件具有不确定性,风险相对较高。由于申请人要对医疗器械最终的安全性与有效性负责,因此应采用基于风险管理的方法对现成软件进行质量管理。
现成软件具体分为:
1)成品软件:已开发且通常可得到的,但申请人未进行完整生存周期控制的软件,包含商业现货软件(COTS)和免费软件;
2)遗留软件:申请人以前开发但现在不能得到足够开发记录的软件;
3)外包软件:申请人委托第三方开发的定制软件。
目前,本指导原则所述的现成软件仅限于应用软件,今后将在适当时机下扩至系统软件和支持软件。但申请人应保证系统软件和支持软件的质量和安全。
(二)现成软件要求
医疗器械软件的开发方式不同,采用的现成软件类型不同,软件质量保证措施也不同,注册申报资料也有所差异。
1、部分采用现成软件
对于部分采用现成软件的方式,成品、遗留和外包软件的资料要求详见表3,其中:
表3:部分现成软件内容框架
安全性级别 | A级 | B级 | C级 |
软件描述 文档条款 | 软件标识、结构功能、风险管理、验证与确认、更新历史 | 软件标识、结构功能、需求规范、风险管理、生存周期、验证与确认、缺陷管理、更新历史、核心算法 |
(1)软件标识
A、B、C级描述现成软件的名称、型号规格、发布版本、制造商和生产地址。
(2)结构功能
A、B、C级注明组成模块、临床功能模块所用现成软件的名称、发布版本和类型(外包、成品、遗留)。
(3)风险管理
A、B、C级提供现成软件的风险管理资料。
(4)需求规范
B级和C级提供现成软件的需求规范资料。
(5)生存周期
B级和C级在开发生存周期计划、配置管理计划和维护计划中明确现成软件的要求。
(6)验证与确认
A、B、C级提供现成软件的验证与确认资料。
(7)缺陷管理
B级和C级列明现成软件的缺陷管理流程和剩余缺陷情况。
(8)更新历史
A、B、C级明确现成软件的版本命名规则。
(9)核心算法
B级和C级列明现成软件核心算法的名称(或编号)、用途和所对应的临床功能。
2、全部采用现成软件
对于全部采用现成软件的方式,申报要求如下:
(1)成品软件提供外购合同复印件(或声明)和软件描述文档(不适用条款说明理由),如已在中国注册提供注册证复印件;
(2)遗留软件提供注册证复印件和软件描述文档(不适用条款说明理由),并提供遗留软件上市后临床评价资料;
(3)外包软件提供外包合同复印件(或声明)和软件描述文档。
(三)现成软件更新要求
现成软件的更新类型、更新注册要求和风险从高原则与自主开发软件相同,注册申报资料要求与自主开发软件有所差异。
现成软件发生增强类更新应参照自主开发增强类更新的要求提交简化现成软件描述文档,其中不适用条款说明理由。而现成软件发生纠正类更新与自主开发软件纠正类更新要求相同,提交简化软件申报资料即可。
对于部分采用现成软件的情况,自主开发软件发生更新按照自主开发软件更新要求提交申报资料,现成软件发生更新按照现成软件更新要求提交申报资料。
(四)现成软件版本要求
现成软件版本同样要考虑监管要求和风险从高原则。现成软件开发方的软件版本命名规则如符合监管要求,申请人可以直接采用开发方的软件版本和版本命名规则。
申请人应在软件版本命名规则真实性声明中明确现成软件的版本及版本命名规则。