附件 医疗器械软件注册审查指导原则 （2022 年修订版） 本指导原则旨在指导注册申请人规范医疗器械软件生存周 期过程和准备医疗器械软件注册申报资料，同时规范医疗器械 软件的技术审评要求，为医疗器械软件、质量管理软件的体系 核查提供参考。 本指导原则是对医疗器械软件的一般要求，注册申请人需 根据产品特性和风险程度确定本指导原则具体内容的适用性， 若不适用详述理由。注册申请人亦可采用其他符合法规要求的 替代方法，但需提供详尽研究资料。 本指导原则是在现行法规、强制性标准体系以及当前科技 能力、认知水平下制定的，随着法规、强制性标准体系的不断 完善以及科技能力、认知水平的不断发展，本指导原则相关内 容也将适时调整。 本指导原则作为注册申请人、审评人员和检查人员的指导 性文件，不包括审评审批所涉及的行政事项，亦不作为法规强 制执行，应在符合法规要求的前提下使用本指导原则。 本指导原则是数字医疗（Digital Health）指导原则体系的 基础指导原则，亦是医疗器械软件的通用指导原则，其他含有 — 1 — 或涉及软件的医疗器械指导原则可在本指导原则基础上进行有 针对性的调整、修改和完善。 一、适用范围 本指导原则适用于医疗器械软件的注册申报，包括第二、 三类独立软件和含有软件组件的医疗器械（包括体外诊断医疗 器械）；适用于自研软件、现成软件的注册申报。 本指导原则也可用作医疗器械软件、质量管理软件的体系 核查参考。 二、主要概念 （一）医疗器械软件 医疗器械软件包括本身即为医疗器械的软件或者医疗器械 内含的软件，前者即医疗器械独立软件（简称独立软件），后者 即医疗器械软件组件（简称软件组件），详见图 1。 独立软件（SaMD）是指具有一个或多个医疗目的/用途， 无需医疗器械硬件即可完成自身预期用途，运行于通用计算平 台的软件1。通用计算平台满足信息技术设备安全要求（含电磁 兼容），符合 GB 4943.1、GB/T 9254 等标准。 独立软件可分为通用型独立软件和专用型独立软件，前者 通常基于通用数据接口与多个医疗器械联合使用，如医学图像 处理软件、患者监护软件；后者基于通用、专用数据接口与特 定医疗器械联合使用，可视为医疗器械附件，如动态心电数据 1详见 IMDRF/SaMD WG/N10 FINAL: 2013。 — 2 — 分析软件、眼科显微镜图像处理软件。 软件组件（SiMD）是指具有一个或多个医疗目的/用途， 控制/驱动医疗器械硬件或运行于医用计算平台的软件。医用计 算平台满足医用电气设备（GB 9706 系列）、实验室用电气设备 （GB 4793 系列）或有源植入式医疗器械（GB 16174 系列）等 安全要求（含电磁兼容） ；医用计算平台可与通用计算平台联合 使用构成系统，整体视为医用计算平台。 软件组件可分为内嵌型软件组件和外控型软件组件，前者 运行于医用计算平台，控制/驱动医疗器械硬件，如心电图机、 脑电图机所含嵌入式软件（即固件） ；后者运行于通用计算平台， 控制/驱动医疗器械硬件，如 CT、MRI 图像采集工作站软件2。 图 1 医疗器械软件类型 独立软件作为医疗器械或医疗器械附件，通常单独注册， 特殊情况可随医疗器械进行注册，此时虽不控制/驱动医疗器械 2医用计算平台、软件组件可参考 GB 9706.1-2020 关于医用电气设备/系统、可编程医用电气设备/系统的定义和 要求。 — 3 — 硬件但从产品角度运行于医用计算平台，故视为软件组件，如 专用型独立软件可作为附件随医疗器械进行注册。 软件组件作为医疗器械或医疗器械部件、附件的组成部分， 不宜单独注册，需随医疗器械进行整体注册。 （二）系统软件、应用软件、中间件、支持软件 系统软件是指设计用于保障计算机系统正常运行的软件， 如操作系统软件、虚拟机软件。应用软件是指设计用于实现计 算机用户特定需求的软件，如浏览器软件、数据库软件、安全 软件。中间件介于系统软件和应用软件之间，依赖于系统软件 的支持，同时又为应用软件提供支持，如分布式计算平台软件。 支持软件是指设计用于开发、测试其他软件的软件，如软件开 发工具、软件测试工具。 医疗器械软件属于应用软件，其正常运行通常需要基于系 统软件，或同时需要应用软件（含其他医疗器械软件）、中间件、 支持软件的支持。 有些注册申请人会开发医用中间件用作医疗器械软件的公 共支持平台，由于这些医用中间件是医疗器械软件正常运行所 必需的，故作为医疗器械软件的组成部分予以考虑。 有些支持软件（如 VTK、ITK）自带算法库，医疗器械软 件开发过程已将算法库相关内容集成于自身内部，故医疗器械 软件正常运行需要这些支持软件的支持。 本指导原则将医疗器械软件正常运行所必需的其他的医疗 — 4 — 器械软件及医用中间件称为必备软件，而将其正常运行所必需 的系统软件、通用应用软件、通用中间件、支持软件统称为外 部软件环境。必备软件作为医疗器械软件单独注册，明确相互 接口关系及技术特征即可。外部软件环境不含必备软件，亦非 医疗器械软件。 （三）软件生存周期 软件生存周期（又称软件生命周期）是指软件系统从概念 定义至停止使用的时间周期，包括软件开发策划、软件需求分 析、软件设计、软件编码、软件测试、软件发布、软件部署、 软件维护、软件停运等阶段。其中，从软件需求分析到软件发 布的时间周期称为软件开发生存周期。 软件开发策划主要确定软件开发的目标和可行性。软件需 求分析是将法规、标准、用户、产品等要求转换为软件需求规 范/软件需求规格说明（SRS） 。软件设计是通过设计活动将软件 需求规范转换为软件设计规范/软件设计规格说明（SDS）。软 件编码是通过编写源代码将软件设计规范转换为软件系统。软 件测试是通过各类测试活动保证软件系统质量。软件发布是将 软件系统予以产品定型。软件部署是指软件系统的交付、安装、 设置和配置。软件维护是对软件系统发布后的更新需求予以实 现。软件停运（即软件退市）是指终止软件系统的销售和售后 服务，售后服务停止时间通常晚于停售时间。 软件生存周期模型是指一组包含过程、活动和任务的框架， — 5 — 跨越从软件需求分析到软件停运的软件生存周期过程，每个过 程可细分为若干活动，每个活动又可细分为若干任务。其中， 软件开发生存周期模型是软件生存周期模型的重要组成部分， 常见模型包括瀑布模型、迭代模型、增量模型、V 模型等。 敏捷开发是以人为核心、迭代与增量相结合的软件开发方 法，常见软件开发生存周期模型包括 SCRUM、极限编程等。 敏捷开发秉承四条理念：人员互动胜于过程和工具，可用的软 件胜于详尽的文档，客户合作胜于合同谈判，响应变化胜于遵 循计划。因此，使用敏捷开发应兼顾质量管理体系相关要求， 重点关注软件更新、文件与记录等控制要求。 注册申请人可结合软件的产品特点、风险程度以及质量管 理体系要求，选择适宜的软件生存周期模型，参照相关国际、 国家、行业标准建立相应软件生存周期过程。 （四）软件测试、软件验证、软件确认 软件测试是软件质量保证的基本措施，也是软件验证、软 件确认的重要方法，从不同角度有不同分类方法。 从测试依据角度可分为黑盒测试和白盒测试。其中，黑盒 测试是指基于输入与输出的测试，白盒测试是指基于源代码的 测试，黑盒测试与白盒测试可组合使用，即灰盒测试。白盒测 试根据是否运行源代码又可分为静态、动态分析/测试。 从测试进程角度可分为单元测试、集成测试、系统测试。 其中，单元测试是对软件单元进行测试，通常采用白盒测试； — 6 — 集成测试是对软件项（由若干软件单元组成，即软件模块）进 行测试，白盒测试、黑盒测试、灰盒测试相结合；系统测试是 对软件系统（由若干软件项组成）进行测试，通常采用黑盒测 试，其从测试内容角度又可分为功能测试、性能测试、并发测 试、压力测试、接口测试、内存测试、兼容性测试、用户界面 测试、安装卸载测试、安全测试等。 从测试实施方角度可分为内部测试、用户测试、第三方测 试。其中，内部测试是指注册申请人实施的测试，包括单元测 试、集成测试、系统测试，白盒测试、黑盒测试、灰盒测试相 结合；用户测试是指预期用户在真实或模拟使用场景对软件系 统进行测试，采用黑盒测试；第三方测试是指第三方机构对软 件系统进行测试，通常采用黑盒测试。 回归测试是指用于确定软件更新没有产生不良影响且未引 入风险不可接受新缺陷的软件测试。回归测试需根据软件更新 的类型、内容和程度，开展与之相适宜的单元测试、集成测试、 系统测试、用户测试、第三方测试等测试活动。 软件验证是指通过提供客观证据认定软件开发、软件维护 某一阶段的输出满足输入要求。软件验证包括源代码审核、静 态和动态分析/测试、单元测试、集成测试、系统测试、设计评 审等系列活动，是软件确认的基础。 软件确认是指通过提供客观证据认定软件满足用户需求和 预期用途。软件确认是基于过程控制的设计确认，包括用户测 — 7 — 试、临床评价、设计评审等系列活动，即要保证软件满足用户 需求和预期用途，又要确保软件已知剩余缺陷的风险均可接受。 注册申请人需结合软件的产品特点、风险程度考虑相应软 件测试要求，明确语句、判定、条件、路径等测试覆盖率要求， 以保证软件验证、软件确认的质量。全部源代码均应测试，可 结合白盒测试、黑盒测试、灰盒测试等方法予以实现。 （五）软件可追溯性分析 软件可追溯性分析作为软件验证、软件确认的重要活动之 一，是指追踪软件需求、软件设计、源代码、软件测试、软件 风险管理之间的关系，分析已识别关系的正确性、一致性、完 整性、准确性。 软件生存周期过程均需开展可追溯性分析活动，详见图 2。 软件需求分析阶段追溯分析软件需求与产品需求、软件需求与 风险分析的关系。软件设计阶段追溯分析软件设计与软件需求、 软件设计与风险控制的关系。软件编码阶段追溯分析源代码与 软件设计、源代码与测试用例的关系。内部测试阶段追溯分析 单元测试、集成测试、系统测试各级测试用例与软件设计，系 统测试与软件需求，系统测试与风险管理的关系。用户测试阶 段追溯分析用户测试与产品需求、用户测试与风险管理的关系。 软件更新亦需开展与之相适宜的软件可追溯性分析活动。 — 8 — 图 2 软件可追溯性分析 注册申请人应建立软件可追溯性分析过程，规范软件可追 溯性分析相关活动要求，以保证软件验证、软件确认的质量。 考虑到行业实际情况，源代码追溯分析活动追溯至软件单元（列 明名称）即可。 （六）软件更新 1. 主要概念 软件更新是指注册申请人在软件生存周期全过程对软件所 做的任一修改，亦称软件变更、软件维护。软件维护通常与软 件更新含义相同，但可特指发布后软件更新。 软件更新从不同角度出发有不同分类方法。从更新结果角 度可分为重大更新和轻微