医疗器械软件注册指导

时间:2024.3.24


第二篇:《医疗器械软件注册申报资料指导原则》征求意见


指导原则编号:□□□□□□□□□

医疗器械软件注册申报资料

指导原则

(征求意见稿)

二O一五年三月

- 1 -

前 言……………………………………………………………………1

一、 适用范围…………………………………………………………2

二、 基本原则…………………………………………………………3

三、 软件描述文档……………………………………………………5

(一) 基本信息

(二) 实现过程

(三) 核心算法

四、 软件更新………………………………………………………11

(一) 基本考量

(二) 重大软件更新

(三) 软件更新要求

五、 软件版本………………………………………………………15

(一) 基本考量

(二) 软件版本要求

六、 现成软件………………………………………………………16

(一) 基本考量

(二) 现成软件要求

(三) 现成软件更新要求

(四) 现成软件版本要求

七、 注册申报资料要求……………………………………………19

(一) 产品注册

(二) 注册变更

(三) 延续注册

八、 参考文献………………………………………………………26 附录I 独立软件技术要求模板……………………………………30

- 2 -

医疗器械软件注册申报资料

指导原则

一、适用范围

本指导原则适用于医疗器械软件的注册申报,包括进口医疗器械和国产III类医疗器械的注册申报,适用的软件开发方式包括自主开发、部分采用现成软件和全部采用现成软件。

医疗器械软件包括独立软件和软件组件:

1)独立软件:作为医疗器械或其附件的软件;

2)软件组件:作为医疗器械或其部件、附件组成的软件。 独立软件同时满足以下三个条件:具有一个或多个医疗用途,无需医疗器械硬件即可完成预期用途,运行于通用计算平台。独立软件包括通用型软件和专用型软件,其中通用型软件基于通用数据接口与多个医疗器械产品联合使用,如PACS、中央监护软件等;而专用型软件基于通用、专用的数据接口与特定医疗器械产品联合使用,如Holter数据分析软件、眼科显微镜图像处理软件等。

软件组件同时满足以下两个条件:具有一个或多个医疗用途,控制(驱动)医疗器械硬件或运行于医用计算平台。软件组件包括嵌入式软件和控制型软件,其中嵌入式软件(即固件)运行于医用计算平台,控制(驱动)医疗器械硬件(可兼有处理功能),如心电图机所含软件、脑电图机所含软件等;而控制型软件运行于通用

- 1 -

计算平台,控制(驱动)医疗器械硬件(可兼有处理功能),如CT图像采集工作站软件、MRI图像采集工作站软件等。

专用型独立软件可以单独注册,也可以随同医疗器械产品注册(此时视为软件组件)。

二、基本原则

软件是无形的产品,没有物理实体,在开发和使用过程中人为因素影响无处不在,软件测试由于时间和成本的限制不能穷尽所有情况,所以软件缺陷无法避免。同时,软件更新频繁且迅速,轻微更新也可能导致严重后果,而且还具有退化问题(即每修复若干个缺陷就会产生一个新缺陷),所以软件缺陷无法根除。因此,软件缺陷可以视为软件的固有属性之一,软件的质量问题不容忽视。

鉴于软件的特殊性,医疗器械软件只有结合风险管理、质量管理和软件工程的要求才能保证安全性与有效性。采用基于风险的方法对医疗器械软件进行监管已是业内共识。

软件风险水平应根据软件安全性级别(YY/T 0664《医疗器械软件 软件生存周期过程》)进行确定,软件安全性级别基于软件损害严重度分为:

A级:不可能对健康有伤害和损坏;

B级:可能有不严重的伤害;

C级:可能死亡或严重伤害。

软件安全性级别应结合软件的预期用途、使用环境和核心功能

- 2 -

(软件在预期使用环境完成预期用途所必需的功能)进行判定。其中预期用途主要考虑软件的临床用途(如诊断、治疗、监护、筛查等)和重要程度(如重要作用、辅助作用、补充作用等),使用环境主要考虑软件的使用场所(如医院、家庭等)、疾病类型(如严重性、紧迫性、传染性等)、患者人群(如成年人、儿童、老年人、女性等)和用户类型(如专业用户、普通用户、患者等),核心功能主要考虑软件的功能类型(如控制驱动、处理分析等)、实现方法(如CT图像重建采用滤波反投影算法还是迭代算法,异常识别采用常规图像处理算法还是人工智能算法等)和复杂程度(如算法规模、参数数量、运算速度等)。

软件安全性级别也可以根据风险管理所确定的风险等级进行判定,安全性级别与风险等级的分级可以不同,但二者存在对应关系,因此可以根据风险等级来判定安全性级别。

申请人应结合自身的质量管理体系,建立与软件风险水平相匹配的软件生存周期过程,包括软件开发过程、软件维护过程、配臵管理过程、风险管理过程和问题解决过程。同时,申请人还应保证软件的信息安全,确保健康信息的保密性、完整性和可得性。

申请人应基于软件安全性级别提交相应的注册申报资料。注册申报资料均源于软件生存周期过程所形成的文档资料,详尽程度取决于软件安全性级别和软件复杂程度,安全性级别和复杂程度越高注册申报资料越多。

尽管独立软件和软件组件在结构和功能上有所不同,风险情况

- 3 -

也存在差异,但软件生存周期过程要求基本一致,注册申报资料的整体要求相同,但在具体要求上有所区别。

三、软件描述文档

软件描述文档基于YY/T 0664《医疗器械软件 软件生存周期过程》制定,用于自主开发医疗器械软件的产品注册。软件描述文档包括基本信息、实现过程和核心算法(详见表1),具体要求如下:

(一)基本信息

1、软件标识

描述软件的名称、型号规格、发布版本、申请人和生产地址。软件组件为申请人内部质量控制所用的软件标识。

2、安全性级别

明确软件安全性级别(A级、B级、C级),并详述确定理由。

3、结构功能

依据软件设计规范(SDS)提供体系结构图和用户界面关系图。 体系结构图用于图示组成模块之间、组成模块与外部接口之间的关系,依据体系结构图描述组成模块(注明选装、版本)的功能、模块关系和外部接口。

用户界面关系图用于描述用户界面之间的关系,依据用户界面

- 4 -

关系图描述临床功能模块(注明选装、版本)的功能、模块关系和外部接口。

4、硬件拓扑

依据软件设计规范(SDS)提供物理拓扑图,图示和描述软件(或组成模块)、通用计算机、医疗器械硬件相互之间的物理连接关系。

5、运行环境

描述软件运行所需的硬件配臵、软件环境和网络条件。其中硬件配臵包括处理器、存储器和外设器件,软件环境包括系统软件、支持软件和安全软件,网络条件包括网络架构(BS、CS)、网络类型(广域网、局域网、个域网)和带宽要求。

6、适用范围

独立软件描述软件的适用范围,软件组件描述医疗器械产品的适用范围。进口医疗器械软件描述原产国注册所批准的适用范围。

7、禁忌症

独立软件描述软件的禁忌症或使用限制,软件组件描述医疗器械产品的禁忌症或使用限制。进口医疗器械软件描述原产国注册所批准的禁忌症或使用限制。

8、注册历史

列明软件在中国的注册情况,包括历次注册的版本和注册证号。同时列明软件在原产国历次注册的日期、版本和管理类别,在其他主要国家和地区的注册历史也可提供。

- 5 -

软件组件描述医疗器械产品的注册历史。

(二)实现过程

1、开发概述

描述软件开发所用的语言、工具和方法,其中工具描述支持软件(含开源软件)和应用软件(第三方软件)的名称、版本和申请人。同时给出开发人员数量、开发时间、工作量(人月数)和代码行总数。

2、风险管理

依据风险管理相关标准提供软件风险管理资料,风险管理资料应另附原始文件。软件组件提供医疗器械产品的风险管理资料。

3、需求规范

A级提交软件需求规范关于软件功能的相应内容,B级和C级提供软件需求规范全文。需求规范应另附原始文件。软件组件如无单独的需求规范文档,可提供医疗器械产品的需求规范文档。

4、生存周期

A级提供软件开发生存周期计划摘要,描述各阶段的划分情况和工作任务。B级在A级基础上提供配臵管理计划摘要和维护计划摘要,描述相应的工具和流程。C级在B级基础上提供设计历史文件(DHF)的文档索引表。

生存周期也可提交申请人软件生存周期过程控制文档、YY/T 0664《医疗器械软件 软件生存周期过程》等标准的核查表,用于替代相应描述。

- 6 -

5、验证与确认

验证是指通过提供客观证据来认定软件某开发阶段的输出满足输入要求,包括代码检查、设计评审、测试等质量保证活动。确认是指通过提供客观证据来认定软件满足用户需求,通常是指在真实或模拟使用环境的测试。可追溯性分析是指追踪需求规范、设计规范、源代码、测试、风险管理之间的关系,分析已识别关系的正确性、一致性、完整性和准确性。

A级提供系统测试、用户测试的计划和报告摘要,描述测试的条件、工具、方法、通过准则和结果。B级提供系统测试、用户测试的计划和报告,并概要介绍各个阶段的验证活动,描述相应的工具、方法和任务。C级在B级基础上提供可追溯性分析报告。

系统测试和用户测试的计划和报告应另附原始文件,测试报告关于测试记录的内容可以提供一个测试记录样例和完整的测试记录清单。验证活动也可以提交申请人软件质量保证文件,用于替代相应描述。

6、缺陷管理

A级描述缺陷管理的工具和流程,给出开发阶段所发现的缺陷总数和已知剩余缺陷数。B级和C级在A级基础上列明已知剩余缺陷情况。已知剩余缺陷情况可另附原始文件。

7、更新历史

所有级别软件均应描述软件版本命名规则,明确软件版本的全部字段及字段含义,确认软件的完整版本和发布版本。

- 7 -

A级列明软件在本次注册时(即本次申报版本与原产国前次注册版本之间)历次软件更新的版本、日期和类型(完善型、适应型、纠正型、预防型)。B级在A级基础上详述本次注册时历次软件更新的具体内容。C级列明软件在原产国历次注册时历次软件更新的版本、日期、类型和具体更新内容。更新历史可另付原始文件。

8、临床评价

临床评价资料包括临床文献资料、临床经验数据和临床试验报告。临床评价资料应另附原始文件。

(三)核心算法

依据软件设计规范(SDS)和使用说明书列明核心算法的名称、类型、用途和所对应的临床功能。

核心算法是指实现软件核心功能所必需的算法,包括成像算法、后处理算法和人工智能算法。其中成像算法是指用于获取医学图像或数据的算法,后处理算法是指改变原始医学图像或数据而产生新临床信息的算法,人工智能算法是指采用人工智能技术进行医学图像或数据分析处理的算法。

算法类型包括公认成熟算法或全新算法。其中公认成熟算法是指源自公开文献专利标准、原理简单明确、上市多年且无不良事件的算法,全新算法是指源自临床研究、科学研究的新算法。

核心算法详尽程度取决于安全性级别和算法类型。当安全性级别为A级时,公认成熟算法和全新算法均需列明算法的名称、类型、

- 8 -

用途和临床功能。当安全性级别为B级和C级时,公认成熟算法需列明算法的名称、类型、用途和临床功能,全新算法在公认成熟算法基础上还应提供安全性与有效性验证资料。

- 9 -

表1:软件描述文档内容框架

医疗器械软件注册申报资料指导原则征求意见

- 10 -

- 11 -

医疗器械软件注册申报资料指导原则征求意见

四、软件更新

(一)基本考量

医疗器械软件更新是指申请人在整个软件生存周期过程中对软件所做的修改。软件更新类型从不同角度出发有不同划分方法。从更新的结果和影响角度出发,软件更新可分为:

1)重大更新:影响到医疗器械安全性或有效性的软件更新;

2)轻微更新:不影响医疗器械安全性和有效性的软件更新。 从更新的目的和范围角度出发,软件更新可分为增强类更新和纠正类更新,其中增强类更新又可分为完善型更新和适应型更新,而纠正类更新又可分为纠正型更新和预防型更新(改自GB/T 20157《信息技术 软件维护》):

1)完善型更新:医疗器械软件交付后,为改变性能、维护性或其他软件属性而进行的软件更新;

2)适应型更新:医疗器械软件交付后,为适应新的运行环境而进行的软件更新;

3)纠正型更新:医疗器械软件交付后,为修正软件已知缺陷而进行的软件更新;

4)预防型更新:医疗器械软件交付后,为修正软件潜在未知缺陷以避免出现运行故障而进行的软件更新。

同时,还有两种特殊情况需要考虑:

1)内部构建(Build):符合软件更新的定义,通过质量管理体系进行控制,申报资料要求与纠正类更新相同。下文如无特别说明,

- 12 -

纠正类更新均包含内部构建;

2)涉及召回的软件更新:包括软件更新导致医疗器械召回、召回处理措施所引发的软件更新,这两种情况均属于重大更新,应按照医疗器械召回的相关法规处理,不属于本指导原则讨论范围。

本指导原则关注软件的安全性与有效性,将软件更新划分为:

1)重大软件更新:影响到医疗器械安全性或有效性的增强类更新,即重大增强类软件更新(含重大完善型更新、重大适应型更新);

2)轻微软件更新:不影响医疗器械安全性或有效性的增强类更新和纠正类更新,包括轻微增强类软件更新(含轻微完善型更新、轻微适应型更新)和纠正类软件更新(含纠正型更新、预防型更新和内部构建)。

医疗器械软件发生重大软件更新应进行许可事项变更,而发生轻微软件更新应通过质量管理体系进行控制,无需进行许可事项变更,待到下次注册(注册变更或延续注册)时提交相应申报资料。

软件生存周期过程模型发生改变(如瀑布模型改为V模型)视为软件的重新开发,应按照医疗器械产品注册的要求提交申报资料。

(二)重大软件更新

根据重大软件更新的定义,凡是影响到医疗器械安全性或有效性的软件更新均为重大软件更新。具体而言,软件更新如影响到医疗器械的预期用途、使用环境或核心功能均视为重大软件更新。

本指导原则所述重大软件更新包括下列情形之一:

1)适应型软件更新:软件运行平台跨越互不兼容的计算平台(含

- 13 -

硬件和软件),如操作系统软件由Windows变为iOS,32位计算平台变为64位计算平台、常规计算平台变为移动计算平台等,而系统软件和支持软件的补丁一般不视为重大软件更新,除非影响到医疗器械的安全性与有效性。

2)完善型软件更新:影响到用户临床决策(包括决策能力、决策结果、决策流程和用户临床行动),或者影响到人员安全(包括患者、用户和其他相关人员),包括但不限于:

— 临床功能改变,如新增临床应用、新增运行模式、采用新核心算法等;

— 软件输出结果改变,如医学图像或数据质量改变、用户界面增加临床信息等;

— 用户使用习惯改变,如用户原有临床工作流程改变、用户界面布局改变等;

— 影响到患者安全,如采用新的软件安全标准、用户界面增加报警信息等。

而核心算法运算速度的单纯性提高、临床工作流程的可配臵化(即用户可以保留原有临床工作流程)、用户界面的文字性修改一般不视为重大更新,除非影响到医疗器械的安全性与有效性。

3)其他软件更新:软件的安全性级别、体系结构、用户界面关系和物理拓扑发生改变。

重大软件更新的范围会随着认知与技术水平的提高、不良事件与召回事件的分析进行动态调整。

- 14 -

(三)软件更新要求

软件发生增强类更新应提交简化软件描述文档,包括基本信息、实现过程和核心算法,要求详见表2。

表2:简化软件描述文档内容框架

医疗器械软件注册申报资料指导原则征求意见

- 15 -

软件发生纠正类更新应提交简化软件申报资料,包括软件更新情况说明、回归测试计划与报告、新增剩余缺陷的风险管理资料。

软件同时发生多种类型的软件更新,应按照风险从高原则提交申报资料,即同时发生重大软件更新和轻微软件更新则按照重大软件更新提交申报资料,同时发生增强类软件更新和纠正类软件更新则按照增强类软件更新提交申报资料。

五、软件版本

(一)基本考量

软件是无形的,只能通过状态管理来保证质量,而软件版本用于标识软件状态,控制软件更新,进而保证软件质量,因此软件版本与软件是相互对应的表里关系,即软件版本是软件标识不可或缺的组成部分,也是实现医疗器械软件可追溯性的重要工具。

申请人无论采用何种名称和形式(如修订号、构建号、发布日期等),只要用于标识软件状态均视为软件版本。申请人制定软件命名规则除了考虑医疗器械自身特点、质量管理体系的要求之外,还要考虑监管的要求,即软件版本命名规则能区分软件更新的类型,可以明确软件的完整版本和发布版本:

1)软件完整版本:体现重大增强类更新、轻微增强类更新、纠正类更新和内部构建(如适用);

- 16 -

医疗器械软件注册申报资料指导原则征求意见

2)软件发布版本:仅体现重大增强类更新。

软件发布版本发生改变应进行许可事项变更,软件完整版本发生改变但发布版本未变无需进行许可事项变更。例如,软件版本命名规则为X.Y.Z.B,其中X表示重大增强类更新,Y表示轻微增强类更新,Z表示纠正类更新,B表示内部构建,则软件完整版本为X.Y.Z.B,而软件发布版本为X,此时X发生变化应进行许可事项变更,而Y、Z和B发生变化无需进行许可事项变更。

软件版本命名规则同样适用于风险从高原则,即不能区分重大软件更新和轻微软件更新则按照重大软件更新处理,不能区分增强类软件更新和纠正类软件更新则按照增强类软件更新处理。

(二)软件版本要求

软件版本命名规则真实性声明应明确软件版本的全部字段及字段含义,确认软件的完整版本和发布版本。

对于独立软件(含专用型独立软件视为软件组件的情况)和控制型软件组件,申请人应在登录界面、主界面等界面体现软件发布版本,在―关于‖、―帮助‖等界面体现软件完整版本,注册检测报告应提供软件完整版本界面和软件发布版本界面的照片。

同时,进口独立软件(含专用型独立软件视为软件组件的情况)应在原产国主管部门出具的上市证明材料中体现软件发布版本,如CFG证书、EC符合性声明、出口证明等。

六、现成软件

(一)基本考量

- 17 -

随着信息技术的快速发展,医疗器械使用现成软件的情况越来越普遍,但是现成软件不能完全满足医疗器械的预期功能,而且申请人也未对现成软件进行完整生存周期控制,因此使用现成软件具有不确定性,风险相对较高。由于申请人要对医疗器械最终的安全性与有效性负责,因此应采用基于风险管理的方法对现成软件进行质量管理。

现成软件具体分为:

1)成品软件:已开发且通常可得到的,但申请人未进行完整生存周期控制的软件,包含商业现货软件(COTS)和免费软件;

2)遗留软件:申请人以前开发但现在不能得到足够开发记录的软件;

3)外包软件:申请人委托第三方开发的定制软件。

目前,本指导原则所述的现成软件仅限于应用软件,今后将在适当时机下扩至系统软件和支持软件。但申请人应保证系统软件和支持软件的质量和安全。

(二)现成软件要求

医疗器械软件的开发方式不同,采用的现成软件类型不同,软件质量保证措施也不同,注册申报资料也有所差异。

1、部分采用现成软件

对于部分采用现成软件的方式,成品、遗留和外包软件的资料要求详见表3,其中:

表3:部分现成软件内容框架

医疗器械软件注册申报资料指导原则征求意见

- 18 -

(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级明确现成软件的版本命名规则。

- 19 -

医疗器械软件注册申报资料指导原则征求意见

(9)核心算法

B级和C级列明现成软件核心算法的名称(或编号)、用途和所对应的临床功能。

2、全部采用现成软件

对于全部采用现成软件的方式,申报要求如下:

(1)成品软件提供外购合同复印件(或声明)和软件描述文档(不适用条款说明理由),如已在中国注册提供注册证复印件;

(2)遗留软件提供注册证复印件和软件描述文档(不适用条款说明理由),并提供遗留软件上市后临床评价资料;

(3)外包软件提供外包合同复印件(或声明)和软件描述文档。

(三)现成软件更新要求

现成软件的更新类型、更新注册要求和风险从高原则与自主开发软件相同,注册申报资料要求与自主开发软件有所差异。

现成软件发生增强类更新应参照自主开发增强类更新的要求提交简化现成软件描述文档,其中不适用条款说明理由。而现成软件发生纠正类更新与自主开发软件纠正类更新要求相同,提交简化软件申报资料即可。

对于部分采用现成软件的情况,自主开发软件发生更新按照自主开发软件更新要求提交申报资料,现成软件发生更新按照现成软件更新要求提交申报资料。

(四)现成软件版本要求

- 20 -

现成软件版本同样要考虑监管要求和风险从高原则。现成软件开发方的软件版本命名规则如符合监管要求,申请人可以直接采用开发方的软件版本和版本命名规则。

申请人应在软件版本命名规则真实性声明中明确现成软件的版本及版本命名规则。

七、注册申报资料要求

(一)产品注册

1、产品名称与结构组成

(1)独立软件

产品名称应为通用名称,可结合人体部位(如胸部、心脏等)、临床科室(如骨科、神经外科等)、处理对象(如CT图像、MRI图像、心电数据等)和功能用途(如计划、处理、CAD等)进行命名,应符合相关法规、规范性文件的要求。

结构组成应包括物理组成和逻辑组成,其中物理组成应描述软件的存储介质或交付方式,如光盘、U盘、预装于计算机交付等;结构组成应描述软件的临床功能模块,包括客户端和服务器端(如适用),注明选装和模块版本(如适用)。

(2)软件组件

软件组件无相应要求。专用型独立软件视为软件组件时,应在结构组成中明确软件的名称、型号规格和发布版本。

2、软件研究资料

申请人应单独提供一份软件描述文档,具体要求详见第三节。鉴

- 21 -

于进口软件不一定在中国同步注册,即该软件在境外已多次注册变更但在中国为首次产品注册,此时软件描述文档追溯至境外首次产品注册的技术资料。

同时,申请人还应单独出具一份软件版本命名规则声明,具体要求详见第五节。

3、产品技术要求

(1)独立软件

独立软件的技术要求应在―产品型号/规格及其划分说明‖中明确软件名称、型号规格、发布版本与版本命名规则,而―性能指标‖分为通用要求、专用要求和安全要求,其中通用要求应符合GB/T 25000.51《软件工程 软件产品质量要求与评价(SQuaRE) 商业现货(COTS)软件产品的质量要求与测试细则》相应条款的要求,专用要求应符合相应标准(如放射治疗相关标准)的要求,安全要求应符合相应安全标准(如报警、放射治疗相关标准)的要求。

独立软件技术要求模板详见附录I。

(2)软件组件

软件组件应在医疗器械产品技术要求中进行规范,其中―产品型号/规格及其划分说明‖应明确软件名称、型号规格、发布版本与版本命名规则,―性能指标‖应明确软件的全部临床功能。对于控制型软件组件,―产品型号/规格及其划分说明‖还应明确通用计算平台的最低要求(含硬件配臵、软件环境和网络条件)。

专用型独立软件视为软件组件时,要求与软件组件相同。

- 22 -

4、注册单元划分原则

(1)独立软件

独立软件的注册单元以管理类别、预期用途、处理对象和临床功能模块作为划分原则。

不同管理类别的独立软件应作为不同注册单元进行申报,在无法分割的情况下可作为一个注册单元并按照较高的管理类别进行申报。

不同预期用途的独立软件应作为不同注册单元进行申报,按照预期用途大体上可分为治疗计划类、诊断类、监护类和信息管理类。

不同处理对象的独立软件应作为不同注册单元进行申报,按照处理对象大体上可分为图像类和数据类。

对于功能庞大复杂的独立软件,应依据临床功能模块的类型和数量划分注册单元,每个注册单元所包含的模块数量应适中。按照模块功能可划分为通用功能软件和专用功能软件,其中通用功能软件的功能较为简单,但支持多种模式的图像或数据,而专用功能软件仅支持单一模式的图像或数据,但功能较为复杂。

例如,某PACS包含数十个独立的临床功能模块,并含有CAD类模块,可以拆分为一个通用功能软件和多个专用功能软件,其中通用功能软件作为软件平台提供基本功能和共用功能,而专用功能软件只处理一种成像模式的图像但提供复杂功能和专用功能,CAD类模块应作为单独的注册单元。

(2)软件组件

软件组件不符合医疗器械的定义,不能单独申报注册,应随同医

- 23 -

疗器械产品进行申报注册,注册单元与医疗器械产品相同。

专用型独立软件视为软件组件时,要求与软件组件相同。

5、检测单元划分原则

(1)独立软件

独立软件的检测单元原则上与注册单元一致,但如有多个互不兼容的运行环境,则每个不兼容的运行环境均应作为一个检测单元。

(2)软件组件

软件组件的检测单元与医疗器械产品相一致,但医疗器械产品如包含多个软件组件或多个版本的软件组件,则每个软件组件或每个版本软件组件均应作为一个检测单元,除非检测单元可以完整覆盖注册单元全部情况。

专用型独立软件视为软件组件时,检测单元原则上与软件组件相同,但如有多个互不兼容的运行环境,则每个不兼容的运行环境均应作为一个检测单元。

6、临床评价资料

(1)独立软件

独立软件应根据相关法规、规范性文件的要求提交相应的临床评价资料。

独立软件的非临床功能(如患者信息管理、打印等)可通过软件测试进行确认。

独立软件的临床功能应依据《医疗器械临床评价技术指导原则》提交相应的临床评价资料。对于采用人工智能算法实现的临床功能

- 24 -

(如计算机辅助检测、分类和诊断等CAD类功能),应提交相应的临床试验资料。

(2)软件组件

软件组件应与医疗器械产品整体开展临床评价工作,并提交医疗器械产品的临床资料。如软件组件具有处理功能,相应功能的临床资料要求与独立软件相同。

专用型独立软件视为软件组件时,要求与独立软件相同。

7、现成软件(如适用)

现成软件的申报要求和版本要求详见第六节。

8、说明书

说明书应符合相关的法规、规范性文件、国家标准、行业标准的要求,体现软件全部功能(包含安全功能)。

对于独立软件(含专用型独立软件视为软件组件的情况)和控制型软件组件,说明书应明确软件发布版本。

9、其他说明

医疗器械注册证―其他内容‖注明软件安全性级别,并注明―申请人应在后续注册时提交软件更新资料‖。

(二)注册变更

1、变更情况声明

明确软件和现成软件(如适用)的版本命名规则、发布版本、完整版本和版本变更情况。

2、软件研究资料

- 25 -

医疗器械注册变更应根据软件更新情况提交相应申报资料:

(1)涉及重大更新:单独提交一份简化软件描述文档,具体要求详见第四节;

(2)涉及轻微增强类更新:单独提交一份简化软件描述文档,具体要求详见第四节;

(3)仅发生纠正类更新:提交简化软件申报资料,具体要求详见第四节;

(4)未发生软件更新:出具真实性声明。

3、产品技术要求

(1)独立软件

独立软件技术要求应体现软件更新情况,包括―产品型号/规格及其划分说明‖、―性能指标‖和附录。

(2)软件组件

如适用,医疗器械产品技术要求应体现软件组件的更新情况,包括―产品型号/规格及其划分说明‖中的软件信息、―性能指标‖中的软件临床功能。

专用型独立软件视为软件组件时,要求与软件组件相同。

4、现成软件(如适用)

医疗器械注册变更应根据现成软件更新情况提交相应申报资料:

(1)涉及重大更新:单独提交一份简化现成软件描述文档,具体要求详见第六节;

(2)涉及轻微增强类更新:单独提交一份简化现成软件描述文

- 26 -

档,具体要求详见第六节;

(3)仅发生纠正类更新:提交简化软件申报资料,具体要求详见第四节;

(4)未发生现成软件更新:出具真实性声明。

5、说明书(如适用)

说明书应体现软件全部功能(包含安全功能),明确软件发布版本,提供变化情况说明。

(三)延续注册

1、产品未变化声明

明确软件和现成软件(如适用)的版本命名规则、发布版本和完整版本。

2、产品分析报告(如适用)

根据原医疗器械注册证所载明的关于提交软件更新资料的要求,医疗器械延续注册应提交相应申报资料:

(1)涉及轻微增强类软件更新:单独提交一份简化软件描述文档和简化现成软件描述文档,具体要求详见第四节和第六节;

(2)仅发生纠正类软件更新:提交简化软件申报资料,具体要求详见第四节。

3、特殊情形

如涉及重大软件更新,前次注册所批准的事项可以延续注册。

八、参考文献

[1]《医疗器械注册管理办法》(国家食品药品监督管理总局令第4号)

- 27 -

[2]《医疗器械说明书和标签管理规定》(国家食品药品监督管理总局令第6号)

[3]《医疗器械召回管理办法(试行)》(卫生部令第82号)

[4] 国家食品药品监督管理总局关于发布医疗器械产品技术要求编写指导原则的通告(20xx年第9号)

[5] 国家食品药品监督管理总局关于公布医疗器械注册申报资料要求和批准证明文件格式的公告(20xx年第43号)

[6] 食品药品监管总局关于实施《医疗器械注册管理办法》和《体外诊断试剂注册管理办法》有关事项的通知(食药监械管[2014]144号)

[7] 关于《医疗器械临床评价技术指导原则》征求意见的通知(食药监械管便函[2014]46号)

[8] GB/T 13702-1992《计算机软件分类代码》

[9] GB/T 18492-2001《信息技术 系统及软件完整性级别》

[10] GB/T 11457-2006《信息技术 软件工程术语》

[11] GB/T 20157-2006《信息技术 软件维护》

[12] GB/T 19003-2008《软件工程 GB/T 19001-2000应用于计算机软件的指南》

[13] GB/T 25000.51-2010《软件工程 软件产品质量要求与评价(SQuaRE) 商业现货(COTS)软件产品的质量要求与测试细则》

[14] YY 0637-2013《医用电气设备 放射治疗计划系统的安全要求》

[15] YY 0709-2009《医用电气设备 第1-8部分:安全通用要求 并列标准 医用电气设备和医用电气系统中报警系统的测试和指南》

[16] YY 0721-2009《医用电气设备 放射治疗记录与验证系统的安全》

[17] YY 0775-2010《远距离放射治疗计划系统 高能X(γ)射束剂量计算准确性要求和试验方法》

[18] YY 0831.1-2011《γ射束立体定向放射治疗系统 第1部分:头部多源γ射束立体定向放射治疗系统》

[19] YY 0832.1-2011《X射线放射治疗立体定向及计划系统 第1部分:头部X射线放射治疗立体定向及计划系统》

[20] YY/T 0287-2003《医疗器械 质量管理体系法规要求》

[21] YY/T 0316-2008《医疗器械 风险管理对医疗器械的应用》

[22] YY/T 0664-2008《医疗器械软件 软件生存周期过程》

[23] YY/T 0708-2009《医用电气设备 第1-4部分:安全通用要求 并列标准 可编程医用电气系统》

[24] YY/T 0887-2013《放射性粒籽植入治疗计划系统剂量计算要求和试验方法》

- 28 -

[25] YY/T 0889-2013《调强放射治疗计划系统性能和试验方法》

[26] FDA, Do It by Design - An Introduction to Human Factors in Medical Devices, December, 1996

[27] FDA, Deciding When to Submit a 510(k) for a Change to an Existing Device, January 10, 1997

[28] FDA, Reviewer Guidance for a Premarket Notification Submission for Blood Establishment Computer Software, January 13,1997

[29] FDA, Design Control Guidance for Medical Device Manufacturers, March 11, 1997

[30] FDA, Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices, May 29,1998

[31] FDA, Guidance for Industry, FDA Reviewers and Compliance on Off-The-Shelf Software Use in Medical Devices, September 9,1999

[32] FDA, Guidance for the Submission of Premarket Notifications for Medical Image Management Devices, July 27, 2000

[33] FDA, General Principles of Software Validation; Final Guidance for Industry and FDA Staff, January 11, 2002

[34] FDA, Cybersecurity for Networked Medical Devices Containing Off-the-Shelf Software, January 14, 2005

[35] FDA, Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices, May 11, 2005

[36] FDA, Guidance for Industry and FDA Staff - Modifications to Devices Subject to Premarket Approval (PMA) - The PMA Supplement Decision, December 11, 2008

[37] FDA, Guidance for Industry and Food and Drug Administration Staff - Computer-Assisted Detection Devices Applied to Radiology Images and Radiology Device Data - Premarket Notification [510(k)] Submissions, July 3, 2012

[38] FDA, Guidance for Industry and FDA Staff - Clinical Performance Assessment: Considerations for Computer-Assisted Detection Devices Applied to Radiology Images and Radiology Device Data - Premarket Approval (PMA) and Premarket Notification [510(k)] Submissions, July 3, 2012

[39] FDA, Mobile Medical Applications - Guidance for Industry and Food and Drug Administration Staff, September 25, 2013

- 29 -

[40] FDA, Content of Premarket Submissions for Management of Cybersecurity in Medical Devices - Guidance for Industry and Food and Drug Administration Staff, October 2, 2014

[41] FDA, General Wellness: Policy for Low Risk Devices - Draft Guidance for Industry and Food and Drug Administration Staff, January 20, 2015

[42] FDA, Medical Device Data Systems, Medical Image Storage Devices and Medical Image Communications Devices - Guidance for Industry and Food and Drug Administration Staff, February 9, 2015

[43] MEDDEV 2.7/1 Rev.3, Clinical evaluation: Guide for manufacturers and notified bodies, December 2009

[44] MEDDEV 2.7/4, Guidelines on Clinical investigations: a guide for manufacturers and notified bodies, December 2010

[45] MEDDEV 2.1/6, Qualification and Classification of standalone software, January 2012

[46] NB-MED/2.2/Rev4, Software and Medical Devices, March 29, 2010

[47] Team-NB, Frequently Asked Questions related to the Implementation of EN 62304:2006 with respect to MDD 93/42/EEC, April 5, 2013

[48] IEC 62366 Ed1.1:2014, Medical devices - Application of usability engineering to medical devices

[49] IEC/TR 80002-1:2009, Medical device software - Part 1: Guidance on the application of ISO 14971 to medical device software

[50] IEC80001-1:2010, Application of risk management for IT-networks incorporating medical devices - Part 1: Roles,responsibilities and activities

[51] IEC/TR 80001-2-1:2012, Application of risk management for IT-networks incorporating medical devices - Part 2-1: Step-by-step risk management of medical IT-networks – Practical applications and examples

[52] IEC/TR 80001-2-2:2012, Application of risk management for IT-networks incorporating medical devices - Part 2-2: Guidance for the disclosure and communication of medical device security needs, risks and controls

[53] IEC/TR 80001-2-3:2012, Application of risk management for IT-networks incorporating medical devices - Part 2-3: Guidance for wireless networks

[54] IEC/TR 80001-2-4:2012, Application of risk management for IT-networks incorporating medical devices - Part 2-4: Application guidance - General implementation guidance for healthcare delivery organizations

- 30 -

[55] IEC 62304 am1, Medical device software - Software life cycle processes

[56] IEC 82304-1, Health Software - Part 1: General requirements for product safety

[57] IEC/TR 80002-2, Medical device software - Part 2: Validation of software for regulated processes

[58] IMDRF/UDI WG/N7FINAL:2013, UDI Guidance: Unique Device Identification of Medical Devices,December18, 2013

[59] IMDRF/SaMD WG/N10FINAL:2013, Software as a Medical Device: Key Definitions, December18, 2013

[60] IMDRF/SaMD WG/N12FINAL:2014, Software as a Medical Device: Possible Framework for Risk Categorization and Corresponding Considerations,September18, 2014

- 31 -

附录I:独立软件技术要求模板

医疗器械产品技术要求

医疗器械产品技术要求编号:

产品名称

1. 产品型号/规格及其划分说明

1.1 软件型号规格

1.2 软件发布版本

1.3 软件版本命名规则

明确软件完整版本的全部字段及字段含义

2. 性能指标

注:斜体字部分应详细描述

2.1 使用手册要求

2.1.1 可用性

使用手册对于该产品的潜在需方和用户应是可用的。

2.1.2 内容

2.1.2.1使用手册应包含潜在需方所需的信息,以便评价该软件其需要的适用性。

2.1.2.2 使用手册应排除内部的不一致。

2.1.2.3 使用手册中包括的说明应是可测试的或可验证的。

2.1.3 标识和标示

2.1.3.1 使用手册应显示唯一的标识。

列明全部使用手册的名称

- 32 -

2.1.3.2 COTS软件产品应以其名称、版本和日期指称。

2.1.3.3 使用手册应包含供方和至少一家销售商、(当适用时)电子商务销售商或分销商的名称和地址。

2.1.3.4使用手册应标识该软件能完成的预期的工作任务和服务。

2.1.3.5当由法律或行政机构界定的要求适用于COTS软件产品、而供方想要声称符合于相应的需求文档时,则产品说明应标识出这些需求文档。

2.1.3.6使用手册应指明COTS软件产品期望在单一系统上供多个并发最终用户使用或供一个最终用户使用,并且应说明在所要求的系统的所陈述的性能级别上可行的最大并发最终用户数。

明确软件最大并发用户数(患者数)

2.1.3.7当使用手册引证已知的对其他软件的用户可调用的接口时,则应标识出这些接口或软件。

明确软件的通用接口(如Dicom、HL7)、产品接口(可联合使用的独立软件和医疗器械硬件)

2.1.3.8使用手册应以适当的引用文档指明COTS软件产品在何处依赖于特定软件和(或)硬件。

明确软件运行所必备的独立软件、医疗器械硬件

2.1.3.9使用手册应陈述是否对运行COTS软件产品提供支持。

2.1.3.10使用手册应陈述是否提供维护。如果提供维护,则使用手册应陈述所提供的维护服务。

2.1.4 功能性陈述

2.1.4.1使用手册应提供该产品中最终用户可调用的功能的概述。

依据使用手册描述软件的全部临床功能

2.1.4.2使用手册应说明所有的关键功能。

决定软件安全性级别的临床功能

2.1.4.3当有软件组件的选项和版本时,应予以指明。

明确软件的可选模块、模块版本

2.1.4.4对用户功能性的所有已知的限制均应加以说明。

依据使用手册描述软件的使用限制

- 33 -

2.1.4.5当提供对软件的未授权访问(不管是偶然的还是故意的)的预防措施时,则使用手册应包含这种信息。

明确软件的用户访问控制管理机制

2.1.5 可靠性陈述

2.1.5.1在遇有用户接口出错、应用程序自身的逻辑出错、系统或网络资源可用性引发差错的情况下,使用手册应就软件的继续运行能力作出说明。

明确软件出错后继续运行的能力

2.1.5.2使用手册应包括关于数据保存和恢复规程的信息。

明确软件出错后数据保存与恢复能力

2.1.6易用性陈述

2.1.6.1使用手册应规范用户接口(用户界面)的类型。

明确软件的用户界面类型

2.1.6.2使用手册应规定使用和操作该软件所要求的专门知识。

明确软件的用户类型(如专业用户、普通用户、患者等)

2.1.6.3当该软件能由用户作适应性修改时,则应标识用于修改的工具或规程及其使用条件。

2.1.6.4当预防版权侵犯的技术保护妨碍易用性时,则应陈述这种保护。

明确软件版权保护技术

2.1.6.5使用手册应包括可访问性的规定标示,特别是对有残疾的用户和存在语言差异的用户。

明确软件所支持的语言种类

2.1.7 效率陈述

明确软件在特定配置条件下完成典型临床功能所需的时间。

2.1.8 维护性陈述

明确软件向用户提供的维护信息类型。

2.1.9 可移植性陈述

2.1.9.1使用手册应规定将该软件投入使用的不同配置或所支持的配置(硬件、软件)。

明确软件运行所需的通用硬件配置、通用软件环境和网络条件,包括服务器

- 34 -

端和客户端的要求

2.1.9.2使用手册应提供安装规程信息。

明确软件安装方式(如用户自行安装、制造商安装)

2.2 用户文档集要求

2.2.1 完备性

2.2.1.1用户文档集应包含使用该软件必需的信息。

2.2.1.2用户文档集中将会说明使用手册中所陈述的所有功能以及最终用户能够使用的所有功能

2.2.1.3用户文档集中将会说明可靠性特征及其操作。

2.2.1.4用户文档集中应列出是的本产品失效或发生差错的条件,特别是那些会引起数据丢失的条件需要详细说明。

2.2.1.5用户文档集将会给出本产品存储的备份和恢复指南。

2.2.1.6用户文档集应该对本产品的所有的关键功能提供完备的细则信息和参考信息。

2.2.1.7用户文档集应说明在使用手册中给出的所有限制。

2.2.1.8用户文档集应当说明产品安装所要求的最小和最大磁盘空间。

2.2.1.9用户文档集中要包括用户可以进行应用程序配置所需的所有信息。

2.2.1.10 在用户进行应用程序配置时,用户文档集应给出验证用户是否正确配置的提示信息说明。

2.2.1.11如果用户文档集分若干部分提供,在该集合中至少有一处应标识出所有的部分。

2.2.2 正确性

2.2.2.1用户文档集中的所有信息应当都是正确的。

2.2.2.2用户文档集中不应出现有歧义的信息。

2.2.3 一致性

2.2.3.1用户文档集中的各文档不应自相矛盾、互相矛盾以及与使用手册矛盾。

2.2.4 易理解性

2.2.4.1 用户文档集应使用用户可以理解的术语进行文档描述,方便用户的理解。

2.2.4.2 用户文档集应提供经编排的文档清单为用户理解文档提供便利。

- 35 -

2.2.5 易学性

2.2.5.1 用户文档集应为用户学会如何使用本产品提供必要的信息。

2.2.6 可操作性

2.2.6.1如果用户文档集不以印刷的形式提供,则文档集应指明是否可以被打印,如果可以打印,那么指出如何获得打印件。

2.2.6.2卡片和快速参考指南以外的用户文档集,应给出目次(或主题词列表)和索引。

2.2.6.3对于不常用的术语和首字母缩略语,用户文档集应加以定义。

2.3 软件质量要求

2.3.1 功能性

2.3.1.1 功能性安装之后,软件的功能是否能完成应是可识别的。

2.3.1.2 在给定的限制范围内,使用相应的环境设施、器材和数据,用户文档集中所陈述的所有功能应是可执行的。

依据软件用户界面按照“一级目录,二级目录,三级目录,功能描述”进行列表描述。

2.3.1.3 按照用户文档集中所有的陈述,软件的功能应是可执行的。

2.3.1.4 软件应符合使用手册所引用的任何需求文档中的全部需求。

2.3.1.5 软件不应自相矛盾,并且不与使用手册和用户文档集矛盾。

2.3.1.6 由遵循用户文档集的最终用户对软件操作进行的控制与软件的行为应是一致的。

2.3.2 可靠性

2.3.2.1 软件必须按照用户文档集中定义的可靠性特征来运行。

2.3.2.2 与差错处置相关的功能应与使用手册和用户文档集中的陈述一致。

2.3.2.3 在用户文档集中陈述的限制范围内使用时,软件不应丢失数据。

2.3.2.4 软件应识别违反句法条件的输入,并且不应作为许可的输入加以处理。

2.3.3 易用性

2.3.3.1 有关软件执行的各种问题、消息和结果都应是易理解的。

2.3.3.2 软件出错消息应指明如何改正差错或要报告差错向谁联系。

2.3.3.3 软件应以最终用户易于理解的形式提供信息,即以可见易读的文本或图

- 36 -

形输出,或以易听的音频输出。

2.3.3.4 出自软件的消息应设计成使最终用户易于理解的形式。

明确软件的消息类型

2.3.3.5 屏幕输入格式、报表和其他输出对用户来说应是清晰且易理解的。

2.3.3.6 对具有严重后果的功能的执行应是可逆的,或者软件应给出这种后果的明显警告,并且在这种命令执行前要求确认。

2.3.3.7 借助用户接口、帮助功能或用户文档集提供的手段,最终用户应能够学习如何使用某一功能。

2.3.3.8 当遇有执行某一功能其响应时间超出通常预期限度会引起冲突时,最终用户应被告知。

2.3.3.9 每一元素(数据媒体、文件等)均应带有产品标识,如果有两种以上的元素,则应附上标识号或标识文字。

2.3.4 效率

应符合使用手册中有关效率的陈述。

2.3.5 维护性

应符合使用手册中有关维护性的陈述。

2.3.6 可移植性

2.3.6.1 如果用户能够实施安装、遵循安装文档中的信息应能成功地安装软件。

2.3.6.2 对于软件应用程序的成功安装和正确运行,应就使用手册中列出的所有支持平台和系统加以验证。

2.3.6.3 当用户能够实施安装、且该软件对已安装的任何部件具有任何共存性约束时,则这种约束应在安装前予以陈述。

2.3.6.4 软件应向用户提供移去或卸载所有已安装的部件的方法。

2.4专用要求 (如适用)

注:依据相应标准条款逐条描述

2.4.1 YY 0775(如适用)

??

2.5安全要求 (如适用)

注:列明相应安全标准名称即可

- 37 -

2.5.1 YY 0709(如适用)

2.5.2 YY 0637(如适用)

2.5.3 YY 0721(如适用)

??

3. 检验方法

3.1使用手册要求的符合性检验

通过检查使用手册、标识标签验证2.1的符合性。

3.2用户文档集要求的符合性检验

通过检查用户文档集验证2.2的符合性。

3.3软件质量要求的符合性检验

通过实际操作验证2.3的符合性。

3.4 专用要求检验方法(如适用)

3.4.1依据YY 0775的方法进行检验(如适用)。 ??

3.5 安全要求检验方法(如适用)

3.5.1 依据YY 0709的方法进行检验(如适用)。

3.5.2 依据YY 0637的方法进行检验(如适用)。

3.5.3 依据YY 0721的方法进行检验(如适用)。 ??

4. 术语(如适用)

4.1 ??

4.2 ??

??

(分页)

附录

1. 体系结构图及必要注释

2. 用户界面关系图及必要注释

3. 物理拓扑图及必要注释

- 38 -

医疗器械软件注册申报资料

指导原则编制说明

一、指导原则编写的目的和依据

本指导原则旨在为申请人准备医疗器械软件注册申报资料提供具体建议,并规范医疗器械软件的技术审评要求。

本指导原则以现行的CFDA相关法规、国家标准、行业标准为基础,参考了相关的国际标准、国外法规要求以及技术指导文件,特别是借鉴了IMDRF相关工作组的文件。

二、指导原则有关内容的说明

1、软件是无形的,具有特殊性,现行法规没有明确软件的具体监管要求。为了达到监管目的并促进行业发展,本指导原则在现行法规框架下针对软件的特殊性进一步明确了软件的监管要求,特别是对软件更新的监管要求。

2、本指导原则是医疗器械软件的通用指导原则,其他涉及软件的医疗器械指导原则可在本指导原则基础上进行有针对性的调整、修改和完善。

3、软件需要结合风险管理、质量管理和软件工程的要求才能保证质量,因此良好的软件生存周期过程对于保证软件质量至关重要。申请人应考虑基于YY/T 0664-2008《医疗器械软件 软件生存周期过程》建立起与安全性级别相匹配的软件生存周期过程,并作为自身质量管理体系的重要组成部分。

4、软件描述文档于20xx年12月1日(YY/T 0708-2009《医用电气 - 39 -

设备 第1-4部分:安全通用要求 并列标准 可编程医用电气系统》实施时间)开始要求,基于四年多的实施情况和反馈意见进行了修改和调整。部分条款名称进行了文字性修改,以保证用语更规范更准确,具体为:―产品标识‖改为―软件标识‖,―硬件关系‖改为―硬件拓扑‖,―上市历史‖改为―注册历史‖,―开发综述‖改为―开发概述‖、―需求规格‖改为―需求规范‖、―修订历史‖改为―更新历史‖。同时,部分条款内容也进行了修改和调整,具体为:―结构功能‖强化了用户界面关系图和临床功能模块的要求;―适用范围‖和―禁忌症‖明确进口产品描述原产国的情况,删除了适用人群的要求;―注册历史‖将―在原产国、美国、欧盟和日本等主要国家和地区首次注册‖改为―在原产国历次注册‖;―开发概述‖删除了生存周期模型和控制文档总数的要求;―需求规范‖简化了A级软件要求;―生存周期‖将―各阶段输入输出文档‖改为―设计历史文件(DHF)的文档索引表‖,细化了附件要求;―验证与确认‖删除了单元测试覆盖率和集成测试集成策略的要求,简化了测试报告的资料要求,C级软件增加了可追溯性分析报告的要求,验证活动细化了附件要求;―更新历史‖强化了更新具体内容的要求;―核心算法‖增加了成像算法,为了避免涉及商业秘密并参考IMDRF相关要求将―原理‖改为―临床功能‖,A级软件统一了公认成熟算法和全新算法的要求。

5、软件可追溯性分析是保证软件质量的重要技术手段,美国和欧盟均要求全面开展软件可追溯性分析工作。考虑到境内申请人存在一定实施难度,故本指导原则仅对C级软件进行了要求,A级软件和B - 40 -

级软件未做要求。但从技术发展趋势而言,今后将在适当时机下要求申请人全面开展软件可追溯性分析工作。

6、重大软件更新和轻微软件更新并不存在着清晰明确的划分界线,需要具体情况具体分析。本指导原则综合考虑监管目标和行业发展的关系,基于现有的认知水平、技术能力和监管资源明确了重大软件更新的范围,今后会随着认知与技术水平的提高、不良事件与召回事件的分析对重大软件更新的范围进行动态调整。

7、软件是无形的,只能通过状态管理来保证质量。软件版本用于标识软件状态和控制软件更新,与软件是相互对应的表里关系,即软件版本是软件标识不可或缺的组成部分,因此可以基于软件版本实现软件监管目的,特别是对软件更新的监管,但前提是软件版本命名规则是真实有效的。

8、本指导原则所述现成软件仅包含应用软件,暂不包含系统软件和支持软件。这是基于当前技术审评侧重的考虑,并不意味申请人可以放弃对系统软件和支持软件的风险管理,现成软件的范围今后将在适当时机下扩至系统软件和支持软件。同时,也是基于现成软件仅包含应用软件的考虑,现成软件的软件描述文档增加了核心算法的要求,但内容进行了简化;而对于全部采用遗留软件的开发方式,增加了遗留软件上市后临床评价资料的要求。

9、独立软件目前尚无医疗器械行业产品标准,技术要求暂以通用软件产品标准GB/T 25000.51-2010《软件工程 软件产品质量要求与评价(SQuaRE) 商业现货(COTS)软件产品的质量要求与测试细 - 41 -

则》作为参考基础,但由于该标准并非医疗器械行业标准,相应要求并不能完全满足监管要求,因此技术要求模板进行了适当调整。今后,独立软件技术要求模块也会随着国家标准和行业标准的实施情况进行相应调整。

10、由于医疗器械软件的类型和功能众多,难以统一临床评价要求,本指导原则所述临床资料的要求仅为一般性原则,申请人应根据相关法规要求和软件自身特点开展相应临床评价工作。

11、技术审评需要基于说明书评价软件当前状态,因此说明书应真实、准确和完整的体现软件当前状态。由于软件更新情况复杂,某些情况下仅依靠说明书的变化内容无法评估软件当前状态,特别是对重大软件更新。因此,软件更新仍需要提交软件当前状态下的全部说明书,并提交变化情况说明,除非软件更新内容未在说明书中体现。

12、随着网络技术的快速发展,越来越多的医疗器械具有联网功能,信息安全问题随之产生,美国和欧盟均加强了医疗器械信息安全的监管要求。考虑到信息安全问题并不限于软件,我国医疗器械信息安全工作尚处于起步阶段,本指导原则主要针对软件的信息安全提出了基本要求,今后将在适当时机下单独制定医疗器械信息安全技术审评的指导原则。

三、指导原则编写单位

本指导原则的编写由医疗器械监管人员、技术审评人员、检测人员、临床专家、工程专家、软件专家、制造商软件开发专家共同完成。 - 42 -

更多相关推荐:
医疗器械质量手册

医疗器械质量手册,内容附图。

医疗器械质量手册

1範圍ISO13485第1章11總則ISO13485第11節本質量手冊作為除無菌醫療器械有源植入性醫療器械和植入性醫療器械以外的其他一般醫療器械的設計和製造的總要求本手冊旨在向本公司各級人員和相關方明確傳達和明...

医疗器械质量手册

公司QGMFRS01质量手册第A版第0次修改公司质量手册版号A版分发号受控状态发布日期实施日期年月年月日日公司QGMFRS01质量手册第A版第0次修改A批准页编制日期年月日批准日期年月日公司QGMFRS01质量...

医疗器械质量手册A

新疆亚胜医药有限公司医疗器械质量手册版号A版分发号101受控状态受控发布日期20xx年09月20日实施日期20xx年09月20日A批准页编制批准20xx20xx年09月20日年09月20日日期日期C发布令本质量...

医疗器械公司质量手册

受控编号XXXX医疗器械有限公司第A0版文件编号XXQBPS010185质量手册包括程序文件依据YYT028720xx编制审核批准20XX0528发布20XX0528实施XXXX医疗器械有限公司发布质量手册发布...

医疗器械公司质量手册

受控编号XXXX医疗器械有限公司第A0版文件编号XXQBPS010185质量手册包括程序文件依据YYT028720xx编制审核批准20XX0528发布20XX0528实施XXXX医疗器械有限公司发布质量手册发布...

医疗器械经营企业质量手册

有限公司QLYBLZS01质量手册第A版第0次修改有限公司质量手册版号A版分发号201受控状态受控发布日期20xx年9月10实施日期20xx年9月10日日有限公司QLYBLZS01质量手册第A版第0次修改A批准...

医疗器械经营企业质量手册

郑州科乔医疗器械有限公司QLYBLZS01质量手册第A版第0次修改郑州医疗器械有限公司质量手册版号A版分发号201受控状态受控发布日期20xx年12月20实施日期20xx年12月20日日1郑州科乔医疗器械有限公...

公司质量手册范本

YXZS01依据GBT19xx120xxidtISO900120xx第1版编制张爱英审核李俊批准李金民受控状态受控非受控分发号20xx年5月1日发布20xx年5月1日实施目录01手册发布令02管理者代表任命书0...

质量手册范本

xxxxxxxxx制造有限公司ISO900120xx9723EC指令质量手册文件编号BXQM20xx生效时间20xx年05月10日版本号A修改次数0页码第1页共39页xxxxxxxxx制造有限公司ISO9001...

质量手册范本

质量手册目录0.1发布令┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄-┄┄20.2企业简介┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄--┄30.3质量手册说明┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄-…

20xx质量手册编写范本

编号QXXXX20xx质量手册依据GBT19xx120xx第1版编制受控状态审核分发号批准修改状态第0次修订XXXX有限公司20xx年X月X日发布20xx年X月X日实施注以上画下横线部分是根据GBT19xx12...

医疗器械质量手册范本(15篇)