序号及项目 | 旧版 | 新版 |
1.指导原则的地位 | | 本指导原则是数字医疗（Digital Health）指导原则体系的基础指导原则，亦是医疗器械软件的通用指导原则 |
| 本指导原则适用于医疗器械软件的注册申报，包括第二类、第三类医疗器械产品，适用的软件开发方式包括自主开发、部分采用现成软件和全部采用现成软件。 | 本指导原则适用于医疗器械软件的注册申报，包括第二、三类独立软件和含有软件组件的医疗器械（包括体外诊断医疗器械）；适用于自研软件、现成软件的注册申报。本指导原则也可用作医疗器械软件、质量管理软件的体系核查参考。 |
| | 医用中间件是医疗器械软件正常运行所必需的，故作为医疗器械软件的组成部分予以考虑。 |
| 有些支持软件（如VTK、ITK）自带算法库，医疗器械软件开发过程已将算法库相关内容集成于自身内部，故医疗器械软件正常运行需要这些支持软件的支持。 |
| 必备软件: 医疗器械软件正常运行所必需的其他的医疗器械软件及医用中间件 |
| 外部软件环境: 正常运行所必需的系统软件、通用应用软件、通用中间件、支持软件 |
| A级提供软件开发生存周期计划摘要，描述开发各阶段的划分情况和工作任务。B级在A级基础上提供配置管理计划摘要和维护计划摘要，描述所用的工具和流程。C级在B级基础上提供设计历史文档集索引表（DHF）。生存周期也可提交制造商软件生存周期过程文件或YY/T 0664《医疗器械软件软件生存周期过程》等过程标准的核查表，用于替代相应描述。 | 软件生存周期（又称软件生命周期）是指软件系统从概念定义至停止使用的时间周期，包括软件开发策划、软件需求分析、软件设计、软件编码、软件测试、软件发布、软件部署、软件维护、软件停运等阶段。 |
| | 软件生存周期模型是指一组包含过程、活动和任务的框架，跨越从软件需求分析到软件停运的软件生存周期过程，每个过程可细分为若干活动，每个活动又可细分为若干任务。 |
| 验证是指通过提供客观证据认定软件某开发阶段的输出满足输入要求，包括代码检查、设计评审、测试等质量保证活动。 | 软件验证是指通过提供客观证据认定软件开发、软件维护某一阶段的输出满足输入要求。软件验证包括源代码审核、静态和动态分析/测试、单元测试、集成测试、系统测试、设计评审等系列活动，是软件确认的基础。 |
| A级提供系统测试、用户测试的计划和报告摘要，描述测试的条件、工具、方法、通过准则和结果。B级提供系统测试、用户测试的计划和报告，概述开发各阶段的验证活动，描述所用的工具、方法和任务。 | 软件测试是软件质量保证的基本措施，也是软件验证、软件确认的重要方法，从不同角度有不同分类方法。单元测试是对软件单元进行测试，通常采用白盒测试. 集成测试是对软件项（由若干软件单元组成，即软件模块）进行测试，白盒测试、黑盒测试、灰盒测试相结合；系统测试是对软件系统（由若干软件项组成）进行测试，通常采用黑盒测试，其从测试内容角度又可分为功能测试、性能测试、并发测试、压力测试、接口测试、内存测试、兼容性测试、用户界面测试、安装卸载测试、安全测试等。内部测试是指注册申请人实施的测试，包括单元测试、集成测试、系统测试，白盒测试、黑盒测试、灰盒测试相结合；用户测试是指预期用户在真实或模拟使用场景对软件系统进行测试，采用黑盒测试；第三方测试是指第三方机构对软件系统进行测试，通常采用黑盒测试。回归测试是指用于确定软件更新没有产生不良影响且未引入风险不可接受新缺陷的软件测试。 |
| 确认是指通过提供客观证据认定软件满足用户需求和预期用途，通常是指在真实或模拟使用环境进行的用户测试。 | 软件确认是基于过程控制的设计确认，包括用户测试、临床评价、设计评审等系列活动，即要保证软件满足用户需求和预期用途，又要确保软件已知剩余缺陷的风险均可接受。 |
| C级在B级基础上提供可追溯性分析报告（追溯需求规范、设计规范、测试、风险管理的关系表）。 | 注册申请人应建立软件可追溯性分析过程，规范软件可追溯性分析相关活动要求，以保证软件验证、软件确认的质量。考虑到行业实际情况，源代码追溯分析活动追溯至软件单元（列明名称）即可。 |
| | 从医疗器械唯一标识（UDI）角度，软件完整版本属于生产标识（PI）的组成部分。 |
|
| 检测报告提供软件版本界面照片或列明软件版本信息，有用户界面的软件体现软件发布版本、软件完整版本，无用户界面的软件体现软件完整版本。说明书注明软件发布版本。 |
| 核心算法是指实现软件核心功能（软件在预期使用环境完成预期用途所必需的功能）所必需的算法，包括但不限于成像算法、后处理算法和人工智能算法。其中成像算法是指用于获取医学图像或数据的算法，后处理算法是指改变原始医学图像或数据产生新临床信息的算法，人工智能算法是指采用人工智能技术进行医学图像或数据分析的算法。算法类型包括公认成熟算法和全新算法。其中公认成熟算法是指源自公开文献资料、原理简单明确、上市多年且无不良事件的算法，而全新算法是指源自临床研究、科学研究的新算法。 | 软件算法从重要性角度可分为核心算法和非核心算法，其中核心算法是指实现软件核心功能所必需的算法，反之即为非核心算法。从复杂性角度可分为简单算法和复杂算法，前者原理简单明确或基于成熟公式，后者通常基于模型研究，存在诸多假设条件且影响因素较多，同时二者在算法规模、参数数量、运算速度等方面亦存在差异。从可解释性角度可分为白盒算法和黑盒算法，前者可与现有知识建立关联，后者难与现有知识建立关联，前者可解释性优于后者。 |
| | 软件功能从不同角度出发有不同分类方法。从重要性角度可分为核心功能和非核心功能，其中核心功能是指软件在预期使用场景完成预期用途所必需的功能，反之即为非核心功能。从技术特征角度大体上可分为处理功能、控制功能、安全功能，其中处理功能是指加工医疗器械数据（即医疗器械产生的用于医疗用途的客观数据）或基于模型计算（如辐射剂量模型、药代模型）的功能，控制功能是指控制/驱动医疗器械硬件运行的功能，安全功能是指保证医疗器械安全性的功能。处理功能从数据流角度又可分为前处理功能和后处理功能，前者是指采集人体解剖、生理信息生成医疗器械数据过程的处理功能，后者是指利用医疗器械数据生成诊疗信息或进行医疗干预过程的处理功能; 后处理功能从复杂性角度又可分为简单功能和复杂功能，前者是指对现有医疗信息进行操作而非生成新医疗信息的功能，后者是指生成新医疗信息的功能;从监管范围角度可分为医疗器械功能和非医疗器械功能，其中医疗器械功能是指可用作医疗器械界定依据的软件功能，反之即为非医疗器械功能，实现医疗器械功能所必需的患者信息管理功能属于医疗器械功能。二者尽量通过模块化设计予以拆分，若在技术上无法拆分需将非医疗器械功能作为医疗器械软件的组成部分予以整体考虑。 |
|
| 软件用途通常可分为辅助决策和非辅助决策，其中辅助决策是指通过提供诊疗活动建议辅助用户（如医务人员、患者）进行医疗决策;仅提供医疗参考信息而不进行医疗决策即为非辅助决策.实时性角度均可细分为实时和非实时，前者风险通常高于后者。故软件功能从软件用途角度又可分为辅助决策类功能和非辅助决策类功能、实时功能和非实时功能。 |
| 软件安全性级别应结合软件的预期用途、使用环境和核心功能（软件在预期使用环境完成预期用途所必需的功能）进行判定。其中预期用途主要考虑软件的临床用途（如诊断、治疗、监护、筛查等）和重要程度（如重要作用、辅助作用、补充作用等），使用环境主要考虑软件的使用场所（如医院、家庭等）、疾病类型（如严重性、紧迫性、传染性等）、患者人群（如成人、儿童、老年、女性等）和用户类型（如专业用户、普通用户、患者等），核心功能主要考虑软件的功能类型（如控制驱动、处理分析等）、实现方法（如CT图像重建采用滤波反投影算法还是迭代算法，异常识别采用常规图像处理算法还是人工智能算法等）和复杂程度（如算法规模、参数数量、运算速度等）。 | 软件安全性级别可结合软件的预期用途、使用场景、核心功能进行综合判定。其中，预期用途主要考虑软件的用途类型（如治疗、诊断、监护、筛查）、重要程度（如重要作用、参考作用、补充作用）、紧迫程度（如危重情形、严重情形、普通情形）、成熟程度（成熟、全新）等因素，使用场景主要考虑软件的使用场所（如门诊、手术、住院、急救、家庭、转运、公共场所）、疾病特征（如严重性、紧迫性、传染性）、适用人群（如成人、儿童、老人、孕妇）、目标用户（如医务人员、患者）等因素，核心功能主要考虑软件的功能类型（如重要程度、技术特征、复杂程度、成熟程度）、核心算法（如重要程度、复杂程度、可解释性、成熟程度）、输入输出（输入数据如医学图像、生理参数、体外诊断等数据，输出结果如处理、测量、分析等结果）、接口（如应用程序接口（API）、数据接口、产品接口）等因素。 |
| | 上市前开展充分有效的软件验证与确认活动，识别软件可预见的风险并将其降至可接受水平。上市后继续开展软件质量保证工作，结合用户投诉、不良事件和召回等情况识别前期未预见的风险，并采取必要措施保证软件质量；同时，基于软件更新需求的评估，实施软件更新活动以满足用户新需求，并开展与之相适宜的软件验证与确认活动，以保证软件更新质量；此外，软件停运考虑用户告知与后续服务、数据迁移、患者数据与隐私保护等要求。 |
| | 需考虑现成软件组件和外部软件环境的更新，并开展外部软件环境更新的影响评估工作。 |
| | 质量管理软件是指医疗器械质量管理所用的应用软件，非医疗器械软件，无需申报注册。质量管理软件与医疗器械软件在技术层面具有相同之处，故可参照医疗器械软件相关要求考虑质量管理软件的确认要求。质量管理软件参照医疗器械软件可分为类独立软件和类软件组件，前者包括设计开发所用软件、流程管理所用软件等，后者包括生产设备所含软件、检验设备所含软件等。 |
| 不同预期用途的独立软件应作为不同注册单元，按照预期用途大体上可分为治疗计划类、诊断类、监护类和信息管理类。 | 不同预期用途的独立软件作为不同注册单元，按照预期用途可分为辅助决策类和非辅助决策类，每类又可细分为治疗、诊断、监护、筛查等情形。 |
| 有多个运行环境或多个发布版本，则每个互不兼容的运行环境（含云计算）或每个互不涵盖的发布版本均需作为一个检测单元。 | 有多个运行环境或多个发布版本，则每个互不兼容的运行环境（含云计算）或每个互不涵盖的发布版本均需作为一个检测单元。若软件核心功能相同但核心算法类型不同，则每类核心算法所对应的核心功能均需检测（检测对象为核心功能而非核心算法）。同理，若软件核心功能相同但核心算法类型不同，则每类核心算法所对应的核心功能均需检测。 |
| 独立软件应依据《医疗器械临床评价技术指导原则》提交临床评价资料，不适用条款说明理由。对于采用人工智能算法实现的功能（如计算机辅助检测、分类和诊断等CAD类功能），应提交基于临床试验的临床评价资料。制造商可以选取已上市医疗器械产品所含的同类软件功能进行实质等同对比。 | 独立软件通常基于软件功能进行临床评价，必要时可基于软件算法进行临床评价。临床评价需结合独立软件的预期用途和成熟度予以综合考虑，可选择已上市医疗器械所含同类软件功能进行同品种医疗器械比对。非辅助决策类软件功能基于核心功能进行同品种医疗器械比对。全新的核心算法、核心功能、预期用途原则上均需开展临床评价。简单操作类、单纯流程优化类软件功能可通过非临床证据予以评价。辅助决策类软件功能基于核心算法进行同品种医疗器械比对，所选同品种医疗器械的临床证据原则上需基于临床试验（含回顾性研究，下同）。全新的核心算法、核心功能、预期用途原则上均需开展临床试验。临床试验若采用阳性对照设计，可选择预期用途相同且核心算法或核心功能等同的独立软件进行对照。 |
| | 医疗器械网络安全需从网络安全角度综合考虑信息安全和数据安全。医疗器械软件若具备电子数据交换、远程访问与控制、用户访问三种功能当中一种及以上功能，均需考虑网络安全问题，具体要求详见医疗器械网络安全相关指导原则。 |
| | 建议加强医疗器械软件用户界面的人因设计以提升可用性，将用户错误使用的风险降至可接受水平，具体要求详见医疗器械人因设计相关指导原则。 |
| | 互操作性（又称互用性）是指医疗器械与其他医疗器械或通用设备通过电子接口交换并使用信息的能力。其中电子接口包含硬件接口和软件接口，信息包括但不限于医学图像、生理参数、体外诊断等数据和控制指令。互操作性重点关注医疗器械软件的接口设计及其风险，接口包括内部接口和外部接口，前者是指软件模块之间的接口，后者是指供用户调用的接口，分体式医疗器械各独立部分的内部接口视为外部接口，如服务器与客户端、主机与从机的内部接口。从用户角度出发软件接口若无明示均指外部接口。注册申请人需考虑软件接口的需求分析、风险管理、验证与确认、维护计划等活动要求，以及说明书与标签的设计要求。注册申请人可单独提交一份互操作性研究资料，内容包括基本信息、需求规范、风险管理、验证与确认、维护计划；亦可在自研软件研究报告相关条款中体现软件接口要求， |
| | 测量功能（又称量化、定量功能）可分为图形学测量功能、客观物理测量功能，前者基于图形学间接反映客观事物的测量结果，后者直接反映客观事物的测量结果。无论何种测量功能均需结合测量的误差、不确定度等因素，明确测量准确性指标，如线性度、精度、重复性、再现性、范围限值、显示误差等。注册申请人需提供测量准确性的研究资料，并在说明书中向用户告知。此外，客观物理测量还需在产品技术要求中明确准确性指标，图形学测量还需在说明书中提供关于测量准确性的警示信息。 |
| | 对于远程访问与控制（含远程维护与升级）功能，需明确相关功能的性能指标要求和网络安全要求，具体要求详见医疗器械网络安全相关指导原则。注册申请人需在软件研究资料、网络安全研究资料中提供相应研究资料，在产品技术要求中明确性能指标要求，并在说明书中向用户告知相应功能的使用要求（含网络安全）。 |
| | 医疗器械软件若在技术上能够拆分非医疗器械功能，即采用模块化设计区分医疗器械功能和非医疗器械功能，则产品结构组成不应包含非医疗器械功能模块，说明书若含有非医疗器械功能应予以删除或注明为非医疗器械功能，产品技术要求不应含有非医疗器械功能。医疗器械软件若在技术上无法拆分非医疗器械功能，需将非医疗器械功能作为自身组成部分予以整体考虑，重点关注非医疗器械功能对于医疗器械软件的影响及其风险。 |
| | 由于植入式医疗器械风险较高，植入物产品设计软件属于质量管理软件，故可参照严重级别的成品软件、自研软件要求提交软件研究资料， |
| | 异常处理（Exception handling）用于处理软件出现的异常状况，及时将软件异常信息告知用户，以采取风险控制措施保证安全有效性。 |
| | 考虑到行业实际情况，功能安全、软件可靠性暂不要求，待时机成熟时纳入考量。建议注册申请人参考相关标准要求加强功能安全、软件可靠性的设计工作，若已开展相应工作可在软件研究资料中予以提供。 |
| | GB/T 25000.51适用于医疗器械软件，其中“产品说明要求”、“用户文档集要求”适用于说明书，“软件质量要求”适用于软件本身，同时“使用质量”不适用。在技术要求中删除GB/T 25000.51，注册申请人需在软件研究资料中提交GB/T 25000.51自测报告，亦可提交自检报告或检验报告代替自测报告.软件组件也应按GB/T 25000.51进行检测。 |
| | 进口医疗器械软件若存在中外差异，如语言差异、软件功能删减、适用范围缩减等，需在软件研究资料中提交本次申报软件与原产国获准上市版本软件的中外差异说明材料。 |
| 需求规范：A级提供需求规范摘要，B，c级需要软件需求规范文档验证与确认：A级提供测试计划与报告摘要，B，c级需要测试计划与报告文档 | |
|
| 外部软件环境评估报告用于医疗器械软件外部软件环境（含云计算）的评估，适用于医疗器械软件的初次发布和再次发布，内容框架详见表3，包括安全性级别、软件标识、功能用途、运行环境、风险管理、验收管理、维护计划、结论，详尽程度取决于软件安全性级别。 |
| 明确软件的处理对象类型，如图像（如CT、MRI、X-ray、PET、US等）、数据（如心电、血压、血氧、血糖等） | 明确软件的输入数据类型（如医学图像、生理参数、体外诊断等数据）、输出结果类型（如处理、测量、分析等结果）。 |
| 明确软件的通用数据接口（如Dicom、HL7）、产品接口（可联合使用的独立软件、医疗器械硬件） | 明确软件供用户调用的应用程序接口（API）、数据接口（含传输协议、存储格式，如DICOM、HL7、JPG、PNG、私有协议与格式）、产品接口（可联合使用的其他医疗器械独立软件、医疗器械硬件产品）。 |
| 明确软件完成预期用途所必备的独立软件、医疗器械硬件 | 明确软件正常运行所必需的其他的医疗器械独立软件（名称、型号规格、发布版本）及医用中间件（名称、型号规格、发布版本）、医疗器械硬件产品（名称、型号规格）。 |
| |
| |
| 说明书应符合相关的法规、规范性文件、国家标准、行业标准的要求，体现软件全部功能（包含安全功能），明确软件发布版本。 | 说明书逐项说明每个软件接口的预期用户、使用场景、预期用途、技术特征、使用限制、故障应对措施。根据风险控制要求，标签明确关键软件接口的技术特征、使用限制。说明书必要时需明确外部软件环境所含全部现成软件的交付、安装、设置、配置、更新以及使用限制、警示提示等内容。 |
全部 0条评论