FDA指南 | 生产与质量管理体系软件的计算机软件保证

导读：本文基于美国食品药品监督管理局（FDA）于2026年2月3日发布的行业与FDA工作人员指南《生产与质量管理体系软件的计算机软件保证》进行编译与解读。该指南旨在为医疗器械生产和质量管理中使用的计算机及自动化数据处理系统提供基于风险的“计算机软件保证”建议，取代了2025年9月的旧版文件。本文将严格遵循原文档逻辑，以专业中文呈现其核心框架、风险分析方法及实施考量，重点解析如何应用风险思维来建立并维持软件在生命周期内的受控（已验证）状态，助力行业在合规前提下提升效率与灵活性。

I. 引言 Introduction

FDA发布本指南，旨在为作为医疗器械生产或质量管理体系一部分而使用的计算机和自动化数据处理系统提供关于计算机软件保证 Computer Software Assurance的建议。本指南：

• 将“计算机软件保证”描述为一种基于风险的方法 Risk-Based Approach，用于建立对用于生产或质量管理体系的自动化的信心，并指出在何处可能需要额外的严谨性；以及
• 描述了可用于建立计算机软件保证并提供客观证据以满足法规要求（例如，质量管理体系义务中的计算机软件验证要求，包括经引用并入2016版ISO 13485的21 CFR第820部分中的要求）的各种方法和测试活动。

本指南是对FDA指南《软件验证的一般原则》（下称“软件验证指南”）的补充，但本指南取代了软件验证指南的第6节：自动化工艺设备与质量体系软件的验证。

通常，FDA的指南文件并不建立法律上可强制执行的责任。相反，指南描述了FDA当前对某个主题的思考，应仅被视为建议，除非引用了特定的法规或法定要求。在FDA指南中使用“应 should”一词意味着某事是建议或推荐，但并非强制要求。

II. 背景 Background

FDA设想这样一种未来状态：医疗器械生态系统本质上专注于能提升产品质量和患者安全的器械特性与生产实践。FDA已寻求识别并推广成功的生产实践，帮助器械制造商提高其生产质量水平。在此过程中，一个目标是帮助制造商生产出符合FDA实施的法律法规的高质量医疗器械。遵守质量管理体系义务（包括第820部分中的义务）对于成品医疗器械制造商是必需的，只要他们从事这些义务适用的操作。质量管理体系义务包括要求医疗器械制造商开发、实施、控制并监控生产过程以确保器械符合其规范，包括要求制造商验证作为生产或质量管理体系一部分使用的计算机软件用于其预期用途 for its intended use。

近年来，制造技术的进步，包括自动化、机器人技术、模拟和其他数字能力的采用，使制造商能够减少错误来源、优化资源并降低患者风险。FDA认识到这些技术在提高医疗器械质量、可用性和安全性方面具有巨大潜力，并已采取多项努力来促进此类技术的采用和使用。

传统上，软件验证通常通过在软件开发生命周期每个阶段进行的软件测试和其他验证活动来完成。然而，正如FDA的软件验证指南所解释的，仅靠软件测试通常不足以建立软件适合其预期用途的信心。相反，软件验证指南建议“软件质量保证”应侧重于防止缺陷引入软件开发过程，并鼓励使用基于风险的方法来建立软件适合其预期用途的信心。

FDA认为，对作为生产或质量管理体系一部分使用的计算机软件应用基于风险的方法，将能更好地聚焦制造商的质量保证活动，有助于确保产品质量，同时帮助满足验证要求。因此，FDA正在为作为医疗器械生产或质量管理体系一部分使用的计算机和自动化数据处理系统提供关于计算机软件保证的建议。FDA相信，这些建议将有助于促进创新技术的采用和使用，这些技术可促进患者获得高质量的医疗器械，并帮助制造商跟上动态、快速变化的技术格局，同时促进对FDA实施的法律法规的遵守。

III. 范围 Scope

本指南为用于医疗器械的生产或质量管理体系的计算机或自动化数据处理系统提供关于计算机软件保证的建议。

本指南并非旨在提供软件验证所有原则的完整描述。FDA先前已在FDA的软件验证指南中概述了软件验证的原则，包括将变更管理作为软件生命周期的一部分。本指南将软件验证指南中讨论的基于风险的软件验证方法应用于生产或质量管理体系软件。本指南还讨论了特定的风险考量、可接受的测试方法，以及通过医疗器械生命周期为生产或质量管理体系软件高效生成客观证据。

本指南不提供对符合《联邦食品、药品和化妆品法》（FD&C Act）第201(h)条器械定义的软件功能（即器械软件功能 Device Software Functions）的设计和开发验证或确认要求的建议。有关FDA对医疗器械软件验证的建议的更多信息，请参阅软件验证指南。

IV. 定义 Definitions

• 计算机软件保证 Computer Software Assurance：一种基于风险的方法，用于建立对用于生产或质量管理体系的自动化的信心。计算机软件保证活动提供了软件适合其预期用途 fit for its intended use的客观证据。
• 基于风险的方法 Risk-Based Approach：一种系统性地应用风险管理原则、流程和工具来识别危害、估计和评估相关风险、实施和监控风险控制措施，并评审风险管理过程有效性的方法。
• 预期用途 Intended Use：软件在特定条件下的预期应用。对于本指南，预期用途是指软件作为生产或质量管理体系一部分的用途。
• 已验证状态 Validated State：软件持续适合其预期用途的状态。
• 云计算 Cloud Computing：一种模型，用于实现对可配置计算资源（例如，网络、服务器、存储、应用和服务）的共享池的 ubiquitous（无处不在）、方便、按需的网络访问，这些资源可以通过最少的管理工作或服务提供商交互来快速配置和释放。本指南讨论了与计算机化系统相关的各种云计算模型，例如基础设施即服务 Infrastructure as a Service、平台即服务 Platform as a Service和软件即服务 Software as a Service。

V. 计算机软件保证 Computer Software Assurance

计算机软件保证是一种基于风险的方法，用于建立对用于生产或质量管理体系的自动化的信心。计算机软件保证活动提供了软件适合其预期用途的客观证据。计算机软件保证的目标是帮助确保用于生产或质量管理体系的软件在其整个生命周期内处于受控状态（“已验证状态”）。这一点很重要，因为制造商越来越依赖计算机和自动化处理系统来监控和操作生产、提醒责任人员以及传输和分析生产数据等。通过允许制造商利用诸如基于风险的测试、非脚本化测试、持续性能监控和数据监控，以及其他实体（例如，开发者、供应商、云服务提供商）执行的验证活动等原则，计算机软件保证方法提供了灵活性和敏捷性，有助于确保软件保持符合适用质量管理体系义务的已验证状态。

A. 计算机软件保证风险框架 Computer Software Assurance Risk Framework

以下方法旨在帮助制造商在整个软件生命周期内建立计算机软件保证的基于风险框架。概述的方法可应用于（但不限于）用作生产或质量管理体系一部分的自动化工具（例如，机器人流程自动化或自动工作流）、数据分析工具、人工智能/机器学习工具和云计算。

附录A提供了将此风险框架应用于各种计算机软件保证情况的示例。

(1) 识别预期用途 Identifying the Intended Use

法规要求制造商验证作为生产或质量管理体系一部分使用的软件用于其预期用途 for its intended use。这包括与计算机化系统相关的各种云计算模型，如IaaS、PaaS和SaaS。

为确定验证要求是否适用，制造商必须确定该软件是否（或将要）用作生产或质量管理体系的一部分（无论是直接使用还是用于支持生产或质量管理体系）。

具有以下预期用途的软件被视为直接用作 Directly Used as Part of生产或质量管理体系的一部分：

• 旨在自动化生产过程、检查、测试或生产数据收集与处理的软件；以及
• 旨在自动化质量管理体系流程、质量管理体系数据收集与处理，或维护根据适用质量管理体系义务建立的质量记录 Quality Record的软件。

具有以下预期用途的软件被视为用于支持生产或质量管理体系 Supporting Production or the Quality Management System：

• 旨在用作测试或监控软件系统或自动化用于生产或质量管理体系软件的测试活动的开发工具，例如用于开发和运行脚本或嵌入生产设备（如固件）中的软件的工具；以及
• 旨在自动化非质量记录部分的生产或质量管理体系一般记录保存的软件。

这两种软件都用作生产或质量管理体系的一部分，并且必须根据ISO 13485的4.1.6、7.5.6或7.6子条款（视情况而定）进行验证。然而，如下文进一步讨论，支持性软件通常风险较低，因此在基于风险的计算机软件保证方法下，验证工作可相应减少，而不会影响安全性。

FDA建议制造商在考虑云计算模型时，重点关注软件的预期用途，因为并非所有云计算模型都“直接”用作生产或质量管理体系的一部分。例如，一个IaaS云存储解决方案属于基础设施类别，但可能用于存储根据适用质量管理体系义务建立的质量记录，在这种情况下，该IaaS云存储解决方案将被视为直接用作生产或质量管理体系的一部分。在此示例中，FDA建议制造商将保证工作的重点放在与记录完整性相关的特性或功能以及适用于预期存储记录的21 CFR第11部分要求上。

相反，一个IaaS云存储解决方案可能支持存储生产和过程数据的基础设施；这不会被视作已建立的质量管理体系记录。在此示例中，IaaS云存储解决方案不支持生产或质量管理体系，ISO 13485的4.1.6、7.5.6和7.6子条款中的验证要求将不适用。当数据在云中的存储独立于该数据是否属于质量记录时，制造商有义务确定该应用的适当风险水平。制造商可以考虑采用最低负担方法 Least-Burdensome Approach来确保IaaS云存储解决方案适合其业务。

如ISO 13485的4.1.6、7.5.6和7.6子条款所述，与软件验证和再验证相关的方法和活动需要与软件使用相关的风险（包括对产品符合规范能力的影响）相称。FDA认识到，用于生产或质量管理体系的软件通常是复杂的，由多个特性、功能和操作组成；软件可能根据其各个特性、功能和操作具有一个或多个预期用途。在软件的各个特性、功能和操作在生产或质量管理体系中具有不同作用的情况下，它们可能呈现不同的风险，需要不同程度的验证工作。FDA建议制造商检查各个特性、功能和操作的预期用途，以便于制定基于风险的保证策略。制造商可以决定针对与预期用途相关的各个特性、功能或操作进行不同的保证活动。

例如，一个商用现成品软件 Commercial Off-The-Shelf Software可能包含具有不同预期用途的各种功能。当利用COTS电子表格软件的基本输入功能，用于记录固化过程的时间和温度读数的预期用途时，制造商可能不需要执行超出COTS软件开发者进行的以及初始安装和配置之外的额外保证活动。软件的预期用途“记录读数”仅支持维护过程信息的记录，流程风险较低。因此，初始活动（如成功的供应商评估以及软件安装和配置）可能足以确定软件适合其预期用途并保持已验证状态。然而，如果制造商还利用COTS电子表格的内置功能创建直接用于生产或质量管理体系的自定义公式，则可能存在额外的风险和数据完整性考量。例如，如果自定义公式自动计算时间和温度统计数据以监控固化过程的性能和适用性，则可能需要制造商进行额外的验证。

就本指南而言，我们描述并推荐一个计算机软件保证框架，其中制造商检查软件的各个特性、功能或操作的预期用途。然而，在软件只有一个预期用途的简单情况下（例如，如果软件内的所有特性、功能和操作共享相同的预期用途），制造商可能会发现单独检查每个特性、功能和操作并无帮助。在这种情况下，制造商可以根据软件的整体预期用途制定基于风险的方法并考虑保证活动。

FDA建议制造商记录其用于确定软件特性、功能或操作是否（或将要）用作生产或质量管理体系一部分的决策过程。

(2) 确定基于风险的方法 Determining the Risk-Based Approach

一旦制造商确定软件特性、功能或操作已（或将要）用作生产或质量管理体系的一部分，则使用基于风险的分析来确定适当的保证活动。应注意，根据ISO 13485的4.1.2子条款，制造商需要将基于风险的方法应用于控制质量管理体系所需的适当过程。广义而言，这种基于风险的方法包括系统性地识别合理可预见的软件故障，确定此类故障是否构成高流程风险 High Process Risk，并系统性地选择和执行与医疗器械风险或流程风险（视情况而定）相称的保证活动。

制造商应根据其基于风险的分析，并考虑其流程和程序，为所执行的软件和保证活动选择适当的保证活动执行频率。

请注意，如本指南所述，为生产或质量管理体系软件进行计算机软件保证的基于风险分析，与执行ISO 14971:2019中描述的医疗器械风险分析是不同的。生产或质量管理体系软件的基于风险分析侧重于那些可能影响或阻止软件按预期执行的因素，例如适当的系统配置和管理、系统安全性、数据完整性、数据存储、数据传输或操作错误。生产或质量管理体系软件的基于风险分析应考虑哪些故障是合理可预见的（而非可能的），以及每个此类故障导致的风险。例如，在基于风险的分析中，制造商可以考虑停电导致的风险，这在生产或质量管理体系的生命周期中可能不常发生，但合理可预见会发生。本指南讨论了流程风险 Process Risk和医疗器械风险 Medical Device Risk。流程风险是指损害生产或质量管理体系的潜在可能性。医疗器械风险是指器械伤害患者或用户的潜在可能性。在讨论医疗器械风险时，本指南侧重于因损害安全性的质量问题导致的医疗器械风险。

具体而言，FDA认为，当软件特性、功能或操作未能按预期执行可能导致损害安全性的质量问题时，即构成高流程风险。此流程风险识别步骤仅关注流程本身，而非对患者或用户造成的医疗器械风险。

通常属于高流程风险的软件特性、功能或操作示例包括那些：

• 维持影响产品物理特性或被确定为对器械安全性至关重要的制造工艺的工艺参数 Process Parameters（例如，温度、压力或湿度）；
• 在有限或没有额外人工感知或审查的情况下，测量、检查、分析和/或确定产品或工艺的可接受性；
• 基于数据监控或其他工艺步骤的自动化反馈，在没有额外人工感知或审查的情况下，执行工艺纠正或调整工艺参数；
• 生成对医疗器械安全操作必要的使用说明或其他提供给患者和用户的标签；和/或
• 自动化制造商确定为对器械安全性（例如，网络安全）和质量至关重要的数据的监控、趋势分析或跟踪。

相反，FDA认为，当软件特性、功能或操作未能按预期执行不会导致损害安全性的质量问题时，则不构成高流程风险。这包括未能按预期执行不会导致质量问题的情况，以及未能按预期执行可能导致质量问题但不会合理可预见地导致安全性受损的情况。通常不构成高流程风险的软件特性、功能或操作示例包括那些：

• 收集和记录用于监控和审查目的的过程数据，这些数据对生产或工艺性能没有直接影响；
• 用作质量管理体系一部分，用于纠正和预防措施 Corrective and Preventive Actions路由、投诉的自动化记录/跟踪、自动化变更控制管理或自动化程序管理；
• 旨在管理数据（处理、存储和/或组织数据）、自动化现有计算、增加过程监控，或在既定过程中发生异常时提供与数据管理相关的警报；和/或
• 用于支持生产或质量管理体系，如第V.A.1节所述。

FDA承认，与用作生产或质量管理体系一部分的软件相关的流程风险是一个范围，从高流程风险到低流程风险。制造商应根据软件的预期用途，确定每个软件特性、功能或操作在该风险范围上的风险等级。FDA主要关注那些高流程风险的软件特性、功能和操作的审查和保证，因为其故障也构成医疗器械风险。就本指南而言，FDA以二元方式呈现流程风险，即“高流程风险”和“非高流程风险”。制造商仍可确定流程风险为“中等”、“中间”甚至“低”，以用于确定保证活动；在这种情况下，本指南中关于“非高流程风险”的部分将适用。如下文第V.A.4节所述，应对“高流程风险”的软件进行与医疗器械风险相称的保证活动，对“非高流程风险”的软件进行与流程风险相称的保证活动。

(3) 生产或质量管理体系软件变更 Production or Quality Management System Software Changes

对于已批准上市前批准申请 Premarket Approval Applications或人道主义器械豁免 Humanitarian Device Exemptions的器械，对不影响器械安全或有效性的制造程序或制造方法的变更，如果在向FDA的定期报告（通常称为年度报告）中报告，则不需要提交PMA/HDE增补。PMA/HDE增补也不需要对影响器械安全性和有效性的制造程序或制造方法的修改；这些修改以30天通知的形式提交。对制造程序或制造方法的变更可能包括对用于生产或质量管理体系的软件的变更。对于已批准PMA或HDE的器械，在其生产或质量管理体系软件的增加或变更方面，FDA建议制造商应用上述第V.A.2节概述的原则来确定变更是否可能影响器械的安全性或有效性。通常，如果变更可能导致损害安全性的质量问题，则应提交30天通知。如果变更不会导致损害安全性的质量问题，则该变更可能适合在年度报告中报告。

(4) 确定适当的保证活动 Determining the Appropriate Assurance Activities

一旦制造商确定软件特性、功能或操作是否构成高流程风险（即可能导致损害安全性的质量问题），制造商应识别与医疗器械风险或流程风险相称的保证活动。在质量问题可能损害安全性（高流程风险）的情况下，保证水平应与医疗器械风险相称。在质量问题可能不会损害安全性（非高流程风险）的情况下，保证严谨性水平应与流程风险相称。在任何一种情况下，软件特性、功能或操作的较高风险通常需要更严格的保证工作（即更多的客观证据）。相反，相对较低的风险（即非高流程风险）可能允许较不严格的保证工作（即较少的客观证据）。

制造商可考虑作为保证活动一部分的手动或自动化测试类型包括但不限于以下内容：

• 非脚本化测试 Unscripted Testing：测试人员的操作未由测试用例中的书面指令规定的动态测试。它包括：
  • 探索性测试 Exploratory Testing：一种基于经验的测试，测试人员积极控制测试设计，并将测试设计、测试执行、测试结果分析和学习同时或交替进行，作为相互支持的活动。
  • 基于错误的测试 Error-Guessing：一种基于经验的测试技术，测试人员利用其技能和直觉来识别可能已引入故障的测试条件。
• 脚本化测试 Scripted Testing：测试人员的操作由书面指令规定的动态测试。
• 自动化测试 Automated Testing：使用软件工具执行测试活动并评估结果，而无需人工干预。
• 基于场景的测试 Scenario-Based Testing：一种基于需求的测试，其中测试用例基于用户场景设计。
• 基于风险的测试 Risk-Based Testing：一种测试方法，其中测试活动的管理、选择、优先级排序和使用有意识地基于相应类型和水平的已分析风险。

对于高流程风险的软件特性、功能和操作，可能需要更严格的测试方法，例如详细的脚本化测试，以提供更高水平的保证。对于非高流程风险的软件特性、功能和操作，非脚本化测试可能就足够了。然而，对于某些非高流程风险的软件特性、功能和操作，制造商可能会发现脚本化测试更合适。例如，对于具有多个复杂交互或需要严格可重复性以支持其预期用途的软件特性、功能和操作，更稳健的脚本化测试（其中测试用例和证据可能包括可重复性、可追溯性或可审计性的详细要求）可能是合适的。

本指南描述了制造商可考虑用于满足法规要求的基于风险方法。它并非软件测试方法和原则的详尽列表。FDA认识到，除了指南中引用的方法外，还有制造商可以根据情况灵活考虑和使用的软件测试方法和途径。例如，适用于具有网络安全考量的器械的《医疗器械网络安全：质量管理体系考量与上市前提交内容》指南，描述了针对某些上市前提交类型的器械提交网络安全信息的建议，包括用于证明设计和开发活动有效性的网络安全测试建议。制造商在进行本指南所述的保证活动时，可考虑使用该指南中描述的网络安全测试方法，如适用。

通常，FDA建议制造商应用基于风险的测试 Risk-Based Testing原则，其中有意识地基于相应类型和水平的已分析风险来管理、选择、优先级排序和使用测试活动及资源，以确定适当的保证活动。对于高流程风险的软件特性、功能和操作，制造商可能会发现非脚本化测试（如探索性测试）更适合，即使对于高流程风险的特性、功能和操作，也能保证软件按预期执行。相反，制造商可能会发现为非高流程风险的特性、功能和操作开发脚本化测试并实现自动化更为有效和高效。

(5) 保证活动的额外考量 Additional Considerations for Assurance Activities

在决定适当的保证活动时，制造商应考虑在整个质量管理体系中是否存在任何额外的控制或机制，这些控制或机制可以在软件特性、功能或操作发生故障时降低安全性受损和/或质量影响。例如，作为全面保证方法的一部分，制造商可以利用以下方面来减少额外保证活动的工作量：

• 在软件参与的生产过程中提供控制或完全验证过程的活动和既定流程。此类活动可能包括确保支持生产的数据完整性、后续检查或测试的程序，或由其他组织单位执行的软件质量保证过程。
• 用于选择和监督软件供应商的既定采购控制 Purchasing Control流程。例如，医疗器械制造商可以将软件开发者已执行的软件开发实践、验证工作和电子信息作为起点，并确定可能需要哪些额外的活动。对于一些较低风险的软件特性、功能和操作，这可能就是制造商所需的全部保证。
• 在整个生产过程中已纳入的额外过程控制，包括减少网络安全暴露的活动。例如，如果一个过程被充分理解，所有关键工艺参数都受到监控，和/或一个过程的所有输出都经过验证测试，这些控制可以作为额外的机制来检测和纠正软件特性、功能或操作未能按预期执行时可能发生的质量问题。在此示例中，这些控制的存在可以用来减少适合该软件的保证活动的工作量。
• 尽可能使用支持软件开发和系统生命周期活动的工具（例如，缺陷、异常跟踪、需求可追溯性工具）来保证用于生产或作为质量管理体系一部分的软件。
• 在用于生产或作为质量管理体系一部分的软件的整个生命周期中，迭代循环和持续进行的测试及结果。

FDA认识到，制造商作为评估的一部分，可能对软件供应商的信息访问有限，并建议制造商在其保证方法中建立并应用对软件供应商的基于风险分析。制造商的评估在决定软件供应商（例如，采购控制）的适当控制水平时，可以考虑各种信息来源。为了评估供应商的能力（无论是基于云、本地部署还是混合模式），制造商可以考虑的活动包括但不限于：

• 对供应商进行现场审计（如适用）。FDA承认，对于器械制造商来说，审计软件供应商可能不可行或不合适。制造商可以在对软件供应商的控制和能力进行基于风险的分析时，考虑任何替代的信息组合（如适用）；
• 保留记录、归档数据以及生成准确完整的记录副本；
• 保护静态和传输中的数据（即，维护用户操作和数据更改的安全、计算机生成的、带时间戳的审计跟踪，加密数据）；和/或
• 为用户操作建立和维护访问控制、电子签名控制和授权检查。

制造商应在其程序中建立并维护其对供应商的要求，基于供应商满足规定要求的能力，并定义对产品、服务和供应商实施的控制类型和程度。制造商应在评估决策中考虑有关供应商的适当信息来源。

FDA建议制造商建立基于风险的方法，用于评估软件或服务的供应商、评估活动以及保留适当的客观证据。

例如，如第V.A.1节所述，支持性软件通常风险较低，因此保证工作通常可相应减少。因为“直接”用于生产或质量管理体系的保证活动通常固有地涵盖了支持性软件的性能，通过利用供应商评估和验证记录、软件安装或软件配置，可能足以确定该支持性软件按预期执行，从而使得额外的保证活动（例如，脚本化或非脚本化测试）变得不必要。

制造商负责确定确保软件特性、功能或操作保持已验证状态的适当保证活动。上述保证活动和考量是提供保证的一些可能方式，并非旨在规定性或详尽无遗。制造商可以利用任何最适合与预期用途相关风险的活动或活动组合。

(6) 建立适当的记录 Establishing the Appropriate Record

在建立记录时，制造商应捕获足够的客观证据，以证明软件特性、功能或操作已得到评估并按预期执行。通常，FDA建议记录包括以下内容：

• 软件特性、功能或操作的预期用途；
• 软件特性、功能或操作的基于风险分析的结果；以及
• 所进行的保证活动的文件记录，包括：
  • 基于保证活动进行的测试描述。
  • 测试期间发现的问题（例如，偏差、缺陷和/或故障）。
  • 声明软件适合其预期用途的结论陈述。如果发现问题，FDA建议将发现问题的解决作为结论陈述的一部分。制造商可考虑包括为解决任何问题对预期用途的影响而实施的过程控制，或说明为何发现的问题不会影响预期用途的适当风险论证。
  • 执行测试/评估的人员记录和测试/评估执行的日期。
  • 适当时建立的审查和批准（例如，必要时，具有签署权限的个人的签名和日期）。

保证活动的文件记录无需包含超出必要范围以证明软件特性、功能或操作按预期执行以应对已识别风险的证据。FDA建议记录保留保证活动的足够细节，以作为改进的基线或问题发生时的参考点。

数字技术的进步可能允许制造商利用结果的数字保留、自动化可追溯性、自动化测试以及所执行工作的电子捕获作为客观证据，减少对人工或纸质文件的需求。作为一种最低负担方法，FDA建议结合使用数字记录，例如系统日志、审计跟踪和软件生成及维护的其他数据，而不是纸质文件、屏幕截图或复制软件已数字保留的结果。在使用数字记录时，FDA建议制造商将记录的准确性、可靠性、完整性、可用性和真实性的需求作为已建立的基于风险保证方法的一部分加以考虑。

表1提供了在使用基于风险的测试方法（包括上文第V.A.4节中确定的测试方法）时，实施和开发记录的一些示例方式。制造商可以使用替代方法并提供不同的文件记录，只要其方法满足适用的法律文件记录要求即可。

表1：基于风险的测试方法记录示例

以下是一个保证活动记录的示例，场景是制造商开发了一个电子表格，其预期用途是收集和绘制存储在受控系统中的不合格数据以用于监控目的。在此示例中，制造商已建立了额外的过程控制和检查，确保不合格产品不被放行。在这种情况下，电子表格未能按预期执行不会导致损害安全性的质量问题，因此该电子表格不构成高流程风险。制造商对电子表格中使用的特定功能进行了快速探索性测试，以确保可以创建、读取、更新和/或删除分析。在探索性测试期间，所有计算字段都正确更新，除了在测试更新时发生的一个偏差。在此场景中，记录将如下记录：

• 基于风险的分析：在这种情况下，该软件仅用于收集和显示数据以监控不合格，并且制造商已建立了额外的过程控制和检查以确保不合格产品不被放行。因此，电子表格未能按预期执行不应导致损害安全性的质量问题。因此，该软件不构成高流程风险，保证活动应与流程风险相称。
• 保证活动：进行了探索性测试。测试目标：验证电子表格可以创建、读取、更新和删除分析。测试结果：所有计算字段在更新时正确更新，除了一个偏差（具体描述偏差）。偏差已解决（描述解决方式）。
• 结论：该电子表格适合其预期用途。
• 记录：测试人员：张三。测试日期：2026-03-15。

B. 电子记录要求的考量 Considerations for Electronic Records Requirements

制造商对21 CFR第11部分《电子记录；电子签名》对用作生产或质量管理体系一部分的计算机或自动化数据处理系统的适用性表示困惑和关切。制造商在确定是否以及如何应用21 CFR第11部分（下称“第11部分”）时，应参考《第11部分，电子记录；电子签名——范围与应用》指南（下称“电子记录指南”）。

第11部分中的法规规定了FDA认为电子记录、电子签名以及手写签名应用于电子记录是可信、可靠且通常等同于纸质记录和手写签名应用于纸质记录的标准。通常，第11部分适用于根据FDA法规规定的任何记录要求创建、修改、维护、归档、检索或传输的电子形式记录。第11部分也适用于根据《联邦食品、药品和化妆品法》和《公共卫生服务法》要求提交给FDA的电子记录，即使此类记录未在FDA法规中特别指明。在《FD&C法案》、《PHS法案》和FDA法规（第11部分除外）中规定的基本要求被称为“基础规则 Predicate Rules”。此外，如果电子签名及其关联的电子记录符合第11部分的要求，FDA通常将认为电子签名等同于FDA法规要求的完整手写签名、首字母和其他一般签署。

对于用作生产或质量管理体系一部分的计算机软件，适用的基础规则包括第820部分下的规则。第820部分要求的文件——包括但不一定是第820部分要求签名的文件——并以电子形式维护的，通常构成第11部分下的“电子记录”。为确定何时需要根据第820部分保留记录，制造商应考虑，除其他事项外，该记录是否作为证明所需验证的证据是必要的。如果制造商以电子形式维护第820部分要求的文件，则第11部分通常适用。

示例：证明管理企业系统正确可靠地自动化检查生产前材料的文件，通常作为制造商支持已验证状态的必要证据。在此示例中，如果以电子形式存在，第11部分通常适用于该文件。
示例：在应用启动时，一个COTS软件自动保存常规活动日志。然而，在这种情况下，这些活动日志并非制造商支持已验证状态的必要证据。在此示例中，第11部分不适用于活动日志。

如电子记录指南中所述，FDA打算对用于创建、修改、维护或传输电子记录的计算机化系统的验证的特定第11部分要求行使执法自由裁量权。但电子记录指南中描述的执法自由裁量政策（关于用于创建、修改、维护或传输电子记录的计算机化系统的验证）明确不适用于根据ISO 13485的4.1.6、7.5.6和7.6子条款产生的、用于生产或质量管理体系的计算机软件的验证要求。

本指南建议制造商将其计算机软件保证方法建立在合理且有文件记录的风险评估以及对系统可能影响产品质量、患者安全和记录完整性的潜在性的确定之上。制造商可以利用本指南中概述的最低负担、基于风险的方法来提供保证，确保维护受第11部分约束的电子记录的软件按预期执行。

附录A. 示例 Appendix A. Examples

本节中的示例概述了本指南中的原则在各种软件保证情况下的可能应用。

示例1：不合格管理系统

制造商购买并配置了用于自动化其不合格流程的COTS软件，并在实施中应用基于风险的计算机软件保证方法。该软件旨在以电子方式管理不合格流程。

作为保证活动的一部分，制造商对软件供应商进行了全面评估，包括：

• 评估供应商的软件开发生命周期，
• 审查供应商的质量管理体系和相关认证，以及
• 审查供应商的网络安全文件和生命周期管理计划以及相关认证。

根据制造商既定的供应商评估SOP，供应商满足制造商要求的能力被视为可接受该软件的预期用途。制造商根据其既定的采购控制程序保留了评估记录。

制造商在制定基于风险的保证策略时考虑了以下特性、功能或操作：

示例3：商业智能应用

医疗器械制造商决定实施一个商业商业智能解决方案，用于数据挖掘、分析和报告。该软件旨在更好地了解产品和过程随时间推移的性能，以识别改进机会。

作为保证活动的一部分，制造商对软件供应商进行了全面评估，包括：

• 评估供应商的软件开发生命周期，
• 审查供应商的质量管理体系和相关认证，以及
• 审查供应商的网络安全文件和生命周期管理计划以及相关认证。

根据制造商既定的供应商评估SOP，供应商满足制造商要求的能力被视为可接受该软件的预期用途。制造商根据其既定的采购控制程序保留了评估记录。

除了供应商评估，制造商在制定基于风险的保证策略时还考虑了以下特性、功能或操作：

示例4：软件即服务产品生命周期管理系统

制造商正在实施一个SaaS产品生命周期管理系统，用于管理产品开发项目。该软件的预期用途是捕获项目需求、制定项目计划、监控/跟踪项目执行，并在项目结束时维护相关记录、签名和交付物。该系统的此预期用途不直接影响患者安全或产品质量，但确实维护了一个需要数据完整性的质量记录。制造商不需要对SaaS产品的“开箱即用”功能进行任何定制，只需要执行SaaS产品的基本标准配置（例如，用户角色、账户）。

作为保证活动的一部分，制造商对SaaS供应商进行了全面评估，包括：

• 评估供应商的软件开发生命周期，
• 审查供应商的质量管理体系和相关认证，
• 审查供应商的网络安全文件和生命周期管理计划以及相关认证，以及
• 审查供应商的基础设施支持，包括可用性和可靠性。

根据制造商既定的供应商评估SOP，供应商满足制造商要求的能力被视为可接受该软件的预期用途。制造商根据其既定的采购控制程序保留了评估记录。制造商还与SaaS供应商建立了服务协议，其中包括安全性、数据完整性、隐私、可用性、变更管理和业务连续性要求。

结语

FDA《生产与质量管理体系软件的计算机软件保证》指南的发布，标志着对医疗器械行业软件验证实践的现代化指引。其核心在于推动从传统、可能过于繁琐的验证方式，向灵活、高效且基于风险的“保证”模式转变。通过聚焦软件的预期用途 Intended Use、科学评估流程风险 Process Risk与医疗器械风险 Medical Device Risk，并允许采用多样化的测试方法（从严格的脚本化测试到灵活的探索性测试），该框架旨在帮助企业在确保患者安全和产品质量的前提下，更敏捷地采用和创新自动化与数字化技术。制造商应深入理解其软件在生产与质量管理中的具体作用，据此制定并记录基于风险的保证策略，从而在合规与创新之间找到最佳平衡点。

免责声明：本文是对美国FDA指南文件《Computer Software Assurance for Production and Quality Management System Software》的专业解读与编译，旨在传递信息与促进理解。本文内容不应被视为法律或监管建议，也不构成任何官方文件的替代。对于文中的任何解读或表述，读者在应用于具体实践前，应始终以FDA发布的原始英文指南文件及其引用的相关法律法规为准，并建议咨询专业的法规事务或质量保证人员。编译者不对依赖本文内容所采取的任何行动或决策承担法律责任。