某知名制药外企计算机化系统验证CSV管理程序.docx

某知名制药外企计算机化系统验证CSV管理程序.docx

《某知名制药外企计算机化系统验证CSV管理程序.docx》由会员分享，可在线阅读，更多相关《某知名制药外企计算机化系统验证CSV管理程序.docx（49页珍藏版）》请在冰豆网上搜索。

某知名制药外企计算机化系统验证CSV管理程序

内容目录

1目的

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

它说明了执行计算机系统验证所需要遵守的程序并且定义了所使用的一般标准。

验证的范围可能有所不同，取决于计算机系统的复杂程度和关键程度。

无论何种情况，验证必须证明计算机系统能适用于其预定的目的，在本SOP中，描述了具体的本地要求，职责与责任定义，以及详述关于CSV话题在某些领域的本地特定的注释/要求。

2范围

2.1流程范围

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

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

不在范围内的系统:

集团系统：

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

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

由第三方支持的共享基础设施不在范围之内。

然而这也必须通过供应商资质确认，供应商评估，监控和基础合同这些方式来确保其提供了合适的服务。

2.2目标受众

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

3程序

3.1通则

本程序定义了在公司内部的CS验证与运行的最低要求。

本程序与其他系统特定规程如有更严格或更细致的要求亦可使用。

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

但此类情况必须在这一系统的高级文件中记录、论证并批准，例如该系统的HLRA，URS，验证方案或管理检查清单。

3.1.1培训

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

具体系统相关的各培训任务是系统业务流程所有者的责任。

这包括确保培训材料最新，定义不同访问级别的培训需求，以及开展必要的（定期）培训。

BPO可以将任务的具体执行委托给系统管理员或工厂培训团队，但无论如何BPO仍为这些任务最终负责，并通过签署用户申请表、定期回顾/再评估表来确认。

3.1.2验证需求

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

如果一个系统被认定为GMP相关并需要验证，则可以不需要进行HLRA评估。

另一种情况是计算机系统的上级已经被书面的定义为非GMP。

例如所在的建筑已经有项目HLRA定义为非GMP用途，或计算机系统所附在的设备本身已经由QNA定义为非GMP用途。

在这种情况下，也无需生成该系统的HLRA。

3.1.3计算机化系统清单

计算机化系统清单（CSI）使用模板表单维护。

本地计算机验证委员会（CVC）负责维护CSI并至少每年更新一次。

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

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

3.1.4基于风险的途径

风险管理方法

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

∙对病人安全、产品质量和数据完整性的影响。

可参考表3-1.

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

∙供应商评估的结果

∙根据系统的范围和所支持的业务流程，额外的风险比如业务影响，HSE，数据/网络安全,数据隐私也必须进行识别和考虑，并减轻其风险。

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

表3-1风险的定义

Risks

风险

Low

低

Medium

中

High

高

对病人安全的影响

功能故障间接导致轻微的病人损害，仅当多个其他程序或者系统发生故障

严重的伤害

严重而可逆的对健康的不利影响

严重而不可逆的对健康的不利影响（完全残疾的情况）

个别对健康不利/不可逆的情形导致死亡

对产品质量的影响

对产品质量或者病人不显著的影响以及/或者此影响是受控的/可接受的

不太可能被法规提及并且不值得报告

不影响GxP

卫生当局检查观察项，例如FDA483表格观察项可能需要重要的资源或者金钱保证来改善

令人不满的卫生当局的检查结果，例如警告信，货物的扣押，召回或者更加严重的法规处罚

数据完整性

系统并不存储或加工任何GxP数据。

系统存储或加工GxP数据

系统存储或处理关键的直接影响患者安全或产品质量的GxP数据，例如系统存储产品放行相关的数据，风险应被评为“高“。

功能风险评估

功能风险评估（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部分。

除非另有声明并得到批准，电子系统中的原始数据应视为电子记录，并按照“电子记录与电子签名（ERES）”进行管理与保存。

这样的声明必须包括合适的替代技术与流程控制，以确保在任何情况下不损害GMP数据完整性。

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

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

这通常记录在系统的URS中定义。

在验证（章节3.2.3.4）中严格的ERES功能测试，参照21CFRPart11的要求进行。

对于每个数据点（例如对自动化系统中的每个工艺数值，QC系统中的每个测试方法，DMS系统中的每种文件类型），需进行完整的检查。

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

评估电子记录对于产品质量、患者安全、数据完整性的影响。

这通常在系统风险评估阶段中评估。

评估对于电子数据的风险。

这通常在系统FRA中完成。

根据识别的风险采取控制行动，并确认这些控制得到成功实施。

这些应在系统的确认活动中完成。

在运作阶段监控这些控制措施的有效性。

通过事故管理（见3.3.3）与定期回顾（见3.3.9）进行。

3.1.6计算机化系统的分类

GAMP5给出了基于硬件与软件的计算机化系统分类方案。

决定类别对于识别正确的验证方法是至关重要的。

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

表3-4硬件分级

硬件类别

ValidationApproach

验证方法

ExampleSoftware/

SystemType

软件实例/系统类型

1

标准硬件

记录识别号及供应商。

如适用，需记录安装、连接、版本、序列号、授权等内容

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

例如：

PC（个人电脑），HMI（人机界面），服务器

2

定制硬件

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

按照项目URS定制的硬件，例如专为项目加工而成的CPU（中央处理器）

表3-5软件分级

软件类别

验证方法

软件实例/系统类型

1

基础软件

记录版本（包括服务包）。

核实正确的安装。

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

例如：

Unix,Windows,Oracle,Databases,C++.Excel

3

标准软件（非配置）

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

按使用规定对标准/要求基于风险的测试。

基于固件的程序，包括非定制PLC阶梯代码在内的市售商业软件。

例如：

仪表，天平，秤，条形码扫描仪，电子表单。

4

可配置软件

对标准/要求基于风险的测试来证明应用程序按照设计工作。

存在数据管理程序

LIMS，SCADA，ERP，DCS，MES，建筑管理程序，CRM。

例如：

SAP，Relsys，Werum，Labware

5

定制开发软件

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

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

例如：

内部开发的应用程序。

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

应注意GAMP软件分类3至5并没有清晰的界限。

关键的内容应该始终是定义清所需要的验证输出/交付，来最小化对该系统所支持的业务流程的风险。

表3-6关键性矩阵

影响

软件类别

轻

中

高

1基础软件

A

A

A

3标准软件

A

A

B

4可配置软件

B

B

C

5定制开发软件

B

C

C

表3-7结果行动

严重性

供应商评估

功能风险评估（FRA）

A

在URS（或QP、CR）中记录供应商的名称并给出免于评估的理由

不需要FRA

B

至少需要一次正式的供应商评估例如邮寄/桌面审计或者一次绩效审核

FRA必须基于URS

C

必须有一次详细的供应商评估例如审计

FRA必须基于功能规范（FS）等级

3.1.7供应商评估

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

对于新系统的引进，以及系统的变更，均必须执行供应商评估。

但基于风险评估的输出（见章节3.1.4和3.1.6，表3-7），具体评估的途径可以有所不同。

∙低风险的理由可以为:

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

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

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

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

通过审核邮寄/邮件渠道收集的信息来进行审核。

一次邮寄/桌面审计至少应包括下列内容：

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

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

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

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

∙审计

对于集团系统，将执行供应商审计的申请发给集团。

基于集团合规团队的风险评估，可决定供应商是否由集团或者本地QA审计，或者不需要审计。

对于本地计算机系统，本地QA组织负责进行审计。

正式审计实施前建议先通过《供应商调查问卷_CSV》，收集供应商基本信息。

《供应商调现场审计报告_CSV》可用于支持此类此类供应商的本地审计及批准。

3.1.8利用集团业务部的资源

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

由集团发布的部署计划或本地利用合适的形式（用于实施该控制。

此流程同时作为引入系统的变更控制，由系统的本地业务流程所有者负责。

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

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

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

∙SOP的适用范围

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

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

4.集团系统检查清单

3.1.9系统文档管理

所有的文件应遵循公司SOP规定的GDP要求进行管理。

考虑到某些系统生命周期文件可能需要频繁更新，可以接受由文件负责人发布一份主文件的方式来管理微小变更，而无需对文件进行完整升版。

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

。

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

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

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

3.2验证计算机化系统

一般情况下公认的计算机系统的生命周期就是指任何可以确保系统能够按照既定的标准进行了开发，运作和报废，并且符合其预定目标的方法。

通常它由四个阶段组成,如表3-8所示：

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

∙项目阶段

∙生产/运营阶段

∙报废/停运阶段

表3-8:

一般系统生命周期

最普通的在法规环境下确保计算机系统的验证状态的方法是V-模型。

不过需要提到的是，其他开发和执行方法例如快速原型技术,瀑布式模型和螺旋式模型同样也可以符合要求并应用于适当场合。

此外，选定的方法必须为每个项目而定义并且在验证计划中证明。

任何情况下，各方法必须确保关键要求可以被追溯到相应的测试，并且法规要求的关键交付结果是按照受控的方式进行了开发和维护。

备注：

章节8的附件1：

验证GMPCS的通用流程，给出了一个计算机系统在验证时刻参考的具体流程图。

3.2.1项目生命周期内控制

配置控制

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

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

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

1.硬件:

∙计算机品牌和型号

∙计算机名称/ID

∙处理器

∙内存大小

∙磁盘大小

∙显示卡型号

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

∙额外的内部/外部设备

2.软件：

∙已安装的软件清单（名称，版本）。

∙补丁级别

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

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

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

3.网络：

∙所安装网络组件的清单：

以太网、电缆、网络协议、机柜、服务器、交换器等。

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

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

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

任何时候必须存在一个当前的计算机系统相关的配置项目清单。

配置由负责应用程序的经理进行维护，例如作为功能说明/设计说明的一部分。

配置项目只能通过按照3.2.2.2所述的变更管理程序来更改。

不改变计算机系统功能的维护和维修活动必须根据事故和故障管理程序进行登记。

变更控制

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

这些处理应在系统移交给用户前即完成。

移交之后则按照运行阶段变更管理（见3.3.2）进行。

从项目变更为运行阶段的变更控制应有明确的时间节点。

如未事先特别申明，默认使用验证报告批准的日期作为这一节点。

风险控制

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

文件控制

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

设计审查/追溯性

参见3.2.3.3之设计审查部分

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

计划

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

基于所验证系统的复杂性，可以开发一份项目计划（PP）。

此时，应在VP中引用/附上PP。

但PP本身仅供参考，且无需GMP控制（例如版本、更新、审核/批准）。

发布PP并不能替代VP中的任何内容。

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

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

规范

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

用户需求规范：

除非在VP中论述并得到批准，每个GMPCS都应生成URS。

可以接受的无需URS的论述例如：

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

功能规范、配置规范、设计规范：

如果在VP中定义为需要，则应相应生成这些文件，并在系统生命周期中维持最新。

可以接受此类文件由供应商提供并使用供应商的样式。

但此类情况下，必须在VP中申明并得到供应商评估（章节3.1.7）结果的支持，并有充分的审核/批准。

追溯矩阵：

在包括URS在内的各规范之间，必须确保可追溯性。

它提供了关键性需求和相应测试之间的映射关系。

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

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

此项目阶段的交付结果:

∙设计审查（DQ）：

根据标准和要求评估可交付成果，确定问题，并提出所需的纠正措施。

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

设计审查要求由规范的正式审查和批准，并建立可追溯性的矩阵（例如：

FRA,文件交付清单等）。

设计审查方法必须在验证计划（VP）或测试策略和计划（TSP）中定义。

设计审查也称为设计确认（DQ）。

∙代码审查：

如果软件的代码由，或专为本公司编写，则应定义代码编写的标准。

必须有书面记录的代码审查。

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

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

代码审查应在接受测试开始前进行。

对于购买的方案，公司通过供应商评估确保其在建造和编码期间有合适的控制。

∙配置文件：

软件应有配置管理和书面的版本控制。

对于可配置的系统，需在验证测试开始前建立并定义一份配置基准。

该基准应根据相应规程进行维护与更新（如适用）。

∙技术文件：

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

这份说明书是执行IQ的基础。

∙用户文件：

用户手册描述了如何使用计算机系统。

管理员手册描述了如何管理计算机系统。

∙数据迁移计划：

GMP数据载入/迁移活动应遵循预定义的流程。

载入/迁移的有效性与准确性应被确认。

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

∙系统管理流程：

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

在SOP中或者操作手册中将会描述相应的流程。

对于外部服务供应商，这些服务必须由服务合约建立。

检查（测试）

检验过程的目的是证实规范和计算机系统之间的合规性。

基于验证计划，必须定义IQ/OQ/PQ的测试案例和其下的测试方案，以及测试结果的接收标准。

必须提供测试和方案之间的追溯性。

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

如技术上可行，要使用一个测试环境来进行测试。

测试环境必须最大可能地模拟生产，且需根据其预期用途确认或验证其适用性与匹配性。

测试数据集必须充分定义以便将来重复测试之用。

最好在任何测试之前完成环境的IQ。

特别的，应考虑系统（流程）参数界限、数据界限和错误处理。

所有定义为高风险的功能应进行全面且严格的挑战测试直至失效（如适用），包括负面测试和在业务流程可能的范围之外的测试。

当无法提供一个独立的测试环境，这种情形下测试在生产环境中进行。

必须采取所有可能的防范措施来保护生产数据。

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

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

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

测试应被标示为通过或失败。

如果有测试失败，应由复核人决定应采取何种措施或追加何种测试或进行何种分析（如适用）。

这些决定应一并记录在测试项中，或单独记录但关联到相应的测试项。

此项目阶段的交付结果：

∙测试策略：

测试策略在验证范围内描述，或在单独的测试策略文档中描述，该文档由与验证计划相同的角色批准。

这包括：

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

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

-测试环境的描述；

-执行顺序（如需）：

先决条件、依赖性等；

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

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

-测试途径；

-执行指导；

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

∙测试方案：

测试方案记录了执行测试的指导。

应使用清晰准确的语言以确保目标读者（通常是测试者或复核人）可以正确理解。

测试方案可以是纸质或者电子的，但是电子方式进行记录的测试必须使用合适的工具。

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

测试方案应足够详细以便能始终一致的重复测试。

其详尽程度应与执行测试的人员/组织的经验与知识相匹配。

测试的执行和评审:

∙IQ方案：

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

如有相关的环境要求（如防止受热，受潮，灰尘或震动：

），则应记录已满足相关要求。

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

一个系统可能有几个安装确认。

要产生一份记录来创建不同的环境（例如：

开发，测试和生产）以及系统的不同组件（例如设备硬件安装，以及软件装载（如是分开的））。

测试策略定义了哪个环境需要验证。

∙OQ方案：

OQ方案是执行和文件记录系统是功能按规范运行的指导。

OQ方案可被追溯到功能规范。

通过功能性的/配置测试来挑战和其他系统的交互界面以及直接的I/O连接，并且确认在功能规范中定义的系统的功能可以在所有已经定义的操作范围内正常运作。

对于购买的有FS的系统，要追溯到URS。

对于有警报的系统，大多数的警报测试是在这个阶段。

如适用，应对备份和恢复进行测试。

∙PQ方案：

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

PQ方案可被追溯到URS。

对于小的和不大复杂的系统，OQ和PQ方案可以被合并。

测试数据组是生产数据的真实模拟。

如果系统包括警报，任何可触发警报而不能在OQ中进行测试的需要在这阶段进行。

警报测试的严格程度是基于风险的。

∙SOP:

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

∙IQ报告：

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

∙OQ报告：

OQ报告确定系统测试的功能和配置符合规范的功能和配置。

∙PQ报告：

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

∙偏差报告：

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

∙本地系统管理检查清单：

该检查清单汇总了此后日常运作阶段的基本要求及需符合的规程。

报告与放行

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

此项目阶段的交付结果：

∙培训报告：

培