一、正文中的适用范围

旧版中这里含有概念及医用软件的类型说明，新版将这范围块清晰的划分为“适用范围和主要概念”而适用范围修改为“本指导原则适用于医疗器械软件的注册申报，包括第二、三类独立软件和含有软件组件的医疗器械（包括体外诊断医疗器械）；适用于自研软件、现成软件的注册申报。本指导原则也可用作医疗器械软件、质量管理软件的体系核查参考。”适用范围增加了体外诊断医疗器械和医疗器械软件的体系核查参考。

主要概念新增给出了明确的医疗器械软件、医疗器械独立软件和医疗器械软件组件的定义，同时明确医疗器械独立软件通用计算平台应满足信息技术设备安全要求、电磁兼容及GB4943.1、GB/T9254等标准。医疗器械软件组件应满足相关医用电气设备（GB 9706系列）、实验室用电气设备（GB 4793系列）或有源植入式医疗器械（GB 16174系列）等安全要求（含电磁兼容），并举例示意组件和独立软件的产品。医疗其中软件类型及符合标准参考下图1：

图1 医疗器械软件类型及符合标准

图2医疗器械产品示意图

二、系统软件、应用软件、中间件、支持软件的概念

系统软件是指设计用于保障计算机系统正常运行的软件，如操作系统软件、虚拟机软件。

应用软件是指设计用于实现计算机用户特定需求的软件，如浏览器软件、数据库软件、安全软件。

中间件介于系统软件和应用软件之间，依赖于系统软件的支持，同时又为应用软件提供支持，如分布式计算平台软件。有些注册申请人会开发医用中间件用作医疗器械软件的公共支持平台，由于这些医用中间件是医疗器械软件正常运行所必需的，故作为医疗器械软件的组成部分予以考虑。

支持软件是指设计用于开发、测试其他软件的软件，如软件开发工具、软件测试工具。有些支持软件（如VTK、ITK）自带算法库，医疗器械软件开发过程已将算法库相关内容集成于自身内部，故医疗器械软件正常运行需要这些支持软件的支持。

必备软件：将医疗器械软件正常运行所必需的其他的医疗器械软件及医用中间件称为必备软件。必备软件作为医疗器械软件单独注册，明确相互接口关系及技术特征即可。

外部软件环境：正常运行所必需的系统软件、通用应用软件、通用中间件、支持软件统称为外部软件环境。外部软件环境不含必备软件，亦非医疗器械软件。

三、软件生存周期

软件生存周期模型是指一组包含过程、活动和任务的框架，跨越从软件需求分析到软件停运的软件生存周期过程，每个过程可细分为若干活动，每个活动又可细分为若干任务。常见模型包括瀑布模型、迭代模型、增量模型、V模型等，软件的开发类似某个模型，无法复制完全按照某个模型去完成设计开发。

软件生存周期（又称软件生命周期）是指软件系统从概念定义至停止使用的时间周期，22版的将软件生存周期每一阶段的要求都标明了，我们需在软件的生命周期每个阶段做什么给的非常清楚，具体内容如下表：

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

软件测试、软件验证定义的内容不做赘述，软件确认新增临床评价、设计评审，又要求确保软件已知剩余缺陷的风险均可接受。

五、软件可追溯性分析

软件可追溯性分析作为软件验证、软件确认的重要活动之一，是指追踪软件需求、软件设计、源代码、软件测试、软件风险管理之间的关系，分析已识别关系的正确性、一致性、完整性、准确性。要分析就需要软件可追溯性分析工具，很多企业说自己没有分析工具，一般企业的软件工程师医疗器械行业的法规标准不了解、不熟悉、不懂得，这就会造成他们有用工具但工程师们认为只是办公软件而已，不是可追溯性分析工具，这种现象很普遍，比如Word、Excel都可以作为软件可追溯性分析工具。有了工具就要有工具的使用管理规程制度，有了规程制度就应该有记录，所以你漏了哪些呢？

注册申请人应建立软件可追溯性分析过程，规范软件可追溯性分析相关活动要求，以保证软件验证、软件确认的质量。考虑到行业实际情况，源代码追溯分析活动追溯至软件单元（列明名称）即可。

六、软件更新

软件更新是指注册申请人在软件生存周期全过程对软件所做的任一修改，亦称软件变更、软件维护。软件维护通常与软件更新含义相同，但可特指发布后软件更新。更新维护重点医疗器械产品的安全性和有效性，还需要考虑现成软件组件和外部环境的更新，并开展外部软件环境更新的影响评估工作。目前大部分更新都是需要进行变更注册的。

七、软件版本

软件完整版本和发布版本，注册申请人应综合考虑软件产品特点、质量管理体系要求、合规性等因素制定软件版本命名规则并予以记录，明确字段的位数、范围、含义，涵盖软件更新全部类型，字段含义明确且无歧义无矛盾，能够区分重大软件更新和轻微软件更新，保证软件更新的版本变更符合软件版本命名规则要求。从医疗器械唯一标识（UDI）角度，软件完整版本属于生产标识（PI）的组成部分。现阶段很多小伙伴被发补过软件版本命名规则不清晰的问题，主要是含义不明确，范围不清晰，字段的位数有多有少不一致。还有一些则是软件界面上没有完整版本号或没有发布版本信息。检测报告提供软件版本界面照片或列明软件版本信息，有用户界面的软件体现软件发布版本、软件完整版本，无用户界面的软件体现软件完整版本。说明书注明软件发布版本。

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

先上个关系图，看看软件算法、软件功能、软件用途之间的关系

软件算法是软件功能的基础，二者是多对多的关系，即一个软件算法可供一个或多个软件功能使用，一个软件功能可含一个或多个软件算法。同理，软件功能和软件用途的关系亦是如此。这里体现了质量管理体系的重要性及各部门之间的沟通。算法是研发技术人员熟知的，功能是研发技术人员设计实现的软件用途，注册人员是能看不能写，注册申报涉及算法研究的只能研发技术自己输出。

8.1软件功能分类还是做个表比比，话不多说看表：

8.2软件算法

软件算法从重要性角度可分为核心算法和非核心算法，其中核心算法是指实现软件核心功能所必需的算法，反之即为非核心算法。从复杂性角度可分为简单算法和复杂算法，前者原理简单明确或基于成熟公式，后者通常基于模型研究，存在诸多假设条件且影响因素较多，同时二者在算法规模、参数数量、运算速度等方面亦存在差异。从可解释性角度可分为白盒算法和黑盒算法，前者可与现有知识建立关联，后者难与现有知识建立关联，前者可解释性优于后者。关于算法在自研软件研究报告中要明确算法类型、工作原理、临床用途，成熟算法还需要给出相关文献。全新算法需要给出相关验证。最常见的就是企业技术人员经过多次流动导致无法给出完整的信息，甚至可能工作原理都不知道怎么去描述。所以监管过程会注重企业人员流动情况，重点查看开发、测试、维护人员的履历和人员流动后管理流程如人员离职后权限的回收注销、技术成果的交接程序和记录。

8.3软件用途

软件用途通常可分为辅助决策和非辅助决策，其中辅助决策是指通过提供诊疗活动建议辅助用户（如医务人员、患者）进行医疗决策，如病灶特征识别、病灶性质判定、用药指导、制定治疗计划等，相当于用户的“助手”；反之，仅提供医疗参考信息而不进行医疗决策即为非辅助决策，包括流程优化、诊疗驱动，前者如诊疗流程简化等，后者如测量、分割、三维重建等，相当于用户的“工具”。同时，辅助决策和非辅助决策从实时性角度均可细分为实时和非实时，前者风险通常高于后者。故软件功能从软件用途角度又可分为辅助决策类功能和非辅助决策类功能、实时功能和非实时功能。

关于软件用途（理解为预期用途）独立软件按软件用途，软件组件则根据医疗器械产品的预期用途一致。

九、基本原则

9.1软件特性

15版本内几乎没有提到软件特性的内容，22版讲解了软件的特性，没有物理实体、软件测试不能穷尽、软件缺陷无法避免且不能除根、更新频繁且迅速、细微更新可能导致严重后果、存在累积效应和退化问题，结合更多软件专业的内容，使医疗器械软件的科学面又拓宽了，监管的内容又增加了。综合考虑风险管理、质量管理和软件工程的要求才能保证软件的安全有效性。注册申请人需基于软件风险程度，采用良好软件工程实践完善质量管理体系，针对算法、接口、更新、异常处理等软件召回主要原因，尽早、重点、全面开展软件质量保证工作。

9.2风险导向—软件安全性级别

软件安全性级别可结合软件的预期用途、使用场景、核心功能进行综合判定 。其中，预期用途主要考虑软件的用途类型（如治疗、诊断、监护、筛查）、重要程度（如重要作用、参考作用、补充作用）、紧迫程度（如危重情形、严重情形、普通情形）、成熟程度（成熟、全新）等因素，使用场景主要考虑软件的使用场所（如门诊、手术、住院、急救、家庭、转运、公共场所）、疾病特征（如严重性、紧迫性、传染性）、适用人群（如成人、儿童、老人、孕妇）、目标用户（如医务人员、患者）等因素，核心功能主要考虑软件的功能类型（如重要程度、技术特征、复杂程度、成熟程度）、核心算法（如重要程度、复杂程度、可解释性、成熟程度）、输入输出（输入数据如医学图像、生理参数、体外诊断等数据，输出结果如处理、测量、分析等结果）、接口（如应用程序接口（API）、数据接口、产品接口）等因素。

在软件安全性级别的判定上，除了上述的判定外还会有部分工作指导文件/制度明确给出软件的级别，一般这都是风险较高的产品如除颤仪（体外自动/半自动除颤仪）在《体外除颤产品注册技术审查指导原则》则明确标出“参考《医疗器械软件注册技术审查指导原则》的要求，应按照C级安全性级别来提供软件描述文档”。大家不管是编写质量管理体系设计开发文件还是编写注册申报资料一定要结合产品相关的所有的法规、标准全方位的考虑产品遵守的法规标准。否则法不对位，所有白费。

9.3全生命周期质控

重中之重：上市前开展充分有效的软件验证与确认活动，识别软件可预见的风险并将其降至可接受水平。上市后继续开展软件质量保证工作，结合用户投诉、不良事件和召回等情况识别前期未预见的风险，并采取必要措施保证软件质量；同时，基于软件更新需求的评估，实施软件更新活动以满足用户新需求，并开展与之相适宜的软件验证与确认活动，以保证软件更新质量；此外，软件停运考虑用户告知与后续服务、数据迁移、患者数据与隐私保护等要求。软件的发补近期发补内容越来越多，也越来越细致，之前经历过被发补补充软件版本命名规则、补充软件规格型号、补充技术要求未检测/漏检检验报告等这些比较显眼的内容，现在发补的内容比较精细了如补充产品工作原理，确定产品功能模块的作业，补充竞品信息，要求提供软件效期论证、有载体的需要按包装验证标准提供相关验证报告、补充系统测试报告维护性测试用例等等。审核老师越来越专用，越来越深入研究，所以企业必须同步学习共同进步，否则就被吊打的状态。

9.4现成软件

旧版已明确，新版又重申了，可见现成软件对产品的影响还是很大的，根据本指导原则要求，我们对现成软件需进行管理，很多企业只管给个《现成软件的管理规程》却忘了这些现成软件的采购，关于采购可加入在《采购控制程序》也可以单拎出来《现成软件采购管理规程》，只要有如何分类、供应商审核再评价、如何进行验收确认、记录怎么处置，不管是在《采购控制程序》还是《现成软件采购管理规程》都可以，只要不忘就行。