人工智能医疗器械软件生产质量管理体系特殊要求研究

李澍，王浩，王晨希，郝烨，李佳戈，李静莉

中国食品药品检定研究院 医疗器械检定所，北京 102629

引言

医疗器械产品从前期的设计开发、设计转化、验证和确认到后期的设计变更、不合格品控制等各个环节都应该进行严格把控，才能确保产品本身的安全有效，因此为了保证每个环节不出纰漏，每个医疗器械生产企业都要建立一套完整的医疗器械生产质量管理体系[1-2]。2019年7月，国家药品监督管理局发布《医疗器械生产质量管理规范附录独立软件》，旨在加强独立软件类医疗器械生产监管，规范独立软件生产质量管理[3]。该附录已于2020年7月1日起实施。对于独立软件的设计与开发，附录提出，设计与开发应结合软件生命周期模型的特点，建立软件生命周期过程控制程序等要求；在生产管理方面，附录规定应确保软件发布的可重复性。在质量控制方面，附录规定软件产品需要进行安装和卸载测试、产品完整性检查、发布批准等活动。在不良事件的监测、分析和改进方面，附录规定数据分析和控制程序应涵盖软件缺陷和网络安全事件要求，并保存相关记录[4-5]。

独立软件附录的特殊要求中需要引起关注的就是软件的变更控制。目前，独立软件附录要求：软件更新应当形成文件，涵盖现成软件、网络安全的变更控制要求，确定软件更新请求评估、软件更新策划、软件更新实施、风险管理、验证与确认、缺陷管理、可追溯性分析、配置管理、文件与记录控制、评审、用户告知等活动要求，形成相关文件和记录并经批准。软件版本变更应当与软件更新情况相匹配。验证与确认应当根据软件更新的类型、内容和程度实施相适宜的回归测试、用户测试等活动[6-8]。然而，和常规软件不同，当前以大数据与深度学习为基础的人工智能技术存在不可解释性和不可理解性，在动态变化的环境，或者信息不完全、存在干扰与虚假信息时，人工智能系统的性能可能会显著下降。同时，人工智能算法的灵敏度和准确性高度依赖训练用测试数据集，数据集的变更会对人工智能系统的判断结果产生很大的影响。因此，训练用数据库如何更新、产品如何迭代，以及这种更新和迭代是否允许、允许多大程度的变更、变更如何控制，这样的监管问题一直是讨论的焦点[9-11]。因此，生产企业及监管方有必要在独立软件附录基础上，进一步研究人工智能类医疗器械（Artificial Intelligence Medical Device，AIMD）生产质量管理的特殊要求。

1 AIMD产品生命周期不同阶段及讨论

在开发AIMD系统时，应根据其在开发生命周期中的阶段对某些考虑因素进行最佳描述，并基于这些因素考虑相应的框架。ISO/IEC 62304软件标准[12]针对产品开发生命周期的不同阶段进行了定义和说明，因此，在考虑AIMD生产质量管理规范框架模型时，可以参考现有标准，并结合AIMD的特殊性，以便将这些考虑因素整合到现有的软件开发过程中[13]。

将全生命周期（Total Product Lifecycle，TPLC）方法应用于软件产品的管理对于基于AIMD产品来说尤其重要，因为它能够在真实世界使用过程中进行适应和改变。在针对TPLC认证方法中，通过评估特定公司的质量体系和组织架构，并对其软件开发、测试和产品性能监控的质量进行评价，保证产品在TPLC中是有效的，从而增强患者、护理人员、医疗保健专业人员和其他用户对产品安全有效性的信心[14]。

为了充分实现AIMD学习算法的强大功能，同时实现其性能的持续改进和限制退化，可以基于以下一般原则平衡利益和风险，并评估基于AIMD的安全有效性：① 对质量体系和质量管理规范建立明确的期望；② 对必要的AIMD进行上市前审查，以合理保证其安全性和有效性。并为AIMD制造商建立明确的期望，以在整个生命周期内持续管理患者风险；③ 建议制造商持续监控AIMD产品，并在算法变更的开发、验证和执行中纳入风险管理方法；④ 使用上市后真实的再评价报告，提高产品对用户和监管部门的透明度，以持续保证产品安全性和有效性。

1.1 制定计划阶段

软件开发计划显然在确保产品质量方面起着重要作用。对于AIMD产品，需要在计划阶段，说明确保数据完整性、可靠性和有效性所需的处理步骤、确定良好输入数据的定义、确定数据是单一来源还是多种来源、明确“持续”的训练数据来源是否与最初开发产品时使用的来源的一致、使用的数据提取工具的说明、可接受性标准的说明、产品上市后验收标准的差异性等[15-16]。

1.2 设计开发阶段

设计开发与需求阶段应针对以下内容进行考虑：① 质量保证方面。应规定AIMD训练用和测试用数据集需要的检查项目。例如，某些项目可能是独立的测试用例，从而确保训练数据的质量，其他项目可能是内置的测试项目，在某些质量检查手段运行时发现质量问题；② 质量改进方面。为了在产品发布后更好地促进其安全有效，应该考虑添加有助于将来进行根本原因分析和功能改进的功能和需求。例如，为支持将来的根本原因分析，当在现场对AIMD系统进行更新时，应记录数据、时间、数据源以及神经网络加权因子等信息，该信息对可能快速跟踪性能的重大变化非常有用。

1.3 上市后考虑因素

上市后活动应遵循上市后计划进行考虑。AIMD的持续学习系统需要持续监控，以确保系统在预期性能范围内运行。由于AIMD系统可以宣称具有诊断功能，因此创建持续的受益-风险分析以针对AIMD性能和医师诊断结果进行比较很有必要，因为两者都会随时间变化。同时，安装阶段应制定AIMD系统训练数据的质量标准；应该验证在安装阶段访问的数据源是否符合这些标准（例如数据值、格式、类型等）。同时，版本控制对于AIMD系统而言特别重要，尤其是考虑到频繁更新以及回滚到先前版本的可能性。

1.4 软件维护与变更管理

在此产品生命周期阶段，主要进行软件更新（例如增加新功能）和变更维护（例如错误修复等）。对于AIMD系统，软件更新可能是由于额外的训练、持续更新，或者由制造商定义的定期更新。对于AIMD学习系统，变更速度可能比传统的医疗器械软件版本快得多。因此，在初始产品发布之前，应建立评估准则标准，以评估何时需要软件更新。同时，在执行更新时应通知用户，并清楚描述变更（例如导致变更的因素）。用户应能够拒绝算法更新或恢复到以前的算法版本。但是，这可能会导致在同一时间市场上存在多个有效算法版本，需要考虑如何跟踪算法的投诉或其他问题。

2 AIMD质量管理规范框架讨论

2.1 基于风险分类的AIMD监管思路

基于AIMD的软件，在用于诊断、治疗、缓解或预防疾病时，符合医疗器械的定义，属于医疗器械的范畴。因此与其他软件类医疗器械类似，AIMD的风险等级取决于预期用途在风险分类框架下对患者的影响。

根据国际医疗器械监管者论坛IMDRF的风险框架，可以确定以下两个主要因素，用来说明AIMD的预期用途：① AIMD提供的信息对医疗决策的重要性（表1），该信息确定了AIMD提供信息的预期用途。例如用于治疗或诊断、临床决策、临床通知等；② 医疗条件或环境的状态，从而用于识别AIMD的预期使用者、疾病状况以及人群。例如紧急、严重或非严重的医疗事件或状况。

表1 IMDRF AIMD风险分类表决策重要性

需要注意的是，虽然AIMD取决于患者的风险分类，但由于人工智能算法的特殊性，因此风险也取决于从“锁定”到“持续学习”的程度。“锁定”算法是指每次提供相同输入时都提供相同结果的算法。因此，“锁定”算法将固定函数（例如静态查找表、决策树或复杂分类器）应用于给定的输入集，这些算法可以使用手动过程进行更新和验证。与“锁定”算法相比，自适应算法（例如机器学习算法）使用定义的学习过程改变其行为。算法的自适应性使得对于给定的一组输入，在实现改变之前和之后，输出可能是不同的。这些算法变更通常是通过一个定义良好且可能完全自动化的过程来实现和验证的，该过程旨在通过对新数据或附加数据的分析来提高算法性能。

适应过程可用于解决多种不同的临床情况，例如在特定环境中优化性能（如基于当地患者群体）、基于设备的使用方式优化性能（如基于特定医生的偏好）、通过收集更多临床数据以提高性能、更改设备的预期用途等。适应过程包括两个阶段：学习和更新。算法“学习”如何改变自身的行为。例如，通过添加新的输入类型或向已经存在的训练数据库中添加新的案例。当部署新版本的算法时，“更新”就会发生。因此，在时间A（更新前）和时间B（更新后）给定相同的输入集，算法的输出可能不同。

总体来说，将TPLC方法应用于软件产品的监管对于基于AIMD来说尤其重要，因为它能够在真实世界使用过程中进行适应和改变。在针对TPLC预认证方法中，通过评估相应公司的质量体系和组织架构，并对其软件开发、测试和产品性能监控的质量进行合理评价，继而保证产品在整个生命周期中都是有效的，从而对患者、护理人员、医务人员和其他用户提供产品安全有效的信心。因此，TPLC方法能够对软件产品从上市前的开发到上市后的性能进行评估和监控，并持续展示组织的优异性（图1）。

图1 基于全生命周期的AIMD要求框架

2.2 基于AIMD的修改和变更

AIMD可能有很多类型的修改，修改一般包括算法架构修改和使用新数据集重新训练两部分。修改类型通常分为三大类：① 性能更变，包括临床和使用性能发生变化；② 输入变更，算法使用的输入及其与输出的临床关联变化；③ 预期用途变更，AIMD的预期用途发生变化。

与性能相关的修改，不改变预期用途或增加新的输入类型，这种类型的修改包括分析和临床性能的改进。这些改进可以由许多更改引起，可能包括使用相同类型输入信号的预期使用群体内的新数据集进行重新训练、人工智能架构的改变或其他方式。对于这种类型的修改，制造商通常旨在更新用户的性能，而不改变其产品的任何明确使用声明。

与输入相关的修改，不改变预期用途，这些类型的修改是改变人工智能算法使用输入的修改。这些修改可能涉及对用于新类型输入信号的算法的更改，但不会更改产品使用声明。这些变化的例子有：扩展软件与相同输入数据类型的其他来源数据的兼容性（例如修改以支持与其他制造商的CT扫描仪兼容）；添加不同的输入数据类型（例如将诊断心房颤动的输入扩展到包括血氧饱和度数据）。

与预期用途相关的修改，这些类型的修改包括导致软件提供的信息的重要性发生变化（例如从“辅助诊断”到“最终诊断”）。预期用途的修改也包括扩大预期患者群体（例如扩大至儿童群体）、预期疾病或条件（例如从一种癌症到另一种癌症的病变检测）等。当然，所述的更改可能不是相互排斥的，一个软件修改可能会导致输入的变化和性能的变化；或者，性能更改可能会增加设备的临床性能，进而影响预期用途等等。

3 讨论

3.1 AIMD的可解释性

基于AIMD系统关键的挑战之一是对系统的可解释性。在传统的软件开发项目中，促使人们对产品充满信心的基本原因是可以理解的算法设计以及完善的、透明的验证和确认工作。但是，对于AIMD系统，软件工程师不会直接创建决策算法，并且在测试时可能将系统视为黑盒，所以这个部分并不容易实现。

目前，可解释性在人工智能领域有新的含义和目的，通常指完全理解和记录人工智能系统输出、建议、预测或决策开发中所用逻辑、决策方法和数据源的必要性。对于某些不包括人工干预的高级人工智能系统，尤其是AIMD系统，这个概念成了问题。此外，随着最近发布的欧盟GDPR法规，这种可解释性的概念已具有新的形式化紧迫感。例如，根据这些法规，受影响的数据主体和用户有权要求提供关于人工智能驱动输出中涉及的逻辑等有意义的信息，以及在决策做出后提出质疑的能力。

3.2 基于AIMD的软件的验证和确认

AIMD系统的持续学习是关于学习、忘记和重新学习的过程。当系统完成持续学习时，就必然需要建立对系统操作和输出的关系。验证和确认为可信度和系统性能提供了证据。本文使用以下定义：验证指“以正确的方式构建系统”，即证明系统正确实施且符合其质量标准（满足技术要求）。确认指“构建正确的系统”，即证明系统执行任务的准确性的程度（满足预期用途）。

针对AIMD的验证，应定义与一致性、完整性、正确性和冗余概念相关的验证方法，以实现异常检测和/或错误消除，从而建立对系统的信心。开发者可以在知识库中记录他们拥有或获得的专业知识，这将为AIMD系统算法的“可解释性”奠定基础。这是该过程的重要可交付成果，随着算法的日趋成熟以及内容的性质，需要不断修订，预期它会成为具有非常复杂的科学和数学内容的高技术性文件，并且可能从数据科学家的角度编写。

针对AIMD系统的确认。一般而言，确认是指通过检查和提供客观证据来证实设计的系统符合用户需求和预期用途的过程。具体到AIMD，则是指通过使用独立的参考标准来衡量系统性能的过程。参考标准可有多种来源，包括明确定义的基准事实（例如患者是否患有系统预测的疾病）、相关领域专家的共识（例如比较AIMD与病理学家对活检标本的解读）或临床医生做出的临床决定。

3.3 AIMD应用场景示例

本节介绍了在医疗卫生系统中使用AIMD软件的实际场景以及发生变更的实际情况。

3.3.1 肌电假体控制

肌电控制假肢是一种通过用户自身肌肉产生的电信号实现控制的外部供电假肢。大多数假肢控制方法的局限性在于控制器无法随时间推移适应患者及其意图或使用模式的变化。因此，大多数假肢使用者无法在诊所外独立改善其肢体控制器。而AIMD配合机器学习，能够了解并预测用户意图，并根据使用者反馈不断改进控制。因此，需要针对每例患者对器械进行训练，并使该器械在患者使用后仍可继续学习。依据使用者培训不同，每例患者的器械表现出来的性能可能有所不同，进而需要相应的鲁棒性能评估方法。

3.3.2 基于AIMD分类的医学影像筛查系统

AIMD系统已广泛应用于医学影像筛查。以胸部CT影像检测肺癌为例，选择了特定于深度学习架构进行初步训练。该架构包括层数量、每一层卷积核大小、每一层卷积核的数量、每一层激活函数的类型、每一层应用梯度下降算法等。如果设计人员希望有更多数据可用时对AIMD架构进行再训练，在训练时，不仅神经网络权值会发生变化，甚至整个架构都会发生变化。因此，权值/系数发生变化但其架构保持不变的AIMD和权值/系数和架构均发生变化的AIMD对持续学习的置信度和适应性均有显著的差别。

4 总结

AIMD正处于蓬勃发展期，为临床医生提高医疗诊断效率和治疗的可靠性提供了帮助，目前有许多AIMD正在临床实践中使用，因此，需要针对AIMD的需要建立动态稳健的质量管理模式，在缩短产品研发与验证周期的同时，及时前瞻性地发现AIMD带来的新的使用风险。本文讨论了AIMD的质量管理体系框架，在此基础上，讨论了影响人工智能医疗器械质量的关键因素，设计变更和验证确认环节的控制思路。并对人工智能医疗器械在质量评价过程中需重点关注的软件可解释性、评价方法和验证和确认进行了讨论。