医疗器械软件技术审查指导原则第二版征求意见稿.docx

《医疗器械软件技术审查指导原则第二版征求意见稿.docx》由会员分享，可在线阅读，更多相关《医疗器械软件技术审查指导原则第二版征求意见稿.docx（79页珍藏版）》请在三一文库上搜索。

1、附件1医疗器械软件技术审查指导原则（第二版征求意见稿）目录前言一、适用范围二、软件基础（一）医疗器械软件（二）系统软件、应用软件、中间件、支持软件（三）软件生存周期（四）软件测试、软件验证、软件确认（五）软件可追溯性分析（六）软件更新（七）软件版本（八）软件算法、软件功能、软件用途三、基本原则（一）基于软件特性（二）风险导向（三）全生命周期管理四、现成软件（一）基本概念（二）通用考量五、质量管理软件（一）基本概念（二）软件确认考量六、软件生存周期过程七、技术考量（一）注册单元与检测单元（二）临床评价基本原则（三）网络安全（四）云计算（五）移动计算（六）人工智能/机器学习（七）人因设计（八）互操

2、作性（九）测量功能（十）非医疗器械功能（十一）产品设计软件（十二）使用期限八、软件研究资料（一）自研软件研究报告（二）自研软件更新研究报告（三）现成软件研究资料九、注册申报资料说明（一）产品注册（二）许可事项变更（三）延续注册十、参考文献附录：独立软件产品技术要求模板医疗器械软件技术审查指导原则（第二版）本指导原则旨在指导生产企业规范医疗器械软件生存周期过程和准备医疗器械软件注册申报资料，同时规范医疗器械软件技术审评要求，为医疗器械软件和质量管理软件的体系核查提供参考。本指导原则是对医疗器械软件的一般性要求，生产企业应根据医疗器械软件特性提交注册申报资料，判断本指导原则具体内容的适用性，不适用

3、内容详述理由。生产企业亦可采用其他符合法规要求的替代方法，但应提供详尽研究资料。本指导原则基于当前认知水平和技术能力，在现行法规体系下参考国外法规与指南、国际标准与技术报告予以制定。随着认知水平和技术能力的不断提高以及法规体系的不断完善，相关内容也将适时修订。本指导原则作为生产企业、审评人员和检查人员的指导性文件，不包括审评审批所涉及的行政事项，亦不作为法规强制执行，应在符合法规要求的前提下使用本指导原则。本指导原则针对软件特殊性，在现行法规体系下进一步明确医疗器械软件监管要求。本指导原则是医疗器械软件的通用指导原则，其他涉及软件的医疗器械指导原则可在本指导原则基础上进行有针对性的调整、修改和

4、完善。一、适用范围本指导原则适用于医疗器械软件的注册申报，包括第二、三类独立软件和含有软件组件的医疗器械；适用于自研软件、现成软件的注册申报。本指导原则也可用作医疗器械软件、质量管理软件体系核查的参考。二、软件基础（一）医疗器械软件医疗器械软件包括本身即为医疗器械的软件或者医疗器械内含的软件，前者即医疗器械独立软件（以下简称独立软件），后者即医疗器械软件组件（以下简称软件组件），详见图1。独立软件是指具有一个或多个医疗目的/用途，无需医疗器械硬件即可完成自身预期目的/用途，运行于通用计算平台的软件，通用计算平台满足信息技术设备安全要求。独立软件可分为通用型独立软件和专用型独立软件，前者通常基于

5、通用数据接口与多个医疗器械联合使用，如医学图像处理软件、生理参数监护软件；后者基于通用、专用数据接口与特定医疗器械联合使用，可视为医疗器械附件，如动态心电数据分析软件、眼科显微镜图像处理软件。软件组件是指具有一个或多个医疗目的/用途，控制/驱动医疗器械硬件或运行于医用计算平台的软件，医用计算平台满足医用电气设备或实验室用电气设备安全要求。医用计算平台可与通用计算平台联合使用构成系统，整体视为医用计算平台。软件组件可分为内嵌型软件组件和外控型软件组件，前者运行于医用计算平台，控制/驱动医疗器械硬件，如心电图机、脑电图机所含嵌入式软件（即固件），产品整体属于可编程医用电气设备；后者运行于通用计算平

6、台，控制/驱动医疗器械硬件，产品整体属于可编程医用电气系统，如CT、MRI图像采集工作站软件。独立软件作为医疗器械或医疗器械附件，通常单独注册，特殊情况可随医疗器械进行注册，此时虽不控制/驱动医疗器械硬件但运行于医用计算平台，故视为软件组件，如专用型独立软件可作为附件随医疗器械进行注册。软件组件作为医疗器械或医疗器械部件、附件的组成部分，不能单独注册，需随医疗器械进行注册。图1：医疗器械软件（二）系统软件、应用软件、中间件、支持软件系统软件是指设计用于保障计算机系统正常运行的软件，如操作系统软件、虚拟机软件。应用软件是指设计用于实现计算机用户特定需求的软件，如浏览器软件、数据库软件、安全软件。

7、中间件介于系统软件和应用软件之间，依赖于系统软件的支持，同时又为应用软件提供支持，如Web服务器软件。支持软件是指设计用于开发、测试其他软件的软件，如软件开发工具、软件测试工具。医疗器械软件属于应用软件，其正常运行通常需要基于系统软件，或同时需要应用软件（含其他医疗器械软件）、中间件、支持软件的支持。有些生产企业会开发医用中间件用作本企业医疗器械软件的公共支持平台，这些医用中间件本身虽无需单独注册，但却是医疗器械软件正常运行所必需的，故作为医疗器械软件的组成模块予以考虑。有些支持软件（如VTK、ITK）自带算法库，医疗器械软件开发过程已将算法库相关内容集成于自身内部，故医疗器械软件正常运行需要

8、这些支持软件。本指导原则将医疗器械软件正常运行所必需的其他医疗器械软件、医用中间件称为必备软件，而将其正常运行所必需的系统软件、通用应用软件、通用中间件、支持软件统称为外部软件环境，即外部软件环境不含必备软件。（三）软件生存周期软件生存周期（又称软件生命周期）是指软件系统从概念定义至停止使用的时间周期，包括软件开发策划、软件需求分析、软件设计、软件编码、软件测试、软件发布、软件部署、软件维护、软件停运等阶段。软件开发策划主要确定软件开发的目标和可行性。软件需求分析是将法规、标准、用户、产品等方面要求转换为软件需求规范/软件需求规格说明（SRS）。软件设计是将软件需求规范转换为软件设计规范（SD

9、S）。软件编码是通过编写源代码将软件设计规范转换为软件系统。软件测试是通过各类测试活动保证软件系统质量。软件发布是将软件系统予以产品定型。软件部署是指软件系统的交付、安装、设置和配置。软件维护是对软件系统上市后的更新需求予以实现。软件停运（又称软件退市）是指终止软件系统的销售和售后服务。软件生存周期模型是指一组包含过程、活动和任务的框架，跨越从软件需求分析到软件停运的软件生存周期过程，每个过程可细分为若干活动，每个活动又可细分为若干任务。常见模型包括瀑布模型、迭代模型、增量模型、V模型等。敏捷开发是以人为核心、迭代与增量相结合的软件生存周期模型，如SCRUM、极限编程（XP）等。敏捷开发秉承四

10、条理念：人员互动胜于过程和工具，可用的软件胜于详尽的文档，客户合作胜于合同谈判，响应变化胜于遵循计划。使用敏捷开发需要兼顾质量管理体系相关要求，重点关注软件更新控制、文件与记录控制等要求。生产企业可结合软件的产品特点、风险程度以及质量管理体系要求，选择适宜的软件生存周期模型，参照相关国际、国家、行业标准建立相应软件生存周期过程。（四）软件测试、软件验证、软件确认软件测试是软件质量保证的基本措施，也是软件验证、软件确认的重要方法，从不同角度有不同分类方法。从测试依据角度可分为黑盒测试和白盒测试。其中，黑盒测试是指基于规范的测试，白盒测试是指基于源代码的测试。白盒测试根据是否运行源代码又可分为静态

11、分析和动态分析，需考虑语句、判定、条件、路径等测试覆盖率要求，其中语句测试覆盖率应保证100%。从测试进程角度可分为单元测试、集成测试、系统测试。其中，单元测试是对软件单元进行测试，通常采用白盒测试；集成测试是对软件项（由若干软件单元组成，即软件模块）进行测试，白盒测试与黑盒测试相结合；系统测试是对软件系统（由若干软件项组成）进行测试，采用黑盒测试，其从测试内容角度又可分为功能测试、性能测试、并发测试、压力测试、接口测试、兼容性测试、用户界面测试、安装卸载测试等类型。从测试实施方角度可分为内部测试、用户测试、第三方测试。其中，内部测试是指生产企业实施的测试，包括单元测试、集成测试、系统测试，白

12、盒测试和黑盒测试相结合；用户测试是指用户在真实或模拟使用场景对软件系统进行测试，采用黑盒测试；第三方测试是指第三方机构对软件系统进行测试，采用黑盒测试。回归测试是指用于确定软件更新没有产生不良影响且未引入不可接受新缺陷的软件测试。回归测试需根据软件更新的类型、内容和程度，开展与之相适宜的单元测试、集成测试、系统测试、用户测试、第三方测试等测试活动。软件验证是指通过提供客观证据认定软件开发、软件维护某一阶段的输出满足输入要求。软件验证包括源代码审核、静态分析、动态分析、单元测试、集成测试、系统测试、评审等一系列活动，是软件确认的基础。软件确认是指通过提供客观证据认定软件满足用户需求和预期用途。软

13、件确认是基于过程控制的设计确认，包括用户测试、临床评价、评审等一系列活动，即要保证软件满足用户需求和预期用途，又要确保软件已知剩余缺陷的风险均可接受。生产企业需结合软件的产品特点、风险程度考虑相应软件测试要求，以保证软件验证、软件确认的质量。（五）软件可追溯性分析软件可追溯性分析作为软件验证、软件确认的重要活动之一，是指追踪软件需求、软件设计、源代码、软件测试、软件风险管理之间的关系，分析已识别关系的正确性、一致性、完整性、准确性。软件生存周期过程均应开展软件可追溯性分析，详见图2。软件需求分析追溯分析软件需求与产品需求、软件需求与风险分析的关系。软件设计追溯分析软件设计与软件需求、软件设计与

14、风险控制的关系。软件编码追溯分析源代码与软件设计、源代码与测试用例的关系。内部测试追溯分析单元测试、集成测试、系统测试各级测试用例与软件设计，系统测试与软件需求，系统测试与风险管理的关系。用户测试追溯分析用户测试与产品需求、用户测试与风险管理的关系。软件更新亦应开展软件可追溯性分析。图2：软件可追溯性分析生产企业需建立软件可追溯性分析过程，以规范软件可追溯性分析相关活动要求，以保证软件验证、软件确认的质量。（六）软件更新1. 基本概念软件更新是指生产企业在软件生存周期全过程对软件所做的任一修改，亦称软件变更、软件维护。软件维护通常与软件更新含义相同，但可特指上市后软件更新。软件更新从不同角度出

15、发有不同分类方法。从更新结果角度可分为重大更新和轻微更新，重大更新是指影响到医疗器械安全性或有效性的软件更新，反之即为轻微更新。从更新内容角度可分为增强类更新和纠正类更新（即软件缺陷修复）。增强类更新又可分为完善型更新和适应型更新，其中完善型更新是指改变功能、性能、接口等软件属性的软件更新，适应型更新是指适应新运行环境的软件更新。纠正类更新又可分为修正型更新和预防型更新，其中修正型更新是指修复软件存在且已造成运行故障缺陷的软件更新，预防型更新是指修复软件存在但尚未造成运行故障缺陷的软件更新。本指导原则关注软件的安全性和有效性，故将软件更新（图3）分为：（1）重大软件更新：影响到医疗器械安全性或

16、有效性的增强类更新，即重大增强类软件更新，应申请许可事项变更。（2）轻微软件更新：不影响医疗器械安全性与有效性的增强类更新、纠正类更新，包括轻微增强类软件更新、纠正类软件更新，通过质量管理体系进行控制，无需申请许可事项变更，待下次许可事项变更时提交相应注册申报资料。考虑到软件更新具有累积效应，注册申报资料应涵盖自前次注册以来的全部软件更新内容。此外，软件构建（Build）即软件编译生成一个工作版本，符合软件更新定义，视为纠正类软件更新。召回相关软件更新包括软件更新导致召回、召回措施所用软件更新，均属于重大软件更新，按照医疗器械召回相关法规要求处理。软件重新开发即生产企业弃用原有软件而开发新软件

17、不属于软件更新范畴，按初次发布处理。软件更新遵循风险从高原则，即同时发生重大、轻微软件更新按重大软件更新处理，同时发生增强类、纠正类软件更新按增强类软件更新处理。图3：医疗器械软件更新2. 重大软件更新软件更新若影响到医疗器械的预期用途、使用场景或核心功能原则上均属于重大软件更新，包括但不限于：（1）完善型软件更新：影响到用户决策（含决策能力、决策结果、决策流程、用户行动）或人员（含患者、用户、其他相关人员）安全，如软件的输入输出、用户界面结构、核心算法、核心功能、工作流程或预期用途等发生改变，或符合新安全标准要求等；而运算速度单纯提高、工作流程可配置化、用户界面文字性修改等情况一般不视为重

18、大软件更新，除非影响到医疗器械的安全性或有效性。（2）适应型软件更新：软件运行平台跨越互不兼容的计算平台（含硬件、软件），如操作系统软件由Windows变为iOS，计算平台由通用计算平台变为医用计算平台等；系统软件、支持软件和中间件的补丁一般不视为重大软件更新，除非影响到医疗器械的安全性或有效性。（3）混合型软件更新：软件的安全性级别、体系结构、用户界面关系或物理拓扑发生改变。重大软件更新的范围会随着认知水平与技术能力的提高、不良事件与召回的情况分析进行动态调整。（七）软件版本软件没有物理实体，只能通过状态标识进行软件更新管理，从而保证软件质量。软件版本使用不同字段来区分软件更新类型，进而标识

19、软件状态，因此软件版本与软件是一一对应的表里关系，亦是软件标识不可或缺的组成部分。从医疗器械唯一标识（UDI）角度，软件版本可分为软件发布版本和软件完整版本，前者属于产品标识（DI）组成部分，后者属于生产标识（PI）组成部分。具体而言，软件发布版本仅体现重大软件更新，即只限于重大增强类软件更新，其改变意味着发生重大软件更新，反之亦然；软件完整版本体现重大、轻微软件更新的全部类型，包括重大增强类软件更新、轻微增强类软件更新、纠正类软件更新、软件构建（若适用），其不同字段的改变意味发生不同类型的软件更新，反之亦然。软件发布版本发生改变代表软件发生重大更新，应申请许可事项变更，软件完整版本发生改变但

20、软件发布版本未变代表软件仅发生轻微更新，此时通过质量管理体系进行控制，无需申请许可事项变更。例如，软件版本命名规则为X.Y.Z.B，其中X表示重大增强类软件更新，Y表示轻微增强类软件更新，Z表示纠正类软件更新，B表示软件构建，则软件发布版本为X，软件完整版本为X.Y.Z.B，此时X改变应申请许可事项变更，而Y、Z、B改变但X未改变无需申请许可事项变更。生产企业需综合考虑软件产品特点、质量管理体系要求、合规性等因素制定软件版本命名规则，涵盖软件更新全部类型，字段含义明确且无歧义无矛盾，能够区分重大软件更新和轻微软件更新（若不能区分遵循风险从高原则），保证软件更新的版本变更符合软件版本命名规则要求

21、有用户界面的软件可在登录界面、主界面、“关于”或“帮助”等界面体现软件发布版本、软件完整版本。无用户界面的软件需提供获取软件版本信息的技术方法。检测报告提供软件版本界面照片或列明软件版本信息，说明书注明软件发布版本。对于进口医疗器械软件，生产企业应提供申报版本软件在原产国已获准上市的证明性文件，注明软件完整版本。（八）软件算法、软件功能、软件用途软件算法是软件功能的基础，二者是多对多的关系，即一个软件算法可供一个或多个软件功能使用，一个软件功能可含一个或多个软件算法。同理，软件功能和软件用途的关系亦是如此。从用户角度出发，软件算法是内在不可见的，软件功能和软件用途是外在可见的，考虑到软件功能

22、是软件算法、软件用途的联系纽带，故以软件功能作为软件安全有效性评价主线。例如，区域生长算法可实现图像分割功能，图像分割功能可用于病变轮廓标识。软件功能从不同角度出发有不同分类方法。从重要性角度可分为核心功能和非核心功能，其中核心功能是指软件在预期使用场景完成预期用途所必需的功能，反之即为非核心功能。从技术特征角度大体上可分为控制功能和处理功能，其中控制功能是指控制/驱动医疗器械硬件运行的功能，处理功能是指加工医疗器械数据的功能。处理功能从数据流角度又可分为前处理功能和后处理功能，前者是指采集人体解剖、生理信息生成医疗器械数据过程的处理功能，如滤波、降噪、校正、重建等功能；后者是指利用医疗器械数

23、据生成诊疗信息过程的处理功能，如平移、缩放、旋转、滤波、测量、分割融合、三维可视化、计划制定等功能。后处理功能从复杂性角度又可分为简单功能和复杂功能，前者是指对现有医疗信息进行操作而非生成新医疗信息的功能，如平移、缩放、旋转等功能；后者是指生成新医疗信息的功能，如滤波、测量、分割融合、三维可视化、计划制定等功能。独立软件的功能均为后处理功能，软件组件的功能以控制功能、前处理功能为主，兼具后处理功能。考虑到控制功能和前处理功能通常与医疗器械硬件共同评价，故处理功能若无明示均指后处理功能。从监管范围角度可分为医疗器械功能和非医疗器械功能，其中医疗器械功能是指可用作医疗器械界定依据的软件功能，如医学

24、图像、生理参数数据的测量、处理、分析等功能；反之即为非医疗器械功能，如收费计价、行政办公等功能；必要的患者信息管理功能属于医疗器械功能。二者尽量通过模块化设计予以拆分，若在技术上无法拆分需将非医疗器械功能作为医疗器械软件的组成部分予以整体考虑。软件算法从重要性角度可分为核心算法和非核心算法，其中核心算法是指实现软件核心功能所必需的算法，反之即为非核心算法。从复杂性角度可分为简单算法和复杂算法，前者原理简单明确，后者通常基于模型研究，存在诸多假设条件且影响因素较多，同时二者在算法规模、参数数量、运算速度等方面亦存在差异。软件用途通常可分为辅助决策和非辅助决策，其中辅助决策是指通过提供诊疗活动建议

25、辅助医务人员进行临床决策，反之即为非辅助决策，包括流程优化、诊疗驱动。辅助决策相当于医务人员的“助手”，非辅助决策相当于医务人员的“工具”。故软件功能从软件用途角度又可分为辅助决策类功能和非辅助决策类功能。软件算法、软件功能、软件用途从成熟度角度均可分为成熟和全新两种类型，其中成熟是指安全有效性已在使用实践中得到充分证实的情形，全新是指未上市或安全有效性尚未在使用实践中得到充分证实的情形。同理，软件亦可分为全新软件和成熟软件，软件的算法、功能、用途若有一项为全新类型则属于全新软件，反之属于成熟软件。因全新软件的风险高于成熟软件，故本指导原则以核心功能、核心算法为基础，重点关注全新软件的安全有效

26、性。三、基本原则（一）基于软件特性随着信息技术的迅猛发展，软件在医疗器械中的应用日益普遍，作用日趋重要，开发形式灵活多变，新技术层出不穷。但随之而来的质量问题也日益增多，医疗器械召回数据表明软件相关召回数量持续增加，明显高于同期医疗器械整体水平，同时软件失效导致患者死亡或严重伤害的召回事件也屡见不鲜，因此软件质量问题的严重性不容忽视。软件没有物理实体，在开发和使用过程中人为因素影响无处不在，软件测试由于时间和成本的限制不能穷尽所有情况，所以软件缺陷无法避免。同时，软件更新频繁且迅速，轻微更新可能导致严重后果，并存在累积效应和退化问题（即每修复若干个缺陷就会产生一个新缺陷），所以软件缺陷无法根除

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

28、量管理和软件工程的要求才能保证软件的安全有效性。生产企业应基于软件风险程度，采用良好软件工程实践完善质量管理体系，针对算法、接口、更新等软件召回主要原因，尽早、重点、全面开展软件质量保证工作。（二）风险导向综合考虑软件使用的普遍性、监管资源的有限性和风险分级管理导向，软件风险程度不同，其生存周期质控要求和注册申报资料要求亦不同。软件风险程度采用软件安全性级别进行表述，软件安全性级别越高，生存周期质控要求越严格，注册申报资料也越详尽。软件安全性级别基于软件风险程度分为轻微、中等、严重，其中轻微级别（A级）即软件不可能产生伤害，中等级别（B级）即软件可能直接或间接产生轻微伤害，严重级别（C级）即软

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

30、果如结构化报告、屏显结果）。软件安全性级别也可根据风险管理所确定的风险等级进行判定，软件安全性级别与风险等级的分级可以不同，但二者存在对应关系，因此可根据风险等级来判定软件安全性级别，但应在采取风险缓解措施之前进行判定。软件风险管理需要注意：软件本身不是危险源，但会引发危险情况；软件失效虽表现为随机性失效但实为系统性失效，即软件失效概率视为100%，由于软件失效所致伤害概率难以统计，故软件风险程度基于伤害严重度进行判定；软件组件应与所属医疗器械整体开展风险管理。生产企业应结合质量管理体系要求，建立充分、适宜、有效的软件生存周期过程，并开展与软件安全性级别相匹配的软件质量保证工作。同时，基于软件

31、安全性级别提交相应注册申报资料，注册申报资料均源自软件生存周期过程所形成的文档。独立软件和软件组件虽然存在技术特征差异，但生存周期过程质控要求相同，故二者注册申报资料基本一致，具体内容略有差异，详见第八章。（三）全生命周期管理由于软件本身的复杂性和软件测试的局限性，软件开发过程的质量保证活动不足以保证软件的安全有效性，因此应在医疗器械全生命周期中考虑软件质控要求，并将软件风险管理、软件配置管理、软件缺陷管理、软件可追溯分析贯穿于全程。上市前应开展充分有效的软件验证与确认活动，识别软件可预见的风险并将其降至可接受水平。上市后结合用户投诉、不良事件和召回等情况，识别前期未预见的风险采取必要措施保证

32、软件质量，同时基于软件更新需求的评估，实施软件更新活动以满足用户新需求，并开展与之相适宜的软件验证与确认活动，以保证软件更新质量。四、现成软件（一）基本概念现成软件是指生产企业未进行完整生存周期控制的软件，包括遗留软件、成品软件、外包软件。其中，遗留软件是指生产企业以前开发但现在不能得到足够开发记录的软件，涉及医用应用软件、医用中间件。成品软件是指已开发且通常可得到的，但生产企业未进行完整生存周期控制的软件，涉及系统软件、应用软件、中间件、支持软件，如开源/闭源软件、免费/付费软件等。外包软件是指生产企业委托第三方开发的软件，涉及医用应用软件、医用中间件。现成软件与医疗器械软件的关系可分为两类

33、一类是现成软件作为医疗器械软件的组成部分，即现成软件组件，包括遗留软件、成品软件、外包软件，涉及应用软件、中间件、支持软件；无论是否设计用于医疗用途，现成软件组件作为医疗器械软件的组成部分，其功能均属于医疗器械功能。另一类是现成软件作为医疗器械软件运行环境的组成部分，即外部软件环境，均为成品软件，涉及系统软件、通用应用软件、通用中间件、支持软件，其功能均属于非医疗器械功能。综上，现成软件类型详见图4。图4：现成软件类型医疗器械软件除部分嵌入式软件外，均需外部软件环境的支持方能运行。同时，医疗器械软件既可自研软件和现成软件组件相结合，部分使用现成软件组件，即部分使用方式；又可全部使用现成软件组

34、件，即全部使用方式。因此，现成软件具有普遍性、灵活性、复杂性等特点。由于现成软件，特别是外部软件环境，通常并非设计用于医疗用途，未必能够满足医疗器械相关要求，未用功能可能通过耦合关系对医疗器械软件产生不利影响，而且生产企业未对现成软件进行完整生存周期控制，因此使用现成软件的风险相对较高，特别是现成软件组件。生产企业使用现成软件应保证医疗器械软件的安全有效性，而现成软件开发商作为供应商并不承担生产企业相关责任。因此，生产企业应结合现成软件的类型、特点以及业界使用情况，区分现成软件组件和外部软件环境，综合考虑现成软件的使用广泛度、技术成熟度、售后支持程度以及功能、性能、兼容性、易用性、可靠性、维护

35、性、可移植性、网络安全等方面要求，采用基于风险的全生命周期管理方法进行质控，特别是在采购、设计开发、上市后监测等方面。由于自研软件与现成软件、现成软件组件与外部软件环境、部分使用方式与全部使用方式的质控要求均存在差异，故相应注册申报资料均有所不同，具体要求详见第八章。此外，医疗器械软件可同时使用多个版本、多个、多种的现成软件，需进行整体考量并提供相应注册申报资料。（二）通用考量1. 现成软件组件现成软件组件的软件更新、软件版本相关要求与自研软件基本相同，同样遵循风险从高原则。现成软件组件若发生重大软件更新亦需申请许可事项变更，若发生轻微软件更新通过质量管理体系进行控制，无需申请许可事项变更。现

36、成软件组件的版本命名规则亦需考虑合规性要求。若现成软件组件供应商的软件版本命名规则满足合规性要求，生产企业可直接采用。2. 外部软件环境医疗器械软件与外部软件环境存在耦合关系，需进行整体考量。从医疗器械软件角度，软件安全性级别判定需考虑外部软件环境失效的影响，软件需求规范（SRS）文档、软件测试计划与报告均需列明外部软件环境所含各现成软件的名称、完整版本、补丁版本。软件测试需基于外部软件环境所含全部现成软件予以实施，若同一现成软件有多个版本，则每个版本均需纳入软件测试。医疗器械软件必要时应具备外部软件环境自检功能，以确保自身能够正常运行。说明书必要时应明确外部软件环境所含全部现成软件的交付、安

37、装、设置、配置、更新等要求，以及使用限制、警示提示等说明。从外部软件环境角度，自身风险相对较低，由于与医疗器械软件相互耦合，故其安全性级别与医疗器械软件的安全性级别相同，注册申报资料详尽程度亦取决于安全性级别。外部软件环境更新对于医疗器械软件而言属于适应型更新，包括补丁更新、版本更新、产品更新（即更换外部软件环境所含现成软件）等情况。外部软件环境更新情况不同，对于医疗器械软件的影响亦不同，通常补丁更新、与医疗器械软件兼容的版本更新属于轻微软件更新，而产品更新、与医疗器械软件不兼容的版本更新属于重大软件更新，同样遵循风险从高原则。因此，生产企业应建立相应流程开展外部软件环境更新的影响评估工作。五

38、质量管理软件（一）基本概念质量管理软件是指医疗器械质量管理所用的应用软件，不是医疗器械软件，无需申报注册。质量管理软件亦需外部软件环境（含系统软件、通用应用软件、通用中间件、支持软件）的支持方能正常运行。质量管理软件参照医疗器械软件可分为类独立软件和类软件组件，前者包括设计开发所用软件、流程管理所用软件等软件，后者包括生产设备所含软件、检验设备所含软件等软件。质量管理软件多数通过采购获得，特别是类软件组件，可视为成品软件，且采用全部使用方式；少数自行研发，主要是类独立软件，可视为自研软件。因此，质量管理软件确认可参照全部使用成品软件、自研软件的确认要求。（二）软件确认考量质量管理软件确认以软

39、件功能为基础，综合考虑需求分析、验收测试、维护计划等要求。其中，需求分析考虑软件的功能、性能、接口等方面要求，评估候选软件以确定目标对象。验收测试基于外部软件环境予以实施，确保软件能够满足使用需求，而且软件已知剩余缺陷、未用软件功能对于医疗器械软件质量的影响均可接受。维护计划考虑软件更新相关要求，特别是纠正类软件更新（即软件缺陷修复）的维护方案。质量管理软件外部软件环境的评估要求可参照自研软件相应要求。质量管理软件更新应重新进行软件确认，其外部软件环境更新亦需开展影响评估工作。六、软件生存周期过程软件生存周期过程主要包括软件开发过程、软件维护过程、软件风险管理过程、软件配置管理过程、软件缺陷管

40、理过程等过程。软件开发过程包括软件开发策划、软件需求分析、软件设计、软件编码、软件验证、软件确认、软件发布等活动。软件维护过程适用于上市后增强类软件更新，包括软件更新需求评估、软件更新策划、软件更新实施、软件验证、软件确认、软件发布、用户告知等活动。软件风险管理过程包括风险分析、风险评价、风险控制、综合剩余风险评价等活动，基于医疗器械风险管理过程予以实施，可采用医疗器械常用风险管理方法。软件配置管理过程包括配置项识别、更改控制、配置状态记录等活动，基于软件版本命名规则进行软件版本控制，可使用配置管理工具或常用办公软件予以实施。软件版本命名规则应涵盖软件、现成软件、网络安全的全部软件更新类型，各

41、字段含义明确且无歧义无矛盾。软件缺陷管理过程适用于上市前和上市后纠正类软件更新，包括软件缺陷评估、软件缺陷修复、回归测试等活动，可使用缺陷管理工具或常用办公软件予以实施。软件开发过程、软件维护过程是前后关系，软件风险管理过程、软件配置管理过程、软件缺陷管理过程贯穿于软件开发过程、软件维护过程。同时，软件可追溯性分析也是软件生存周期过程重要过程之一，同样贯穿于软件开发过程、软件维护过程，可使用可追溯性分析工具或常用办公软件予以实施。此外，软件生存周期过程亦需考虑现成软件、网络安全相关要求。现成软件考虑采购控制、设计开发控制等要求，使用外包软件需与供应商签订质量协议，使用遗留软件需评估现有文件、上

42、市后使用问题（含不良事件、召回）等情况，使用开源软件需遵循相应开源许可协议。网络安全设计开发应与软件设计开发相融合，并考虑网络安全事件应急响应要求。软件生存周期过程质量保证活动要求应与软件安全性级别相匹配，软件风险程度越高，其质控要求越严格。敏捷开发还需明确文件与记录控制要求。软件生存周期过程（包括现成软件、网络安全）具体要求详见医疗器械生产质量管理规范附录独立软件。七、技术考量（一）注册单元与检测单元1. 注册单元划分原则（1）独立软件独立软件注册单元以管理类别、预期用途、功能模块作为划分原则。不同管理类别的独立软件作为不同注册单元，若在技术上无法拆分可作为一个注册单元并按照较高管理类别申报

43、注册。不同预期用途的独立软件作为不同注册单元，按照预期用途可分为辅助决策类和非辅助决策类，每类又可细分为治疗计划、诊断、监护、临床管理、个人管理等情形。预期用途相同但核心算法类型不同的独立软件亦作为不同注册单元，如常规图像处理算法和人工智能算法。对于功能庞大复杂的独立软件，依据功能模块的类型和数量划分注册单元，每个注册单元所含功能模块数量需适中。按照功能模块类型可分为平台功能软件和特定功能软件，其中平台功能软件作为软件平台提供基本功能和共用功能，支持多模态数据（如医学图像、生理参数数据、基因测序数据）；特定功能软件运行于平台功能软件并提供特定功能，支持单模态数据，或者使用多模态数据实现某一特定

44、预期用途。例如，某PACS包含数十个单独的功能模块，并含有辅助决策类功能模块，应拆分为一个平台功能软件和多个特定功能软件，其中辅助决策类功能模块单独作为一个注册单元。（2）软件组件软件组件注册单元与所属医疗器械相同。专用型独立软件视为软件组件的注册单元与软件组件相同。2. 检测单元划分原则检测单元是指同一注册单元内用于检测的代表产品。（1）独立软件独立软件检测单元原则上与注册单元相同，但若有多个运行环境或多个发布版本，则每个互不兼容的运行环境或每个互不涵盖的发布版本均应作为一个检测单元。（2）软件组件软件组件检测单元原则上与所属医疗器械相同，但医疗器械若包含多个软件组件或多个发布版本的软件组件

45、则每个软件组件或每个发布版本的软件组件均应作为一个检测单元，除非检测单元能够完整覆盖注册单元全部情况。专用型独立软件视为软件组件的检测单元原则上与软件组件相同，但若有多个运行环境，则每个互不兼容的运行环境均应作为一个检测单元。（二）临床评价基本原则1. 独立软件独立软件以软件功能为基础进行临床评价，可选择已上市医疗器械所含同类软件功能进行比对。非辅助决策类软件功能基于核心功能进行同品种医疗器械比对。全新的核心算法、核心功能、预期用途原则上均应开展临床评价，简单操作类软件功能、单纯流程优化类软件功能可通过非临床证据予以评价。辅助决策类软件功能基于核心算法进行同品种医疗器械比对，比对所选产品的临

46、床证据需基于临床试验。全新的核心算法、核心功能、预期用途原则上均应开展临床试验，临床试验可与预期用途相同且核心算法或核心功能等同的独立软件进行对照。2. 软件组件软件组件控制功能、前处理功能的临床评价通常与所属医疗器械进行整体评价。后处理功能临床评价可参照独立软件要求，亦可随所属医疗器械进行整体评价。专用型独立软件视为软件组件的临床评价与软件组件后处理功能要求相同。（三）网络安全医疗器械网络安全需从信息安全角度综合考虑医疗器械的网络安全和数据安全。医疗器械软件若具备电子数据交换、远程控制或用户访问控制功能，均应考虑网络安全问题，具体要求详见医疗器械网络安全相关指导原则，包括网络安全更新、软件版

47、本命名规则、网络安全研究资料等要求。（四）云计算 移动医疗器械相关指导原则关于云计算的要求同步废止。云计算在医疗器械行业的应用日益增多，虽然其具有降低信息化成本、减少重复建设、提高资源利用率、增加业务灵活性、提升服务专业性等优势，但是也存在着用户对数据控制能力减弱、服务可持续性降低、数据所有权面临挑战、数据保护困难、数据残留难以处理、用户与云服务商责任不清、产生司法管辖权问题、面临网络安全威胁等风险，因此生产企业需权衡使用云计算的收益和风险。云计算可视为现成软件，云服务商即供应商，因此生产企业可参照现成软件和供应商相关要求，考虑云计算的需求分析、风险管理、验证与确认、维护计划等活动要求。需求分

48、析需考虑云计算的技术特征、云服务商的选择问题。云计算技术特征包括服务模式、部署模式、配置情况、核心功能、数据接口、网络安全保证等方面，其中服务模式分为软件即服务（SaaS）、平台即服务（PaaS）、基础设施即服务（IaaS），部署模式分为私有云、公有云、混合云，配置情况包括计算资源、配套软件功能等要求，核心功能包括数据存储、数据处理、数据分析等功能，数据接口考虑传输协议、存储格式等要求，网络安全保证考虑数据匿名、数据加密、数据传输校验、安全配置等技术措施。同时，基于云计算服务资质、云计算服务协议等因素考虑云服务商选择问题，云计算服务协议需明确网络安全保证、患者数据与隐私保护等责任承担要求。风险管理基于云计算的核心功能、数据接口、网络安全保证予以实施。验证与确认应基于云计算环境开展医疗器械软件的验证与确认，确保云计算满足使用要求，且已知剩余缺陷的风险均可接受。维护计划考虑云计算更新的维护方案，重新进行医疗器械软件的验证与确认，明确云计算服务终止的无损数据迁移方案。若使用云计算，生产企业