近日，北京市药品监督管理局关于对《第二类医疗器械独立软件技术审评规范（征求意见稿）》公开征集意见，内容如下：

 

第二类医疗器械独立软件技术审评规范

（征求意见稿）

 

本审评规范旨在规范第二类医疗器械独立软件（以下简称独立软件）的技术审评，同时也用于指导注册申请人提交独立软件注册申报资料的准备及撰写。

 

本审评规范是对技术审评主要关注点的具体要求，应在现行已发布的《医疗器械软件注册审查指导原则（2022年修订版）》、《医疗器械网络安全注册审查指导原则（2022年修订版）》、《移动医疗器械注册技术审查指导原则》等相关指导原则的基础上使用。如有能够满足相关法规要求的其他方法，也可以采用，但需要提供详细的研究资料和验证资料。

 

本审评规范是在现行法规、标准体系以及当前科技能力、认知水平下制定的。随着法规、标准的不断完善，以及科技能力、认知水平的不断提高，相关内容也将适时进行修订。

 

一、适用范围

 

本审评规范适用于独立软件的注册申报，在《医疗器械分类目录》中分类编码为21医用软件，医疗器械软件组件可参照相关适用内容。

 

二、技术审查要点

 

（一）产品名称

 

产品命名应符合《医疗器械通用名称命名规则》、《医用软件通用名称命名指导原则》的要求。通用名称按“特征词1（如有）+特征词2（如有）+特征词3（如有）+核心词”结构编制。核心词是对具有相同或者相似的预期用途的软件的概括表述，如“处理软件”、“分析软件”等。特征词从使用部位、处理对象、技术特点、适用场景等方面展开。特征词不超过3个。

 

（二）产品结构及组成

 

结构及组成至少应包括产品架构、交付内容和功能模块，交付形式不在结构及组成中体现。

 

产品架构应描述产品的技术架构，如单机、C/S 架构、B/S 架构、混合式架构（兼具 C/S、B/S 架构）。

 

交付内容一般包括软件安装程序、授权文件、外部软件环境安装程序等软件程序文件。功能模块包括单机或客户端、服务器端（若适用）、云端（若适用），若适用注明选装、模块版本。

 

（三）产品适用范围

 

产品适用范围一般基于预期用途、使用场景、核心功能予以规范，若适用分述各功能模块的适用范围。同时保证用语的规范性，区分“分析”与“测量”、“手术模拟”与“手术计划”（牙科、耳鼻喉类），使用“显示”、“接收”而非“浏览”、“采集”。

 

产品具有图像处理功能的，应在适用范围中明确主要的处理功能，如自动测量、三维重建等。

 

独立软件中出现部分非医疗用途功能（如教学、语音及视频聊天等），应尽量通过模块化设计予以拆分，若在技术上无法拆分，需将非医疗器械功能作为医疗器械软件的组成部分予以整体考虑。部分由通用设备（如电脑、手机等）或其他非医疗器械产生的数据，如用于医疗目的（基于相应的医疗指南或专家共识等），可按照医疗器械数据进行规范。非医疗器械功能不应体现在产品适用范围中。

 

申报软件的适用范围需与申报产品的性能、功能相符，并与非临床研究/临床评价资料结论相一致。

 

（四）产品工作原理

 

1.核心算法

 

应结合产品的核心功能介绍产品核心算法，核心算法应按照处理顺序逐项说明。如产品核心功能使用第三方组件，注册申请人应提供对第三方组件的成熟度评价。如产品具有全新算法，注册申请人应注明相关功能并提供算法研究报告。

 

2.功能

 

功能应详细阐述产品技术要求中列明的功能及可拆分的非医疗器械功能（如适用）。如功能中包含不可拆分的非医疗器械功能，应对无法拆分的原因进行说明，描述非医疗器械功能对于医疗器械软件的影响，同时分析其可能产生的风险。如功能中包含可拆分的非医疗器械功能，应对耦合性进行说明。

 

3.体系结构

 

体系结构应采用适当的形式给予说明（如分层架构图），详述图示软件模块（即组成模块）的功能、用途、接口以及必备软件、云计算等情况，并对涉及到的必备软件、外部软件环境相关软件用途进行说明。

 

4.用户界面

 

产品图示应结合用户界面关系图与界面图示共同说明，应体现产品的总体操作逻辑，如医疗器械功能的组合路径或调用关系，且应与其他申报资料保持一致。如申报产品具备报告功能，应关注输出报告的具体内容。

 

5.物理拓扑

 

物理拓扑应采用适当的形式给予说明，应明确数据流向与数据内容，同时应包含与其连接的全部设备，如CT机。

 

产品描述模板详见附录1。

 

（五）产品风险管理资料

 

依据GB/T 42062-2022《医疗器械风险管理对医疗器械的应用》及YY/T 1406.1-2016《医疗器械软件 第1部分 YY/T 0316 应用于医疗器械软件的指南》，提供产品风险管理报告。

 

申请人需重点说明：申报产品的研制阶段已对有关可能的危害及产生的风险进行了估计和评价，针对性地实施了降低风险的技术和管理方面的措施。产品性能测试对上述措施的有效性进行了验证，达到了通用和专用标准的要求。申请人对所有剩余风险进行了评价，全部达到可接受的水平。产品风险分析资料需为申请人关于产品安全性的承诺提供支持。

 

风险管理报告一般包括以下内容：

 

1.1申报产品的风险管理组织。

 

1.2申报产品的组成。

 

1.3申报产品符合的安全标准。

 

1.4申报产品的预期用途，与安全性有关的特征的判定。

 

1.5申报产品的全部可能危害。

 

1.6对所判定危害采取的控制措施。

 

1.7对采取控制措施后的剩余风险进行的估计和评价。

 

（六）产品技术要求

 

产品技术要求应重点审查以下几方面内容：

 

1.软件版本命名规则

 

软件版本命名规则中各字段含义应明确且无歧义无矛盾，能够区分重大软件更新和轻微软件更新，保证软件更新的版本变更符合软件版本命名规则要求。各字段含义应进行举例说明。适用时，版本命名规则需考虑医疗器械网络安全指导原则等相关指导原则及要点的要求。

 

2.功能

 

产品功能应涵盖产品说明书（以下简称说明书）中对应的供用户调用的全部医疗器械功能（含安全功能），其中对于医学图像、生理参数、体外诊断等数据的测量、处理、模型计算、分析等医疗器械功能应进行详细说明。

 

技术要求上不应包含可拆分的非医疗器械功能，对于不可拆分的非医疗器械功能简述功能即可。

 

功能描述应具体准确，如图像的测量功能应明确测量的具体内容（角度、长度、面积等）。

 

3.接口

 

明确软件供用户调用的应用程序接口（API）、数据接口（含传输协议、存储格式，如DICOM、HL7、JPG、PNG、私有协议与格式）、产品接口（可联合使用的其他医疗器械独立软件、医疗器械硬件产品）。

 

其中数据接口应包含外部获取信息接口，对外输出信息接口以及内部不同实体间（如适用）的接口。

 

4.运行环境

 

运行环境应明确软件正常运行所需的典型运行环境，包括硬件配置（含处理器、存储器、外设器件）、外部软件环境（列明全部软件的名称、完整版本、补丁版本，使用“兼容版本”而非“以上版本”、“更高版本”）、网络条件（含网络架构、网络类型、网络带宽），涵盖客户端、服务器端（若适用）、云端（若适用）要求。无需重复描述必备软硬件。

 

典型环境并非最低配置，一般硬件设备应避免使用“及以上”等描述。

 

5.性能效率

 

性能效率应明确软件在典型运行环境（含云计算）下完成典型核心功能的时间特性，若适用明确规定性能效率下的资源利用性、容量。

 

典型功能的处理对象如对性能效率产生影响，应明确处理对象的规格，如图像处理类，推荐使用512×512重建矩阵、含有2 幅影像的CT序列。

 

6.最大并发数

 

最大并发数应明确软件在典型运行环境（含云计算）下的实施典型并发操作的最大并发用户数和/或患者数，注明相应响应时间。

 

典型操作不应只有登录操作，还应包含主要的医疗器械功能，如PACS中的影像加载。

 

最大并发数的响应效率应考虑缓存的影响，应说明不受缓存影响下的响应时间，并在检验方法明确具体操作；如提供的响应时间受到缓存影响应进行说明。

 

产品技术要求模板详见附录2。

 

（七）软件研究

 

1. 自研软件研究报告

 

注册申请人应依据《医疗器械软件注册审查指导原则（2022年修订版）》提交软件研究资料（含现成软件研究资料、互操作性研究资料、GB/T 25000.51-2016检测报告等），软件安全性级别通常为中等。

 

如GB/T 25000.51-2016 检测报告为自测，应按照GB/T 25000.51-2016第6章、第7章提供相应证明及过程资料。

 

如产品具有全新算法，注册申请人应提交算法研究报告。算法研究报告通常包括算法基本信息、算法风险管理、算法需求规范、算法质控要求、算法验证与确认、算法可追溯性分析、结论等内容。如产品使用数据资源（如参考数据库）明确数据种类以及每类数据的样本量、数据分布等情况。

 

如产品未使用全新算法，但具有非流程性的复杂处理功能，如器官分割，原则上应提交证明产品可满足临床应用要求的验证资料。

 

自研软件研究报告模板详见附录3。

 

2.网络安全研究资料

 

注册申请人应依据《医疗器械网络安全注册审查指导原则（2022年修订版）》提交网络安全研究资料，网络安全的安全性级别通常为中等。

 

如软件产品按照B/S架构开发，但声称按照单机的网络架构使用，需在网络安全研究资料中的适当位置进行说明，并在说明书中明确相应要求，如禁止网络连接、关闭访问端口等。

 

如产品的网络类型为局域网，但涉及敏感信息的存储，应考虑系统性数据被窃取的风险，如局域网内使用的PACS产品，未添加任何防护措施，可能导致所有影像数据被窃取的风险。

 

如产品的网络类型为广域网，应提供渗透测试报告；外部软件环境应具备持续更新的能力，并在软件研究资料中提供相应资料，满足网络安全要求，并在说明书及其他相应资料中明确相应要求。

 

  5.其他资料

 

产品若采用移动计算、云计算、虚拟现实等信息通信技术实现预期功能与用途，应关注相应的研究资料。

 

网络安全研究资料模板详见附录4。

 

（八）产品说明书和标签样稿

 

说明书、标签和包装标识需符合《医疗器械说明书和标签管理规定》、《医疗器械软件注册审查指导原则（2022年修订版）》、《医疗器械网络安全注册审查指导原则（2022年修订版）》等相关标准的规定。

 

1.说明书

 

说明书需体现软件的功能、使用限制、输入输出数据类型（如：CT、MRI、US）、必备软硬件、最大并发数、接口、访问控制、运行环境（如适用）、性能效率（如适用）等信息，明确软件发布版本。

 

其中，软件功能包括全部核心功能（含安全功能），注明选装、自动功能，其中测量功能明确测量准确性指标，图形学测量功能还需提供关于测量准确性的警示信息，数据资源明确数据种类和每类数据的样本量。接口逐项说明每个供用户调用软件接口的预期用户、使用场景、预期用途、技术特征、使用限制、故障应对措施。

 

软件功能中对于可拆分的非医疗器械功能应予以删除或注明为非医疗器械功能，对于不可拆分医疗的非医疗器械功能应注明为非医疗器械功能。

 

说明书提供网络安全说明和使用指导，明确用户访问控制机制、电子接口（含网络接口、电子数据交换接口）及其数据类型和技术特征、网络安全特征配置、数据备份与灾难恢复、运行环境（含硬件配置、外部软件环境、网络环境，如适用）、安全软件兼容性列表（如适用）、外部软件环境与安全软件更新（如适用）、现成软件清单（SBOM，如适用）等要求。

 

2.标签样稿

 

对于物理交付方式，产品标签应符合相应规定。对于网络交付方式，提交产品网络交付页面照片。

 

此外，建议在“关于”或“帮助”等软件用户界面体现产品注册信息。

 

（九）产品变更

 

1.产品更新

 

软件更新分为：

 

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

 

（2）轻微软件更新：不影响医疗器械安全性与有效性的增强类更新、纠正类更新，包括轻微增强类软件更新、纠正类软件更新，通过质量管理体系进行控制，原则上无需申请变更注册，待下次变更注册时提交相应注册申报资料，但若涉及技术要求内容变化也应申请变更注册。

 

2.更新资料要求

 

2.1 软件研究资料

 

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

 

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

 

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

 

3）仅发生纠正类软件更新：适用于自研软件仅发生纠正类更新的情形，此时提交自研软件纠正类更新研究报告；

 

4）未发生软件更新：出具真实性声明，明确对此承担法律责任。

 

2.2. 产品技术要求

 

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

 

2.3．说明书

 

若适用，提交说明书变化情况说明。

 

2.4. 产品标签样稿

 

若适用，提交申报产品的产品标签样稿及其变化情况说明。

 

三、审查关注点

 

审查中需重点关注以下几个方面：

 

（一）本规范适用于独立软件产品注册审查。该产品管理类别为II类，分类编码为21医用软件。

 

（二）产品技术要求性能指标是否清晰明确。

 

（三）说明书中必须告知用户的信息是否完整，如应明确本产品预期使用的环境、适用人群和限制使用的情况。

 

（四）产品的预期用途，从医疗器械注册申请表、产品综述资料、风险管理报告、产品使用说明书、临床评价资料等方面阐述的是否一致。是否明确了产品的适用人群，以及使用场所。

 

四、参考文献

 

[1]国家市场监督管理总局.医疗器械注册与备案管理办法:国家市场监督管理总局令第47号[Z].

 

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

 

[3]国家食品药品监督管理局.医疗器械通用名称命名规则:国家食品药品监督管理总局令第19号[Z].

 

[4]国家药品监督管理局.医疗器械注册申报资料要求和批准证明文件格式:国家药监局公告2021年第121号[Z].

 

[5]国家食品药品监督管理局.医疗器械分类目录:国家食品药品监督管理总局公告2017年第104号[Z].

 

[6]国家药品监督管理局.医疗器械产品技术要求编写指导原则:国家药监局通告2022年第8号[Z].

 

[7]国家药品监督管理局医疗器械审评中心.医疗器械网络安全注册审查指导原则（2022年修订版）:国家药监局器审中心通告2022年第7号[Z].

 

[8]国家药品监督管理局医疗器械审评中心.人工智能医疗器械注册审查指导原则:国家药监局器审中心通告2022年第8号[Z].

 

[9]国家药品监督管理局医疗器械审评中心.医疗器械软件注册审查指导原则（2022年修订版）:国家药监局器审中心通告2022年第9号[Z].

 

[10]国家药品监督管理局医疗器械审评中心.移动医疗器械注册技术审查指导原则:国家药监局器审中心通告2017年第222号[Z].

 

[11]GB/T 42062-2022,医疗器械 风险管理对医疗器械的应用[S].

 

[12]GB/T 25000.51-2016,软件工程 软件产品质量要求与评价(SQuaRE)商业现货(COTS)软件产品的质量要求和测试细则[S].

 

[13]YY/T 0664-2020,医疗器械软件 软件生存周期过程[S].

 

[14]GB/T 42984.1-2023,健康软件 第1部分：产品安全的通用要求[S].

 

[15]YY/T 1861-2023,医学影像存储与传输系统软件专用技术条件[S].

 

[16]YY/T 1862-2023, 冠状动脉CT影像处理软件专用技术条件[S].

 

[17]YY/T 1843-2022, 医用电气设备网络安全基本要求[S].

 

附录1产品描述模板

 

产品描述

1. 器械及操作原理描述

1.1 产品工作原理

1.1.1核心算法

提供支持的DICOM服务及实现方式（如适用）。

提供其他核心功能的工作原理（如适用）。

注：核心算法如涉及处理顺序，请对顺序进行说明，并按照处理顺序逐项说明; 如核心功能为全新算法，应注明相关功能并提供算法研究报告; 如产品核心功能使用第三方组件，注册申请人应提供对第三方组件的成熟度评价; DICOM相关功能使用的不是第三方组件，应提供DICOM符合性声明，及提供完整测试记录的。

1.1.2产品功能

说明产品全部功能。

注：功能应涵盖说明书中对应的供用户调用的全部功能（含安全功能）; 对于医学图像、生理参数、体外诊断等数据的测量、处理、模型计算、分析等医疗器械功能应进行详细说明; 如产品功能包含非医疗器械功能，应对无法拆分的原因提供说明，描述非医疗器械功能对于医疗器械软件的影响，同时分析其可能产生的风险。

1.1.3体系结构

提供适用的体系架构图（如分层架构），以及架构图实现产品功能的相关说明。

1）体系架构图请区分医疗器械软件、必备软件、外部软件环境。

2）若适用，组成模块和功能模块均需注明选装。

3）提供必备软件、外部软件环境相关软件用途说明，如必备软件、外部软件环境在体系结构图上不方便进行体现，可只以文字进行说明。

1.1.4用户界面

1）提供用户界面关系图。

2）说明界面与功能的对应关系，界面应提供全部的功能。

3）说明产品正常使用时，医疗器械功能界面各种可能组合的路径。

4）依据主要界面图/图示（如原始图片不清晰提供图示）详述界面的布局、选项、功能，说明当前界面的进入方式、输入项与输出项。

5）如适用，提供软件输出报告样张，就输出报告的具体内容进行描述。

注：此处描述为主要界面并非主界面，技术要求部分与研究报告可只说明主界面。

1.1.5物理拓扑

1）基于软件设计规范文档提供软件的物理拓扑图，并进行详细说明，物理拓扑图应体现数据流向及数据内容，可参考《医学图像存储与传输软件（PACS）注册审查指导原则（2024年修订版）》中的“图二 物理拓扑示意图”。

2）物理拓扑图应展现软件/组成模块、通用计算平台、医疗器械硬件产品/部件、必备软件之间的物理连接关系，包括全部外围设备。

1.1.6其他资料

1）若适用，请说明与其他系统（如HIS等）的通信方式（如协议、接口等），若采用接口请说明对接方式，以及所需的信息列表。

2）若适用，请说明如何更改Logo。

3）若适用，请说明如何更改报告模板。

1.2 结构及组成

1）交付内容: 包括软件安装程序、授权文件、外部软件环境安装程序等软件程序文件。

注：可不再体现交付形式

2）产品架构：如单机（客户端）、CS架构、BS架构、混合式架构（兼具CS、BS架构））。

3）功能模块：包括客户端、服务器端（如适用）、云端（如适用），如适用注明选装、模块版本。

注：模块功能请与技术要求保持一致。

4）预期规模（PACS适用）：如单机PACS、科室级PACS、院级PACS和区域级PACS等。

1.3 区别于其他同类产品的特征

依实际情况填写，如无明显特征可写无。

2. 型号规格

1）如只有一个型号，与申请表一致。

2）如有多个型号，采用对比表或带有说明性文字的图片、图表，描述各种型号规格的结构及组成（或配置）、功能、产品特征和运行模式、技术参数等内容。

3. 包装说明

1）若产品采用物理交付的形式，应提供下列信息：

a) 包装材料/材质

b) 包装清单

c) 包装图纸、照片

2）若产品采用网络交付的形式，提交产品网络交付页面照片，该页面的产品注册信息应符合相应规定。

4. 研发历程

依实际情况填写（阐述注册产品的研发背景和目的）。

5. 同类产品的参考和比较

1）参考原因

2）列表对比

列表对比应说明申报产品与同类产品和/或前代产品在工作原理、结构及组成、制造材料、性能指标、作用方式，以及适用范围等方面的异同。

 

附录2产品技术要求模板

 

医疗器械产品技术要求

 

医疗器械产品技术要求编号：

 

××××××软件

 

1.产品型号/规格及其划分说明

1.1软件型号规格

型号规格：明确软件的型号/规格，无需体现软件发布版本。

1.2软件发布版本

软件发布版本：明确软件发布版本。

1.3 软件版本命名规则

明确软件完整版本全部字段的位数、范围、含义，若软件模块（含医用中间件）单独进行版本控制亦需提供其版本命名规则，并明确与软件版本命名规则的关系。软件和软件模块的版本命名规则均需与质量管理体系保持一致。

注：软件版本命名规则需注明“完整版本”的全部字段及字段含义; 软件完整版本应涵盖软件更新全部类型，字段含义明确且无歧义无矛盾，能够区分重大软件更新和轻微软件更新，保证软件更新的版本变更符合软件版本命名规则要求; 考虑《医疗器械软件注册审查指导原则》、《医疗器械网络安全注册审查指导原则》中关于重大、轻微变更的界定要求。

2.性能指标

注：性能指标可以不适用，但不应有空缺部分，不适用部分应在非临床资料中单独提供详细说明; 性能指标应可测试、可验证如指标在不同典型测试环境有区别应分别要求(PC端、移动端)。

2.1 通用要求

2.1.1 功能

依据说明书和用户界面明确软件供用户调用的全部医疗器械功能（含安全功能）纲要，注明选装、自动功能，其中客观物理测量功能应明确测量准确性指标，数据资源（如参考数据库）明确数据种类和每类数据的样本量。若核心功能相同但核心算法类型不同，则每类核心算法均需备注。

技术要求中不应包含可拆分的非医疗器械功能，对于不可拆分的非医疗器械功能简述功能即可。

功能描述应具体准确，如图像的测量功能应明确测量具体内容，且功能描述尽量不要用“主要”“等”“大概”字眼。

不同算法类型的医疗器械功能应进行说明。

2.1.2 使用限制

依据说明书明确软件的用户使用限制和技术限制。

可包括如下使用限制：

用户使用限制包括用户使用或管理的数据的长度、数量、句法条件等客观约束，如登录名和密码格式限制，导入导出文件格式要求。

技术限制包括样本的大小、参数的限制值、处理图像数据的限制，如CT影像的层厚、管电流管电压、分辨率。

2.1.3 输入输出

明确软件的输入数据类型（如医学图像、生理参数、体外诊断等数据）、输出结果类型（如处理、测量、分析等结果）。

注：需要与数据接口中数据类型相对应。

2.1.4 接口

明确软件供用户调用的应用程序接口（API）、数据接口（含传输协议、存储格式，如DICOM、HL7、JPG、PNG、私有协议与格式）、产品接口（可联合使用的其他医疗器械独立软件、医疗器械硬件产品）。

如适用，应明确产品支持的 DICOM 服务（如DICOM Query/Retrieve、DICOM Work List、DICOM Storage 、DICOM Storage Commitment、DICOM Print、DICOM MPPS）。

数据接口应包含以下三种实体接口类型：

a) 外部获取信息接口，如从数据库、文件、其他程序api获取数据。

b) 对外输出接口，如输出报告文件、向数据库写入数据。

c) 内部不同实体间的接口，如服务器与客户端通信。

描述应具体，包括涉及协议、存储格式、预期目的等信息，如：客户端通过HTTPS协议与服务器连接，进行影像数据传输，数据存储格式为.dcm。

2.1.5 必备软硬件

明确软件正常运行所必需的其他的医疗器械独立软件（名称、型号规格、发布版本）及医用中间件（名称、型号规格、发布版本）、医疗器械硬件产品（名称、型号规格）。

注：非医疗硬件、软件不属于必备软硬件。

2.1.6 运行环境

明确软件正常运行所需的典型运行环境，包括硬件配置（含处理器、存储器、外设器件）、外部软件环境（列明全部软件的名称、完整版本、补丁版本，使用“兼容版本”而非“以上版本”、“更高版本”）、网络条件（含网络架构、网络类型、网络带宽），涵盖客户端、服务器端（若适用）、云端（若适用）要求。无需重复描述必备软硬件。

外部软件环境包括系统软件、通用应用软件、通用中间件、支持软件; 网络架构如BS架构、CS架构、混合架构等; 网络类型如广域网、局域网、个域网。

2.1.7 性能效率

明确软件在典型运行环境（含云计算）下完成典型核心功能的时间特性，若适用明确资源利用性、容量。

典型功能的处理对象如对性能效率产生影响，应明确处理对象的规格，如图像处理类，推荐使用512X512重建矩阵、含有2 幅影像的CT序列。

2.1.8 最大并发数

明确软件在典型运行环境（含云计算）下的实施典型并发操作的最大并发用户数和/或患者数，注明相应响应时间。

典型操作不应只有登录操作，还应包含主要的医疗器械功能，如PACS中的影像加载。

最大并发数的响应效率应考虑缓存的影响，应说明不受缓存影响下的响应时间，如响应时间受到缓存影响应进行说明。

2.1.9 用户界面

明确软件的用户界面类型和用户输入类型。

2.1.10 消息

明确软件向用户提供的消息类型和形式。

形式通常包括：弹出框、提示音、进度条、颜色突出等方式，类型通常包括：确认、提示、警告和错误分类。

2.1.11 用户差错防御

明确软件对导致严重后果的用户操作错误的防御能力。

注：用户差错防御应对的应当是用户的主动行为，如影像文件传输过程中的关闭，可进行提醒确认，以及支持断点续传。

2.1.12 访问控制

明确软件的用户身份鉴别方法、用户类型及用户访问权限。

用户登陆软件的方式通常包括：用户名和口令、个人密钥、生物特征技术等。

示例：软件采用用户名和密码的方式登陆，用户类型包含普通用户和管理员，用户和管理员的权限分别列出。

2.1.13 版权保护

明确软件的版权保护技术及其对软件正常使用的影响。

通常采用：注册码，license，硬件加密狗等。

2.1.14 可靠性

明确软件出错的数据保存、恢复及继续运行能力。

数据备份和恢复能力包括：软件出错后（自身错误、网络中断、资源紧张、服务器宕机）异常消除后能否正常运行，数据丢失情况。

2.1.15 维护性

明确软件向用户提供的维护功能和维护信息类型。

包括对系统资源适用情况的监测，日志，警告屏，异常信息提示，软件本身的配置管理功能，用户管理、系统管理等。

2.2专用要求（若适用）

注：依据专用标准（名称、发布年份）适用条款逐条描述

2.3安全要求（若适用）

注：明确安全标准名称和发布年份

2.3.1 YY 9706.108-2021（若适用）

……

软件如涉及报警功能应考虑YY 9706.108-2021的适用性。

3.检验方法

3.0 依据检测单元分述软件测试环境（与典型运行环境等同）。

3.1通用要求符合性检验

通过检查说明书、实际操作、软件测试等方法逐条说明2.1各条款的检验方法，并验证2.1各条款的符合性。

若核心功能相同但核心算法类型不同，则每类核心算法所对应的核心功能均需检测（检测对象为核心功能而非核心算法）。

注：建议在技术要求中提供具体明确且能满足可复现要求的检验方法。

3.2 专用要求检验方法（若适用）

3.3 安全要求检验方法（若适用）

3.3.1 依据 YY 9706.108-2021的方法进行检验（若适用）。

……

4.术语 

注：明确软件所用专业术语（缩写）含义

举例：

4.1 DICOM 3.0标准

即医学数字成像和通信（Digital Imaging and Communication of Medicine - DICOM），是医学图像和相关信息的国际标准。它定义了质量能满足临床需要的可用于数据交换的医学图像格式。

即标准化的卫生信息传输协议，是医疗领域不同应用之间电子传输的协议。

（分页）

附录

1) 体系结构图

2) 用户界面关系图与主界面图示

3) 物理拓扑图

 

附录3自研软件研究报告模板

 

自研软件研究报告

1.基本信息

1.1软件标识

软件的名称：

型号规格：

发布版本：

HASH值:（如MD5值）

注册申请人:

设计开发地址:

现成软件组件：

1.2安全性级别

软件的安全性级别：

注：从风险角度建议独立软件的安全性级别至少为中等。

判定理由：

1)结合软件的预期用途、使用场景、核心功能进行综合判定

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

3)亦可参考已上市同类医疗器械软件的不良事件和召回情况进行判定，即已上市同类医疗器械软件若发生严重不良事件或一级召回属于严重级别，发生不良事件或二级召回属于中等级别，未发生不良事件且仅发生三级召回或无召回属于轻微级别。

 

1.3结构功能

1.3.1体系结构图

此处应在技术要求的基础上注明各组成模块的安全性级别。

1.3.2用户界面关系图与主界面图示

此处应与技术要求附录一致。

1.3.3功能详述

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

1.3.4 接口相关信息

表1 接口描述信息

 

接口名称   接口信息
接口描述
预期用户
使用场景
预期用途
技术特征
使用限制
故障应对措施

 

注：技术要求中的接口均应在此处说明;技术特征包括但不限于连接对象、信息内容、通信协议、性能指标、网络安全保证等要求;使用限制需考虑每个软件接口的预期用户范围、连接要求。

1.3物理拓扑

在技术要求附录要求的基础上描述每个数据场景\流向下的接口、功能模块、用途等相关信息。

1.5运行环境

1.5.1硬件配置

此处应技术要求保持一致。

1.5.2外部软件环境

此处应与技术要求保持一致。

1.5.3必备医疗器械软件

此处应与技术要求保持一致。

1.5.4网络条件

此处应与技术要求保持一致。

1.5.5云计算

若不适用请说明。

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

1.6注册历史

若不适用请说明。

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

2.实现过程

2.1开发概述

1）开发方法：如面向过程、面向对象、敏捷开发等。

2）编程语言：如C#，HTML等。

3）开发测试环境

a)软硬件设备

b)开发测试工具：开发测试工具明确名称、完整版本、开发商

c)网络条件

d)云计算

4）开发测试人员数量：

5）开发时间：

6）工作量（人月数）：

7）代码行总数（概数）：

2.2风险管理

1）软件风险管理流程图

2）风险管理过程的具体活动

依据流程图详述软件风险管理过程的具体活动。

3）风险管理矩阵

提供采取风险控制措施前后的风险矩阵汇总表。

4）软件开发原始文件

提供开发所形成的原始文件。

5）软件组件（如适用）

软件组件提供所属医疗器械的风险管理文档，并注明软件组件所在位置。

请在此处说明软件组件的在风险管理文档的风险编号。

2.3需求规范

1）软件需求规范文档

提供需求规范文档。

需求文档内容可参考YY/T 0664-2020中5.2.2的要求。

2）软件开发所形成的原始文件

提供软件开发所形成的原始文件。

3）软件组件（如适用）

软件组件若无单独文档，可提供所属医疗器械的产品需求规范文档，并注明软件组件所在位置。

若使用所属医疗器械的产品需求规范文档，建议在此处说明软件组件在产品需求规范文档中的需求编号。

2.4生存周期

可以选择以下任意一种方式进行：

方式一：提供详细说明

1）软件开发

a)提供开发流程图。

b)依据流程图详述开发过程的具体活动，也可另附相关计划文档（详述的具体活动或计划文档应包含开发过程的里程碑，如项目节点、节点的输入及节点的输出物）。

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

2）软件维护

a)提供软件维护流程图。

b)依据流程图详述软件维护过程的具体活动，也可另附相关计划文档（详述的具体活动或计划文档应包含新需求来源与分类，以及说明不同分类的在后续过程中的区别）。

注：软件维护并非软件售后，为软件发布后的增强类软件更新; 软件维护过程包括软件更新需求评估、软件更新策划、软件更新实施、软件验证、软件确认、软件发布、用户告知等活动。

3）软件配置管理

a)提供配置流程图。

b)依据流程图详述配置过程的具体活动，也可另附相关计划文档（详述的具体活动或计划文档应包含配置识别项清单，配置识别项清单包括但不限于文档、源代码、开发测试工具、外部软件环境等）; 如采用敏捷开发，应增加基线管理。

注： 软件配置管理过程包括配置项识别、更改控制、配置状态记录等活动。

4）如采用敏捷开发，应提供文件与记录控制文档。

 

方式二：提供软件生存周期过程控制程序文档

提供软件生存周期过程控制程序文档，内容须明确各个环节的具体活动。

 

方式三：软件生存周期过程标准核查表

提供软件生存周期过程标准核查表，须核查YY/T 0664-2020的各项要求。

核查表建议采用以下形式：

表2软件生存周期过程标准核查表

 

序号	核查项目	标准条款	标准要求	核查结果	支持性证据	支持性说明

 

2.5验证与确认

2.5.1软件开发质量保证活动

概述软件开发过程质量保证活动，或提供软件开发质量保证计划文档。

软件开发过程质量保证活动应考虑全生命周期的质量保证，但本部分重点考虑验证与确认活动。

软件验证包括：源代码审核、静态和动态分析/测试、单元测试、集成测试、系统测试、设计评审等一系列活动，是软件确认的基础。

软件确认包括：用户测试、临床评价等一系列活动，即要保证软件满足用户需求和预期用途，又要确保软件已知剩余缺陷的风险均可接受。

2.5.2系统测试

1）提供系统测试计划。

2）提供系统测试报告。

注：如系统测试计划/报告中如未说明测试用例，需单独提交测试用例; 系统测试计划与报告应确保测试环境信息齐全，可对全部功能进行验证，如连接影像设备的PASS软件的相关设备或相关模拟程序; 测试用例应包含所有功能和典型工作流中的功能组合、应包含所有使用限制，测试用例应参考YY/T 1861-2023的要求进行编写，测试用例的操作过程应具体明确，并保障测试用例的可重复性与可操作性。

2.5.2用户测试

1）提供用户测试计划。

2）提供用户测试报告。

3）用户测试应包含用户测试人员信息。

注：测试人员应能代表预期使用对象，如代表医生用户应为对项目不了解的具有医疗背景的人员，代表患者的用户，应为对项目不了解的不具有医疗背景的人员。

2.6可追溯性分析

2.6.1可追溯性分析过程

1）提供可追溯性分析流程图。

2）依据流程图详述可追溯性分析过程的具体活动，也可另附相关计划文档。

注：可追溯性是全生命周期的活动，每个阶段都应进行可追溯的分析; 对于每个阶段，都应进行可追溯分析确认，以确保每个阶段的文档都与前一阶段的文档有明确的追溯关系。

2.6.2可追溯性分析报告

可追溯性分析报告应包含以下内容：

1）分析报告应包含在生命周期各阶段的可追溯性情况以及结论。

2）分析报告应说明软件需求等信息在开发过程中是否发生变化，如发生变化，应说明可追溯分析的实施情况。

3）汇总列明软件需求规范文档、软件设计规范文档、源代码（明确软件单元名称即可）、软件测试报告、软件风险分析报告之间的对应关系。

2.6.3软件开发所形成的原始文件

提供开发所形成的原始文件。

2.7缺陷管理

2.7.1缺陷管理过程

1）缺陷管理流程图。

2）依据流程图详述缺陷管理的具体活动，也可另附相关计划文档（详述的具体活动或计划文档应包含缺陷记录要求）。

注：软件缺陷管理过程包括软件缺陷评估、软件缺陷修复、回归测试等活动。

2.7.2测试阶段缺陷数据

1）缺陷总数。

2）剩余缺陷数。

2.7.3已知缺陷内容

列明软件已知剩余缺陷的内容、影响、风险，确保风险均可接受。

软件已知剩余缺陷情况可另附文件。

2.8更新历史

2.8.1完整版本命名规则

明确软件完整版本全部字段的位数、范围、含义，若软件模块（含医用中间件）单独进行版本控制亦需提供其版本命名规则，并明确与软件版本命名规则的关系。软件和软件模块的版本命名规则均需与质量管理体系保持一致。

注：此处应与技术要求保持一致。

如适用，列明自前次注册以来历次软件更新的完整版本、日期、类型、具体内容。 

表3软件历次更新信息

发布版本	日期	备注	完整版本
		首次发布

3.核心功能

本软件采用的算法详细信息如下表所示：

表4 算法详细信息

核心功能及类型	核心算法及类型	预期用途及类型

核心功能与核心算法类型包括全新和成熟两种类型，其中全新是指未上市或安全有效性尚未在医疗实践中得到充分证实的情形，成熟是指安全有效性已在医疗实践中得到充分证实的情形。核心算法若基于已有的成熟算法但用于新的预期用途、适用范围也属于全新类型。

全新的核心功能、核心算法、预期用途需注明，并提供相应安全有效性研究资料。

全新算法需要提供《算法研究报告》，通常包括算法基本信息、算法风险管理、算法需求规范、算法质控要求、算法验证与确认、算法可追溯性分析、结论等内容。

4.结论

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

5.附件

提供以本部分附件的文件列表。

 

附录4网络安全研究报告模板

 

网络安全研究报告

1. 基本信息

1.1软件信息

1) 软件名称：

2) 型号规格：

3) 发布版本：

4) 网络安全的安全性级别：轻微、中等、严重（说明与软件安全级别是否相同，如果低于软件安全级别需要说明理由，理由阐述可以结合网络安全的风险分析）

1.2数据架构

提供申报医疗器械在每个使用场景（含远程维护与升级，下同）下的网络环境和数据流图，并依据图示描述医疗器械相关数据和电子接口的基本情况。

1.2.1网络条件和数据流图

网络条件：

表5网络条件描述

配置项	要求
网络类型
服务端带宽要求

数据流图：

此处提供数据流图

 

表6数据流向说明

序号	数据流向说明
1
2
3

 

1.2.2数据类型

表7数据类型说明

序号	医疗器械相关数据的类型	内容
1	□敏感医疗数据	1）具体内容（□ 个人信息、□医疗活动信息、□设备运行信息） 2）功能（ □单向、□双向电子数据交换，□实时、非实时远程访问与控制） 3）用途（□医疗活动、□设备维护）
2	□非敏感医疗数据	1）具体内容（□ 个人信息、□医疗活动信息、□设备运行信息） 2）功能（ □单向、□双向电子数据交换，□实时、非实时远程访问与控制） 3）用途（□医疗活动、□设备维护）
3	□设备数据	1）具体内容（□ 个人信息、□医疗活动信息、□设备运行信息） 2）功能（ □单向、□双向电子数据交换，□实时、非实时远程访问与控制） 3）用途（□医疗活动、□设备维护）

序号 医疗器械相关数据的类型 内容

1 □敏感医疗数据 1）具体内容（□ 个人信息、□医疗活动信息、□设备运行信息）

2）功能（ □单向、□双向电子数据交换，□实时、非实时远程访问与控制）

3）用途（□医疗活动、□设备维护）

2 □非敏感医疗数据 1）具体内容（□ 个人信息、□医疗活动信息、□设备运行信息）

2）功能（ □单向、□双向电子数据交换，□实时、非实时远程访问与控制）

3）用途（□医疗活动、□设备维护）

3 □设备数据 1）具体内容（□ 个人信息、□医疗活动信息、□设备运行信息）

2）功能（ □单向、□双向电子数据交换，□实时、非实时远程访问与控制）

3）用途（□医疗活动、□设备维护）

注：敏感数据有个人信息的医疗数据指能够单独或与其他信息结合识别特定自然人个人身份的各种信息，如自然人的姓名、出生日期、身份证件号码、个人生物识别信息（含容貌信息）、住址、电话号码等; 设备数据指描述医疗器械运行状况的数据，用于监视、控制医疗器械运行或用于医疗器械的维护维修，不应含有个人信息。

1.2.3电子接口

表8电子接口描述信息

接口名称 接口信息
接口描述
预期用户
使用场景
预期用途
技术特征
使用限制
故障应对措施

 

1.3网络安全能力

逐项分析申报医疗器械对于该项网络安全能力的适用性，详述适用网络安全能力的实现方法以及不适用理由。若适用，提供其他网络安全能力的适用情况说明。

1.4网络安全补丁

列明网络安全补丁的基本情况（含必备软件、外部软件环境），明确网络安全补丁的名称、完整版本、发布日期。

1.5安全软件

明确安全软件的基本情况。描述申报医疗器械兼容或所用的安全软件（如杀毒软件、防火墙等）的名称、型号规格、完整版本、供应商、运行环境、防护规则配置要求。

2. 实现过程

2.1风险管理

通常出具单独的网络安全风险管理报告和风险分析报告，如果没有单独的网络安全风险管理报告和风险分析报告，需要注明网络安全的情况。

网络安全风险管理活动，主要包括 识别资产、威胁、脆弱性：

识别资产（Asset，对个人或组织有价值的物理和数字实体）

威胁（Threat，可能导致对个人或组织产生损害的非预期事件发生的潜在原因）

脆弱性（Vulnerability，可能会被威胁所利用的资产或风险控制措施的弱点）

评估威胁和脆弱性对于医疗器械和患者的影响以及被利用的可能性；

确定风险水平并采取充分、有效、适宜的风险控制措施；

基于风险接受准则评估网络安全综合剩余风险，保证网络安全综合剩余风险均处于可接受水平。

2.2需求规范

提供申报医疗器械的网络安全（含远程维护）需求规范文档，如果没有单独的网络安全需求，可提供软件需求文档，但需注明网络安全情况。

2.3验证与确认

2.3.1网络安全验证

提供申报医疗器械的网络安全（含远程维护）测试计划和报告。

需在软件验证与确认的框架下，结合产品网络安全特性开展相关质控工作，质控方法：源代码安全审核、威胁建模、漏洞扫描、渗透测试、模糊测试等。。

网络安全能力要求可参考YY/T 1843-2022中的要求。

2.3.2安全软件兼容性验证

列出建议安装的安全软件用于防止本软件受到潜在恶意软件和病毒的攻击，且与本软件兼容的安全软件。并提供兼容性测试报告。

2.3.3标准传输协议的验证

对于标准传输协议或存储格式，若其满足医疗器械网络安全需求出具真实性声明即可，反之提供相应证明材料。

2.3.4私有协议的验证

对于私有传输协议或存储格式，提供完整性测试总结报告。

1）私有协议涉及数据内容：如文本、数字等；

2）传输数据设计；

3）数据生成完成性测试，应对不同复杂度的数据进行生成测试，并进行多次生成测试（如涉及应包括不同设备不同系统），确保多次生成的同样数据一致：如涉及时间签名等信息，进行说明，并说明如何确保数据完整；

4）数据读取完整性测试，应对不同复杂度的数据进行读取测试，对于同一份数据多次读取结果一致（如涉及应包括不同设备不同系统）；

5）测试结论。

2.4可追溯性分析

提供申报医疗器械的网络安全可追溯性分析报告，汇总列明网络安全需求规范文档、网络安全设计规范文档、源代码（明确软件单元名称即可）、网络安全测试报告、网络安全风险分析报告之间的对应关系。亦可提供医疗器械软件的可追溯性报告，但需注明网络安全情况。

2.5维护计划

提供申报医疗器械网络安全更新的流程图，并结合质量体系的要求依据图示描述相关活动。

如涉及远程维护，需提供远程维护流程图，并结合体系要求描述相关活动。

提供网络安全事件应急响应的流程图，并依据图示描述相关活动；或者提供网络安全事件应急响应预案文档。

3. 漏洞评估

对于网络安全级别为中等的产品，可提供网络安全漏洞自评报告或者网络安全评估机构出具的网络安全漏洞评估报告，明确已知剩余漏洞的维护方案。

网络安全漏洞评估报告需包括：扫描所用软件工具、漏洞库（基于国家信息安全漏洞库或互认的国际信息安全漏洞库）的基本信息（如名称、完整版本、发布日期、供应商等）按照漏洞等级明确已知漏洞总数和剩余漏洞总数，列明已知剩余漏洞的内容、对产品的影响及综合剩余风险，确保产品综合剩余风险均可接受。

如产品的网络类型为广域网，应提供渗透测试的报告。

4. 总结

概述申报医疗器械的网络安全实现过程的规范性和网络安全漏洞评估结果，判定申报医疗器械的网络安全是否满足要求，受益是否大于风险。

5. 附件

提供以附件形式提供的文件列表。