计算机化系统验证(CSV)管理程序

内容目录

1目的

2范围

2.1流程范围

2.2目标受众

3程序

3.1通则

3.1.1培训

3.1.2验证需求

3.1.3计算机化系统清单

3.1.4基于风险的途径

3.1.4.1风险管理方法

3.1.4.2功能风险评估

3.1.5电了记录与电了签名（ERES）

3.1.6计算机化系统的分类

3.1.7供应商评估

3.1.8利用集团业务部的资源

3.1.9系统文档管理

3.2验证计算机化系统

3.2.1项目生命周期内控制

3.2.1.1配置控制

3.2.1.2变更控制

3.2.1.3风险控制

3.2.1.4文件控制

3.2.1.5设计审查/追溯性

3.2.2项目生命周期内通常的活动和交付

3.2.2.1计划

3.2.2.2规范

3.2.2.3搭建和配置，开发及测试代码

3.2.2.4检查（测试）

3.2.2.5报告与放行

3.2.3终端用户应用程序

3.2.4移动应用程序

3.2.5基建控制与合规

3.3验证状态的维持

3.3.1配置管理

3.3.2运作变更与放行管理

3.3.3事故与故障管理

3.3.4安全管理

3.3.4.1用户识别

3.3.4.2用户管理

3.3.5风险管理

3.3.6灾难恢复

3.3.7业务持续

3.3.8数据管理

3.3.8.1数据归档与取回

3.3.8.2数据迁移

3.3.8.3元数据要求

3.3.8.4系统/数据备份与恢复

3.3.8.5电子数据的确认

3.3.8.6数据的复核

3.3.8.7审计追踪

3.3.9系统定期回顾及再验证

3.3.10服务水平管理

3.3.11文档管理

3.3.12业务和终端用户文档

3.3.13退役

4其他信息

4.1职责

4.2单机版GMP计算机系统的管理

5缩写及定义

5.1缩写

5.2定义

6参考文件

6.1相关文件

6.2参照文件

6.3外部参照

7变更历史

7.1变更

目的

本SOP的目的是说明计算机化系统（CS）验证的主计划（VMP）及具体方法。它说明了执行计算机系

统验证所需要遵守的程序并且定义了所使用的一般标准。验证的范围可能有所不同，取决于计算机系统

的复杂程度和关键程度。无论何种情况，验证必须证明计算机系统能适用于其预定的目的，在本SOP

中，描述了具体的本地要求，职责与责任定义，以及详述关于CSV话题在某些领域的本地特定的注释/

要求。

2范围

2.1流程范围

术语“计算机化系统”（CS）指的是包括硬件、软件、网络（如适用）、控制功能和相关文件组成的系

统。

本程序适用于公司所有使用的与GMP相关以及商业关键的计算机系统的验证。

不在范围内的系统：

集团系统：公司使用的集团计算机化系统的集团验证活动不在本SOP的范围之内。这类的计算机系统

本地执行的验证活动必须由集团验证活动来协调并且减少到最少数量以避免相同功能的重复测式。

由第三方支持的共享基础设施不在范围之内。然而这也必须通过供应商资质确认，供应商评估.监控和

基础合同这些方式来确保其提供了合适的服务.

2.2目标受众

所有在公司需要执行GMP相关的计算机系统验证的工作的人员。

3程序

3.1通则

本程序定义r在公司内部的cs验证与运行的最低要求。本程序与其他系统特定规程如有更严格或更细

致的要求亦可使用。

无论如何，由于不同的计算机化系统的功能、风险和复杂程度差异巨大，可以接受一些系统不适用本规

程中的部分要求。但此类情况必须在这一系统的高级文件中记录、论证并批准，例如该系统的HLRA,

URS,验证方案或管理检查清宜。

3.1.1培训

整体来说，培训的要求按照培训标准操作规程实施。

具体系统相关的各培训任务是系统'业务流程所有者的责任。这包括确保培训材料最新，定义不同访问级

别的培训需求，以及开展必要的（定期）培训。BPO可以将任务的具体执行委托给系统管理员或工厂培

训团队，但无论如何BPO仍为这些任务最终负责，并通过签署用户申请表、定期回顾/再评估表来确

认。

3.1.2验证需求

HLRA是决定一个计算机系统是否需要为GMP或者商业关键原因而验证的基准，HLRA对于定义为非

GMP关键的系统是必须进行的。如果一个系统被认定为GMP相关并需要验证，则可以不需要进行

HLRA评估。

另一种情况是计算机系统的上级已经被书面的定义为非GMP。例如所在的建筑已经有项目HLRA定义

为非GMP用途，或计算机系统所附在的设备本身已经由QNA定义为非GMP用途。在这种情况下，也

无需生成该系统的HLRAo

3.1.3计算机化系统清单

计算机化系统清单（CSI）使用模板表单维护。本地计算机验证委员会（CVC）负责维护CSI并至少每年

更新一次。自章节3.1.3中决定的需要验证系统必须被列在相应的CSI中。

CSI中的系统应在技术变更控制流程中维护。

3.1.4基于风险的途径

3.1.4.1风险管理方法

在定义验证策略/深度/活动范围时，还应考虑下列因素

•对病人安全、产品质量和数据完整性的影响。可参考表3-1.

•在整个记录保留期内的数据、原始数据、和元数据的处理。

•供应商评估的结果

•根据系统的范围和所支持的业务流程，额外的风险比如业务影响，HSE,数据/网络安全，数据隐私

也必须进行识别和考虑，并减轻其风险。

因为一个系统通常有多种级别的各种不同的功能，会采用识别出的最高级别的风险（低/中/高）。

表3-1风险的定义

RisksLowMediumHigh

风险低中高

对病人安全功能故障间接导致轻微的严重的伤害严重而不可逆的对健康

的影响病人损害，仅当多个其他严重而可逆的对健康的不的不利影响（完全残疾

程序或者系统发生故障利影响的情况）

个别对健康不利/不可逆

的情形导致死亡

对产品质鼠对产品质鼠或者病人不显卫生当局检查观察项，例令人不满的卫生当局的

的影响著的影响以及域者此影响如FDA483表格观察项可检查结果，例如警告

是受控的/可接受的能需要重要的资源或者金信，货物的扣押，召回

不太可能被法规提及并且钱保证来改善或者更加严重的法规处

不值得报告罚

不影响GxP

RisksLowMediumHigh

风险低中高

数据完整性系统并不存储或加工任何系统存储或加工GxP数据系统存储或处理关键的

GxP数据。直接影响患者安全或产

品质量的GxP数据，例

如系统存储产品放行相

关的数据，风险应被评

为“高

3.1.4.2功能风险评估

功能风险评估（FRA）定义了测试方法和风险管理。对URS和FS定义的程序和功能进行评估。

表3-2风险优先级

可能性低高

发生的可能性实际上从没有见过故障已知的故障，已经发生过至少一次。

对于新的功能和系统而言，必须选择这

个最差情形。

检测到的可能在当前的行动中有对故障的检测或者在正仅由调查检测故障

性常的程序中由接下来的或者相平行的行动

来检测

基于表3-2,所建议的测试方法见表3-3

表3-3测试方法的定义

影响/故障结果发生的可能性没有检测到的可能性测试方法

H高H高H高Challenge挑战

H高H高L低Challenge挑战

H高L低H高Challenge挑战

H高L低L低Challenge挑战

M中H高H高Challenge挑战

M中H高L低Positive正向

M中L低H高Positive正向

M中L低L低Positive正向

L低H高H高Positive正向

L低H高L低Positive正向

L低L低H高Positive正向

L低L低L低Positive正向

None*无H高H高Positive正向

None*无H高L低Notesting不测试

None*无L低H高Notesting不测试

None*无L低L低Notesting不测试

“不影响病人安全和产品质量的功能

测试方法描述：

•高风险度的功能的挑战测试是指例如压力测试，边界测试。（业务）程序流程包括分支和所有情形

下的逻辑操作必须进行测试。

•中等风险度的功能的正向测试是指至少必须测试（业务）程序的主要流程。

•不测试•对于低风险的功能意味着不需要文件记录的测试。

•当缺少风险分析，则需要对所有的系统功能进行严格测试。

3.1.5电子记录与电子签名（ERES）

在此部分产生，存储或者处理电子记录或者利用电子签名的系统要经过验证。需要在用户需求中考虑

ERES部分。

除非另有声明并得到批准，电子系统中的原始数据应视为电子记录，并按照“电子E录与电子签名

（ERES）”进行管理与保存。这样的声明必须包括合适的替代技术与流程控制，以确保在任何情况下不

损害GMP数据完整性。

用于识别、管理和控制ERES的流程包括：

根据业务需求和相应的法规，识别系统中存在哪些法规相关的记录，签名将会存在何处。这通常记录在

系统的URS中定义。

在验证（章节3.234）中严格的ERES功能测试，参照21CFRPart11的要求进行。对于每个数据点

（例如对自动化系统中的每个工艺数值，QC系统中的每个测试方法，DMS系统中的每种文件类型），

需进行完整的检查。除非有科学的说明并得到QA的批准，通过抽样测试的数据点不能代替完整的ER

检查。

评估电子记录对于产品质量、患者安全、数据完整性的影响。这通常在系统风险评估阶段中评估。

评估对于电子数据的风险。这道常在系统FRA中完成。

根据识别的风险采取控制行动，并确认这些控制得到成功实施。这些应在系统的确认活动中完成。

在运作阶段监控这些控制措施的有效性。通过事故管理（见333）与定期回顾（见3.3.9）进行。

3.1.6计算机化系统的分类

GAMP5给出了基于硬件与软件的计算机化系统分类方案。决定类别对于识别正确的验证方法是至关重

要的。任何建议的方案与目标是否合适需要进行评估，并且在决定类别时，任何类似的应用程序使用历

史也需要考虑。

表3-4硬件分级

ExampleSoftware/

ValidationApproach

硬件类别SystemType

验证方法软件实例/系统类型

记录识别号及供应商。

1大部分从供应商处直接购买的硬

如适用，需记录安装、连接、版

标准硬件件。例如：PC（个人电脑），

本、序列号、授权等内容

HMI（人机界面），服务器

按照项目URS定制的硬件，例

2基于设计规范（DS）文件进行验

如专为项目加工而成的CPU（中

定制硬件证。

央处理器）

表3-5软件分级

软件类别验证方法软件实例/系统类型

中间设备，操作系统，统计包。

1记录版本（包括服务包）。核实

例如：

基础软件正确的安装。Unix,Windows,Oracle,

Databases,C++.Excel

基于固件的程序，包括非定制

PLC阶梯代码在内的方售商业软

3记录版本并核实正确的安装。

件。

标准软件（非配置）按使用规定对标准/要求基于风险

例如：仪表，天平，秤，条形码

的测试。

扫描仪，电子表单。

4对标准/要求基于风险的测试来证LIMS,SCADA,ERP,DCS,

可配置软件明应用程序按照设计工作。MES,建筑管理程序，CRM,

存在数据管理程序例如：SAP,Relsys,

Werum,Labware

5根据客户需要开发源代码。例

验证整个系统的生命周期过程。

定制开发软件如：内部开发的应用程序。

*以前的类别2（GAMP2）不再存在。

应注意GAMP软件分类3至5并没有清晰的界限。关键的内容应该始终是定义清所需要的验证输出/交

付，来最小化对该系统所支持的业务流程的风险。

表3-6关键性矩阵

影响轻中高

1基础软件AAA

3标准软件AAB

4可配置软件BBC

5定制开发软件BCC

表3・7结果行动

严重性供应商评估功能风险评估（FRA）

在URS（或QP、CR）中记录供应商的名称并给出免不需要FRA

A

于评估的理由

至少需要一次正式的供应商评估例如邮寄/桌面审计或FRA必须基于URS

B

者一次绩效审核

必须有一次详组的供应商评估例如审计FRA必须基于功能规范（FS）

C

等级

3.1.7供应商评估

公司应在建立合同前评估软件或系统供应商，确认其是否有合适的专业水平和资源来支持公司的业务需

求和期待。

对于新系统的引进，以及系统的变更，均必须执行供应商评估。但基于风险评估的输出（见章节3.1.4

和3.1.6,表3-7）,具体评估的途径可以有所不同。

•低风险的理由可以为：

该供应商仅提供已被定义为低风险的系统。

供应商是业界领先的公司，在世界范围广泛使用且声誉良好。

推荐使用《供应商评估初始评估_csv》表单模板，对供应商进行初始评估。

•邮寄/桌面审计/调查问卷

通过审核邮寄/邮件渠道收集的信息来进行审核。一次邮寄/桌面审计至少应包括下列内容：

公司的基本信息（名称、产品、地址等）

已有的资质/认证（例如IS09000系列）

关键流程的支持规程（例如产品开发，变更控制，售后服务）

桌面审计/调行问卷可参考《供应商调杳问卷_CSV》

•审计

对于集团系统，将执行供应商审计的申请发给集团。基于集团合规团队的风险评估，可决定供应商是否

由集团或者本地QA审计，或者不需要审计。

对于本地计算机系统，本地QA组织负责进行审计。正式审计实施前建议先通过《供应商调杳问卷

_CSV》，收集供应商基本信息。《供应商调现场审计报告_CSV》可用于支持此类此类供应商的本地审

计及批准。

3.1.8利用集团业务部的资源

在引进新的用于支持GMP流程的集团系统至本地工厂使用前，必须建立充分的控制。由集团发布的部

署计划或本地利用合适的形式：用于实施该控制。此流程同时作为引入系统的变更控制，由系统的本地

业务流程所有者负责。

在此类变更控制中，至少应涵盖下列点，可以根据业务需求和相应的风险增加更多。

1.系统描述，范围与预期交付时间；

2.检查系统生命周期文档是否已更新，例如：

•SOP的适用范围

•培训材料包括培训课程体系

3.如需，建立本地支持规程；

4.集团系统检查清单

3.1.9系统文档管理

所有的文件应遵循公司SOP规定的GDP要求进行管理。考虑到某些系统生命周期文件可能需要频繁更

新，可以接受由文件负责人发布一份主文件的方式来管理微小变更，而无需对文件进行完整升版。

主文件必须是文件已批准版本的准确复:制件•，并盖有带签名FI期的复印章。。

每当在主文件上进行修改时，必须有清晰的原因及相应的参考号（例如变更号，偏差号或ticket号）。

下列为可以不必列出参考号的特例：

在该打印错误不影响含义及标准的情况F,对已批准文件中打印错误的纠正。

3.2验证计算机化系统

一般情况下公认的计算机系统的生命周期就是指任何可以确保系统能够按照既定的标准进行r开发，运

作和报废，并且符合其预定目标的方法。通常它由四个阶段组成，如表3-8所示：

•概念阶段（即业务案例的开发，本阶段不属于验证范围内）

•项目阶段

•生产/运营阶段

•报废/停运阶段

表3-8:一般系统生命周期

p

l

B

/

p

z

s

u

o

o

Production/Retirement/

OperationDecommissioning

生产/运营报废/停运

ValidationValidatedState

验证已验证状态

最普通的在法规环境卜.确保计算机系统的验证状态的方法是V-模型。不过需要提到的是，其他开发和执

行方法例如快速原型技术，瀑布式模型和螺旋式模型同样也可以符合要求并应用于适当场合。此外，选定

的方法必须为每个项目而定义并且在验证计划中证明。任何情况下，各方法必须确保关键要求可以被追

溯到相应的测试，并且法规要求的关键交付结果是按照受控的方式进行了开发和维护。

备注:章节8的附件1：验证GMPCS的通用流程，给出了一个计算机系统在验证时刻参考的具体流程

图。

3.2.1项目生命周期内控制

3.2.1.1配置控制

配置管理包括了在计算机系统整个生命周期内的任何点，从开发的起始阶段一直到退役，对其精确定义

的必要活动。

配置项目是计算机系统的一个组成部分，不改变其正常运行的结果。

对于计算机，配置项目包括（如适用）：

1.硬件：

计算机品牌和型号

计算机名称/ID

•处理器

•内存大小

•磁盘大小

•显示卡型号

•读写设备（软盘，CD-ROM,刻录机等）

•额外的内部/外部设备

2.软件：

•己安装的软件清单（名称，版本）。

•补丁级别

•系统文件，包括手册和帮助文件

•对于软件，非标准/非默认的参数设定（例如自定义的数据采集策略，本地文件保存位置，工艺报警

设置等）。如果应用了此类手动配置，至少应在。测试中包括对设置的确认（双人复核，或提供截

图/照片）

3.网络：

•所安装网络组件的清单：以太网、电缆、网络协议、机柜、服务器、交换器等。

•网络拓扑结构图，包括具体的连接方式与采用的协议。

•每个组件的识别号，包括物理识别号与网络IP地址。

对于集团系统，要求一份显示应用当前集团架构的记录。

任何时候必须存在一个当前的计算机系统相关的配置项目清单。配置由负责应用程序的经理进行维护，

例如作为功能说明/设计说明的一部分。

配置项目只能通过按照3.222所述的变更管理程序来更改。不改变计算机系统功能的维护和维修活动

必须根据事故和故障管理程序进行登记。

3.2.1.2变更控制

应为项目阶段定义变更和配置管理的流程，其中应考虑计划性和紧急性的变更的处理。这些处理应在系

统移交给用户前即完成°移交之后则按照运行阶段变更管理（见332）进行。

从项目变更为运行阶段的变更挖制应有明确的时间节点。如未事先特别申明，默认使用验证报告批准的

日期作为这一节点。

3.2.1.3风险控制

适用表单参见本规程章节3.1.4,

3.2.1.4文件控制

适用规程参本规程章节3.1.9。

3.2.1.5设计审查/追溯性

参见3.2.3.3之设计审查部分

3.2.2项目生命周期内通常的活动和交付

3.2.2.1计划

本阶段的主要输出是HLRA（见章节3.1.2）和验证方案（VP）。

基于所验证系统的复杂性，可以开发一份项目计划（PP）。此时，应在VP中引用/附上PP。3Pp本

身仅供参考，且无需GMP控制（例如版本、更新、审核/批准）。发布PP并不能替代VP中的任何内

容。VP总是验证活动的经批准的GMP计划。

每个GMP计算机化系统的验证都需要VP.

3.2.2.2规范

基于所验证系统的复杂性，需要的规范可能包括：

用户需求规范：除非在VP中论述并得到批准，每个GMPCS都应生成URS。可以接受的无需URS的

论述例如：CS本身为简单系统且整体属于低风险，或已有类似系统而共享•份URS。

功能规范、配置规范、设计规范：如果在VP中定义为需要，则应相应生成这些文件，并在系统生命周

期中维持最新。可以接受此类文件由供应商提供并使用供应商的样式。但此类情况下，必须在VP中申

明并得到供应商讨估（章节3.1.7）结果的支持，并有充分的审核/批准。

追溯矩阵：在包括URS在内的各规范之间，必须确保可追溯性。它提供了关键性需求和相应测试之间

的映射关系。它要求在整个生命过程阶段前后映射。

3.2.2.3搭建和配置/开发及测试代码

此项目阶段的交付结果：

•设计审查（DQ）：根据标准和要求评估可交付成果，确定问题，并提出所需的纠正措施。设计审查旨

在识别和消除在以后阶段可能导致变更的问题，因此该审查在接受最终构建之前执行。设计审查要

求由规范的正式审查和批准，并建立可追溯性的矩阵（例如：FRA,文件交付清单等）。设计审查方

法必须在验证计划（VP）或测试策略和计戈IJ（TSP）中定义。设计审查也称为设计确认（DQ）。

•代码审查：如果软件的代码由，或专为本公司编写，则应定义代码编写的标准。必须有书面记录的

代码审查。代码审查由开发该方案的组织中的SME,或委托有资质的第三方进行并记录。代码审

查的范围应基于系统的类别、复杂度，以及其对产品质量、患者安全和数据完整性的风险。代码审

查应在接受测试开始前进行。对于购买的方案，公司通过供应商评估确保其在建造和编码期间有合

适的控制。

•配置文件：软件应有配置管理和书面的版本控制。对于可配置的系统，需在验证测试开始前建立并

定义一份配置基准。该基准应根据相应规程进行维护与更新（如适用）。

•技术文件：技术文件至少有安装说明书，即安装计算机系统时必须遵守的一套指导书。这份说明书

是执行IQ的基础。

•用户文件•：用户手册描述了如何使用计算机系统。管理员手册描述了如何管理计算机系统。

•数据迁移计划：GMP数据或入/迁移活动应遵循预定义的流程。载入/迁移的有效性与准确性应被确

认。如果没有在系统验证方案和报告中涵盖，应单独创建数据迁移方案与报告，其批准应与验证方

案和报告一致。

•系统管理流程：系统管理流程提供了所有运行计算机系统必须的流程（见章节3.3）。在SOP中或

者操作手册中将会描述相应的流程。对于外部服务供应商，这些服务必须由服务合约建立。

3.2.2.4检查（测试）

检验过程的目的是证实规范和计算机系统之间的合规性。基于验证计划，必须定义IQ/OQ/PQ的测试

案例和其下的测试方案，以及测试结果的接收标准。必须提供测试和方案之间的追溯性。项目经理负责

维护在项目阶段的追溯性，系统所有者负责在运作阶段的追溯性。

如技术上可行，要使用一个测试环境来进行测试。测试环境必须最大可能地模拟生产，且需根据其预期

用途确认或验证其适用性与匹配性。测试数据集必须充分定义以便将来重复测试之用。最好在任何测试

之前完成环境的IQ。

特别的，应考虑系统（流程）参数界限、数据界限和错误处理。所有定义为高风险的功能应进行全面且

严格的挑战测试直至失效（如适用），包括负面测试和在业务流程可能的范围之外的测试。

当无法提供一个独立的测试环境，这种情形下测试在生产环境中进行。必须采取所有可能的防范措施来

保护生产数据。

如适用，测试方法和测试环境的证据应在测试报告中体现与记录。

测试结果与证据应在测试执行时即刻记录，且应有足够的细节以便复核人可以独立的评估是否之到预期

的结果。

测试的人员应有记录且测试的结果应由来自业务部门的SME复核，而非由测试人自身复核。

测试应被标示为通过或失败。如果有测试失败，应由复核人决定应采取何种措施或追加何种测忒或进行

何种分析（如适用）。这些决定应一并记录在测试项中，或单独记录但关联到相应的测试项。

此项目阶段的交付结果：

•测试策略：测试策略在验证范围内描述，或在单独的测试策略文档中描述，该文档由与验证计划相

同的角色批准。这包括：

-创建、批准和执行的角色与职责；

-记录、分析和解决测试事故和测试失败的程序：

•测试环境的描述；

-执行顺序（如需）：先决条件、依赖性等；

-对供应商文件的引用（如需〉；

•用于支持或自动化测试的工具（如需）；

-测试途径：

-执行指导；

-记录测试结果的方法，如截图、日志文件、打印等。

•测试方案：测试方案记录了执行测试的指导。应使用清晰准确的语言以确保目标读者（通常是测试

者或复核人）可以正确理解。测试方案可以是纸质或者电子的，但是电子方式进行记录的测试必须

使用合适的工具。不允许使用那种无法将已经提交的测试结果进行锁定的电子工具，例如excel电

子表单。测试方案应足够详细以便能始终一致的重复测试。其详尽程度应与执行测试的人员/组织的

经验与知识相匹配。

测试的执行和评审：

IQ方案：是基于技术文件和相关的规范并提供证据证明所有的组件按照规范定义而安装。如有相关

的环境要求（如防止受热，受潮，灰尘或震动：），则应记录已满足相关要求。

文件由特别设计的方案和执行记录，供应商提供的安装记录，日志文件或者其他的成功完成的自动

安装方案的证据，或者这些的组合来组成。

一个系统可能有几个安装确认。要产生一份记录来创建不同的环境（例如：开发，测试和生产）以

及系统的不同组件（例如设备硬件安装，以及软件装载（如是分开的））。测试策略定义了哪个环

境需要验证。

•0Q方案：0Q方案是执行和文件记录系统是功能按规范运行的指导。0Q方案可被追溯到功能规

范。

通过功能性的/配置测试来挑战和其他系统的交互界面以及直接的I/O连接，并且确认在功能规范中

定义的系统的功能可以在所有已经定义的操作范围内正常运作。对于购买的有FS的系统，要追溯

到URS。对于有警报的系统，大多数的警报测试是在这个阶段。如适用，应对备份和恢复进行测

试。

•PQ方案：PQ方案是执行和文件记录系统能在用户环境卜.支持相关业务流程的指导。PQ方案可被

追溯至UURS。对于小的和不大复杂的系统，0Q和PQ方案可以被合并。

测试数据组是生产数据的真实模拟。如果系统包括警报，任何可触发警报而不能在0Q中进行测试

的需要在这阶段进行。警报测试的严格程度是基于风险的。

•SOP:除了功能测试之外，在系统放行之前必须核实系统操作和支持的SOP都已到位。

•IQ报告：IQ报告确定系统已经按照技术文件所规范的进行了安装。

•0Q报告：0Q报告确定系统测试的功能和配置符合规范的功能和配置。

•PQ报告：PQ报告确定计算机系统与其预定的目标相符可以支持用户环境下相关的业务程序。

•偏差报告：偏差报告列明了所有在测试期间产生的偏差以及它们的纠正和预防措施（CAPA）。

•本地系统管理检查清单：该检杳清单汇总了此后日常运作阶段的基本要求及需符合的规程,

3.2.2.5报告与放行

报告过程的目的是准备使用计算机系统，执行移交，放行至使用以及移交至业务和支持组织。

此项目阶段的交付结果：

•培训报告：培训报告是已进行的培训的文件证据，提供：培训者的姓名，培训日期，培训范围和内

容，参加者的姓名。

•验证报告：验证报告总结了验证活动的结果并且提供将计算机系统释放至使用，它包括八

-放行决定

-目的

-范围

•已批准的交付清单

-测试结果和未关闭的偏差

•包括任何计算机系统的局限，未关闭偏差（如适用）和跟进措施的讨论和结论。

-一个关于系统状态的明确申明，包括其是否适用于预期的用途。此申明需考虑所有已发生的偏差或

已采取的纠正性行动。

如果系统需要在报告批准之前临时放行到生产，那么要求的行动的完成期限需要文件记录在放行备忘

中，并且对于其批准的要求和验证报告一致。放行备忘中必须明确有效期。同一个系统不允许有两份以

上的放行备忘。

3.2.3终端用户应用程序

用于由最终用户处理或维护GxP数据的最终用户应用程序，例如电子表格工作簿或小型数据库，应被

验证。验证活动的水平和广度应考虑应用程序本身的风险和复朵程度，也需考虑其对产品质量、患者安

全和数据完整性的影响。应用程序的技术与流程管控也应考虑上述因子。应有书面的风险评估支持上述

行为。

对于用于创建统计用数据表的电子表格工作簿，如果其中的数据并不更新，则可视为文件管理：如果是

将其使用作为模板，则应按照相应的电子文件管理方式管理。

如果电子表格工作簿中使用了其中的计算功能用于加工GxP数据，则应有独立的复核记录，确认其使

用的正确的计算功能。此时应定义并实施包括安全管理在内的运行管控工作。应有书面的正式测试确认

应用程序复核这些要求。

相应运行管控例如安全存储、版本控制、访问控制和变更管理应有定义且被实施。

电子表格工作簿不得被作为数据库使用。

电子表单的验证及管理规程参考《表单验证规程》。

3.2.4移动应用程序

将移动应用程序作为GxP系统的一部分来使用，应在风险评估、规范定义和验证活动中考虑其特有的

风险。

如果移动应用程序的用途为诊断级别，或身体状态（例如移动医学程序），或用于治愈、缓解、治疗、

预防疾病，或用于影响人体的任何结构或功能，此类移动应用程序应视为医疗器械，并应符合相应的医

疗器械法规与标准。

其他由公司内部发布供公众使用的移动应用程序，即便其不属于医疗器械，也应按照公司产品管理，适

用公司关于产品质量的政策。此类产品的生产应按照预定的质量保证体系进行。

3.2.5基建控制与合规

基建应始终按照计划进行确认活动并根据预定的规程维持在确认状态。基建的安装应参考生产商的标准

与建议并书面记录。支持GxP引用的关键功能的组件，应进行确认，并包括适用的功能测试。其确认

应考虑上述章节3.2中的各项运行要求。

对于有第三方服务供应商提供的基建功能，本章节中定义的各项要求为此供应商的责任，而公司基建支

持人员则负责此类行为的合规性。且应通过服务水平合约确认这些要求得到满足、监控，且在有审计或

检查时，相关文件可以及时获取。

任何对公司要求的偏离应得到记录、论证，并最终被组织中负责监管基建供应商的人员批准。

系统所有者或业务流程所有者1如果不是同•个人）负责与基建支持部门确认合约基建供应服务的服务

水平符合其引用的需要。

3.3验证状态的维持

系统验证放行以后，将系统管理程序应用于维护计算机系统的已验证状态。使用系统管理检杳清单来总

结一个cs的管理要求。并应在验证报告前完成。

除非在系统专有的SOP,WP或者使用手册匕另作说明，下列的程序是必要的:

3.3.1配置管理

章节3.2.2.1中的要求应适用于GMPCS的整个生命周期

3.3.2运作变更与放行管理

变更管理是一个关键的活动，是维持计算机系统和程序的合规状态的基础。所有在计算机系统这行阶段

被提议的变更，不管是和软件，硬件，基础设施或者使用计算机系统相关的，都属于一个正式的变更控

制程序。这个程序确保了建议的变更进行了适当的审核来对执行变更的影响和风险进行了评估。这个程

序确保了变更在执行之前和后来的关闭之前进行了适当的评估，授权，记荥，测试和批准。SME评估

变更并定义变更的批准人。

变更应进行合适的测试，需考虑该变更引入的对产品质量患者安全和数据完整性的影响。

对于每个计算机系统，所适用变更管理工具都应记录在其管理清单中。

补丁管理是变更控制的一个子集并作为独立问题处理。是否及如何应用补丁必须有一个风险分析。对于

补丁的评估来说，最关注的是对公司的风险，这要在对GMP的风险之匕

如果将对系统进行变更有相关性，应确保并测试数据的可读性。

变更控制流程参照《生产设备和计算机化系统变更管理》SOP执行。

3.3.3事故与故障管理

•事故：事故是任何不属于某服务的标准操作部分的事件。事故将导致或者可能导致该服务的中断或者

服务质量的降低（例如：无法使用应用程序或者错误）。事故包括服务申请通知或者协助。

•服务申请：服务申请是事故的一个类型。在不影响系统功能的情况卜.申请某个事先确定的服务（例如：

密码重置，培训等）。实际上，服务申请按照类似事故来操作。

•故障：故障是导致一个或者更多事故的潜在位置原因。任何事故可能演化成一个故障。故障的管理

（故障解决方案）以找到根本原因结束，并且可能导致变更申请。

•已知错误/工作区：当根本原因已知晓并且确定了一个临时的二作区或者7K久转变，一个故障将变成已

知错误。

•变更申请：变更申请是申请配置项目的变更。

•事故管理：记录和监控事故的进度。目的是尽可能快速的恢复服务，并且将对业务的负面影响最小化。

•故障管理：确定（重复发生的）事件或者故障的实际原因。之后设计出最终解决故障的方案。故障管理

不和用户接触。目标是通过研究原因维持系统稳定性。

如果发生了关键事故（即，直接影响了产品质量或患者安全，或GMP数据的数据完整性无法保障），

则应发起偏差并按照（偏差处理流程）处理。

3.3.4安全管理

计算机系统和数据必须得到充分的保护以防止有意/以外的丢失，损坏或者未经授权的变更。计算机系统

的安全管理应遵循集团的统一指导。

只要可能，无论什么时候每个系统应当有三级安全保护：

•物理进入系统硬件：系统必须有物理保护以防止外部影响和盗窃（例如通过钢缆锁）。使用开

机密码也可以阻止直接进入计算机BIOS.,

•本地进入操作系统：必须有一个特有用户识别保护进入操作系统。如果可能，在一段定义时间

的不操作状态之后（例如10分钟之后）自动激活一个有密码保护的屏幕保护程序。

•本地进入应用程序：进入GMP相关的应用程序必须由一个特有用户识别保护。也可参见错误！

未找到引用源。。

•非公司系统连接到公司网络，以及通过调制解调器，传真等里连接到互联网是不允许的。在需

要例外的情况下，必须向本地IT负责人提交申请，他将审核并确保该申请与集团相关政策/规程

的符合。

对于不能进行电子登入控制的CS,必须使用日志记录，至少包括如下的信息：

•用户识别（例如姓名，用户ID）

•进入时间（日期和时间）

•执行的动作

•用户签字和日期

3.3.4.1用户识别

进入系统，操作系统和应用程序必须由特定用户识别来保护。最少由两个部分组成（例如用户ID和密

码）。密码必须符合“高质量密码”的要求，要求包括如下：

1.密码、密码短语和口令应该不容易被识破或猜中；

2.普通和共享帐户的密码长度至少为8个字符：

3.技术和管理员帐户的密码长度推荐至少为15个字符：

4.密码和密码短语至少应该包含以下四组字符中的三组：

•大写字符

•小写字符

•数字字符

•非字母数字字符,如~!@#$%人&*_-+='|\（）｛出:；"'<>,.?/

3.3.4.2用户管理

根据用户在系统里的职责角色向其提供登入权限。这个系统应当至少区别下列两种用户登入权限：

•管理员：管理员拥有所有登入系统的权限

•用户：用户只有能够执行他的任务的权限

有潜在的可能修改GMP数据的用户不可以在同一系统拥有系统管理员/配置权限。

对于本地系统，每个用户组的权限配置应有记录。对于这一配置的任何变动应遵循相应的变更及制程

序。

如果在技术上无法避免使用集体帐号，则必须在系统的SOP里定义如何对集体帐号进行管理和控制。

如为集体帐号，其密码更新策略应在系统与状态清档中记录并得到QA的批准。

必须通过文件记录用户的登记和用户登入权限的分配，并且必须由系统的业务流程所有者进行枇准。

分配用户登入权限的先决条件是完成所需的培训。所有个人使用和管理计算机系统都需要足够的培训。

对于由于离职、转岗、轮岗等情况需要调整访问的用户，凡其可能在公司的GMP系统中有权限的（例

如雇员、实习生、第三方合作伙伴等），其权限应被合适的变更/失效/删除。每个系统负责人i或其指

定的系统管理员）负责在收到通知/申请后及时处理账号。QA负责总览整个流程。

该流程同样推荐用于人员长期伏假等情况（对于离岗超过六个月的员工，其在相关系统内的账号需失

活）。

账户的失效/删除/冻结等行为，可能是系统自动功能或离职转岗等情况卜人工操作所形成的。由于此类

行为的风险很低，不要求填写相应的申请表单，由系统管理员负责。

3.3.5风险管理

对于风险的管理，见章节3.1.4,

3.3.6灾难恢复

每个GMPCS都需要定义灾难恢复。此类恢豆一般通过重新搭建运行环境实现，例如从重启，到重新

安装。恢复需要记录（例如在事故日志）中，如为重新安装还需要有变更控制。如果恢复活动导致产品

质量、患者安全或GMP数据完整性受到负面影响，则必须发起偏差。如果仅非GMP（例如系统技术信

息，或非产品相关信息）数据完整性受到影响，可以通过质量未遂事件记录并由QA批准。QA在批准

未遂事件时，可能基于对GMP合规的影响而要求发起偏差。

任何灾难恢复的活动必须进行登记（例如使用事故日志）。

3.3.7业务持续

必须建立业务持续计划，定义故障之后如何继续业务和处理数据。它也需要定义在中断之后恢复业务流

程所需要的步骤以及如何管理中断期间产生的数据。业务持续计划可以是一个独立的文件或者规程，在

SOP,工作指导或者操作手册当中进行描述。对于没有专门的业务持续计划的CS,则原由该系统支持

的业务流程将暂缓，直至系统恢复（见章节3.3.6）。

任何业务持续的活动必须进行登记（例如使用事故日志）。

3.3.8数据管理

对于ERES的管理，见章节3.1.6。

3.3.8.1数据归档与取回

系统停运前或因系统储存空间限制，需要决定数据在要求的保留期间如何管理。对于退役系统.如果数

据有迁移则数据不需存档，数据迁移按照3.3.8.2执行。对于系统储存空间限制及退役带来的数据归

档，则需要在其定义的保留期内执行定期的数据取回测试，定期监控的适用性及监控周期需在各区域的

系统维护规程中进行描述。这些内容可在3.3.9定义相应级别的回顾中完成。

除了完全可加工数据，任何选择的方案都基于成文的风险评估。当存档的数据达到保留期限，数据所有

者决定是否摧毁它们或者延长俣留期限。延长保留期要有成文£勺证明和理由。

必须在系统文件或者SOP,WP或操作手册里描述GMP相关数据的归档。当数据从•个电子格式转换

到另一个时，需要确认/验证的程序来确保数据进行了完整和准确地转换，并且所有例外情形都进行了适

当的审核和纠正。

3.3.8.2数据迁移

数据迁移遵照预先制定的计划并且包括确保数据迁移的精确度和完整性的测试。基于风险，可以使用但

不限于这些测试手段：对比数据/文件大小、对比文件名称、对比文件的元数据、使用统计方法例如

AQL（可接受质量限度）对迁移的数据采样、完整性测试、兼容性测试等。

以下情况要进行数据迁移的计划：

•将一个应用程序或者其数据转移到一个新的数据库平台

•作为计算机系统升级的一部分转换数据（软件或者硬件）

•根据业务需要改变GMP数据的存储位置（例如由于需要进行升级/变更而临时将运作数据移动

至其他媒介而事后移回，或进行媒介刷新）

•重新将已有的计算机系统功能作为另一个全新计算机系统的主机

书面的计划要求是基于风险的，考虑到数据的重要度和敏感度以及转换的技术风险。文件中包括迁移结

果的简要总结。

所有需要提供对存档数据存取的应用软件，系统软件和文件必须连同数据一起存档。存取数据文件的方

法必须说明。这些方法包括了：

•将退役的应用程序恢复到运行环境。

•保留退役软件的子集用于恢复该软件。

•做出规定能够使第三方供应商有权使用已退役或者相当的机器型号。

•开发存取数据的另一个工具。

特定系统的选项记录在退役计划中。

在存档不是由另一个已验证的系统完成时，至少需要保留两份采用不同类型介质的副本（参考

3.3.8.5）o

3.3.8.3元数据要求

元数据是指“关于数据的数据”。该术语在CSV的场合中有两种情况。结构性元数据是关于数据结构本身

的设计和标准定义；而描述性元数据是关于每个数据本身内容。

结构性元数据通过系统验证的过程管理并通过每次的变更控制维护。

描述性元数据（例如审计追踪）对数据的产生和意义给出更全面的理解。在日常运作中此类数据对于用

户可能不是明显可见的。如果系统有电子数据审核功能，相适用的元数据应有回顾程序。元数据回顾的

要求应在系统管理清单及相应的系统管理规程（如适用）中说明。

3.3.8.4系统/数据备份与恢复

必须建立程序来确保软件，记录和数据的备份副本的建立，维护并且能在一段规定的时期中在安全可靠

的区域内进行保管。必须建立并测试恢复的程序，测试结果必须存档。如果由第三方来管理备分，则需

要评估证明这些程序的存在。

有两种类型的备份：

•系统备份：通过备份系统，可在系统故障或者灾难性血溃后一段时间及时恢复系统（灾难恢

复）。

系统备份必须在移交给运营之前完成，在对系统进行变更之后，并且定期更新数据存储的介质。

如果可以确保在系统故障或者灾难性崩溃之后可以使用验证/确认文件在可接受时间内对系统完全恢

复，那么可以不需要系统备份。

•数据备份：实际应用程序数据的备份。

数据备份必须定期执行，或者由事件驱动（例如：对系统执行变更之前）。至少需要保留之前两个

版本的备份。

如果系统备份也包括r数据并且定期进行，那么数据备份也可以包含在系统备份中。

必须将备份保存在安全的环境：例如防止水，火，丢失，盗窃；。建议和系统一起保存一份备分，另一

份备份保存在另一个安全的建筑中。

建立备份，存取备份和恢复必须进行登记。

备份数据的完整性和准确性，以及数据和无数据的可恢复性应定期监控。定期监控的适用性及监控周期

需在各区域的系统维护规程中进行描述。这些内容可在3.3.9定义相应级别的回顾中完成。

3.3.8.5电子数据的确认

1.确认活动的过程数据记录原则

1）两个或以上计算机化系统采集同一数据源时（例如工艺温度、压力、流量、PH值等同时被PCS和

PI记录），其中一个自动化系统的数据记录作为确认活动的主数据记录，其余作为确认活动的参考数据

记录;

2）主数据记录作为确认活动的数据记录依据；

3）数据•致性的确认方法基于对系统的评估进行定义，并在测试方案中进行描述；

4）确认活动的主数据记录与参考数据记录的偏差的绝对值必须小于等于偏差限值；

5）偏差限值的评估由相关计算机化系统的专业人员、自动化工程师、系统最终用户、QA共同参与。

2.超出偏差限值的处理方案确认活动的主数据记录与参考数据记录的偏差的绝对值大于偏差限值时，

需要针对两个计算机化系统做根本原因调查，例如检查仪表回路、信号屏蔽保护、通讯参数、计算

机化系统中过程数据的参数检查（地址、量程、数据记录功能参数等），在根本原因调查结束并纠

正后，应对数据一致性重新进行确认。

3.3.8.6数据的复核

系统的使用部门作为数据所有者部门，需负责数据得到有效、充分的复核。这一概念应在系统设计阶段

即予以考虑，并在贯穿在确认活动中。

数据复核的范围和程度应基于该数据的对产品质量/患者安全的风险。数据和元数据（包括审计追踪）都

是需要考虑的范围。以下列出了一些参考问题可用于辅助评估：

•该系统中包括哪些受法规约束的数据？

•这些受法规约束的数据，具对产品质量和患者安全的影响是什么？

•从系统层面，数据复核对应的风险是什么？

•数据是如何被记录的，从哪里、何时开始？

•终端用户（如操作员、分析员）是否有权限对过程参数/配方/方法进行修改？

•除了要最终报告的数据（例如含量），过程中还生成了什么数据（例如系统适用性）？

•这些数据是如何关联在一起的，又是如何相互可追溯的？

•数据是否可以被删除？如果可以，谁可以，如何记录？

•是否配备了审计追踪并已启用，谁可以看到审计追踪？

•系统之间的数据传输是如何进行的？

•如果是白动，是否已经验证

•如果是手动，是否有