从一八年概念提出，到二二年草稿版二十几页，再到今天终版四十页页，虽然最后只有cdrh和cber参与，虽然主要只适用与医疗器械和qms体系系统，但是这是行业的一大步，让人亢奋
Table of Contents
目录
I. Introduction .................................................................................................................4
I. 引言.............................................................................................................................4
II. Background ...............................................................................................................5
II. 背景.............................................................................................................................5
III. Scope ..........................................................................................................................6
III. 范围.................................................................................................................................6
IV. Definitions ...................................................................................................................7
IV. 定义...............................................................................................................................7
V. Computer Software Assurance ..................................................................................8
V. 计算机软件保障...............................................................................................................8
A. Computer Software Assurance Risk Framework ...................................................8
A. 计算机软件保障风险框架.............................................................................................8
(1) Identifying the Intended Use .................................................................................9
(1) 识别预期用途........................................................................................9
(2) Determining the Risk-Based Approach ...............................................................11
(2) 确定基于风险的方法......................................................................11
(3) Production or Quality System Software Changes ............................................14
(3) 生产或质量体系软件变更......................................................14
(4) Determining the Appropriate Assurance Activities ..........................................14
(4) 确定适当的保障活动....................................................14
(5) Additional Considerations for Assurance Activities ........................................17
(5) 保障活动的其他考虑因素..................................................17
(6) Establishing the Appropriate Record ..................................................................19
(6) 建立适当的记录..........................................................................19
B. Considerations for Electronic Records Requirements .........................................23
B. 电子记录要求的考虑因素...................................................23
Appendix A. Examples ...................................................................................................26
附录A. 示例.................................................................................................................26
Example 1: Nonconformance Management System ...............................................26
示例1：不合格品管理系统.................................................................26
Example 2: Learning Management System (LMS) ...................................................30
示例2：学习管理系统（LMS）..................................................................30
Example 3: Business Intelligence Applications ....................................................33
示例3：商业智能应用程序........................................................................33
Example 4: Software as a Service (SaaS) Product Life Cycle Management System (PLM) ...37
示例4：软件即服务（SaaS）产品生命周期管理系统（PLM） ...37
I. Introduction ................................................................................................4
I. 引言...............................................................................................................4
FDA is issuing this guidance to provide recommendations on computer software assurance for computers and automated data processing systems used as part of medical device production or the quality system. This guidance:
FDA发布本指南，旨在为用于医疗器械生产或质量系统的计算机及自动化数据处理系统提供计算机软件保障方面的建议。本指南：
• Describes "computer software assurance" as a risk-based approach to establish confidence in the automation used for production or quality systems, and identifies where additional rigor may be appropriate; and
• 将“计算机软件保障”描述为一种基于风险的方法，用于建立对生产或质量系统所用自动化手段的信心，并指出在哪些情况下可能需要采取更严格的措施；以及
• Describes various methods and testing activities that may be applied to establish computer software assurance and provide objective evidence to fulfill regulatory requirements, such as computer software validation requirements in quality system obligations, including requirements in 21CFR Part 820 (hereafter referred to as "Part 820").
• 介绍了可用于建立计算机软件保障并提供客观证据以满足法规要求的各种方法和测试活动，例如满足质量体系义务中的计算机软件验证要求，包括21CFR第820部分（以下简称“第820部分”）中的要求。
This guidance supplements FDA's guidance, "General Principles of Software Validation" (hereafter referred to as the "Software Validation guidance"), except this guidance supersedes Section 6: Validation of Automated Process Equipment and Quality System Software of the Software Validation guidance.
本指南是对FDA《软件验证通用原则》（以下简称“软件验证指南”）的补充，但本指南取代了软件验证指南中第6节“自动化工艺设备及质量系统软件的验证”。
For the current edition of the FDA-recognized consensus standard referenced in this document, see the FDA Recognized Consensus Standards Database.
有关本文件中引用的FDA认可共识标准的最新版本，请参见《FDA认可共识标准数据库》。
In general, FDA's guidance documents do not establish legally enforceable responsibilities. Instead, guidances describe the Agency's current thinking on a topic and should be viewed only as recommendations, unless specific regulatory or statutory requirements are cited. The use of the word should in Agency guidances means that something is suggested or recommended, but not required.
一般而言，FDA指南文件并不设定具有法律强制执行力的责任。相反，指南阐述了FDA对某一主题的当前观点，除非引用了具体的法规或法定要求，否则应仅视为建议。FDA指南中使用“应”（should）一词表示某事被建议或推荐，但并非强制要求。
II. Background .................................................................................................5
II. 背景................................................................................................................5
FDA envisions a future state where the medical device ecosystem is inherently focused on device features and manufacturing practices that promote product quality and patient safety.
FDA 设想未来的医疗器械生态系统将聚焦于能够促进产品质量和患者安全的器械特性和生产实践。
FDA has sought to identify and promote successful manufacturing practices and help device manufacturers raise their manufacturing quality level.
FDA 致力于识别和推广成功的生产实践，帮助器械制造商提升其生产质量水平。
In doing so, one goal is to help manufacturers produce high-quality medical devices that align with the laws and regulations implemented by FDA.
为此，目标之一是帮助制造商生产出符合 FDA 法律法规要求的高质量医疗器械。
Compliance with quality system obligations including those in Part 820 is required for manufacturers of finished medical devices to the extent they engage in operations to which those obligations apply.
成品医疗器械制造商必须遵守质量体系义务，包括第 820 部分中的要求，只要其从事适用这些义务的操作。
Quality system obligations include requirements for medical device manufacturers to develop, conduct, control, and monitor production processes to ensure that a device conforms to its specifications, including requirements for manufacturers to validate computer software used as part of production or the quality system for its intended use.
质量体系义务要求医疗器械制造商开发、实施、控制和监控生产过程，以确保器械符合其规范，包括验证用于生产或质量系统的计算机软件是否适用于其预期用途。
The recommendations on computer software assurance in this guidance are intended to promote product quality and patient safety, and correlate to higher-quality outcomes.
本指南中关于计算机软件保障的建议旨在促进产品质量和患者安全，并与更高质量的结果相关联。
This guidance addresses practices relating to computers and automated data processing systems used as part of production or the quality system.
本指南涉及用于生产或质量系统的计算机和自动化数据处理系统的实践。
In recent years, advances in manufacturing technologies, including the adoption of automation, robotics, simulation, and other digital capabilities, have allowed manufacturers to reduce sources of error, optimize resources, and reduce patient risk.
近年来，包括自动化、机器人、仿真和其他数字化能力在内的制造技术进步，使制造商能够减少错误来源、优化资源并降低患者风险。
FDA recognizes the potential for these technologies to provide significant benefits for enhancing the quality, availability, and safety of medical devices, and has undertaken several efforts to help foster the adoption and use of such technologies.
FDA 认识到这些技术在提升医疗器械质量、可及性和安全性方面具有显著潜力，并已采取多项措施促进这些技术的采用和使用。
Specifically, FDA has engaged with stakeholders via the Medical Device Innovation Consortium (MDIC), site visits to medical device manufacturers, and benchmarking efforts with other industries (e.g., automotive, consumer electronics) to keep abreast of the latest technologies and to better understand stakeholders' challenges and opportunities for further advancement.
具体而言，FDA 通过医疗器械创新联盟（MDIC）、对医疗器械制造商的现场访问以及与其他行业（如汽车、消费电子）的对标工作，与利益相关方保持沟通，以紧跟最新技术并更好地理解其在进一步推进中的挑战与机遇。
As part of these ongoing efforts, medical device manufacturers have expressed a desire for greater clarity regarding the Agency's expectations for software validation for computers and automated data processing systems used as part of production or the quality system.
在这些持续努力中，医疗器械制造商表示，希望 FDA 能更明确地说明其对用于生产或质量系统的计算机和自动化数据处理系统的软件验证期望。
Given the rapidly changing nature of software, manufacturers have also expressed a desire for a more iterative, agile approach for validation of computer software used as part of production or the quality system.
鉴于软件变化迅速，制造商还希望采用更迭代、更敏捷的方法来验证用于生产或质量系统的计算机软件。
Traditionally, software validation has often been accomplished via software testing and other verification activities conducted at each stage of the software development life cycle.
传统上，软件验证通常通过在软件开发生命周期的每个阶段进行软件测试和其他验证活动来完成。
However, as explained in FDA's Software Validation guidance, software testing alone is often insufficient to establish confidence that the software is fit for its intended use.
然而，正如 FDA 的《软件验证指南》中所述，仅依靠软件测试往往不足以建立对软件适用于其预期用途的信心。
Instead, the Software Validation guidance recommends that "software quality assurance" focus on preventing the introduction of defects into the software development process, and it encourages use of a risk-based approach for establishing confidence that software is fit for its intended use.
相反，《软件验证指南》建议“软件质量保证”应专注于防止在软件开发过程中引入缺陷，并鼓励采用基于风险的方法来建立对软件适用于其预期用途的信心。
FDA believes that applying a risk-based approach to computer software used as part of production or the quality system would better focus manufacturers' quality assurance activities to help ensure product quality while helping to fulfill validation requirements.
FDA 认为，对用于生产或质量系统的计算机软件采用基于风险的方法，将有助于制造商更有针对性地开展质量保证活动，在确保产品质量的同时，帮助满足验证要求。
For these reasons, FDA is providing recommendations on computer software assurance for computers and automated data processing systems used as part of medical device production or the quality system.
因此，FDA 就用于医疗器械生产或质量系统的计算机和自动化数据处理系统的计算机软件保障提供建议。
FDA believes that these recommendations will help foster the adoption and use of innovative technologies that promote patient access to high-quality medical devices and help manufacturers to keep pace with the dynamic, rapidly changing technology landscape, while promoting compliance with laws and regulations implemented by FDA.
FDA 相信，这些建议将有助于促进创新技术的采用和使用，使患者能够获得高质量的医疗器械，并帮助制造商跟上动态、快速变化的技术环境，同时促进遵守 FDA 实施的法律法规。
III. Scope .....................................................................................................6
III. 范围...............................................................................................................6
This guidance provides recommendations regarding computer software assurance for computers or automated data processing systems used as part of production or the quality system for medical devices.
本指南为用于医疗器械生产或质量系统的计算机或自动化数据处理系统提供计算机软件保障方面的建议。
This guidance is not intended to provide a complete description of all software validation principles. FDA has previously outlined principles for software validation, including managing changes as part of the software life cycle, in FDA's Software Validation guidance. This guidance applies the risk-based approach to software validation discussed in the Software Validation guidance to production or quality system software. This guidance additionally discusses specific risk considerations, acceptable testing methods, and efficient generation of objective evidence for production or quality system software through the life cycle of the medical device.
本指南并不旨在对所有软件验证原则进行完整描述。FDA此前已在《软件验证指南》中概述了软件验证原则，包括将变更管理作为软件生命周期的一部分。本指南将《软件验证指南》中讨论的基于风险的软件验证方法应用于生产或质量系统软件。本指南进一步讨论了特定风险考虑、可接受的测试方法，以及在医疗器械整个生命周期内为生产或质量系统软件高效生成客观证据的方法。
This guidance does not provide recommendations for the design verification or validation requirements for device software functions, which are software functions that meet the definition of a device under section 201(h) of the Federal Food, Drug, and Cosmetic Act (FD&C Act). For more information regarding FDA's recommendations for the validation of medical device software, see the Software Validation guidance.
本指南不为器械软件功能（即符合《联邦食品、药品和化妆品法》（FD&C Act）第201(h)条所定义器械的软件功能）的设计验证或确认要求提供建议。有关FDA对医疗器械软件验证的建议，请参见《软件验证指南》。
IV. Definitions .................................................................................................7
IV. 定义.............................................................................................................7
Note: The following definitions apply for the purposes of this guidance. Some definitions originate from other FDA sources (e.g., Software Validation guidance) and are applicable in those instances.
注：以下定义适用于本指南。部分定义源自其他FDA文件（如《软件验证指南》），并在相应情况下适用。
Cloud Computing (Cloud): Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction.
云计算（云）： 云计算是一种模式，用于实现无处不在、便捷、按需的网络访问，可访问共享的可配置计算资源池（如网络、服务器、存储、应用程序和服务），这些资源可以快速配置和释放，且管理开销或服务提供商交互最小。
This cloud model is composed of five essential characteristics: on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service. The cloud is composed of three service models: Software as a Service (SaaS), Platform as a Service (PaaS), and Infrastructure as a Service (IaaS). The cloud model is also composed of four deployment models: private cloud, community cloud, public cloud, and hybrid cloud.
该云模式由五个基本特征组成：按需自助服务、广泛的网络访问、资源池化、快速弹性和可计量服务。云由三种服务模式组成：软件即服务（SaaS）、平台即服务（PaaS）和基础设施即服务（IaaS）。云还包括四种部署模式：私有云、社区云、公有云和混合云。
Infrastructure as a Service (IaaS): The capability provided to the consumer is to provision processing, storage, networks, and other fundamental computing resources where the consumer is able to deploy and run arbitrary software, which can include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, and deployed applications; and possibly limited control of select networking components (e.g., host firewalls).
基础设施即服务（IaaS）： 向消费者提供的能力是配置处理、存储、网络和其他基本计算资源，消费者可在此之上部署和运行任意软件，包括操作系统和应用程序。消费者不管理或控制底层云基础设施，但可控制操作系统、存储和已部署的应用程序，并可能对部分网络组件（如主机防火墙）有有限控制权。
Platform as a Service (PaaS): The capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created or acquired applications created using programming languages, libraries, services, and tools supported by the provider. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, or storage, but has control over the deployed applications and possibly configuration settings for the application-hosting environment.
平台即服务（PaaS）： 向消费者提供的能力是将消费者创建或获取的应用程序部署到云基础设施上，这些应用程序使用提供商支持的编程语言、库、服务和工具编写。消费者不管理或控制底层云基础设施（包括网络、服务器、操作系统或存储），但可控制已部署的应用程序，并可能对应用程序托管环境的配置设置有控制权。
Software as a Service (SaaS): The capability provided to the consumer is to use the provider's applications running on a cloud infrastructure. The applications are accessible from various client devices through either a thin client interface, such as a web browser (e.g., email), or a program interface. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.
软件即服务（SaaS）： 向消费者提供的能力是使用提供商在云基础设施上运行的应用程序。这些应用程序可通过各种客户端设备访问，例如通过瘦客户端界面（如网页浏览器，如电子邮件）或程序接口。消费者不管理或控制底层云基础设施（包括网络、服务器、操作系统、存储，甚至单个应用程序功能），可能仅对有限的用户特定应用程序配置设置有控制权。
V. Computer Software Assurance ..................................................................8
V. 计算机软件保障..............................................................................................8
Computer software assurance is a risk-based approach for establishing and maintaining confidence that software is fit for its intended use.
计算机软件保障是一种基于风险的方法，用于建立并维持对软件适用于其预期用途的信心。
This approach considers the risk of compromised safety and/or quality of the device (should the software fail to perform as intended) to determine the level of assurance effort and activities appropriate to establish confidence in the software.
该方法考虑了软件未能按预期运行时可能对器械安全性和/或质量造成的风险，以确定建立软件信心所需的保障工作和活动的适当水平。
Because the computer software assurance effort is risk-based, it follows a least-burdensome approach, where the burden of validation is no more than necessary to address the risk.
由于计算机软件保障工作基于风险，因此遵循最小负担原则，即验证负担不超过应对风险所必需的程度。
Such an approach supports the efficient use of resources, in turn promoting product quality.
这种方法支持资源的高效利用，从而促进产品质量。
In addition, computer software assurance establishes and maintains that the software used in production or the quality system is in a state of control throughout its life cycle ("validated state").
此外，计算机软件保障确保用于生产或质量系统的软件在其整个生命周期内处于受控状态（即“已验证状态”）。
This is important because manufacturers increasingly rely on computers and automated processing systems to monitor and operate production, alert responsible personnel, and transfer and analyze production data, among other uses.
这一点很重要，因为医药厂家越来越依赖计算机和自动化处理系统来监控和操作生产、提醒相关人员、传输和分析生产数据等。
By allowing manufacturers to leverage principles such as risk-based testing, unscripted testing, continuous performance monitoring, and data monitoring, as well as validation activities performed by other entities (e.g., developers, suppliers, cloud service providers), the computer software assurance approach provides flexibility and agility in helping to provide assurance that the software maintains a validated state consistent with applicable quality system obligations.
通过允许制造商利用基于风险的测试、非脚本化测试、持续性能监控和数据监控等原则，以及由其他实体（如开发者、供应商、云服务提供商）执行的验证活动，计算机软件保障方法在确保软件保持与适用质量体系义务一致的验证状态方面提供了灵活性和敏捷性。
Software that is fit for its intended use and that maintains a validated state should perform as intended, helping to ensure that finished devices will be safe and effective and in compliance with regulatory requirements (see 21 CFR 820.1(a)(1)).
适用于其预期用途并保持验证状态的软件应按预期运行，有助于确保成品器械安全有效，并符合法规要求（见21 CFR 820.1(a)(1)）。Section V outlines a risk-based framework for computer software assurance.第V节概述了计算机软件保障的基于风险的框架。
A. Computer Software Assurance Risk Framework ........................................8
A. 计算机软件保障风险框架................................................................................8
The following approach is intended to help manufacturers establish a risk-based framework for computer software assurance throughout the software's life cycle. The approach outlined can be applied, but is not limited, to automation tools (e.g., BOTS or automatic workflows), data analytic tools, artificial intelligence/machine learning tools, and cloud computing when used as part of production or the quality system.
以下方法旨在帮助制造商在软件的整个生命周期内建立基于风险的计算机软件保障框架。所述方法可应用于（但不限于）自动化工具（如机器人或自动工作流）、数据分析工具、人工智能/机器学习工具以及在用于生产或质量系统时的云计算。
Examples of applying this risk framework to various computer software assurance situations are provided in Appendix A.
本附录 A 提供了将该风险框架应用于各种计算机软件保障情境的示例。
(1) Identifying the Intended Use ...................................................................9
(1) 识别预期用途........................................................................................9
The regulation requires manufacturers to validate software that is used as part of production or the quality system for its intended use (see 21CFR 820.70(i)). This includes various cloud computing models related to computerized systems, such as IaaS, PaaS, and SaaS.
法规要求制造商验证用于生产或质量系统的软件是否适用于其预期用途（见21CFR 820.70(i)）。这包括与计算机化系统相关的各种云计算模式，如IaaS、PaaS和SaaS。
To determine whether the requirement for validation applies, manufacturers must determine whether the software is or will be used as part of production or the quality system (whether directly or to support production or the quality system).
为确定是否适用验证要求，制造商必须确定该软件是否正在或将被用于生产或质量系统（无论是直接用于还是支持生产或质量系统）。
Software with the following intended uses is considered to be used directly as part of production or the quality system:
具有以下预期用途的软件被视为直接用于生产或质量系统的一部分：
Software intended for automating production processes, inspection, testing, or the collection and processing of production data; and
用于自动化生产过程、检验、测试或生产数据收集和处理的软件；以及
Software intended for automating quality system processes, collection and processing of quality system data, or maintaining a quality record established under applicable quality system obligations.
用于自动化质量体系过程、质量体系数据收集和处理，或维护根据适用质量体系义务建立的质量记录的软件。
Software with the following intended uses is considered to be used to support production or the quality system:
具有以下预期用途的软件被视为支持生产或质量系统：
Software intended for use as development tools that test or monitor software systems or that automate testing activities for the software used as part of production or the quality system; and
用作开发工具的软件，用于测试或监控系统，或为用于生产或质量系统的软件自动执行测试活动；以及
Software intended for automating general record-keeping for production or the quality system that is not part of the quality record.
用于自动化生产或质量系统的一般记录保存，且该记录不属于质量记录部分的软件。
Both kinds of software are used as part of production or the quality system and must be validated under 21CFR 820.70(i).
上述两类软件均作为生产或质量系统的一部分使用，必须根据21CFR 820.70(i)进行验证。
On the other hand, software with the following intended uses generally is not considered to be used as part of production or the quality system, such that the requirement for validation in 21 CFR 820.70(i) would not apply:
另一方面，具有以下预期用途的软件通常不被视为用于生产或质量系统的一部分，因此不适用21 CFR 820.70(i)中的验证要求：
Software intended for management of general business processes or operations not specific to production or the quality system, such as email or accounting applications; and
用于管理非特定于生产或质量体系的一般业务流程或操作的软件，例如电子邮件或会计应用程序；以及
Software intended for establishing or supporting infrastructure not specific to production or the quality system, such as networking, user authentication, or continuity of operations (e.g., backup and restore).
用于建立或支持非特定于生产或质量体系的基础设施，例如网络、用户身份验证或业务连续性（如备份和恢复）的软件。
FDA recommends manufacturers focus on the intended use of the software when considering cloud computing models, as not all cloud computing models are "directly" used as part of production or the quality system.
FDA建议制造商在考虑云计算模式时，重点关注软件的预期用途，因为并非所有云计算模式都被“直接”用于生产或质量系统。
For example, an IaaS cloud storage solution falls into the category of infrastructure, but may be used to store quality records established under applicable quality system obligations, in which case the IaaS cloud storage solution would be considered to be used directly as part of production or the quality system.
例如，IaaS云存储解决方案属于基础设施类别，但可用于存储根据适用质量体系义务建立的质量记录，在此情况下，IaaS云存储解决方案将被视为直接用于生产或质量系统的一部分。
In this example, FDA recommends manufacturers focus the assurance effort on the features or functions relevant to the integrity of the records and 21 CFR Part 11 requirements applicable to the records intended to be stored.
在此示例中，FDA建议制造商将保障工作重点放在与记录完整性相关的功能或特性上，以及适用于拟存储记录的21 CFR第11部分要求。
Conversely, an IaaS cloud storage solution may support infrastructure to store production and process data; this would not be considered an established quality system record.
相反，IaaS云存储解决方案可能支持用于存储生产和过程数据的基础设施；这不被视为已建立的质量体系记录。
In this example, the IaaS cloud storage solution does not support production or the quality system, and the requirement for validation in 21 CFR 820.70(i) would not apply.
在此示例中，IaaS云存储解决方案不支持生产或质量系统，因此不适用21 CFR 820.70(i)的验证要求。
When storage of data in the cloud is independent of whether or not the data is part of the quality record, it is the manufacturer's obligation to determine what the appropriate level of risk is for that application.
当云中的数据存储与数据是否属于质量记录无关时，制造商有责任确定该应用程序的适当风险水平。
Manufacturers may consider a least-burdensome approach to assuring the IaaS cloud storage solution is adequate for their business.
制造商可考虑采用最小负担的方法来确保IaaS云存储解决方案足以满足其业务需求。
FDA recognizes that software used in production or the quality system is often complex and comprised of multiple features, functions, and operations; software may have one or more intended uses depending on the individual features, functions, and operations of that software.
FDA认识到，用于生产或质量系统的软件通常较为复杂，由多个特性、功能和操作组成；根据软件的具体特性、功能和操作，软件可能具有一个或多个预期用途。
In cases where the individual features, functions, and operations of the software have different roles within production or the quality system, they may present different risks with different levels of validation effort.
在软件的各个特性、功能和操作在生产或质量系统中承担不同角色的情况下，它们可能带来不同的风险，并需要不同程度的验证工作。
FDA recommends that manufacturers examine the intended uses of the individual features, functions, and operations to facilitate development of a risk-based assurance strategy.
FDA建议制造商审查各个特性、功能和操作的预期用途，以促进制定基于风险的保障策略。
Manufacturers may decide to conduct different assurance activities for individual features, functions, or operations as related to the intended use.
制造商可决定针对与预期用途相关的各个特性、功能或操作，开展不同的保障活动。
For example, a commercial off-the-shelf (COTS) spreadsheet software may be comprised of various functions with different intended uses.
例如，一款商用现成（COTS）电子表格软件可能由具有不同预期用途的多种功能组成。
When utilizing the basic input functions of the COTS spreadsheet software for an intended use of documenting the time and temperature readings for a curing process, a manufacturer may not need to perform additional assurance activities beyond those conducted by the COTS software developer and initial installation and configuration.
当将COTS电子表格软件的基本输入功能用于记录固化过程的时间和温度读数时，制造商可能无需开展超出COTS软件开发商已完成的初始安装和配置之外的额外保障活动。
The intended use of the software, "documenting readings," only supports maintaining a record of the process information and poses a low process risk.
该软件的预期用途“记录读数”仅用于维护过程信息的记录，构成较低的过程风险。
As such, initial activities such as the successful vendor assessment and software installation and configuration may be sufficient to establish that the software is fit for its intended use and maintains a validated state.
因此，成功的供应商评估以及软件的安装和配置等初始活动，可能足以确立软件适用于其预期用途并保持验证状态。
However, if a manufacturer also utilizes built-in functions of the COTS spreadsheet to create custom formulas that are directly used in production or the quality system, then additional risks and data integrity considerations may be present.
然而，如果制造商还利用COTS电子表格的内置功能创建直接用于生产或质量系统的自定义公式，则可能存在额外的风险和数据完整性考虑。
For example, if a custom formula automatically calculates time and temperature statistics to monitor the performance and suitability of the curing process, then additional validation by the manufacturer might be necessary.
例如，如果某个自定义公式自动计算时间和温度统计数据以监控固化过程的性能和适用性，则可能需要制造商进行额外的验证。
For the purposes of this guidance, we describe and recommend a computer software assurance framework where manufacturers examine the intended uses of the individual features, functions, or operations of the software.
就本指南而言，我们描述并推荐一种计算机软件保障框架，制造商在该框架下审查软件的各个特性、功能或操作的预期用途。
However, in simple cases where software has only one intended use (e.g., if all of the features, functions, and operations within the software share the same intended use), manufacturers may not find it helpful to examine each feature, function, and operation individually.
然而，在软件仅有一个预期用途的简单情况下（例如，软件内的所有特性、功能和操作共享相同的预期用途），制造商可能认为逐一审查每个特性、功能和操作并无帮助。
In such cases, manufacturers may develop a risk-based approach and consider assurance activities based on the intended use of the software overall.
在此类情况下，制造商可制定基于风险的方法，并基于软件整体的预期用途考虑保障活动。
FDA recommends that manufacturers document their decision-making process for determining whether a software feature, function, or operation is or will be used as part of production or the quality system through their quality management system.
FDA建议制造商通过其质量管理体系，记录其确定某个软件特性、功能或操作是否正在或将被用于生产或质量系统的决策过程。
(2) Determining the Risk-Based Approach ..................................................11
(2) 确定基于风险的方法......................................................................11
Once a manufacturer has determined that a software feature, function, or operation is or will be used as part of production or the quality system, FDA recommends using a risk-based analysis to determine appropriate assurance activities.
一旦制造商确定某个软件特性、功能或操作正在或将被用于生产或质量系统，FDA建议采用基于风险的分析来确定适当的保障活动。
Broadly, this risk-based approach entails systematically identifying reasonably foreseeable software failures, determining whether such a failure poses a high process risk, and systematically selecting and performing assurance activities commensurate with the medical device or process risk, as applicable.
总体而言，这种基于风险的方法包括：系统地识别合理可预见的软件故障，确定此类故障是否构成高过程风险，并系统地选择和执行与医疗器械或过程风险相称的保障活动。
Manufacturers should select an appropriate frequency for performing assurance activities based on their risk-based analysis and accounting for their processes and procedures, as appropriate for the software and assurance activities being performed.
制造商应根据其基于风险的分析，并结合其过程和程序，为所执行的软件和保障活动选择适当的执行频率。
Note that conducting a risk-based analysis for computer software assurance for production or quality system software, as described in this guidance, is distinct from performing a risk analysis for a medical device as described in ISO 14971:2019.
请注意，本指南所述的针对生产或质量系统软件的计算机软件保障的风险分析，不同于ISO 14971:2019中描述的医疗器械风险分析。
The risk-based analysis for production or quality system software focuses on
那些可能影响或阻止软件按预期运行的因素，如系统配置和管理、系统安全性、数据完整性、数据存储、数据传输或操作错误。
生产或质量系统软件的基于风险的分析聚焦于可能影响或阻止软件按预期运行的因素，例如系统配置与管理、系统安全性、数据完整性、数据存储、数据传输或操作错误。
A risk-based analysis for production or quality system software should consider which failures are reasonably foreseeable (as opposed to likely) and the risks resulting from each such failure.
对生产或质量系统软件的基于风险的分析应考虑哪些故障是合理可预见的（而非可能发生），以及每种故障所带来的风险。
For example, in a risk-based analysis a manufacturer may consider the risks resulting from a power outage, which may not be likely to occur but is reasonably foreseeable to occur over the life cycle of a production or quality system.
例如，在基于风险的分析中，制造商可考虑停电带来的风险，停电可能不太可能发生，但在生产或质量系统的生命周期内是合理可预见的。
This guidance discusses both process risks and medical device risks. A process risk refers to the potential to compromise production or the quality system. A medical device risk refers to the potential for a device to harm the patient or user.
本指南讨论了过程风险和医疗器械风险。过程风险指对生产或质量系统造成损害的潜在可能性。医疗器械风险指器械对患者或用户造成伤害的潜在可能性。
When discussing medical device risks, this guidance focuses on the medical device risk resulting from a quality problem that compromises safety.
在讨论医疗器械风险时，本指南聚焦于因质量问题导致安全性受损而产生的医疗器械风险。
Specifically, FDA considers a software feature, function, or operation to pose a high process risk when its failure to perform as intended may result in a quality problem that foreseeably compromises safety, meaning a medical device risk.
具体而言，当某个软件特性、功能或操作未能按预期运行可能导致质量问题，从而可预见地损害安全性（即医疗器械风险）时，FDA认为其构成高过程风险。
This process risk identification step focuses only on the process, as opposed to the medical device risk posed to the patient or user.
此过程风险识别步骤仅聚焦于过程本身，而非对患者或用户构成的医疗器械风险。
Examples of software features, functions, or operations that are generally high process risk are those that:
通常属于高过程风险的软件特性、功能或操作包括：
Maintain process parameters (e.g., temperature, pressure, or humidity) that affect the physical properties of product or manufacturing processes identified as essential to device safety;
维护影响产品物理特性或制造过程的过程参数（如温度、压力或湿度），且这些参数被确定为对器械安全至关重要；
Measure, inspect, analyze and/or determine acceptability of product or process with limited or no additional human awareness or review;
在几乎或完全无需人工意识或审查的情况下，测量、检验、分析和/或确定产品或过程的可接受性；
Perform process corrections or adjustments of process parameters based on data monitoring or automated feedback from other process steps without additional human awareness or review;
在几乎或完全无需人工意识或审查的情况下，根据数据监控或其他过程步骤的自动反馈执行过程纠正或对过程参数进行调整；
Produce instructions for use or other labeling provided to patients and users that are necessary for safe operation of the medical device; and/or
生成提供给患者和用户的使用说明或其他标签，这些对于医疗器械的安全操作是必需的；和/或
Automate surveillance, trending, or tracking of data that the manufacturer identifies as essential to device safety (e.g., cybersecurity).
自动化监控、趋势分析或跟踪制造商确定为对器械安全至关重要的数据（如网络安全）。
In contrast, FDA considers a software feature, function, or operation not to pose a high process risk when its failure to perform as intended would not result in a quality problem that foreseeably compromises safety.
相反，当某个软件特性、功能或操作未能按预期运行不会导致可预见地损害安全性的质量问题，FDA认为其不构成高过程风险。
This includes situations where failure to perform as intended would not result in a quality problem, as well as situations where failure may result in a quality problem that does not foreseeably lead to compromised safety.
这包括未能按预期运行不会导致质量问题的情况，以及可能导致质量问题但不会可预见地导致安全性受损的情况。
Examples of software features, functions, or operations that generally are not high process risk include those that:
通常不属于高过程风险的软件特性、功能或操作包括：
Collect and record data from the process for monitoring and review purposes that do not have a direct impact on production or process performance;
为监控和审查目的收集和记录过程数据，且对生产或过程性能无直接影响；
Are used as part of the quality system for Corrective and Preventive Actions (CAPA) routing, automated logging/tracking of complaints, automated change control management, or automated procedure management;
用作质量体系的一部分，用于纠正和预防措施（CAPA）流转、投诉的自动记录/跟踪、自动变更控制管理或自动程序管理；
Are intended to manage data (process, store, and/or organize data), automate an existing calculation, increase process monitoring, or provide alerts relevant to managing data when an exception occurs in an established process; and/or
旨在管理数据（处理、存储和/或组织数据）、自动化现有计算、增强过程监控或在已建立过程中发生异常时提供与数据管理相关的警报；和/或
Are used to support production or the quality system, as explained in Section V.A.1.
如第V.A.1节所述，用于支持生产或质量系统。
FDA acknowledges that process risks associated with software used as part of production or the quality system are on a spectrum, ranging from high process risk to low process risk.
FDA承认，用于生产或质量系统的软件相关过程风险处于一个范围内，从高过程风险到低过程风险。
Manufacturers should determine the risk of each software feature, function, or operation as the risk falls on that spectrum, depending on the intended use of the software.
制造商应根据软件的预期用途，确定每个软件特性、功能或操作在该风险范围内的风险水平。
FDA is primarily concerned with the review and assurance for those software features, functions, and operations that are high process risk because a failure also poses a medical device risk.
FDA主要关注对那些构成高过程风险的软件特性、功能和操作的审查和保障，因为其故障也会构成医疗器械风险。
For the purposes of this guidance, FDA presents the process risks in a binary manner, "high process risk" and "not high process risk."
就本指南而言，FDA以二元方式呈现过程风险，即“高过程风险”和“非高过程风险”。
A manufacturer may still determine that a process risk is, for example, "moderate," "intermediate," or even "low" for purposes of determining assurance activities; in such a case, the portions of this guidance concerning "not high process risk" would apply.
制造商仍可判定某一过程风险为“中等”、“中等偏低”或甚至“低”，以用于确定保障活动；在此情况下，本指南中关于“非高过程风险”的部分将适用。
As discussed in Section V.A.4 below, assurance activities should be conducted for software that is "high process risk" commensurate with the medical device risk and "not high process risk" commensurate with the process risk.
如下文第V.A.4节所述，对“高过程风险”软件应开展与其医疗器械风险相称的保障活动，对“非高过程风险”软件应开展与其过程风险相称的保障活动。
Example: An Enterprise Resource Planning (ERP) Management system contains a feature that automates manufacturing material restocking.示例：某企业资源计划（ERP）管理系统中有一项功能，可自动进行生产物料补货。
This feature automates material ordering and delivery to appropriate production operations.
该功能可自动将物料订购并交付至相应的生产环节。
However, a qualified person checks the materials before their use in production.
然而，在生产使用前，会有合格人员对物料进行检查。
The failure of this feature to perform as intended may result in a mix-up in restocking and delivery, which would be a quality problem because the wrong materials would be restocked and delivered.
如果该功能未按预期运行，可能导致补货和交付错误，从而引发质量问题，因为错误的物料将被补货和交付。
However, the delivery of the wrong materials to the qualified person should result in the rejection of those materials before use in production; as such, the quality problem should not foreseeably lead to compromised safety.
然而，错误物料交付给合格人员后，应在使用前被拒绝，因此该质量问题不会可预见地导致安全性受损。
The manufacturer identifies this as an intermediate (not high) process risk and determines assurance activities commensurate with the process risk.
制造商将其识别为中等（非高）过程风险，并确定与过程风险相称的保障活动。
The manufacturer has performed an evaluation of the ERP vendor, the ERP system information, and has configured the ERP system for its operations.
制造商已评估ERP供应商、ERP系统信息，并为其运营配置了ERP系统。
The manufacturer implements any remaining assurance activities associated with the material order and delivery automation.
制造商实施了与物料订购和交付自动化相关的剩余保障活动。
Example: A similar feature in another ERP management system performs the same tasks as in the previous example except that it also automates checking the materials before their use in production.
示例：另一ERP管理系统中的类似功能执行与前述相同的任务，此外还可在生产使用前自动检查物料。
A qualified person does not check the material first.
合格人员不再先行检查物料。
The manufacturer identifies this as a high process risk because the failure of the feature to perform as intended may result in a quality problem that foreseeably compromises safety.
制造商将其识别为高过程风险，因为该功能未按预期运行可能导致质量问题，从而可预见地损害安全性。
As such, the manufacturer will determine assurance activities that are commensurate with the related medical device risk.
因此，制造商将确定与相关医疗器械风险相称的保障活动。
The manufacturer has previously performed assurance activities on the material identification data system, the automated material scanning systems (barcode scanners), evaluated the ERP vendor/information, and has configured the ERP system for their operations.
制造商此前已对物料识别数据系统、自动化物料扫描系统（条码扫描器）执行保障活动，评估了ERP供应商/信息，并为其运营配置了ERP系统。
The manufacturer implements any remaining assurance activities associated with the ordering and delivery automation.
制造商实施了与订购和交付自动化相关的剩余保障活动。
Example: An ERP management system contains a feature to automate product delivery.
示例：某ERP管理系统中有一项功能，可自动进行产品交付。
The medical device risk depends upon, among other factors, the correct product being delivered to the device user.
医疗器械风险取决于多个因素，其中包括是否将正确的产品交付给器械用户。
A failure of this feature to perform as intended may result in a delivery mix-up, which would be a quality problem that foreseeably compromises safety; as such, the manufacturer identifies this as a high process risk.
如果该功能未按预期运行，可能导致交付错误，这将是一个可预见地损害安全性的质量问题；因此，制造商将其识别为高过程风险。
Since the failure would compromise safety, the manufacturer will next determine the related increase in medical device risk and identify the assurance activities that are commensurate with the medical device risk.
由于该故障将损害安全性，制造商接下来将确定相关医疗器械风险的增加，并识别与医疗器械风险相称的保障活动。
In this case, the manufacturer has not already implemented any of the identified assurance activities, so the manufacturer implements all of the assurance activities identified in the analysis.
在此情况下，制造商尚未实施任何已识别的保障活动，因此其实施了分析中识别的所有保障活动。
Example: An automated graphical user interface (GUI) function in the production software is used for developing test scripts based on user interactions and to automate future testing of modifications to the user interface of a system used in production.
示例：生产软件中的自动化图形用户界面（GUI）功能用于基于用户交互开发测试脚本，并自动化未来对生产系统用户界面修改的测试。
A failure of this GUI function to perform as intended may result in implementation disruptions and software updates to the production system being delayed, but in this case, these errors should not foreseeably lead to compromised safety because the GUI function operates in a separate test environment.
如果该GUI功能未按预期运行，可能导致实施中断和生产系统软件更新延迟，但在此情况下，这些错误不会可预见地导致安全性受损，因为GUI功能在独立的测试环境中运行。
The manufacturer identifies this as a low (not high) process risk and determines assurance activities that are commensurate with the process risk.
制造商将其识别为低（非高）过程风险，并确定与过程风险相称的保障活动。
The manufacturer already undertakes some of those identified assurance activities so implements the remaining identified assurance activities.
制造商已执行部分已识别的保障活动，因此其实施了剩余已识别的保障活动。
(3) Production or Quality System Software Changes ................................14
(3) 生产或质量体系软件变更......................................................14
For devices with approved premarket approval applications (PMA) or humanitarian device exemptions (HDE), PMA/HDE supplements are not required for changes to the manufacturing procedure or method of manufacturing that do not affect the safety or effectiveness of the device if they are reported to FDA in a periodic report (usually referred to as an annual report).
对于已获得上市前批准申请（PMA）或人道主义器械豁免（HDE）的器械，如制造程序或制造方法的变更不影响器械的安全性或有效性，且已在定期报告（通常称为年度报告）中向FDA报告，则无需提交PMA/HDE补充申请。
PMA/HDE supplements also are not required for modifications to manufacturing procedures or methods of manufacture that affect the safety and effectiveness of the device; these are submitted in a 30-day notice.
对于影响器械安全性和有效性的制造程序或制造方法的修改，也无需提交PMA/HDE补充申请；这些变更以30天通知的形式提交。
Changes to the manufacturing procedure or method of manufacturing may include changes to software used in production or the quality system.
制造程序或制造方法的变更可能包括用于生产或质量系统的软件的变更。
For an addition or change to software used in production or the quality system of devices with approved PMAs or HDEs, FDA recommends that manufacturers apply the principles outlined above in Section V.A.2 in determining whether the change may affect the safety or effectiveness of the device.
对于已获得批准的PMA或HDE的器械，其用于生产或质量系统的软件的增加或变更，FDA建议制造商在确定该变更是否可能影响器械的安全性或有效性时，应用上文第V.A.2节所述的原则。
In general, if a change may result in a quality problem that foreseeably compromises safety, then it should be submitted in a 30-day notice.
一般而言，如果某一变更可能导致可预见地损害安全性的质量问题，则应以30天通知的形式提交。
If a change would not result in a quality problem that foreseeably compromises safety, then the change may be appropriate to report in an annual report.
如果某一变更不会导致可预见地损害安全性的质量问题，则该变更可在年度报告中报告。
For example, a Manufacturing Execution System (MES) may be used to manage workflow, track progress, record data, and establish alerts or thresholds based on validated parameters, which are part of maintaining the quality system.
例如，制造执行系统（MES）可用于管理工作流、跟踪进度、记录数据，并基于已验证的参数建立警报或阈值，这些是维护质量体系的一部分。
Failure of such an MES to perform as intended may disrupt operations but not affect the process parameters established to produce a safe and effective device.
此类MES未能按预期运行可能会扰乱操作，但不会影响为生产安全有效器械而建立的过程参数。
Changes affecting these MES operations are generally submitted in annual reports.
影响这些MES操作的变更通常在年度报告中提交。
In contrast, an MES used to automatically control and adjust established critical production parameters (e.g., temperature, pressure, process time) may be a change to a manufacturing procedure that affects the safety or effectiveness of the device.
相反，用于自动控制和调整已建立的关键生产参数（如温度、压力、过程时间）的MES可能是影响器械安全性或有效性的制造程序的变更。If so, changes affecting
this specific operation would be submitted in a 30-day notice.
如是，影响此特定操作的变更应以30天通知的形式提交。
(4) Determining the Appropriate Assurance Activities ...............................14
(4) 确定适当的保障活动....................................................14
Once the manufacturer has determined whether a software feature, function, or operation poses a high process risk (a quality problem that may foreseeably compromise safety), the manufacturer should identify the assurance activities commensurate with the medical device risk or the process risk.
一旦制造商确定某一软件特性、功能或操作是否构成高过程风险（即可能导致可预见地损害安全性的质量问题），制造商应识别与其医疗器械风险或过程风险相称的保障活动。
In cases where the quality problem may foreseeably compromise safety (high process risk), the level of assurance should be commensurate with the medical device risk.
在质量问题可能可预见地损害安全性（高过程风险）的情况下，保障水平应与其医疗器械风险相称。
In cases where the quality problem may not foreseeably compromise safety (not high process risk), the level of assurance rigor should be commensurate with the process risk.
在质量问题不会可预见地损害安全性（非高过程风险）的情况下，保障严谨程度应与其过程风险相称。
In either case, heightened risks of software features, functions, or operations generally entail greater rigor for assurance efforts (i.e., a greater amount of objective evidence).
无论哪种情况，软件特性、功能或操作的风险越高，通常意味着保障工作需要更高的严谨性（即更多的客观证据）。
Conversely, relatively low risk (i.e., not high process risk) of compromised safety and/or quality generally entails less collection of objective evidence for the computer software assurance effort.
相反，相对较低的风险（即非高过程风险）对安全性和/或质量的损害通常意味着计算机软件保障工作所需收集的客观证据较少。
A software feature, function, or operation that could lead to severe harm to a patient or user would generally be high medical device risk.
可能导致患者或用户严重伤害的软件特性、功能或操作通常属于高医疗器械风险。
In contrast, a feature, function, or operation that would not foreseeably lead to severe harm would likely not be high medical device risk.
相反，不会可预见地导致严重伤害的特性、功能或操作可能不属于高医疗器械风险。
In either case, the risk of the software's failure to perform as intended is commensurate with the resulting medical device risk.
无论哪种情况，软件未能按预期运行的风险与其导致的医疗器械风险相称。
If the manufacturer determined that the software feature, function, or operation does not pose a high process risk (i.e., it would not lead to a quality problem that foreseeably compromises safety), the manufacturer should consider the risk relative to the process (i.e., production or the quality system).
如果制造商确定该软件特性、功能或操作不构成高过程风险（即不会导致可预见地损害安全性的质量问题），制造商应考虑其与过程（即生产或质量体系）相关的风险。
This is because the failure would not compromise safety, so the failure would not introduce additional medical device risk.
这是因为故障不会损害安全性，因此不会引入额外的医疗器械风险。
For example, a function that collects and records process data for review would pose a lower process risk than a function that determines acceptability of product prior to human review.
例如，与在人工审查前确定产品可接受性的功能相比，收集和记录过程数据以供审查的功能所构成的过程风险较低。
Types of manual or automated testing that may be considered as part of the assurance activities commonly performed by manufacturers include, but are not limited to, the following:
制造商通常可考虑的保障活动中的手动或自动测试类型包括但不限于以下内容：
Unscripted testing: Dynamic testing in which the tester's actions are not prescribed by written instructions in a test case.
非脚本化测试： 测试人员的行为不受测试用例中书面指令规定的动态测试。
Scenario Testing (Also referred to as Ad-Hoc Testing): A specification-based test case design technique based on exercising sequences of interactions between the test item and other systems.
场景测试（也称为临时测试）： 一种基于规范的测试用例设计技术，基于测试项与其他系统之间的交互序列进行测试。
Experience-based testing: Class of test case design techniques based on using the experience of testers to generate test cases.
基于经验的测试： 基于测试人员经验生成测试用例的测试用例设计技术类别。
Error guessing: A test design technique in which test cases are derived on the basis of the tester's knowledge of past failures or general knowledge of failure modes.
错误猜测： 基于测试人员对过去故障的了解或对故障模式的通用知识来推导测试用例的测试设计技术。
Exploratory testing: Experience-based testing in which the tester spontaneously designs and executes tests based on the tester's existing relevant knowledge, prior exploration of the test item, and heuristic "rules of thumb" regarding common software behaviors and types of failure.
探索性测试： 基于经验的测试，测试人员基于现有相关知识、对测试项的先前探索以及关于常见软件行为和故障类型的启发式“经验法则”自发地设计和执行测试。
Scripted testing: Testing in which test cases are recorded and can then be executed manually or automatically using an automated testing tool.
脚本化测试： 测试用例被记录下来的测试，可手动执行，也可使用自动化测试工具自动执行。
This guidance describes a risk-based approach manufacturers may consider in meeting regulatory requirements.
本指南描述了一种基于风险的方法，制造商可考虑将其用于满足法规要求。
It is not an exhaustive list of software testing methods and principles.
它并非软件测试方法和原则的详尽清单。
FDA recognizes that there are software testing methods and approaches, beyond those referenced.
FDA 认识到，除本指南引用内容外，还存在其他软件测试方法和途径。
For example, the "Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submission" guidance, which is applicable to devices with cybersecurity considerations and describes recommendations regarding the cybersecurity information to be submitted for devices under certain premarket submission types, includes recommendations for cybersecurity testing used to demonstrate the effectiveness of design controls.
例如，《医疗器械网络安全：质量体系考量及上市前提交资料内容》指南适用于涉及网络安全考虑的器械，并说明了针对某些上市前提交类型所需网络安全信息的建议，其中包括用于证明设计控制有效性的网络安全测试建议。
Manufacturers may consider utilizing the cybersecurity testing methods described in that guidance when conducting the assurance activities described in this guidance, as appropriate.
制造商在开展本指南所述保障活动时，可酌情考虑使用该指南中描述的网络安全测试方法。
In general, FDA recommends that manufacturers apply principles of risk-based testing in which the management, selection, prioritization, and use of testing activities and resources are consciously based on corresponding types and levels of analyzed risk to determine the appropriate activities.
总体而言，FDA 建议制造商采用基于风险的测试原则，即对测试活动及资源的管理、选择、优先级排序和使用，应有意识地依据所分析风险的类型和级别，来确定适当的活动。
For high process risk software features, functions, and operations, manufacturers may choose to consider more rigor such as the use of scripted testing or a hybrid approach of scripted testing and unscripted testing, scaled as appropriate, when determining their assurance activities.
对于高过程风险的软件特性、功能及操作，制造商在确定保障活动时，可选择采用更严谨的方法，例如使用脚本化测试，或脚本化测试与非脚本化测试相结合的混合方法，并根据需要调整规模。
In contrast, for software features, functions, and operations that are not high process risk, manufacturers may consider using unscripted testing methods such as scenario testing, error-guessing, exploratory testing, or a combination of methods that is suitable for the risk.
相反，对于非高过程风险的软件特性、功能及操作，制造商可考虑使用非脚本化测试方法，如场景测试、错误猜测、探索性测试，或结合使用适合该风险水平的多种方法。
The testing examples discussed for high process risk and not high process risk are not exclusive to those categories.
针对高过程风险与非高过程风险所讨论的测试示例，并非仅适用于这些类别。
Manufacturers should apply the principles of risk-based testing to determine the appropriate type of testing to perform.
制造商应运用基于风险的测试原则，来确定应执行的具体测试类型。
For example, unscripted testing may be better suited to assure the software performs as intended even for high process risk features, functions, and operations.
例如，非脚本化测试可能更适合确保软件按预期运行，即便对于高过程风险的特性、功能和操作也是如此。
Conversely, a manufacturer may find it more effective and efficient to develop scripted testing and automate it for not high process risk features, functions, and operations.
反之，制造商可能会发现，为非高过程风险的特性、功能和操作开发脚本化测试并实现自动化，更为有效和高效。
(5) Additional Considerations for Assurance Activities ..............................17
(5) 保障活动的其他考虑因素..................................................17
When deciding on the appropriate assurance activities, manufacturers should consider whether there are any additional controls or mechanisms in place throughout the quality system that may decrease the impact of compromised safety and/or quality if failure of the software feature, function, or operation were to occur.
在确定适当的保障活动时，制造商应考虑质量体系中是否已建立其他控制或机制，以在软件特性、功能或操作发生故障时降低对安全性和/或质量的影响。
For example, as part of a comprehensive assurance approach, manufacturers can leverage the following to reduce the effort of additional assurance activities:
例如，作为全面保障方法的一部分，制造商可利用以下方式减少额外保障活动的工作量：
Activities and established processes that provide control in production or fully verify processes in which software is involved.
在生产中提供控制或完全验证涉及软件的过程的已建立活动和过程。
Established purchasing control processes for selecting and monitoring software vendors.
用于选择和监控软件供应商的已建立采购控制过程。
Additional process controls, including activities to reduce cybersecurity exposure, that have been incorporated throughout production.
已纳入整个生产过程中的额外过程控制，包括降低网络安全风险的活动。
The data and information periodically or continuously collected by the software for the purposes of monitoring or detecting issues and anomalies in the software after implementation.
软件在实施后定期或持续收集的用于监控或检测软件中问题和异常的数据和信息。
The use of tools supporting software development and system life cycle activities (e.g., bug, anomaly tracking, requirement traceability tools) for the assurance of software used in production or as part of the quality system whenever possible.
在可能的情况下，使用支持软件开发和系统生命周期活动的工具（如缺陷、异常跟踪、需求可追溯性工具）来保障用于生产或作为质量系统一部分的软件。
The use of testing and results done in iterative cycles and continuously throughout the life cycle of the software used in production or as part of the quality system.
在用于生产或作为质量系统一部分的软件的生命周期内，以迭代周期持续进行测试并使用测试结果。
FDA recognizes that manufacturers may have limited access to information from the software vendor as part of an assessment and recommends manufacturers establish and apply a risk-based analysis of the software vendor as part of their assurance approach.
FDA认识到，制造商在评估过程中可能无法获得软件供应商的全部信息，建议制造商建立并应用对软件供应商的基于风险的分析，作为其保障方法的一部分。
The manufacturer's assessment may consider various sources of information when deciding the appropriate level of control for the software vendor (e.g., purchasing controls).
制造商在确定对软件供应商的适当控制水平时，其评估可考虑多种信息来源（如采购控制）。
To evaluate the vendor's capabilities, whether cloud-based, on premise, or a hybrid, the manufacturer may consider activities including but not limited to:
为评估供应商的能力，无论是基于云、本地部署还是混合模式，制造商可考虑开展包括但不限于以下活动：
Onsite audits of the vendor, if applicable. FDA acknowledges that it may not be feasible or appropriate for a device manufacturer to audit the software vendor. Manufacturers may consider any alternative combination of information, as applicable, in a risk-based analysis of the controls and capabilities of the software vendor;
如适用，可对供应商进行现场审计。FDA 认可，对于器械制造商而言，对软件供应商进行审计可能并不可行或不合适。制造商可在对软件供应商控制措施和能力进行基于风险的分析时，酌情考虑任何其他信息组合方式；
Review of the vendor's accreditations and certifications (e.g., Service Organization Controls reports), and industry standard certifications (e.g., ISO certifications);
审查供应商的认可和认证（例如服务组织控制报告）以及行业标准认证（例如 ISO 认证）；
Review of the vendor's practices and documentation for software development, software quality assurance, cybersecurity (e.g., security risk assessments, threat modeling, security design reviews, software bill of materials (SBOM), and testing) and risk mitigation; and
审查供应商在软件开发、软件质量保证、网络安全（例如安全风险评估、威胁建模、安全设计评审、软件物料清单（SBOM）和测试）以及风险缓解方面的实践和文件；以及
Review of the vendor's or software's data integrity capabilities or controls such as, but not limited to:
审查供应商或软件的数据完整性能力或控制措施，包括但不限于：
Retaining records, archiving data, and generating accurate and complete copies of records;
保留记录、归档数据以及生成准确完整的记录副本；
Securing data at rest and in transit (i.e., maintaining secure, computer-generated, time-stamped audit trails of users' actions and changes to data, encrypting data); and/or
保护静态和传输中的数据（即维护安全、计算机生成、带时间戳的用户操作和数据更改审计跟踪，加密数据）；和/或
Establishing and maintaining access controls, electronic signature controls and authorization checks for users' actions.
建立和维护用户操作的访问控制、电子签名控制以及授权检查。
A manufacturer should establish and maintain within its procedures the requirements it has for suppliers on the basis of their ability to meet specified requirements and define the type and extent of control to be exercised over the product, services, and suppliers.
制造商应在其程序中建立并维护对供应商的要求，这些要求应基于供应商满足规定要求的能力，并明确对产品、服务和供应商所实施控制的类型和程度。
Manufacturers should consider appropriate sources of information regarding the vendor in their evaluation decision.
制造商在评估决策中应考虑有关供应商的适当信息来源。
FDA recommends that manufacturers establish a risk-based approach to the evaluation of the vendor of software or service, the evaluation activities, and the appropriate objective evidence to retain.
FDA 建议制造商建立基于风险的方法，用于评估软件或服务供应商、评估活动以及应保留的适当客观证据。
For example, supporting software, as referenced in Section V.A.1, often carries lower risk, such that the assurance effort may generally be reduced accordingly.
例如，第 V.A.1 节所述的支持软件通常风险较低，因此其保障工作量可相应减少。
Because assurance activities used "directly" in production or the quality system often inherently cover the performance of supporting software, assurance that this supporting software performs as intended may be sufficiently established by leveraging vendor evaluation and validation records, software installation, or software configuration, such that additional assurance activities (e.g., scripted or unscripted testing) may be unnecessary.
由于“直接”用于生产或质量系统的保障活动通常已涵盖支持软件的性能，因此通过利用供应商评估和验证记录、软件安装或配置，足以确立支持软件按预期运行的保障，无需开展额外保障活动（如脚本化或非脚本化测试）。
Example: A CAPA automation system is being written in Java script and a debugger tool is used to set up breakpoints and step through the code. Once the code is debugged, all the debugger content is removed prior to implementation.
示例：某 CAPA 自动化系统使用 JavaScript 编写，调试工具用于设置断点并逐步执行代码。代码调试完成后，所有调试内容在实施前均被移除。
In this situation, the debugger tool is used to assist a software developer during the coding of a quality system but is not subject to quality system obligations because the COTS tool, which is not integrated with production or the quality system, is not used as part of production or the quality system.
在此情况下，调试工具用于在质量体系编码过程中协助软件开发人员，但由于该商用现成（COTS）工具未与生产或质量体系集成，也不作为生产或质量体系的一部分使用，因此不受质量体系义务约束。
FDA recommends manufacturers establish a least-burdensome approach to ensure the tool performs as intended.
FDA 建议制造商建立最小负担方法，以确保该工具按预期运行。
(6) Establishing the Appropriate Record .................................................19
(6) 建立适当的记录..........................................................................19
When establishing the record, the manufacturer should capture sufficient objective evidence to demonstrate that the software feature, function, or operation was assessed and performs as intended.
在建立记录时，制造商应收集足够的客观证据，以证明该软件特性、功能或操作已得到评估，并按预期运行。
In general, FDA recommends the record include the following:
一般而言，FDA建议记录应包括以下内容：
The intended use of the software feature, function, or operation;
该软件特性、功能或操作的预期用途；
The result of the risk-based analysis of the software feature, function, or operation; and
对该软件特性、功能或操作的基于风险的分析结果；以及
Documentation of the assurance activities conducted, including:
所开展保障活动的文件，包括：
A description of the testing conducted based on the assurance activity.
基于保障活动所开展测试的描述。
Issues found during testing (e.g., deviations, defects, and/or failures).
测试过程中发现的问题（如偏差、缺陷和/或故障）。
A conclusion statement declaring acceptability of the software for its intended use.
声明该软件适用于其预期用途的结论性说明。
If issues were found, FDA recommends including resolution of issues found as part of the conclusion statement.
如发现问题，FDA建议在结论性说明中包括对所发现问题的解决方案。
Record of who performed testing/assessment and date the testing/assessment was performed.
测试/评估执行人员及测试/评估日期的记录。
Established review and approval when appropriate (e.g., when necessary, a signature and date of an individual with signatory authority).
在适当时建立审查和批准（例如，必要时由有签字权的人员签字并注明日期）。
Documentation of assurance activities need not include more evidence than necessary to show that the software feature, function, or operation performs as intended for the risk identified.
保障活动的文件无需包含超出证明该软件特性、功能或操作按预期运行所必需的证据。
FDA recommends the record retain sufficient details of the assurance activity to serve as a baseline for improvements or as a reference point if issues occur.
FDA建议记录应保留保障活动的足够细节，以作为改进的基线或出现问题时的参考点。
Advances in digital technology may allow for manufacturers to leverage digital retention of results, automated traceability, automated testing, and electronic capture of work performed as objective evidence.
数字技术的进步可能使制造商能够利用结果的数字化保留、自动化可追溯性、自动化测试以及对所执行工作的电子捕获作为客观证据。
As a least-burdensome approach, FDA recommends incorporating the use of digital records, such as system logs, audit trails, and other data generated and maintained by the software, as opposed to paper documentation, screenshots, or duplicating results already digitally retained by the software when establishing the record associated with the assurance activities.
作为最小负担方法，FDA建议在建立与保障活动相关的记录时，使用数字记录，如系统日志、审计跟踪以及软件生成和维护的其他数据，而非纸质文件、屏幕截图或重复软件已数字保留的结果。
When using digital records, FDA recommends manufacturers consider the intended use and the need for accuracy, reliability, integrity, availability, and authenticity of the record as part of the risk-based assurance approach.
在使用数字记录时，FDA建议制造商考虑记录的预期用途以及对记录的准确性、可靠性、完整性、可用性和真实性的需求，作为基于风险的保障方法的一部分。
Table 1 provides some examples of ways to implement and develop the record when using the risk-based testing approaches, including testing approaches identified in Section V.A.4 above.
表1提供了在使用基于风险的测试方法（包括上文第V.A.4节所述测试方法）时，如何实施和形成记录的一些示例。
Manufacturers may use alternative approaches and provide different documentation so long as their approach satisfies applicable legal documentation requirements.
制造商可采用其他方法并提供不同文件，只要其方法满足适用法规文件要求即可。
Table 1 – Examples of Assurance Activities and Records
表1 – 保障活动与记录示例
|
Assurance Activity 保障活动 |
Test Plan 测试计划 |
Test Results 测试结果 |
Record (Including Digital) 记录（含数字记录） |
|
Scripted Testing: Robust 脚本化测试：稳健型 |
• Test objectives 测试目标 |
• Result record obtained for each test case 所获结果记录覆盖每个用例 |
• Intended use 预期用途 |
|
• Test cases (step-by-step procedure) 测试用例（分步程序） |
• Details regarding any failures/deviations found 任何失效/偏差的详情 |
• Result of risk-based analysis 基于风险的分析结果 |
|
• Expected results 预期结果 |
• Result for each test case 每个用例的结果 |
• Detailed report of testing performed 所执行测试的详细报告 |
|
|
• Issues found 发现的问题 |
|
|
|
• Conclusion declaring acceptability of the software for its intended use, including the resolution or appropriate risk justification of issues found 声明软件适用于预期用途的结论，包括对发现问题的处理或适当风险论证 |
|
|
|
• Record of who performed testing and the date the testing was performed 测试执行人及日期记录 |
|
|
|
• Established review and approval when appropriate 适当时的评审与批准记录 |
|
|
|
Independent review and approval of test plan when appropriate 适当时对测试计划的独立评审与批准 |
|
|
|
Assurance Activity 保障活动 |
Test Plan 测试计划 |
Test Results 测试结果 |
Record (Including Digital) 记录（含数字记录） |
|
Scripted Testing: Limited 脚本化测试：有限型 |
• Limited test cases (step-by-step procedure) identified 限定数量的测试用例（分步程序） |
• Result record obtained for each test case 所获结果记录覆盖每个用例 |
• Intended use 预期用途 |
|
• Expected results 预期结果 |
• Details regarding any failures/deviations found 任何失效/偏差的详情 |
• Result of risk-based analysis 基于风险的分析结果 |
|
|
• Result for each test case 每个用例的结果 |
• Summary description of testing performed 所执行测试的概要描述 |
|
|
• Issues found 发现的问题 |
|
|
|
• Conclusion declaring acceptability of the software for its intended use, including the resolution or appropriate risk justification of issues found 声明软件适用于预期用途的结论，包括对发现问题的处理或适当风险论证 |
|
|
|
• Record of who performed testing and date the testing was performed 测试执行人及日期记录 |
|
|
|
• Established review and approval when appropriate 适当时的评审与批准记录 |
|
|
|
• Identify unscripted testing applied 指明所应用的非脚本化测试 |
|
|
|
• Independent review and approval of test plan when appropriate 适当时对测试计划的独立评审与批准 |
|
Assurance Activity 保障活动 |
Test Plan 测试计划 |
Test Results 测试结果 |
Record (Including Digital) 记录（含数字记录） |
|
Unscripted Testing: Scenario Testing 非脚本化测试：场景测试 |
• Testing of features and functions with no test plan 无测试计划下对特性与功能的测试 |
• Details regarding any failures/deviations found 任何失效/偏差的详情 |
• Intended use 预期用途 |
|
• Issues found 发现的问题 |
• Result of risk-based analysis 基于风险的分析结果 |
|
• Conclusion declaring acceptability of the software for its intended use, including the resolution or appropriate risk justification of issues found 声明软件适用于预期用途的结论，包括对发现问题的处理或适当风险论证 |
• Summary description of features and functions tested, and testing performed 被测特性与功能及所执行测试的概要描述 |
|
• Record of who performed testing and date the testing was performed 测试执行人及日期记录 |
|
|
• Established review and approval when appropriate 适当时的评审与批准记录 |
|
|
Assurance Activity 保障活动 |
Test Plan 测试计划 |
Test Results 测试结果 |
Record (Including Digital) 记录（含数字记录） |
|
Unscripted Testing: Error Guessing 非脚本化测试：错误猜测 |
• Testing of failure-modes with no test plan 无测试计划下对失效模式的测试 |
• Details regarding any failures/deviations found 任何失效/偏差的详情 |
• Intended use 预期用途 |
|
• Issues found 发现的问题 |
• Result of risk-based analysis 基于风险的分析结果 |
|
• Conclusion declaring acceptability of the software for its intended use, including the resolution or appropriate risk justification of issues found 声明软件适用于预期用途的结论，包括对发现问题的处理或适当风险论证 |
• Summary description of failure-modes tested, and testing performed 被测失效模式及所执行测试的概要描述 |
|
• Record of who performed testing and date the testing was performed 测试执行人及日期记录 |
|
|
• Established review and approval when appropriate 适当时的评审与批准记录 |
|
|
Assurance Activity 保障活动 |
Test Plan 测试计划 |
Test Results 测试结果 |
Record (Including Digital) 记录（含数字记录） |
|
Unscripted Testing: Exploratory Testing 非脚本化测试：探索性测试 |
• Establish high level test plan objectives with pass/fail criteria for each objective (no step-by-step procedure is necessary) 为每个目标建立高层级测试计划目标及通过/失败准则（无需分步程序） |
• Details regarding any failures/deviations found 任何失效/偏差的详情 |
• Intended use 预期用途 |
|
• Issues found 发现的问题 |
• Result of risk-based analysis 基于风险的分析结果 |
|
• Conclusion declaring acceptability of the software for its intended use, including the resolution or appropriate risk justification of issues found 声明软件适用于预期用途的结论，包括对发现问题的处理或适当风险论证 |
• Summary description of the objectives tested, and testing performed 被测目标及所执行测试的概要描述 |
|
• Record of who performed testing and date the testing was performed 测试执行人及日期记录 |
|
|
• Established review and approval when appropriate 适当时的评审与批准记录 |
|
The following is an example of a record of assurance in a scenario where a manufacturer has developed a spreadsheet with the intended use of collecting and graphing nonconformance data stored in a controlled system for monitoring purposes.
以下示例展示了某制造商开发的一款电子表格的保障记录，该表格用于收集和绘制受控系统中存储的不合格数据以供监控。
In this example, the manufacturer has established additional process controls and inspections that ensure non-conforming product is not released.
在此示例中，制造商已建立额外的过程控制和检查，确保不会放行不合格产品。
In this case, failure of the spreadsheet to perform as intended would not result in a quality problem that foreseeably leads to compromised safety, so the spreadsheet would not pose a high process risk.
在此情况下，电子表格未按预期运行不会导致可预见地损害安全性的质量问题，因此该表格不构成高过程风险。
The manufacturer conducted rapid exploratory testing of specific functions used in the spreadsheet to ensure that analyses can be created, read, updated, and/or deleted.
制造商对电子表格中使用的特定功能进行了快速探索性测试，以确保可以创建、读取、更新和/或删除分析。
During exploratory testing, all calculated fields updated correctly except for one deviation that occurred during the testing of the update.
在探索性测试期间，除更新测试中出现的一处偏差外，所有计算字段均正确更新。
In this scenario, the record would be documented as follows:
在此情形下，记录应如下所示：Intended Use:
预期用途：
The spreadsheet is intended for use in collecting and graphing nonconformance data stored in a controlled system for monitoring purposes; as such, it is used as part of production or the quality system.
该电子表格用于收集和绘制受控系统中存储的不合格数据以供监控；因此，它作为生产或质量体系的一部分使用。
Because of this use, the spreadsheet is different from similar software used for business operations such as for accounting.
由于此用途，该电子表格不同于用于业务运营（如会计）的类似软件。
Risk-Based Analysis:
基于风险的分析：
In this case, the software is only used to collect and display data for monitoring nonconformances, and the manufacturer has established additional process controls and inspections to ensure that nonconforming product is not released.
在此情况下，软件仅用于收集和显示监控不合格数据，且制造商已建立额外的过程控制和检查，确保不合格产品不会被放行。
Therefore, failure of the spreadsheet to perform as intended should not result in a quality problem that foreseeably leads to compromised safety.
因此，电子表格未按预期运行不应导致可预见地损害安全性的质量问题。
As such, the software does not pose a high process risk, and the assurance activities should be commensurate with the process risk.
因此，该软件不构成高过程风险，保障活动应与过程风险相称。
Tested:Spreadsheet X, Version 1.2
测试对象： 电子表格 X，版本 1.2T
est type:Unscripted testing – exploratory testing
测试类型： 非脚本化测试 – 探索性测试
Goal: Ensure that analyses can be correctly created, read, updated, and deleted
目标： 确保可以正确创建、读取、更新和删除分析
Testing objectives and activities:
测试目标与活动：
Create new analysis: Passed
创建新分析：通过
Read data from the required source: Passed
从所需源读取数据：通过
Update data in the analysis: Failed due to input error, then passed re-test
更新分析中的数据：因输入错误失败，重新测试后通过
Delete data: Passed
删除数据：通过
Verify through observation that all calculated fields correctly update with changes: Passed with noted deviation
通过观察验证所有计算字段随更改正确更新：通过（注明偏差）
Deviation:
偏差：
During the testing of the update, when the user inadvertently input text into an updatable field requiring numeric data, the associated row showed an immediate error.
在更新测试中，当用户不慎在要求数字的可更新字段中输入文本时，相关行立即显示错误。
Conclusion:
结论：
The spreadsheet is acceptable for its intended use.
该电子表格适用于其预期用途。
Incorrectly inputting text into the field is immediately visible and does not impact the intended use.
字段中输入文本的错误立即可见，不影响预期用途。
A new validation rule was placed on the field to permit only numeric data inputs.
已对该字段添加新验证规则，仅允许数字输入。
The testing was performed again with the validation rule and the update passed all testing objectives.
在添加验证规则后再次测试，更新通过所有测试目标。
No additional errors were observed in the spreadsheet functions after the validation rule was implemented.
实施验证规则后，电子表格功能中未观察到其他错误。
When/Who:July 9, 2024, by Jane Smith
时间/人员： 2024年7月9日，Jane Smith
B. Considerations for Electronic Records Requirements .............................23
B. 电子记录要求的考虑因素...................................................23
Manufacturers have expressed confusion and concern regarding the application of 21CFR Part 11, Electronic Records; Electronic Signatures, to computers or automated data processing systems used as part of production or the quality system.
制造商对将21CFR第11部分《电子记录；电子签名》应用于用于生产或质量系统的计算机或自动化数据处理系统表示困惑和担忧。
Manufacturers should refer to the "Part 11, Electronic Records; Electronic Signatures – Scope and Application" guidance (hereafter referred to as the "Electronic Records guidance"), when determining whether and how to apply 21CFR Part 11 (hereafter referred to as "Part 11").
制造商在确定是否以及如何应用21CFR第11部分（以下简称“第11部分”）时，应参考《第11部分，电子记录；电子签名——范围和应用》指南（以下简称“电子记录指南”）。
The regulations in Part 11 set forth the criteria under which FDA considers electronic records, electronic signatures, and handwritten signatures executed to electronic records to be trustworthy, reliable, and generally equivalent to paper records and handwritten signatures executed on paper.
第11部分的法规规定了FDA认为电子记录、电子签名以及对电子记录的手写签名可信、可靠，并通常与纸质记录和手写签名具有同等效力的标准。
In general, Part 11 applies to records in electronic form that are created, modified, maintained, archived, retrieved, or transmitted under any records requirements set forth in Agency regulations.
一般而言，第11部分适用于根据FDA法规中的任何记录要求以电子形式创建、修改、维护、归档或传输的记录。
Part 11 also applies to electronic records submitted to the Agency under requirements of the FD&C Act and the Public Health Service Act (PHS Act), even if such records are not specifically identified in Agency regulations.
第11部分还适用于根据《FD&C法案》和《公共卫生服务法》（PHS法案）要求向FDA提交的电子记录，即使这些记录未在FDA法规中明确列出。
The underlying requirements set forth in the FD&C Act, PHS Act, and FDA regulations (other than Part 11) are referred to as "predicate rules."
《FD&C法案》、《PHS法案》和FDA法规（第11部分除外）中规定的基本要求被称为“前置规则”。
In addition, where electronic signatures and their associated electronic records meet the requirements of Part 11, FDA will generally consider the electronic signatures to be equivalent to full handwritten signatures, initials, and other general signings as required by agency regulations.
此外，如果电子签名及其相关电子记录符合第11部分的要求，FDA通常将认为电子签名等同于法规要求的全名手写签名、首字母缩写及其他一般签署。
For computer software used as part of production or the quality system, the applicable predicate rules include those under Part 820.
对于用于生产或质量系统的计算机软件，适用的前置规则包括第820部分中的要求。
A document required under Part 820—including, but not necessarily limited to, a document Part 820 requires to bear a signature—and maintained in electronic form would generally be an "electronic record" under Part 11.
根据第820部分要求提供的文件——包括但不限于第820部分要求签名的文件——如以电子形式维护，通常属于第11部分下的“电子记录”。
To determine when a record is required under Part 820, manufacturers should consider, among other things, whether the record would be necessary as evidence to document required validation.
为确定何时需要根据第820部分提供记录，制造商应考虑，除其他事项外，该记录是否为记录所需验证所必需的证据。
If a manufacturer maintains in electronic form a document required under Part 820, then Part 11 generally applies.
如果制造商以电子形式维护根据第820部分要求提供的文件，则通常适用第11部分。
As discussed in the Electronic Records guidance, FDA intends to exercise enforcement discretion regarding specific Part 11 requirements for validation of computerized systems used to create, modify, maintain, or transmit electronic records.
如《电子记录指南》所述，FDA打算对用于创建、修改、维护或传输电子记录的计算机化系统的验证方面的特定第11部分要求行使执法自由裁量权。
But the enforcement discretion policy described in the Electronic Records guidance expressly does not apply to the validation requirement for computer software used as part of production or the quality system arising under 21CFR 820.70(i).
但《电子记录指南》所述的执法自由裁量政策明确不适用于根据21CFR 820.70(i)产生的用于生产或质量系统的计算机软件的验证要求。
This guidance recommends that manufacturers base their approach to computer software assurance on a justified and documented risk assessment and a determination of the potential of the system to affect product quality, patient safety, and record integrity.
本指南建议制造商在开展计算机软件保障时，以有正当理由并记录的风险评估以及对系统可能影响产品质量、患者安全和记录完整性的潜力的判定为基础。
Manufacturers may utilize a least-burdensome, risk-based approach outlined in this guidance to provide assurance that the software that maintains electronic records subject to Part 11 performs as intended.
制造商可利用本指南所述的最小负担、基于风险的方法，为确保维护受第11部分约束的电子记录的软件按预期运行提供保障。
Appendix A. Examples
附录A 示例
The examples in this section outline possible application of the principles in this guidance to various software assurance situations.
本节示例概述了本指南原则在不同软件保障情境中的可能应用。
Example 1: Nonconformance Management System
示例1：不合格品管理系统
A manufacturer has purchased and configured COTS software for automating their nonconformance process and is applying a risk-based approach for computer software assurance in its implementation. The software is intended to manage the nonconformance process electronically.
某制造商已购买并配置商用现成（COTS）软件，用于自动化其不合格品处理流程，并在实施中采用基于风险的计算机软件保障方法。该软件旨在以电子方式管理不合格品处理流程。
As part of the assurance activities, the manufacturer performs a thorough assessment of the software vendor that includes:
作为保障活动的一部分，制造商对软件供应商进行了全面评估，包括：
Evaluation of the vendor's software development life cycle,
评估供应商的软件开发生命周期，
Review of the vendor's quality management system and relevant certifications, and
审查供应商的质量管理体系及相关认证，以及
Review of vendor's cybersecurity documentation and life cycle management plans as well as relevant certifications.
审查供应商的网络安全文件及生命周期管理计划及相关认证。
Based on the manufacturer's established SOP for evaluating suppliers, the vendor's capability to meet the manufacturer's requirements are deemed acceptable for the software's intended use. The manufacturer maintains a record of the evaluation according to their established purchasing control procedures.
根据制造商已建立的供应商评估SOP，供应商满足制造商要求的能力被认为适用于该软件的预期用途。制造商根据其已建立的采购控制程序保存评估记录。
The following features, functions, or operations were considered by the manufacturer in developing a risk-based assurance strategy:
制造商在制定基于风险的保障策略时考虑了以下特性、功能或操作：
Table 2. Computer Software Assurance Example for a Nonconformance Management System
表2 不合格品管理系统计算机软件保障示例表格复制
|
Features, Functions, or Operations 特性、功能或操作 |
Intended Use of the Features, Functions or Operations 特性、功能或操作的预期用途 |
Risk-Based Analysis 基于风险的分析 |
Assurance Activities 保障活动 |
Establishing the appropriate record 建立适当记录 |
|
Access Control, User Management, and Notification Functions |
Manage user access/workflow/training notifications |
Impact integrity, not safety → Not high process risk |
Vendor + system assessment; unscripted error-guessing tests |
记录同表2结构 |
|
访问控制、用户管理与通知功能 |
管理用户访问/工作流/培训通知 |
影响记录完整性，不危及安全 → 非高过程风险 |
供应商+系统评估；非脚本化错误猜测测试 |
同左记录结构 |
Record-keeping and Reporting Functions| Capture training evidence; generate reports for review | Same risk conclusion as above | Vendor assessment + unscripted "break-the-system" tests
| 同左记录结构 | | 记录与报告功能 | 捕获培训证据；生成报告供审查 | 同上风险结论 | 供应商评估+非脚本化“破坏系统”测试 | 同左记录结构 |
Example 3: Business Intelligence Applications
示例3：商业智能应用程序
A medical device manufacturer has decided to implement a commercial business intelligence solution for data mining, analytics, and reporting. The software is intended to better understand product and process performance over time, to identify improvement opportunities.
某医疗器械制造商决定实施商用商业智能解决方案，用于数据挖掘、分析和报告。该软件旨在更好地理解产品和过程随时间的性能，以识别改进机会。
As part of the assurance activities, the manufacturer performs a thorough assessment of the software vendor that includes:
作为保障活动的一部分，制造商对软件供应商进行了全面评估，包括：
Evaluation of the vendor's software development life cycle,
评估供应商的软件开发生命周期，
Review of the vendor's quality management system and relevant certifications, and
审查供应商的质量管理体系及相关认证，以及
Review of vendor's cybersecurity documentation and life cycle management plans as well as relevant certifications.
审查供应商的网络安全文件及生命周期管理计划及相关认证。
Based on the manufacturer's established SOP for evaluating suppliers, the vendor's capability to meet the manufacturer's requirements are deemed acceptable for the software intended use. The manufacturer maintains a record of the evaluation according to their established purchasing control procedures.
根据制造商已建立的供应商评估SOP，供应商满足制造商要求的能力被认为适用于该软件的预期用途。制造商根据其已建立的采购控制程序保存评估记录。
In addition to the vendor assessment, the following features, functions, or operations were considered by the manufacturer in developing a risk-based assurance strategy:
除供应商评估外，制造商在制定基于风险的保障策略时考虑了以下特性、功能或操作：
Table 4. Computer Software Assurance Example for a Business Intelligence Application
表4 商业智能应用程序计算机软件保障示例表格复制
|
Features, Functions, or Operations 特性、功能或操作 |
Intended Use of the Features, Functions or Operations 特性、功能或操作的预期用途 |
Risk-Based Analysis 基于风险的分析 |
Assurance Activities 保障活动 |
Establishing the appropriate record 建立适当记录 |
|
Connectivity Functions |
Ensure secure/robust connection to data sources; maintain data integrity; prevent corruption. |
Failure could lead to inaccurate trending → High process risk. |
Vendor assessment + detailed scripted protocol with repeatability tests. |
Documents intended use, risk analysis, detailed protocol, pass/fail per case, issues, signatory review. |
|
连接功能 |
确保安全/稳健连接数据源；维护数据完整性；防止损坏。 |
失效或致趋势分析不准确 → 高过程风险。 |
供应商评估+详细脚本化方案含可重复性测试。 |
记录预期用途、风险分析、详细方案、逐例通过/失败、问题、签字评审。 |
User Help Feature | Provide help menu for users. | Unlikely to result in quality problem → Not high process risk. | No additional assurance beyond vendor assessment.
| 记录同表2结构。 | | 用户帮助功能 | 为用户提供帮助菜单。 | 不太可能引发质量问题 → 非高过程风险。 | 除供应商评估外无需额外保障。 | 同左记录结构。 |
|Reporting Functions | Query data, perform analysis, generate visuals/summaries for monitoring/review. | No direct impact on production → Not high process risk. | Leverage vendor validation; vendor assessment + system install.
| 同左记录结构。 | | 报告功能 | 查询数据、执行分析、生成可视化/摘要供监控/审查。 | 对生产无直接影响 → 非高过程风险。 | 利用供应商验证；供应商评估+系统安装。 | 同左记录结构。 |
Example 4: Software as a Service (SaaS) Product Life Cycle Management System (PLM)
示例4：软件即服务（SaaS）产品生命周期管理系统（PLM）
A medical device manufacturer has decided to implement a SaaS-based Product Life Cycle Management System (PLM). While the PLM SaaS solution has the capability to automate the management of various life cycle stages of a product development, the manufacturer intends to use the solution for broad project management. The SaaS PLM is intended to automate the intake of project requirements, develop project plans, monitor/track project execution, and maintain relevant records, signatures, and deliverables upon project closing. This intended use of the system does not directly impact patient safety or product quality but does maintain a quality system record where integrity of the data is needed. The manufacturer does not need any customization of the “out-of-the-box” capabilities of the SaaS product and only needs to perform basic standard configuration of the SaaS product (e.g., user roles, accounts).
某医疗器械制造商决定实施基于SaaS的产品生命周期管理（PLM）系统。尽管PLM SaaS解决方案具备自动化管理产品开发各生命周期阶段的能力，制造商仍打算将该解决方案用于广泛的项目管理。SaaS PLM旨在自动化项目需求收集、制定项目计划、监控/跟踪项目执行，并在项目结束时维护相关记录、签名和交付成果。该系统的预期用途不会直接影响患者安全或产品质量，但会维护需要数据完整性的质量体系记录。制造商无需对SaaS产品的“开箱即用”功能进行任何定制，只需执行SaaS产品的基本标准配置（如用户角色、账户）。
As part of the assurance activities, the manufacturer performs a thorough assessment of the SaaS vendor that includes:
作为保障活动的一部分，制造商对SaaS供应商进行了全面评估，包括：
Evaluation of the vendor's software development life cycle,
评估供应商的软件开发生命周期，
Review of the vendor's quality management system and relevant certifications,
审查供应商的质量管理体系及相关认证，
Review of vendor's cybersecurity documentation and life cycle management plans as well as relevant certifications, and
审查供应商的网络安全文件及生命周期管理计划及相关认证，以及
Review of the vendor's infrastructure support including availability and reliability.
审查供应商的基础设施支持，包括可用性和可靠性。
Based on the manufacturer's established SOP for evaluating suppliers, the vendor's capability to meet the manufacturer's requirements are deemed acceptable for the software intended use. The manufacturer maintains a record of the evaluation according to their established purchasing control procedures. The manufacturer also establishes a service agreement with the SaaS vendor that includes requirements for security, data integrity, privacy, availability, change management, and business continuity.
根据制造商已建立的供应商评估SOP，供应商满足制造商要求的能力被认为适用于该软件的预期用途。制造商根据其已建立的采购控制程序保存评估记录。制造商还与SaaS供应商建立了服务协议，其中包括对安全性、数据完整性、隐私、可用性、变更管理和业务连续性的要求。
Automatic Updates:
自动更新：
The SaaS vendor provides the manufacturer documentation summarizing the changes, testing, and testing results of all automatic updates made to the SaaS system functions identified by the manufacturer as part of the service agreement. The manufacturer performs an assessment of the changes and the effect they may have on the intended use. The manufacturer performs risk-based assurance testing of the changes appropriate to the impact identified. The manufacturer maintains a record summarizing the risk assessment of the change and any assurance activities performed.
SaaS供应商向制造商提供文件，总结制造商在服务协议中确定的SaaS系统功能所进行的所有自动更新的变更、测试和测试结果。制造商对这些变更及其对预期用途可能产生的影响进行评估。制造商根据识别的影响进行基于风险的保障测试。制造商保存一份记录，总结对变更的风险评估和所开展的任何保障活动。Table 5.
Computer Software Assurance Example for SaaS PLM
表5 SaaS PLM计算机软件保障示例表格复制
|
Features, Functions, or Operations 特性、功能或操作 |
Intended Use of the Features, Functions or Operations 特性、功能或操作的预期用途 |
Risk-Based Analysis 基于风险的分析 |
Assurance Activities 保障活动 |
Establishing the appropriate record 建立适当记录 |
|
Project Initiation and Planning Function |
Automate creation of project data record, assign roles, intake key data, develop project plan, monitor changes. |
Failure impacts QS record integrity, not safety → Not high process risk. |
Vendor + service agreement assessment; config verification + exploratory UAT. |
Documents intended use, risk analysis, test summary, issues, conclusion, tester/date. |
|
项目启动与规划功能 |
自动化创建项目数据记录、分配角色、录入关键数据、制定项目计划、监控变更。 |
失效影响质量体系记录完整性，不危及安全 → 非高过程风险。 |
供应商+服务协议评估；配置验证+探索性UAT。 |
记录预期用途、风险分析、测试概要、问题、结论、测试人/日期。 |
Electronic Signature Function | Capture/store electronic signature meeting Part 11 requirements. | Failure may delay compliance but not foreseeably compromise safety → Not high process risk. | Vendor assessment + scenario testing with users. |
同上，含功能符合性结论。 | | 电子签名功能 | 捕获/存储符合第11部分要求的电子签名。 |失效或延迟合规，但不会可预见地危害安全 → 非高过程风险。 | 供应商评估+与用户进行场景测试。| 同上，增加功能符合性结论。 |
|Access Control and Traceability Functions | Control user roles/permissions; log access/changes; produce time-stamped reports. | Significant impact on intended use; QS integrity issue only → Not high process risk. | Config verification + automated test script + exploratory UAT on reporting. | Documents intended use, risk analysis, automated script summary, issues, conclusion, tester/date. |
| 访问控制与可追溯性功能 | 控制用户角色/权限；记录访问/更改；生成带时间戳报告。 | 对预期用途影响显著；仅质量体系完整性问题 → 非高过程风险。 | 配置验证+自动化测试脚本+对报告进行探索性UAT。 | 记录预期用途、风险分析、自动化脚本概要、问题、结论、测试人/日期。
