原文：https://yjj.beijing.gov.cn/yjj/ztzl48/ylqxjgfwzn/jsscgfzl64/yycp60/11001660/index.html
发布时间：2021年06月03日
版权归属原文本规范旨在指导企业提交医疗器械软件注册申报资料，同时规范医疗器械软件的技术审评要求。
本规范是对医疗器械软件的一般性要求，企业应根据医疗器械软件的特性提交注册申报资料，判断指导原则中的具体内容是否适用，不适用内容详述理由。企业也可采用其他满足法规要求的替代方法，但应提供详尽的研究资料和验证资料。
本规范是在现行法规和标准体系以及当前认知水平下、并参考了国外法规与指南、国际标准与技术报告制定的。随着法规和标准的不断完善，以及认知水平和技术能力的不断提高，相关内容也将适时进行修订。
本规范是对企业和审查人员的指导性文件，不包括审评审批所涉及的行政事项，亦不作为法规强制执行，应在遵循相关法规的前提下使用本规范。
本规范针对软件的特殊性，在现行法规要求下进一步明确了对医疗器械软件的要求，特别是对软件更新、软件版本的要求。本规范是医疗器械软件的通用规范，其他涉及软件医疗器械产品的规范可在本规范基础上进行有针对性的调整、修改和完善。
一、适用范围
本规范适用于第二类医疗器械软件的注册申报，适用的软件开发方式包括自主开发、部分采用现成软件和全部采用现成软件。
医疗器械软件包括独立软件和软件组件。独立软件：作为医疗器械或其附件的软件；软件组件：作为医疗器械或其部件、附件组成的软件。
独立软件应同时具备以下三个特征：具有一个或多个医疗用途，无需医疗器械硬件即可完成预期用途，运行于通用计算平台。独立软件包括通用型软件和专用型软件，其中通用型软件基于通用数据接口与多个医疗器械产品联合使用，如PACS、中央监护软件等；而专用型软件基于通用、专用的数据接口与特定医疗器械产品联合使用，如Holter数据分析软件、眼科显微镜图像处理软件等。
软件组件应同时具备以下两个特征：具有一个或多个医疗用途，控制（驱动）医疗器械硬件或运行于专用（医用）计算平台。软件组件包括嵌入式软件和控制型软件，其中嵌入式软件（即固件）运行于专用（医用）计算平台，控制（驱动）医疗器械硬件，如心电图机所含软件、脑电图机所含软件等；而控制型软件运行于通用计算平台，控制（驱动）医疗器械硬件。
软件组件也可兼具处理功能。专用型独立软件可单独注册，也可随医疗器械产品注册，此时视为软件组件。
二、技术审查要点
（一）产品名称和结构组成的要求
1.独立软件
产品名称应为通用名称，并符合相关法规、规范性文件的要求，可以结合人体部位（如胸部、心脏等）、临床科室（如骨科、神经外科等）、处理对象（如CT图像、MRI图像、心电数据等）和功能用途（如治疗、处理、诊断等）进行命名。
结构组成应包括物理组成和逻辑组成，其中物理组成描述软件的存储介质或交付方式，如光盘、U盘、预装于计算机交付或网络下载交付等；逻辑组成描述软件的临床功能模块，包括服务器（如适用）和客户端，注明选装和模块版本。
2.软件组件
软件组件无相应要求。
专用型独立软件视为软件组件时，软件名称与独立软件要求相同，结构组成应明确软件的名称、型号规格和发布版本。
（二）注册单元划分的原则和实例
1.独立软件
独立软件的注册单元以管理类别、预期用途、处理对象和临床功能模块作为划分原则。
（1）不同管理类别的独立软件应作为不同注册单元，在无法分割的情况下可作为一个注册单元并按照较高管理类别注册申报。
（2）不同预期用途的独立软件应作为不同注册单元，按照预期用途大体上可分为治疗类、诊断类、监护类和信息管理类。
（3）不同处理对象的独立软件应作为不同注册单元，按照处理对象大体上可分为图像类和数据类。
（4）对于功能庞大复杂的独立软件，应依据临床功能模块的类型和数量划分注册单元，每个注册单元所含模块的数量应适中。按照模块功能可分为平台功能软件和特定功能软件，其中平台功能软件作为软件平台提供基本功能和共用功能，支持多种模式的图像或数据，而特定功能软件运行于平台功能软件并提供特定功能，支持单一模式的图像或数据，或实现某一特定预期用途。
例如，某PACS包含数十个独立的临床功能模块，可以拆分为一个平台功能软件和多个特定功能软件，应划分为不同的注册单元。
2.软件组件
软件组件不符合医疗器械的定义，不宜单独注册申报，应随医疗器械产品注册申报，注册单元与医疗器械产品相同。
专用型独立软件视为软件组件时，要求与软件组件相同。
（三）产品适用的相关标准
根据产品自身特点适用表1中相关标准：
表1 相关标准
上述标准包括了产品技术要求中经常涉及到的标准。有的企业还会根据产品的特点引用一些行业外的标准和一些较为特殊的标准。
产品技术要求编写时与产品相关的国家、行业标准是否进行了引用，以及引用是否准确。可以通过对“符合性声明”中声明符合的相关标准是否齐全、适宜来进行审查。此时，应注意标准编号、标准名称是否完整规范，年代号是否有效。其次对引用标准的采纳情况进行审查。即所引用的标准中的条款要求，是否在产品技术要求中进行了实质性的条款引用。
上述标准如有新版发布实施，应执行最新版本。
（四）产品的主要风险及安全性级别划分要求
软件产品在进行风险管理时应符合YY/T 0316-2016《医疗器械风险管理对医疗器械的应用》的要求，与产品有关的安全性特征判定可参考YY/T 0316-2016的附录C，危害、可预见的事件序列和危害处境判断可参考YY/T 0316-2016附录E、I，风险控制的方案与实施、综合剩余风险的可接受性评价及生产和生产后监视相关方法可参考YY/T 0316-2016附录F、G、J。
软件没有物理实体，在开发和使用过程中人为因素影响无处不在，软件测试由于时间和成本的限制不能穷尽所有情况，所以软件缺陷无法避免。同时，软件更新频繁且迅速，轻微更新也可能导致严重后果，而且还存在退化问题（即每修复若干个缺陷就会产生一个新缺陷），所以软件缺陷无法根除。因此，软件缺陷可视为软件的固有属性之一，软件的质量问题不容忽视。
鉴于软件的特殊性，医疗器械软件需要综合考虑风险管理、质量体系管理和软件工程等要求才能保证安全性与有效性。
医疗器械软件的风险水平采用软件安全性级别（YY/T 0664《医疗器械软件软件生存周期过程》）进行分级，软件安全性级别基于软件损害严重度分为：
A级：不可能对健康有伤害和损坏；
B级：可能有不严重的伤害；
C级：可能死亡或严重伤害。
软件安全性级别应结合软件的预期用途、使用环境和核心功能（软件在预期使用环境完成预期用途所必需的功能）进行判定。其中预期用途主要考虑软件的临床用途（如诊断、治疗、监护、筛查等）和重要程度（如重要作用、辅助作用、补充作用等），使用环境主要考虑软件的使用场所（如医院、家庭等）、疾病类型（如严重性、紧迫性、传染性等）、患者人群（如成人、儿童、老年、女性等）和用户类型（如专业用户、普通用户、患者等），核心功能主要考虑软件的功能类型（如控制驱动、处理分析等）、实现方法（如CT图像重建采用滤波反投影算法还是迭代算法，异常识别采用常规图像处理算法还是人工智能算法等）和复杂程度（如算法规模、参数数量、运算速度等）。
软件安全性级别也可根据风险管理所确定的风险等级进行判定，软件安全性级别与风险等级的分级可以不同，但二者存在对应关系，因此可根据风险等级来判定软件安全性级别。
企业应在采取风险缓解措施之前判定软件安全性级别，并结合质量管理体系要求，建立与软件安全性级别相匹配的软件生存周期过程，包括软件开发过程、软件维护过程、配置管理过程、风险管理过程和问题解决过程。同时，企业可采用良好软件工程实践完善质量管理体系要求，保证软件质量。另外，企业应保证软件自身的信息安全，确保健康数据的保密性、完整性和可得性。
企业应基于软件安全性级别提交相应注册申报资料。注册申报资料均源自软件生存周期过程所形成的文件资料，详尽程度取决于软件的安全性级别和复杂程度。
独立软件和软件组件尽管在结构和功能上有所不同，风险情况也不尽相同，但软件生存周期过程基本一致，故二者注册申报资料要求的基本原则相同，具体要求有所差异。
（五）产品技术要求
1.独立软件
独立软件产品技术要求应在“产品型号/规格及其划分说明”中明确软件的名称、型号规格、发布版本和版本命名规则，而“性能指标”分为通用要求、质量要求、专用要求和安全要求，其中通用要求应根据软件自身特性进行规范，质量要求应符合GB/T 25000.51《软件工程软件产品质量要求与评价（SQuaRE）商业现货（COTS）软件产品的质量要求与测试细则》的要求，专用要求应符合相关性能标准的要求，安全要求应符合相关安全标准的要求。
独立软件产品技术要求模板详见附录I。
2.软件组件
软件组件应在医疗器械产品技术要求中进行规范，其中“产品型号/规格及其划分说明”应明确软件的名称、型号规格、发布版本、版本命名规则、运行环境（控制型软件组件适用，包括硬件配置、软件环境和网络条件），而“性能指标”应明确软件全部临床功能纲要。
专用型独立软件视为软件组件时，要求与软件组件相同（运行环境适用）。
（六）同一注册单元内注册检验代表产品确定原则和实例
检测单元是指同一注册单元内用于检测的代表产品。
1.独立软件
独立软件的检测单元原则上与注册单元一致，但如有多个运行环境或多个发布版本，则每个互不兼容的运行环境或每个互不涵盖的发布版本均应作为一个检测单元。
2.软件组件
软件组件的检测单元原则上与医疗器械产品一致，但医疗器械产品如包含多个软件组件或多个发布版本的软件组件，则每个软件组件或每个发布版本的软件组件均应作为一个检测单元，除非检测单元完整覆盖注册单元全部情况。
专用型独立软件视为软件组件时，检测单元原则上与软件组件相同，但如有多个运行环境，则每个互不兼容的运行环境均应作为一个检测单元。
（七）产品生产制造相关要求
应明确产品生产工艺过程，可采用流程图的形式，并说明其过程控制点。
有多个研制、生产场地，应介绍每个研制、生产场地的实际情况。
（八）产品的临床评价细化要求
1.独立软件
独立软件应依据《医疗器械临床评价技术指导原则》提交临床评价资料，不适用条款说明理由。对于采用人工智能算法实现的功能（如计算机辅助检测、分类和诊断等CAD类功能），应提交基于临床试验的临床评价资料。
2.软件组件
软件组件应与医疗器械产品整体开展临床评价工作，提交医疗器械产品的临床评价资料。软件组件的处理功能可随医疗器械产品进行临床评价，也可单独进行临床评价，此时要求与独立软件相同。
专用型独立软件视为软件组件时，要求与软件组件的处理功能相同。
（九）产品说明书和标签要求
产品的说明书和标签应当符合《医疗器械说明书和标签管理规定》（国家食品药品监督管理总局令第6号）和其他相关法规、规范性文件、国家标准、行业标准的要求，体现软件全部功能（包含安全功能），明确软件发布版本。
（十）研究资料要求
根据所申报的产品，提供适用的研究资料。
1.产品性能研究
应当提供产品性能研究资料以及产品技术要求的研究和编制说明，包括功能性、安全性指标以及与质量控制相关的其他指标的确定依据，所采用的标准或方法、采用的原因及理论基础。
2.产品有效期和包装研究
有效期的确定：应当提供产品有效期的验证报告。
包装及包装完整性：应当提供在宣称的有效期内以及运输储存条件下，保持包装完整性的依据。
3.软件研究
应当提供一份单独的医疗器械软件描述文档，内容包括基本信息、实现过程和核心算法，详尽程度取决于软件的安全性级别和复杂程度。具体要求详见“（十一）软件描述文档要求”。
同时，应出具关于软件版本命名规则的声明，并明确软件版本的全部字段及字段含义，确定软件的完整版本和发行所用的标识版本。具体要求详见“（十二）软件版本要求”。
（十一）软件描述文档要求
软件描述文档基于YY/T 0664《医疗器械软件软件生存周期过程》予以制定，用于自主开发医疗器械软件的产品注册。现成软件软件描述文档要求详见“（十四）现成软件要求”。软件描述文档包括基本信息、实现过程和核心算法,详见表2。
1.基本信息
（1）软件标识
明确软件的名称、型号规格、发布版本、企业和生产地址。软件组件标识为企业质量控制所用标识。
（2）安全性级别
明确软件安全性级别（A级、B级、C级），详述确定理由。
（3）结构功能
依据软件设计规范（SDS）提供体系结构图和用户界面关系图（如适用）。
体系结构图用于图示组成模块之间、组成模块与外部接口之间的关系，依据体系结构图描述组成模块（注明选装、模块版本）的功能、模块关系和外部接口。
用户界面关系图用于描述用户界面之间的关系，依据用户界面关系图（如不适用则为体系结构图）描述临床功能模块（注明选装、模块版本）的功能和模块关系。
（4）硬件拓扑
依据软件设计规范（SDS）提供物理拓扑图，图示并描述软件（或组成模块）、通用计算机、医疗器械硬件之间的物理连接关系。
（5）运行环境
明确软件运行所需的硬件配置、软件环境和网络条件。其中硬件配置包括处理器、存储器和外设器件，软件环境包括系统软件、支持软件和安全软件，网络条件包括网络架构（BS、CS）、网络类型（广域网、局域网、个域网）和带宽。
（6）适用范围
独立软件描述软件的适用范围，软件组件描述医疗器械产品的适用范围。
（7）禁忌症
独立软件描述软件的禁忌症或使用限制，软件组件描述医疗器械产品的禁忌症或使用限制。
（8）注册历史
独立软件列明历次注册的发布版本和注册证号。软件组件列明医疗器械产品的注册情况。
2.实现过程
（1）开发概述
明确软件开发所用的语言、工具和方法，其中工具描述支持软件（含开源软件）和应用软件（第三方软件）的名称、完整版本和供应商。同时明确开发人员数量、开发时间、工作量（人月数）和代码行总数。
（2）风险管理
依据风险管理相关标准提供软件风险分析报告和软件风险管理报告，风险管理资料另附原始文件。软件组件提供医疗器械产品的风险管理资料。
（3）需求规范
A级提供软件需求规范（SRS）关于软件功能的要求，B级和C级提供软件需求规范全文。软件需求规范另附原始文件。软件组件如无单独的软件需求规范，可提供医疗器械产品的需求规范。
（4）生存周期
A级提供软件开发生存周期计划摘要，描述开发各阶段的划分情况和工作任务。B级在A级基础上提供配置管理计划摘要和维护计划摘要，描述所用的工具和流程。C级在B级基础上提供设计历史文档目录。
生存周期也可提交企业软件生存周期过程文件或YY/T 0664《医疗器械软件软件生存周期过程》等过程标准的核查表，用于替代相应描述。
（5）验证与确认
验证是指通过提供客观证据认定软件某开发阶段的输出满足输入要求，包括代码检查、设计评审、测试等质量保证活动。确认是指通过提供客观证据认定软件满足用户需求和预期用途，通常是指在真实或模拟使用环境进行的用户测试。可追溯性分析是指追踪需求规范、设计规范、源代码、测试、风险管理之间的关系，分析已识别关系的正确性、一致性、完整性和准确性。
A级提供系统测试、用户测试的计划和报告摘要，描述测试的条件、工具、方法、通过准则和结果。B级提供系统测试、用户测试的计划和报告，概述开发各阶段的验证活动，描述所用的工具、方法和任务。C级在B级基础上提供可追溯性分析报告（追溯需求规范、设计规范、测试、风险管理的关系表）。
系统测试和用户测试的计划和报告另附原始文件。测试报告关于测试记录的内容可以提供一个测试记录样例和完整的测试记录清单。验证活动也可提交企业软件质量保证计划文件，用于替代相应描述。
（6）缺陷管理
A级描述缺陷管理的工具和流程，明确软件本次注册已知的缺陷总数和剩余缺陷数。B级和C级在A级基础上列明已知剩余缺陷情况，证明全部已知剩余缺陷的风险均是可接受的。已知剩余缺陷情况可另附原始文件。
（7）更新历史
A、B、C级均应描述软件版本命名规则，明确软件版本的全部字段及字段含义，确认软件完整版本和软件发布版本。
A级列明软件本次注册与前次注册之间历次软件更新的完整版本、日期和类型。B级在A级基础上详述历次软件更新的具体更新内容。C级列明软件历次注册时历次软件更新的完整版本、日期、类型和具体更新内容。
首次产品注册描述软件开发阶段的更新情况。更新历史可另付原始文件。
（8）临床评价
临床评价资料另附原始文件。
3.核心算法
依据软件设计规范（SDS）和说明书列明核心算法的名称、类型、用途和临床功能。
核心算法是指实现软件核心功能（软件在预期使用环境完成预期用途所必需的功能）所必需的算法，包括但不限于成像算法、后处理算法和人工智能算法。其中成像算法是指用于获取医学图像或数据的算法，后处理算法是指改变原始医学图像或数据产生新临床信息的算法，人工智能算法是指采用人工智能技术进行医学图像或数据分析的算法。
算法类型包括公认成熟算法和全新算法。其中公认成熟算法是指源自公开文献资料、原理简单明确、上市多年且无不良事件的算法，而全新算法是指源自临床研究、科学研究的新算法。
核心算法详尽程度取决于安全性级别和算法类型。当安全性级别为A级时，公认成熟算法和全新算法均列明算法的名称、类型、用途和临床功能。当安全性级别为B级和C级时，公认成熟算法列明算法的名称、类型、用途和临床功能，全新算法在公认成熟算法基础上提供安全性与有效性的验证资料。
表2 软件描述文档框架
（十二）软件版本要求
本节适用于自主开发医疗器械软件的版本要求，现成软件软件版本要求详见“（十四）现成软件要求”。
1.基本考量
软件没有物理实体，只能通过状态管理保证质量，而软件版本用于标识软件状态，控制软件更新，进而保证软件质量，因此软件版本与软件是相互对应的表里关系，即软件版本是软件标识不可或缺的组成部分，也是实现医疗器械软件可追溯性的重要工具。
企业无论采用何种名称和形式（如修订号、构建号、发布日期等），只要用于标识软件状态均视为软件版本。企业制定软件版本命名规则除了考虑医疗器械产品自身特点、质量管理体系要求之外，还要考虑监管的要求，即软件版本命名规则能够区分软件更新类型，可以确认软件完整版本和软件发布版本：
（1）软件完整版本：体现重大增强类软件更新、轻微增强类软件更新、纠正类软件更新和构建（如适用）；
（2）软件发布版本：软件发行所用的标识版本，仅体现重大增强类软件更新（即重大软件更新）。
软件发布版本发生改变应进行许可事项变更，软件完整版本发生改变但软件发布版本未变无需进行注册变更。例如，软件版本命名规则为X.Y.Z.B，其中X表示重大增强类软件更新，Y表示轻微增强类软件更新，Z表示纠正类软件更新，B表示构建，则软件完整版本为X.Y.Z.B，软件发布版本为X，此时X发生变化应进行许可事项变更，而Y、Z和B发生变化无需进行注册变更。
软件版本命名规则同样遵循风险从高原则，即不能区分重大软件更新和轻微软件更新则按照重大软件更新处理，不能区分增强类软件更新和纠正类软件更新则按照增强类软件更新处理。
2.软件版本要求
企业应出具软件版本命名规则真实性声明，明确软件版本的全部字段及字段含义，确认软件完整版本和软件发布版本。
企业应在说明书中明确软件发布版本。
对于独立软件（含专用型独立软件视为软件组件的情况）和控制型软件组件，企业应在登录界面、主界面、“关于”或“帮助”等界面体现软件完整版本和软件发布版本，注册检测报告应包含软件完整版本和软件发布版本的界面照片。
（十三）软件更新要求
本节适用于自主开发医疗器械软件的更新要求，现成软件更新要求详见“（十四）现成软件要求”。
1.基本考量
医疗器械软件更新是指企业在整个软件生存周期过程中对软件所做的任一修改。软件更新类型从不同角度出发有不同划分方法。从更新的结果和影响角度出发，软件更新可分为：
（1）重大更新：影响到医疗器械安全性或有效性的软件更新；
（2）轻微更新：不影响医疗器械安全性与有效性的软件更新。
从更新的目的和范围角度出发，软件更新可分为增强类更新和纠正类更新，其中增强类更新又可分为适应型更新和完善型更新，纠正类更新又可分为纠正型更新和预防型更新（改自GB/T 20157《信息技术软件维护》）：
（1）适应型更新：医疗器械软件上市后，为适应新的运行环境而进行的软件更新；
（2）完善型更新：医疗器械软件上市后，为改变功能、性能等软件属性而进行的软件更新；
（3）纠正型更新：医疗器械软件上市后，为修正软件已知缺陷而进行的软件更新；
（4）预防型更新：医疗器械软件上市后，为修正软件潜在未知缺陷以避免出现运行故障而进行的软件更新。
同时，有两种特殊情况需要考虑：
（1）构建（Build）：是指软件编译生成一个工作版本，符合软件更新的定义，通过质量管理体系进行控制，申报资料要求与纠正类更新相同。下文如无特别说明，纠正类更新均包含构建；
（2）涉及召回：包括软件更新导致医疗器械召回、召回处理措施所引发的软件更新，这两种情况均属于重大更新，应按照医疗器械召回的相关法规处理，不属于本指导原则讨论范围。
本规范关注软件的安全性与有效性，将软件更新分为：
（1）重大软件更新：影响到医疗器械安全性或有效性的增强类更新，即重大增强类软件更新；
（2）轻微软件更新：不影响医疗器械安全性与有效性的增强类更新和纠正类更新，即轻微增强类软件更新和纠正类软件更新。
2.重大软件更新
根据定义，凡是影响到医疗器械安全性或有效性的软件更新均为重大软件更新。具体而言，软件更新如影响到医疗器械的预期用途、使用环境或核心功能均为重大软件更新。
本规范所述重大软件更新包括以下情形之一：
（1）适应型软件更新：软件运行平台跨越互不兼容的计算平台（包括硬件和软件），如操作系统软件由Windows变为iOS，32位计算平台变为64位计算平台、常规计算平台变为移动计算平台等，而系统软件和支持软件的补丁一般不视为重大软件更新，除非影响到医疗器械的安全性或有效性。
（2）完善型软件更新：影响到用户临床决策（包括决策能力、决策结果、决策流程和用户临床行动），或者影响到人员安全（包括患者、用户和其他相关人员），包括但不限于：
a）临床功能改变，如新增临床应用、新增运行模式、采用新核心算法等；
b）软件输出结果改变，如医学图像或数据质量改变、用户界面增加临床信息等；
c）用户使用习惯改变，如用户原有临床工作流程改变、用户界面布局改变等；
d）影响到患者安全，如采用新的软件安全标准、用户界面增加报警信息等。
而核心算法运算速度的单纯性提高、临床工作流程的可配置化（即用户可以保留原有临床工作流程）、用户界面的文字性修改，除非影响到医疗器械的安全性或有效性,一般不视为重大更新。
（3）其他软件更新：软件的安全性级别、体系结构、用户界面关系或物理拓扑发生改变。
重大软件更新的范围会随着认知水平与技术能力的提高、不良事件与召回事件的分析进行动态调整。
3.软件更新要求
医疗器械软件发生重大软件更新应进行许可事项变更，而发生轻微软件更新通过质量管理体系进行控制，无需进行注册变更，待到下次注册（注册变更和延续注册）时提交相应申报资料。
已注册的医疗器械软件在后续注册（注册变更和延续注册）时应根据软件更新情况提交相应申报资料：
（1）重大软件更新
软件发生重大软件更新应提交软件更新描述文档，包括基本信息、实现过程和核心算法，详见表3。
表3 软件更新描述文档框架
（2）轻微软件更新
软件发生轻微软件更新时，轻微增强类软件更新同样应提交软件更新描述文档，而纠正类软件更新应提交软件更新情况说明、回归测试计划与报告、新增已知剩余缺陷情况说明。
软件同时发生多种类型的软件更新，应按照风险从高原则提交申报资料，即同时发生重大软件更新和轻微软件更新则按照重大软件更新处理，同时发生增强类软件更新和纠正类软件更新则按照增强类软件更新处理。
医疗器械软件的重新开发（即企业弃用原有软件）不属于软件更新，应按照医疗器械产品注册的要求提交申报资料。
（十四）现成软件要求
1.基本考量
随着信息技术的快速发展，医疗器械产品使用现成软件的情况越来越普遍，但现成软件不能完全满足医疗器械产品的预期用途，而且企业未对现成软件进行完整生存周期控制，因此使用现成软件风险相对较高。由于要对医疗器械产品最终的安全性与有效性负责，企业应采用基于风险的方法保证现成软件的质量和安全。
现成软件分为：
（1）成品软件：已开发且通常可得到的，但企业未进行完整生存周期控制的软件，包含商业软件和免费软件；
（2）遗留软件：企业以前开发但现在不能得到足够开发记录的软件；
（3）外包软件：企业委托第三方开发的定制软件。
目前，本指导原则所述的现成软件仅限于应用软件，今后将在适当时机下扩至系统软件和支持软件。但企业应保证系统软件和支持软件的质量和安全。
2.现成软件要求
医疗器械软件的开发方式不同，采用的现成软件类型不同，软件质量保证措施也不同，注册申报资料亦有所差异。
（1）部分采用现成软件
对于部分采用现成软件的方式，三种现成软件的要求相同，企业均应在软件描述文档相应条款中描述（详见表4）。
表4 部分现成软件框架
a）软件标识
A、B、C级明确现成软件的名称、型号规格、发布版本、供应商和生产地址。
b）结构功能
A、B、C级注明组成模块、临床功能模块所用现成软件的名称、发布版本和类型。
c）风险管理
A、B、C级提供现成软件的风险管理资料。
d）需求规范
B级和C级提供现成软件的需求规范资料。
e）生存周期
B级和C级在开发生存周期计划、配置管理计划和维护计划中明确现成软件的要求。
f）验证与确认
A、B、C级提供现成软件的验证与确认资料。
g）缺陷管理
B级和C级明确现成软件的缺陷管理流程和已知剩余缺陷情况。
h）更新历史
A、B、C级明确现成软件的版本命名规则。
i）核心算法
B级和C级列明现成软件核心算法的名称（或编号）、用途和临床功能，全新临床功能提供安全性与有效性的验证资料。
（2）全部采用现成软件
对于全部采用现成软件的方式，三种现成软件的要求有所不同：
a）成品软件：企业应提供外购合同复印件或声明、软件描述文档（不适用条款说明理由），成品软件如已在中国上市提供注册证复印件；
b）遗留软件：企业应提供遗留软件证明性文件（如YY/T 0664实施之前的注册证或上市批书复印件）、软件描述文档（不适用条款说明理由）、上市后临床评价资料；
c）外包软件：企业应提供外包合同复印件或声明、软件描述文档（不适用条款说明理由）。
3.现成软件更新要求
现成软件的更新类型、更新注册要求和风险从高原则与自主开发软件相同，注册申报资料要求与自主开发软件有所差异。
现成软件发生重大软件更新时，应参照自主开发软件重大软件更新要求提交现成软件更新描述文档，不适用条款说明理由。现成软件发生轻微软件更新时，轻微增强类软件更新同样应提交现成软件更新描述文档，而纠正类软件更新与自主开发软件纠正类软件更新要求相同。
对于部分采用现成软件的情况，自主开发的软件发生更新按照自主开发软件更新要求提交相应申报资料，现成软件发生更新按照现成软件更新要求提交相应申报资料。
4.现成软件版本要求
现成软件版本同样要考虑监管要求和遵循风险从高原则。现成软件供应商的软件版本命名规则如符合监管要求，企业可直接采用现成软件供应商的版本命名规则。
企业应在软件版本命名规则真实性声明中明确现成软件的版本命名规则、完整版本和发布版本。
（十五）现场体系核查软件研发基本要求
企业应按《医疗器械生产质量管理规范》（国家食品药品监督管理总局2016年第64号公告）及相关文件的要求建立质量体系，还应符合本部分的要求。
1.企业应按照软件生命周期的要求，保存医疗软件产品研发过程中所产生的文档，其中包括可行性分析、需求分析、概要设计、详细设计、源代码和测试文档等方面的内容，具体要求见附录II。
2.企业应有与医疗软件产品研发过程相适应的人员分工、设备管理、配置管理、BUG管理等方面的要求，具体要求见附录II。
3.企业应配备同医疗软件产品生产相适应的软硬件资源，包括计算机、服务器（如有）、测试用专用软件（如有）、操作系统软件等。
4.生产与测试用计算机系统应相互独立。
5.企业应建立软件版本号管理制度。
6.企业应有医疗软件产品维护的相关要求（如有）。
7.如企业为委托研发，应提供委托研发合同/协议和上述所有资料。
三、审查关注点
审查中需重点关注以下几个方面：
（一）产品命名是否符合通用名称及相关法规、规范性文件要求，可以结合人体部位、临床科室、处理对象和功能用途进行命名。
（二）产品适用范围、结构组成以及所包括的功能模块等是否符合本规范界定的医疗软件产品的定义，属于自主开发、部分采用现成软件还是全部采用现成软件，是独立软件和软件组件，根据不同情况适用于本规范不同章节的要求。
（三）根据医疗器械软件风险水平的不同是否对软件安全性级别进行了合理分级，软件安全性级别应结合软件的预期用途、使用环境和核心功能进行判定，并应结合质量管理体系要求，建立与软件安全性级别相匹配的软件生存周期过程，包括软件开发过程、软件维护过程、配置管理过程、风险管理过程和问题解决过程。企业应基于软件安全性级别提交相应注册申报资料。注册申报资料均源自软件生存周期过程所形成的文件资料，详尽程度取决于软件的安全性级别和复杂程度。
（四）产品技术要求的内容和格式是否符合本规范附录I的相关要求，附录I是对《关于发布医疗器械产品技术要求编写指导原则的通告》（国家食品药品监督管理总局2014年第9号通告）和GB/T 25000.51《软件工程软件产品质量要求与评价（SQuaRE）商业现货（COTS）软件产品的质量要求与测试细则》要求的合并，此外产品的专用要求还应结合相关的性能标准和安全标准予以补充。
（五）医疗软件产品研究资料应重点关注软件描述文档，是否结合所确定的软件安全性级别正确提交了相应的软件描述文档并符合本规范的要求，本规范对自主开发的医疗器械软件产品、部分采用现成软件产品、现成软件产品以及软件更新时规定了不同的软件描述文档内容要求。
（六）软件版本控制是软件不同于其他产品而应重点关注的内容之一，是否符合本规范的相关要求，本规范对自主开发的医疗器械软件产品、部分采用现成软件产品、现成软件产品以及软件更新时规定了不同的软件版本要求。
（七）软件更新应重点鉴别是重大更新还是轻微更新，是增强类更新还是纠正类更新，其中增强类更新是适应型更新还是完善型更新，纠正类更新是纠正型更新还是预防型更新，是否符合本规范的相关要求，本规范对自主开发的医疗器械软件产品、部分采用现成软件产品和现成软件产品的不同情况的更新规定了不同的要求。
（八）现成软件分为成品软件、遗留软件和外包软件，审查时应予以关注属于何种情况，本规范对部分采用现成软件和全部采用现成软件的软件描述文档要求、软件更新要求、软件版本要求提出了明确的要求，审查时应予以关注是否符合相关要求。
（九）本规范明确了医疗软件产品现场体系核查时的相关要求，并应重点关注软件研发过程和文档是否符合本规范附录II给出的相关要求。
附录I
独立软件产品技术要求模板
医疗器械产品技术要求
医疗器械产品技术要求编号：
产品名称
1. 产品型号/规格及其划分说明
1.1 软件型号规格
1.2 软件发布版本
1.3 版本命名规则
明确软件完整版本的全部字段及字段含义
2. 性能指标
2.1 通用要求
2.1.1 处理对象
明确软件的处理对象类型，如图像（如X-ray、US等）、数据（如心电、血压、血氧、血糖等）
2.1.2 最大并发数
明确软件的最大并发用户数、患者数
2.1.3 数据接口
明确软件的通用数据接口（如Dicom、HL7）、产品接口（可联合使用的独立软件、医疗器械硬件）
2.1.4 特定软硬件
明确软件完成预期用途所必备的独立软件、医疗器械硬件
2.1.5 临床功能
依据说明书明确软件全部临床功能纲要（注明可选）
2.1.6 使用限制
依据说明书明确软件的使用限制
2.1.7 用户访问控制
明确软件的用户访问控制管理机制
2.1.8 版权保护
明确软件的版权保护技术
2.1.9 用户界面
明确软件的用户界面类型
2.1.10 消息
明确软件的消息类型
2.1.11 可靠性
明确软件出错后数据保存与恢复能力
2.1.12 维护性
明确软件向用户提供的维护信息类型
2.1.13 效率
明确软件在典型配置条件下完成典型临床功能所需的时间
2.1.14 运行环境
明确软件运行所需的硬件配置、软件环境和网络条件，包括服务器（如适用）和客户端的要求
2.2 质量要求
符合GB/T 25000.51第5章要求
2.3 专用要求（如适用）
注：依据相应标准条款逐条描述
2.3.1 YY 0670（如适用）
……
2.4 安全要求（如适用）
注：列明相应安全标准名称即可
2.4.1 YY 0709（如适用）
2.4.2 YY 0784（如适用）
2.4.3 YY 0785（如适用）
……
3. 检验方法
3.1 通用要求符合性检验
通过检查说明书、实际操作验证2.1的符合性。
3.2 质量要求符合性检验
依据GB/T 25000.51第7章方法验证2.2的符合性。
3.3 专用要求检验方法（如适用）
3.3.1 依据YY 0670的方法进行检验（如适用）。
……
3.4 安全要求检验方法（如适用）
3.4.1 依据YY 0709的方法进行检验（如适用）。
3.4.2 依据YY 0784的方法进行检验（如适用）。
3.4.3 依据YY 0785的方法进行检验（如适用）。
……
4. 术语（如适用）
4.1 ……
4.2 ……
……
（分页）
附录
1. 体系结构图及必要注释
2. 用户界面关系图及必要注释
3. 物理拓扑图及必要注释
附件II
医疗软件研发基本要求
企业应按照软件生命周期的要求，保留医疗软件产品研发过程中所产生的相关文档记录：
一、软件生命周期要求
（一）应有可行性分析，一般包括：
1. 产品研发的意义
2. 产品研发的计划
（二）应有软件需求分析，一般包括：
1. 软件的功能需求
2. 需求文档评审
3. 需求文档验证
4. 软件测试计划和系统测试用例
5. 需求分析变更（如有）
（三）应有概要设计，一般包括：
1. 软件模块总体概要说明
2. 软件模块之间的关系说明
3. 软件数据库设计说明（如有）
4. 软件概要设计阶段评审
5. 软件概要设计阶段验证
6. 软件集成测试用例
（四）应有详细设计，一般包括：
1. 软件模块内的结构说明
2. 软件详细设计阶段评审
3. 软件详细设计阶段验证
4. 软件单元测试用例
（五）应有程序源代码，一般包括：
1. 代码注释
2. 代码评审
3. 代码验证
（六）应有测试文档，一般包括：
1. 测试用例输入、预计输出结果和实际输出结果
2. 各个主要功能的测试用例
二、软件配置管理要求，一般包括：
1. 更改控制
2. 配置标识
3. 配置状态记录
如使用软件配置管理工具，还应提供：
1. 所需工具软件的名称
2. 所需工具软件的企业
三、软件BUG管理要求，一般包括：
1. BUG描述
2. BUG解决方法
3. BUG测试
四、软件研发应有人员分工要求，一般包括：
1. 软件研发人员职责分配
2. 软件研发人员的任务
3. 阶段项目工作量估算
五、软件研发应有设备管理要求，一般包括：
1. 软件开发平台
2. 网络版的测试服务器（如有）
3. 可移植软件的多种操作系统（如有）
医疗软件产品技术审评规范（2017版）
修订说明
一、规范编写目的
本规范的编写目的是指导和规范该类产品的技术审评工作，帮助审评人员理解和掌握该类医疗软件产品的命名、种类、安全性级别、产品技术要求、研发周期要求、版本控制要求、软件更新要求等内容，把握技术审评工作基本要求和尺度，对产品安全性、有效性做出系统评价，同时也为了指导生产企业的产品注册工作。
二、规范编写依据
（一）《医疗器械监督管理条例》（国务院令第650号）
（二）《医疗器械注册管理办法》（国家食品药品监督管理总局令第4号）
（三）《医疗器械说明书和标签管理规定》（国家食品药品监督管理总局令第6号）
（四）《关于印发《境内第二类医疗器械注册审批操作规范》的通知》（食药监械管〔2014〕209号）
（五）《国家食品药品监督管理总局关于公布医疗器械注册申报资料要求和批准证明文件格式的公告》（国家食品药品监督管理总局公告2014年第43号）
（六）《国家食品药品监督管理总局关于发布医疗器械产品技术要求编写指导原则的通告》（国家食品药品监督管理总局通告2014年第9号）
（七）《关于发布医疗器械临床评价技术指导原则的通告》（国家食品药品监督管理总局通告2015年第14号）
（八）《医疗器械软件注册技术审查指导原则》（国家食品药品监督管理总局2015年第50号通告）
（九）国家食品药品监督管理部门发布的其他规范性文件
三、规范中重点内容说明
（一）软件没有物理实体，具有特殊性。为了达到监管目的同时促进行业发展，本规范在现行法规框架下针对软件的特殊性进一步明确了软件的监管要求，特别是对软件更新、软件版本的要求。
（二）本规范是医疗器械软件的通用技术审评规范，其他涉及软件医疗器械产品的规范可在本规范基础上进行有针对性的调整、修改和完善。
（三）软件只有结合风险管理、质量管理和软件工程的要求才能保证质量，因此良好的软件生存周期过程对于保证软件质量至关重要。企业应基于YY/T 0664-2008《医疗器械软件软件生存周期过程》建立起与软件安全性级别相匹配的软件生存周期过程，并作为自身质量管理体系的组成部分。
（四）软件可追溯性分析是保证软件质量的重要技术手段，美国和欧盟均要求全面开展软件可追溯性分析工作。考虑到境内企业存在一定实施难度，故本规范仅对C级软件进行了要求，A级和B级软件未做要求。但从技术发展趋势而言，今后将在适当时机要求企业全面开展软件可追溯性分析工作。
（五）重大软件更新和轻微软件更新不存在清晰明确的划分界线，需要具体情况具体分析。本规范综合考虑监管目标和行业发展的关系，基于现有的认知水平、技术能力和监管资源明确了重大软件更新的范围，今后会随着认知水平与技术能力的提高、不良事件与召回事件的分析动态调整重大软件更新的范围。
（六）软件没有物理实体，只能通过状态管理保证质量。软件版本用于标识软件状态和控制软件更新，与软件是相互对应的表里关系，即软件版本是软件标识不可或缺的组成部分，因此可以基于软件版本实现软件监管目的，特别是对软件更新的监管，但前提是软件版本命名规则是真实有效的。
（七）本规范所述现成软件仅包含应用软件,暂不包含系统软件和支持软件。这是基于当前技术审评侧重的考虑，并不意味企业可以放弃对系统软件和支持软件的质量管理，现成软件的范围今后将在适当时机下扩至系统软件和支持软件。同时，也是基于现成软件仅包含应用软件的考虑，现成软件的软件描述文档增加了核心算法的要求，但内容进行了简化；对于全部采用遗留软件的开发方式，增加了上市后临床评价资料的要求。
（八）独立软件目前尚无医疗器械产品标准，产品技术要求暂以通用软件产品标准GB/T 25000.51-2010《软件工程软件产品质量要求与评价（SQuaRE）商业现货（COTS）软件产品的质量要求与测试细则》作为参考，但由于该标准不是医疗器械产品标准，相应要求不能完全满足监管要求，因此产品技术要求模板进行了适当调整。今后，独立软件产品技术要求模版将随着国家标准和行业标准的实施情况进行调整。
（九）医疗器械软件功能众多，难以统一临床评价要求。本指导原则依据《医疗器械临床评价技术指导原则》明确了软件临床评价的一般原则，企业应根据相关法规、规范性文件的要求并结合软件自身特性开展相应的临床评价工作。
（十）说明书是评价软件质量的重要依据，因此说明书应真实、准确和完整的体现软件当前状态。由于软件更新情况复杂，某些情况下仅依靠说明书的变化内容无法评估软件当前状态，特别是对重大软件更新。因此，软件更新仍需提交软件当前状态下的全部说明书，并提交变化情况说明，除非软件更新内容未在说明书中体现。
（十一）随着网络技术的快速发展，越来越多的医疗器械具有联网功能，信息安全问题随之产生，近来美国和欧盟均加强了医疗器械信息安全的监管要求。考虑到信息安全并不限于软件，我国医疗器械信息安全监管工作尚处于起步阶段，本规范对软件的信息安全提出了原则性要求，今后将在适当时机下单独制定医疗器械信息安全技术审评规范。
四、规范编写单位和人员
本规范编写单位为北京市食品药品监督管理局，编写组成员包括技术审评人员、行政审批人员及相关专业的临床和工程专家、专业厂家代表。
五、关于本版规范的修订说明
本次修订主要涉及以下内容：
（一）根据国家食品药品监督管理总局对注册技术审查指导原则编写格式的最新要求调整了排版、章节顺序和章节名称，新增了产品生产制造相关要求、研究资料要求、审查关注点，并结合医疗软件产品特点增加了软件安全性级别划分要求、软件描述文档要求、软件版本要求、软件更新要求、现成软件要求，同时删减了产品工作原理/作用机理、产品的适用范围/预期用途、禁忌症、产品的不良事件历史记录。
（二）本规范修订时尽可能吸收和采纳了《医疗器械软件注册技术审查指导原则》（国家食品药品监督管理总局2015年第50号通告）的核心内容，同时保留原规范产品适用的相关标准、产品说明书和标签要求、产品研发周期文档要求和质量体系要求的相关内容，将两者予以了融合。
（三）本规范修订时突破了原规范的适用范围，不仅限于独立软件产品，含软件组件的产品也适用，和国家食品药品监督管理总局发布的《医疗器械软件注册技术审查指导原则》适用范围的差异仅在于是国产器械还是进口器械，产品管理类别是二类产品还是三类产品。
（四）根据最新发布的《医疗器械注册管理办法》更新了规范中适用的相关法规以及注册申报资料的名称和要求，其中产品技术要求撰写格式和要求采纳了国家食品药品监督管理总局发布的《医疗器械软件注册技术审查指导原则》的相关要求。
评论区