本文件提供了制药机械(设备)计算机化系统验证的指南，内容包括总则、验证流程、系统验证方案、人员培训和验证文档管理。
本文件适用于制药机械(设备)计算机化系统的验证,药品生产企业、制药装备的生产企业、第三方验证机构均可参照使用。
2规范性引用文件
本文件没有规范性引用文件。
3术语和定义
下列术语和定义适用于本文件：
3.1
制药机械pharmaceuticalmachinery
3.2
制药机械(设备)计算机化系统computerizedsystemofpharmaceuticalmachinery(equipment)
由一系列硬件和软件组成,以满足制药机械(设备)在药品生产质量管理过程中特定功能的系统。注:以下简称系统。
3.3
验证报告validationreport
3.4
电子签名electronicsignatures
电子数据中以电子形式所含、所附用于识别签名人身份并表明签名人认可其中内容的数据。
3.5
电子数据electronicdata
以电子、光学、磁或者类似手段生成、发送、接收或者储存的信息。
3.6
系统的全生命周期lifecycleofsystem
计算机化系统从提出用户需求到终止使用的过程。
注:系统的全生命周期包括设计、设定标准、编程、测试、安装、运行、维护等阶段，以下简称生命周期。
4总则
4.1基本目的
4.1.1证明系统符合《药品生产质量管理规范(2010年修订))第七章的规定。
4.1.2证明系统符合《药品生产质量管理规范(2010年修)》附录和附录2的规定，以及用户需求，达到规定的系统效果。
4.1.3证明系统符合设计和药品生产质量要求。
4.1.4证明系统具有完整性、成熟性、稳定性、容错性以及易恢复性功能。
4.1.5证明系统数据的完整性、真实性和可追溯性。
4.2验证原则
4.2.1系统验证根据《药品生产质量管理规范(2010年修订)》、制药设备产品标准、用户需求标准等要求制定验证方案，验证的每个阶段都有各自的验证方案。
4.2.3系统验证分为系统立项,系统实施、系统运行，系统退役等阶段。
4.2.4系统验证方案按照预先确定并批准的方案实施，并有记录。
4.2.5系统验证工作完成后，官写出确认或验证报告，并经审核、批准。当验证结果不符合预先设定的可接受标准时，需进行记录并分析原因。验证结果和结论(包括评价和建议)宜有记录并存档。
4.2.6系统验证活动宜能真实体现实际情况，数据不宜增加、删除、修改，宜保持完整性。
4.2.7系统验证活动可通过责任划分记录标识和过程监督等方式满足追潮性要求。
4.2.8在系统验证活动的生命周期实施风险分析及评估并实时监控风险，以实现全面、动态的管理，隆低风险的不利影响。
4.3系统软、硬件分类
系统软件分类见表1.系统硬件分类见表2。
5验证流程
5.1概述
系统的验证程序依次是系统立项、系统实施、系统运行、系统退役。在系统宅施各确认阶段，均需形成阶段性验证报告;当出现关键性能偏差(如影响设备正常运行、安全及产品质量)时不宜进行下阶段的确认。验证程序参考GB/T28671-2012中4.3的要求执行。
5.2系统影响性评估
项目星期官进行初步的系统影响性评估，相据系结是否对药品的质量参数有吉接的影响，将系统分类为直接影响系统、间接影响系统和无影响系统。如有影响宜在设计、调试、确认和验证过程中,执行符合《药品生产质量管理规范(2010年修订)》的计算机化系统验证。
5.3风险评估
5.31风险识别
5.3.2风险分析
5.3.2.1概述
针对不同的风险项目可选择不同的风险评估工具或方法。宜通过定性或定量地评估确定风险的可能性、易发现程度和严重性。风险评估的结果可以表示为总体的风险值，例如:定量的表示为具体的数字,如1.2.3:或定性的表示为风险的范围，如高、中、低。
5.3.2.2常用的风险分析方法
常用的风险分析方法包括:
a)一般的常用统计工具:用于收集或组织数据、构建项目管理等，如流程图、图形分析、鱼骨图、检查列表等;
b)风险排列和过滤(RRF)，将风险因素进行排列和比较，对每种风险因素微多重的定量和定性评价.权衡因素并确定风险得分；
c)先危害分析(PHA);用于在事情发生前应用经验和知识对危害和失败进行分析，以确定将
来可能发生的危害或失败；
d)危害分析及主要控制点(HACCP);可用于保证产品质量、可靠性和安全性，是一个系统的、前瞻的、预防性的工具;
e)过失树分析(FTA):鉴别假设可能会发生过失的原因分析方法;FTA结合过失产生原因的多
种可能假设，基干对过程的认识做出正确的判断;
失败模式效果分析(FMEA);评估潜在的失败模式和因此对产品性能或结果产生的影响，具体方法可以给出相应数值，如工、。其发生概率采用客观概率估计，即根据历史数据或大量的试验来推定其概率;根据风险的易发现程度来确定风险的优先级，并给出相应数值;根据风险事件对产品质量最终的影响程度进行划分，并给出其相应的数值;将以上三种分数相乘，即可得出总体风险分数,最终根据总体风险分数将所有风险归类划分;以失败模式效果分析法的风险分析示例可参考附录A。
5.3.3风险评价
根据系统风险分析等级采取适当控制措施，在引入风险控制措施后，重新进行风险评价，以确定能够使风险等级降低到预期标准以下且不会引人新的风险。风险管理过程中宜编制风险追踪矩阵，参见表3,确保能够准确、全面地反映整个风险管理过程。
5.4系统验证活动简述
可按照软件系统类别，对照不同验证阶段，并参照表4组织验证活动。
6系统验证方案
6.1系统验证模型
在进行系统验证时宜遵循生命周期V模型(参照GAMP5良好自动化生产宅践指南)根据表4组织具体验证活动。在整个脸证活动过程执行风险评估，并采用适宜手段管理整个风险过程。
6.2系统立项
系统立项的活动主要收决干验证方提出并确认系统启动的方案，并开展可行性分析，通常，在这个阶段提出初始需求并考虑可能的解决方案，通过对系统验证范围，成本和收益的机步评估决定是否需要进入系统实施阶段。
6.3系统实施
6.3.1计划阶段
6.3.1.1制定验证计划
验证计划宜包含系统描述、法律法规、验证的组织结构及职责分配、验证方案、验证的范围和技术要求，以及项目交付物等文件。
6.3.1.2制定实施计划
6.3.1.3开展供应商评估
6.3.2设计阶段
6.3.2.1用户需求说明(URS)
在合理范围内满足用户需求，比如硬件设备的型号、品牌，软件系统功能、数据追溯、数据存储备份、电子签名以及报警触发机制和处理方式等内容。宜通过需求追溯矩阵确认其是否满足用户需求。
6.3.2.2系统设计说明
63.2.2.1功能说明(FS)
功能说明是描述设备的性能和技术参数，主要内容宜包括:a)设备设计参考标准;b)主要硬件配置和软件配置列表及功能描述;c)控制系统输入/输出功能设计说明;d)控制系统的报警功能设计说明e)控制系统的联锁功能;f)设备操作功能描述。
63.2.2.2硬件设计说明(HDS)
a)硬件说明:说明系统包含的硬件设备，提供系统控制模型和电器硬件清单以及PLC和温度压力传感器等模块的技术参数；
b)硬件工作环境要求:说明硬件工作的环境要求，包括温度、湿度以及辐射和电磁干扰范围等；
c)电力供应说明:说明正常运行所需要的电力要求;
6.3.2.2.3软件设计说明(SDS)
a)系统模块程序设计:系统的功能设计，断电恢复功能、程序流程描述以及遵循的开发标准;
b)报警联锁设计:提供系统报警清单，并对报警触发的条件进行说明，以及当报警触发时需要进行的操作;
c)系统权限设计:说明系统的权限设计和划分，以及对应权限的人员可以进行的操作;
d)系统电子数据生成和管理:对系统运行所产生的电子数据存储路径、存储格式、存储介质进行说明,数据迁移备份需要进行何种操作，采取何种方法来确保电子数据的完整性等。
6.3.3测试阶段
63.31源代码编程/测试
源代码编程宜以用户需求规范为基准，确保实现的功能与预期结果一致。宜提供代码开发标准文件、说明测试方法，进行单元测试、集成测试，不断进行回归测试等。
6.3.3.2工厂验收测试(FAT)
6.3.3.3现场验收测试(SAT)
a)系统软件版本记录:确认并记录控制系统软件版本号，便于软件版本控制，当系统遇到宕机等情况可进行系统恢复，测试过程需注意1)检查设备的标识是否与要求一致;2)检查软件版本，并进行记录;3)在测试中发现问题，记录问题，形成文档;4)如果达到可接受标准，记录测试通过。
1)测试按钮或者开关，或者是制定场景满足一定条件检测相应点位，确认PI.C显示正确的输入、输出结果;2)用模拟量测试仪器进行模拟量测试，输出结果需在误差允许范围内;3)在测试中发现问题，记录问题，形成文档;4)如果达到可接受标准，记录测试通过。
c)软件功能确认:对系统功能逐一确认，是否符合用户需求规范。测试过程中需注意:1)点击每一个设定的画面功能,确认弹出正确的设定画面和实际结果;2)在测试中发现问题，记录问题，形成文档:3)如果达到可接受标准，记录测试通过。
d)报警联锁测试:对系统设定的报警逐一测试并记录，确认报警和联锁能否正常触发。测试过程中需注意:1)根据报警联锁清单,模拟现场程序达到报警条件,确认报警和联锁控制是否正确产生，如有必要可把报警测试历史数据附在文档后:2)测试中发现问题，记录问题，形成文档;3)如果达到可接受标准。记录测试通过。
f)最后制定验收测试总结报告，对测试结果进行分析，报告需适当的解决验证中发现的问题。
6.3.4确认阶段
6.3.4.1设计确认(DO)
a)确认硬件设计说明(HDS)和软件设计说明(SDS)是否已完成;
b)确认系统功能设计是否符合用户需求说明(URS)，比较用户需求说明(URS)与设计文件，检查系统是否满足要求，若不满足要求且无其他明确规定，可以与供应商协商解决。
设计确认完成后,制定设计确认总结报告，总结设计确认测试结果是否已达到验收标准，对于不能满足的项目进行偏差处理。
6.3.4.2安装确认(IQ)
a)测试前提条件确认:确认安装确认的前提条件已满足，并且软件的版本已根据批准的配置管理文件进行版本控制;
b)硬件设备品牌、型号、数量和安装位置确认:根据硬件清单逐一确认，确认是否已经正确安装:
c)软件组态安装版本和位置确认:根据供应商提供的组态软件版本进行确认，方便后期系统升级维护和故障的处理;
d)在测试中发现问题，记录问题，形成文档;e)如果达到可接受标准，记录测试通过;
f)最后制定安装确认总结报告，对安装确认过程中的结果进行分析，对应不满足批准的测试项目进行汇总并给出处理结果，安装确认总结报告需经审核和批准后才能进行下一阶段测试
6.3.4.3运行确认(Q)
旨在确认系统功能是否符合预期要求，能在预期范围内正常运行并可正确执行相应的操作，确认内容宜包含以下内容:
a)软件版本记录:便于系统版本控制；
6.3.4.4性能确认(PQ)
旨在确认系统运行过程的可控性、稳定性和有效性是否满足标准要求。性能确认方案可从以下几方面开展验证活动:
a)负裁运行条件下,对药品生产过程及设备要求的适应性；
b)生产能力;
d)运行结果的重复性;
e)控制精度准确性;
f)安全性能;
g)负载运行的可靠性试验;h)其他所需的挑战性试验:
i)也可参考GB/T28671-2012中44的内容进行。
6.4系统运行
6.4.1问题报告
系统使用过程中出现对产品质量或数据完整性等产生影响的事件，宜评估事件的影响，并根据情况制定处理方法。对问题进行记录，编制问题报告。
6.4.2变更控制
变重管理是保持系统和流程合规的基础。变事申请宜经过审查，基于风险评估来确定变重的可家旅性、变更的范围以及变更的影响。
实施和审核变更所需的活动进行详细的描述，变更产生的影响需考虑是否进一步风险评估。
6.4.3系统管理
系统正式使用后宜对系统进行合理管理,以确保设备可正常持续运行，宜包含以下内容:
6.5退役阶段
该阶段决定是否保留记录、迁移或销毁，并对该过程进行管理，包含以下内容:
a)制定役计划，一日不再需要系统或其组件时，系统或组件按照已建立经批准的程序退役:批
准的规程包括变更控制程序和正式的退役计划:
b)记录保存:尽管退役，仍需保持在整个所要求的记录保存期间，确保记录的可读性，并保持原电子记录的内容和含义;
c)制定退役报告:退役活动的结果，包括数据和系统的可追溯性，宜呈现在报告中。
7人员培训
a)确定必要的培训需求，制定培训方案，按需求提供培训;
b)评估培训的有效性;
d)进行适当的培训记录;
e)确保培训是最新的。
8验证文档管理
8.1验证文档基本内容
验证文档内容可参照GB/T28671-2012中4.4.2、4.4.3、4.4.4的要求。
8.2文档编号
文档编号是系统唯一文件名的标识，宜制定文档编号规则，并按照规则进行编号。
8.3版本控制
列举的项目文档和图纸按照标准操作程序进行版本控制。任何发布的受控文档的版本号宜具备唯一的标识，受控文档的版本说明参见表5。
8.4.1存档
验证文档需以电子版或纸质版存档，宜有明确的存档位置，验证文档清单可参见附录B
8.4.2管理
宜安排专人负责验证文档的编写、修改、发布、保存和归档。
附录A
(资料性)
风险评估示例
A.1风险评估工具
A11风险等级值(RPN)评估原则
风险等级值(RPN)评估原则三个数值各自独立发生。
A.1.2风险等级值(RPN)计算公式
风险等级值(RPN)按公式(A.1)计算。
A.1.3发生概率(O)
发生概率的评估值选取见表A.1
A.1.4易发现程度(D)
易发现程度的评估值选取见表A.2。
A.1.5影响程度(1)
影响程度的评估值选取见表A.3。
表A.3影响程度(1)的评估值
A.2风险等级值(RPN)评估
A.2.1风险严重等级值参考表A.4确定。
A.2.2风险等级值参考表A.5确定。
A.2.3风险等级值(RPN)在1~27之间，依据风险等级值将风险划分为低风险、中风险、高风险，具体如下:
A.3关于风险评估的说明
A.3.1分析潜在风险源后，如果出现中高风险，在通过控制措施后根据计算的风险等级值(RPN)确认是否降到低风险。