医疗器械软件注册审查指导原则2015版与2020版本对比
章节 | 医疗器械软件注册技术审查指导原则2015版 | 医疗器械软件注册审查指导原则2022年第8号 | 差异变化分析 |
1 | 在指导制造商提交医疗器械软件注册申报资料,同时规范医疗器械软件的技术审评要求 | 指导注册申请人规范医疗器械软件生存周期过程和准备医疗器械软件注册申报资料,同时规范医疗器械软件的技术审评要求,为医疗器械软件、质量管理软件的体系核查提供参考。 | 增加了指导原则应用包含了医疗器械软件生存周期过程和医疗软件、质量管理软件的体系核查参考文件 这意味着今后软件产品的体考可能会更加严格了 |
2 | 本指导原则是对医疗器械软件的一般性要求,制造商应根据医疗器械软件的特性提交注册申报资料,判断指导原则中的具体内容是否适用,不适用内容详述理由。制造商也可采用其他满足法规要求的替代方法,但应提供详尽的研究资料和验证资料。 | 本指导原则是对医疗器械软件的一般要求,注册申请人需根据产品特性和风险程度确定本指导原则具体内容的适用性,若不适用详述理由。注册申请人亦可采用其他符合法规要求的替代方法,但需提供详尽研究资料。 | 本段中旧版制造商在2022修订版中改为注册申请人,这个改变满足了注册人制度。 旧版中“验证资料”去掉了,原因是独立软件研究资料一般是包含验证资料的如:单元测试报告、集成测试报告、系统测试报告、用户测试报告等附原文。 |
3 | 本指导原则是在现行法规和标准体系以及当前认知水平下、并参考了国外法规与指南、国际标准与技术报告制定的。随着法规和标准的不断完善,以及认知水平和技术能力的不断提高,相关内容也将适时进行修订。 | 本指导原则是在现行法规、强制性标准体系以及当前科技能力、认知水平下制定的,随着法规、强制性标准体系的不断完善以及科技能力、认知水平的不断发展,本指导原则相关内容也将适时调整。 | 旧版与新版比较最大的变化就是2022版按强制标准体系进行。明确了指导原则的修订依据,两版都强调了会随着医疗器械及科技发展及时修改调整。 |
4 | 本指导原则是对制造商和审查人员的指导性文件,不包括审评审批所涉及的行政事项,亦不作为法规强制执行,应在遵循相关法规的前提下使用本指导原则。 | 本指导原则作为注册申请人、审评人员和检查人员的指导性文件,不包括审评审批所涉及的行政事项,亦不作为法规强制执行,应在符合法规要求的前提下使用本指导原则。 | 适用的人员旧版仅适用于制造商和审查人员,新版除注册申请人、审评人员还增加了检查人员。再次说明未来体考过程应该会增加难度了。 |
5 | 本指导原则针对软件的特殊性,在现行法规要求下进一步明确了对医疗器械软件的要求,特别是对软件更新、软件版本的要求。本指导原则是医疗器械软件的通用指导原则,其他涉及软件医疗器械产品的指导原则可在本指导原则基础上进行有针对性的调整、修改和完善。 | 本指导原则是数字医疗(Digital Health)指导原则体系的基础指导原则,亦是医疗器械软件的通用指导原则,其他含有或涉及软件的医疗器械指导原则可在本指导原则基础上进行有针对性的调整、修改和完善。 | 明确了数字医疗指导原则体系、医疗器械软件的通用指导原则。旧版强调了软件更新、版本的要求,新版直接囊括了整个数字医疗体系。 |
一、正文中的适用范围
旧版中这里含有概念及医用软件的类型说明,新版将这范围块清晰的划分为“适用范围和主要概念”而适用范围修改为“本指导原则适用于医疗器械软件的注册申报,包括第二、三类独立软件和含有软件组件的医疗器械(包括体外诊断医疗器械);适用于自研软件、现成软件的注册申报。本指导原则也可用作医疗器械软件、质量管理软件的体系核查参考。”适用范围增加了体外诊断医疗器械和医疗器械软件的体系核查参考。
主要概念新增给出了明确的医疗器械软件、医疗器械独立软件和医疗器械软件组件的定义,同时明确医疗器械独立软件通用计算平台应满足信息技术设备安全要求、电磁兼容及GB4943.1、GB/T9254等标准。医疗器械软件组件应满足相关医用电气设备(GB 9706系列)、实验室用电气设备(GB 4793系列)或有源植入式医疗器械(GB 16174系列)等安全要求(含电磁兼容),并举例示意组件和独立软件的产品。医疗其中软件类型及符合标准参考下图1:
图1 医疗器械软件类型及符合标准
图2医疗器械产品示意图
医疗器械软件 | 软件类型 | 产品举例 | 特点 | 注册要求 |
独立软件 (医疗器械或医疗器械附件) | 通用型 | 医学图像处理软件 患者监护软件 | 通用数据接口 多个器械联合使用 | 单独注册 |
专用型 | 动态心电数据分析软件 眼科显微镜图像处理软件 | 通用、专用数据接口 特定器械联合使用 | 随医疗器械进行注册(视为软件组件) | |
软件组件 | 内嵌型 | 心电图机 脑电图机 | 嵌入式软件(固件)医用计算机平台 | 不宜单独注册,随医疗器械进行整体注册 |
外控型 | CT、MRI图像采集工作站 | 控制/驱动 通用计算机平台 |
二、系统软件、应用软件、中间件、支持软件的概念
系统软件是指设计用于保障计算机系统正常运行的软件,如操作系统软件、虚拟机软件。
应用软件是指设计用于实现计算机用户特定需求的软件,如浏览器软件、数据库软件、安全软件。
中间件介于系统软件和应用软件之间,依赖于系统软件的支持,同时又为应用软件提供支持,如分布式计算平台软件。有些注册申请人会开发医用中间件用作医疗器械软件的公共支持平台,由于这些医用中间件是医疗器械软件正常运行所必需的,故作为医疗器械软件的组成部分予以考虑。
支持软件是指设计用于开发、测试其他软件的软件,如软件开发工具、软件测试工具。有些支持软件(如VTK、ITK)自带算法库,医疗器械软件开发过程已将算法库相关内容集成于自身内部,故医疗器械软件正常运行需要这些支持软件的支持。
必备软件:将医疗器械软件正常运行所必需的其他的医疗器械软件及医用中间件称为必备软件。必备软件作为医疗器械软件单独注册,明确相互接口关系及技术特征即可。
外部软件环境:正常运行所必需的系统软件、通用应用软件、通用中间件、支持软件统称为外部软件环境。外部软件环境不含必备软件,亦非医疗器械软件。
三、软件生存周期
软件生存周期模型是指一组包含过程、活动和任务的框架,跨越从软件需求分析到软件停运的软件生存周期过程,每个过程可细分为若干活动,每个活动又可细分为若干任务。常见模型包括瀑布模型、迭代模型、增量模型、V模型等,软件的开发类似某个模型,无法复制完全按照某个模型去完成设计开发。
软件生存周期(又称软件生命周期)是指软件系统从概念定义至停止使用的时间周期,22版的将软件生存周期每一阶段的要求都标明了,我们需在软件的生命周期每个阶段做什么给的非常清楚,具体内容如下表:
生命周期 | 主要活动内容 | 要点分析 |
软件开发策划 | 开发目标、可行性(软件需求分析、软件设计、软件编码、验证与确认、开发和测试环境,风险管理、缺陷管理、可追溯性分析、配置管理、文件与记录控制、现成软件使用、网络安全保证、评审等) | 一般输出设计开发计划、软件质量保证计划;很多企业会觉得产品简单可能会遗漏测试环境要求、质量保证计划、或者这个阶段就没有风险管理的输入,还有就是配置管理计划并没有将其放在计划中 |
软件需求分析 | 法规、标准、用户、产品、功能、性能、接口、用户界面、网络安全、警示提示等软件需求,风险管理,可追溯性,现成软件,软件确认测试计划等 | 输出软件需求规范/软件需求规格说明(SRS),其中很多不明白可追溯应该如何形成,怎么记录,需求阶段应将每个需求都个一个需求ID,风险识别也给出风险ID,最常见的就是网络安全ID彻底遗忘,确切的说不是遗忘而是不知道什么是网络安全。 |
软件设计 | 软件体系架构、功能、性能、算法、接口、用户界面、单元、网络安全等设计 | 输出软件设计规范/软件设计规格说明(SDS)、软件架构设计说明书、软件详细设计说明书;每次看软件设计架构、详细设计都挺痛苦的,很多企业把功能、性能、接口、用户界面、网络安全混合编写, 比如接口中混合用户访问权限、比如性能中插入显示屏尺寸、分辨率等。另外详细设计是要编制到最小软件单元可编码实现的,企业为了省事可能写了三级功能就行四级五级功能就直接视而不见,最终就是说明书上有了这个功能而详细设计上没有这些内容。 |
软件编码 | 源代码编写与注释、现成软件使用、可追溯性分析、各级测试用例创建、评审等 | 源代码(关于源代码不止一次被追问有没有模板,这个我无话可说) 软件编码规则(应根据不同的编程语言应给出不同的编码规则如《软件编码规则-JAVA》、《软件编码规则-python》。 |
软件测试(全部源代码均应测试,可结合白盒测试、黑盒测试、灰盒测试等方法予以实现。) | 测试依据:白盒测试(基于源代码):源代码审核、静态分析、动态分析、黑盒测试(基于输入与输出)、灰盒测试(白黑盒结合); | 输出测试记录与报告、缺陷管理记录、风险管理记录、评审记录、可追溯性分析记录,文件名称我就不逐个写上了,代码测试不保证100%正确,但是咱们软件测试源代码要确保100%覆盖。最常见的就是技术要求中的性能测试不完整,或者给出的不全面,有缺少并发数测试、有缺少压力测试、有缺少兼容性测试,还有维护性等,功能测试最常见的登录测试经常会出现非法用户登录测试被漏掉。还遇到卸载测试不做了,理由是只要安装上就行不卸载的,一直使用的。编码完成后建立测试用例时一定先将代码测试、评审做了,然后根据说明书按用户界面所有功能逐个测试并给出记录。 |
测试进程:单元测试(白盒)、集成测试(白、黑、灰结合)、系统测试(黑盒) | ||
测试内容:功能测试、性能测试、并发测试、压力测试、接口测试、内存测试、兼容性测试、用户界面测试、安装卸载测试、安全测试等 | ||
测试实施方:内部测试(注册申请人实施的测试,包括单元测试、集成测试、系统测试,白盒测试、黑盒测试、灰盒测试相结合)、用户测试(预期用户在真实或模拟使用场景对软件系统进行测试,采用黑盒测试)、第三方测试(第三方机构对软件系统进行测试,通常采用黑盒测试。) | ||
回归测试需根据软件更新的类型、内容和程度,开展与之相适宜的单元测试、集成测试、系统测试、用户测试、第三方测试等测试活动。 | 根据测试内容出具测试记录/报告。回归测试没有单独的模板,是哪个阶段的测试就按哪个阶段测试形成记录就行。这个测试很容易被忽略,其实这也就是缺陷修复后的测试,程序员叫二轮测试、三轮测试… | |
软件发布 | 将软件系统予以产品定型,确保其可重复性。 | 输出软件发布记录,容易出问题的是软件发布时间,到底是软件编码完成还是注册检验过后,又或是拿到注册证,多半认为是软件编码完成与注册检验之间这个阶段是内测灰度发布,用户测试/临床试验完成后的时间实现外部灰度发布。注册检验完成后可实现软件发布。 |
软件部署 | 软件系统的交付、安装、设置和配置 | 输出软件部署记录,这里最大的问题就是软件部署这个工作给哪个部门,有企业给销售部,有企业给生产部、也有给了研发部,给哪个部门只要人员符合要求,哪个部门都可以做,然我们体系认为这是生产的活,是生产的一个过程一个工序,建议生产部或研发部来做软件部署工作。 |
软件维护 | 软件系统发布后的更新需求予以实现 | 输出软件维护相关记录,注册过程中软件多个版本,配置管理没有相关记录,漏洞很明显。 |
软件停运(即软件退市) | 终止软件系统的销售和售后服务,售后服务停止时间通常晚于停售时间(后续用户服务、数据迁移、患者数据与隐私保护) | 输出用户告知等记录,现阶段还没有接触过退市的软件产品,软件停运管理规程及用户告知的记录单必须有。 |
四、软件测试、软件验证、软件确认
软件测试、软件验证定义的内容不做赘述,软件确认新增临床评价、设计评审,又要求确保软件已知剩余缺陷的风险均可接受。
五、软件可追溯性分析
软件可追溯性分析作为软件验证、软件确认的重要活动之一,是指追踪软件需求、软件设计、源代码、软件测试、软件风险管理之间的关系,分析已识别关系的正确性、一致性、完整性、准确性。要分析就需要软件可追溯性分析工具,很多企业说自己没有分析工具,一般企业的软件工程师医疗器械行业的法规标准不了解、不熟悉、不懂得,这就会造成他们有用工具但工程师们认为只是办公软件而已,不是可追溯性分析工具,这种现象很普遍,比如Word、Excel都可以作为软件可追溯性分析工具。有了工具就要有工具的使用管理规程制度,有了规程制度就应该有记录,所以你漏了哪些呢?
注册申请人应建立软件可追溯性分析过程,规范软件可追溯性分析相关活动要求,以保证软件验证、软件确认的质量。考虑到行业实际情况,源代码追溯分析活动追溯至软件单元(列明名称)即可。
六、软件更新
软件更新是指注册申请人在软件生存周期全过程对软件所做的任一修改,亦称软件变更、软件维护。软件维护通常与软件更新含义相同,但可特指发布后软件更新。更新维护重点医疗器械产品的安全性和有效性,还需要考虑现成软件组件和外部环境的更新,并开展外部软件环境更新的影响评估工作。目前大部分更新都是需要进行变更注册的。
七、软件版本
软件完整版本和发布版本,注册申请人应综合考虑软件产品特点、质量管理体系要求、合规性等因素制定软件版本命名规则并予以记录,明确字段的位数、范围、含义,涵盖软件更新全部类型,字段含义明确且无歧义无矛盾,能够区分重大软件更新和轻微软件更新,保证软件更新的版本变更符合软件版本命名规则要求。从医疗器械唯一标识(UDI)角度,软件完整版本属于生产标识(PI)的组成部分。现阶段很多小伙伴被发补过软件版本命名规则不清晰的问题,主要是含义不明确,范围不清晰,字段的位数有多有少不一致。还有一些则是软件界面上没有完整版本号或没有发布版本信息。检测报告提供软件版本界面照片或列明软件版本信息,有用户界面的软件体现软件发布版本、软件完整版本,无用户界面的软件体现软件完整版本。说明书注明软件发布版本。
八、软件算法、软件功能、软件用途
先上个关系图,看看软件算法、软件功能、软件用途之间的关系
软件算法是软件功能的基础,二者是多对多的关系,即一个软件算法可供一个或多个软件功能使用,一个软件功能可含一个或多个软件算法。同理,软件功能和软件用途的关系亦是如此。这里体现了质量管理体系的重要性及各部门之间的沟通。算法是研发技术人员熟知的,功能是研发技术人员设计实现的软件用途,注册人员是能看不能写,注册申报涉及算法研究的只能研发技术自己输出。
8.1软件功能分类还是做个表比比,话不多说看表:
分类角度 | 软件功能 | 描述 |
重要性 | 核心功能 | 软件在预期使用场景完成预期用途所必需的功能为核心功能,反之则为非核心功能 |
非核心功能 | ||
技术特征 | 处理功能 | 独立软件居多,前处理和后处理功能,主要采集人体解剖、生理信息生成的医疗数据处理功能和利用医疗器械数据生成诊疗信息或进行医疗干预过程的处理功能。 |
控制功能 | 软件组件居多,指控制/驱动医疗器械硬件运行的功能,兼具后处理功能。 | |
安全功能 | 保证医疗器械安全性的功能。 | |
监管范围 | 医疗器械功能 | 用作医疗器械界定依据的软件功能 |
非医疗器械功能 | 不属于监管对象 |
8.2软件算法
软件算法从重要性角度可分为核心算法和非核心算法,其中核心算法是指实现软件核心功能所必需的算法,反之即为非核心算法。从复杂性角度可分为简单算法和复杂算法,前者原理简单明确或基于成熟公式,后者通常基于模型研究,存在诸多假设条件且影响因素较多,同时二者在算法规模、参数数量、运算速度等方面亦存在差异。从可解释性角度可分为白盒算法和黑盒算法,前者可与现有知识建立关联,后者难与现有知识建立关联,前者可解释性优于后者。关于算法在自研软件研究报告中要明确算法类型、工作原理、临床用途,成熟算法还需要给出相关文献。全新算法需要给出相关验证。最常见的就是企业技术人员经过多次流动导致无法给出完整的信息,甚至可能工作原理都不知道怎么去描述。所以监管过程会注重企业人员流动情况,重点查看开发、测试、维护人员的履历和人员流动后管理流程如人员离职后权限的回收注销、技术成果的交接程序和记录。
8.3软件用途
软件用途通常可分为辅助决策和非辅助决策,其中辅助决策是指通过提供诊疗活动建议辅助用户(如医务人员、患者)进行医疗决策,如病灶特征识别、病灶性质判定、用药指导、制定治疗计划等,相当于用户的“助手”;反之,仅提供医疗参考信息而不进行医疗决策即为非辅助决策,包括流程优化、诊疗驱动,前者如诊疗流程简化等,后者如测量、分割、三维重建等,相当于用户的“工具”。同时,辅助决策和非辅助决策从实时性角度均可细分为实时和非实时,前者风险通常高于后者。故软件功能从软件用途角度又可分为辅助决策类功能和非辅助决策类功能、实时功能和非实时功能。
关于软件用途(理解为预期用途)独立软件按软件用途,软件组件则根据医疗器械产品的预期用途一致。
九、基本原则
9.1软件特性
15版本内几乎没有提到软件特性的内容,22版讲解了软件的特性,没有物理实体、软件测试不能穷尽、软件缺陷无法避免且不能除根、更新频繁且迅速、细微更新可能导致严重后果、存在累积效应和退化问题,结合更多软件专业的内容,使医疗器械软件的科学面又拓宽了,监管的内容又增加了。综合考虑风险管理、质量管理和软件工程的要求才能保证软件的安全有效性。注册申请人需基于软件风险程度,采用良好软件工程实践完善质量管理体系,针对算法、接口、更新、异常处理等软件召回主要原因,尽早、重点、全面开展软件质量保证工作。
9.2风险导向—软件安全性级别
软件安全性级别可结合软件的预期用途、使用场景、核心功能进行综合判定 。其中,预期用途主要考虑软件的用途类型(如治疗、诊断、监护、筛查)、重要程度(如重要作用、参考作用、补充作用)、紧迫程度(如危重情形、严重情形、普通情形)、成熟程度(成熟、全新)等因素,使用场景主要考虑软件的使用场所(如门诊、手术、住院、急救、家庭、转运、公共场所)、疾病特征(如严重性、紧迫性、传染性)、适用人群(如成人、儿童、老人、孕妇)、目标用户(如医务人员、患者)等因素,核心功能主要考虑软件的功能类型(如重要程度、技术特征、复杂程度、成熟程度)、核心算法(如重要程度、复杂程度、可解释性、成熟程度)、输入输出(输入数据如医学图像、生理参数、体外诊断等数据,输出结果如处理、测量、分析等结果)、接口(如应用程序接口(API)、数据接口、产品接口)等因素。
在软件安全性级别的判定上,除了上述的判定外还会有部分工作指导文件/制度明确给出软件的级别,一般这都是风险较高的产品如除颤仪(体外自动/半自动除颤仪)在《体外除颤产品注册技术审查指导原则》则明确标出“参考《医疗器械软件注册技术审查指导原则》的要求,应按照C级安全性级别来提供软件描述文档”。大家不管是编写质量管理体系设计开发文件还是编写注册申报资料一定要结合产品相关的所有的法规、标准全方位的考虑产品遵守的法规标准。否则法不对位,所有白费。
9.3全生命周期质控
重中之重:上市前开展充分有效的软件验证与确认活动,识别软件可预见的风险并将其降至可接受水平。上市后继续开展软件质量保证工作,结合用户投诉、不良事件和召回等情况识别前期未预见的风险,并采取必要措施保证软件质量;同时,基于软件更新需求的评估,实施软件更新活动以满足用户新需求,并开展与之相适宜的软件验证与确认活动,以保证软件更新质量;此外,软件停运考虑用户告知与后续服务、数据迁移、患者数据与隐私保护等要求。软件的发补近期发补内容越来越多,也越来越细致,之前经历过被发补补充软件版本命名规则、补充软件规格型号、补充技术要求未检测/漏检检验报告等这些比较显眼的内容,现在发补的内容比较精细了如补充产品工作原理,确定产品功能模块的作业,补充竞品信息,要求提供软件效期论证、有载体的需要按包装验证标准提供相关验证报告、补充系统测试报告维护性测试用例等等。审核老师越来越专用,越来越深入研究,所以企业必须同步学习共同进步,否则就被吊打的状态。
9.4现成软件
旧版已明确,新版又重申了,可见现成软件对产品的影响还是很大的,根据本指导原则要求,我们对现成软件需进行管理,很多企业只管给个《现成软件的管理规程》却忘了这些现成软件的采购,关于采购可加入在《采购控制程序》也可以单拎出来《现成软件采购管理规程》,只要有如何分类、供应商审核再评价、如何进行验收确认、记录怎么处置,不管是在《采购控制程序》还是《现成软件采购管理规程》都可以,只要不忘就行。
暂无评论