医疗器械软件注册申报资料指导原则（最新版）

本指导原则旨在指导生产企业规范医疗器械软件生存周期过程和准备医疗器械软件注册申报资料，同时规范医疗器械软件技术审评要求，为医疗器械软件和质量管理软件的体系核查提供参考。
本指导原则是对医疗器械软件的一般性要求，生产企业应根据医疗器械软件特性提交注册申报资料，判断本指导原则具体内容的适用性，不适用内容详述理由。生产企业亦可采用其他符合法规要求的替代方法，但应提供详尽研究资料。
本指导原则基于当前认知水平和技术能力，在现行法规体系下参考国外法规与指南、国际标准与技术报告予以制定。随着认知水平和技术能力的不断提高以及法规体系的不断完善，相关内容也将适时修订。
本指导原则作为生产企业、审评人员和检查人员的指导性文件，不包括审评审批所涉及的行政事项，亦不作为法规强制执行，应在符合法规要求的前提下使用本指导原则。
本指导原则针对软件特殊性，在现行法规体系下进一步明确医疗器械软件监管要求。本指导原则是医疗器械软件的通用指导原则，其他涉及软件的医疗器械指导原则可在本指导原则基础上进行有针对性的调整、修改和完善。
一、适用范围
本指导原则适用于医疗器械软件的注册申报，包括第二、三类独立软件和含有软件组件的医疗器械；适用于自研软件、现成软件的注册申报。
本指导原则也可用作医疗器械软件、质量管理软件体系核查的参考。
二、软件基础
（一）医疗器械软件
医疗器械软件包括本身即为医疗器械的软件或者医疗器械内含的软件，前者即医疗器械独立软件（以下简称独立软件），后者即医疗器械软件组件（以下简称软件组件），详见图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. 软件组件
软件组件控制功能、前处理功能的临床评价通常与所属医疗器械进行整体评价。后处理功能临床评价可参照独立软件要求，亦可随所属医疗器械进行整体评价。
专用型独立软件视为软件组件的临床评价与软件组件后处理功能要求相同。
（三）网络安全
医疗器械网络安全需从信息安全角度综合考虑医疗器械的网络安全和数据安全。医疗器械软件若具备电子数据交换、远程控制或用户访问控制功能，均应考虑网络安全问题，具体要求详见医疗器械网络安全相关指导原则，包括网络安全更新、软件版本命名规则、网络安全研究资料等要求。
（四）云计算
云计算在医疗器械行业的应用日益增多，虽然其具有降低信息化成本、减少重复建设、提高资源利用率、增加业务灵活性、提升服务专业性等优势，但是也存在着用户对数据控制能力减弱、服务可持续性降低、数据所有权面临挑战、数据保护困难、数据残留难以处理、用户与云服务商责任不清、产生司法管辖权问题、面临网络安全威胁等风险，因此生产企业需权衡使用云计算的收益和风险。
云计算可视为现成软件，云服务商即供应商，因此生产企业可参照现成软件和供应商相关要求，考虑云计算的需求分析、风险管理、验证与确认、维护计划等活动要求。
需求分析需考虑云计算的技术特征、云服务商的选择问题。云计算技术特征包括服务模式、部署模式、配置情况、核心功能、数据接口、网络安全保证等方面，其中服务模式分为软件即服务（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：自研软件完善型更新研究报告框架

条款		轻微	中等	严重
基本信息	软件标识	明确申报版本软件情况，详述变化。
	安全性级别	明确申报版本软件情况，若改变详述理由并按新安全性级别提交注册申报资料。
	结构功能	明确申报版本软件情况，详述变化。
	物理拓扑	明确申报版本软件情况，详述变化。
	运行环境	明确申报版本软件情况，详述变化。
	注册历史	明确申报版本软件情况。
实现过程	开发概况	明确申报版本软件情况。
	风险管理	依据流程图详述软件风险管理过程，提供软件更新部分的风险分析报告、风险管理总结报告。
	需求规范	提供软件更新部分的需求规范文档。
	生存周期	概述软件维护过程、软件配置管理过程。	依据流程图详述软件维护过程、软件配置管理过程。	依据流程图详述软件维护过程、软件配置管理过程，提供软件更新部分的设计历史文档集索引表，软件编码规则文档。
	验证与确认	提供回归测试计划与报告。	概述软件维护过程质量保证活动，提供回归测试计划与报告。	依据流程图详述软件维护过程质量保证活动，提供回归测试计划与报告。
	可追溯性分析	依据流程图详述软件可追溯性分析过程，提供软件更新部分的可追溯性分析报告。
	缺陷管理	概述软件缺陷管理过程，明确申报版本软件已知缺陷总数和剩余缺陷数。	依据流程图详述软件缺陷管理过程，明确申报版本软件已知缺陷总数和剩余缺陷数，列明已知剩余缺陷的内容、影响、风险，确保风险均可接受。
	更新历史	明确软件版本命名规则、发布版本、完整版本，列明前次注册以来历次软件更新的完整版本、日期、类型。	明确软件版本命名规则、发布版本、完整版本，列明前次注册以来历次软件更新的完整版本、日期、类型、具体内容。	明确软件版本命名规则、发布版本、完整版本，列明首次注册以来历次软件更新的完整版本、日期、类型、具体内容。
核心功能		列明软件更新部分的核心功能情况。	列明软件更新部分的核心功能情况，全新的核心功能、核心算法、预期用途均需提供安全有效性研究资料。
结论		概述软件更新实现过程的规范性以及相应核心功能的正确性，判定申报版本软件的安全有效性是否满足要求。