计算机化系统的文档管理

人工智能AI+数字化验证工具

赋能药企生产质量管理

大家好，我们今天接着上期的变更管理，接着说计算机化系统的文档管理。

下列法规中描述文档管理的要求

Adequate controls over the distribution of, access to, and use of documentation for system operation and maintenance.

21 CFR Part 11 11.10（K）（1）

我们上一期说的变更管理中其中一段也提到过，文档的修订也是变更管理活动的一部分，前提就是我们得有正确的文档管理。

对于文档如何管理，这个我就不班门弄斧了。这个是GMP的基本常识。这篇文章主要是讲计算机化系统的文档管理的几个案例，希望能够引出各位老师的一些思考和理解。

虽然FDA的Part11里面要求的是操作和运维文档，但是此文不仅限于该文档。

首先讲讲验证/确认方案和脚本的不同的展示方式。

这也是我做每个项目最初一定要和甲方沟通清楚的地方。之所以想说这个，就是想和大家说方案、脚本、报告的展示方式其实有多种。

• 测试脚本在方案的正文中，方案签批后，执行的时候直接在脚本上填写，然后出具报告。

• 测试脚本作为方案的附件，方案签批后，执行的时候复印该测试脚本填写，填写版作为报告的附件。

• 测试脚本作为方案的附件，方案签批后，直接出需填写的报告，脚本同时也作为报告的附件，测试完成后填写报告和脚本。

以上做法没有哪个好或者不好的说法，只是做法不同。

但是从个人角度来看，最好的做法就是第二种，并且在复印的时候要盖copy章，以避免在执行的时候私自更改脚本。

然后我们接着说运维和操作SOP。

一般来说，在执行PQ之前，我们需要确定我们的操作SOP的草版已经好了，并且我们的PQ应该遵循草版SOP里面的步骤来执行。如果PQ结束后没有偏差和变更，那么就把草版的SOP生效。

而运维的SOP中描述的账户管理、角色和权限管理、备份还原、审计追踪审核这些很少会放在PQ中去做，而是放在OQ中做。我们的运维SOP一定要遵从我们OQ中执行的方法来描述。

我在过往的审计中，多次见到验证的备份方法和SOP中描述的备份方法不一样。这样就相当于执行一个没有验证过的备份方法，是不合规的，风险很大。

接下来我们说技术规格文档和URS。

对于URS来说，它可能是独立的，也可能是连续的。是因为有些URS是针对单个系统的，有些URS是针对多个系统的。

例如我们新上一个ERP，和所有系统都没有接口。那么这个ERP的URS是独立的。而如果我们已经有了ERP、LIMS、MES，这个时候我们上一个WMS，并且要与ERP、LIMS、MES做接口。那么新起草WMS的URS，并且更新ERP、LIMS、MES的URS是一个工作量增加的行为。最常见的做法就是起草WMS的URS，并且把接口需求写在这个URS里面。

但是对于技术规格文档，例如FS、CS、FDS、TDS这些。他们的主体肯定还是本系统。

他们的更新来源其实可以是本系统的URS，也有可能是其他系统URS的接口部分。

在验证阶段这些文档的管理，和运维阶段这些文档的管理我不赘述了。我最想讲的是切换的时候技术规格由项目阶段的验证文件转变为质量体系下的技术规格文档的活动。

对于一些做的比较好的乙方，他们会有一个配置基线文档，在关键节点都会更新配置基线文档，例如DR和PQ。以确保当前执行设计审核和PQ是基于哪些技术规格文档来执行的。然后做的比较好的甲方，也会在上线切换的同时，将最新的配置基线转变为体系内的文件。以后执行项目的时候就可以在此基础上更新了。

如果这个文档管控的比较好的话（这里的好是指写的详细，写的准确，更新的及时）。那么即便以后更新供应商，更换系统所有者，都不会对这个系统的运维和使用产生影响。

以上这种做法是最推崇的，大部分企业都是会把技术规格文档堆在验证的文件堆里面。当升级改造的时候再从这个故纸堆里面找出来，甚至找不到。

以上就是对于计算机化系统的相关文档的管理的一些思路。