什么叫生命周期中保持其验证状态

计算机化系统的生命周期大家应该已经很熟悉了，从系统的项目实施阶段到系统的操作维护阶段，最后到系统的退役阶段。项目实施阶段又包括计划、需求、设计确认、测试、接收和系统投入使用。项目阶段的验证大家应该比较熟悉了，前面几篇推送中也在跟大家一再强调操作维护阶段也需要重视起来。今天重点说说什么叫保持验证状态。

回到验证的定义：“证明任何操作规程（或方法）、生产工艺或系统能够达到预期结果的一系列活动。”那保持验证状态最重要的就是两个方面，有书面的证明和保持预期的结果。

保持验证状态不是说系统不能出问题。系统出了问题不用怕，应该通知谁就通知谁，应该谁处理就由谁来处理，系统不能用一两个小时天塌不下来。换个角度来说，真的长时间DOWN机，说不定还给了你个测试业务持续计划的机会呢。系统出了问题解决就是，按照规定的流程，查原因，找问题，复杂些的系统在测试环境试着重现问题，必要的测试后解决问题。

人还经常会有个感冒咳嗽，系统偶尔出点儿问题也正常。有时说不定重启一下就好了，没什么好紧张，有些系统在设计时就会已经考虑到相关的冗余，重启一下不一定会造成数据的丢失，当然，说说不算，要测试。

只要按照规定的流程来处理问题，并且有相应的记录就好，哪怕系统需要重新安装软件，只要是同一版本的，功能和之前的又没有变化，那就不影响预期的结果，因为之前安装的流程是经过确认的，那只需要按照之前的配置重新配置或者做一下系统恢复也就可以了。

系统出问题比较怕的情况是系统数据丢失。如果有另外的可靠的数据来源，那问题很简单，用另一个数据源的数据就是，当然，偏差里要写清楚；如果没有另外的数据源，允许的情况下通过偏差重新测试，产生结果也是可以接受的；如果是实时数据，没有了也找不回来了，也不允许通重新测试，那就只好基于其他的支持性数据间接证明，并通过偏差记录下评估的过程，必要时增加样品的稳定性考察也就可以了，这更应该听业务流程负责人的。IT需要负责的是把系统恢复就好，发生问题的原因找到并解决就好。

保持验证状态不是说不能有变更，如果仅是基础架构层面的变更，或者安全软件打个补丁，仅涉及到GAMP分类为1的软件，升级完后确认一下系统功能不受影响就可以了；对于GAMP分类为1的标准硬件，情况也是如此，比如扫描枪，工业键盘，打印机，装相应的驱动，完成配置，确认下功能就好。

如果涉及到功能变更或者是比较大的版本变更，需要考虑对系统验证的动态文件是否有影响，比如用户需求是否需要更新，测试是否需要补充进行，是否影响业务流程等，这一切其实也都可以通过变更控制进行；数据库存的变更与升级可能会比较麻烦，可能涉及到数据的转移，但是通常有数据库转移的工具，这些数据库转移的工具到处都在用，不限于制药行业，从风险的角度来说也是相对较低的。

计算机化系统验证从来不是独立于质量体系之外的，变更和偏差是很重要的两个工具确保系统的验证状态。包括一些技术性变更，比如换个内存，换个路由器，真的没什么好紧张的，不要动不动就扣上一个影响验证状态的帽子，这一点上，需要多尊重IT部门的意见，QA或者业务流程所有者往往并不是这方面的业务专家。

保持验证状态需要操作人员始终按照规定的流程去操作、去使用计算机化系统。因为系统的功能很多，对于某些COTS软件，验证的甚至只是部分的法规要求的功能，在验证的范围内使用系统，恰当分配系统的权限，必要时及时更新相关的操作性文件。

保持验证状态不要忽略了系统退役后的活动，在数据没有完全转移到新系统的情况下，系统退役了往往系统中的电子数据还是需要保留的，而且还要在数据保留的期限内始终可以访问，这也是计算机化系统生命周期的一部分，也是保持验证状态的一部分。

上述所有的内容系统变更、异常事件、偏差、系统性能、数据、支持流程、权限清单的回顾，实际上可以通过系统的周期性回顾实现，这也是保持系统验证状态的一个重要途径。