独立医疗器械软件的质量管理体系的思考建议

2019-09-09胡凯杨辉沈亦红张丹

中国医疗设备 2019年9期

胡凯，杨辉，沈亦红，张丹

浙江省医疗器械审评中心，浙江杭州 311121

引言

近年来，随着制造业技术升级和“人工智能”“互联网+”等概念的普及，医疗领域的智能化和信息化已大步向前迈进。医疗器械软件，在医疗智能化和“互联网+医疗”中占有核心地位。FDA 已审批了多种预期用途的医疗器械软件，举例：① 直接诊断和检测疾病，如脑脊液光谱数据分析来诊断儿童肺结核或病毒性脑膜炎；② 通过连接控制实体医疗器械，对患者实行治疗，为治疗和缓解耳鸣提供声音治疗；③ 辅助诊断决策支持，使用个体数据预测进展性卒中或心脏疾病的风险系数；④ 医疗数据管理，医学图像传输与存档。

而软件本身独特的非实体化存在的形式，其质量管理工作给医疗器械从业人员带来不小的困惑。据相关文献报道，1999～2005 年，FDA 共有3771 个产品被召回，由于软件故障被召回的产品有425 个，占全部被召回产品的11.3%[1]。2015 年，西门子公司的PACS 产品因打印配置文件与打印机不匹配导致打印图像尺寸失真而被召回。2017年，Spacelabs Healthcare 公司的麻醉气体输送系统中的软件，因在送气故障时未显示故障及报警而被召回[2]。软件工程领域已有管理方法的探讨[3-4]，但针对作为医疗器械的软件，未有正式的管理规范结合医疗器械相关要求（截至收稿时）。可见，如何科学有效的管理医疗器械软件是一个意义重大的课题。本文将通过对相关国家的生产质量管理规范的探索，对ISO 13485 和IEC 62304 等标准进行讨论，结合软件生产企业的实际检查，给出初步建议。

1 医疗器械独立软件生产管理过程的特点

软件作为逻辑产品不具有实体。它渗透了大量的脑力劳动，人的逻辑思维、智能活动和技术水平是软件产品的关键。软件通常以程序和文档的形式保存在作为计算机存储器的磁盘和光盘介质上，通过操作计算机才能体现出它的功能和作用。以上特性决定了软件具有以下特点。

（1）生产与研发紧密结合，生产过程趋于扁平化。软件产品的人力资源和成本主要集中在软件的开发和研制上。如果把代码理解为“零件”，模块理解为“组件”，那么编译并封装就相当于成品的“组装”。软件开发研制完成后，通过复制就可以产生大量的软件产品，不需要投入大量的人力和设备构建生产线，相对地会在后期维护中升级。软件产品不会用坏，不存在磨损、消耗等问题。

（2）研发元素的多元化。第一，软件开发商会依据客户需求，制定研发计划并编写代码，而客户需求会依据主客观环境的不同有区别；第二，软件开发过程可能会使用第三方产品或技术，如现成软件[5]、开源API[6]，融入产品本身或配合产品使用；第三，不同开发商的基础数据库数据来源不同。如骨密度检测软件基于不同的适用人群会有不同的临床数据库人群分布[7]。

（3）售后安装及使用情况多变复杂。不同的使用者，其使用的网络、信息设备、终端、系统软件不尽相同。软件开发商在为客户安装的时候，可能会根据使用者现有信息接口的不同，对软件中间件[8]做出相应的调整。现有版本软件的小升级、大升级、后续版本开发等工作，是独立软件产品全生命周期质量管理的重要内容。因此，同一企业的同一软件产品可能存在多种有细微差异的“版本”。

2 目前存在的管理难题

2.1 由于生产过程扁平化及高灵活度导致难以全面记录

设计开发和生产有合并的趋势。在设计研发阶段输出成果（代码）后，企业根据软件载体的不同，采用不同的生产方式。实体载体如光盘，通过拷录电脑进行拷贝。虚拟载体形式则将软件产品上传至服务器，通过使用者或装维人员自行下载。在现场检查过程中，管理人员可能对于最终软件成品的拷录电脑或存储服务器，缺乏相应的使用管理，具体表现为：现场拷录电脑不固定、未进行安全验证、没有使用记录，存储服务器缺少安全验证等。《医疗器械生产质量管理规范现场检查指导原则》（以下简称《检查指导原则》）中，“设备”“文件管理”“生产管理”均有涉及上述内容，如3.2.1、3.2.3、4.4.2、7.5.2、7.6.1 等条款。

2.2 研发要素多元化、更新快导致的过程评价不及时

评价不及时体现在：① 对第三方软件或开源代码缺少评价与验证，研发人员利用开源代码直接嵌入；② 由于软件的需求变化较快，软件的更改未得到及时的评价；③ 核心算法中的经验系数，缺少临床确认记录。在企业的体系文件中，IEC 62304（YY/T 0664）、《医疗器械软件注册技术审查指导原则》《医疗器械网络安全注册技术审查指导原则》等往往作为法规标准的研发输入，但企业往往未实际按照以上标准建立评价过程和记录。在《检查指导原则》中，“设计开发”章节较多的涉及此内容，如5.2.1、5.6.1、5.9.1、5.10.1 等。

2.3 售后体系对已售出的产品实施的追溯和控制容易被忽视

售后支撑人员依据客户现场的实际情况，对产品本身可能做出的调试性修改，但不能有效记录；不同客户可能具有细微差别的产品，版本管理不能有效识别这些差异。

由于上述过程的疏忽，直接导致对应的信息安全风险不能有效识别，举例有：第三方和开源API 对患者信息的处理流程不清晰，导致人种、人群数据被窃取；企业代码被内部人员恶意窃取/修改；因内部代码管理服务器被入侵而导致产品遭恶意修改；已售产品版本管理混乱导致的未能及时升级补丁造成的漏洞等。

3 强化执行医疗器械独立软件生产质量管理法规和标准的建议

3.1 医疗器械企业质量体系建立

在我国，医疗器械独立软件在2002 版医疗器械分类目录编码为“6870-软件”，2017 年发布新版目录中为“21 医用软件”，属有源医疗器械。其生产质量体系需满足总局2014[64]号文件《医疗器械生产管理规范要求》。

美国FDA 医疗器械的分类由21 CFR（美国联邦法规第21 部分）进行列举，未给医疗器械软件单独的CFR 编码。软件根据风险等级分为Class III-I，申报PMA/510K 或豁免。产品需满足 21 CFR 820 的要求，即QSR。其中对于510k 产品，FDA 会视情况对企业进行文档或现场审核，PMA 需现场审核。

欧盟的产品分类方式为“基于规则（By Rule）”，即无分类列表，只阐述分类原则，医疗器械独立软件根据风险可能分为I、IIa、IIb、III。其质量管理体系需得到公告机构的认证，建议使用欧盟的协调化标准（EN ISO 13485）要求。

IMDRF 在综合了多国的法规要求基础上，出台了独立软件质量体系要求，该文件同时为FDA 的等同性指南，我国也是该组织的参与国。

医疗器械企业质量体系的建立参照ISO 13485（YY/T 0287）的要求，同时其设计研发过程应当满足IEC 62304（YY/T 0664）。IEC 62304 附表部分给出了两大标准的对应关系。在此基础上，笔者增加了新版ISO 13485 等部分内容，但并非完全列举，见表1。

上述表格中，主对比列为“IEC 62304- ISO 13485:2003”，出自IEC 62304 附表部分内容。“ISO 13485:2016”列增加的对比项为相比“ISO 13485:2003”的改版增加的“设计开发转换”“投诉处理”“安装活动”等内容，依据“IEC 62304- ISO 13485:2016”条款文字表述进行填写。“IMDRF”列内容为在“IMDRF/SaMD WG/N23”（下文简称WG/N23）文件基础上，并结合条款表述进行填写。“中国《规范》”列为基于WG/N23 文件的映射提示。

3.2 建议

结合IEC 62304、ISO13485 并基于WG/N23 对软件实现的定义划分，针对前文所述的管理问题，提出以下两方面综合建议。

3.2.1 强化各过程的评价措施

（1）设计、开发。设计活动旨在基于用户等需求确定软件系统的架构、组件和界面，并且与独立软件预期用途及计划运行的各种临床和家庭使用环境相符。开发活动将需求、架构、设计（包括接口定义）、公认的编码操作（安全）及架构模式转化为软件项，并将这些软件项整合进独立软件中。WG/N23 的7.6 部分指出，开发商可以基于其内部优势和能力选择将其独立软件的不同部分外包；也可以采购商用现货软件（Commercial off the Shelf，COTS）或另一个独立软件来纳入其产品中。可见，了解、维持控制并管理这种外包过程、活动或产品的影响是重要的，并且对于交付安全有效的独立软件是必需的。举例，在开发阶段采用必要的科学检测模型来杜绝开发人员对未知来源的开源代码复制到独立软件产品中，如基于修改日志克隆代码跟踪及演化模式识别[9]。

表1 医疗器械企业质量体系建立新增内容对比

（2）验证和确认。验证和确认活动的目标应该是独立软件对患者安全的影响及危险程度。WG/N23 的8.4 指出，验证和确认活动应该将重点放在独立软件与操作系统、外包组件及与计算平台相关的其他相关性的接口上，充分考虑到以下因素：患者安全和临床环境、技术和系统环境。如针对日益移动化的医疗场景，匹配独立软件产品与移动终端的信息安全考虑，可建立匹配开发商独立软件产品的模型对其进行评价[10]。

（3）部署、维护。部署活动包括支持独立软件受控、有效地分发给客户的交货、安装、设置和配置方面，包括针对独立软件整个生命周期支持过程和实现使用过程中识别的危害的任何计划的风险缓解措施。维护活动可以是来源于软件生命周期过程和活动的适应性、改善性、预防性和纠正性活动，或基于用户需求或社会-技术环境的改变。采用合适的问题分析框架，对软件系统部署方法和技术的选择及开发具有重要的指导意义，如W4H[11]等。

3.2.2 提供合理的软件开发工具及相关管理软件

WG/N23 的6.2 部分指出，基础设施包括在生命周期过程中提供模拟预期使用环境的测试环境及支持管理各种软件配置的工具，比如，开发期间针对源代码的版本管理。7.4 部分指出，在独立软件配置的管理中，软件工具通常用于管理源代码、发布、记录、部署、维护等。常用的测试软件工具举例：白盒测试工具giscope、DevPartner；黑盒测试工具LoadRunner、Quantify；测试管理工具TestDirector[10]。常用项目管理工具：SVN[13]，GitLab[14]等。