简介这份资源是一套面向制药企业QA、设备工程、IT及验证相关岗位的GMP计算机化系统验证管理规程文档适用于物料控制、实验室设备、生产工艺及公用设施等与GMP相关的计算机控制系统验证场景帮助读者建立从用户需求到系统验收的全生命周期验证思路。压缩包内共1个doc文件约230KB内容涵盖验证目的与范围、各职能部门职责划分、验证小组组成、软硬件分类及对应验证方法、验证清单与实施流程等模块并附有验证流程图与风险评估步骤说明。目前已有56人学习下载。读者可据此了解质量保证部、使用部门、物料部与工程部信息管理岗在验证中的具体分工掌握基础软件、非配置软件、可配置软件与用户定制软件的分类逻辑及差异化验证策略同时获取URS、DQ、IQ、OQ、PQ等环节的执行要点为实际验证方案编制与偏差变更管理提供可参照的规程模板。1. 一份 19 页的验证规程为什么值得制药 IT 和 QA 反复翻如果你在制药、生物制品或者医疗器械行业做 IT、QA、设备工程大概率听过这句话“这个系统要不要做计算机化系统验证”每次项目立项、设备采购、系统上线这个问题都会被重新翻出来吵一遍。吵到最后往往不是技术问题而是没人能拿出一份说得清“什么系统该验、验到什么程度、谁签字负责”的规程。这份《GMP认证计算机化系统验证管理规程》就是干这个的。它把与 GMP 相关的计算机控制系统从用户需求、风险评估、供应商评估、设计确认、安装确认、运行确认、性能确认一直到系统引退和回顾验证整条生命周期串成了一条可执行的流程。适用对象包括物料控制、实验室设备、生产工艺控制、公用设施控制这几类系统PLC、SCADA、LIMS、ERP 都在射程内。它适合三类人一是制药企业里被拉进验证小组的 IT 和工程人员需要知道自己在 URS、IQ、OQ 各阶段到底要交什么二是 QA需要一套能落地的分类和分级判断依据三是做 GMP 合规咨询或者准备供应商审计的人需要一份能对照检查的清单。下面我按“怎么用”的顺序把这份规程拆开讲。2. 软硬件分类与验证清单先搞清楚你的系统该验到什么程度2.1 GAMP 五类软件分类的实操判断规程里最核心的一张底牌是引用了 GAMP5 的软件分类逻辑。它不是让你背概念而是直接决定验证工作量和文件范围。分类依据是三个维度风险性、复杂性、创新性。落到实操上我一般按下面这个顺序问自己这个软件是市售成品还是为你们定制的能不能配置配置程度有多深有没有自定义代码或者宏按规程的划分软件分五类。第 I 类是基础软件比如操作系统、数据库引擎、中间件验证方式就是确认名称、版本号按批准的安装规程确认安装正确。第 III 类是非配置软件比如基于中间件的应用程序、COTS 软件、仪表仪器这类只能用默认配置验证方式是简化生命周期记录版本号、确认安装、基于风险做供应商评估、基于风险测试。第 IV 类是可配置软件比如 ERP、LIMS、SCADA、DCS、CDS这类能配置业务流程验证要走完整生命周期供应商评估要证明其有质量控制体系还要做基于风险的测试。第 V 类是用户定制软件包括定制梯级逻辑、定制固件、带宏的电子表格这类要贯穿整个生命周期的文档资料供应商评估审计更严格。这里有个血泪经验很多团队把“可配置”和“定制”混为一谈。一个 LIMS 如果只是改改字段标签、配配工作流那是第 IV 类但如果供应商给你们写了一段专用接口代码那部分模块就要按第 V 类处理。规程里专门写了一句“部分结构较复杂的计算机控制系统不能简单的划分为某一类应根据其每一个模块开发程度进行分类”这句话是整份文件里最容易被忽略、但审计时最容易被抓的点。硬件分类相对简单分标准硬件和客户定制组件。标准硬件就是市售的 PC、打印机、条码扫描仪、PLC、服务器、网络硬件验证方式是记录厂家、序列号、版本号做 IQ 安装确认适用配置管理和变更控制。客户定制组件是按用户需求特殊设计生产的硬件要做设计说明 DS、验收测试基于风险对供应商审计。2.2 验证清单表怎么读、怎么用规程里有一张“计算机验证清单”表横轴是软件分类 I、III、IV、V 和硬件分类 I、II纵轴是 URS、DQ、风险评估、供应商选择和评估、FAT、IQ、OQ、PQ、回顾验证、系统引退报告。打勾的格子代表该类系统需要做这项验证活动。我把它翻译成一句人话基础软件I 类只需要做 URS、IQ、回顾验证和引退报告非配置软件III 类在 I 类基础上增加风险评估、供应商评估、OQ、PQ可配置软件IV 类几乎全做包括 DQ、FAT定制软件V 类也是全做而且文档要求更严。硬件方面标准硬件I 类做 URS 之外的 IQ、回顾验证、引退定制硬件II 类要做 DQ、风险评估、供应商评估、IQ、回顾验证、引退。注意表里 URS 那一行软件 I 类打勾硬件 I 类和 II 类都是叉。这意味着标准硬件不需要单独写用户需求但定制硬件需要。这个细节在写验证方案时经常被搞反。提示这张表是“可以省略、合并并根据具体设备或系统进行适当调整”的。也就是说它不是死规矩但任何省略和合并都要在方案里写清楚理由。审计员不会因为你省略了某项而开缺陷但会因为你说不清为什么省略而开缺陷。2.3 用 Python 快速生成一份分类判断辅助表实际项目里系统模块多靠人脑记分类容易乱。我一般会写个小脚本把每个模块的属性和对应的验证活动列出来方便在验证方案里直接引用。下面这段代码不依赖任何第三方库输入模块信息输出该模块需要执行的验证项。# 根据 GAMP5 软硬件分类输出每个模块对应的验证活动清单 # 分类依据软件 I/III/IV/V硬件 I/II # 验证活动矩阵key 为分类value 为该分类需要执行的活动集合 software_activities { I: {URS, IQ, 回顾验证, 系统引退报告}, III: {URS, 风险评估, 供应商评估, IQ, OQ, PQ, 回顾验证, 系统引退报告}, IV: {URS, DQ, 风险评估, 供应商评估, FAT, IQ, OQ, PQ, 回顾验证, 系统引退报告}, V: {URS, DQ, 风险评估, 供应商评估, FAT, IQ, OQ, PQ, 回顾验证, 系统引退报告}, } hardware_activities { I: {IQ, 回顾验证, 系统引退报告}, II: {DQ, 风险评估, 供应商评估, IQ, 回顾验证, 系统引退报告}, } def get_activities(module_name, sw_classNone, hw_classNone): 输入模块名和软硬件分类返回需要执行的验证活动 result set() if sw_class: result | software_activities.get(sw_class, set()) if hw_class: result | hardware_activities.get(hw_class, set()) return sorted(result) # 示例一个 LIMS 系统软件为 IV 类可配置硬件为标准服务器 I 类 activities get_activities(LIMS 主模块, sw_classIV, hw_classI) print(LIMS 主模块需执行, 、.join(activities)) # 示例一个定制 PLC 控制逻辑软件 V 类硬件 II 类定制组件 activities2 get_activities(PLC 定制控制逻辑, sw_classV, hw_classII) print(PLC 定制控制逻辑需执行, 、.join(activities2))这段代码的逻辑很直白用两个字典分别存软件和硬件的验证活动矩阵get_activities函数把两个集合做并集最后排序输出。参数sw_class和hw_class分别对应规程里的软件分类和硬件分类取值就是字符串I、III、IV、V和I、II。实际使用时你可以把系统拆成若干模块每个模块调一次把结果贴进验证方案的范围章节。这样写出来的方案分类依据和验证活动是一一对应的审计时经得起追问。3. 风险评估与供应商评估把“就高不就低”落到表格里3.1 从 GxP 关键性到功能影响识别规程里的风险评估流程分五步初步风险评估并确认系统影响、确认对患者安全/产品质量/数据完整性有影响的功能、功能性影响评估并识别控制措施、实施并核实控制措施、审查风险与监控控制措施。这五步不是让你写五份文件而是五个判断动作最终落到几张表上。第一步是 GxP 关键性评估。规程给了一张表六个问题只要有一个回答“是”就是 GxP 关键系统。这六个问题分别是是否生成/处理/控制用于支持法规安全性和功效提交文件的数据是否控制临床前、临床、开发或生产相关关键参数和数据是否控制或提供有关产品放行的数据或信息是否控制与产品召回相关要求的数据或信息是否控制不良事件或投诉的记录或报告是否支持药物安全监视。我见过最常见的翻车现场是把“实验室用来跑中控的 HPLC 工作站”判成非 GxP 关键。理由听起来很合理“它只是中控不直接放行。”但只要它产生的数据用于支持工艺决策或者最终放行判断第一个问题就踩中了。判断的时候不要问“这个数据重不重要”要问“这个数据会不会进入放行决策链”。第二步是影响分级。对患者安全、产品质量、数据完整性三个维度分别评高、中、低。规程里写了一条原则“可能有多个原因采取‘就高不就低’原则。”这句话是护身符也是紧箍咒。护身符是说当你拿不准的时候往高了评不会错紧箍咒是说你不能因为想省事就故意往低了评审计员会拿这条原则反问你。第三步是功能影响识别。把系统拆成功能比如密码权限、打印功能、审计追踪、软件控制功能、数据备份及存储功能每个功能单独判断是否 GxP 关键、影响级别是什么。这一步的产出直接决定后面 OQ 测试的深度。影响级别高的功能测试要更严、重复次数要更多。3.2 供应商评估的四种方式和选择逻辑规程里列了四种供应商评估方式通过自身经验评估、通过公司外的参考意见评价、调查表-信函审核、通过第三方审核进行评价、通过用户所在的公司进行供应商审核。实际选择哪种取决于风险评估结果评价标准包括供应商风险和产品风险。我的经验是第 I 类基础软件操作系统、数据库基本不用做供应商现场审计记录版本号就行第 III 类非配置软件如果供应商有公开的质量体系认证可以做调查表审核第 IV 类可配置软件尤其是 LIMS、ERP 这种建议做调查表加参考意见关键供应商要做现场审计第 V 类定制软件必须做现场审计而且要审开发过程文档。规程里有一句话很关键“系统所有者应证明并记录归档选择的程序。”也就是说你选了哪种评估方式理由要写下来。不能因为“一直这么做的”就跳过。3.3 用表格把风险评估结果结构化下面这张表是我根据规程里的表 5 和表 6 整理的实操模板把功能、风险和可预测故障、严重性 S、可能性 P、可检测性 D、风险等级 RPN、控制措施、措施处理人、处理时间、措施核实串在一起。RPN 的计算方式常见做法是 S×P×D但规程没有强制公式你可以用定性分级也可以用定量乘积关键是前后一致。功能风险和可预测故障SPDRPN控制措施处理人处理时间核实密码权限未授权用户访问高中低高强制密码策略、权限分级、审计追踪IT上线前QA 复核审计追踪数据修改无记录高低中中开启审计追踪、定期审查QA持续季度审查数据备份备份失败导致数据丢失高中低高双备份、定期恢复演练IT每月演练报告打印功能打印内容与实际不符中低中中打印模板校验、打印日志使用部门上线前QA 复核这张表的用法是先填功能和风险再评 S/P/D算出 RPN然后针对高风险项写控制措施。控制措施不是写“加强管理”这种空话要写到能验证的程度。比如“强制密码策略”要写明密码长度、复杂度、更换周期“定期恢复演练”要写明频率和成功标准。注意规程里明确写了“影响级别高或影响级别中的系统进行功能影响识别”。也就是说如果影响分级评出来是低功能影响识别这一步可以跳过。但跳过要有依据不能因为想省事就评低。4. 从 URS 到 PQ验证执行阶段的文档与测试要点4.1 URS 里必须写清楚的五类内容用户需求 URS 是整个验证的起点由使用部门和工程部人员制定。规程里列了五类内容系统说明、物理要求、硬件文件标准、软件文件标准、测试要求、对供应商的其他要求。系统说明要写清楚系统要做什么、各单元之间如何连接及相互作用、控制方式逻辑控制、分选控制、互锁控制、报警控制、位置控制、速度控制、温度控制、压力控制、时间控制、计数等、执行过程、操作人员对接口的要求及安全性要求。物理要求包括有效空间、位置、所处环境。硬件文件标准包括图纸、流程图、手册、部件清单。软件文件标准包括程序编号及修订号、输出程序及详细解释、复制件的提供及贮存条件、系统框图及配置清单。测试要求包括系统开发过程中所要求进行的测试项目及记录包括单独模块测试及集成测试。对供应商的其他要求包括对已完成的系统验证要求、关于在设计开发过程中的质量控制和变更控制要求。我一般会在 URS 里加一条“可追溯性矩阵”把每条需求编号后面 DQ、IQ、OQ、PQ 的测试项都引用这个编号。这样审计的时候审计员随便挑一条需求你能在几分钟内找到对应的测试记录。没有这个矩阵验证报告就是一堆散装文件。4.2 IQ、OQ、PQ 的测试项拆解安装确认 IQ 的核心是确认系统安装符合设计标准所需技术数据俱全。规程里列了文件确认、安装过程确认、环境和公用系统确认、系统测试及确认四块。文件确认包括用户技术指南、标准操作规程、培训计划、售后服务协议、安全程序、设备清单、硬件确认、软件确认、原代码、仪器仪表清单、技术标准及图纸、仪器仪表校验程序、PID 图、控制回路图、I/O 设备清单及接线图、备品备件清单、预防维修程序。环境和公用系统确认包括清洁度、射频/电磁干扰、振动、温湿度、噪声、照明以及火警通告/抑制、冷却系统、电力及调节、不间断供电、广域网连接、局域网连接、灾难恢复接线、电话数码/模拟等。运行确认 OQ 的核心是在现场操作环境下对系统所有功能进行确认测试。规程里列了系统安全性测试、过程控制功能测试、报警和互锁功能测试、定时器和序列发生器测试、数据处理和存储功能测试、断电/恢复功能测试。系统安全性测试要挑战所有逻辑系统比如各工作层的使用权限证明未经授权的操作得到禁止。过程控制功能测试要在最高特定条件下进行比如最高通讯负载、大型数据文件的处理。断电/恢复功能测试要复查断电之前、期间和之后的数据采集状况证明资料没有破坏或丢失还要测试后备供电、不间断供电和动力调节器、发电机功能恢复是否正常。性能确认 PQ 的核心是确认系统在正常生产环境下运行过程的有效性和稳定性。如果系统是生产、实验设备或公用设施的一部分PQ 应与设备设施的 PQ 结合在一起完成。当计算机控制系统取代人工系统时可以进行平行的验证试验。对于生产设备应对生产出的产品质量特性进行检验应该在相同生产条件下连续重复 3 次以上。对于连续过程处理的设备如空气净化系统应在一定时期内对尘埃粒子、微生物、温湿度、空气流向、压差、换气次数等指标进行监测。4.3 用 bash 脚本管理验证文档的版本和编号规程里规定了编号方式计算机系统评估报告编号为 RA-CS-部门代号-流水号三位数字例如实验室计算机系统第一个评估报告 RA-CS-03-001。计算机系统验证方案及报告编号为车间/部门文件类别验证类别序列号验证类别用 CS 表示例如实验室计算机系统第一个验证方案 03VPCS001第一个验证报告 03VRCS001。实际项目里文件版本多了容易乱我一般用一段 bash 脚本做命名检查和归档。下面这段脚本不依赖外部工具输入部门代号和流水号生成标准文件名并检查目录里是否已存在。#!/bin/bash # 生成 GMP 计算机化系统验证文件的标准编号 # 用法./gen_doc_id.sh 部门代号 流水号 类型 # 类型RA 表示评估报告VP 表示验证方案VR 表示验证报告 DEPT$1 SEQ$2 TYPE$3 # 流水号补零到三位 SEQ_PADDED$(printf %03d $SEQ) case $TYPE in RA) DOC_IDRA-CS-${DEPT}-${SEQ_PADDED} ;; VP) DOC_ID${DEPT}VPCS${SEQ_PADDED} ;; VR) DOC_ID${DEPT}VRCS${SEQ_PADDED} ;; *) echo 未知类型$TYPE请使用 RA / VP / VR exit 1 ;; esac echo 生成的文件编号${DOC_ID} # 检查当前目录是否已有同名文件 if ls ${DOC_ID}* 1 /dev/null 21; then echo 警告当前目录已存在以 ${DOC_ID} 开头的文件请检查是否重复。 else echo 当前目录无同名文件可以创建。 fi这段脚本的逻辑是接收三个参数部门代号、流水号、类型根据类型拼接不同的编号格式。printf %03d把流水号补成三位数保证 001 而不是 1。最后用ls检查当前目录有没有同名文件避免重复编号。参数说明DEPT是部门代号比如实验室是 03SEQ是流水号从 1 开始TYPE是文件类型RA 对应评估报告VP 对应验证方案VR 对应验证报告。实际使用时可以在验证方案起草前先跑一遍确认编号没被占用。5. 避坑与排查验证执行中最容易翻车的五个点5.1 偏差处理不及时关键项未确认就进入下一步现象验证执行过程中发现某个测试项没通过但为了赶进度先做下一步确认打算后面补做。原因规程里写了“某些非关键项目的测试未进行前可执行下一步的确认该项目应作为偏差进行描述并在报告中明确解释。关键项目未进行确认前进行下一步确认是不允许的。”但实际操作时很多人分不清关键项和非关键项或者故意把关键项说成非关键项。解决在验证方案里提前列出关键项清单任何关键项未通过必须走偏差管理规程不能跳过。偏差报告要写清楚原因、影响评估、纠正措施和再验证计划。5.2 变更控制漏掉数据库关键参数现象系统升级或者硬件更换后只做了软件版本确认没有检查数据库里的关键参数是否被重置。原因规程里明确写了变更类型包括“数据库中关键参数的变更”但很多人只盯着软件和硬件忘了数据库。解决变更申请时要求供应商提供数据库参数清单变更后逐项核对。如果参数被重置要评估是否影响已验证状态必要时做再验证。5.3 回顾性验证周期一刀切现象所有计算机化系统都按 3 年做回顾性验证不管分类。原因规程里写了“对于 III、IV 类计算机控制系统回顾性运行验证的周期一般为 3 年其他计算机控制系统可以适当延长至 5 年。”但实际执行时有人图省事全部按 3 年有人全部按 5 年。解决按分类定周期III 类和 IV 类 3 年I 类和 V 类可以 5 年。回顾性验证以数据分析为主可以把周期均分为数个区间分阶段进行数据分析最后汇总。5.4 系统引退时数据迁移不完整现象旧系统停用新系统上线但旧系统里的历史数据没有完整迁移或者迁移后没有验证。原因规程里写了“原系统数据必须被完整地转移到新系统中这是新系统验证的一部分。”但实际操作时数据迁移往往被当成 IT 项目没有纳入验证范围。解决引退计划里要包含数据迁移方案和迁移验证方案迁移后要做数据完整性检查确认记录数、关键字段、审计追踪都完整。5.5 供应商审计流于形式现象供应商审计报告只有一页纸写着“供应商质量体系符合要求”没有具体审核记录。原因规程里写了“供应商审查应在报告中详细记录并给出最终水平。其他评估也应在报告概述中记录并给出最终水平。”但实际执行时审计人员可能没有接受过培训或者时间不够。解决供应商审计报告要包含审核范围、审核发现、不符合项、纠正措施、最终结论。对于第 IV 类和第 V 类软件供应商建议做现场审计审核开发过程文档和质量控制记录。6. 回顾验证与系统引退验证状态维持的最后一公里回顾性验证是很多团队容易忽略的环节。规程里写得很清楚所有验证的计算机控制系统都必须进行回顾性验证以确认计算机控制系统的状态始终处于验证状态。回顾内容包含六项计算机控制系统的维护、变更、数据统计分析、硬件检查、软件的安全性稳定性检查及评估、偏差处理及统计分析。我一般会把回顾性验证做成一个年度检查表按下面这个结构组织回顾项数据来源检查要点输出系统维护维护工单维护频率、故障类型、修复时间维护趋势分析系统变更变更记录变更数量、变更类型、再验证情况变更影响评估数据统计分析系统日志数据完整性、审计追踪审查数据完整性报告硬件检查硬件清单序列号、版本号、配置一致性硬件状态确认软件安全性稳定性版本记录、补丁记录版本一致性、补丁安装、漏洞修复软件状态确认偏差处理偏差记录偏差数量、根本原因、纠正措施偏差趋势分析回顾性验证的周期III 类和 IV 类一般 3 年其他可以延长到 5 年。为了避免一次性分析大量数据可以把周期均分为数个区间分阶段进行数据分析最后汇总。比如 3 年周期可以按每 6 个月一个区间分 6 次做数据分析最后汇总成一份回顾报告。系统引退是验证生命周期的终点也是最容易出问题的地方。规程里写了引退计划的制定、数据转移、通知相关部门、撤销系统特殊程序、切断系统通道、整理系统所有逻辑值符号和菜单参考、删除所有软件和工作环境下存档的电子记录。最后要写引退报告总结整个引退工作的实际执行结果。我自己的习惯是每次系统引退前先做一次数据完整性检查确认所有需要保留的数据已经迁移到新系统或者归档到指定的电子记录存储位置。然后做一次权限清理确认所有旧系统的账号、角色、访问通道都已经关闭。最后做一次文档归档把引退计划、数据迁移记录、引退报告一起交给文件 QA 归档。从那以后我每次做系统引退都强制走一遍“数据迁移验证、权限清理确认、文档归档检查”这三步少一步都不签字。希望帮到你。本文还有配套的精品资源点击获取