医疗器械软件注册审查指导原则修订版0309.docx
《医疗器械软件注册审查指导原则修订版0309.docx》由会员分享，可在线阅读，更多相关《医疗器械软件注册审查指导原则修订版0309.docx（56页珍藏版）》请在冰豆网上搜索。
医疗器械软件注册审查指导原则修订版0309
附件
医疗器械软件注册审查指导原则
（2022年修订版）
本指导原则旨在指导注册申请人规范医疗器械软件生存周期过程和准备医疗器械软件注册申报资料，同时规范医疗器械软件的技术审评要求，为医疗器械软件、质量管理软件的体系核查提供参考。
本指导原则是对医疗器械软件的一般要求，注册申请人需根据产品特性和风险程度确定本指导原则具体内容的适用性，若不适用详述理由。
注册申请人亦可采用其他符合法规要求的替代方法，但需提供详尽研究资料。
本指导原则是在现行法规、强制性标准体系以及当前科技能力、认知水平下制定的，随着法规、强制性标准体系的不断完善以及科技能力、认知水平的不断发展，本指导原则相关内容也将适时调整。
本指导原则作为注册申请人、审评人员和检查人员的指导性文件，不包括审评审批所涉及的行政事项，亦不作为法规强制执行，应在符合法规要求的前提下使用本指导原则。
本指导原则是数字医疗（DigitalHealth）指导原则体系的基础指导原则，亦是医疗器械软件的通用指导原则，其他含有或涉及软件的医疗器械指导原则可在本指导原则基础上进行有针对性的调整、修改和完善。
一、适用范围
本指导原则适用于医疗器械软件的注册申报，包括第二、三类独立软件和含有软件组件的医疗器械（包括体外诊断医疗器械）；适用于自研软件、现成软件的注册申报。
本指导原则也可用作医疗器械软件、质量管理软件的体系核查参考。
二、主要概念
（一）医疗器械软件
医疗器械软件包括本身即为医疗器械的软件或者医疗器械内含的软件，前者即医疗器械独立软件（简称独立软件），后者即医疗器械软件组件（简称软件组件），详见图1。
独立软件（SaMD）是指具有一个或多个医疗目的/用途，无需医疗器械硬件即可完成自身预期用途，运行于通用计算平台的软件。
通用计算平台满足信息技术设备安全要求（含电磁兼容），符合GB4943.1、GB/T9254等标准。
独立软件可分为通用型独立软件和专用型独立软件，前者通常基于通用数据接口与多个医疗器械联合使用，如医学图像处理软件、患者监护软件；后者基于通用、专用数据接口与特定医疗器械联合使用，可视为医疗器械附件，如动态心电数据分析软件、眼科显微镜图像处理软件。
软件组件（SiMD）是指具有一个或多个医疗目的/用途，控制/驱动医疗器械硬件或运行于医用计算平台的软件。
医用计算平台满足医用电气设备（GB9706系列）、实验室用电气设备（GB4793系列）或有源植入式医疗器械（GB16174系列）等安全要求（含电磁兼容）；医用计算平台可与通用计算平台联合使用构成系统，整体视为医用计算平台。
软件组件可分为内嵌型软件组件和外控型软件组件，前者运行于医用计算平台，控制/驱动医疗器械硬件，如心电图机、脑电图机所含嵌入式软件（即固件）；后者运行于通用计算平台，控制/驱动医疗器械硬件，如CT、MRI图像采集工作站软件。
图1医疗器械软件类型
独立软件作为医疗器械或医疗器械附件，通常单独注册，特殊情况可随医疗器械进行注册，此时虽不控制/驱动医疗器械硬件但从产品角度运行于医用计算平台，故视为软件组件，如专用型独立软件可作为附件随医疗器械进行注册。
软件组件作为医疗器械或医疗器械部件、附件的组成部分，不宜单独注册，需随医疗器械进行整体注册。
（二）系统软件、应用软件、中间件、支持软件
系统软件是指设计用于保障计算机系统正常运行的软件，如操作系统软件、虚拟机软件。
应用软件是指设计用于实现计算机用户特定需求的软件，如浏览器软件、数据库软件、安全软件。
中间件介于系统软件和应用软件之间，依赖于系统软件的支持，同时又为应用软件提供支持，如分布式计算平台软件。
支持软件是指设计用于开发、测试其他软件的软件，如软件开发工具、软件测试工具。
医疗器械软件属于应用软件，其正常运行通常需要基于系统软件，或同时需要应用软件（含其他医疗器械软件）、中间件、支持软件的支持。
有些注册申请人会开发医用中间件用作医疗器械软件的公共支持平台，由于这些医用中间件是医疗器械软件正常运行所必需的，故作为医疗器械软件的组成部分予以考虑。
有些支持软件（如VTK、ITK）自带算法库，医疗器械软件开发过程已将算法库相关内容集成于自身内部，故医疗器械软件正常运行需要这些支持软件的支持。
本指导原则将医疗器械软件正常运行所必需的其他的医疗器械软件及医用中间件称为必备软件，而将其正常运行所必需的系统软件、通用应用软件、通用中间件、支持软件统称为外部软件环境。
必备软件作为医疗器械软件单独注册，明确相互接口关系及技术特征即可。
外部软件环境不含必备软件，亦非医疗器械软件。
（三）软件生存周期
软件生存周期（又称软件生命周期）是指软件系统从概念定义至停止使用的时间周期，包括软件开发策划、软件需求分析、软件设计、软件编码、软件测试、软件发布、软件部署、软件维护、软件停运等阶段。
其中，从软件需求分析到软件发布的时间周期称为软件开发生存周期。
软件开发策划主要确定软件开发的目标和可行性。
软件需求分析是将法规、标准、用户、产品等要求转换为软件需求规范/软件需求规格说明（SRS）。
软件设计是通过设计活动将软件需求规范转换为软件设计规范/软件设计规格说明（SDS）。
软件编码是通过编写源代码将软件设计规范转换为软件系统。
软件测试是通过各类测试活动保证软件系统质量。
软件发布是将软件系统予以产品定型。
软件部署是指软件系统的交付、安装、设置和配置。
软件维护是对软件系统发布后的更新需求予以实现。
软件停运（即软件退市）是指终止软件系统的销售和售后服务，售后服务停止时间通常晚于停售时间。
软件生存周期模型是指一组包含过程、活动和任务的框架，跨越从软件需求分析到软件停运的软件生存周期过程，每个过程可细分为若干活动，每个活动又可细分为若干任务。
其中，软件开发生存周期模型是软件生存周期模型的重要组成部分，常见模型包括瀑布模型、迭代模型、增量模型、V模型等。
敏捷开发是以人为核心、迭代与增量相结合的软件开发方法，常见软件开发生存周期模型包括SCRUM、极限编程等。
敏捷开发秉承四条理念：
人员互动胜于过程和工具，可用的软件胜于详尽的文档，客户合作胜于合同谈判，响应变化胜于遵循计划。
因此，使用敏捷开发应兼顾质量管理体系相关要求，重点关注软件更新、文件与记录等控制要求。
注册申请人可结合软件的产品特点、风险程度以及质量管理体系要求，选择适宜的软件生存周期模型，参照相关国际、国家、行业标准建立相应软件生存周期过程。
（四）软件测试、软件验证、软件确认
软件测试是软件质量保证的基本措施，也是软件验证、软件确认的重要方法，从不同角度有不同分类方法。
从测试依据角度可分为黑盒测试和白盒测试。
其中，黑盒测试是指基于输入与输出的测试，白盒测试是指基于源代码的测试，黑盒测试与白盒测试可组合使用，即灰盒测试。
白盒测试根据是否运行源代码又可分为静态、动态分析/测试。
从测试进程角度可分为单元测试、集成测试、系统测试。
其中，单元测试是对软件单元进行测试，通常采用白盒测试；集成测试是对软件项（由若干软件单元组成，即软件模块）进行测试，白盒测试、黑盒测试、灰盒测试相结合；系统测试是对软件系统（由若干软件项组成）进行测试，通常采用黑盒测试，其从测试内容角度又可分为功能测试、性能测试、并发测试、压力测试、接口测试、内存测试、兼容性测试、用户界面测试、安装卸载测试、安全测试等。
从测试实施方角度可分为内部测试、用户测试、第三方测试。
其中，内部测试是指注册申请人实施的测试，包括单元测试、集成测试、系统测试，白盒测试、黑盒测试、灰盒测试相结合；用户测试是指预期用户在真实或模拟使用场景对软件系统进行测试，采用黑盒测试；第三方测试是指第三方机构对软件系统进行测试，通常采用黑盒测试。
回归测试是指用于确定软件更新没有产生不良影响且未引入风险不可接受新缺陷的软件测试。
回归测试需根据软件更新的类型、内容和程度，开展与之相适宜的单元测试、集成测试、系统测试、用户测试、第三方测试等测试活动。
软件验证是指通过提供客观证据认定软件开发、软件维护某一阶段的输出满足输入要求。
软件验证包括源代码审核、静态和动态分析/测试、单元测试、集成测试、系统测试、设计评审等系列活动，是软件确认的基础。
软件确认是指通过提供客观证据认定软件满足用户需求和预期用途。
软件确认是基于过程控制的设计确认，包括用户测试、临床评价、设计评审等系列活动，即要保证软件满足用户需求和预期用途，又要确保软件已知剩余缺陷的风险均可接受。
注册申请人需结合软件的产品特点、风险程度考虑相应软件测试要求，明确语句、判定、条件、路径等测试覆盖率要求，以保证软件验证、软件确认的质量。
全部源代码均应测试，可结合白盒测试、黑盒测试、灰盒测试等方法予以实现。
（五）软件可追溯性分析
软件可追溯性分析作为软件验证、软件确认的重要活动之一，是指追踪软件需求、软件设计、源代码、软件测试、软件风险管理之间的关系，分析已识别关系的正确性、一致性、完整性、准确性。
软件生存周期过程均需开展可追溯性分析活动，详见图2。
软件需求分析阶段追溯分析软件需求与产品需求、软件需求与风险分析的关系。
软件设计阶段追溯分析软件设计与软件需求、软件设计与风险控制的关系。
软件编码阶段追溯分析源代码与软件设计、源代码与测试用例的关系。
内部测试阶段追溯分析单元测试、集成测试、系统测试各级测试用例与软件设计，系统测试与软件需求，系统测试与风险管理的关系。
用户测试阶段追溯分析用户测试与产品需求、用户测试与风险管理的关系。
软件更新亦需开展与之相适宜的软件可追溯性分析活动。
图2软件可追溯性分析
注册申请人应建立软件可追溯性分析过程，规范软件可追溯性分析相关活动要求，以保证软件验证、软件确认的质量。
考虑到行业实际情况，源代码追溯分析活动追溯至软件单元（列明名称）即可。
（六）软件更新
1.主要概念
软件更新是指注册申请人在软件生存周期全过程对软件所做的任一修改，亦称软件变更、软件维护。
软件维护通常与软件更新含义相同，但可特指发布后软件更新。
软件更新从不同角度出发有不同分类方法。
从更新结果角度可分为重大更新和轻微更新，重大更新是指影响到医疗器械安全性或有效性的软件更新，反之即为轻微更新。
从更新内容角度可分为增强类更新和纠正类更新（即软件缺陷修复）。
增强类更新又可分为完善型更新和适应型更新，其中完善型更新是指改变功能、性能、接口等软件属性的软件更新，适应型更新是指适应新运行环境的软件更新；其从更新结果角度又可分为重大增强类更新、轻微增强类更新。
纠正类更新又可分为修正型更新和预防型更新，其中修正型更新是指修复软件存在且已造成运行故障缺陷的软件更新，预防型更新是指修复软件存在但尚未造成运行故障缺陷的软件更新；其通常属于轻微更新，除非影响到医疗器械安全性或有效性。
本指导原则关注医疗器械软件的安全性和有效性，将软件更新分为：
（1）重大软件更新：
影响到医疗器械安全性或有效性的增强类更新，即重大增强类软件更新，应申请变更注册。
（2）轻微软件更新：
不影响医疗器械安全性与有效性的增强类更新、纠正类更新，包括轻微增强类软件更新、纠正类软件更新，通过质量管理体系进行控制，无需申请变更注册，待下次变更注册时提交相应注册申报资料。
此外，软件构建是指软件编译生成一个工作版本，符合软件更新定义，通过质量管理体系进行控制，注册申报资料要求与纠正类软件更新相同。
召回相关软件更新包括软件更新导致召回、召回措施所用软件更新，无论增强类更新还是纠正类更新均属于重大软件更新，按照医疗器械召回相关法规要求处理，不属于本指导原则讨论范畴。
软件更新遵循风险从高原则，即同时发生重大、轻微软件更新按重大软件更新处理，同时发生增强类、纠正类软件更新按增强类软件更新处理。
软件更新需考虑引入回滚机制，以保证医疗业务的连续性，特别是对高风险软件。
软件重新开发即注册申请人弃用原有软件而开发新软件，不属于软件更新范畴，按初次发布处理。
2.重大软件更新判定原则
软件更新若影响到医疗器械的预期用途、使用场景或核心功能原则上均属于重大软件更新，其判定原则包括但不限于：
（1）完善型软件更新：
若影响到用户决策（含决策能力、决策结果、决策流程、用户行动）或人员（含患者、用户、其他相关人员）安全则属于重大软件更新，如软件的输入输出数据类型、体系结构、用户界面关系、物理拓扑、核心算法、核心功能、诊疗流程或预期用途等发生改变，软件系统、高风险软件项/软件单元进行代码重构，安全性级别改变，调整报警方式等；而运算效率单纯提高、诊疗流程或工作语言可配置化（即用户可保留原有诊疗流程或工作语言）、用户界面文字性修改、中低风险软件项/软件单元的代码重构等情况通常不视为重大软件更新，除非影响到医疗器械的安全性或有效性。
（2）适应型软件更新：
若软件运行环境跨越互不兼容的计算平台（含硬件配置、外部软件环境、必备软件、网络条件）则属于重大软件更新，如预期运行的操作系统软件由Windows变为iOS，更换浏览器内核、必备软件，网络条件由局域网变为广域网，计算平台由通用计算平台变为医用计算平台等；预期运行的系统软件、支持软件、通用中间件的兼容性版本更新、补丁更新通常不视为重大软件更新，除非影响到医疗器械的安全性或有效性。
综上，医疗器械软件更新类型如图3所示。
图3医疗器械软件更新类型
重大软件更新的范围会随着认知水平与技术能力的提高、不良事件与召回情况的分析进行动态调整。
（七）软件版本
软件没有物理实体，只能通过状态标识进行软件更新管理，从而保证软件质量。
软件版本使用不同字段来区分软件更新类型，进而标识软件状态，因此软件版本与软件是一一对应的表里关系，亦是软件标识不可或缺的组成部分。
软件版本可分为软件发布版本和软件完整版本，其中软件发布版本仅体现重大软件更新，即只限于重大增强类软件更新，其改变意味着发生重大软件更新，反之亦然；软件完整版本体现重大、轻微软件更新的全部类型，包括重大增强类软件更新、轻微增强类软件更新、纠正类软件更新、软件构建（若适用），其不同字段的改变意味发生不同类型的软件更新，反之亦然。
软件发布版本发生改变表示软件发生重大更新，应申请变更注册，软件完整版本发生改变但软件发布版本未变表示软件仅发生轻微更新，此时通过质量管理体系进行控制，无需申请变更注册。
例如，软件版本命名规则为X.Y.Z.B，其中X表示重大增强类软件更新，Y表示轻微增强类软件更新，Z表示纠正类软件更新，B表示软件构建，则软件发布版本为X，软件完整版本为X.Y.Z.B，此时X改变应申请变更注册，而Y、Z、B改变但X未变则无需申请变更注册。
注册申请人应综合考虑软件产品特点、质量管理体系要求、合规性等因素制定软件版本命名规则并予以记录，明确字段的位数、范围、含义，涵盖软件更新全部类型，字段含义明确且无歧义无矛盾，能够区分重大软件更新和轻微软件更新，保证软件更新的版本变更符合软件版本命名规则要求。
同时，考虑医疗器械网络安全、人工智能医疗器械等指导原则的要求。
软件版本命名规则同样遵循风险从高原则，即某字段同时表示重大软件更新和轻微软件更新，则该字段按重大软件更新处理，并作为软件发布版本的组成部分。
有用户界面的软件可在登录界面、主界面、“关于”或“帮助”等界面体现软件发布版本、软件完整版本，两个版本均需体现但无需每个界面同时体现。
无用户界面的软件需提供获取软件完整版本的方法，以明确软件版本信息。
产品技术要求注明软件发布版本、软件版本命名规则，其中软件版本命名规则需与质量管理体系保持一致。
检测报告提供软件版本界面照片或列明软件版本信息，有用户界面的软件体现软件发布版本、软件完整版本，无用户界面的软件体现软件完整版本。
说明书注明软件发布版本。
软件模块（含医用中间件）若单独进行版本控制，亦需满足版本控制要求，并明确与软件系统版本控制的关系。
（八）软件算法、软件功能、软件用途
软件算法是软件功能的基础，二者是多对多的关系，即一个软件算法可供一个或多个软件功能使用，一个软件功能可含一个或多个软件算法。
同理，软件功能和软件用途的关系亦是如此。
从用户角度出发，软件算法是内在不可见的，软件功能和软件用途是外在可见的，考虑到软件功能是软件算法、软件用途的联系纽带，故以软件功能作为软件安全有效性评价主线。
例如，区域生长算法可实现图像分割功能，图像分割功能可用于病变轮廓标识。
软件功能从不同角度出发有不同分类方法。
从重要性角度可分为核心功能和非核心功能，其中核心功能是指软件在预期使用场景完成预期用途所必需的功能，反之即为非核心功能。
从技术特征角度大体上可分为处理功能、控制功能、安全功能，其中处理功能是指加工医疗器械数据（即医疗器械产生的用于医疗用途的客观数据）或基于模型计算（如辐射剂量模型、药代模型）的功能，控制功能是指控制/驱动医疗器械硬件运行的功能，安全功能是指保证医疗器械安全性的功能。
处理功能从数据流角度又可分为前处理功能和后处理功能，前者是指采集人体解剖、生理信息生成医疗器械数据过程的处理功能，如滤波、降噪、校正、重建等功能；后者是指利用医疗器械数据生成诊疗信息或进行医疗干预过程的处理功能，如平移、缩放、旋转、滤波、测量、分割、融合、三维重建、治疗计划制定、药代模型计算、基因测序、分析等功能。
后处理功能从复杂性角度又可分为简单功能和复杂功能，前者是指对现有医疗信息进行操作而非生成新医疗信息的功能，如平移、缩放、旋转等功能；后者是指生成新医疗信息的功能，如滤波、测量、分割、融合、三维重建、治疗计划制定、药代模型计算、基因测序、分析等功能。
独立软件的功能均为后处理功能，软件组件的功能以控制功能、前处理功能为主，兼具后处理功能。
考虑到控制功能和前处理功能通常与医疗器械硬件产品共同评价，故处理功能若无明示均指后处理功能；同时，考虑到测量、模型计算、分析等功能具有特殊性，通常情况下与处理功能并列表述。
从监管范围角度可分为医疗器械功能和非医疗器械功能，其中医疗器械功能是指可用作医疗器械界定依据的软件功能，如医学图像、生理参数、体外诊断等数据的测量、处理、模型计算、分析等功能；反之即为非医疗器械功能，如收费计价、行政办公等功能，不属于监管对象；实现医疗器械功能所必需的患者信息管理功能属于医疗器械功能。
二者尽量通过模块化设计予以拆分，若在技术上无法拆分需将非医疗器械功能作为医疗器械软件的组成部分予以整体考虑。
软件算法从重要性角度可分为核心算法和非核心算法，其中核心算法是指实现软件核心功能所必需的算法，反之即为非核心算法。
从复杂性角度可分为简单算法和复杂算法，前者原理简单明确或基于成熟公式，后者通常基于模型研究，存在诸多假设条件且影响因素较多，同时二者在算法规模、参数数量、运算速度等方面亦存在差异。
从可解释性角度可分为白盒算法和黑盒算法，前者可与现有知识建立关联，后者难与现有知识建立关联，前者可解释性优于后者。
软件用途通常可分为辅助决策和非辅助决策，其中辅助决策是指通过提供诊疗活动建议辅助用户（如医务人员、患者）进行医疗决策，如病灶特征识别、病灶性质判定、用药指导、制定治疗计划等，相当于用户的“助手”；反之，仅提供医疗参考信息而不进行医疗决策即为非辅助决策，包括流程优化、诊疗驱动，前者如诊疗流程简化等，后者如测量、分割、三维重建等，相当于用户的“工具”。
同时，辅助决策和非辅助决策从实时性角度均可细分为实时和非实时，前者风险通常高于后者。
故软件功能从软件用途角度又可分为辅助决策类功能和非辅助决策类功能、实时功能和非实时功能。
软件算法、软件功能、软件用途从成熟度角度均可分为成熟和全新两种类型，其中成熟是指安全有效性已在医疗实践中得到充分证实的情形，全新是指未上市或安全有效性尚未在医疗实践中得到充分证实的情形。
同理，软件亦可分为全新软件和成熟软件，软件的算法、功能、用途若有一项为全新类型则属于全新软件，反之属于成熟软件。
因全新软件的潜在未知风险多于成熟软件，故本指导原则以核心功能、核心算法为基础，重点关注全新软件的安全有效性。
三、基本原则
（一）基于软件特性
随着信息通讯技术的迅猛发展，软件在医疗器械中的应用日益普遍，作用日趋重要，开发形式灵活多变，新技术层出不穷。
但随之而来的质量问题也日益增多，医疗器械召回数据表明软件相关召回数量持续增加，明显高于同期医疗器械整体水平，同时软件失效导致患者死亡或严重伤害的召回事件也屡见不鲜，因此软件质量问题的严重性不容忽视，需要基于软件特性加强软件质量保证工作。
软件没有物理实体，在开发和使用过程中人为因素影响无处不在，软件测试由于时间和成本的限制不能穷尽所有情况，所以软件缺陷无法避免。
同时，软件更新频繁且迅速，细微更新可能导致严重后果，并存在累积效应和退化问题（即每修复若干个缺陷就会产生一个新缺陷），所以软件缺陷无法根除。
因此，软件缺陷可视为软件的固有属性之一，这也是软件质量问题较为突出的根源所在。
软件与硬件存在诸多差异：
硬件是物理实体，软件是逻辑关系；硬件变更周期较长，软件更新容易、快速且频繁；硬件有磨损问题，软件虽无磨损但有累积效应和退化问题；硬件质量取决于设计开发和生产，软件质量取决于设计开发，与生产基本无关；硬件失效先有征兆再发生，软件失效往往没有征兆突然发生，软件失效率远高于硬件；硬件部件可以标准化，软件模块的标准化较为复杂；细微变更对硬件影响有限，但对软件影响可能严重；硬件检验可基本保证质量，软件测试不足以保证质量。
这些差异使得传统硬件质量控制方法对于软件质量保证往往达不到预期效果。
鉴于软件特性，只有综合考虑风险管理、质量管理和软件工程的要求才能保证软件的安全有效性。
注册申请人需基于软件风险程度，采用良好软件工程实践完善质量管理体系，针对算法、接口、更新、异常处理等软件召回主要原因，尽早、重点、全面开展软件质量保证工作。
（二）风险导向
综合考虑软件使用的普遍性、监管资源的有限性和风险分级管理导向，软件风险程度不同，其生存周期质控要求和注册申报资料要求亦不同。
软件风险程度采用软件安全性级别进行表述，软件安全性级别越高，生存周期质控要求越严格，注册申报资料也越详尽。
软件安全性级别基于软件风险程度分为轻微、中等、严重三个级别，其中轻微级别即软件不可能产生伤害，中等级别即软件可能直接或间接产生轻微（不严重）伤害，严重级别即软件可能直接或间接产生严重伤害或导致死亡。
软件安全性级别可结合软件的预期用途、使用场景、核心功能进行综合判定。
其中，预期用途主要考虑软件的用途类型（如治疗、诊断、监护、筛查）、重要程度（如重要作用、参考作用、补充作用）、紧迫程度（如危重情形、严重情形、普通情形）、成熟程度（成熟、全新）等因素，使用场景主要考虑软件的使用场所（如门诊、手术、住院、急救、家庭、转运、公共场所）、疾病特征（如严重性、紧迫性、传染性）、适用人群（如成人、儿童、老人、孕妇）、目标用户（如医务人员、患者）等因素，核心功能主要考虑软件的功能类型（如重要程度、技术特征、复杂程度、成熟程度）、核心算法（如重要程度、复杂程度、可解释性、成熟程度）、输入输出（输入数据如医学图像、生理参数、体外诊断等数据，输出结果如处理、测量、分析等结果）、接口（如应用程序接口（API）、数据接口、产品接口）等因素。
软件安全性级别也可根据风险管理所确定的风险等级进行判定，软件安全性级别与风险等级的分级可以不同，但二者存在对应关系，因此可根据风险等级来判定软件安全性级别，但应在采取风险控制措施之前进行判定，后续可通过外部风险控制措施（含软件措施、硬件措施）降低初始软件安全性级别。
软件风险管理需要注意：
软件本身不是危险，但可能会引发危险情况；软件失效虽表现为随机性失效但实为系统性失效，同时软件失效所致危险的发生概率难以统计，故软件风险程度基于伤害严重度并可结合危险情况所致伤害的概率进行判定；软件组件需与所属医疗器械整体开展风险管理工作。
软件安全性级别亦可参考已上市同类医疗器械软件
升级会员 