计算机化系统验证基本要求的探讨

王健明

（上海信谊药厂有限公司制药二厂，上海201200）

0 引言

随着GMP（2010修订版）有关计算机化系统附录的生效日期的临近，计算机化系统验证的话题已经被人们经常提及，但大多对自己企业各类相关的计算机化系统应该如何验证感到困惑，应该遵从怎样的规范来实施验证，本文希望就上述话题与同行一起学习和探讨，分享我们多年来在工作实践中的成果。

1 基本概念

GMP计算机化系统附录第4章就验证做出如下阐述：应使用科学的风险评估方法来决定计算机化系统的验证范围与程度，应当将验证看作计算机化系统生命周期的一个组成部分，这个生命周期包括计划、设定标准、编程、测试、试运行、文档管理、运行、监控、修改更新等阶段，要充分考虑计算机化系统的使用范围，确定其属于前验证还是回顾性验证，系统是否引入新的组件。

首先我们有必要将上述专业名词用ISPEGAMP 5《良好自动化生产实践指南》来做一下定义，以便明确其内涵。

1.1 风险评估方法

计算机化系统质量风险管理流程（图1），采用了ICH Q9的一般原则来说明风险管理的“5个步骤”，该流程是实现与维护系统不可或缺的部分，对于简单的低风险的系统可以进行组合。

图1 计算机化系统质量风险管理流程

1.2 计算机化系统

计算机化系统框图如图2所示，其是由硬件、软件、网络组件以及可控的功能和相关文件组成。它可以包括：生产资源计划系统、实验室信息管理系统、自动化生产设备系统、生产执行系统、仓储与配送系统、文件管理系统。

图2 计算机化系统框图

1.3 计算机化系统的生命周期

计算机化系统的生命周期由以下4个主要阶段组成：概念提出、项目实施、系统运行、系统退役。

概念提出阶段通常由监管公司根据自己的业务需求和收益来考虑阶段需要实现的业务流程，并考虑可能的解决方法。

项目实施是充分考虑了自己的业务需求和收益后，根据项目的活动中的计划，评估和选择供应商，规范各层级的需求，并进行配置、验证，直到项目的验收和系统投入使用。

系统运行是4个阶段中最长的阶段，是由确定的及时更新的具有可操作性的规程来对其进行管理，期望保持系统可控、符合预定用途及合规等都是非常关键的方面，重点是对系统的影响、范围和复杂性的变更进行管理。

当系统即将退出公司的业务不再使用时，就自然进入了退役阶段，该阶段决定对数据进行保留、迁移还是销毁。

2 验证实施

验证通常使用国际制药工程协会（ISPE）的《良好自动化生产实践指南》（GAMP5）的V字模型（图3），该模型是使系统在整个生命周期实现合规与符合预定用途的通用方法。该模型的验证过程包括用户需求规范、功能需求规范、设计规范、系统开发、安装确认、运行确认和性能确认。测试阶段的验证活动用来确认规范阶段的需求得到满足。

2.1 验证主计划（VMP）

在项目实施前首先需要定义验证计划，它可以作为既定的时间段内或工作流的总体计划，它应该是验证项目的概述文件，必须清晰精确地表述和涵盖设施、系统、流程的概述。

验证过程是建立文件证据，为特定的计算机化流程可以持续地满足预先定义的质量要求规范提供高度保证。其主要目标是通过文件、记录系统可持续满足需求。此验证主计划的目的是定义该系统的验证活动，内容包含定义、验证范围、验证角色和职责以及主要验证产生文档的描述。

图3 GAMP5 V字模型

2.1.1 系统描述

系统是进行药品生产质量控制的技术平台，它是由多个子系统集成，主要涵盖生产管理、质量管理等模块。

2.1.2 功能范围

验证项目实施的范围有生产流程、质量管理流程，功能模块有生产管理模块、质量管理模块等。

2.1.3 系统的技术架构

系统主要由生产管理模块、质量管理模块以及其他业务模块组成，涵盖开发环境、验证环境、运行环境以及备份服务器的架构及配置文件的描述等。

2.1.4 验证方法

验证将使用国际制药工程协会（ISPE）的《良好自动化生产实践指南》（GAMP5）的V字模型，该模型是使系统在整个生命周期实现合规与符合预定用途的通用方法。该模型的验证过程包括用户需求规范、功能需求规范、设计规范、系统开发、安装确认、运行确认和性能确认等。

2.1.5 风险评估

作为验证方法的组成部分，企业将采取基于风险的方法，对系统功能的风险水平进行评估。风险评估将对系统验证范围内的流程或功能相关的法规和业务风险进行合理地评估并进行书面记录。编制风险评估报告递交决策层审批。

2.1.6 验证交付

验证交付的内容：验证主计划、设计需求规范、功能需求规范、用户需求规范、确认阶段（IQ、OQ、PQ）、标准操作程序、用户培训、偏差管理、验证总结报告。

2.1.7 项目的角色与职责

验证主管和信息系统质量保证主管需要对协议授权，对验证结果和验证总结报告进行审批。项目中需要对团队的角色做出定义，如执行决策者（ES）、项目经理（PM）、开发团队主管（DTL）、开发团队成员（DTM）、业务部门主管/团队成员（BTL/BTM）、验证主管（VTL）、验证团队成员（VTM）、信息系统质量保证主管（ISQA）等，并按照上述角色，确定审批矩阵。

2.2 风险评估

该系统为企业的生产、质量控制的业务流程提供有效的运作支持，企业将采取基于风险的方法，对业务环境面临的风险进行整体的风险评估。

2.2.1 目的

风险评估的目的是对系统功能的重要性和复杂性进行评价。风险评估对企业系统的相关功能的业务、技术和法规风险提供合理的评估结果，并进行文件记录。

对系统的功能性风险评估将考虑系统对企业质量管理体系、产品的质量、安全和效用以及数据完整性方面的潜在影响。此外，系统功能所支持的业务的重要性以及系统解决方案的技术复杂程度也是风险评估考虑的因素。

2.2.2 范围

文档的范围限于验证主计划中所列的业务流程涉及的各模块。

2.2.3 角色与职责

定义验证团队业务部门主管、信息技术主管、项目经理的职责。

2.2.4 风险评估

2.2.4.1 系统风险评估

（1）GMP评估：用来判断该系统是否应作为企业质量体系的一部分而被定义为一个GMP相关的系统。被判定与GMP相关就要求通过验证以满足GMP的要求。

（2）重要性评估：根据提出的问题所作的回答来判定其重要程度。

（3）复杂性评估：根据提出的问题所作的回答来判定其复杂程度。

（4）评估总结：对重要性和复杂性评估的结果作出判断。

2.2.4.2 功能风险评估

如果模块是与GMP相关的，则需要对每个功能进行进一步的评估。表1为功能风险评估表，功能风险评估方法参照ISPEGAMP5中的方法，由业务风险、技术风险、GMP风险3个维度组成。每个维度都有4个等级来表示风险的等级：高（3）、中（2）、低（1）、无（0）。每个功能最终的风险等级将由3个维度中风险等级最高的维度的风险等级决定。风险评估的结果将被用来定义验证范围和测试等级。验证范围将包括所有与GMP相关的功能。

表1 功能风险评估表

评估结果为高、中风险，需要做正式归档测试，正式归档测试时，所有的测试实例会被预先审批，然后执行、审核以及批准。

评估结果为低、无风险，需要做非正式归档测试，在非正式归档测试时，测试实例无需预先审批，只会在执行后被审批，但是测试总结报告会被审核以及批复。

2.3 用户需求规范

2.3.1 目的

文档的目的是为了定义企业实施并使用系统的业务/用户需求。

2.3.2 范围

文档的内容包括生产管理、质量管理业务流程的用户需求。

2.3.3 用户需求定义

表2 为用户需求定义，其包括子流程编号、用户需求编号以及用户需求描述。

表2 用户需求定义

2.4 功能需求规范

2.4.1 目的

文档的目的是为了定义企业实施并使用系统的功能需求。

2.4.2 范围

文档的内容包括企业生产、质量管理业务流程的功能需求。

2.4.3 子流程功能需求定义

表3 为子流程功能需求定义，其文档应该具备功能需求编号及详细描述。

2.5 设计需求规范

2.5.1 目的

文档的目的是描述系统模块的设计规范，简述模块中重要功能的输入、输出项及实现逻辑。

表3 子流程功能需求定义

2.5.2 范围

文档的内容包括模块业务流程中识别的被评估为高风险的系统功能的设计需求。本文档记录的系统功能已对业务风险、技术风险、GMP风险进行了功能性风险评估，3个维度均被评估为高风险系统功能编写设计需求。

2.5.3 功能描述

表4 为功能描述，其包括：（1）设计需求编号；（2）所实现的功能；（3）功能的输入项目；（4）功能的输出项目；（5）逻辑流程描述；（6）其他功能的接口和限制条件；（7）功能所需达到的性能要求；（8）测试要点。

表4 功能描述

2.6 安装确认

安装确认是指检查、测试或其他核实，从而证明软件和硬件的安装、配置是正确的。

2.6.1 安装确认协议

2.6.1.1 目的

编写本安装确认协议的目的是为了描述系统进行安装确认将要执行的各项任务。

2.6.1.2 方法

针对系统应用的阶段，可以将验证分为前验证或回顾性验证，验证系统生产运行环境或验证环境范围内的硬件和软件是否符合IT基础设施和软件规范定义的标准。

2.6.1.3 范围

该安装确认协议适用范围为系统的验证环境和生产环境的基础设施和软件。

该安装确认协议的测试实例，在被执行之前，需要经过审批，审批通过之后将被用来检验验证。

该安装确认协议需要在进行安装确认测试活动开始之前被审批。完成安装确认测试之后，安装确认报告将会被撰写，其中将会包括安装的满意度和发现的问题。

2.6.1.4 风险评估

本风险估会在执行此协议时被执行。对于软硬件的风险评估，将基于该软硬件是否对运行确认测试和性能确认测试产生影响和该软硬件是否将应用于生产环境。如果符合以上2种情况中的任何一种，将判定该软硬件的风险等级为高。

2.6.1.5 角色与职责

定义项目参与人员及需要的角色，如质量职责、信息系统职责、测试职责、验证团队等。

2.6.1.6 测试实例内容

IT基础设施验证包括：（1）物理环境；（2）系统崩溃；（3）访问安全；（4）数据完整。

2.6.1.7 系统管理流程验证

系统管理流程验证包括：（1）服务器运行（时钟验证）；（2）系统状态检查；（3）定期维护；（4）系统清理；（5）系统诊断，性能评估；（6）系统电力供应和后备电源。

2.6.1.8 物理安全流程验证

物理安全流程验证包括：（1）紧急情况条例；（2）访问者/承包商条例；（3）机房访问。

2.6.1.9 逻辑安全流程验证

逻辑安全流程验证包括：（1）系统访问控制；（2）密码变更方式和频率；（3）病毒防护/探查方法和频率；（4）自动注销功能；（5）访问复原要求流程。

2.6.1.10 培训

所有参加安装确认的人员，都应该参加足够的培训，以完成所分配的任务并明确培训的内容。

2.6.1.11 流程

在执行安装确认测试实例之前，以下工作必须完成：（1）安装确认协议需要被批准；（2）软硬件的风险评估需被确认；（3）每一个测试实例需要被批准。

2.6.1.12 测试执行

在正式测试前，需要对以下问题作出说明：系统访问、阅读测试实例、测试命令或数据输入、系统截屏、测试结果、测试者姓名以及测试日期、测试员错误、非预期结果。

2.6.1.13 测试偏差

如果某种测试结果不能满足之前提供的期望结果，测试员由于某种原因不能完成整个测试，或者验证团队主管决定某个测试结果不满足预期结果则验证团队主管需要记录该测试偏差，测试员需要填写测试偏差记录。内容应包括：测试偏差描述、偏差文档、测试偏差分类、测试偏差调查、重新测试说明、重新测试、测试审核和结束、测试事件汇报和跟踪。

2.6.1.14 测试结果审查

在每一个测试实例完成时，测试实例及其支持文档应被测试员和验证团队主管独立审查，以确保测试结果的完成，包括对于测试偏差报告的审核、安装确认测试实例的审核等。

2.6.1.15 安装确认报告

安装确认报告将在测试完成后被编制和审批，该报告包含：（1）安装确认测试的概要；（2）各安装确认测试实例的结果；（3）产生的偏差事件以及结果；（4）与原测试计划的偏离；（5）结果可接受性的结论。

2.6.2 安装确认测试脚本

安装确认测试脚本（表5）具体内容如下：

（1）需要明确测试的环境及服务器名称、环境名称等详细描述。

（2）测试记录应包括：规范描述、测试结果复核、步骤、操作/步骤描述、测试活动、预期结果、测试结果、测试结论、通过/不通过。

（3）总体测试结果：对测试结果作出判断通过、不通过、在条件下通过的结论。

（4）审批矩阵。

（5）测试支持文档：将测试过程中的主要结果以截图方式提供。

表5 安装确认测试脚本

2.6.3 安装确认报告

文档的目的是对安装确认测试活动以及结果作出综合性的评价。安装确认测试已经执行，安装确认的目的是确认系统的软硬件已经按照需求安装，并能支撑系统的运作。

2.6.3.1 详细描述

记录安装测试脚本的实例汇总（表6），所有的测试脚本已经完成，并对所列项目以表格形式汇总测试结果，应包括：安装确认编号、测试实例名、生产环境（通过/不通过）、验证环境（通过/不通过）。

表6 安装测试脚本的汇总

2.6.3.2 偏差记录

测试员在IQ测试中发现的偏差已被记录，验证团队已经对偏差进行了评估，并针对评估的结果制定了偏差处理的解决方案。根据解决方案，验证团队已经对系统进行了相应的变更并进行了重新测试。

2.6.3.3 偏差最终状态

安装协议中规定测试中出现的偏差需要重新测试，并在处理结果（表7）中显示偏差描述、处理结果、偏差最终状态，然后确认是否同意关闭。

表7 偏差最终状态处理结果

2.6.3.4 结论

安装确认已经按照安装确认协议完整执行。安装确认测试脚本已经完成编制，并经过审批和签署。所有的偏差已经被记录、报告、分析和处理，所有的偏差都已被关闭，可以进行运行确认测试。

2.7 运行确认

运行确认是指按照规范来进行的系统测试或其他核实活动，用来证明功能的正确运行能够支持所有规定运行范围内的具体业务流程。

2.7.1 运行确认协议

2.7.1.1 目的

运行确认协议的目的是记录系统的运行与用户要求及功能描述相一致的验证过程。在批准和执行本运行确认协议并执行相关测试后，编制运行确认报告，管理层对运行确认报告的审批表示系统的功能运行已处于验证状态，可以进行下一步的性能确认。

2.7.1.2 范围

运行确认测试的功能范围为规范阶段定义的系统功能需求，包括生产管理模块、质量管理模块等。

2.7.1.3 运行确认方法

文件定义了运行确认的目标、范围、职责、方法、执行流程及验收标准。对于GMP风险归类被定义为“高”风险的功能需求，在运行确认测试中将进行重点测试。

（1）功能测试：运行确认单元功能测试是用来证明系统功能的运作符合项目的设计的，单元功能测试可以确认系统的运作功能是否能满足企业在功能需求文档中的要求。

（2）测试环境：运行确认单元测试会在信息系统的验证环境中执行，该环境需要包括所有系统功能以及运行确认范围下定制的对象。任何与单元测试、偏差/错误修复不相关的系统配置更新会被归档，且按照项目变更控制流程来评估。

（3）运行确认测试的建立和审批：每个编制完成的测试脚本会在执行之前被业务部门团队主管及验证团队主管审批。对于已经审批的文档如有任何更改，需要遵循文件控制流程。

（4）执行运行确认测试：经审批的运行确认测试脚本将被测试员执行测试，将执行运行确认单元测试脚本的结果以及相关的截屏打印出来，并在打印出的文件上签署名字和日期。

（5）验证：验证主管需在执行测试脚本前审查和批准运行确认协议以及每个运行确认测试脚本，验证团队应确保测试环境已被正确安全地建立，确保验证人员得到培训并熟悉协议中所确定的流程。验证主管需要评估运行确认的整体结果，来决定其是否满足验收标准。

（6）测试脚本的执行和审批：测试员需要遵循测试脚本中的测试步骤，记录测试的实际结果，按需要提供系统截屏。测试员需要评估测试的实际结果，并确定它们是否满足预期结果。如果满足了预期结果，测试员需要标注该步骤为“通过”，如果没有满足预期结果，测试员需要标注该步骤为“未通过”，并且记录为一个偏差。测试脚本应当在执行前由验证主管审批。

（7）测试脚本执行后的审查：职能团队主管需审查测试员的测试结果，也需要确认提供的相关文档与脚本执行的结论（通过/未通过）相符，并提交验证主管审查批准。

2.7.1.4 偏差管理

（1）偏差记录。当测试结果与预期结果或者功能规范不符时，测试员需要记录为一个偏差，并记录相关的测试步骤编号。

（2）偏差分类。偏差可以分为严重、高、中、低4类。

（3）测试偏差调查：系统管理员、测试员和验证团队主管会评估每一个测试事件及其成因。

（4）重新测试。如果测试事件报告的结论是需要重新测试，验证团队主管将发布运行确认重新测试副本，需包含相关的测试实例，标记并签名相关测试会被重新执行。测试完成后，测试人员将所有的文档递交给验证团队主管。

（5）最终协议审批及验收标准。在测试执行结束后且执行性能确认测试前，必须满足下列验收标准：此协议下的所有测试脚本都被执行，且相关的系统截屏或者其他支持文档都已提交。所有测试步骤被标注为“通过”，当标注为“未通过”时，相应的偏差被修复或已拥有合适的替代方案。偏差只有不影响用户使用系统时，在结束运行确认后，才可以允许维持“未关闭”状态。严重偏差和高偏差必须修复，或者至少有过渡时期的解决方案。中低偏差需要先确认分类是否准确，并提出相应的解决方案。

2.7.2 运行确认测试脚本

2.7.2.1 目的

文档的目的在于确认系统满足了功能需求，并且系统能够用来执行性能确认测试。

2.7.2.2 测试范围

文档包括生产管理、质量管理流程的功能需求。

2.7.2.3 测试接受标准

测试结果与预期结果一致为通过，否则不通过。

2.7.2.4 测试环境描述

说明服务器名称、测试环境、软件版本等。

2.7.2.5 测试脚本

测试脚本中申明功能需求的编号、测试结果的复核，以及测试的步骤、操作描述、测试数据、预期结果、测试结果和测试结论。

2.7.2.6 偏差记录

测试结果的审批。

2.7.3 运行确认报告

文档目的是对运行确认测试活动以及结果给出综合性的评价。运行确认测试已经完成，运行确认的目的是确认系统的功能需求已得到满足，系统可以继续执行性能确认的测试。

2.7.3.1 测试详述

测试实例汇总，所有测试已经执行完毕。

2.7.3.2 偏差记录（略）

2.7.3.3 结论

运行确认是已经按照运行确认协议被完整地执行。运行确认测试脚本已经完成编制，经过审批和签署。所有的偏差已经被记录、报告、分析和处理，所有的偏差都已被关闭，可以进行性能确认测试。

2.8 性能确认

通过测试和其他活动来证明系统符合预定用途，并允许按照所规定要求进行系统验收。

2.8.1 性能确认协议

2.8.1.1 目的

性能确认是指通过文件记录证明企业实施系统在业务流程和运行环境范围内，能够按照书面的预先已批准的用户需求规范正确运行所要求的业务流程活动。性能确认将使用集成的测试业务场景。性能确认使用的是真实的业务数据，针对用户角色安全功能的安全测试将被包含在性能确认中。

2.8.1.2 系统描述

系统包含生产管理模块和质量管理模块集成。

2.8.1.3 验证范围

验证范围仅限于在验证主计划（VMP-CN）中确定的企业实施的系统。性能确认测试的功能范围为规范阶段定义的用户需求规范。在规范阶段定义的用户需求涉及生产业务流程、QA业务流程以及生产管理模块、质量管理模块等系统模块。

2.8.1.4 性能确认方法（略）

2.8.1.5 测试数据需求

性能确认使用的是真实的业务数据，来确保每个单元模块联合起来操作后也能正常稳定地运作。

2.8.1.6 职责

定义性能确认的每个任务的执行和审核职责。

2.8.1.7 验收标准

当下列条件满足时，性能确认被认为满足验收标准：（1）用户需求已得到满足，系统能持续运作；（2）每个测试脚本的验收标准已得到满足；（3）所有性能确认的测试已经完成并圆满通过；（4）异常情况被归档且解决；（5）性能确认报告圆满完成，通过审核并得到审批。

2.8.1.8 测试的执行

（1）测试脚本审批：每个测试脚本在执行前需要得到职能团队主管和验证主管的批准。

（2）脚本执行：测试员需要遵循测试脚本中的测试步骤，记录测试的实际结果，按需要提供系统截屏。测试员需要评估测试的实际结果，并决定它们是否满足预期结果。如果满足了预期结果，测试员需要标注该步骤为“通过”，如果没有满足预期结果，测试员需要标注该步骤为“未通过”，并且记录为一个偏差。

（3）执行后审查：职能团队主管需要对测试员提供的文档以及测试结果进行审查。

2.8.1.9 偏差管理（略）

2.8.1.10 偏差记录

当测试结果与预期结果或者功能规范不符时，测试员需要记录为一个偏差，并记录相关的测试步骤编号。

2.8.1.11 偏差分类（同运行确认测试协议）

2.8.2 性能确认测试脚本

2.8.2.1 目的

文档的目的在于确认系统的生产管理、质量管理满足了性能需求。

2.8.2.2 测试范围

测试性能确认包括生产流程、质量管理流程系统性能需求。

2.8.2.3 测试条件的建立（略）

2.8.2.4 测试接受标准（略）

2.8.2.5 测试详述

测试环境说明服务器名称、测试环境、软件版本等。

2.8.2.6 测试脚本

测试脚本中应申明功能需求的编号、测试结果的复核以及测试的步骤、操作描述、测试数据、预期结果、测试结果和测试结论。

2.8.2.7 偏差记录（略）

2.8.2.8 测试结果审批（略）

2.8.3 性能确认报告

文档的目的是对性能确认测试活动以及结果作出综合性的评价，性能确认目的是确认系统的用户需求已经得到满足。

2.8.3.1 测试详述

列出性能测试脚本的实例汇总，列出所有的测试脚本并已经执行完毕。

2.8.3.2 偏差记录（略）

2.8.3.3 结论

性能确认已经按照性能确认协议被完整地执行。性能确认测试脚本已经完成编制，经过审批和签署。所有的偏差已经被记录、报告、分析和处理，所有的偏差都已被关闭。

2.9 验证总结报告

2.9.1 项目概述（略）

2.9.2 验证文件清单

验证主计划（VMP）、安装确认协议（IQP）、安装确认报告（IQR）、运行确认协议（OQP）、运行确认报告（OQR）、性能确认协议（PQP）、性能确认报告（PQR）。2.9.3 人员与职责（略）

2.9.4 验证总结

验证方法依据国际制药工程协会（ISPE）的《良好自动化生产实践指南》（GAMP5）中类别软件产品（可配置软件产品）适用的V字模型。验证过程中编制的所有文档均经过审批。

2.9.5 验证主计划描述

验证主计划描述包括：（1）业务流程描述；（2）用户需求规范描述；（3）功能需求规范描述；（4）设计需求规范描述；（5）安装确认；（6）运行确认；（7）性能确认；（8）用户培训验证结果判定和结论。

3 结语

GMP附录就验证的定义可以看出，验证是计算机化系统生命周期的一个组成部分，是持续地贯穿于整个生命周期的活动，在每一阶段都需要产生验证活动，尤其进入运行阶段，从系统的变更管理活动而言，应更加注重基于风险评估的验证活动，只有如此，才能使系统永久处于可验证的良好运行状态。