|
计算机系统验证概述 1. 前言 关于计算机系统的验证，一直以来想写点什么，可因为种种原因，却一直迟迟没有动笔。 今总算有点时间，就想把自己这几年的经历以及自己对计算机系统验证的一些理解整理下。也希望对一些新人有一定的帮助，当然对于一些大家觉得不正确的见解，欢迎一起讨论。 我不是什么专业的人士，也没有那些响亮的名头，更没有去那些国外专业机构去镀金。仅仅是经过这几年做软件项目和一些WHO、FDA、GMP以及一些国外的咨询公司在做交流积累的各种经验，当然还有就是自己去看GAMP5、联邦法规等这些资料，然后站在制药以及计算机软件的角度去理解所谓的计算机系统验证。
这个看着神秘而高大上的东西其实我们换个角度去看去理解，也就没有那么的神秘了。或许还会有豁然开朗的感觉。通篇我在写的时候会尽量使用白话文将自己想表达的意思表达出来，或许会有些啰嗦，大家可以跳过直接看每章节的总结部分。
通篇我主要围绕的是“为什么做、谁来做、怎么做、什么时候做”的中心来阐述。所以在读此文的时候也希望大家围绕这几个问题去理解。
2. 验证与项目 关键字：验证、项目 2.1. 验证 首先我们先说下为什么要做验证？验证能给我们带来什么？或许大家都会说是法规的要求，其实换个角度，我们做验证的目的是什么，是为了确保我所购买的仪器设备或软件系统从供应商车间到达我们的车间或者实验室安装使用以及通过长时间的运行之后，仍然满足我的最开始的法规要求、规格要求以及性能要求。所以我们购买的各类仪器设备都要做“验证”（为什么打双引号？），比如购买回来的仪器或设备通常会要求其供应商给我们提供IQ/OQ/PQ，以确保买回来的设备满足我们的使用需求。随着时间的推移，仪器或设备的性能或者说稳定性会随之降低，所以我们通过周期性的PQ（有的企业是做回顾确认），从而确保仪器的性能或者稳定性不会随着时间的推移而发生偏差。进而保证数据的准确性以及产品的质量。软件系统也一样，不仅仅要按照仪器设备的要求让供应商或者第三方进行“验证”，甚至其验证还会要求更高，这是因为软件系统在可操作性上更灵活，随之风险也会更高。那验证又能给我们带来什么呢，从长远的角度来看，不仅仅帮我们提高了企业的人员素质，更重要的是保证了我们的产品的质量持续而稳定，其利益我就不在此啰嗦了。
再来看看验证的定义： “执行验证原则、验证策略及验证计划和报告的生命周期活动；在系统的整个生命周期中采取适当的操作控制以达到并维持相关GXP法规且达到预期使用目的行动” 从定义的第一层来看，验证其实就是一个项目加上周期性的活动，周期性活动好理解，比如我们做的PQ其实就是周期性的活动。按照PQ方案每隔一段时间对仪器、设备、系统进行确认，从而证明其经过一段的时间后仍然满足我最初的URS要求；而把验证当做一个项目来看待，其实也是从验证的整个过程来看的。验证的整个过程包含了规划、规格、配置/开发、确认、报告，其实就是一个项目管理的过程，同时整个过程都应在系统中留下相应的痕迹从而证明其验证的有效性。至于定义中的第二层含义，其实就是说我们所做的这些活动或者说操作都应该是在满足GXP法规要求的前提下进行的。法规没有明确说明计算机系统应该怎么做，而是我们在计算机系统上所替代的当前线下活动应是满足法规要求的。比如说样品检测过程管理，采用计算机系统之后也应当是在满足法规要求的前提下进行。
2.2. 项目 我为什么把项目放在此来说，我们先看下项目的定义： “项目是为了创造独特的产品、服务或成果而进行的临时性工作。其临时性是指有明确的起点和终点” 从项目的执行过程上可以将项目划分为如下图示几个关键阶段。当项目结束从进而转入运维阶段。每个阶段都包含有计划、执行、收尾。即就是前面我提到的谁去做，怎么做，什么时候做。项目结束后，即进入运维阶段，通过一系列的运维过程从而确保项目产生的产品、服务或成果得以继续使用。 图1 通用型项目阶段 再来看看验证的过程，参考GAMP5的V模型，通用的过程如下图示。经过规划、规格、配置/开发、确认、报告阶段。同样的每个阶段都包含有计划、执行、收尾。有的人将Verification翻译成了验证，其实是不准确的，此阶段实际进行的工作就是确认、核查，以确保满足Specification。同样的我没有把Planning翻译成计划，是因为此处实际进行的工作应该是规划，即我们中文中的方案阶段，即表示我要做什么，什么时候做，谁去做。
图2 验证通用模型 通过对比，我们可以得出验证的整个过程其实就是一次项目的过程，然又有不同的是，验证是有着长期性的特点。因为在PQ阶段开始，进行的是周期性的活动，可以每月、每季度、每年进行一次PQ，从而确保计算机系统经过长时间的运行后，仍然满足其最开始的规格要求。
总结：通过简单分析验证与项目的过程节点，我们可以的出验证其实就是一次项目的过程，从规划开始，通过每个阶段的不同的计划、执行、报告从而最终完成整个验证的过程。同时又比项目多了一部分周期性的活动，就是PQ部分。软件系统经过第一个周期的PQ后，系统开始上线运行，后续的就是经过不同周期的PQ，来确保系统经过长时间的运行后仍然满足我们最开始的各种需求。
3. 验证与确认 关键字：验证、确认 此前看到某位前辈关于验证与确认之关系的见解，不是很认同。我在上一章节中说明验证的整个过程，再来看看确认，确认一般我们可以认为是某人按照某个文档或者规格要求进行的结果的确认活动。比如IQ/OQ/PQ，我们所进行的就是按照文档一步一步进行操作，最终得出确认后的结论。又比如我们自己买个手机，按照手机供应商提供的各种文档去操作，最终确认出手机符合厂家描述的性能指标。
总结：验证其实就是一个项目加上其周期性活动，而确认是验证的一部分活动。所以不能将验证和确认同日而语，也不可将几本确认过程文档就当做是一次验证。
4. 计算机系统验证框架 关键字：验证相关SOP、验证主计划、验证计划、风险评估
4.1. 相关SOP与验证 计划写这章的时候，我一直在纠结应该写到哪个层面，好像有太多的东西要写。最终还是觉得从整体框架入手先将验证的整个过程梳理一遍。
我们先看下图3框图。系统验证的进行，需要企业内部相关SOP的支持，以确保验证的合法合规性。这些SOP应明确规定如何进行验证，验证的原则是什么，验证的流程是什么等等。同时，还应建立相应的计算机系统的运行相关的SOP文件，这些文件的建立应在OQ报告之前完成并生效，而后系统才能进行上线正式运行。
在图中，我列举了部分SOP文件的名称，当然这些SOP文件的生效，应当在企业关于编写SOP规程的SOP下进行，如SOP文件编写规程、SOP文件编号规程等等。也就是说，从一个SOP文件应当最终到最初始的SOP文件，也就是总则类文件。 图3 系统验证SOP框图 4.2. 验证主计划与验证计划 Plan被翻译过来之后是计划，我一直觉得站在中文的角度上总是不能完整的表达其本意。更切近的意思我觉得应该是规划/方案。因为这个Plan不仅仅是时间和事件上的计划，还应包含什么时候做，做什么，怎么做，谁去做等等。 验证主计划，一般是企业年初制定的新年验证年度规划，其包括了现有系统的PQ，同时明确当新增系统之后的验证规划的编写与审批流程。而验证计划则是对当前系统的一个整体规划，表明当前系统的验证如何进行，同样的是什么时候做，做什么，怎么做，谁去做等等。无论是哪一种计划，都应当明确落地，即就有可执行性。也就是当执行人拿到这些计划之后无需再去询问就能讲按照标准去完成相应的工作，否则计划也就失去了本身的意义。
4.3. 验证流程概述 如果要讲验证的整体流程详细描述完整，恐怕5000字的篇幅也不能完成，参见GAMP5就知道了。所以在此我仍然是将整体的一个思路讲出来，如果有需要，后续的我会再深入的去将每一个步骤详细的进行描述，真正的做到“怎么做”。 图4 验证整体流程 从图中我们可以看出，验证整体流程可以分为5个节点，分别为计划、开发/配置、确认、维护、退役。
计划阶段我们首先要做的就是评估，评估上这套计算机系统之后对我现在的操作方式的影响以及对产品的影响，是直接、间接还是无影响。这个评估类似项目中的商业论证。 用户需求，是对我想要选择的这个计算机系统的要求，包括安装、运行环境、安全、功能、应用、规范等的要求，应具有可考量性，是整个计算机系统的基础，后续的所有确认均来自这份文件。
供应商审计，这个相信每个企业也都有相关的规程，这里就不啰嗦了。 验证计划，之前也提到了，重要的重复一遍，就是计划应当落地，应当有可执行性。 功能规格、设计规格，这些都是供应商按照需求文件提供的整个计算机系统的基本文件，企业应当对这些文件进行审核，必要时可请第三方机构进行审核。
开发和配置阶段，一般企业基本上已经无法进行监管，因此在供应商审计时应当着重考量，对于供应商质量管理体系不健全的，应当列为高风险项。 在确认阶段，相信大家都比较熟悉了，在此只想说明一点，就是OQ报告之前，应当完成相关系统运行所必须的SOP文件的生效。 维护阶段，主要是用来保证系统的良好运行，而PQ也同步在继续进行，用于证明系统的良好运行。 退役阶段，主要的是保证系统被替代后，历史数据仍按照法规要求继续保留。 风险评估是全程进行的，每个阶段都应当进行风险评估以及响应，这个和项目中的风险管理是一致的。风险不会完全消除，但可通过各种方式的控制以达到风险的降低。 以上，是我对流程的简单的描述，其中有两项需求跟踪矩阵。其面向的对象不一样，第一个需求跟踪矩阵主要是URS-FS-DS直接的响应或者说对应关系，而第二个需求跟踪矩阵则加入了TC，即测试用例的对应关系。表明每一个URS点是如何进行确认的。
5. 数据完整性之数据安全 关键字：数据安全 数据完整性近两年被吵的火热，相信好多企业也都在这方面吃过亏。理应将这部分内容单独来讲，在此我就简单的说一下数据安全这部分吧。 数据安全，包括了存储安全、访问安全、应用安全……关于存储安全大家听到的最多的可能就是关于异地备份了。我想说的是，异地备份这个事大家不要想的过于复杂。异地即异位，至于是异硬盘还是异服务器还是异物理空间，完全是由风险评估进行的。无论选择哪一种异位，其实都存在一定的风险，只是看这个风险的大小而已。之前我在国网做数据安全的时候，做的最多的就是异服务器存储，尽管也存在诸如失火、地震等风险因素，但这些也都只能是小概率事件了。想想如果一个机房失火是高概率，那机房监管人员估计也早就该下岗了。至于有些用户担心的硬盘存储坏了的问题，也只能算个中风险。想想如果选择了异城市的备份，不也一样存在硬盘存储坏了的问题吗？所以这个异地我想说的达到异服务器存储即可，至少我在跟那么多专家沟通的时候并没有被提出挑战。当然前提是我们要做好相关的监管工作。 6.写在最后 全篇写到这里我不得不结束了，实在是不敢在往下写了，因为太多了，有太多的我们要做的。
ouryao-com·因为有你 |
|
|
