计算机系统验证资料

1、计算机计算机系统验证系统验证概述概述 1. 前言前言 关于计算机系统的验证， 一直以来想写点什么， 可因为种种原因， 却一直迟迟没有动笔。 今总算有点时间，就想把自己这几年的经历以及自己对计算机系统验证的一些理解整理下。 也希望对一些新人有一定的帮助，当然对于一些大家觉得不正确的见解，欢迎一起讨论。 我不是什么专业的人士，也没有那些响亮的名头，更没有去那些国外专业机构去镀金。 仅仅是经过这几年做软件项目和一些 WHO、FDA、GMP 以及一些国外的咨询公司在做交 流积累的各种经验，当然还有就是自己去看 GAMP5、联邦法规等这些资料，然后站在制药 以及计算机软件的角度去理解所谓的计算机系统验证。 这个看着神秘而高大上的东西其实我们换个角度去看去理解，也就没有那么的神秘了。 或许还会有豁然开朗的感觉。 通篇我在写的时候会尽量使用白话文将自己想表达的意思表达 出来，或许会有些啰嗦，大家可以跳过直接看每章节的总结部分。 通篇我主要围绕的是“为什么做、谁来做、怎么做、什么时候做”的中心来阐述。所以 在读此文的时候也希望大家围绕这几个问题去理解。 2. 验证验证与项目与项目 关键字关键字：验证、

2、项目：验证、项目 2.1. 验证验证 首先我们先说下为什么要做验证？验证能给我们带来什么？或许大家都会说是法规的 要求，其实换个角度，我们做验证的目的是什么，是为了确保我所购买的仪器设备或软件系 统从供应商车间到达我们的车间或者实验室安装使用以及通过长时间的运行之后， 仍然满足 我的最开始的法规要求、规格要求以及性能要求。所以我们购买的各类仪器设备都要做“验 证” （为什么打双引号？） ，比如购买回来的仪器或设备通常会要求其供应商给我们提供 IQ/OQ/PQ，以确保买回来的设备满足我们的使用需求。随着时间的推移，仪器或设备的性 能或者说稳定性会随之降低， 所以我们通过周期性的 PQ （有的企业是做回顾确认） ， 从而确 保仪器的性能或者稳定性不会随着时间的推移而发生偏差。 进而保证数据的准确性以及产品 的质量。 软件系统也一样， 不仅仅要按照仪器设备的要求让供应商或者第三方进行 “验证”， 甚至其验证还会要求更高，这是因为软件系统在可操作性上更灵活，随之风险也会更高。那 验证又能给我们带来什么呢，从长远的角度来看，不仅仅帮我们提高了企业的人员素质，更 重要的是保证了我们的产品的质量持续

3、而稳定，其利益我就不在此啰嗦了。 再来看看验证的定义： “执行验证原则、验证策略及验证计划和报告的生命周期活动；在系统的整个生命执行验证原则、验证策略及验证计划和报告的生命周期活动；在系统的整个生命 周期中采取适当的操作控制以达到并维持相关周期中采取适当的操作控制以达到并维持相关 GXPGXP 法规且达到预期使用目的行动法规且达到预期使用目的行动” 从定义的第一层来看，验证其实就是一个项目加上周期性的活动，周期性活动好理解， 比如我们做的 PQ 其实就是周期性的活动。按照 PQ 方案每隔一段时间对仪器、设备、系统 进行确认，从而证明其经过一段的时间后仍然满足我最初的 URS 要求；而把验证当做一个 项目来看待，其实也是从验证的整个过程来看的。验证的整个过程包含了规划、规格、配置 /开发、确认、报告，其实就是一个项目管理的过程，同时整个过程都应在系统中留下相应的 痕迹从而证明其验证的有效性。 至于定义中的第二层含义， 其实就是说我们所做的这些活动 或者说操作都应该是在满足 GXP 法规要求的前提下进行的。法规没有明确说明计算机系统 应该怎么做， 而是我们在计算机系统上所替代的当前线下活动

4、应是满足法规要求的。 比如说 样品检测过程管理，采用计算机系统之后也应当是在满足法规要求的前提下进行。 2.2. 项目项目 我为什么把项目放在此来说，我们先看下项目的定义： “项目项目是为了创造是为了创造独特独特的产品的产品、服务服务或或成果而进行的临时性工作。成果而进行的临时性工作。其临时性其临时性是指有是指有 明确的起点和明确的起点和终点终点” 从项目的执行过程上可以将项目划分为如下图示几个关键阶段。当项目结束从进而 转入运维阶段。每个阶段都包含有计划、执行、收尾。即就是前面我提到的谁去做，怎 么做，什么时候做。项目结束后，即进入运维阶段，通过一系列的运维过程从而确保项 目产生的产品、服务或成果得以继续使用。 图图 1 通用型通用型项目阶段项目阶段 再来看看验证的过程，参考 GAMP5 的 V 模型，通用的过程如下图示。经过规划、 规格、配置/开发、确认、报告阶段。同样的每个阶段都包含有计划、执行、收尾。有的 人将Verification翻译成了验证，其实是不准确的，此阶段实际进行的工作就是确认、 核查，以确保满足Specification。同样的我没有把Planning翻译成计划

5、，是因为此处实 际进行的工作应该是规划， 即我们中文中的方案阶段， 即表示我要做什么， 什么时候做， 谁去做。 图图 2 验证验证通用通用模型模型 通过对比，我们可以得出验证的整个过程其实就是一次项目的过程，然又有不同的 是，验证是有着长期性的特点。因为在 PQ 阶段开始，进行的是周期性的活动，可以每 月、每季度、每年进行一次 PQ，从而确保计算机系统经过长时间的运行后，仍然满足 其最开始的规格要求。 总结总结 通过简单分析验证与项目的过程节点，我们可以的出验证其实就是一次项目的过程， 从规划开始，通过每个阶段的不同的计划、执行、报告从而最终完成整个验证的过程。 同时又比项目多了一部分周期性的活动， 就是 PQ 部分。 软件系统经过第一个周期的 PQ 后，系统开始上线运行，后续的就是经过不同周期的 PQ，来确保系统经过长时间的运 行后仍然满足我们最开始的各种需求。 3. 验证与验证与确认确认 关键字关键字：验证验证、确认、确认 此前看到某位前辈关于验证与确认之关系的见解， 不是很认同。 我在上一章节中说明验 证的整个过程， 再来看看确认， 确认一般我们可以认为是某人按照某个文档或者规格

6、要求进 行的结果的确认活动。比如 IQ/OQ/PQ，我们所进行的就是按照文档一步一步进行操作，最 终得出确认后的结论。又比如我们自己买个手机，按照手机供应商提供的各种文档去操作， 最终确认出手机符合厂家描述的性能指标。 总结总结 验证其实就是一个项目加上其周期性活动， 而确认是验证的一部分活动。所以所以不能不能将将验验 证和确认同日而语，也不证和确认同日而语，也不可可将将几本几本确认过程文档就当做是一次验证。确认过程文档就当做是一次验证。 4. 计算机系统计算机系统验证框架验证框架 关键字关键字：验证验证相关相关 SOP、验证主计划、验证计划、风险评估验证主计划、验证计划、风险评估 4.1. 相关相关 SOPSOP 与与验证验证 计划写这章的时候，我一直在纠结应该写到哪个层面，好像有太多的东西要写。最终还 是觉得从整体框架入手先将验证的整个过程梳理一遍。 我们先看下图 3 框图。系统验证的进行，需要企业内部相关 SOP 的支持，以确保验证 的合法合规性。这些 SOP 应明确规定如何进行验证，验证的原则是什么，验证的流程是什 么等等。同时，还应建立相应的计算机系统的运行相关的 SOP 文

7、件，这些文件的建立应在 OQ 报告之前完成并生效，而后系统才能进行上线正式运行。 在图中，我列举了部分 SOP 文件的名称，当然这些 SOP 文件的生效，应当在企业关 于编写 SOP 规程的 SOP 下进行，如 SOP 文件编写规程、SOP 文件编号规程等等。也就 是说，从一个 SOP 文件应当最终到最初始的 SOP 文件，也就是总则类文件。 图图 3 系统系统验证验证 SOP 框图框图 4.2. 验证验证主计划与验证计划主计划与验证计划 Plan 被翻译过来之后是计划，我一直觉得站在中文的角度上总是不能完整的表达其本 意。更切近的意思我觉得应该是规划/方案。因为这个 Plan 不仅仅是时间和事件上的计划， 还应包含什么时候做，做什么，怎么做，谁去做等等。 验证主计划，一般是企业年初制定的新年验证年度规划，其包括了现有系统的 PQ，同 时明确当新增系统之后的验证规划的编写与审批流程。 而验证计划则是对当前系统的一个整 体规划，表明当前系统的验证如何进行，同样的是什么时候做，做什么，怎么做，谁去做等 等。无论是哪一种计划，都应当明确落地，即就有可执行性。也就是当执行人拿到这些计划 之后无

8、需再去询问就能讲按照标准去完成相应的工作，否则计划也就失去了本身的意义。 4.3. 验证验证流程概述流程概述 如果要讲验证的整体流程详细描述完整， 恐怕 5000 字的篇幅也不能完成， 参见 GAMP5 就知道了。所以在此我仍然是将整体的一个思路讲出来，如果有需要，后续的我会再深入的 去将每一个步骤详细的进行描述，真正的做到“怎么做” 。 图图 4 验证验证整体流程整体流程 从图中我们可以看出，验证整体流程可以分为 5 个节点，分别为计划、开发/配置、确 认、维护、退役。 计划阶段我们首先要做的就是评估， 评估上这套计算机系统之后对我现在的操作方式的 影响以及对产品的影响，是直接、间接还是无影响。这个评估类似项目中的商业论证。 用户需求，是对我想要选择的这个计算机系统的要求，包括安装、运行环境、安全、功 能、应用、规范等的要求，应具有可考量性，是整个计算机系统的基础，后续的所有确认均 来自这份文件。 供应商审计，这个相信每个企业也都有相关的规程，这里就不啰嗦了。 验证计划，之前也提到了，重要的重复一遍，就是计划应当落地，应当有可执行性。 功能规格、 设计规格， 这些都是供应商按照需求文

9、件提供的整个计算机系统的基本文件， 企业应当对这些文件进行审核，必要时可请第三方机构进行审核。 开发和配置阶段， 一般企业基本上已经无法进行监管， 因此在供应商审计时应当着重考 量，对于供应商质量管理体系不健全的，应当列为高风险项。 在确认阶段，相信大家都比较熟悉了，在此只想说明一点，就是 OQ 报告之前，应当完 成相关系统运行所必须的 SOP 文件的生效。 维护阶段，主要是用来保证系统的良好运行，而 PQ 也同步在继续进行，用于证明系统 的良好运行。 退役阶段，主要的是保证系统被替代后，历史数据仍按照法规要求继续保留。 风险评估是全程进行的， 每个阶段都应当进行风险评估以及响应， 这个和项目中的风险 管理是一致的。风险不会完全消除，但可通过各种方式的控制以达到风险的降低。 以上，是我对流程的简单的描述，其中有两项需求跟踪矩阵。其面向的对象不一样，第 一个需求跟踪矩阵主要是 URS-FS-DS 直接的响应或者说对应关系， 而第二个需求跟踪矩阵 则加入了 TC，即测试用例的对应关系。表明每一个 URS 点是如何进行确认的。 5. 数据完整性之数据完整性之数据安全数据安全 关键字：数据安全 数据完整性近两年被吵的火热， 相信好多企业也都在这方面吃过亏。 理应将这部分内容 单独来讲，在此我就简单的说一下数据安全这部分吧。 数据安全，包括了存储安全、访问安全、应用安全关于存储安全大家听到的最多的 可能就是关于异地备份了。我想说的是，异地备份这个事大家不要想的过于复杂。异地即异 位，至于是异硬盘还是异服务器还是异物理空间，完全是由风险评估进行的。无论选择哪一 种异位，其实都存在一定的风险，只是看这个风险的大小而已。之前我在国网做数据安全的 时候，做的最多的就是异服务器存储，尽管也存在诸如失火、地震等风险因素，但这些也都 只能是小概率事件了。 想想如果一个机房失火是高概率， 那机房监管人员估计也早就该下岗 了。至于有些用户担心的硬盘存储坏了的问题，也只能算个中风险。想想如果选择了异城市 的备份， 不也一样存在硬盘存储坏了的问题吗？所以这个异地我想说的达到异服务器存储即 可， 至少我在跟那么多专家沟通的时候并没有被提出挑战。 当然前提是我们要做好相关的监 管工作。 6. 写在写在最后最后 全篇写到这里我不得不结束了，实在是不敢在往下写了，因为太多了，有

《计算机系统验证资料》由会员w****i分享，可在线阅读，更多相关《计算机系统验证资料》请在金锄头文库上搜索。