计算机化系统验证标准操作规程

1.目的
描述了计算机化系统验证工作应遵从的基本程序，使计算机系统验证符合GMP的法规要求，同时使验证工作有组织、有计划的顺利进行。

2.适用范围
本规程适用于我公司药品生产质量管理过程中应用的计算机化系统。

3.职责
3.1.计算机化系统的使用部门提出需求计划。

3.2.计算机化系统的使用部门、采购供应部门、工程设备部门、IT管理员负责计算机化系
统生命周期内的所有业务。

3.3.工程设备部、中心化验室分别负责质量控制系统和生产系统计算机化系统的验证方案
及验证报告的起草及组织实施，IT管理员、使用部门及供应商提供验证支持。

3.4.质量部、质量保证室及生产部、生产车间参与验证方案、报告的审核及验证过程的实
施。

3.5.中心化验室、生产车间等使用部门负责按照要求使用、维护计算机化系统，并制定计
算机化系统的相关责任人。

3.6.计算机化系统验证实施小组，成员来自受特定影响的所有部门，应包括使用部门、IT
管理员、物料部、工程设备部、供应商（可以是商业经销商、软件开放公司、内部软件开发或以上之组合）相关人员组成。

组长由上述分工组织实施者担任，验证小组成员的职责在验证方案中具体明确。

其分工见下表：
3.7.质量负责人批准验证方案和验证报告，并在资源方面予以调配和支持。

4.定义
计算机化系统验证为应用程序（应用软件）的验证和基础架构（计算机硬件和软件）的确认。

4.1.计算机化系统：指受控系统、计算机控制系统以及人机接口的组合体系。

4.2.应用软件指针对用户的特殊需求而开发、购买或修订的程序（主程序和子程序），他
可执行数据的收集、处理、报告、存档及过程控制。

4.3.系统软件：操作系统和通用功能的一套程序。

在硬件及应用软件之间起接口的作用，
且管理计算机的使用。

4.4.基础架构：为应用计算机程序提供平台使其实现功能的一些列硬件和基础软件，如网
路软件和操作系统。

4.5.可配置软件：由供应商开发的程序（主程序和子程序），该软件可以提供通用功能，
用户可以自行设计工作程序或设定工作流程。

5.内容
5.1.计算机化系统的分类
5.1.3.依据以上分类原则，建立包含药品生产质量管理过程中涉及的所有计算机化系统清
单，清单应详细表明与药品生产质量相关的功能，见附件1，计算机化系统应当及时更新，又新增加或报废等情况应及时进行添加或删除。

5.2.计算机化系统的生命周期及管理
计算机化系统生命周期的每一个阶段，供应商与公司（客户）部门/人员应当有明确的职责，公司外部人员应当有相应的资质，公司内部人员需要参加相关的培训并经过相关资质的确认。

具体阶段分类如下：
5.2.1.计划和需求阶段：即准备阶段，功能需求的提出，功能规范的制定，如目标系统性
能规范，系统的可靠性、可维护性，系统的运行环境、系统与外部生产过程、环境
人员等的接口关系等。

5.2.2.设计阶段：系统总体描述，硬件/软件总体设计，技术途径的选择与实现。

设计的方
法采用黑箱设计法。

做出系统结构设计，体现方块之间的信号输入输出关系和功能
要求。

5.2.3.模拟与调试阶段：软件仿真模拟和硬件调试。

5.2.4.现场安装调试、确认与验证阶段：硬件、软件安装后的系统联合调试。

5.2.5.投入运行和日常硬件、软件维护阶段：适宜的变更控制、必要的再验证以及验证状
态的预防性维护、计量校准等。

5.2.
6.硬件更新与软件升级直至最后的报废。

5.3.计算机化系统的验证文件的需求
结合计算机化系统软件分类，针对计算机化系统的生命周期，确认各个类型的计算机化系统
5.4.计算机化系统的风险评估
5.4.1.每一个计算机化系统的选型或设计阶段需要充分考虑风险因素，在确认/验证阶段进
行评估，并且与人工操作的风险进行对比，风险应可接受，并在后续的确认/验证过程中跟踪风险管理。

5.4.2.在生产工艺的风险评估中，把计算机化系统的错误或失效对于这些被控关键工艺参
数的影响风险，风险应可接受。

5.4.3.除以上特殊规定外，计算机化系统的风险评估原则上按照《质量风险评估管理规程》
进行。

5.5.计算机化系统的供应商管理
供应商提供产品或服务时（如安装、配置、集成、验证、维护、数据处理等），企业应当与供应商签订正式协议，明确双方责任。

对于计算机化系统的供应商进行评估并进行分级管理，评估/审计的方式方法、范围取决于计算机化系统的风险评估程度，即对供应商分级管理，从高到低依次为“定制软件、可配置软件、非配置软件、基础设施软件”。

结合计算机化系统如阿健的分类，针对计算机化系统工艺上的等级，确认各个类型的计算机化系统需要对供应商进行评估的内容，如下：
在计算机化系统使用之前，应当对系统进行全面测试，即对计算机化系统进行全面的安装确认、运行确认及性能确认。

5.6.1.计划和需求阶段，用户应该为供应商提供详细的预期性能指标，计算机化系统和PLC
控制系统可以用来决定设计标准，内容如下：
5.6.1.1.操作要求：应该包括功能、数据、技术需求、界面、环境，可以适当的包括流程描
述或流程图：
◆功能;:计算、安全性、系统安全防护(包括访问控制等)、审计追踪等；
◆数据：数据输入和编辑、备份和恢复、存档需要、数据安全防护以及完整性；
◆技术需求;：系统运行中的变更、灾难恢复、发生故障时采取的措施、容量需求、
访问速度需求、硬件需求、效率及可配置型（登陆速度、刷新速度及生成报告的速
度等）
◆界面;相应的角色（比如三级管理）、和其他系统的接口界面和设备的接口界面（比
如传感器、执行器、定制软件建议包括含控制系统输入输出的清单）；
◆环境：布局（比如长距离连接、空间限制）、物理环境条件（温度、湿度、外部干
扰、防护、污渍、灰尘或高震动环境等）电源需求如UPS等、任何特殊的物理和
逻辑需求；
5.6.1.2.限制条件：应该对计算机化系统的限制条件做出需求说明，如兼容性、长期支持、
预期的使用寿命、可能的提高空间及扩展能力。

5.6.1.3.生命周期需求：开发需求（通过供应商的方法达到最低标准、项目管理和质量保证
的规程、特殊测试需求、测试数据、负荷测试、要求的仿真测试、工厂测试、培训
课程以及产品验收后的支持和维护）
5.6.1.4.对供应商的其他要求：如在发展进程中完成系统验证、质量控制和变更控制等。

5.6.2.设计阶段
系统的设计应该由系统配置图、硬件设计和软件设计组成。

在供应商准备的系统设计被用户评估应检验后，可配置的系统图纸设计应该完成，包括系统的PID，I/O（输入/输出的连接图、连接原理图。

5.6.2.1.硬件设计：包括所有I/O（输入/输出）连接模板和类型，CPU选型，通信模板、人
机界面控制器，屏幕查看选择、中继电器、记忆存储器、打印机、辅助动力装置，
电子部件/电线/电缆、其他元件等。

5.6.2.2.软件：包括系统软件、应用和数据。

5.6.3.安装确认阶段
确认计算机化系统及其相关的设备硬件安装，例如在控制系统中国电源线的检查、界面接口的检查等，确认安装了正确的版本的软件，并记录安装过程中任何突发的或者不符合接受标准的事件及其解决方法。

IQ阶段至少应包含不限于以下项目：
◆确认硬件的配置、软件版本;
◆确认现场安装环境、安装条件、安装结果；
◆确认系统开发的技术文件和报告（审核开发过程、而不是审核每一条程序、指令的正确
性）；
◆确认仿真模拟与调试阶段的文件与报告（形式审核与确认）。

◆确认安装后的各种测试、调试的文件、记录和报告（形式审核与确认）。

◆确认各种技术资料、变成软件、应用软件备份、密码保存等；
◆确认I/O清单、电路图、接线图及硬件和软件手册，包括安装、操作、维护保养手册；
直接（或主要间接）影响产品质量的设备/系统、用于直接影响产品放行的检验仪器、
◆IQ合格后，方可进入OQ阶段。

5.6.4.OQ阶段
OQ确认的目的是进行所有功能运行情况方面的测试以确保系统和运行符合设计标准。

系统运行确认应在一个与正常工作环境隔离的测试环境下实施，但应模拟生产/检验环境。

OQ阶段至少包含但不限于以下项目：
◆确认按照标准操作规程进行个中国操作、测试、包括系统的安全性、三级密码、操作权
限、I/O测试、人机接口、错误输入、报警、连锁、断电恢复等。

◆确认每一个正常的工作步骤，每一个操作部件（包含硬件操作部件和模拟操作部件）、
每一个I/O之间的动作关系、模拟运行的过程测试、全自动运行的过程测试确认。

◆测试系统的安全：“最坏情况”的系统逻辑应该进行测试，如使用不同权限以便确认未
经授权运行是否被禁止；系统使用部门应该在IT管理员支持下对每一个系统开发安装计划。

安全策略基于系统和系统功能的关键性。

策略决定必须基于风险评估并且应具有合理性及有关文件证明。

可以选择物理安全或逻辑安全以限制访问系统。

系统使用部门在IT管理员的帮组下决定登陆程序。

例如使用单个或不同的用户账户和密码登陆系统以及应用程序软件包。

系统使用部门应定义访问记录类型以及数据管理活动的权限。

比如，不允许访问、只读访问或读写访问，或创建和删除记录的权限。

控制访问权限的功能应该被验证；
◆测试环境：系统的测试环境应尽可能接近日常使用环境，那么测试应在一个能够反映动
态环境的测试环境下进行。

由系统使用部门在项目小组的帮组下决定采用哪种测试环境。

这种决定应基于风险评估并且合理并记录归档；
◆相同配置的系统：且使用方式相同的系统不需要对所有软件功能或所有系统进行测试。

完全相同配置和使用方式是非常重要的，这包括完全相同的计算机硬件和固件、相同的操作系统及应用软件且配置完全相同。

任何不同点都必须记录且测试每一个系统。

例如不同的客户端的IP地址不会相同，所以需要对每一个系统进行连接测试，系统的所有者在验证实施小组的帮助下决定可以不需要测试所有功能，这种决定应当基于风险分析且合理并记录归档。

◆测试的可追踪性：测试应和URS关联，一般来说一项测试对应一条标准，当然一项测
试也可以对应两条或更多条标准或者一条标准对应多个测试。

没有测试的功能的省略原因应被记录。

例如“供应商已经测试该项功能且该功能不会对用户环境造成影响”。

对于较大项目，可以采用电子文件管理系统，她的范围可以是简单的Word表格或数据库以及针对管理追踪矩阵而开发的软件；
◆根据系统的要求进行的各种各样的过程控制功能测试：“最坏情况”？（例如最大通信
承载、过程相当大的数据文件等）试验检查系统和决策程序的功能，应根据系统不同的要求和标准提供的定义（提供功能图表包括所有出现的偏差）；
◆检查报警及连锁：测序连锁应根据报警条件及系统连锁操作手册进行测试；
◆定时器和定序器测试：根据系统的操作手册设置时间和系统产生的功能以确认系统的有
效时间或程序命令；
◆测试数据的处理和记忆：
正确的数据处理和记忆，准确的数据采集和系统的自我搜索的确认：
数据处理的长度、承载和空载的确认；
数据保存到相应的文件夹的功能确认
关机/恢复测试，在系统关闭之前和之后检查数据采集情况，确保数据没有损坏或丢失，检查备用源的供应，不间断电源供应器、电力调节器和电力发动机；系统故障和失败的时候，能够根据系统的操作手册提供系统备份；
◆其他功能测试；
◆运行合格后，方可进入PQ确认阶段；
5.6.5.PQ阶段
确认系统运行过程的有效性和稳定性，应在正常生产环境下进行测试，性能确认测试项目依据对系统运行希望达到的整体效果而定（如对生产处的产品质量各项特性进行测试）。

测试应在正常生产/检验环境下（相同条件下）重复三次以上。

当一个人工系统被电脑，PLC控制系统取代时，两者需要平行运行。

如果系统是生产、检验或公共设施系统的一部分，系统的PQ必须根据设备的PQ进行完整性测试，PQ至少包含但不限于以下项目：
◆确认系统的运行过程的有效性和稳定性。

◆测试项目依据对系统运行希望达到的整体效果而定，如对生产除的产品质量各项特性进
行测试。

◆测试应该在正常生产/检验环境下，相当于随着正常生产的工艺验证过程中或正常检验
的操作验证过程进行测试。

◆其他功能测试；
◆PQ合格后，方可投入运行（使用阶段）；
5.6.6.使用阶段
验证的系统和所有相关的文件必须在变更控制和周期性回顾下进行维护，以维持系统的验证状态。

使用阶段需要执行以下流程：
◆偏差管理
◆变更控制
◆文件（标准操作过程）管理
◆周期性的回顾审核评估控制/逻辑和物理安全性
◆培训
◆备份/保存和恢复
5.6.7.报废阶段
5.6.7.1.报废阶段需要保证有计划顺序的将计算机化系统从GMP区域移除，报废时需要考
虑不再需要标准操作规程的收回与报废，关于数据等数据保存的方法的有效性与完
整性，以及保证在合适的保存期间内数据可以被查到的方法，证明保存的数据是安
全的、可查到的测试方法需要经过验证。

5.6.7.2.应起草开发关键数据迁移至新系统的计划，确认数据可以在系统上以原有的方式进
行搜索，记录归档最新配置设置，并从现存系统硬盘上删除所有数据，系统方可退
出服务。

5.7.计算机化系统的变更
每项变更申请均应经过审查（必要时协调供应商参与），应基于风险评估来确定此项变更的
可实施性，如实施此项变更应对说明，实施和审核变更所需的活动进行详细的描述，半酣变更的范围以及此项变更受影响的控制项目（如文件等），建议变更所产生的影响和是否需要进一步的风险评估，必要的验证活动以及变更失败时的支持性计划。

审查、风险评估、执行变更决定或拒绝变更决定的理由以及所要求的行为都应该形成相关记录，并且作为计算机化系统验证文件的一部分进行归档。

5.7.1.变更的分类：变更是由硬件变更和软件变更组成。

5.7.2.变更的职责划分：
5.7.2.1.计算机化系统使用部门负责起草书面申请，包括变更原因，证据，内容和实施方案，
负责变更的实施及跟踪。

5.7.2.2.质量保证室、质量部、相关部门的负责人负责变更的评估、审查。

5.7.2.3.当变更已经实施，相关文件已经修订并且经过相关验证后，变更由质量负责人批准
及终止。

5.7.3.除以上规定外，计算机化系统的变更原则按照《变更控制管理规程》进行。

5.8.计算机化系统应进行再验证以在整个生命周期里维持验证状态，再验证取决于以下几
种情形：
5.8.1.定期再验证，再验证类型和频率取决于系统的关键性和稳定性。

5.8.1.1.如果用于高关键水平的应用，则系统每年进行一次完整的再验证，测试的程序与首
次验证相同。

5.8.1.2.如果用于中等水平的应用，则系统需要对实际配置的合规性进行审核回顾，回顾方
式可以通过按照测试计划进行长期持续的确认测试以及审核文件材料进行，如果评
估结果符合可接受标准，那么再验证九不要要进行。

5.8.1.3.如果用于低水平的应用，则系统不需要进行在验证。

5.8.2.变更性再确认，由于硬件、软件或附属程序的变动引起的变更，系统的任何变更均
由风险评估决定是否进行再验证和验证的范围及程度。

5.8.2.1.系统升级到新版本后应进行在验证，新的功能或变动应进行再验证。

5.8.2.2.系统的使用部门应在供应商或IT管理员的帮助下进行再验证类型及范围的详细评
估和最终的定论，再验证的方式以及内容应该基于风险评估并且是合理的并有文件
证明的，再验证范围的可接受标准为系统的关键点和变更的类型。

5.9.计算机化系统验证文件的管理
5.9.1.验证文件的编号的要求
编号格式：AB .CS.CDE.FG
AB代表验证文件性质，为两位英文大写字母，方案为VP，报告VR
CS为验证文件类别的缩写（Computer System）
CDE代表验证文件流水号，为三位阿拉伯数字
FG代表该验证文件的版本号，首次验证为00，第一次再验证为01，第二次为02，以此类推；
5.9.2.举例说明
VP.CS.001.00为001号计算机化系统验证方案，为首次验证文件。

5.9.3.验证文件的归档
计算机化系统验证文件由质量部整理验证方案和验证原始记录，检验记录等内容，完善验证总结报告，完成后将纸质版电子版资料一并归档保存，验证文件应永久保存。

5.9.4.除以上特殊规定外，计算机化系统验证文件其余具体要求参照《验证文件的编写程
序》。

5.10.计算机化系统意外事故规划和灾难性恢复
灾难性恢复程序意外事故和灾难性恢复策略由使用部门制定，则是基于风险评估并且应是合理的并有文件证明的，应作为系统初始和后续的验证程序的一部分被验证。

5.11.计算机化系统的沟通和培训
5.11.1.计算机化系统验证的相关活动应该在公司内部进行交流和沟通，计算机化系统使用
部门和验证人员应当明确其指定分配的任务，在验证过程中，验证成果和任何成果都应相互分享，所有参与验证活动的员工都应进行培训以确保较高的验证活动的成功率，所有计算机化系统的用户应对其进行培训以确保使用计算机的人员都是由资质的并且用户有足够的知识以最高的效率方式操作计算机化系统。

5.11.2.培训的参与人员至少应包括但是不限于以下人员
系统开发人员计算机化系统的供应商
最终用户计算机化系统使用部门
IT人员
QA
内部审计人员
文件管理员
6.培训
所有部门
，。