引言
随着医疗机构对医疗器械智能化要求不断提升，独立软件在临床诊疗中的应用越来越广泛。相比医疗器械硬件，独立软件产品对场地要求较低，对设备要求单一，企业投资成本相对较低。近年来，国家鼓励生物医药产业发展的相关政策陆续出台，上海市独立软件生产企业的数量呈逐年增加的态势。为了规范医疗器械软件监管，国家药品监督管理局于2019年发布了《医疗器械生产质量管理规范附录独立软件》[1]（以下简称软件附录），并于2020年7月1日起正式实施。与《医疗器械生产质量管理规范》[2]相比，软件附录基于软件特性及生存周期特点，对软件质量管理体系要求进行了明确和细化。一方面，软件附录的实施，对于提升医疗器械软件开发水平，以及软件监管的科学规范性起到了积极的推动作用。另一方面，通过软件附录的实施，发现企业对软件附录要求的理解存在偏差，实施过程不够规范，产品质量与风险意识淡薄等诸多问题。
本研究统计自2020年7月软件附录实施以来的3年间上海市医疗器械软件企业现场核查中所发现的不合格项，深入分析占比最多的软件设计开发相关问题，具体如下。
1 医疗器械软件现场核查问题及分析
1.1 近3年本市医疗器械软件现场核查情况
自2020年7月软件附录实施至2023年8月，上海市医疗器械化妆品审评核查中心对本市40家医疗器械独立软件企业开展了注册核查，共涉及软件产品64件，其中二类产品52件，三类产品12件。现场核查发现不合格项合计408个，其中关键不合格项81个，约占20%。基于软件产品类别的产品数量和不合格项数量分布如表1所示。
表1可知，现场核查软件产品中，医学影像类软件产品35件，占55%，主要包含医学影像处理软件、医学影像存储与传输系统（picture archiving andcommunication system, PACS）。核查发现不合格项合计229个。计算机辅助诊断软件产品9件，占14%，均为三类医疗人工智能软件，主要包含新冠肺炎、颅内出血、肺部疾病、冠脉狭窄、眼底疾病等辅助诊断软件。核查发现不合格项合计36个。2020年7月至2023年8月的现场核查中，单次核查发现不合格项数量最多为15个，最少为1个。单次核查重点项最多为4个， 最少为0个。单次现场核查平均不合格项数量约为6个，平均重点项数量约为1个。
1.2 本市医疗器械软件现场核查问题及分析
1.2.1 本市现场核查不合格项汇总分类
按照软件附录各章节，对1.1节独立软件现场核查的不合格项进行了如下分类：不合格项出现最多的依次为设计开发（282个）、生产管理（28个）、质量管理（22个）、机构与人员（18个）、设备（13个）、文件管理（13个）、采购（12个）、其他（含厂房设施、不合格品控制、不良事件检测、销售与售后）（共20个）。设计研发部分不合格项约占69%，重点项出现最多的为设计开发，共有64个，在研发设计部分中约占23%。软件附录中设计开发章节条款最多，也是软件生存周期中最为重要的部分，因此设计开发部分不合格项出现频次也相对较多。
设计研发是实现软件本体的重要环节，进一步分析设计开发部分的不合格项，其在软件附录设计开发各主要规范部分占比情况如表2所示。
设计开发部分不合格项数量总共为282个，从表2可知，设计开发中占比最高的前5位依次为软件测试、软件配置管理、软件需求、软件设计、软件缺陷管理，上述5项共占76.2%，剩余占比依次为现成软件、软件可追溯性、软件风险管理、软件生存周期控制。
1.2.2 现场核查共性问题分析
对于上述设计研发中不合格项最多的5个规范部分，问题分析如下：
1.2.2.1 软件测试
（1）核查发现测试用例描述较为简单、缺乏规范性、对主要功能覆盖不充分、可操作性差、无法实现与需求和设计的追溯等。另外，标准测试数据、测试工具不明确或未经有效验证。例如，医学影像处理软件对DICOM3.0符合性验证不充分，这可能导致由于DICOM属性值错误引起误诊风险；对于含长度、角度、面积及体积等指标测量功能的软件，由于未对测量准确性进行有效验证，或者由于测量方法和使用工具不明确或不规范，会导致无法保证测量精度满足要求；对于某些计算指标，如脂肪浸润平均值、冠脉钙化积分值等，未对计算准确性进行有效验证，可能会影响诊断结果；对于需与其他医疗设备配合使用的软件，未对所声称适用机型进行验证。例如，中央监护软件的测试报告中未包含所支持呼吸机机型的相关验证，未能保证在各模式下参数正确显示以及及时报警。
（2）核查发现系统测试用例未覆盖已识别的软件相关风险，无法实现与风险管理间的追溯。例如，肺部CT影像辅助诊断软件的软件测试用例中未涵盖已识别风险项目——肺叶肺段定位准确性相关内容，可能会导致风险无法有效控制。
（3）核查发现测试用例中未考虑边界测试、错误推测测试、压力测试等常见测试类型，例如，实际需求规定输入参数范围为0.01~99 mm，测试用例中却为1.0~80 mm，未考虑上下限情况，导致边界验证不到位；未考虑错误用例，导致无法确保超过安全阈值时系统提示正确警示信息。
（4）核查中还发现软件测试报告存在记录不规范、后补记录的情况。例如，核查某产品的单元测试报告，未查见部分项目的测试结果，缺少测试及审核人员签字；原始测试记录中测试时间为2023年4月6日，记录时间为2021年2月23日，记录时间存在矛盾。
1.2.2.2 软件配置管理
软件配置管理是通过执行版本控制、变更控制的规程，以及使用合适的配置管理软件，来保证所有配置项的完整性和可跟踪性。软件配置管理涉及4个紧密相关的活动：变更管理、版本管理、系统构建、发布管理。
（1）现场核查中发现多数企业配置记录存在缺失或不充分的情况，未对现成软件、软件开发文件、数据集进行配置管理。特别对直接用于实现医疗器械预期用途的现成软件，配置管理显得尤为重要。尽管多数现成软件不直接用于实现医疗器械预期用途的相关功能，但由于与周边模块的耦合关系可能会对医疗器械软件运行产生影响。
（2）核查中发现企业在软件发生变更后，未按照软件版本命名规则对变更进行有效的版本控制。例如，对于完善型变更，完整版本号中却显示纠正型变更位发生变化，导致未对该完善型变更进行有效控制。在软件发生完善型变更后，存在未及时对软件需求等相关文件做必要的更新。
1.2.2.3 软件需求
（1）核查中发现企业普遍对软件需求分析不够重视，未进行充分、必要的需求分析，设计输入不完整。例如，对测量精度要求未予以明确；影像软件不支持患者信息、体位信息、采集及图像参数等内容的四角区域显示。这些会导致在诊断过程中，医生无法及时获知患者信息及采集参数、体位信息等内容。若性能和测量精度不满足要求，会影响临床诊断结果及效率。此外，核查过程中发现需求缺乏对可用性及非功能需求的描述。例如，医学影像处理产品对CT图像导入、图像重建性能未予以明确；中央监护软件需求中未明确所支持的监护仪、呼吸机以及血气机等设备品牌及型号，以及所支持的外部医疗器械软件种类；医学影像处理软件需求中未明确用户界面、操作方式及输入信息的约束条件，未禁止移动终端操作系统的某些内置功能，导致影响正常操作，甚至出现软件崩溃的情况，大大降低了可用性和用户体验。
（2）软件需求描述与软件功能存在不一致情况。例如，医学影像处理软件需求定义输入图像可以支持由PACS系统远程获取，实际产品演示时发现只能从本地硬盘导入等；核查时看见鼠标右击超声影像处理软件的菜单会出现循环、视频另存、画中画、投影等软件需求文件中并未描述的功能。
1.2.2.4 软件设计
（1）核查中发现产品的软件设计文档存在架构不清晰、内容不充分、无法追溯等问题。例如，缺乏数据库、移动端前端等相关设计内容；设计中未充分考虑产品风险，无法实现与软件需求间的追溯；监护类软件设计中未明确外部支持系统的接口通信协议（如消息队列遥测传输协议等）、监测数据格式、呼吸机通气模式参数以及网络安全等要求。
（2）核查中还发现设计内容与实际产品存在不一致的情况。例如，软件详细设计文档中数据库医生列表的元素类型有12个字段，企业修改产品后未对设计文档进行同步更新，导致实际查见软件实现为16个字段；设计文档中的核心算法设定参数与实际软件代码中的不一致。
（3）对软件核心算法描述不充分或缺失。例如，心电分析软件的设计文件中未查见疑似房颤、疑似节律异常特征参数、相关阈值以及分析算法的详细说明；对深度学习算法，未明确训练、验证及测试等数据集的构建要求。
1.2.2.5 软件缺陷管理
如果软件在执行过程中遇到缺陷，可能会导致软件产品失效[3]。软件缺陷通常可分为需求、设计、文档、算法、界面及性能等6大类型[4]。
（1）现场核查发现，企业普遍存在对软件缺陷管理松散、对软件缺陷随意修改、回归验证不充分等情况。软件缺陷管理文件未对缺陷分级分类、缺陷原因分析、回归测试、评审批准等活动予以明确要求，缺乏对缺陷进行有效管理控制。缺陷管理记录内容不充分，且缺乏评审及批准记录。
（2）核查中发现一些企业用Excel表格进行软件缺陷管理，但Excel无法实现软件协同管理，也缺乏软件流程管理功能，如果较大规模团队使用的话，会存在效率低下、容易引发混乱等问题。
2 讨论及建议
软件是基于人的创造性活动所产生的成果。软件附录[1]要求软件开发人员具备与岗位职责要求相适宜的专业知识、实践经验和工作能力，且接受过相应的培训。软件开发过程控制对软件产品质量尤为重要，企业可按以下原则[5]选择适宜的软件开发模型：①对需求明确的简单软件产品，宜选择瀑布模型。②如果开发时间是首要考虑因素，那么宜选择快速应用程序开发方法。③如果最初需求不清晰，那么宜选择易于明确需求的原型模型，或选择允许需求不断完善的螺旋模型。④如果对安全使用要求较高，那么宜选择可通过反复验证和确认来保障软件产品安全可靠的V模型，或选择基于结构性风险管理的螺旋模型。⑤如果软件需求变化频繁、结构复杂，且需快速交付，那么宜考虑敏捷开发方法，它是以人为核心、迭代与增量相结合的一种软件开发方法。企业应在软件生存周期控制文件中明确所使用的软件开发过程模型（或方法），及相应的控制流程和控制要求。
针对1.2节所分析的现场核查中软件开发的主要问题，提出以下应对措施：
2.1 软件测试
软件测试是确保医疗器械软件安全有效的重要环节之一。软件特征决定了软件缺陷是不可避免的，软件测试用例质量会直接关系到发现缺陷的能力。软件系统各部分的缺陷分布是不均匀的，根据帕累托法则，80%软件缺陷出自大约20%的软件代码，缺陷分布密度主要取决于所在软件代码的复杂性。
针对以上特点，软件测试应考虑以下方面：①因为软件测试条件无法穷尽，所以应在单元测试、集成测试、系统测试、用户测试各环节强化用例设计，并依据YY/T 0664−2020[6]对各环节软件测试的充分性实施评价，保证软件测试用例与软件需求、风险管理间的可追溯性。②单元测试环节尽可能提高代码覆盖率，至少应保证复杂结构、核心算法、风险等相关部分的代码全覆盖。③应加强对关键现成软件的质量控制，确认供应商的软件发布信息以及软件测试报告相关内容，或企业可自行写测试脚本对现成软件进行相关测试。④在设计测试用例时，确保用例的可操作性和有效性、测试数据及工具的规范性。测试用例应涵盖测量功能、核心算法、适用机型和外部支持软件验证等相关内容。此外，应设计与输入边界、警告警示、性能等需求相对应的边界测试、错误推测、压力等测试用例。在用例设计时，不只考虑单一条件，还应考虑复合条件的情况，以提升测试用例的质量。⑤应持续对测试用例进行更新及评审，不断增加新的测试用例来提升测试用例的发现缺陷能力。⑥应考虑重点基于风险的随机测试策略，根据测试结果，必要时进一步更新完善软件测试用例。随机测试通常是对其他软件测试方式的一种有效补充，让不同角色人员参与软件随机测试可提高发现软件缺陷的能力。⑦企业应确保软件测试报告的规范性，报告至少应包含被测软件完整版本、测试条件、测试结果、相关人员（测试、审核以及批准）签名及日期等内容。
2.2 软件配置管理
软件配置管理文件应明确软件版本、源代码、现成软件、技术文件、开发工具、数据集等控制要求，确定配置标识、变更控制、配置状态记录等活动要求，并保存上述活动记录。
根据GB/T 32422−2015 软件异常分类标准[7]，软件变更有以下3种类型：①纠正型变更是修复缺陷所需的变更，包括用户测试、内部测试及其他方式发现的缺陷。②适应型变更是使软件适应环境所做的变更。环境是指可能影响系统的所有外部软硬件条件。例如，硬件/软件基础平台、任何业务规则等。③完善型软件变更是指通过添加新特性或功能改进软件组件的变更，包括因新的功能需求和非功能需求引起的变更。
对发现的软件缺陷，应进行正确软件变更类型分类，根据版本命名规则进行正确的版本控制。对完善型软件变更，必要时更新风险分析、软件需求、设计、测试用例等技术文档。对变更后的软件，更新完善测试用例，实施充分的回归测试，降低引入新缺陷的风险。所有变更及验证记录均应保存，保证充分、完整、可追溯。
为了提升软件配置管理的有效性和效率，可通过Rational ClearCase、Microsoft VSS、开源软件（SVN、CVS、GIT等）等配置管理工具实施，在软件变更后，便于实现追溯，以及对软件版本的有效控制。
2.3 软件需求
软件需求是描述系统应该做什么，系统提供的服务以及相关的约束条件[8] 。软件需求的识别、分析、记录和验证对于确保医疗器械软件的安全有效非常重要。由美国与欧洲软件工程研究者主导的一项研究表明[9]，在医疗软件开发出现的问题中，软件需求相关的约占63%。其他相关研究也表明[10]，需求分析不充分、需求描述不完整且不准确、需求无法追溯、需求变更未能有效管理都是软件产品开发失败的主要原因。
企业应在软件策划阶段实施充分的需求和风险分析。需求的输入源通常为临床用户要求、已上市同类产品、现行技术标准、文献等。软件需求应包括功能和性能、输入/输出、与外部系统接口、软件报警及警告信息、信息安全、用户界面、数据定义和数据库、操作维护、法规及技术标准、风险控制措施等内容。需求应明确用于诊断的测量功能的精度要求以及临床应用功能。网络安全应参照《医疗器械网络安全注册审查指导原则》[11]相关要求。非功能性需求通常比单个功能性需求更为重要，若其不能满足，则意味着系统无法使用。软件需求如有变更，应更新软件需求文档，确保软件实现与软件需求的一致，且应保存变更履历、评审及批准记录。此外，软件安全性级别应当在采取风险控制措施之前，结合软件的预期用途、使用场景和核心功能进行综合判定[12]。企业应按照GB/T 42062−2022[13] 的要求进行风险分析、风险评价、风险控制等风险管理活动。
2.4 软件设计
软件设计是后续开发步骤和维护工作的基础，是构建稳定软件体系结构的重要保障。设计质量直接影响软件产品的质量和用户对最终软件产品的满意程度。据统计，软件50%~75%的问题是在设计阶段导入的[14]，其修复成本会随着发现时间的推后而增长。
软件设计应确保设计内容充分、涵盖已识别风险、实现与需求、源代码的可追溯。软件设计应根据已确立的软件需求来实施软件架构、功能、性能、算法、接口、用户界面、单元、网络安全等相关内容设计，且应符合相关现行标准。应通过伪代码、流程图、类图等工具清晰地描述软件算法，算法设计应包含计算公式、模型结构、关键参数、算法流程等主要内容。人工智能算法相关数据集设计中应考虑数据采集、数据整理、数据标注、数据集构建等活动的质控要求[15]。必要时应更新软件设计文件，确保软件设计描述与软件实现保持一致。应保存设计过程中的审核及批准记录，记录应完整、可追溯。
2.5 软件缺陷管理
软件缺陷管理是软件质量保证的重要环节之一。企业应在软件缺陷管理文件中明确缺陷提交报告、缺陷分析及修复、缺陷管理流程、回归验证测试、风险管理、配置管理等要求。缺陷提交报告内容应至少包括缺陷类型、严重程度、优先等级、缺陷状态、软件版本、提交人及日期等信息。软件缺陷分析报告应包括软件缺陷原因分析、修复影响范围分析、修复方案、评审及批准记录。企业应保留缺陷提交、分析、修复、回归测试、评审及批准等相关记录，并与配置项状态相一致。
规范的缺陷管理工具可以帮助企业有效管理缺陷。国内外比较常见的工具有Bugzilla、Jira、PingCode、Redmine、禅道等，这些工具通常包括缺陷跟踪、缺陷记录、缺陷报告、分析及处理、问题解决情况等系统化缺陷跟踪功能，能够有效提升软件开发效率。
3 结论
本研究对本市自2020年7月以来3年间独立软件产品现场核查中所发现的规范不合格项进行了汇总统计。通过对软件开发过程中所发现的主要问题进行深入分析，针对软件需求、软件设计、软件测试、软件缺陷管理、软件配置管理等问题出现最多的5个规范部分，结合软件开发特点，提出了应对措施建议，这些建议对于独立软件企业开发及质量控制人员、监管部门的技术审评核查人员具有一定的参考意义。
参考文献
------------THE END------------
内容来源：中国医疗器械杂质监管与测试 2024年 48卷 第3期
