24小时服务热线：19103801095
NEWS CENTER
Recommend case
contact us
国药局在2019年7月5日发布了第43号公告《医疗器械生产质量管理规范附录独立软件》，并明确有关企业应在2020年7月1日期实施。2020年6月4日，国药局综合司又发布了《医疗器械生产质量管理规范独立软件现场检查指导原则》。结合之前国药局发布的“软件注册指导原则”和“网络安全指导原则”以及具体软件产品的注册指导原则，形成了一个对医疗器械软件和/或软件组件较为完善的质量管理体系要求。
本文是结合笔者对软件企业审核发现的问题，与业界同仁探讨医疗器械软件开发过程中的一些问题和软件开发应考虑的事项。
“规范附录”1.1节明确指出：“适用于独立软件，软件组件参照执行。”大部分有源企业的产品中，是包括作为控制、显示、驱动、报警等用途的微机系统的，该类系统符合规范3.1节术语“软件组件”的定义的。也就是说，大部分有源产品是应该适用这个法规的。某些被审核企业，没有识别到这一法规的要求，或者虽然识别了该法规，但仅仅将其纳入设计开发的一部分，建立了一个简单的管理制度应付了事，未将该法规要求融入到公司整个质量管理体系作为一个整体来考虑，因此，体系是不符合法规要求的。
但是，法规也规定软件组件“参照执行”。本人理解，这段话的含义是要求企业自己识别该法规中具体条款的适用与否。这种识别活动应由专业人员和合规人员共同进行。例如，很多医疗器械设计时不涉及与网络相连接，则与网络连接安全的部分条款可能并不适用。
很多软件产品缺陷众多、兼容性差很难满足顾客需求和法规要求，甚至在设计开发过程中半途夭折，这与软件策划阶段考虑问题的完整性不够有重要关系。软件是一种特殊产品，在起始阶段没有考虑完全，后期修补是很困难的，即便能完善，也会增加几倍的人力物力。为此，软件开发策划应关注如下问题：
很多软件设计开发失败，在于程序员没有和顾客顺畅的沟通，没有充分理解顾客的真实需求，或者没有理解顾客所描述的流程内容。
一个工作流程、操作流程、涉及的部门、涉及的硬件和软件接口表面看是比较简单，实际有很多细节在里面，这很可能需要做一个多维的图表来描述这些流程。同时，要考虑较多的分支和算法。
应考虑由顾客、开发组共同组成需求小组将所有可能的操作流程、软硬件需求和相关的接口并以图表的方式予以记录可能是恰当的。
不同产品涉及不同的应用（预期用途），要由法规和标准归口部门收集整理相应的法规。目前国药局出台了一些通用法规如第50号通告“软件注册审查指导原则”、第13号通告“网络安全注册审查指导原则”等，还有一些涉及具体产品的法规如“PACS注册审查指导原则”等。地方监管机构如北京局也出台了一些软件注册法规，企业也应及时收集。此外还要考虑软件的一些通用的标准如GB/T 25000.XX“系统与软件质量要求和评价系列标准”等。这些法规和标准，给出了软件设计时应考虑的一些涉及安全、质量的一般要求，因此，法规标准收集应尽可能全面，否则在医疗器械软件产品注册时无法通过审评。
企业可将法规标准所附的全部引用参考文件列出清单，逐一收集，并组织专业部门及项目组评价适用性后，转设计研发部门。
生存周期模型分别适用于不同类型的软件产品，选择什么样的生存周期模型，与软件产品、公司经营模式、设计开发团队技能有较大关系。
如果企业产品无特定的顾客，喜欢稳扎稳打的方式，可以考虑瀑布型的模型。
如果顾客对软件开发进度比较关注，且能提供随时的沟通，可以考虑采用敏捷方法，随时交付一部分完成的项目。
目前大多数企业选择的是V模型。V模型明确了需求与测试对应关系。便于查找问题，以及明确节点要求。
无论何种模型，国药局第43号公告《医疗器械生产质量管理规范附录独立软件》中均规定了企业应建立的文件化要求（20个）和记录要求（15类），企业应严格按照该法规的要求，结合企业特点，将其融入到企业原有的质量管理体系中去，加以实施和保持，并不断改进。
软件作为一种特殊“产品”，其特点是“无形”。既然摸不着看不到，有些缺陷问题，除了通过测试发现以外，往往在使用中才能发现。
仅仅用YY/T 0316标准附录的部分提示来对软件进行风险分析是不够的，因为软件不仅仅是本身存在风险，还有配合的设备接口、软件编程中溢出、算法错误、硬件意外等诸多情况。可考虑YY/T 1406.1等与软件相关的风险管理标准中的内容作为危害清单输入，并结合公司知识管理库中的一些问题来进行分析，评价，采取适当的措施，并保持定期更新。
医疗器械产品是一种特殊商品，关系到人的生命安全，所以我们设计时考虑的软硬件的选择应该是稳妥的、通用的。那些过于追求新的平台，甚至国外都在试验中的平台只适于科研，不一定适于做医疗产品。这里也包括目前大量企业在试水的云技术、云算法。使用这些新技术应该保持慎之又慎的心态。
同时，医疗软件产品未来不仅仅是大的医疗单位在使用，根据社会发展，还有可能在偏远地区使用，这时候更应该注意那些区域的信息技术的现状。
根据目前本人所审核的软件企业设计开发过程来看，大部分企业对文档的编制和保存不重视，保留的文档本身也不够完善，这将导致企业未来再对产品做更新、重编等工作或者发生不良事件等情况时，无法提供很好的溯源，无法查找策划是否有问题。重视设计文档管理应该说是国际企业的一大特色。因此，企业应指定专门的人员编写、收集、补充完善需求规格文档，这类专门人员应具备质量管理、法规意识和设计开发的一些基础能力。具体可依据“规范”、GB/T 9385等标准来实施。
企业应依据“规范”要求建立软件配置管理文件，具备能力和条件的的可使用相关的软件如CVS、VSS等。企业应对每一软件版本建立统一的基线，包括规格说明、软件代码、打包的现成软件等。
目前审核中发现企业在软件设计过程中，对软件版本管控比较随意，开发过程版本和最终的发布的版本对应性不强。企业应关注国药局软件注册法规中对版本的要求，结合企业自身情况，规范好软件版本管理和更新要求。
企业的程序编制人员来自不同的院校，接受不同的培训，使用不同编程工具。因此，企业应建立较为科学、完善的程序编制要求，统一管理软件编程活动。如命名规范、语句规范、注释规范、编码规范等。
目前国内的企业对于设计开发过程评审失于策划的情况比较多，即便有策划，记录缺失也比较严重。企业应关注软件设计过程的评审活动，特别对于敏捷开发来讲，有顾客和法规人员参与的评审小组对于软件开发成功与否是至关重要的。同时，项目组长应关注策划时规定的评审节点，及时敦促相关部门人员参与评审。
软件测试是医疗器械软件开发管理中相对重要的一环，在这个阶段发现、修复、完善的软件缺陷越多，软件后期的问题就会越少。所以，全面地策划软件测试活动，对于软件设计开发过程尤为重要。为此，应关注如下方面：
随着医疗产业的不断更新换代，越来越多的信息技术应用于医疗器械产品，给医疗器械的研发活动带来巨大挑战。同时，在软件测试过程中，设计到的软件接口众多，有HIS、LIS，有UNIX大平台、Windows系列平台，甚至还有很多企业使用安卓技术，WIFI和蓝牙技术，真可谓百花齐放。
笔者在审核中发现很多企业的医疗器械软件产品在使用说明书中声明应用在多平台，甚至云平台。但是，查阅企业的测试资料却发现，企业仅仅在某一最新平台进行测试，并声称向下兼容，而且有些企业还在使用非授权软件（包括操作基础平台和数据库平台）。应该说这样的测试验证的结论是不准确、不完全的。
医疗器械软件验证活动应考虑声明的所有操作基础平台，甚至同一基础平台的32位版及64位版本。还应考虑编程及打包工具、数据库、（微系统）编译器、网络环境（WIFI、蓝牙、Internet）、编程语言、硬件环境、软硬件接口，当然可以考虑使用统计技术进行优化，但优化必须是经评审的、科学合理的，并能提供相应的说明文档。
“斯诺登事件”和各大网购平台的多起安全事件表明，现在的网络安全收到了极大挑战，而医疗器械产品第一要求的就是“安全”。而很多医疗器械软件产品又必须和公网相连。所以软件企业应策划好软件的网络安全测试，包括规定好软硬件防火墙要求，并在编程中考虑攻击强度测试。企业应关注国药局第13号通告“网络安全审查指导原则”中对“网络”的定义和对软件产品涉及网络安全的要求。
作为软件产品的通用属性，尽管现在各机构配备的硬件设施已经较为强大完善，但是效率、可靠性、容量、强度等通用软件的要求仍应作为医疗器械产品的重要特性并在验证中加以测试。这直接关系到医疗器械“有效性”，如时间可能关系到患者的生命。
软件产品要做到无任何漏洞和缺陷几乎是不可能的，我们从微软及谷歌安卓产品的快速更新中就可以体会到这一点。因此积极收集顾客信息和更新的法规，不断评估产品缺陷和风险，持续更新是软件产品特别是独立软件产品一项非常重要的工作。此外，企业应关注软件操作基础平台（操作系统、云平台）的更新，评估相应的风险。
作为企业知识管理和上市后质量管理的一部分，医疗器械软件生产研发企业应从顾客反馈中汲取经验教训，不断完善企业质量管理体系。
总之，医疗器械软件设计开发过程应牢牢把握相关法规要求，从设计开发策划到上市后监督每一步均应切实法规要求，才能持续保证软件产品质量。
来源：CMD-唐立春
站点声明：
本网站所提供的信息仅供参考之用,并不代表本网赞同其观点，也不代表本网对其真实性负责。图片版权归原作者所有，如有侵权请联系我们，我们立刻删除。如有关于作品内容、版权或其它问题请于作品发表后的30日内与本站联系,本网将迅速给您回应并做相关处理。
北京飞速度医疗科技有限公司专注于医疗器械、诊断试剂产品政策与法规规事务服务，提供产品注册申报代理、临床合同(CRO）研究、产品研发、GMP质量辅导等方面的技术外包服务。
