9月24日，FDA正式发布了《产品和质量系统软件CSA指南》，从2018年CSA概念提出，到2022年CSA草案二十几页，再到最终版四十页，业内人士评论这是医药行业的一大步，让人亢奋~
该文件补充了 FDA 此前《软件验证通则》指南的内容，同时取代了其中 “第 6 节：自动化过程设备与质量体系软件的验证” 部分，同时将适配 2026 年2月生效的 21 CFR Part 820（设备质量体系法规）修订终稿（整合 ISO 13485:2016 标准）。文件包含计算机软件保证的风险框架和电子记录要求的考量，围绕预期用途、确定基于风险的方法、生产或质量体系软件变更、确定适当的保证活动、建立适当的记录等内容阐述了详细要求文件还包含大量示例以帮助理解CSA要求。
翻译如下：
Guidance for Industry and Food and Drug Administration Staff
行业和食品药品监管人员指南
Computer Software Assurance for Production and Quality System Software
引言
FDA 发布本指南，旨在为作为医疗器械生产或质量体系一部分的计算机和自动化数据处理系统的计算机软件保证提供建议。本指南：
将“计算机软件保证” 描述为一种基于风险的方法，用于建立对生产或质量体系所用自动化的信心，并指出在哪些情况下可能需要更严格的要求；并且
描述可用于建立计算机软件保证并提供客观证据以满足监管要求的计算机软件保证活动，例如质量体系义务中的计算机软件验证要求，包括21CFR 第820 部分（以下简称 “第820 部分”）中的要求。
本指南是对 FDA《软件验证通则》指南（以下简称《软件验证指南》）的补充，但本指南取代《软件验证指南》中“第6 部分：自动化工艺设备和质量体系软件的验证” 章节。
有关本文件中引用的、FDA 认可的共识标准的当前版本，请参见 FDA 认可的共识标准数据库。³
一般而言，FDA 的指南文件不设立具有法律强制力的责任。相反，指南阐述了本机构在某一主题上的当前思路，且除非引用了具体的监管或法定要求，否则应仅被视为建议。在本机构指南中使用 “should（应该）” 一词，意味着是提出建议或推荐，但并非强制要求。
二、背景
FDA 展望未来，医疗器械生态系统会从本质上聚焦于能提升产品质量和患者安全的器械特征与生产实践。FDA 一直致力于识别并推广成功的生产实践，以帮助器械制造商提高其生产质量水平。在此过程中，一个目标是帮助制造商生产出符合 FDA 所实施的法律和法规的高质量医疗器械。对于成品医疗器械制造商而言，只要其开展的业务涉及质量体系义务的适用范围，就需要遵守包括21 CFR Part 820在内的质量体系义务。质量体系义务包括要求医疗器械制造商开发、实施、控制和监测生产工艺，以确保器械符合其规格要求⁴，其中也包括要求制造商对作为生产或质量体系一部分、用于预期用途的计算机软件进行验证⁵ ⁶。本指南中关于计算机软件保证的建议，旨在提升产品质量和患者安全，并与更高质量的成果相关联。本指南阐述了与作为生产或质量体系一部分的计算机及自动化数据处理系统相关的实践。
近年来，制造技术的进步（包括自动化、机器人技术、仿真技术和其他数字能力的采用）使制造商能够减少误差来源、优化资源并降低患者风险。FDA 认识到这些技术在提升医疗器械的质量、可及性和安全性方面具有显著益处的潜力，并已采取多项举措来助力促进此类技术的采用和使用。
具体而言，FDA 通过医疗器械创新联盟（MDIC）、对医疗器械制造商的现场访问，以及与其他行业（如汽车、消费电子）的标杆对比工作，与利益相关者保持互动，以了解最新技术，并更好地理解利益相关者在进一步发展方面面临的挑战和机遇。作为这些持续努力的一部分，医疗器械制造商表达了希望更清晰了解本机构对作为生产或质量体系一部分的计算机及自动化数据处理系统的软件验证期望的诉求。鉴于软件的快速变化特性，制造商也表达了希望采用更具迭代性、敏捷性的方法来验证作为生产或质量体系一部分的计算机软件的诉求。
传统上，软件验证通常是通过在软件开发生命周期的每个阶段进行的软件测试和其他验证活动来完成的。然而，正如 FDA《软件验证指南》中所阐述的，仅靠软件测试往往不足以建立对软件适用于其预期用途的信心。相反，《软件验证指南》建议 “软件质量保证” 应聚焦于防止在软件开发过程中引入缺陷，并鼓励采用基于风险的方法来建立对软件适用于其预期用途的信心。
FDA 认为，将基于风险的方法应用于作为生产或质量体系一部分的计算机软件保证，能更好地使制造商的质量保证活动聚焦于帮助确保产品质量，同时助力满足验证要求。基于这些原因，FDA 针对作为医疗器械生产或质量体系一部分的计算机及自动化数据处理系统，提供有关计算机软件保证的建议。FDA 认为，这些建议将有助于促进创新技术的采用和使用（这些技术能让患者获得高质量的医疗器械），并帮助制造商跟上动态且快速变化的技术形势，同时促进对 FDA 所实施的法律和法规的遵守。
本指南是对 FDA《软件验证通则》指南（以下简称《软件验证指南》）的补充，但本指南取代《软件验证指南》中 “第 6 部分：自动化工艺设备和质量体系软件的验证” 章节。
有关本文件中引用的、FDA 认可的共识标准的当前版本，请参见 FDA 认可的共识标准数据库。³
一般而言，FDA 的指南文件不设立具有法律强制力的责任。相反，指南阐述了本机构在某一主题上的当前思路，且除非引用了具体的监管或法定要求，否则应仅被视为建议。在本机构指南中使用 “should（应该）” 一词，意味着是提出建议或推荐，但并非强制要求。
三、范围
本指南针对作为医疗器械生产或质量体系一部分的计算机或自动化数据处理系统，提供有关计算机软件保证的建议。
本指南并非旨在完整描述所有软件验证原则。FDA 此前已在其《软件验证》指南中概述了软件验证原则，包括将变更管理作为软件生命周期的一部分。本指南将《软件验证》指南中讨论的基于风险的软件验证方法应用于生产或质量体系软件。此外，本指南还讨论了特定的风险考量、可接受的测试方法，以及在医疗器械生命周期内为生产或质量体系软件高效生成客观证据的相关内容。
本指南不针对器械软件功能的设计验证或确认要求提供建议（器械软件功能是符合FD&C 法案第201 (h) 节中器械定义的软件功能）。如需了解FDA 关于医疗器械软件验证建议的更多信息，请参见《软件验证》指南。
四、定义
以下定义适用于本指南。⁷
云计算（云）：云计算是一种模型，可实现对共享的可配置计算资源池（如网络、服务器、存储、应用程序和服务）的泛在、便捷、按需网络访问，这些资源可通过最少的管理工作或与服务提供商的交互来快速供应和释放。此云模型包含五个基本特征：按需自助服务、广泛的网络访问、资源池化、快速弹性和计量服务。云包含三种服务模型：软件即服务（SaaS）、平台即服务（PaaS）和基础设施即服务（IaaS）。云模型还包含四种部署模型：私有云、社区云、公有云和混合云。⁸
基础设施即服务（IaaS）：向消费者提供的能力是供应处理、存储、网络和其他基本计算资源，消费者能够在这些资源上部署和运行任意软件（可包括操作系统和应用程序）。消费者不管理或控制底层云基础设施，但对操作系统、存储和已部署的应用程序有控制权；并且可能对部分网络组件（如主机防火墙）有有限的控制权。⁹
平台即服务（PaaS）：向消费者提供的能力是在云基础设施上部署消费者创建或获取的应用程序（这些应用程序使用提供商支持的编程语言、库、服务和工具创建）。¹⁰消费者不管理或控制底层云基础设施（包括网络、服务器、操作系统或存储），但对已部署的应用程序以及可能对应用程序托管环境的配置设置有控制权。¹¹
软件即服务（SaaS）：向消费者提供的能力是使用提供商在云基础设施上运行的应用程序。这些应用程序可通过瘦客户端界面（如网页浏览器，例如电子邮件）或程序界面从各种客户端设备访问。消费者不管理或控制底层云基础设施（包括网络、服务器、操作系统、存储，甚至单个应用程序功能），可能仅对有限的特定于用户的应用程序配置设置有控制权。¹²
五、计算机软件保证
计算机软件保证是一种基于风险的方法，用于建立并保持对软件适用于其预期用途的信心。该方法会考虑（若软件未能按预期运行时）器械安全性和 / 或质量受损的风险，以确定为在软件中建立信心而应采取的保证工作和活动的水平。由于计算机软件保证是基于风险的，因此它遵循最小负担的方法，即验证工作的负担不会超过应对风险所需的程度。这种方法支持资源的高效利用，进而提升产品质量。
此外，计算机软件保证能建立并保持生产或质量体系中使用的软件在其整个生命周期内处于受控状态（“已验证状态”）。这一点很重要，因为制造商越来越依赖计算机和自动化处理系统来监控和运行生产、向相关人员发出警报，以及传输和分析生产数据等。通过允许制造商利用其他实体（如开发商、供应商和服务提供商）开展的基于风险的验证活动等原则，计算机软件保证方法在帮助确保软件保持符合适用质量体系义务的已验证状态方面，提供了灵活性和敏捷性。
适用于其预期用途并保持已验证状态的软件应按预期运行，有助于确保成品器械的安全性和有效性，并符合监管要求（见 21 CFR 820.1 (a)(1)）。第五节概述了计算机软件保证的基于风险的框架。
（1）确定预期用途
法规要求制造商对作为生产或质量体系一部分使用的软件，按其预期用途进行验证（参见 21 CFR 820.70 (a)）。这包括与计算机化系统相关的各种云计算模式，如平台即服务（PaaS）、基础设施即服务（IaaS）和软件即服务（SaaS）。
为了确定验证要求是否适用，制造商必须确定该软件是否正在或将要作为生产或质量体系的一部分使用（无论是直接使用还是用于支持生产或质量体系）。
具有以下预期用途的软件被视为直接作为生产或质量体系的一部分使用：
用于自动化生产过程、检验、测试或生产数据收集与处理的软件；以及用于自动化质量体系过程、质量体系数据收集与处理或维护根据适用质量体系要求建立的质量记录的软件。
具有以下预期用途的软件被视为用于支持生产或质量体系：
拟用作测试或监控软件系统的开发工具，或为作为生产或质量体系一部分使用的软件自动化这些活动的开发工具，例如用于开发和运行脚本或嵌入生产设备的软件（如固件）的测试；以及用于自动化生产或质量体系的一般记录保存（且不属于质量记录范畴）的软件。
这两种软件都作为生产或质量体系的一部分使用，必须根据 21 CFR 820.70 (a) 进行验证。然而，如下文进一步讨论的，支持性软件通常风险较低，因此在基于风险的计算机软件保证方法下，验证工作可相应减少，同时不影响安全性。
另一方面，具有以下预期用途的软件通常不被视为生产或质量体系的一部分，因此 21 CFR 820.70 (a) 中的验证要求不适用：
用于管理不特定于生产或质量体系的一般业务流程或运营的软件，如电子邮件或会计应用程序；以及用于建立或支持不特定于生产或质量体系的基础设施的软件，如网络、用户认证或运营连续性（如备份和恢复）。
FDA 建议制造商在考虑云计算模式时，关注软件的预期用途，因为并非所有云计算模式都 “直接” 作为生产或质量体系的一部分使用。
例如，基础设施即服务（IaaS）云存储解决方案属于基础设施类别，但可能被用于存储根据适用质量体系要求建立的质量记录，在这种情况下，该 IaaS 云存储解决方案将被视为直接作为质量体系的一部分使用。在此示例中，FDA 建议制造商将保证工作的重点放在与记录完整性相关的特征或功能，以及适用于拟存储记录的 21 CFR 第 11 部分要求上。
相反，IaaS 云存储解决方案可能支持基础设施来存储生产和过程数据；这不会被视为已建立的质量体系记录。在此示例中，该 IaaS 云存储解决方案不支持生产或质量体系，因此 21 CFR 820.70 (a) 中的验证要求不适用。当数据在云中的存储与该数据是否属于质量记录无关时，制造商有义务确定该应用的适当风险等级。制造商可以考虑采用负担最小的方法来确保 IaaS 云存储解决方案适合其业务。
FDA 认识到，用于生产或质量体系的软件通常很复杂，由多个特征、功能和操作组成。⁴ 软件可能根据其各自的特征、功能和操作具有一个或多个预期用途。在软件的各个特征、功能和操作在生产或质量体系中具有不同作用的情况下，它们可能带来不同的风险，需要不同程度的验证工作。FDA 建议制造商检查软件特征、功能或操作的预期用途，以促进基于风险的保证策略的制定。制造商可以决定针对与预期用途相关的各个特征、功能或操作开展不同的保证活动。
例如，商用现成（COTS）电子表格软件可能包含具有不同预期用途的各种功能。当利用COTS 电子表格软件的基本输入功能来记录固化过程的时间和温度读数时，制造商可能不需要进行超出COTS 软件开发商所进行的以及安装和配置之外的额外保证活动。该软件的预期用途是“记录过程”，仅用于支持维护过程信息的记录，且风险较低。因此，诸如成功的供应商评估以及软件安装和配置等初始活动可能足以确定该软件适合其预期用途并保持验证状态。然而，如果制造商还利用COTS 电子表格的内置功能来创建直接用于生产或质量体系的自定义公式，那么可能会存在额外的风险和数据完整性考虑。例如，如果自定义公式自动计算时间和温度统计数据以监控固化过程的性能和必要性，那么制造商可能需要进行额外的验证。
（2）确定基于风险的方法
一旦制造商确定某一软件特征、功能或操作当前或未来会被用作生产或质量体系的一部分，美国食品药品监督管理局（FDA）建议使用基于风险的分析来确定适当的保证活动。广义而言，这种基于风险的方法需要系统地识别合理可预见的软件故障，确定此类故障是否构成高过程风险，并根据适用情况，系统地选择和执行与医疗器械或过程风险相匹配的保证活动。制造商应根据其基于风险的分析，并考虑其流程和程序（适用于所涉及的软件和正在执行的保证活动），选择执行保证活动的适当频率。
需要注意的是，本指南中所述的针对生产或质量体系软件的计算机软件保证开展基于风险的分析，与国际标准化组织（ISO）
14971:2019《医疗器械-医疗器械风险管理的应用》中所述的针对医疗器械开展的风险分析不同。针对生产或质量体系软件的基于风险的分析侧重于那些可能影响或阻碍软件按预期运行的因素，例如过程系统的配置和管理、系统安全性、数据完整性、数据存储、数据传输或操作错误。针对生产或质量体系软件的基于风险的分析应考虑故障是否是合理可预见的（而非是否可能发生），以及每次此类故障所导致的风险。例如，在基于风险的分析中，制造商可能会考虑电源循环中断带来的风险，这种情况可能不太可能发生，但在生产或质量体系的生命周期内是合理可预见会发生的。本指南既讨论过程风险，也讨论医疗器械风险。过程风险是指生产或质量体系受到损害的可能性。医疗器械风险是指患者或使用者受到损害的可能性。在讨论医疗器械风险时，本指南关注的是由损害安全性的质量问题所导致的医疗器械风险。
具体而言，当某一软件特征、功能或操作未能按预期运行可能导致可预见地损害安全性的质量问题（即医疗器械风险）时，FDA 认为该软件特征、功能或操作构成高过程风险。这一过程风险识别步骤仅关注过程，而非对患者或使用者造成的医疗器械风险。通常属于高过程风险的软件特征、功能或操作包括：
维持对产品物理特性或被确定为对器械安全至关重要的制造过程有影响的过程参数（例如温度、压力或湿度）；
在很少或没有额外人员参与知晓或审核的情况下，对产品或过程进行测量、检验、分析和 / 或确定其可接受性；
基于数据监控或来自其他过程步骤的自动反馈，在没有额外人员参与知晓或审核的情况下，对过程进行修正或对过程参数进行调整；
生成供患者和使用者使用的、对医疗器械的安全操作而言必需的使用说明或其他标签；和 / 或
对制造商确定为对器械安全（例如网络安全）和质量至关重要的数据进行自动监视、趋势分析或跟踪。
相反，当某一软件特征、功能或操作未能按预期运行不会导致可预见地损害安全性的质量问题时，FDA 认为该软件特征、功能或操作不构成高过程风险。这包括未能按预期运行不会导致质量问题的情况，以及未能按预期运行可能导致质量问题但该质量问题不会可预见地导致安全性受损害的情况。通常不属于高过程风险的软件特征、功能或操作包括：
从过程中收集和记录用于监控和审核目的、且对生产或过程性能没有直接影响的数据；
作为质量体系的一部分，用于纠正和预防措施（CAPA）的流转、投诉的自动记录 / 跟踪、变更控制的自动管理或程序的自动管理；
旨在管理数据（监控、存储和 / 或组织数据）、自动执行现有计算、增强过程追溯，或在既定过程中出现异常时提供与数据管理相关的警报；和/ 或
如上文第五节 A.1 部分所述，用于支持生产或质量体系。
FDA 承认，与用作生产或质量体系一部分的软件相关的过程风险是一个连续范围，从高过程风险到低过程风险不等。制造商应根据软件的预期用途，确定每个软件特征、功能或操作的风险在该范围内的位置。FDA 主要关注那些高过程风险的软件特征、功能和操作的审查和保证，因为这些过程也会带来医疗器械风险。就本指南而言，FDA 以二元方式呈现过程风险：“高过程风险” 和 “非高过程风险”。例如，制造商在确定保证活动时，仍可将某一过程确定为 “中等”“中间” 甚至 “低” 风险；在这种情况下，本指南中涉及 “高过程风险” 的部分同样适用。如下文第五节 A.4 部分所述，对于 “高过程风险” 的软件，应开展与医疗器械风险相匹配的保证活动；对于 “非高过程风险” 的软件，应开展与过程风险相匹配的保证活动。
示例：某企业资源规划（ERP）管理系统包含一个自动补充物料的功能（该功能自动进行物料订购并将其交付至相应的生产工序）。不过，经授权人员会在物料用于生产前对其进行检查。该功能若未能按预期运行，可能会导致补充和交付物料时出现混淆，这会是一个质量问题，因为若经授权人员（参与检查），会在物料用于生产前就完成交付；因此，该质量问题不应可预见地导致安全性受损害。制造商将其确定为中等（非高）过程风险，并确定与该过程风险相匹配的保证活动。制造商已对 ERP 供应商、ERP 系统信息进行了评估，并针对其运营和交付自动化配置了 ERP 系统。制造商实施了与物料订购和交付相关的所有剩余保证活动。
示例：另一 ERP 管理系统中的类似功能执行与前例相同的任务，但它还能自动在物料用于生产前对其进行检查。经授权人员会检查物料清单。制造商将其确定为高过程风险，因为该功能若未能按预期运行，可能会导致可预见地损害安全性的质量问题。因此，制造商将确定与相关医疗器械风险相匹配的保证活动。制造商此前已对物料识别数据系统、自动物料扫描系统（条形码扫描器）开展了保证活动，对 ERP 供应商 / 信息进行了评估，并针对其运营配置了 ERP 系统。制造商实施了与订购和交付自动化相关的所有剩余保证活动。
示例：某 ERP 管理系统包含一个自动交付产品的功能。医疗器械风险取决于多个因素，其中包括向器械使用者交付正确的结果。该功能若未能按预期运行，可能会导致交付混淆，这会是一个可预见地损害安全性的质量问题，因此，制造商将其确定为高过程风险。由于该故障会损害安全性，制造商接下来将确定相关的医疗器械风险，并识别与医疗器械风险增加相匹配的保证活动。在这种情况下，制造商尚未实施任何已识别的保证活动，因此制造商实施了分析中识别的所有保证活动。
示例：生产软件中的一个自动图形用户界面（GUI）功能用于根据用户交互开发测试脚本，并自动对生产中使用的系统的用户界面进行未来测试修改。该 GUI 功能若未能按预期运行，可能会导致实施中断以及生产系统的软件更新延迟，但在这种情况下，这些错误不应可预见地导致安全性受损害，因为该 GUI 功能在单独的测试环境中运行。制造商将其确定为低（非高）过程风险，并确定与该过程风险相匹配的保证活动。制造商已经开展了部分已识别的保证活动，因此实施了剩余的已识别保证活动。
（3）生产或质量体系软件变更
对于拥有已批准的上市前批准申请（PMA）或人道主义器械豁免（HDE）的器械，若制造程序或制造方法的变更不影响器械的安全性或有效性，且通过定期报告（通常不称为年度报告）向 FDA 报告，则无需提交 PMA/HDE 补充申请。¹⁵ 对于影响器械安全性和有效性的制造程序或生产制造方法的修改，也无需提交 PMA/HDE 补充申请；此类修改需通过 30 天通知提交。¹⁶ 制造程序或制造方法的变更可能包括对生产中使用的软件或质量体系所用软件的变更。对于拥有已批准 PMA 或 HDE 的器械，其质量体系生产中使用的软件的新增或变更，FDA 建议制造商应用上述第五节 A.2 部分概述的原则，以确定该变更是否可能影响器械的安全性或有效性。一般而言，若某一变更可能导致可预见损害安全性的质量问题，则应通过 30 天通知提交；若某一变更不会导致可预见损害安全性的质量问题，则该变更可酌情在年度报告中报告。¹⁷
例如，制造执行系统（MES）可用于管理工作流程、跟踪进度、记录数据，并基于经验证的参数设置警报或阈值（这些参数是维护质量体系的一部分）。此类 MES 若未能按预期运行，可能会扰乱运营，但不会影响为生产安全且有效的器械而建立的过程参数。影响这些 MES 运行的变更通常在年度报告中提交。相反，用于自动控制和调整既定关键生产参数（如温度、压力、工艺时间）的 MES 可能属于对制造程序的变更，且会影响器械的安全性或有效性；若如此，影响该特定运行的变更应通过 30 天通知提交。
（4）确定适当的保证活动
一旦制造商确定某一软件特征、功能或操作是否构成高过程风险（可能可预见损害安全性的质量问题），制造商应识别与医疗器械风险（高过程风险）相匹配的保证活动。在质量问题可能可预见损害安全性的情况下（高过程风险），保证级别应与医疗器械风险相匹配；在质量问题不可能可预见损害安全性的情况下（非高过程风险），保证级别应与过程风险相匹配。无论哪种情况，软件故障、功能或操作的风险越高，通常意味着保证工作需要更严格（即需要更多客观证据）；相反，安全性和 / 或质量受损害的风险相对较低（即非高过程风险），通常意味着计算机软件保证工作所需收集的客观证据更少。
可能导致患者或使用者受到严重伤害的软件特征、功能或操作通常属于高医疗器械风险；相反，不会可预见导致严重伤害的特征、功能或操作可能不属于高医疗器械风险。无论哪种情况，软件未能按预期运行的风险都与由此产生的医疗器械风险相当。
如果制造商反而确定该软件特征、功能或操作不构成高过程风险（即不会导致可预见损害安全性的质量问题），制造商应考虑与过程（即生产或质量体系）相关的风险。这是因为（软件的）故障不会损害安全性，因此故障不会引入额外的医疗器械风险。例如，用于收集和记录过程数据以供审核的功能，其过程风险要低于在人工审核前确定产品可接受性的功能。
制造商通常开展的保证活动中可能考虑的手动或自动测试类型包括但不限于以下几种：
非脚本测试：测试人员的操作不由书面指令规定的动态测试（也称为即席测试）；这是一种基于规范的测试用例设计技术，其中用户执行测试项与其他系统之间的交互序列。¹⁹（在此语境下，用户被视为其他系统。）
测试用例中的场景测试：一种基于测试人员的经验来生成测试用例的测试用例设计技术。¹⁹ 基于经验的测试可包括针对潜在问题（如测试攻击、性能和其他质量领域）的安全性、遍历和错误分类等概念，²⁰ 且可包括：
错误推测：一种测试设计技术，其中测试用例根据测试人员对过去故障的了解或对故障模式的一般了解推导而来；相关知识可从个人经验中获得，或可被封装在（例如）缺陷数据库或“缺陷分类法” 中。²²
探索性测试：基于经验的测试，其中测试人员根据自身现有的相关知识、对测试项的先前探索（包括以往测试的结果），以及关于常见软件行为和测试设计类型的启发式“经验法则”，自发设计和执行测试，以寻找隐藏属性（包括隐藏的、未预期的用户行为，或可能干扰正在测试的其他软件属性并可能造成软件故障风险的意外使用情况）。²³
脚本测试：测试用例被记录（例如，记录在测试管理工具或电子表格中），随后可手动执行或使用自动化测试工具自动执行的测试。每个测试用例所需的详细程度以及证明软件特征、功能或操作按预期运行所需的证据，取决于该软件特征、功能或操作带来的风险。例如，根据预期用途，更完善的脚本测试（其中测试用例和证据可能包括对可重复性、可追溯性或可审计性的详细要求）可能是适当的。
本指南描述了制造商在满足监管要求时可考虑的基于风险的方法；它并非软件测试方法和原则的详尽列表。FDA 承认，除本指南中提及的方法外，还有其他软件测试方法和途径，制造商可根据具体情况灵活考虑和使用。²⁴
例如，《医疗器械网络安全：质量体系考量和上市前申报资料内容》指南适用于涉及网络安全考量的器械，描述了关于某些上市前申报类型下器械应提交的网络安全信息的建议，其中包括用于证明设计控制有效性的网络安全测试建议。制造商在开展本指南中描述的保证活动时，可酌情考虑使用该指南中描述的网络安全测试方法。
一般而言，FDA 建议制造商应用基于风险的测试原则，即有意识地根据分析得出的相应风险类型和级别，来管理、选择、确定测试活动和资源的优先级并加以利用，以确定适当的活动。对于高过程风险的软件特征、功能和操作，制造商在确定其保证活动时，可选择考虑更严格的要求（如使用脚本测试或脚本测试与非脚本测试相结合的混合方法，并酌情调整）；相反，对于非高过程风险的软件特征、功能和操作，制造商可考虑使用非脚本测试方法（如场景测试、错误推测、探索性测试，或适合该风险的方法组合）。针对高过程风险和非高过程风险讨论的测试类别并非仅限于这些示例；制造商应应用基于风险的测试原则来确定要执行的适当测试类型。例如，即使对于高过程风险的特征、功能和操作，非脚本测试可能更适合确保软件按预期运行；相反，制造商可能会发现，为非高过程风险的特征、功能和操作开发脚本测试并实现自动化，会更有效且更高效。
（5）保证活动的其他考量因素
在确定适当的保证活动时，制造商应考虑整个质量体系中是否存在任何额外的控制措施或机制，若软件特征、功能或操作发生故障，这些措施或机制可降低安全性和 / 或质量受损的影响。例如，作为全面保证方法的一部分，制造商可利用以下方式来减少额外保证活动的工作量：
在已建立的流程中开展的、对生产进行控制或充分验证进展且涉及相关软件的活动。此类活动可能包括确保生产支持数据完整性的程序、后续检验或测试，或由其他组织单位执行的软件质量保证流程。
已建立的用于选择和监督软件供应商的采购控制流程。例如，医疗器械制造商可将软件开发者已开展的软件开发实践、验证工作以及电子信息作为起点，并确定可能需要哪些额外活动。对于某些低风险的软件特征、功能和操作，这可能就是制造商所需的全部保证。
已全面融入生产过程的额外过程控制，包括降低网络安全风险的活动²⁵。例如，若某个过程被充分理解、所有关键过程参数都受到监控，和 / 或过程的所有输出都经过验证测试，那么这些控制可作为额外机制，用于检测和纠正因软件特征、功能或操作未能按预期运行而可能出现的质量问题。在此示例中，这些控制措施的存在可被利用，以减少针对该软件的适当保证活动的工作量。
软件在实施后，为监控或检测软件中的问题或异常情况而定期或持续收集的数据和信息。监控和检测性能问题、偏差及系统错误的能力，可能会降低与软件未能按预期运行相关的风险，且在确定保证活动时可能会被考虑。
尽可能使用支持软件开发和系统生命周期活动的工具（如缺陷、异常跟踪工具，需求可追溯性工具），以保证生产中使用的或作为质量体系一部分的软件。
在生产中使用的或作为质量体系一部分的软件的整个生命周期内，在迭代周期中并持续使用测试和结果数据。
FDA 认识到，作为评估的一部分，制造商可能难以从软件供应商处获取信息，并建议制造商将对软件供应商的基于风险的分析作为其保证方法的一部分来建立和应用。制造商在确定对软件供应商的适当控制级别（如采购控制）时，其评估可考虑各类信息来源。为评估供应商的能力（无论是基于云的、本地的还是混合模式的），制造商可考虑包括但不限于以下的活动：
对供应商进行现场审计（如适用）。FDA 承认，器械制造商对软件供应商进行审计可能并不可行或不适当。制造商可在对软件供应商的控制措施和能力进行基于风险的分析时，考虑任何适用的替代信息组合；
审查供应商的行业资质和认证（如《服务组织控制》报告）以及认可认证（如 ISO 认证）。
审查供应商在软件开发、软件质量保证、网络安全（如安全风险评估、威胁建模、安全设计评审、软件物料清单（SBOM）和测试）以及风险缓解方面的实践和文件；以及
审查供应商或软件的数据完整性能力或控制措施，包括但不限于：
保留记录、归档数据以及生成准确且完整的记录副本；
保护静态和传输中的数据（即维护安全的、计算机生成的、带有时间戳的用户操作和数据变更的审计跟踪，对数据进行加密）；
建立和维护访问控制、电子签名控制以及对用户操作的授权检查。
制造商应根据供应商满足规定要求的能力，在其程序中建立并维护对供应商的要求，并界定对产品、服务和供应商实施控制的类型和范围。制造商在评估决策中应考虑关于供应商的适当信息来源。FDA 建议制造商建立一种基于风险的方法，用于评估软件或服务的供应商、评估活动以及应保留的适当客观证据。
例如，如第五节 A.1 中提及的支持软件，通常风险较低，与 “直接” 用于生产或质量体系的软件的性能相比，保证工作通常可减少；通过利用供应商的评估和验证记录、软件安装或软件配置，往往可充分确定其按预期运行的固有属性，因此可能无需额外的保证活动（如脚本测试或非脚本测试）。
示例：某纠正和预防措施（CAPA）自动化系统采用 JavaScript 编写，且使用调试器工具来设置断点并逐步调试代码。代码调试完成后，在实施前会移除所有调试器内容。在此情况下，调试器工具用于协助软件开发者进行质量体系代码的编写，但不受质量体系要求的约束，因为该工具未与生产或质量体系集成，也不作为生产或质量体系的一部分使用。FDA 建议制造商采用一种负担最小的方法来确保该工具按预期运行。
示例：某制造商采用云存储解决方案来存储生产数据。该系统有网络负载规范，且使用参数化工具来模拟生产系统预期的峰值负载。负载测试结果表明该系统可承受所需的用户负载，且该结果成为客观证据的一部分。参数化工具并非测试结果的记录系统，因为它不会更改生产系统内的代码，且测试不会向生产系统添加任何数据。FDA 建议制造商采用一种负担最小的方法来确保该工具按预期运行。
制造商有责任确定适当的保证活动，以确保软件特征、功能或操作维持验证状态。上述保证活动和考量因素是提供保证的一些可能方式，并非强制性要求或详尽无遗的清单。制造商可利用任何与预期用途相关的风险最匹配的活动，或这些活动的组合。
（6）建立适当的记录
在建立记录时，制造商应获取充分的客观证据，以证明软件特征、功能或操作已得到评估且按预期运行。一般而言，FDA 建议记录包含以下内容：
软件特征、功能或操作的预期用途；
对软件特征、功能或操作开展的基于风险的分析结果；
所开展的保证活动的文件记录，包括：
对保证活动中所进行测试的描述。
测试过程中发现的问题（如偏差、缺陷和 / 或故障）。
声明软件是否可接受其预期用途的结论性陈述。如果发现了问题，制造商可考虑纳入为解决这些问题对预期用途的任何影响而实施的过程控制，或纳入说明这些问题为何不会影响预期用途的适当风险论证。
执行测试 / 评估人员的记录以及测试 / 评估的执行日期。
在适当情况下建立的评审和批准（例如，必要时，具有签字权限人员的签名和日期）。
保证活动的文件记录无需包含超出证明软件特征、功能或操作针对已识别风险按预期运行所需的更多证据。FDA 建议记录保留保证活动的充分细节，以便在需要改进时作为基准，或在出现问题时作为参考点。²⁶
数字技术的进步可能使制造商能够利用结果的数字化留存、自动化可追溯性、自动化测试以及工作执行情况的电子捕获作为客观证据，从而减少对人工或纸质文件的需求。作为一种负担最小的方法，FDA 建议在建立与保证活动相关的记录时，采用数字记录（如系统日志、审计追踪以及由软件生成和维护的其他数据），而非纸质文件、电子表格，或重复软件已以数字方式留存的结果。在使用数字记录时，FDA 建议制造商在已建立的基于风险的保证方法中，考虑记录的预期用途以及对记录的准确性、可靠性、完整性、可用性和真实性的需求。
表 1 提供了在使用基于风险的测试方法（包括上述第五节 A.4 中确定的测试方法）时，实施和编制记录的一些示例。只要制造商的方法符合适用的法律文件要求，他们可以采用替代方法并提供不同的文件。
以下是一个保证记录的示例，场景为某制造商开发了一个电子表格，其预期用途是收集和绘制存储在受控系统中的不合格数据图表，用于监控目的。在本示例中，制造商已建立额外的过程控制和检查，以确保不合格产品不会被放行。在这种情况下，该电子表格无法按预期运行不会导致可预见的、会危及安全性的质量问题，因此该电子表格不会带来高过程风险。制造商对特定功能进行了快速探索性测试
（这些特定功能）用于该电子表格，以确保分析可以被创建、读取、更新和 / 或删除。在探索性测试期间，除了更新过程中出现的一个偏差外，所有计算字段都正确更新。在这种情况下，记录将按以下方式记录：
- 预期用途：该电子表格旨在用于收集和绘制存储在受控系统中的不合格数据图表，以用于监控目的；因此，它被用作生产或质量体系的一部分。由于这种用途，该电子表格与用于业务运营（如会计）的类似软件不同。
- 基于风险的分析：在这种情况下，该软件仅用于收集和显示用于监控不合格情况的数据，并且制造商已建立额外的过程控制和检查，以确保不合格产品不会被放行。因此，该电子表格无法按预期运行不应导致合理情况下会危及安全性的质量问题。因此，该软件不会带来高过程风险，保证活动应与过程风险相匹配。
- 测试对象：电子表格 X，版本 1.2
- 测试类型：无脚本测试 —— 探索性测试
- 目标：确保分析可以被正确创建、读取、更新和删除
测试目标和活动：
创建新分析：通过
从所需来源读取数据：通过
在分析中更新数据：因输入错误失败，重新测试后通过
删除数据：通过
通过观察验证所有计算字段随变更正确更新：通过，但记录了偏差
偏差：在更新测试期间，当用户无意中将文本输入到需要数字数据的可更新字段中时，相关行立即显示错误。
- 结论：该电子表格对于其预期用途是可接受的。向该字段错误输入文本导致该字段仅允许数字输入。一条新的验证规则立即可见，且不影响预期用途。使用该验证规则再次进行了测试，更新通过了所有测试目标。在实施验证规则后，电子表格功能中未观察到其他错误。
- 时间 / 人员：2024 年 7 月 9 日，由简・史密斯（Jane Smith）执行
B. 电子记录要求的考量
制造商们对将《联邦法规法典》第 21 篇第 11 部分（21 CFR Part 11，电子记录；电子签名）应用于作为生产或质量体系一部分的计算机或自动数据处理系统表示困惑和担忧。制造商在确定是否以及如何应用 21 CFR Part 11（以下简称 “Part 11”）时，应参考《Part 11，电子记录；电子签名 —— 范围和应用》指南（以下简称 “《电子记录指南》”）。
Part 11 中的法规规定了 FDA 认为电子记录、电子签名以及针对电子记录的手写签名值得信赖、可靠且通常与纸质记录和在纸质文件上执行的手写签名等效的标准（见 21 CFR 11.1 (a)）。一般而言，Part 11 适用于根据机构法规中规定的任何记录要求以电子形式创建、修改、维护、存档、检索或传输的记录（见 21 CFR 11.1 (b)）。Part 11 也适用于根据《联邦食品、药品和化妆品法案》（FD&C Act）和《公共卫生服务法案》（PHS Act）的要求提交给机构的电子记录，即使此类记录未在机构法规中明确提及（见21 CFR 11.1 (b)）。《联邦食品、药品和化妆品法案》、《公共卫生服务法案》和 FDA 法规（Part 11 除外）中规定的基本要求被称为 “前提性规则”。此外，当电子签名及其相关电子记录符合 Part 11 的要求时，FDA 通常会认为这些电子签名与机构法规要求的完整手写签名、首字母缩写和其他一般签名等效（21 CFR 11.1 (c)）。
对于用作生产或质量体系一部分的计算机软件—— 包括但不限于 Part 820 项下的软件。Part 820 要求的文件 —— 适用的前提性规则包括生产或质量体系 Part 820 项下的规则 —— 包括但不限于 Part 820 要求带有签名并以电子形式保存的文件，通常属于 Part 11 项下的 “电子记录”（见 21 CFR 11.3 (b)(6)）。为了确定 Part 820 何时要求记录，制造商应考虑该记录是否有必要作为证明所需验证的证据等因素。如果制造商以电子形式保存 Part 820 要求的文件，那么 Part 11 通常适用。
示例：证明管理企业系统在生产使用前能正确且可靠地自动检查材料的文件，通常对于制造商而言是支持已验证状态的必要证据。在此示例中，Part 11 通常适用于电子形式的文件。
示例：在应用程序启动时，商用现货软件（COTS）会自动保存日常活动日志。然而，在这种情况下，这些活动日志对于制造商而言不是支持已验证状态的必要证据。在此示例中，Part 11 不适用于这些活动日志。
如《电子记录指南》中所讨论的，FDA 打算对用于创建、修改、维护或传输电子记录的计算机化系统的验证的特定 Part 11 要求行使执法自由裁量权（见 21 CFR 11.10 (a) 和 11.30）。但《电子记录指南》中描述的（关于验证的）执法自由裁量政策明确不适用于根据 21 CFR 820.70 (i) 产生的、用作生产或质量体系一部分的计算机软件的验证要求。
本指南建议制造商将其计算机软件保证方法建立在合理且有记录的风险评估以及对系统影响产品质量、患者安全和记录完整性的潜力的判定基础上。制造商可以利用本指南中概述的负担最小、基于风险的方法来提供保证，确保涉及 Part 11 的、维护电子记录的软件按预期运行。
本节中的示例概述了本指南中的原则在各种软件保证场景中的可能应用。
来源：GMP办公室
关键词：
FDA
CSA指南
