附件医疗器械软件注册技术审查指导原则本指导原则旨在指导制造商提交医疗器械软件注册申报资料，同时规范医疗器械软件的技术审评要求。本指导原则是对
医疗器械软件的一般性要求，制造商应根据医疗器械软件的特性提交注册申报资料，判断指导原则中的具体内容是否适用，不适用内容详述理由。制
造商也可采用其他满足法规要求的替代方法，但应提供详尽的研究资料和验证资料。本指导原则是在现行法规和标准体系以及当前认知水平下、并参
考了国外法规与指南、国际标准与技术报告制定的。随着法规和标准的不断完善，以及认知水平和技术能力的不断提高，相关内容也将适时进行修订
。本指导原则是对制造商和审查人员的指导性文件，不包括审评审批所涉及的行政事项，亦不作为法规强制执行，应在遵循相关法规的前提下使用本
指导原则。本指导原则针对软件的特殊性，在现行法规要求下进一步明确了对医疗器械软件的要求，特别是对软件更新、软件版本的要求。本指导原
则是医疗器械软件的通用指导原则，其他涉及软件医疗器械产品的指导原则可在本指导原则基础上进行有针对性的调整、修改和完善。一、范围本指
导原则适用于医疗器械软件的注册申报，包括第二类、第三类医疗器械产品，适用的软件开发方式包括自主开发、部分采用现成软件和全部采用现成
软件。医疗器械软件包括独立软件和软件组件。独立软件：作为医疗器械或其附件的软件；软件组件：作为医疗器械或其部件、附件组成的软件。独
立软件应同时具备以下三个特征：具有一个或多个医疗用途，无需医疗器械硬件即可完成预期用途，运行于通用计算平台。独立软件包括通用型软件
和专用型软件，其中通用型软件基于通用数据接口与多个医疗器械产品联合使用，如PACS、中央监护软件等；而专用型软件基于通用、专用的数
据接口与特定医疗器械产品联合使用，如Holter数据分析软件、眼科显微镜图像处理软件等。软件组件应同时具备以下两个特征：具有一个或
多个医疗用途，控制（驱动）医疗器械硬件或运行于专用（医用）计算平台。软件组件包括嵌入式软件和控制型软件，其中嵌入式软件（即固件）运
行于专用（医用）计算平台，控制（驱动）医疗器械硬件，如心电图机所含软件、脑电图机所含软件等；而控制型软件运行于通用计算平台，控制（
驱动）医疗器械硬件，如CT图像采集工作站软件、MRI图像采集工作站软件等。软件组件也可兼具处理功能。专用型独立软件可单独注册，也可
随医疗器械产品注册，此时视为软件组件。二、基本原则软件没有物理实体，在开发和使用过程中人为因素影响无处不在，软件测试由于时间和成本
的限制不能穷尽所有情况，所以软件缺陷无法避免。同时，软件更新频繁且迅速，轻微更新也可能导致严重后果，而且还存在退化问题（即每修复若
干个缺陷就会产生一个新缺陷），所以软件缺陷无法根除。因此，软件缺陷可视为软件的固有属性之一，软件的质量问题不容忽视。鉴于软件的特殊
性，医疗器械软件只有综合考虑风险管理、质量管理和软件工程的要求才能保证安全性与有效性。医疗器械软件的风险水平采用软件安全性级别（Y
Y/T0664《医疗器械软件软件生存周期过程》）进行分级，软件安全性级别基于软件损害严重度分为：A级：不可能对健康有伤害和损坏
；B级：可能有不严重的伤害；C级：可能死亡或严重伤害。软件安全性级别应结合软件的预期用途、使用环境和核心功能（软件在预期使用环境完
成预期用途所必需的功能）进行判定。其中预期用途主要考虑软件的临床用途（如诊断、治疗、监护、筛查等）和重要程度（如重要作用、辅助作用
、补充作用等），使用环境主要考虑软件的使用场所（如医院、家庭等）、疾病类型（如严重性、紧迫性、传染性等）、患者人群（如成人、儿童、
老年、女性等）和用户类型（如专业用户、普通用户、患者等），核心功能主要考虑软件的功能类型（如控制驱动、处理分析等）、实现方法（如C
T图像重建采用滤波反投影算法还是迭代算法，异常识别采用常规图像处理算法还是人工智能算法等）和复杂程度（如算法规模、参数数量、运算速
度等）。软件安全性级别也可根据风险管理所确定的风险等级进行判定，软件安全性级别与风险等级的分级可以不同，但二者存在对应关系，因此可
根据风险等级来判定软件安全性级别。制造商应在采取风险缓解措施之前判定软件安全性级别，并结合质量管理体系要求，建立与软件安全性级别相
匹配的软件生存周期过程，包括软件开发过程、软件维护过程、配置管理过程、风险管理过程和问题解决过程。同时，制造商可采用良好软件工程实
践完善质量管理体系要求，保证软件质量。另外，制造商应保证软件自身的信息安全，确保健康数据的保密性、完整性和可得性。制造商应基于软件
安全性级别提交相应注册申报资料。注册申报资料均源自软件生存周期过程所形成的文件资料，详尽程度取决于软件的安全性级别和复杂程度。独立
软件和软件组件尽管在结构和功能上有所不同，风险情况也不尽相同，但软件生存周期过程基本一致，故二者注册申报资料要求的基本原则相同，具
体要求有所差异。三、软件描述文档软件描述文档基于YY/T0664《医疗器械软件软件生存周期过程》予以制定，用于自主开发医疗器械
软件的产品注册。软件描述文档包括基本信息、实现过程和核心算法（详见表1）。（一）基本信息1.软件标识明确软件的名称、型号规格、发
布版本、制造商和生产地址。软件组件标识为制造商质量控制所用标识。2.安全性级别明确软件安全性级别（A级、B级、C级），详述确定理
由。3.结构功能依据软件设计规范（SDS）提供体系结构图和用户界面关系图（如适用）。体系结构图用于图示组成模块之间、组成模块与外
部接口之间的关系，依据体系结构图描述组成模块（注明选装、模块版本）的功能、模块关系和外部接口。用户界面关系图用于描述用户界面之间的
关系，依据用户界面关系图（如不适用则为体系结构图）描述临床功能模块（注明选装、模块版本）的功能和模块关系。4.硬件拓扑依据软件设
计规范（SDS）提供物理拓扑图，图示并描述软件（或组成模块）、通用计算机、医疗器械硬件之间的物理连接关系。5.运行环境明确软件运
行所需的硬件配置、软件环境和网络条件。其中硬件配置包括处理器、存储器和外设器件，软件环境包括系统软件、支持软件和安全软件，网络条件
包括网络架构（BS、CS）、网络类型（广域网、局域网、个域网）和带宽。6.适用范围独立软件描述软件的适用范围，软件组件描述医疗器
械产品的适用范围。进口医疗器械软件描述原产国情况。7.禁忌症独立软件描述软件的禁忌症或使用限制，软件组件描述医疗器械产品的禁忌症
或使用限制。进口医疗器械软件描述原产国情况。8.注册历史独立软件描述中国注册情况（列明历次注册的发布版本和注册证号）和原产国注册
情况（如适用，列明历次注册的日期、发布版本和管理类别），在其它主要国家和地区的注册情况也可提供。软件组件描述医疗器械产品的注册情况
。（二）实现过程1.开发概述明确软件开发所用的语言、工具和方法，其中工具描述支持软件（含开源软件）和应用软件（第三方软件）的名称
、完整版本和供应商。同时明确开发人员数量、开发时间、工作量（人月数）和代码行总数。2.风险管理依据风险管理相关标准提供软件风险分
析报告和软件风险管理报告，风险管理资料另附原始文件。软件组件提供医疗器械产品的风险管理资料。3.需求规范A级提供软件需求规范（S
RS）关于软件功能的要求，B级和C级提供软件需求规范全文。软件需求规范另附原始文件。软件组件如无单独的软件需求规范，可提供医疗器械
产品的需求规范。4.生存周期A级提供软件开发生存周期计划摘要，描述开发各阶段的划分情况和工作任务。B级在A级基础上提供配置管理计
划摘要和维护计划摘要，描述所用的工具和流程。C级在B级基础上提供设计历史文档集索引表（DHF）。生存周期也可提交制造商软件生存周期
过程文件或YY/T0664《医疗器械软件软件生存周期过程》等过程标准的核查表，用于替代相应描述。5.验证与确认验证是指通过提
供客观证据认定软件某开发阶段的输出满足输入要求，包括代码检查、设计评审、测试等质量保证活动。确认是指通过提供客观证据认定软件满足用
户需求和预期用途，通常是指在真实或模拟使用环境进行的用户测试。可追溯性分析是指追踪需求规范、设计规范、源代码、测试、风险管理之间的
关系，分析已识别关系的正确性、一致性、完整性和准确性。A级提供系统测试、用户测试的计划和报告摘要，描述测试的条件、工具、方法、通过
准则和结果。B级提供系统测试、用户测试的计划和报告，概述开发各阶段的验证活动，描述所用的工具、方法和任务。C级在B级基础上提供可追
溯性分析报告（追溯需求规范、设计规范、测试、风险管理的关系表）。系统测试和用户测试的计划和报告另附原始文件。测试报告关于测试记录的
内容可以提供一个测试记录样例和完整的测试记录清单。验证活动也可提交制造商软件质量保证计划文件，用于替代相应描述。6.缺陷管理A级
描述缺陷管理的工具和流程，明确软件本次注册已知的缺陷总数和剩余缺陷数。B级和C级在A级基础上列明已知剩余缺陷情况，证明全部已知剩余
缺陷的风险均是可接受的。已知剩余缺陷情况可另附原始文件。7.更新历史A、B、C级均应描述软件版本命名规则，明确软件版本的全部字段
及字段含义，确认软件完整版本和软件发布版本。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.轻微软件更新：不影响医疗器械安全性与有效性
的增强类更新和纠正类更新，即轻微增强类软件更新和纠正类软件更新。（二）重大软件更新根据定义，凡是影响到医疗器械安全性或有效性的软件
更新均为重大软件更新。具体而言，软件更新如影响到医疗器械的预期用途、使用环境或核心功能均为重大软件更新。本指导原则所述重大软件更新
包括以下情形之一：1.适应型软件更新：软件运行平台跨越互不兼容的计算平台（包括硬件和软件），如操作系统软件由Windows变为i
OS，32位计算平台变为64位计算平台、常规计算平台变为移动计算平台等，而系统软件和支持软件的补丁一般不视为重大软件更新，除非影响
到医疗器械的安全性或有效性。2.完善型软件更新：影响到用户临床决策（包括决策能力、决策结果、决策流程和用户临床行动），或者影响到
人员安全（包括患者、用户和其他相关人员），包括但不限于：（1）临床功能改变，如新增临床应用、新增运行模式、采用新核心算法等；（2）
软件输出结果改变，如医学图像或数据质量改变、用户界面增加临床信息等；（3）用户使用习惯改变，如用户原有临床工作流程改变、用户界面布
局改变等；（4）影响到患者安全，如采用新的软件安全标准、用户界面增加报警信息等。而核心算法运算速度的单纯性提高、临床工作流程的可配
置化（即用户可以保留原有临床工作流程）、用户界面的文字性修改，除非影响到医疗器械的安全性或有效性,一般不视为重大更新。3.其他软
件更新：软件的安全性级别、体系结构、用户界面关系或物理拓扑发生改变。重大软件更新的范围会随着认知水平与技术能力的提高、不良事件与召
回事件的分析进行动态调整。（三）软件更新要求医疗器械软件发生重大软件更新应进行许可事项变更，而发生轻微软件更新通过质量管理体系进行
控制，无需进行注册变更，待到下次注册（注册变更和延续注册）时提交相应申报资料。已注册的医疗器械软件在后续注册（注册变更和延续注册）
时应根据软件更新情况提交相应申报资料：1.重大软件更新软件发生重大软件更新应提交软件更新描述文档，包括基本信息、实现过程和核心算
法（详见表2）。表2软件更新描述文档框架软件描述文档申报要求基本信息软件标识明确软件本次注册情况，如改变详述更新内容。安全性级别
明确软件本次注册情况，如改变详述更新理由并按更新后的安全性级别提交资料。结构功能明确软件本次注册情况，如改变详述更新内容。硬件拓扑
明确软件本次注册情况，如改变详述更新内容。运行环境明确软件本次注册情况，如改变详述更新内容。适用范围明确软件本次注册情况，如改变详
述更新内容。禁忌症明确软件本次注册情况，如改变详述更新内容。注册历史明确软件本次注册情况。实现过程开发概述明确软件本次注册情况，如
改变详述更新内容。风险管理提供更新部分的风险管理资料，包含对整体的影响分析。需求规范提供更新部分的需求规范。生存周期提供软件维护流
程和配置管理流程。验证与确认提供更新部分的验证与确认资料，包含对整体影响的确认。缺陷管理提供缺陷管理流程，明确本次注册已知剩余缺陷
情况。更新历史明确版本命名规则，详述软件具体更新内容。临床评价提供更新部分的临床评价资料。核心算法提供更新部分的核心算法。2.轻
微软件更新软件发生轻微软件更新时，轻微增强类软件更新同样应提交软件更新描述文档，而纠正类软件更新应提交软件更新情况说明、回归测试计
划与报告、新增已知剩余缺陷情况说明。软件同时发生多种类型的软件更新，应按照风险从高原则提交申报资料，即同时发生重大软件更新和轻微软
件更新则按照重大软件更新处理，同时发生增强类软件更新和纠正类软件更新则按照增强类软件更新处理。医疗器械软件的重新开发（即制造商弃用
原有软件）不属于软件更新，应按照医疗器械产品注册的要求提交申报资料。五、软件版本（一）基本考量软件没有物理实体，只能通过状态管理保
证质量，而软件版本用于标识软件状态，控制软件更新，进而保证软件质量，因此软件版本与软件是相互对应的表里关系，即软件版本是软件标识不
可或缺的组成部分，也是实现医疗器械软件可追溯性的重要工具。制造商无论采用何种名称和形式（如修订号、构建号、发布日期等），只要用于标
识软件状态均视为软件版本。制造商制定软件版本命名规则除了考虑医疗器械产品自身特点、质量管理体系要求之外，还要考虑监管的要求，即软件
版本命名规则能够区分软件更新类型，可以确认软件完整版本和软件发布版本：1.软件完整版本：体现重大增强类软件更新、轻微增强类软件更
新、纠正类软件更新和构建（如适用）；2.软件发布版本：软件发行所用的标识版本，仅体现重大增强类软件更新（即重大软件更新）。软件发
布版本发生改变应进行许可事项变更，软件完整版本发生改变但软件发布版本未变无需进行注册变更。例如，软件版本命名规则为X.Y.Z.B，
其中X表示重大增强类软件更新，Y表示轻微增强类软件更新，Z表示纠正类软件更新，B表示构建，则软件完整版本为X.Y.Z.B，软件发布
版本为X，此时X发生变化应进行许可事项变更，而Y、Z和B发生变化无需进行注册变更。软件版本命名规则同样遵循风险从高原则，即不能区分
重大软件更新和轻微软件更新则按照重大软件更新处理，不能区分增强类软件更新和纠正类软件更新则按照增强类软件更新处理。（二）软件版本要
求制造商应出具软件版本命名规则真实性声明，明确软件版本的全部字段及字段含义，确认软件完整版本和软件发布版本。制造商应在说明书中明确
软件发布版本。对于独立软件（含专用型独立软件视为软件组件的情况）和控制型软件组件，制造商应在登录界面、主界面、“关于”或“帮助”等
界面体现软件完整版本和软件发布版本。六、现成软件（一）基本考量随着信息技术的快速发展，医疗器械产品使用现成软件的情况越来越普遍，但
现成软件不能完全满足医疗器械产品的预期用途，而且制造商未对现成软件进行完整生存周期控制，因此使用现成软件风险相对较高。由于要对医疗
器械产品最终的安全性与有效性负责，制造商应采用基于风险的方法保证现成软件的质量和安全。现成软件分为：1.成品软件：已开发且通常可
得到的，但制造商未进行完整生存周期控制的软件，包含商业软件和免费软件；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）遗留软件：制造商应提供遗留软件证明性文件（如Y
Y/T0664或IEC62304实施之前的注册证或上市批书复印件）、软件描述文档（不适用条款说明理由）、上市后临床评价资料；（
3）外包软件：制造商应提供外包合同复印件或声明、软件描述文档（不适用条款说明理由）。（三）现成软件更新要求现成软件的更新类型、更新
注册要求和风险从高原则与自主开发软件相同，注册申报资料要求与自主开发软件有所差异。现成软件发生重大软件更新时，应参照自主开发软件重
大软件更新要求提交现成软件更新描述文档，不适用条款说明理由。现成软件发生轻微软件更新时，轻微增强类软件更新同样应提交现成软件更新描
述文档，而纠正类软件更新与自主开发软件纠正类软件更新要求相同。对于部分采用现成软件的情况，自主开发的软件发生更新按照自主开发软件更
新要求提交相应申报资料，现成软件发生更新按照现成软件更新要求提交相应申报资料。（四）现成软件版本要求现成软件版本同样要考虑监管要求
和遵循风险从高原则。现成软件供应商的软件版本命名规则如符合监管要求，制造商可直接采用现成软件供应商的版本命名规则。制造商应在软件版
本命名规则真实性声明中明确现成软件的版本命名规则、完整版本和发布版本。七、注册单元与检测单元（一）注册单元划分原则1.独立软件独
立软件的注册单元以管理类别、预期用途、处理对象和临床功能模块作为划分原则。（1）不同管理类别的独立软件应作为不同注册单元，在无法分
割的情况下可作为一个注册单元并按照较高管理类别注册申报。（2）不同预期用途的独立软件应作为不同注册单元，按照预期用途大体上可分为治
疗计划类、诊断类、监护类和信息管理类。（3）不同处理对象的独立软件应作为不同注册单元，按照处理对象大体上可分为图像类和数据类。（4
）对于功能庞大复杂的独立软件，应依据临床功能模块的类型和数量划分注册单元，每个注册单元所含模块的数量应适中。按照模块功能可分为平台
功能软件和特定功能软件，其中平台功能软件作为软件平台提供基本功能和共用功能，支持多种模式的图像或数据，而特定功能软件运行于平台功能
软件并提供特定功能，支持单一模式的图像或数据，或实现某一特定预期用途。例如，某PACS包含数十个独立的临床功能模块，并含有CAD类
模块，可以拆分为一个平台功能软件和多个特定功能软件，其中CAD类模块应作为单独的注册单元。2.软件组件软件组件不符合医疗器械的定
义，不宜单独注册申报，应随医疗器械产品注册申报，注册单元与医疗器械产品相同。专用型独立软件视为软件组件时，要求与软件组件相同。（二
）检测单元划分原则检测单元是指同一注册单元内用于检测的代表产品。1.独立软件独立软件的检测单元原则上与注册单元一致，但如有多个运
行环境或多个发布版本，则每个互不兼容的运行环境或每个互不涵盖的发布版本均应作为一个检测单元。2.软件组件软件组件的检测单元原则上
与医疗器械产品一致，但医疗器械产品如包含多个软件组件或多个发布版本的软件组件，则每个软件组件或每个发布版本的软件组件均应作为一个检
测单元，除非检测单元完整覆盖注册单元全部情况。专用型独立软件视为软件组件时，检测单元原则上与软件组件相同，但如有多个运行环境，则每
个互不兼容的运行环境均应作为一个检测单元。八、注册申报资料要求本指导原则未提及的注册申报资料应符合《关于公布医疗器械注册申报资料要
求和批准证明文件格式的公告》的要求。（一）产品注册1.产品名称与结构组成（1）独立软件产品名称应为通用名称，并符合相关法规、规范
性文件的要求，可以结合人体部位（如胸部、心脏等）、临床科室（如骨科、神经外科等）、处理对象（如CT图像、MRI图像、心电数据等）和
功能用途（如计划、处理、CAD等）进行命名。结构组成应包括物理组成和逻辑组成，其中物理组成描述软件的存储介质或交付方式，如光盘、U
盘、预装于计算机交付或网络下载交付等；逻辑组成描述软件的临床功能模块，包括服务器（如适用）和客户端，注明选装和模块版本。（2）软件
组件软件组件无相应要求。专用型独立软件视为软件组件时，软件名称与独立软件要求相同，结构组成应明确软件的名称、型号规格和发布版本。2
.软件研究资料制造商应单独提供一份软件描述文档，具体要求详见第三节。鉴于进口医疗器械软件不一定在中国同步注册，即该软件在境外已多
次注册变更但在中国为首次产品注册，此时软件描述文档应涵盖申报范围内的全部研究资料。3.软件版本制造商应单独出具一份软件版本命名规
则真实性声明，具体要求详见第五节。对于独立软件（含专用型独立软件视为软件组件的情况）和控制型软件组件，注册检测报告应包含软件完整版
本和软件发布版本的界面照片。对于进口医疗器械软件，制造商应提供此发布版本软件在原产国获准上市的证明性文件。4.产品技术要求（1）
独立软件独立软件产品技术要求应在“产品型号/规格及其划分说明”中明确软件的名称、型号规格、发布版本和版本命名规则，而“性能指标”分
为通用要求、质量要求、专用要求和安全要求，其中通用要求应根据软件自身特性进行规范，质量要求应符合GB/T25000.51《软件工
程软件产品质量要求与评价（SQuaRE）商业现货（COTS）软件产品的质量要求与测试细则》的要求，专用要求应符合相关性能标准（
如放射治疗）的要求，安全要求应符合相关安全标准（如报警、放射治疗）的要求。独立软件产品技术要求模板详见附录I。（2）软件组件软件组
件应在医疗器械产品技术要求中进行规范，其中“产品型号/规格及其划分说明”应明确软件的名称、型号规格、发布版本、版本命名规则、运行环
境（控制型软件组件适用，包括硬件配置、软件环境和网络条件），而“性能指标”应明确软件全部临床功能纲要。专用型独立软件视为软件组件时
，要求与软件组件相同（运行环境适用）。5.临床评价资料（1）独立软件独立软件应依据《医疗器械临床评价技术指导原则》提交临床评价资
料，不适用条款说明理由。对于采用人工智能算法实现的功能（如计算机辅助检测、分类和诊断等CAD类功能），应提交基于临床试验的临床评价
资料。制造商可以选取已上市医疗器械产品所含的同类软件功能进行实质等同对比。（2）软件组件软件组件应与医疗器械产品整体开展临床评价工
作，提交医疗器械产品的临床评价资料。软件组件的处理功能可随医疗器械产品进行临床评价，也可单独进行临床评价，此时要求与独立软件相同。
专用型独立软件视为软件组件时，要求与软件组件的处理功能相同。6.现成软件（如适用）现成软件的申报要求和版本要求详见第六节。7.
说明书说明书应符合相关的法规、规范性文件、国家标准、行业标准的要求，体现软件全部功能（包含安全功能），明确软件发布版本。（二）许可
事项变更1.变更情况声明明确软件和现成软件（如适用）的版本命名规则、完整版本、发布版本和发布版本变更情况。2.软件研究资料医疗
器械许可事项变更应根据软件更新情况提交软件变化部分对产品安全性与有效性影响的研究资料：（1）涉及重大软件更新：单独提交一份软件更新
描述文档，具体要求详见第四节；（2）涉及轻微增强类软件更新：单独提交一份软件更新描述文档，具体要求详见第四节；（3）仅发生纠正类软
件更新：提交纠正类软件更新申报资料，具体要求详见第四节；（4）未发生软件更新：出具真实性声明。3.产品技术要求（1）独立软件独立
软件产品技术要求应体现软件更新情况，包括“产品型号/规格及其划分说明”、“性能指标”和“附录”。（2）软件组件（如适用）医疗器械产
品技术要求应体现软件更新情况，包括“产品型号/规格及其划分说明”中的软件信息、“性能指标”中的软件要求。专用型独立软件视为软件组件
时，要求与软件组件相同。4.现成软件（如适用）医疗器械许可事项变更应根据现成软件更新情况提交软件变化部分对产品安全性与有效性影响
的研究资料：（1）涉及重大软件更新：单独提交一份现成软件更新描述文档，具体要求详见第六节；（2）涉及轻微增强类软件更新：单独提交一
份现成软件更新描述文档，具体要求详见第六节；（3）仅发生纠正类软件更新：提交纠正类软件更新申报资料，具体要求详见第四节；（4）未发
生软件更新：出具真实性声明。5.说明书（如适用）说明书应体现软件全部功能（包含安全功能），明确软件发布版本，提供变化情况说明。（
三）延续注册1.产品未变化声明明确软件和现成软件（如适用）的版本命名规则、完整版本和发布版本。2.产品分析报告（如适用）根据已
注册医疗器械软件在后续注册时应提交软件更新资料的要求，医疗器械延续注册产品分析报告第（六）项应提交相应软件更新资料：（1）涉及轻微
增强类软件更新：单独提交一份软件更新描述文档、现成软件更新描述文档，具体要求详见第四节、第六节；（2）仅发生纠正类软件更新：提交纠
正类软件更新申报资料，具体要求详见第四节。3.特殊情形本次注册如涉及重大软件更新，前次注册所批准的事项可以延续注册。九、参考文献
[1]《医疗器械注册管理办法》（国家食品药品监督管理总局令第4号）[2]《医疗器械说明书和标签管理规定》（国家食品药品监督管理总局
令第6号）[3]《医疗器械召回管理办法（试行）》（卫生部令第82号）[4]国家食品药品监督管理总局关于发布医疗器械产品技术要求编
写指导原则的通告（国家食品药品监督管理总局通告2014年第9号）[5]国家食品药品监督管理总局关于公布医疗器械注册申报资料要求和
批准证明文件格式的公告（国家食品药品监督管理总局公告2014年第43号）?[6]国家食品药品监督管理总局关于实施《医疗器械注册管
理办法》和《体外诊断试剂注册管理办法》有关事项的通知(食药监械管[2014]144号)[7]国家食品药品监督管理总局关于发布医疗
器械临床评价技术指导原则的通告（国家食品药品监督管理总局通告2015年第14号）[8]GB/T13702-1992《计算机软件
分类代码》[9]GB/T18492-2001《信息技术系统及软件完整性级别》[10]GB/T11457-2006《信息技
术软件工程术语》[11]GB/T20157-2006《信息技术软件维护》[12]GB/T19003-2008《软件工程
GB/T19001-2000应用于计算机软件的指南》[13]GB/T25000.51-2010《软件工程软件产品质量要
求与评价（SQuaRE）商业现货（COTS）软件产品的质量要求与测试细则》[14]YY0637-2013《医用电气设备放射
治疗计划系统的安全要求》[15]YY0709-2009《医用电气设备?第1-8部分：安全通用要求并列标准医用电气设备和医用
电气系统中报警系统的测试和指南》[16]YY0721-2009《医用电气设备放射治疗记录与验证系统的安全》[17]YY0
775-2010《远距离放射治疗计划系统高能X(γ）射束剂量计算准确性要求和试验方法》[18]YY0831.1-2011《γ
射束立体定向放射治疗系统第1部分：头部多源γ射束立体定向放射治疗系统》[19]YY0832.1-2011《X射线放射治疗立体
定向及计划系统第1部分：头部X射线放射治疗立体定向及计划系统》[20]YY/T0287-2003《医疗器械质量管理体系法规
要求》[21]YY/T0316-2008《医疗器械风险管理对医疗器械的应用》[22]YY/T0664-2008《医疗器械
软件软件生存周期过程》[23]YY/T0708-2009《医用电气设备第1-4部分：安全通用要求并列标准可编程医用电气
系统》[24]YY/T0887-2013《放射性粒籽植入治疗计划系统剂量计算要求和试验方法》[25]YY/T0889-2
013《调强放射治疗计划系统性能和试验方法》[26]FDA,DoItbyDesign-AnIntroduction
toHumanFactorsinMedicalDevices,December,1996[27]FDA,Dec
idingWhentoSubmita510(k)foraChangetoanExistingDevice,
January10,1997[28]FDA,ReviewerGuidanceforaPremarketNoti
ficationSubmissionforBloodEstablishmentComputerSoftware,Ja
nuary13,1997[29]FDA,DesignControlGuidanceforMedicalDevice
Manufacturers,March11,1997?[30]FDA,GuidancefortheContent
ofPremarketSubmissionsforSoftwareContainedinMedicalDevic
es,May29,1998[31]FDA,GuidanceforIndustry,FDAReviewersand
ComplianceonOff-The-ShelfSoftwareUseinMedicalDevices,Sep
tember9,1999[32]FDA,GuidancefortheSubmissionofPremarketN
otificationsforMedicalImageManagementDevices,July27,2000[
33]FDA,GeneralPrinciplesofSoftwareValidation;FinalGuidanc
eforIndustryandFDAStaff,January11,2002[34]FDA,Cybersecu
rityforNetworkedMedicalDevicesContainingOff-the-ShelfSoftw
are,January14,2005[35]FDA,GuidancefortheContentofPremar
ketSubmissionsforSoftwareContainedinMedicalDevices,May11
,2005[36]FDA,GuidanceforIndustryandFDAStaff-Modificatio
nstoDevicesSubjecttoPremarketApproval(PMA)-ThePMASuppl
ementDecision,December11,2008[37]FDA,GuidanceforIndustry
andFoodandDrugAdministrationStaff-Computer-AssistedDetect
ionDevicesAppliedtoRadiologyImagesandRadiologyDeviceData
-PremarketNotification[510(k)]Submissions,July3,2012[38]
FDA,GuidanceforIndustryandFDAStaff-ClinicalPerformanceA
ssessment:ConsiderationsforComputer-AssistedDetectionDevices
AppliedtoRadiologyImagesandRadiologyDeviceData-Premarke
tApproval(PMA)andPremarketNotification[510(k)]Submissions,
July3,2012[39]FDA,ContentofPremarketSubmissionsforManag
ementofCybersecurityinMedicalDevices-GuidanceforIndustry
andFoodandDrugAdministrationStaff,October2,2014[40]FDA,
MobileMedicalApplications-GuidanceforIndustryandFoodand
DrugAdministrationStaff,February9,2015[41]FDA,MedicalDev
iceDataSystems,MedicalImageStorageDevicesandMedicalImage
CommunicationsDevices-GuidanceforIndustryandFoodandDrug
AdministrationStaff,February9,2015[42]FDA,GeneralWellness
:PolicyforLowRiskDevices-DraftGuidanceforIndustryandF
oodandDrugAdministrationStaff,January20,2015[43]MEDDEV2.
7/1Rev.3,Clinicalevaluation:Guideformanufacturersandnotif
iedbodies,December2009[44]MEDDEV2.7/4,GuidelinesonClinica
linvestigations:aguideformanufacturersandnotifiedbodies,
December2010[45]MEDDEV2.1/6,QualificationandClassification
ofstandalonesoftware,January2012[46]NB-MED/2.2/Rev4,Softwar
eandMedicalDevices,March29,2010[47]Team-NB,FrequentlyAsk
edQuestionsrelatedtotheImplementationofEN62304:2006with
respecttoMDD93/42/EEC,April5,2013[48]IEC62366Ed1.1:2014,
Medicaldevices-Applicationofusabilityengineeringtomedica
ldevices[49]IEC/TR80002-1:2009,Medicaldevicesoftware-Part
1:GuidanceontheapplicationofISO14971tomedicaldeviceso
ftware[50]IEC80001-1:2010,ApplicationofriskmanagementforIT
-networksincorporatingmedicaldevices-Part1:Roles,responsib
ilitiesandactivities[51]IEC/TR80001-2-1:2012,Applicationof
riskmanagementforIT-networksincorporatingmedicaldevices-P
art2-1:Step-by-stepriskmanagementofmedicalIT-networks–Pr
acticalapplicationsandexamples[52]IEC/TR80001-2-2:2012,Appl
icationofriskmanagementforIT-networksincorporatingmedical
devices-Part2-2:Guidanceforthedisclosureandcommunication
ofmedicaldevicesecurityneeds,risksandcontrols[53]IEC/TR
80001-2-3:2012,ApplicationofriskmanagementforIT-networksin
corporatingmedicaldevices-Part2-3:Guidanceforwirelessnet
works[54]IEC/TR80001-2-4:2012,Applicationofriskmanagementf
orIT-networksincorporatingmedicaldevices-Part2-4:Applicat
ionguidance-Generalimplementationguidanceforhealthcaredel
iveryorganizations[55]IEC62304am1,Medicaldevicesoftware-
Softwarelifecycleprocesses[56]IEC82304-1,HealthSoftware-
Part1:Generalrequirementsforproductsafety[57]IEC/TR80002-
2,Medicaldevicesoftware-Part2:Validationofsoftwareforr
egulatedprocesses[58]IMDRF/UDIWG/N7FINAL:2013,UDIGuidance:U
niqueDeviceIdentificationofMedicalDevices,December18,2013[5
9]IMDRF/SaMDWG/N10FINAL:2013,SoftwareasaMedicalDevice:Key
Definitions,December18,2013[60]IMDRF/SaMDWG/N12FINAL:2014,S
oftwareasaMedicalDevice:PossibleFrameworkforRiskCategori
zationandCorrespondingConsiderations,September18,2014附录I独立软件产
品技术要求模板医疗器械产品技术要求医疗器械产品技术要求编号：产品名称1.产品型号/规格及其划分说明1.1软件型号规格1.2软
件发布版本1.3版本命名规则明确软件完整版本的全部字段及字段含义2.性能指标2.1通用要求2.1.1处理对象明确软件的处
理对象类型，如图像（如CT、MRI、X-ray、PET、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/T25000.51第5章要求2.3专用要求（如适用）注：依据相应标准条款逐条描述2.3.1
YY0775（如适用）……2.4安全要求（如适用）注：列明相应安全标准名称即可2.4.1YY0709（如适用）2.4.
2YY0637（如适用）2.4.3YY0721（如适用）……3.检验方法3.1通用要求符合性检验通过检查说明书、实际操
作验证2.1的符合性。3.2质量要求符合性检验依据GB/T25000.51第7章方法验证2.2的符合性。3.3专用要求检验方
法（如适用）3.3.1依据YY0775的方法进行检验（如适用）。……3.4安全要求检验方法（如适用）3.4.1依据YY07
09的方法进行检验（如适用）。3.4.2依据YY0637的方法进行检验（如适用）。3.4.3依据YY0721的方法进行检验
（如适用）。……4.术语（如适用）4.1……4.2…………（分页）附录1.体系结构图及必要注释2.用户界面关系图及必要注释3
.物理拓扑图及必要注释医疗器械软件注册技术审查指导原则编制说明一、编写目的和依据本指导原则旨在指导制造商提交医疗器械软件注册申报资
料，同时也规范医疗器械软件的技术审评要求。本指导原则是在现行法规和标准体系以及当前认知水平下、并参考了国外法规与指南、国际标准与技
术报告制定的，特别是借鉴了IMDRF相关工作组（SaMD、UDI）的文件。随着法规和标准的不断完善，以及认知水平和技术能力的不断提
高，相关内容也将适时进行修订。另外，为了保证可读性，本指导原则的部分内容有意留有冗余信息。二、有关内容说明软件没有物理实体，具有特
殊性。为了达到监管目的同时促进行业发展，本指导原则在现行法规框架下针对软件的特殊性进一步明确了软件的监管要求，特别是对软件更新、软
件版本的要求。本指导原则是医疗器械软件的通用指导原则，其他涉及软件医疗器械产品的指导原则可在本指导原则基础上进行有针对性的调整、修
改和完善。软件只有结合风险管理、质量管理和软件工程的要求才能保证质量，因此良好的软件生存周期过程对于保证软件质量至关重要。制造商应
基于YY/T0664-2008《医疗器械软件软件生存周期过程》建立起与软件安全性级别相匹配的软件生存周期过程，并作为自身质量管
理体系的组成部分。软件描述文档于2010年12月1日（YY/T0708-2009《医用电气设备第1-4部分：安全通用要求并列
标准可编程医用电气系统》实施时间）开始要求，基于近五年的实施情况和反馈意见进行了修改和调整。部分条款名称进行了文字性修改，以保证
用语更规范更准确，具体为：“产品标识”改为“软件标识”，“硬件关系”改为“硬件拓扑”，“上市历史”改为“注册历史”，“开发综述”改
为“开发概述”、“需求规格”改为“需求规范”、“修订历史”改为“更新历史”。同时，部分条款内容也进行了修改和调整，具体为：“结构功
能”强化了用户界面关系图和临床功能模块的要求；“适用范围”和“禁忌症”明确进口软件描述原产国的情况，删除了适用人群的要求；“注册历
史”强化了原产国的要求，不再强调美国、欧盟和日本的情况；“开发概述”删除了生存周期模型和控制文档总数的要求；“需求规范”简化了A级软件的要求；“生存周期”将“各阶段输入输出文档”改为“设计历史文档集索引表（DHF）”，细化了附件要求；“验证与确认”删除了单元测试覆盖率和集成测试集成策略的要求，简化了测试报告的申报资料要求，C级软件增加了可追溯性分析报告的要求，验证活动细化了附件要求；“更新历史”强化了更新具体内容的要求；“核心算法”范围与IMDRF保持一致，同时为了避免涉及商业秘密并参考IMDRF要求将“原理”改为“临床功能”，A级软件统一了公认成熟算法和全新算法的要求。软件可追溯性分析是保证软件质量的重要技术手段，美国和欧盟均要求全面开展软件可追溯性分析工作。考虑到境内制造商存在一定实施难度，故本指导原则仅对C级软件进行了要求，A级和B级软件未做要求。但从技术发展趋势而言，今后将在适当时机要求制造商全面开展软件可追溯性分析工作。重大软件更新和轻微软件更新不存在清晰明确的划分界线，需要具体情况具体分析。本指导原则综合考虑监管目标和行业发展的关系，基于现有的认知水平、技术能力和监管资源明确了重大软件更新的范围，今后会随着认知水平与技术能力的提高、不良事件与召回事件的分析动态调整重大软件更新的范围。软件没有物理实体，只能通过状态管理保证质量。软件版本用于标识软件状态和控制软件更新，与软件是相互对应的表里关系，即软件版本是软件标识不可或缺的组成部分，因此可以基于软件版本实现软件监管目的，特别是对软件更新的监管，但前提是软件版本命名规则是真实有效的。本指导原则所述现成软件仅包含应用软件,暂不包含系统软件和支持软件。这是基于当前技术审评侧重的考虑，并不意味制造商可以放弃对系统软件和支持软件的质量管理，现成软件的范围今后将在适当时机下扩至系统软件和支持软件。同时，也是基于现成软件仅包含应用软件的考虑，现成软件的软件描述文档增加了核心算法的要求，但内容进行了简化；对于全部采用遗留软件的开发方式，增加了上市后临床评价资料的要求。独立软件目前尚无医疗器械产品标准，产品技术要求暂以通用软件产品标准GB/T25000.51-2010《软件工程软件产品质量要求与评价（SQuaRE）商业现货（COTS）软件产品的质量要求与测试细则》作为参考，但由于该标准不是医疗器械产品标准，相应要求不能完全满足监管要求，因此产品技术要求模板进行了适当调整。今后，独立软件产品技术要求模版将随着国家标准和行业标准的实施情况进行调整。医疗器械软件功能众多，难以统一临床评价要求。本指导原则依据《医疗器械临床评价技术指导原则》明确了软件临床评价的一般原则，制造商应根据相关法规、规范性文件的要求并结合软件自身特性开展相应的临床评价工作。说明书是评价软件质量的重要依据，因此说明书应真实、准确和完整的体现软件当前状态。由于软件更新情况复杂，某些情况下仅依靠说明书的变化内容无法评估软件当前状态，特别是对重大软件更新。因此，软件更新仍需提交软件当前状态下的全部说明书，并提交变化情况说明，除非软件更新内容未在说明书中体现。随着网络技术的快速发展，越来越多的医疗器械具有联网功能，信息安全问题随之产生，近来美国和欧盟均加强了医疗器械信息安全的监管要求。考虑到信息安全并不限于软件，我国医疗器械信息安全监管工作尚处于起步阶段，本指导原则对软件的信息安全提出了原则性要求，今后将在适当时机下单独制定医疗器械信息安全技术审查指导原则。三、起草单位国家食品药品监督管理总局医疗器械技术审评中心。—10——44——43——36——36— |
|
