医疗器械软件技术审查指导原则

（第二版）

本指导原则旨在指导生产企业规范医疗器械软件生存周期过程和准备医疗器械软件注册申报资料，同时规范医疗器械软件技术审评要求，为医疗器械软件和质量管理软件的体系核查提供参考。

本指导原则是对医疗器械软件的一般性要求，生产企业应根据医疗器械软件特性提交注册申报资料，判断本指导原则具体内容的适用性，不适用内容详述理由。生产企业亦可采用其他符合法规要求的替代方法，但应提供详尽研究资料。

本指导原则基于当前认知水平和技术能力，在现行法规体系下参考国外法规与指南、国际标准与技术报告予以制定。随着认知水平和技术能力的不断提高以及法规体系的不断完善，相关内容也将适时修订。

本指导原则作为生产企业、审评人员和检查人员的指导性文件，不包括审评审批所涉及的行政事项，亦不作为法规强制执行，应在符合法规要求的前提下使用本指导原则。

本指导原则针对软件特殊性，在现行法规体系下进一步明确医疗器械软件监管要求。本指导原则是医疗器械软件的通用指导原则，其他涉及软件的医疗器械指导原则可在本指导原则基础上进行有针对性的调整、修改和完善。

一、适用范围

本指导原则适用于医疗器械软件的注册申报，包括第二、三类独立软件和含有软件组件的医疗器械；适用于自研软件、现成软件的注册申报。

本指导原则也可用作医疗器械软件、质量管理软件体系核查的参考。

二、软件基础

（一）医疗器械软件

医疗器械软件包括本身即为医疗器械的软件或者医疗器械内含的软件，前者即医疗器械独立软件（以下简称独立软件），后者即医疗器械软件组件（以下简称软件组件），详见图1。

独立软件是指具有一个或多个医疗目的/用途，无需医疗器械硬件即可完成自身预期目的/用途，运行于通用计算平台的软件，通用计算平台满足信息技术设备安全要求。独立软件可分为通用型独立软件和专用型独立软件，前者通常基于通用数据接口与多个医疗器械联合使用，如医学图像处理软件、生理参数监护软件；后者基于通用、专用数据接口与特定医疗器械联合使用，可视为医疗器械附件，如动态心电数据分析软件、眼科显微镜图像处理软件。

软件组件是指具有一个或多个医疗目的/用途，控制/驱动医疗器械硬件或运行于医用计算平台的软件，医用计算平台满足医用电气设备或实验室用电气设备安全要求。医用计算平台可与通用计算平台联合使用构成系统，整体视为医用计算平台。软件组件可分为内嵌型软件组件和外控型软件组件，前者运行于医用计算平台，控制/驱动医疗器械硬件，如心电图机、脑电图机所含嵌入式软件（即固件），产品整体属于可编程医用电气设备；后者运行于通用计算平台，控制/驱动医疗器械硬件，产品整体属于可编程医用电气系统，如CT、MRI图像采集工作站软件。

独立软件作为医疗器械或医疗器械附件，通常单独注册，特殊情况可随医疗器械进行注册，此时虽不控制/驱动医疗器械硬件但运行于医用计算平台，故视为软件组件，如专用型独立软件可作为附件随医疗器械进行注册。软件组件作为医疗器械或医疗器械部件、附件的组成部分，不能单独注册，需随医疗器械进行注册。

图1：医疗器械软件

（二）系统软件、应用软件、中间件、支持软件

系统软件是指设计用于保障计算机系统正常运行的软件，如操作系统软件、虚拟机软件。应用软件是指设计用于实现计算机用户特定需求的软件，如浏览器软件、数据库软件、安全软件。中间件介于系统软件和应用软件之间，依赖于系统软件的支持，同时又为应用软件提供支持，如Web服务器软件。支持软件是指设计用于开发、测试其他软件的软件，如软件开发工具、软件测试工具。

医疗器械软件属于应用软件，其正常运行通常需要基于系统软件，或同时需要应用软件（含其他医疗器械软件）、中间件、支持软件的支持。

有些生产企业会开发医用中间件用作本企业医疗器械软件的公共支持平台，这些医用中间件本身虽无需单独注册，但却是医疗器械软件正常运行所必需的，故作为医疗器械软件的组成模块予以考虑。

有些支持软件（如VTK、ITK）自带算法库，医疗器械软件开发过程已将算法库相关内容集成于自身内部，故医疗器械软件正常运行需要这些支持软件。

本指导原则将医疗器械软件正常运行所必需的其他医疗器械软件、医用中间件称为必备软件，而将其正常运行所必需的系统软件、通用应用软件、通用中间件、支持软件统称为外部软件环境，即外部软件环境不含必备软件。

（三）软件生存周期

软件生存周期（又称软件生命周期）是指软件系统从概念定义至停止使用的时间周期，包括软件开发策划、软件需求分析、软件设计、软件编码、软件测试、软件发布、软件部署、软件维护、软件停运等阶段。

软件开发策划主要确定软件开发的目标和可行性。软件需求分析是将法规、标准、用户、产品等方面要求转换为软件需求规范/软件需求规格说明（SRS）。软件设计是将软件需求规范转换为软件设计规范（SDS）。软件编码是通过编写源代码将软件设计规范转换为软件系统。软件测试是通过各类测试活动保证软件系统质量。软件发布是将软件系统予以产品定型。软件部署是指软件系统的交付、安装、设置和配置。软件维护是对软件系统上市后的更新需求予以实现。软件停运（又称软件退市）是指终止软件系统的销售和售后服务。

软件生存周期模型是指一组包含过程、活动和任务的框架，跨越从软件需求分析到软件停运的软件生存周期过程，每个过程可细分为若干活动，每个活动又可细分为若干任务。常见模型包括瀑布模型、迭代模型、增量模型、V模型等。

敏捷开发是以人为核心、迭代与增量相结合的软件生存周期模型，如SCRUM、极限编程（XP）等。敏捷开发秉承四条理念：人员互动胜于过程和工具，可用的软件胜于详尽的文档，客户合作胜于合同谈判，响应变化胜于遵循计划。使用敏捷开发需要兼顾质量管理体系相关要求，重点关注软件更新控制、文件与记录控制等要求。

生产企业可结合软件的产品特点、风险程度以及质量管理体系要求，选择适宜的软件生存周期模型，参照相关国际、国家、行业标准建立相应软件生存周期过程。

（四）软件测试、软件验证、软件确认

软件测试是软件质量保证的基本措施，也是软件验证、软件确认的重要方法，从不同角度有不同分类方法。

从测试依据角度可分为黑盒测试和白盒测试。其中，黑盒测试是指基于规范的测试，白盒测试是指基于源代码的测试。白盒测试根据是否运行源代码又可分为静态分析和动态分析，需考虑语句、判定、条件、路径等测试覆盖率要求，其中语句测试覆盖率应保证100%。

从测试进程角度可分为单元测试、集成测试、系统测试。其中，单元测试是对软件单元进行测试，通常采用白盒测试；集成测试是对软件项（由若干软件单元组成，即软件模块）进行测试，白盒测试与黑盒测试相结合；系统测试是对软件系统（由若干软件项组成）进行测试，采用黑盒测试，其从测试内容角度又可分为功能测试、性能测试、并发测试、压力测试、接口测试、兼容性测试、用户界面测试、安装卸载测试等类型。

从测试实施方角度可分为内部测试、用户测试、第三方测试。其中，内部测试是指生产企业实施的测试，包括单元测试、集成测试、系统测试，白盒测试和黑盒测试相结合；用户测试是指用户在真实或模拟使用场景对软件系统进行测试，采用黑盒测试；第三方测试是指第三方机构对软件系统进行测试，采用黑盒测试。

回归测试是指用于确定软件更新没有产生不良影响且未引入不可接受新缺陷的软件测试。回归测试需根据软件更新的类型、内容和程度，开展与之相适宜的单元测试、集成测试、系统测试、用户测试、第三方测试等测试活动。

软件验证是指通过提供客观证据认定软件开发、软件维护某一阶段的输出满足输入要求。软件验证包括源代码审核、静态分析、动态分析、单元测试、集成测试、系统测试、评审等一系列活动，是软件确认的基础。

软件确认是指通过提供客观证据认定软件满足用户需求和预期用途。软件确认是基于过程控制的设计确认，包括用户测试、临床评价、评审等一系列活动，即要保证软件满足用户需求和预期用途，又要确保软件已知剩余缺陷的风险均可接受。

生产企业需结合软件的产品特点、风险程度考虑相应软件测试要求，以保证软件验证、软件确认的质量。

（五）软件可追溯性分析

软件可追溯性分析作为软件验证、软件确认的重要活动之一，是指追踪软件需求、软件设计、源代码、软件测试、软件风险管理之间的关系，分析已识别关系的正确性、一致性、完整性、准确性。

软件生存周期过程均应开展软件可追溯性分析，详见图2。
软件需求分析追溯分析软件需求与产品需求、软件需求与风险分析的关系。软件设计追溯分析软件设计与软件需求、软件设计与风险控制的关系。软件编码追溯分析源代码与软件设计、源代码与测试用例的关系。内部测试追溯分析单元测试、集成测试、系统测试各级测试用例与软件设计，系统测试与软件需求，系统测试与风险管理的关系。用户测试追溯分析用户测试与产品需求、用户测试与风险管理的关系。软件更新亦应开展软件可追溯性分析。

图2：软件可追溯性分析

生产企业需建立软件可追溯性分析过程，以规范软件可追溯性分析相关活动要求，以保证软件验证、软件确认的质量。

（六）软件更新

1. 基本概念

软件更新是指生产企业在软件生存周期全过程对软件所做的任一修改，亦称软件变更、软件维护。软件维护通常与软件更新含义相同，但可特指上市后软件更新。

软件更新从不同角度出发有不同分类方法。从更新结果角度可分为重大更新和轻微更新，重大更新是指影响到医疗器械安全性或有效性的软件更新，反之即为轻微更新。

从更新内容角度可分为增强类更新和纠正类更新（即软件缺陷修复）。增强类更新又可分为完善型更新和适应型更新，其中完善型更新是指改变功能、性能、接口等软件属性的软件更新，适应型更新是指适应新运行环境的软件更新。纠正类更新又可分为修正型更新和预防型更新，其中修正型更新是指修复软件存在且已造成运行故障缺陷的软件更新，预防型更新是指修复软件存在但尚未造成运行故障缺陷的软件更新。

本指导原则关注软件的安全性和有效性，故将软件更新（图3）分为：

（1）重大软件更新：影响到医疗器械安全性或有效性的增强类更新，即重大增强类软件更新，应申请许可事项变更。

（2）轻微软件更新：不影响医疗器械安全性与有效性的增强类更新、纠正类更新，包括轻微增强类软件更新、纠正类软件更新，通过质量管理体系进行控制，无需申请许可事项变更，待下次许可事项变更时提交相应注册申报资料。考虑到软件更新具有累积效应，注册申报资料应涵盖自前次注册以来的全部软件更新内容。

此外，软件构建（Build）即软件编译生成一个工作版本，符合软件更新定义，视为纠正类软件更新。召回相关软件更新包括软件更新导致召回、召回措施所用软件更新，均属于重大软件更新，按照医疗器械召回相关法规要求处理。

软件重新开发即生产企业弃用原有软件而开发新软件，不属于软件更新范畴，按初次发布处理。

软件更新遵循风险从高原则，即同时发生重大、轻微软件更新按重大软件更新处理，同时发生增强类、纠正类软件更新按增强类软件更新处理。

图3：医疗器械软件更新

2. 重大软件更新

软件更新若影响到医疗器械的预期用途、使用场景或核心功能原则上均属于重大软件更新，包括但不限于：

（1）完善型软件更新：影响到用户决策（含决策能力、决策结果、决策流程、用户行动）或人员（含患者、用户、其他相关人员）安全，如软件的输入输出、用户界面结构、核心算法、核心功能、工作流程或预期用途等发生改变，或符合新安全标准要求等；而运算速度单纯提高、工作流程可配置化、用户界面文字性修改等情况一般不视为重大软件更新，除非影响到医疗器械的安全性或有效性。

（2）适应型软件更新：软件运行平台跨越互不兼容的计算平台（含硬件、软件），如操作系统软件由Windows变为iOS，计算平台由通用计算平台变为医用计算平台等；系统软件、支持软件和中间件的补丁一般不视为重大软件更新，除非影响到医疗器械的安全性或有效性。

（3）混合型软件更新：软件的安全性级别、体系结构、用户界面关系或物理拓扑发生改变。

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

（七）软件版本

软件没有物理实体，只能通过状态标识进行软件更新管理，从而保证软件质量。软件版本使用不同字段来区分软件更新类型，进而标识软件状态，因此软件版本与软件是一一对应的表里关系，亦是软件标识不可或缺的组成部分。

从医疗器械唯一标识（UDI）角度，软件版本可分为软件发布版本和软件完整版本，前者属于产品标识（DI）组成部分，后者属于生产标识（PI）组成部分。具体而言，软件发布版本仅体现重大软件更新，即只限于重大增强类软件更新，其改变意味着发生重大软件更新，反之亦然；软件完整版本体现重大、轻微软件更新的全部类型，包括重大增强类软件更新、轻微增强类软件更新、纠正类软件更新、软件构建（若适用），其不同字段的改变意味发生不同类型的软件更新，反之亦然。

软件发布版本发生改变代表软件发生重大更新，应申请许可事项变更，软件完整版本发生改变但软件发布版本未变代表软件仅发生轻微更新，此时通过质量管理体系进行控制，无需申请许可事项变更。例如，软件版本命名规则为X.Y.Z.B，其中X表示重大增强类软件更新，Y表示轻微增强类软件更新，Z表示纠正类软件更新，B表示软件构建，则软件发布版本为X，软件完整版本为X.Y.Z.B，此时X改变应申请许可事项变更，而Y、Z、B改变但X未改变无需申请许可事项变更。

生产企业需综合考虑软件产品特点、质量管理体系要求、合规性等因素制定软件版本命名规则，涵盖软件更新全部类型，字段含义明确且无歧义无矛盾，能够区分重大软件更新和轻微软件更新（若不能区分遵循风险从高原则），保证软件更新的版本变更符合软件版本命名规则要求。

有用户界面的软件可在登录界面、主界面、“关于”或“帮助”等界面体现软件发布版本、软件完整版本。无用户界面的软件需提供获取软件版本信息的技术方法。

检测报告提供软件版本界面照片或列明软件版本信息，说明书注明软件发布版本。

对于进口医疗器械软件，生产企业应提供申报版本软件在原产国已获准上市的证明性文件，注明软件完整版本。

（八）软件算法、软件功能、软件用途

软件算法是软件功能的基础，二者是多对多的关系，即一个软件算法可供一个或多个软件功能使用，一个软件功能可含一个或多个软件算法。同理，软件功能和软件用途的关系亦是如此。

从用户角度出发，软件算法是内在不可见的，软件功能和软件用途是外在可见的，考虑到软件功能是软件算法、软件用途的联系纽带，故以软件功能作为软件安全有效性评价主线。例如，区域生长算法可实现图像分割功能，图像分割功能可用于病变轮廓标识。

软件功能从不同角度出发有不同分类方法。从重要性角度可分为核心功能和非核心功能，其中核心功能是指软件在预期使用场景完成预期用途所必需的功能，反之即为非核心功能。

从技术特征角度大体上可分为控制功能和处理功能，其中控制功能是指控制/驱动医疗器械硬件运行的功能，处理功能是指加工医疗器械数据的功能。处理功能从数据流角度又可分为前处理功能和后处理功能，前者是指采集人体解剖、生理信息生成医疗器械数据过程的处理功能，如滤波、降噪、校正、重建等功能；后者是指利用医疗器械数据生成诊疗信息过程的处理功能，如平移、缩放、旋转、滤波、测量、分割融合、三维可视化、计划制定等功能。后处理功能从复杂性角度又可分为简单功能和复杂功能，前者是指对现有医疗信息进行操作而非生成新医疗信息的功能，如平移、缩放、旋转等功能；后者是指生成新医疗信息的功能，如滤波、测量、分割融合、三维可视化、计划制定等功能。

独立软件的功能均为后处理功能，软件组件的功能以控制功能、前处理功能为主，兼具后处理功能。考虑到控制功能和前处理功能通常与医疗器械硬件共同评价，故处理功能若无明示均指后处理功能。

从监管范围角度可分为医疗器械功能和非医疗器械功能，其中医疗器械功能是指可用作医疗器械界定依据的软件功能，如医学图像、生理参数数据的测量、处理、分析等功能；反之即为非医疗器械功能，如收费计价、行政办公等功能；必要的患者信息管理功能属于医疗器械功能。二者尽量通过模块化设计予以拆分，若在技术上无法拆分需将非医疗器械功能作为医疗器械软件的组成部分予以整体考虑。

软件算法从重要性角度可分为核心算法和非核心算法，其中核心算法是指实现软件核心功能所必需的算法，反之即为非核心算法。从复杂性角度可分为简单算法和复杂算法，前者原理简单明确，后者通常基于模型研究，存在诸多假设条件且影响因素较多，同时二者在算法规模、参数数量、运算速度等方面亦存在差异。

软件用途通常可分为辅助决策和非辅助决策，其中辅助决策是指通过提供诊疗活动建议辅助医务人员进行临床决策，反之即为非辅助决策，包括流程优化、诊疗驱动。辅助决策相当于医务人员的“助手”，非辅助决策相当于医务人员的“工具”。故软件功能从软件用途角度又可分为辅助决策类功能和非辅助决策类功能。

软件算法、软件功能、软件用途从成熟度角度均可分为成熟和全新两种类型，其中成熟是指安全有效性已在使用实践中得到充分证实的情形，全新是指未上市或安全有效性尚未在使用实践中得到充分证实的情形。同理，软件亦可分为全新软件和成熟软件，软件的算法、功能、用途若有一项为全新类型则属于全新软件，反之属于成熟软件。因全新软件的风险高于成熟软件，故本指导原则以核心功能、核心算法为基础，重点关注全新软件的安全有效性。

三、基本原则

（一）基于软件特性

随着信息技术的迅猛发展，软件在医疗器械中的应用日益普遍，作用日趋重要，开发形式灵活多变，新技术层出不穷。但随之而来的质量问题也日益增多，医疗器械召回数据表明软件相关召回数量持续增加，明显高于同期医疗器械整体水平，同时软件失效导致患者死亡或严重伤害的召回事件也屡见不鲜，因此软件质量问题的严重性不容忽视。

软件没有物理实体，在开发和使用过程中人为因素影响无处不在，软件测试由于时间和成本的限制不能穷尽所有情况，所以软件缺陷无法避免。同时，软件更新频繁且迅速，轻微更新可能导致严重后果，并存在累积效应和退化问题（即每修复若干个缺陷就会产生一个新缺陷），所以软件缺陷无法根除。因此，软件缺陷可视为软件的固有属性之一，这也是软件质量问题较为突出的根源所在。

软件与硬件存在诸多差异：硬件是物理实体，软件是逻辑关系；硬件变更周期长，软件变更容易快速；硬件有磨损问题，软件虽无磨损但有退化问题；硬件质量取决于设计开发和生产，软件质量取决于设计开发，与生产基本无关；硬件失效先有征兆再发生，软件失效往往没有征兆突然发生，软件失效率远高于硬件；硬件部件可以标准化，软件模块的标准化较为复杂；轻微变更对硬件影响有限，但对软件影响可能严重；硬件检验可确保质量，软件测试不足以保证质量。这些差异使得传统硬件质量控制方法对于保证软件质量往往达不到预期效果。

鉴于软件特性，只有综合考虑风险管理、质量管理和软件工程的要求才能保证软件的安全有效性。生产企业应基于软件风险程度，采用良好软件工程实践完善质量管理体系，针对算法、接口、更新等软件召回主要原因，尽早、重点、全面开展软件质量保证工作。

（二）风险导向

综合考虑软件使用的普遍性、监管资源的有限性和风险分级管理导向，软件风险程度不同，其生存周期质控要求和注册申报资料要求亦不同。

软件风险程度采用软件安全性级别进行表述，软件安全性级别越高，生存周期质控要求越严格，注册申报资料也越详尽。软件安全性级别基于软件风险程度分为轻微、中等、严重，其中轻微级别（A级）即软件不可能产生伤害，中等级别（B级）即软件可能直接或间接产生轻微伤害，严重级别（C级）即软件可能直接或间接产生严重伤害或导致死亡。

软件安全性级别可结合软件的预期用途、使用场景、核心功能进行综合判定。其中预期用途主要考虑软件的用途类型（如诊断、治疗、监护、筛查）、重要程度（如重要作用、辅助作用、补充作用）、成熟程度（成熟、全新），使用场景主要考虑软件的使用场合（如医疗机构、家庭、转运、公共场所）、疾病特征（如严重性、紧迫性、传染性）、适用人群（如成人、儿童、老年、女性）、目标用户（如医生、护士、患者），核心功能主要考虑软件的功能类型（如重要程度、技术特征、复杂程度、成熟程度）、核心算法（如重要程度、复杂程度、成熟程度）、输入输出（输入数据如医学图像、生理参数数据、基因测序数据，输出结果如结构化报告、屏显结果）。

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

软件风险管理需要注意：软件本身不是危险源，但会引发危险情况；软件失效虽表现为随机性失效但实为系统性失效，即软件失效概率视为100%，由于软件失效所致伤害概率难以统计，故软件风险程度基于伤害严重度进行判定；软件组件应与所属医疗器械整体开展风险管理。

生产企业应结合质量管理体系要求，建立充分、适宜、有效的软件生存周期过程，并开展与软件安全性级别相匹配的软件质量保证工作。同时，基于软件安全性级别提交相应注册申报资料，注册申报资料均源自软件生存周期过程所形成的文档。

独立软件和软件组件虽然存在技术特征差异，但生存周期过程质控要求相同，故二者注册申报资料基本一致，具体内容略有差异，详见第八章。

（三）全生命周期管理

由于软件本身的复杂性和软件测试的局限性，软件开发过程的质量保证活动不足以保证软件的安全有效性，因此应在医疗器械全生命周期中考虑软件质控要求，并将软件风险管理、软件配置管理、软件缺陷管理、软件可追溯分析贯穿于全程。

上市前应开展充分有效的软件验证与确认活动，识别软件可预见的风险并将其降至可接受水平。上市后结合用户投诉、不良事件和召回等情况，识别前期未预见的风险采取必要措施保证软件质量，同时基于软件更新需求的评估，实施软件更新活动以满足用户新需求，并开展与之相适宜的软件验证与确认活动，以保证软件更新质量。

四、现成软件

（一）基本概念

现成软件是指生产企业未进行完整生存周期控制的软件，包括遗留软件、成品软件、外包软件。其中，遗留软件是指生产企业以前开发但现在不能得到足够开发记录的软件，涉及医用应用软件、医用中间件。成品软件是指已开发且通常可得到的，但生产企业未进行完整生存周期控制的软件，涉及系统软件、应用软件、中间件、支持软件，如开源/闭源软件、免费/付费软件等。外包软件是指生产企业委托第三方开发的软件，涉及医用应用软件、医用中间件。

现成软件与医疗器械软件的关系可分为两类。一类是现成软件作为医疗器械软件的组成部分，即现成软件组件，包括遗留软件、成品软件、外包软件，涉及应用软件、中间件、支持软件；无论是否设计用于医疗用途，现成软件组件作为医疗器械软件的组成部分，其功能均属于医疗器械功能。另一类是现成软件作为医疗器械软件运行环境的组成部分，即外部软件环境，均为成品软件，涉及系统软件、通用应用软件、通用中间件、支持软件，其功能均属于非医疗器械功能。综上，现成软件类型详见图4。

图4：现成软件类型

医疗器械软件除部分嵌入式软件外，均需外部软件环境的支持方能运行。同时，医疗器械软件既可自研软件和现成软件组件相结合，部分使用现成软件组件，即部分使用方式；又可全部使用现成软件组件，即全部使用方式。因此，现成软件具有普遍性、灵活性、复杂性等特点。

由于现成软件，特别是外部软件环境，通常并非设计用于医疗用途，未必能够满足医疗器械相关要求，未用功能可能通过耦合关系对医疗器械软件产生不利影响，而且生产企业未对现成软件进行完整生存周期控制，因此使用现成软件的风险相对较高，特别是现成软件组件。

生产企业使用现成软件应保证医疗器械软件的安全有效性，而现成软件开发商作为供应商并不承担生产企业相关责任。因此，生产企业应结合现成软件的类型、特点以及业界使用情况，区分现成软件组件和外部软件环境，综合考虑现成软件的使用广泛度、技术成熟度、售后支持程度以及功能、性能、兼容性、易用性、可靠性、维护性、可移植性、网络安全等方面要求，采用基于风险的全生命周期管理方法进行质控，特别是在采购、设计开发、上市后监测等方面。

由于自研软件与现成软件、现成软件组件与外部软件环境、部分使用方式与全部使用方式的质控要求均存在差异，故相应注册申报资料均有所不同，具体要求详见第八章。此外，医疗器械软件可同时使用多个版本、多个、多种的现成软件，需进行整体考量并提供相应注册申报资料。

（二）通用考量

1. 现成软件组件

现成软件组件的软件更新、软件版本相关要求与自研软件基本相同，同样遵循风险从高原则。

现成软件组件若发生重大软件更新亦需申请许可事项变更，若发生轻微软件更新通过质量管理体系进行控制，无需申请许可事项变更。

现成软件组件的版本命名规则亦需考虑合规性要求。若现成软件组件供应商的软件版本命名规则满足合规性要求，生产企业可直接采用。

2. 外部软件环境

医疗器械软件与外部软件环境存在耦合关系，需进行整体考量。

从医疗器械软件角度，软件安全性级别判定需考虑外部软件环境失效的影响，软件需求规范（SRS）文档、软件测试计划与报告均需列明外部软件环境所含各现成软件的名称、完整版本、补丁版本。软件测试需基于外部软件环境所含全部现成软件予以实施，若同一现成软件有多个版本，则每个版本均需纳入软件测试。医疗器械软件必要时应具备外部软件环境自检功能，以确保自身能够正常运行。说明书必要时应明确外部软件环境所含全部现成软件的交付、安装、设置、配置、更新等要求，以及使用限制、警示提示等说明。

从外部软件环境角度，自身风险相对较低，由于与医疗器械软件相互耦合，故其安全性级别与医疗器械软件的安全性级别相同，注册申报资料详尽程度亦取决于安全性级别。

外部软件环境更新对于医疗器械软件而言属于适应型更新，包括补丁更新、版本更新、产品更新（即更换外部软件环境所含现成软件）等情况。外部软件环境更新情况不同，对于医疗器械软件的影响亦不同，通常补丁更新、与医疗器械软件兼容的版本更新属于轻微软件更新，而产品更新、与医疗器械软件不兼容的版本更新属于重大软件更新，同样遵循风险从高原则。因此，生产企业应建立相应流程开展外部软件环境更新的影响评估工作。

五、质量管理软件

（一）基本概念

质量管理软件是指医疗器械质量管理所用的应用软件，不是医疗器械软件，无需申报注册。质量管理软件亦需外部软件环境（含系统软件、通用应用软件、通用中间件、支持软件）的支持方能正常运行。

质量管理软件参照医疗器械软件可分为类独立软件和类软件组件，前者包括设计开发所用软件、流程管理所用软件等软件，后者包括生产设备所含软件、检验设备所含软件等软件。

质量管理软件多数通过采购获得，特别是类软件组件，可视为成品软件，且采用全部使用方式；少数自行研发，主要是类独立软件，可视为自研软件。因此，质量管理软件确认可参照全部使用成品软件、自研软件的确认要求。

（二）软件确认考量

质量管理软件确认以软件功能为基础，综合考虑需求分析、验收测试、维护计划等要求。其中，需求分析考虑软件的功能、性能、接口等方面要求，评估候选软件以确定目标对象。验收测试基于外部软件环境予以实施，确保软件能够满足使用需求，而且软件已知剩余缺陷、未用软件功能对于医疗器械软件质量的影响均可接受。维护计划考虑软件更新相关要求，特别是纠正类软件更新（即软件缺陷修复）的维护方案。

质量管理软件外部软件环境的评估要求可参照自研软件相应要求。

质量管理软件更新应重新进行软件确认，其外部软件环境更新亦需开展影响评估工作。

六、软件生存周期过程

软件生存周期过程主要包括软件开发过程、软件维护过程、软件风险管理过程、软件配置管理过程、软件缺陷管理过程等过程。

软件开发过程包括软件开发策划、软件需求分析、软件设计、软件编码、软件验证、软件确认、软件发布等活动。

软件维护过程适用于上市后增强类软件更新，包括软件更新需求评估、软件更新策划、软件更新实施、软件验证、软件确认、软件发布、用户告知等活动。

软件风险管理过程包括风险分析、风险评价、风险控制、综合剩余风险评价等活动，基于医疗器械风险管理过程予以实施，可采用医疗器械常用风险管理方法。

软件配置管理过程包括配置项识别、更改控制、配置状态记录等活动，基于软件版本命名规则进行软件版本控制，可使用配置管理工具或常用办公软件予以实施。软件版本命名规则应涵盖软件、现成软件、网络安全的全部软件更新类型，各字段含义明确且无歧义无矛盾。

软件缺陷管理过程适用于上市前和上市后纠正类软件更新，包括软件缺陷评估、软件缺陷修复、回归测试等活动，可使用缺陷管理工具或常用办公软件予以实施。

软件开发过程、软件维护过程是前后关系，软件风险管理过程、软件配置管理过程、软件缺陷管理过程贯穿于软件开发过程、软件维护过程。

同时，软件可追溯性分析也是软件生存周期过程重要过程之一，同样贯穿于软件开发过程、软件维护过程，可使用可追溯性分析工具或常用办公软件予以实施。

此外，软件生存周期过程亦需考虑现成软件、网络安全相关要求。现成软件考虑采购控制、设计开发控制等要求，使用外包软件需与供应商签订质量协议，使用遗留软件需评估现有文件、上市后使用问题（含不良事件、召回）等情况，使用开源软件需遵循相应开源许可协议。网络安全设计开发应与软件设计开发相融合，并考虑网络安全事件应急响应要求。

软件生存周期过程质量保证活动要求应与软件安全性级别相匹配，软件风险程度越高，其质控要求越严格。

敏捷开发还需明确文件与记录控制要求。

软件生存周期过程（包括现成软件、网络安全）具体要求详见《医疗器械生产质量管理规范附录独立软件》。

七、技术考量

（一）注册单元与检测单元

1. 注册单元划分原则

（1）独立软件

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

不同管理类别的独立软件作为不同注册单元，若在技术上无法拆分可作为一个注册单元并按照较高管理类别申报注册。

不同预期用途的独立软件作为不同注册单元，按照预期用途可分为辅助决策类和非辅助决策类，每类又可细分为治疗计划、诊断、监护、临床管理、个人管理等情形。预期用途相同但核心算法类型不同的独立软件亦作为不同注册单元，如常规图像处理算法和人工智能算法。

对于功能庞大复杂的独立软件，依据功能模块的类型和数量划分注册单元，每个注册单元所含功能模块数量需适中。按照功能模块类型可分为平台功能软件和特定功能软件，其中平台功能软件作为软件平台提供基本功能和共用功能，支持多模态数据（如医学图像、生理参数数据、基因测序数据）；特定功能软件运行于平台功能软件并提供特定功能，支持单模态数据，或者使用多模态数据实现某一特定预期用途。

例如，某PACS包含数十个单独的功能模块，并含有辅助决策类功能模块，应拆分为一个平台功能软件和多个特定功能软件，其中辅助决策类功能模块单独作为一个注册单元。

（2）软件组件

软件组件注册单元与所属医疗器械相同。专用型独立软件视为软件组件的注册单元与软件组件相同。

2. 检测单元划分原则

检测单元是指同一注册单元内用于检测的代表产品。

（1）独立软件

独立软件检测单元原则上与注册单元相同，但若有多个运行环境或多个发布版本，则每个互不兼容的运行环境或每个互不涵盖的发布版本均应作为一个检测单元。

（2）软件组件

软件组件检测单元原则上与所属医疗器械相同，但医疗器械若包含多个软件组件或多个发布版本的软件组件，则每个软件组件或每个发布版本的软件组件均应作为一个检测单元，除非检测单元能够完整覆盖注册单元全部情况。

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

（二）临床评价基本原则

1. 独立软件

独立软件以软件功能为基础进行临床评价，可选择已上市医疗器械所含同类软件功能进行比对。

非辅助决策类软件功能基于核心功能进行同品种医疗器械比对。全新的核心算法、核心功能、预期用途原则上均应开展临床评价，简单操作类软件功能、单纯流程优化类软件功能可通过非临床证据予以评价。

辅助决策类软件功能基于核心算法进行同品种医疗器械比对，比对所选产品的临床证据需基于临床试验。全新的核心算法、核心功能、预期用途原则上均应开展临床试验，临床试验可与预期用途相同且核心算法或核心功能等同的独立软件进行对照。

2. 软件组件

软件组件控制功能、前处理功能的临床评价通常与所属医疗器械进行整体评价。后处理功能临床评价可参照独立软件要求，亦可随所属医疗器械进行整体评价。

专用型独立软件视为软件组件的临床评价与软件组件后处理功能要求相同。

（三）网络安全

医疗器械网络安全需从信息安全角度综合考虑医疗器械的网络安全和数据安全。医疗器械软件若具备电子数据交换、远程控制或用户访问控制功能，均应考虑网络安全问题，具体要求详见医疗器械网络安全相关指导原则，包括网络安全更新、软件版本命名规则、网络安全研究资料等要求。

（四）云计算[1]

云计算在医疗器械行业的应用日益增多，虽然其具有降低信息化成本、减少重复建设、提高资源利用率、增加业务灵活性、提升服务专业性等优势，但是也存在着用户对数据控制能力减弱、服务可持续性降低、数据所有权面临挑战、数据保护困难、数据残留难以处理、用户与云服务商责任不清、产生司法管辖权问题、面临网络安全威胁等风险，因此生产企业需权衡使用云计算的收益和风险。

云计算可视为现成软件，云服务商即供应商，因此生产企业可参照现成软件和供应商相关要求，考虑云计算的需求分析、风险管理、验证与确认、维护计划等活动要求。

需求分析需考虑云计算的技术特征、云服务商的选择问题。云计算技术特征包括服务模式、部署模式、配置情况、核心功能、数据接口、网络安全保证等方面，其中服务模式分为软件即服务（SaaS）、平台即服务（PaaS）、基础设施即服务（IaaS），部署模式分为私有云、公有云、混合云，配置情况包括计算资源、配套软件功能等要求，核心功能包括数据存储、数据处理、数据分析等功能，数据接口考虑传输协议、存储格式等要求，网络安全保证考虑数据匿名、数据加密、数据传输校验、安全配置等技术措施。同时，基于云计算服务资质、云计算服务协议等因素考虑云服务商选择问题，云计算服务协议需明确网络安全保证、患者数据与隐私保护等责任承担要求。

风险管理基于云计算的核心功能、数据接口、网络安全保证予以实施。验证与确认应基于云计算环境开展医疗器械软件的验证与确认，确保云计算满足使用要求，且已知剩余缺陷的风险均可接受。维护计划考虑云计算更新的维护方案，重新进行医疗器械软件的验证与确认，明确云计算服务终止的无损数据迁移方案。

若使用云计算，生产企业应在自研软件研究报告、外部软件环境评估报告相关条款中予以体现，具体要求详见第八章。若自建云计算平台，生产企业应遵循云服务商相关规定，参照自研软件要求提交相应研究资料。

（五）移动计算

医疗器械软件若运行于供个人使用的移动计算终端，包括医用计算终端、通用计算终端，则属于移动医疗器械，应综合考虑移动计算终端的技术特征及其风险，具体要求详见移动医疗器械相关指导原则。

（六）人工智能/机器学习

医疗器械软件若使用人工智能（AI）/机器学习（ML）算法，则属于人工智能医疗器械，应综合考虑人工智能/机器学习算法的技术特征及其风险，具体要求详见人工智能医疗器械相关指导原则。

（七）人因设计

医疗器械软件应加强用户界面人因设计，将用户错误使用的风险降至可接受水平，软件用户界面的人因设计要求和基本要素详见医疗器械人因设计相关指导原则。

（八）互操作性

互操作性（又称互用性）是指医疗器械与其他医疗器械或非医疗器械通过电子接口交换并使用信息的能力。其中电子接口包含硬件接口和软件接口，信息包括但不限于医学图像、生理参数数据、基因测序数据、控制指令。

互操作性重点关注医疗器械软件的接口设计及其风险，接口包括内部接口和外部接口，前者是指软件模块之间的接口，后者是指供用户调用的接口，从用户角度出发软件接口若无明示均指外部接口。因此，生产企业应考虑软件接口的需求分析、风险管理、验证与确认、维护计划等活动要求，以及说明书与标签的设计要求。

需求分析基于软件接口的预期用户（如医务人员、患者、软件维护人员）、使用场景、预期用途明确其技术特征、使用限制。其中，软件接口包括供用户调用的应用程序接口（API）、数据接口（含传输协议、存储格式，如DICOM、HL7、私有协议、JPG、PNG）、产品接口（可联合使用的其他独立软件、医疗器械硬件）。技术特征包括但不限于连接对象、信息内容、通信协议、性能指标、网络安全保证等要求。使用限制需考虑每个软件接口的预期用户范围、连接要求。

风险管理基于软件接口的预期用户、使用场景、预期用途及技术特征、使用限制予以实施。验证与确认应保证软件接口满足设计要求，且已知剩余缺陷的风险均可接受。维护计划考虑软件接口的更新要求，重新进行软件的验证与确认。

说明书逐项说明每个软件接口的预期用户、使用场景、预期用途、技术特征、使用限制。标签明确关键软件接口的技术特征、使用限制。

生产企业应在自研软件研究报告相关条款中体现软件接口要求，具体要求详见第八章。

（九）测量功能

测量功能（又称量化、定量功能）可分为图形学测量功能、客观测量功能，前者基于图形学间接反映客观事物的测量结果，后者直接反映客观事物的测量结果。

无论何种测量功能均需结合测量的误差、不确定度等因素，明确测量准确性指标，如线性度、精度、重复性、再现性、范围限值等。测量准确性指标应在产品技术要求中予以明确，并在说明书中告知用户。此外，客观测量功能需提供测量准确性的研究资料，图形学测量还需在说明书中提供警示信息。

（十）非医疗器械功能

医疗器械软件若在技术上能够拆分非医疗器械功能，即非医疗器械功能采用模块化设计，则功能模块不应包含非医疗器械功能模块，说明书若含有非医疗器械功能模块应删除相应内容或予以注明。

医疗器械软件若在技术上无法拆分非医疗器械功能，需将非医疗器械功能作为自身组成部分予以整体考虑，重点关注非医疗器械功能对于医疗器械软件的影响及其风险。生产企业应在医疗器械软件整体框架下考虑非医疗器械功能的软件生存周期过程质控要求，通常可按轻微软件安全性级别要求予以处理。医疗器械软件的研究资料应涵盖非医疗器械功能，产品技术要求性能指标所述“功能”条款简述非医疗器械功能即可。

（十一）产品设计软件

有些医疗器械本身不含有医疗器械软件，但其安全有效性显著受限于产品设计软件的输出结果，如可编程逻辑控件编程软件、有源植入物集成电路（IC）设计软件、个性化假体（如骨科、齿科增材制造产品）设计软件等。因此，此类产品设计软件亦需提交软件研究资料，可参照全部使用成品软件或自研软件相关要求，具体要求详见第八章。

（十二）使用期限

独立软件的使用期限通过商业因素予以确定。软件组件的使用期限与所属医疗器械相同，无需单独体现。专用型独立软件视为软件组件的使用期限要求与独立软件相同，在所属医疗器械使用期限研究资料中体现。

八、软件研究资料

软件研究资料框架详见图5，具体要求如下。

图5：软件研究资料框架

（一）自研软件研究报告

自研软件研究报告适用于自研软件的初次发布和再次发布，内容包括基本信息、实现过程、核心功能、结论，详尽程度取决于软件安全性级别，附件均应注明软件版本，详见表1。

1. 基本信息

（1）软件标识

明确软件的名称、型号规格、发布版本、生产企业、生产地址。

（2）安全性级别

明确软件的安全性级别，详述判定理由。

（3）结构功能

基于软件设计规范（SDS）文档提供软件的体系结构图（区分医疗器械软件和外部软件环境）、用户界面关系图与主界面图示（若适用）。

依据体系结构图详述软件组成模块的功能、用途、接口以及必备软件、云计算等情况，并注明各组成模块的安全性级别。依据用户界面关系图详述软件功能模块的功能、用途，依据主界面图示详述主界面的布局、选项、功能。

若适用，组成模块和功能模块均需注明选装、模块版本。接口包括供用户调用的应用程序接口（API）、数据接口、产品接口，逐项说明各接口的预期用户、使用场景、预期用途、技术特征、使用限制。

（4）物理拓扑

基于软件设计规范（SDS）文档提供软件的物理拓扑图（涵盖全部外围设备），依据物理拓扑图详述软件/组成模块、必备软件、云计算、通用计算平台、医疗器械硬件/部件之间的物理连接关系。

（5）运行环境

明确软件正常运行所需的硬件配置、外部软件环境、网络条件。其中，硬件配置包括处理器、存储器、外设器件等要求，明确最低配置和/或典型配置；外部软件环境包括系统软件、通用应用软件、通用中间件、支持软件，注明全部软件的名称、完整版本、补丁版本，使用“兼容版本”而非“以上版本”、“更高版本”；网络条件包括网络架构（如BS架构、CS架构、混合架构）、网络类型（如广域网、局域网、个域网）、网络带宽等要求。

若使用云计算，明确云计算的名称、服务模式、部署模式、配置以及云服务商的名称、资质。

（6）注册历史

明确软件在中国、原产国的注册情况，列明历次注册的日期、发布版本、管理类别。软件组件明确所属医疗器械的注册情况。亦可提供软件在其他主要国家和地区的注册情况。

2. 实现过程

（1）开发概况

概述软件所用开发方法（如面向过程、面向对象、敏捷开发等）、编程语言、开发测试环境（含软硬件设备、开发测试工具、网络条件、云计算），明确开发测试工具的名称、完整版本、供应商，明确开发测试的人员总数、时长、工作量（人月数）、代码行总数。

（2）风险管理

提供软件风险管理流程图，依据流程图详述软件风险管理过程相关活动。

提供软件的风险分析报告、风险管理报告，涵盖功能、性能、接口、运行环境、云计算等方面情况，另附原文。软件组件提供所属医疗器械的风险管理文档。

（3）需求规范

提供软件需求规范（SRS）文档，明确软件的功能、性能、接口、运行环境、云计算等方面需求，另附原文。软件组件若无单独文档，可提供所属医疗器械的需求规范文档。

（4）生存周期

轻微级别：概述软件开发过程、软件维护过程、软件配置管理过程相关活动。

中等级别：提供软件开发、软件维护、软件配置管理流程图，依据流程图详述软件开发过程、软件维护过程、软件配置管理过程相关活动。

严重级别：提供软件开发、软件维护、软件配置管理流程图，依据流程图详述软件开发过程、软件维护过程、软件配置管理过程相关活动。提供软件设计历史文档集（DHF）索引表，另附软件编码规则文档。

使用敏捷开发还需提供文件与记录控制文档，亦可提供软件生存周期过程控制程序文档或软件生存周期过程标准核查表，用于替代相应描述。

（5）验证与确认

轻微级别：提供系统测试、用户测试的计划与报告。

中等级别：概述软件开发过程质量保证活动；提供系统测试、用户测试的计划与报告。

严重级别：提供软件开发质量保证流程图，依据流程图详述软件开发过程质量保证活动；提供集成测试、系统测试、用户测试的计划与报告。

测试计划和报告涵盖软件的功能、性能、接口、运行环境、云计算等方面情况，另附原文。测试报告所含测试记录若数量较多可提供测试记录目录清单、典型核心功能测试记录样例。亦可提供软件开发质量保证计划文档，用于替代相应描述。

（6）可追溯性分析

提供软件可追溯性分析流程图，依据流程图详述软件可追溯性分析过程相关活动。

提供软件可追溯性分析报告，追溯分析软件需求规范（SRS）文档、软件设计规范（SDS）文档、软件测试报告、软件风险分析报告的关系，另附原文。

（7）缺陷管理

轻微级别：概述软件缺陷管理过程，明确软件已知缺陷总数和剩余缺陷数。

中等、严重级别：提供软件缺陷管理流程图，依据流程图详述软件缺陷管理过程相关活动；明确软件已知缺陷总数和剩余缺陷数，列明软件已知剩余缺陷的内容、影响、风险，确保风险均可接受。软件已知剩余缺陷情况可另附原文。

（8）更新历史

轻微级别：提供软件版本命名规则，举例说明完整版本各字段含义，明确软件发布版本、软件完整版本；列明自前次注册以来历次软件更新的完整版本、日期、类型。

中等级别：提供软件版本命名规则，举例说明完整版本各字段含义，明确软件发布版本、软件完整版本；列明自前次注册以来历次软件更新的完整版本、日期、类型、具体内容。

严重级别：提供软件版本命名规则，举例说明完整版本各字段含义，明确软件发布版本、软件完整版本；列明自首次注册以来历次软件更新的完整版本、日期、类型、具体内容。

软件功能模块若单独进行版本控制，其版本命名规则亦需提供。软件更新类型注明重大更新或轻微更新。初次发布列明软件开发阶段历次软件更新情况。软件更新历史可另付原文。

3. 核心功能

轻微级别：基于说明书列明软件核心功能的名称、所用核心算法、预期用途，全新的核心功能、核心算法、预期用途需注明。

中等、严重级别：基于说明书列明软件核心功能的名称、所用核心算法、预期用途，全新的核心功能、核心算法、预期用途需注明，并提供相应安全有效性研究资料，其中客观测量功能提供测量准确性的研究资料。

4. 结论

概述软件实现过程的规范性和核心功能的正确性，判定软件的安全有效性是否满足要求。

（二）自研软件更新研究报告

自研软件更新研究报告适用于自研软件的再次发布，包括完善型更新研究报告、适应型更新研究报告、纠正类更新研究报告。

自研软件完善型更新研究报告适用于自研软件重大、轻微完善型更新，或合并适应型更新、纠正类更新，内容详见表2，不再赘述。

适应型更新研究报告适用于重大、轻微适应型更新，或合并纠正类更新，但不含完善型更新，内容包括软件标识、安全性级别、运行环境、风险管理、需求规范、生存周期、验证与确认、可追溯性分析、缺陷管理、更新历史、结论，具体要求详见表2相应说明。

纠正类更新研究报告仅适用于纠正类更新，内容包括软件标识、安全性级别、风险管理、验证与确认、可追溯性分析、缺陷管理、更新历史、结论，具体要求详见表2相应说明。

表1：自研软件研究报告框架

表2：自研软件完善型更新研究报告框架

（三）现成软件研究资料

1．现成软件组件研究资料

（1）部分使用方式

对于部分使用方式，遗留软件、成品软件、外包软件的研究资料要求相同，无需单独提交研究报告，基于医疗器械软件的安全性级别，在自研软件研究报告适用条款中说明现成软件的情况。

适用条款包括软件标识、安全性级别、结构功能、运行环境、风险管理、需求规范、生存周期、验证与确认、可追溯性分析、缺陷管理、更新历史、核心功能、结论，其余条款若适用亦可说明。

此时若现成软件发生软件更新，完善型更新研究报告在自研软件完善型更新研究报告基础上，说明现成软件的变化情况，不适用条款说明理由；适应型更新、纠正类更新研究报告要求与自研软件相同。

（2）全部使用方式

对于全部使用方式，遗留软件、成品软件、外包软件的研究资料要求略有差异，单独提交现成软件组件研究报告和支持证据。

现成软件组件研究报告条款与自研软件研究报告相同，但需基于现成软件（此时即医疗器械软件）的安全性级别予以说明，适用条款至少包括软件标识、安全性级别、运行环境、风险管理、需求规范、验证与确认、缺陷管理、核心功能、结论，不适用条款说明理由。

支持证据用于证明现成软件类型。遗留软件提供YY/T 0664或IEC 62304实施之前的上市证明文件，以及上市后使用情况评价报告。成品软件提供外购合同等证明文件，若已在中国上市提供相应注册信息。外包软件提供外包合同等证明文件。

此时若现成软件发生软件更新，完善型更新研究报告在现成软件组件研究报告基础上，说明现成软件的变化情况，不适用条款说明理由；适应型更新、纠正类更新研究报告要求与自研软件相同。

2．外部软件环境评估报告

外部软件环境评估报告用于医疗器械软件外部软件环境（含云计算）的评估，适用于医疗器械软件的初次发布和再次发布，内容包括安全性级别、软件标识、功能用途、运行环境、风险管理、验收管理、维护计划、结论，详尽程度取决于软件安全性级别，详见表3。

（1）安全性级别

依据医疗器械软件安全性级别，明确外部软件环境的安全性级别。

（2）软件标识

按照系统软件、应用软件、中间件、支持软件四种类型，分类描述外部软件环境所含全部现成软件的名称、完整版本、补丁版本、发布日期、供应商。

（3）功能用途

按照系统软件、应用软件、中间件、支持软件四种类型，分类描述外部软件环境所含全部现成软件的功能、用途、与医疗器械软件的关系、使用限制、选择依据。

（4）运行环境

按照系统软件、应用软件、中间件、支持软件四种类型，分类描述外部软件环境所含全部现成软件的运行环境，结合兼容性考虑医疗器械软件运行环境的确定依据。

（5）风险管理

提供外部软件环境所含全部现成软件的风险分析报告，另附原文。

（6）验收管理

轻微级别：概述外部软件环境验收管理过程相关活动。

中等级别：依据流程图详述外部软件环境验收管理过程相关活动。

严重级别：依据流程图详述外部软件环境验收管理过程相关活动，提供外部软件环境兼容性测试计划和报告，另附原文。

（7）维护计划

轻微级别：概述外部软件环境更新管理过程相关活动，包括补丁更新、版本更新、产品更新。

中等级别：依据流程图详述外部软件环境更新管理过程相关活动，包括补丁更新、版本更新、产品更新。

严重级别：依据流程图详述外部软件环境更新管理过程相关活动，包括补丁更新、版本更新、产品更新；提供现成软件停运后续维护方案，即现成软件供应商停止售后服务后，生产企业对于现成软件的维护方案，如云计算服务终止的无损数据迁移方案。

（8）结论

判定外部软件环境所含全部现成软件的质量是否满足要求。

表3：外部软件环境评估报告框架

外部软件环境发生更新亦需依据安全性级别开展相应评估工作，并更新医疗器械软件的外部软件环境评估报告，以备后续体系核查或许可事项变更使用。

九、注册申报资料说明

（一）产品注册

1. 注册证载明信息

（1）独立软件

产品名称应符合独立软件通用名称命名规范要求，通常体现输入数据、核心功能、预期用途等特征词。

型号规格包含软件发布版本。

结构组成明确交付内容和功能模块，其中交付内容包括软件安装程序、授权文件、外部软件环境安装程序等软件程序文件，功能模块包括客户端和服务器端（若适用），注明选装、模块版本。

适用范围通常基于预期用途、使用场景、核心功能予以规范，分述各功能模块的适用范围（若适用）。同时保证用语的规范性，如区分“分析”与“测量”、“手术模拟”与“手术计划”，使用“显示”、“三维可视化”而非“浏览”、“三维重建”。

（2）软件组件

软件组件通常无需在注册证载明信息中体现。保证结构组成的用语规范性，使用“主机”、“工作站”而非“电脑”、“计算机”。若有辅助决策类软件功能，应在适用范围中予以体现。

对于专用型独立软件视为软件组件的情形，软件名称与独立软件要求相同，结构组成明确软件的名称、型号规格、发布版本。

2. 软件研究资料

生产企业应提交自研软件研究报告、外部软件环境评估报告，若使用现成软件组件，根据其使用方式提交相应研究资料。相关研究资料的具体要求详见第八章。

考虑到进口医疗器械软件不一定在中国同步注册，即该软件在境外已多次注册变更但在中国为首次注册，此时软件研究资料应涵盖申报版本软件的全部内容。

3. 产品技术要求

（1）独立软件

产品技术要求 “产品型号/规格及其划分说明”明确软件的名称、型号规格、发布版本、版本命名规则，功能模块若有单独的版本、版本命名规则均需说明。

“性能指标”包括通用要求、质量要求、专用要求、安全要求，其中通用要求根据软件产品特性进行规范，不适用内容在研究资料中予以说明；质量要求符合GB/T 25000.51要求，专用要求符合相关产品标准（如放射治疗计划软件）要求，安全要求符合相关安全标准（如报警、放射治疗）要求。

“附录”提供体系结构图、用户界面关系图与主界面图示、物理拓扑图以及必要注释。

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

（2）软件组件

软件组件应在所属医疗器械产品技术要求中进行规范，其中“产品型号/规格及其划分说明”明确软件的名称、型号规格、发布版本、版本命名规则，功能模块若有单独的版本、版本命名规则均需说明。

“性能指标”包括软件的功能、接口、访问控制、运行环境（若适用）、性能效率（若适用）、软件质量等要求。其中，功能明确软件的全部核心功能（含安全功能）纲要，注明选装、自动功能，其中测量功能明确测量准确性指标，数据资源（如参考数据库）明确数据种类和每类数据的样本量；接口包括供用户调用的应用程序接口（API）、数据接口、产品接口；访问控制明确软件的用户身份鉴别方法、用户类型及用户访问权限；运行环境、性能效率适用于外控型软件组件、专用型独立软件视为软件组件，运行环境（含云计算）包括硬件配置、外部软件环境、网络条件，性能效率明确软件在相应运行环境下完成典型核心功能的时间特性，若适用还需明确资源利用性、容量；上述条款不适用内容在研究资料中予以说明。软件质量符合GB/T 25000.51要求。

对于专用型独立软件视为软件组件，“附录”亦需提供体系结构图、用户界面关系图与主界面图示、物理拓扑图以及必要注释。

4. 说明书

说明书应符合相关法规、规范性文件、国家标准、行业标准要求，体现软件的功能、接口、访问控制、运行环境（若适用）、性能效率（若适用）等信息，明确软件发布版本。

其中，软件功能包括全部核心功能（含安全功能），注明选装、自动功能，其中测量功能明确测量准确性指标，图形学测量功能还需提供警示信息，数据资源明确数据种类和每类数据的样本量。接口逐项说明每个供用户调用软件接口的预期用户、使用场景、预期用途、技术特征、使用限制。运行环境（含云计算）、性能效率适用于独立软件、外控型软件组件、专用型独立软件视为软件组件。

（二）许可事项变更

1. 软件研究资料

医疗器械许可事项变更应根据软件更新情况，提交软件变化部分对产品安全性与有效性影响的研究资料：

（1）涉及完善型软件更新：适用于软件发生完善型更新或合并适应型更新、纠正类更新的情形，此时提交自研软件完善型更新研究报告（或自研软件研究报告）、外部软件环境评估报告；

（2）涉及适应型软件更新：适用于软件发生适应型更新或合并纠正类更新，但未发生完善型更新的情形，此时提交自研软件适应型更新研究报告，或自研软件研究报告；

（3）仅发生纠正类软件更新：提交自研软件纠正类更新研究报告；

（4）未发生软件更新：出具真实性声明。

若使用现成软件组件，根据其使用方式提交相应研究资料。相关研究资料的具体要求详见第八章。

2. 产品技术要求

（1）独立软件

产品技术要求体现软件更新情况，包括“产品型号/规格及其划分说明”、“性能指标”、“附录”。

（2）软件组件

软件组件所属医疗器械产品技术要求体现软件组件更新情况，包括“产品型号/规格及其划分说明”的软件信息、“性能指标”的软件要求。

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

3. 说明书

说明书体现软件的功能、接口、访问控制、运行环境（若适用）、性能效率（若适用）等信息，明确软件发布版本。若适用提供变化情况说明。

（三）延续注册

延续注册无需提交软件相关研究资料。

产品技术要求“产品型号/规格及其划分说明”明确软件的名称、型号规格、发布版本、版本命名规则，若原注册产品标准及其变更对比表未体现软件相关信息，应在产品未变化声明中予以明确。

十、参考文献

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

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

[3]《医疗器械分类规则》（国家食品药品监督管理总局令第15号）

[4]《医疗器械召回管理办法》（国家食品药品监督管理总局令第29号）

[5]《医疗器械不良事件监测和再评价管理办法》（国家市场监督管理总局令第1号）

[6]《医疗器械注册申报资料要求和批准证明文件格式》（征求意见稿）

[7]《医疗器械生产质量管理规范》（国家食品药品监督管理总局公告2014年第64号）

[8]《医疗器械产品技术要求编写指导原则》（国家食品药品监督管理总局通告2014年第9号）

[9]《医疗器械临床评价技术指导原则》（征求意见稿）

[10]《医疗器械软件注册技术审查指导原则》（国家食品药品监管总局通告2015年第50号）

[11]《医学图像存储传输软件（PACS）注册技术审查指导原则》（国家食品药品监督管理总局通告2016年第27号）

[12]《医疗器械网络安全注册技术审查指导原则》（国家食品药品监督管理总局通告2017年第13号）

[13]《医疗器械注册单元划分指导原则》（国家食品药品监督管理总局通告2017年第187号）

[14]《中央监护软件注册技术审查指导原则》（国家食品药品监督管理总局通告2017年第198号）

[15]《移动医疗器械注册技术审查指导原则》（国家食品药品监督管理总局通告2017年第222号）

[16]《有源医疗器械使用期限注册技术审查指导原则》（国家药品监督管理局通告2019年第23号）

[17]《医疗器械生产质量管理规范附录独立软件》（国家药品监督管理局通告2019年第43号）

[18]《医疗器械生产质量管理规范独立软件现场检查指导原则》（征求意见稿）

[19]《无源植入性骨、关节及口腔硬组织个性化增材制造医疗器械注册技术审查指导原则》（国家药品监督管理局通告2019年第70号）

[20]《医疗器械通用名称命名指导原则》(国家药品监督管理局通告2019年第99号)

[21]《医疗器械安全和性能的基本原则》（国家药品监督管理局通告2020年第18号）

[22]《深度学习辅助决策医疗器械软件审评要点》（国家药品监督管理局医疗器械技术审评中心通告2019年第7号）

[23]《肺炎CT影像辅助分诊与评估软件审评要点（试行）》（国家药品监督管理局医疗器械技术审评中心通告2020年第8号）

[24] GB 4793.1-2007《测量、控制和实验室用电气设备的安全要求 第1部分：通用要求》

[25] GB 4943.1-2011《信息技术设备 安全 第1部分：通用要求》

[26] GB 9706.1-2007《医用电气设备 第1部分：安全通用要求》

[27] GB 9706.15-2008《医用电气设备 第1-1部分：安全通用要求 并列标准：医用电气系统安全要求》

[28] GB/T 8566-2007《信息技术 软件生存周期过程》

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

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

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

[32] GB/T 20158-2006《信息技术 软件生存周期过程 配置管理》

[33] GB/T 20438.1-2017《电气/电子/可编程电子安全相关系统的功能安全 第1部分：一般要求》

[34] GB/T 20438.2-2017《电气/电子/可编程电子安全相关系统的功能安全 第2部分：电气/电子/可编程电子安全相关系统的要求》

[35] GB/T 20438.3-2017《电气/电子/可编程电子安全相关系统的功能安全 第3部分：软件要求》

[36] GB/T 20438.4-2017《电气/电子/可编程电子安全相关系统的功能安全 第4部分：定义和缩略语》

[37] GB/T 20918-2007《信息技术 软件生存周期过程 风险管理》

[38] GB/T 25000.10-2016《系统与软件工程 系统与软件质量要求和评价（SQuaRE） 第10部分：系统与软件质量模型》

[39] GB/T 25000.51-2016《系统与软件工程 系统与软件质量要求和评价（SQuaRE） 第51部分：就绪可用软件产品（RUSP）的质量要求和测试细则》

[40] GB/T 31167—2014《信息安全技术 云计算服务安全指南》

[41] GB/T 31168—2014《信息安全技术 云计算服务安全能力要求》

[42] GB/T 35278-2017《信息安全技术 移动终端安全保护技术要求》

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

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

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

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

[47] YY/T 0287-2017《医疗器械 质量管理体系 用于法规的要求》

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

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

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

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

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

[53] YY/T 0973-2016 《自动控制式近距离后装设备放射治疗计划系统 性能和试验方法》

[54] YY/T 1474-2016 《医疗器械 可用性工程对医疗器械的应用》

[55] YY/T 1630-2018《医疗器械唯一标识基本要求》

[56] YY/T 1681-2019《医疗器械唯一标识系统基础术语》

[57] IEC 60601-1 AMD1:2012, Medical electrical equipment - Part 1: General requirements for basic safety and essential performance

[58] IEC 62304 AMD1:2015, Medical device software - Software life cycle processes

[59] IEC 62366-1:2015 Medical devices - Part 1: Application of usability engineering to medical devices

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

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

[62] ISO/TR 80002-2:2017, Medical device software - Part 2: Validation of software for regulated processes

[63] IEC/TR 80002-3:2014, Medical device software - Part 3: Process reference model of medical device software life cycle processes (IEC 62304)

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

[65] AAMI TIR45:2012, Guidance on the use of AGILE practices in the development of medical device software

[66] FDA, General Principles of Software Validation, 2002.1

[67] FDA, Cybersecurity for Networked Medical Devices Containing Off-the-Shelf Software, 2005.1

[68] FDA, Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices, 2005.5

[69] FDA, Modifications to Devices Subject to Premarket Approval (PMA), 2008.12

[70] FDA, Acceptable Media for Electronic Product User Manuals, 2010.3

[71] FDA, Computer-Assisted Detection Devices Applied to Radiology Images and Radiology Device Data, 2012.7

[72] FDA, Considerations for Computer-Assisted Detection Devices Applied to Radiology Images and Radiology Device Data, 2012.7

[73] FDA, Content of Premarket Submissions for Management of Cybersecurity in Medical Devices, 2014.10

[74] FDA, Postmarket Management of Cybersecurity in Medical Devices, 2016.12

[75] FDA, Applying Human Factors and Usability Engineering to Medical Devices, 2016.2

[76] FDA, Deciding When to Submit a 510(k) for a Software Change to an Existing Device, 2017.10

[77] FDA, Design Considerations and Pre-market Submission Recommendations for Interoperable Medical Devices, 2017.9

[78] FDA, Medical Device Accessories - Describing Accessories and Classification Pathways, 2017.12

[79] FDA, Technical Considerations for Additive Manufactured Medical Devices, 2017.12

[80] FDA, Multiple Function Device Products: Policy and Considerations Draft, 2018.4

[81] FDA, Content of Premarket Submissions for Management of Cybersecurity in Medical Devices Draft, 2018.10

[82] FDA, Developing a Software Precertification Program: A Working Model, 2019.1

[83] FDA, Technical Performance Assessment of Quantitative Imaging in Device Premarket Submissions Draft, 2019.4

[84] FDA, Proposed Regulatory Framework for Modifications to Artificial Intelligence/Machine Learning (AI/ML) - Based Software as a Medical Device (SaMD) Draft, 2019.5

[85] FDA, Off-The-Shelf Software Use in Medical Devices, 2019.9

[86] FDA, General Wellness: Policy for Low Risk Devices, 2019.9

[87] FDA, Medical Device Data Systems, Medical Image Storage Devices, and Medical Image Communications Devices, 2019.9

[88] FDA, Policy for Device Software Functions and Mobile Medical Applications, 2019.9

[89] FDA, Changes to Existing Medical Software Policies Resulting from Section 3060 of the 21st Century Cures Act, 2019.9

[90] FDA, Clinical Decision Support Software Draft, 2019.9

[91] MEDDEV 2.1/6, Qualification and Classification of Standalone Software, 2016.7

[92] NB-MED/2.2/Rev4, Software and Medical Devices, 2010.3

[93] IMDRF/UDI WG/N7 FINAL: 2013, UDI Guidance: Unique Device Identification of Medical Devices, 2013.9

[94] IMDRF/SaMD WG/N10 FINAL: 2013, Software as a Medical Device (SaMD): Key Definitions, 2013.12

[95] IMDRF/SaMD WG/N12 FINAL: 2014, Software as a Medical Device (SaMD): Possible Framework for Risk Categorization and Corresponding Considerations, 2014.9

[96] IMDRF/SaMD WG/N23 FINAL: 2015, Software as a Medical Device (SaMD): Application of Quality Management System, 2015.10

[97] IMDRF/SaMD WG/N41 FINAL: 2017, Software as a Medical Device (SaMD): Clinical Evaluation, 2017.9

[98] IMDRF/CYBER WG/N60 FINAL: 2020, Principles and Practices for Medical Device Cybersecurity, 2020.4