版gmp附录计算机化系统整体及条款解读完整精华版

2010版GMP附录：计算机化系统整体及条款解读(完整精华版)

一、整体解读 通读全文，该附录共有6章24个条款，笔者对其内容分布整理如下：

章 节 条款数 主 要 内 容

第一章范围 1条 讲到什么样的计算机化系统才是需要被验证的，以及计算机化系统的定义和构成

第二章原则 3条 讲到计算机化系统验证的目的、风险控制以及对供应商的管理要求

第三章人员 1条 讲到验证相关人员的职责、权限和培训要求

第四章验证 4条 再次强调验证范围、程度，要建立计算机化系统清单，以及不同类别软件的验证策略和数据迁移要求

第五章系统 14条 从验证系统的安装、测试、使用、变更、数据打印、系统故障应急预案、系统的产品放行以及电子签名作出了明确要求

第六章术语 1条 涉及电子数据、系统生命周期、数据审计跟踪和数据完整性等名词 从上述总结的内容分布来看，笔者认为该附录的核心思想体现为企业在采用计算机化系统来替代手工操作时，对药品生产质量管理过程中的一种风险控制。本质上是药企对自身生产经营风险的管控，从风险管理的角度来看，本附录内容可进行重新编排为

1、风险识别（第一章 范围&第四章 验证 计算机化系统范围的确定）： 2、风险评估（第二章 原则 需考虑患者安全、数据完整性和产品质量） 3、风险控制（第五章 系统 基于系统的复杂度、新颖性和类别确定验证方案） 4、风险跟踪（第三章 人员 明确人员职责和权限，对风险控制措施效果跟踪） 从流程管理的角度来看，该附录可以从另外一个视角来进行重新解读 1、目的：控制同GxP有关的计算机化系统的使用风险 2、范围；药企生产质量管理过程中涉及到的各类计算机化系统 3、原则：系统替代手工不增加总体风险，风险管理贯穿系统的全生命周期 4、方法：采用基于科学的风险评估，确定系统验证方案、执行验证活动 5、重点：不光是验证的硬件、软件本身，更是验证系统所管控的流程； 不光确保某一个阶段系统验证合格，更要确保整个生命周期内系统处于验证的受控状态，例如在系统运行阶段采用变更和配置管理，安全管理和再验证等。

6、策略：根据软件级别的不同其测试程度也不同，比如针对第5类软件系统的源代码审核和功能测试；针对第4类软件系统的配置测试，然后是基于黑盒的功能测试、需求测试以及结合实际工艺和流程的性能测试等。

二、条款解读 原文内容：

第一条：本附录适用于在药品生产质量管理过程中应用的计算机化系统，计算机化系统由一系列硬件和软件组成，以满足特定的功能。

原文解读： 第一条：此附录描述了计算机化系统的适用范围，是在药品生产质量过程中，这是其一；其二，什么是计算机化系统，由一系列硬件和软件组成，从字面上来看，这个定义和“计算机系统”没有本质区别，主要区别在于后面这几个字“以满足特定的功能”。按照PIC/SPI011-3指南的定义，计算机化系统（ComputerizedSystem）由计算机系统（ComputerSystem）和被其控制的功能和流程组成。

那么，在制药企业计算机化系统究竟包括哪些呢？下图举例来说明，大家就一目了然了，清楚多了。

原文内容： 第二条：计算机化系统代替人工操作时，应当确保不对产品的质量、过程控制和其质量保证水平造成负面影响，不增加总体风险。

原文解读： 第二条：很显然，这一条主旨是说计算机化系统可以代替人工操作，提高工作效率，但是需考虑这种替代或变革随之带来的风险，这种风险可能是来自产品质量的、过程控制的，也可能是整个质量保证体系的，需慎重、全面考虑这种变革带来的诸多影响，原则上同过去手工操作相比，不增加总体风险即可。这一条其实给整个附录定了一个基调，就是凡是大到变革、小到变更，只要有变化都要做好风险识别和风险评估工作，这是一切“变”的前提和刚性要求。

原文内容： 第三条：风险管理应当贯穿计算机化系统的生命周期全过程，应当考虑患者安全、数据完整性和产品质量。作为质量风险管理的一部分，应当根据书面的风险评估结果确定验证和数据完整性控制的程度。

原文解读： 第三条：这一条承接上一条，对风险管理从二个维度提出了具体要求。一个是时间维度，风险管理要求贯穿整个计算机化系统全生命周期，包括概念提出、项目实施、系统运行直到系统引退。这种风险意识其实也正好契合了企业家们的危机意识，当今以任正非为代表的中国企业家们，每天思考的其实不是如何成功，而是怎么避免失败，企业能活下去其实就是成功；另一个维度是潜在后果，即风险如果发生，可能会导致的后果会是什么，人员伤亡、质量投诉、数据丢失等，正是基于对这些后果的考虑，才有了风险管理的现实出发点，即所有的系统设计、安装、使用以及变更，都需要充分考虑患者安全、产品质量、数据完整性的影响。且根据风险评估做出的影响分析，用来作为确定系统验证方案和系统数据完整性控制的依据。

原文内容： 第四条：企业应当针对计算机化系统供应商的管理制定操作规程，供应商提供产品或服务时（如安装、配置、集成、验证、维护、数据处理等），企业应当与供应商签订正式协议，明确双方责任。企业应当基于风险评估的结果，提供与供应商质量体系和审计信息相关的文件。 原文解读： 第四条：这一条其实是明确了对IT产品或服务供应商的具体管理要求，包括供应商管理SOP,正式的协议或合同。同时，企业应当基于对风险评估的结果，对供应商进行相应的调查、评估，并有实施审计形成文件化的记录，这一条其实还是在强调对供应商的风险管控，风险管理也从内部延伸到了外部。风险管理的影子无处不在，真的是深入到IT合规管理的骨髓了。

原文内容： 第五条：计算机化系统生命周期中所涉及的各种活动，如验证、使用、维护、管理等，需要各相关的职能部门人员之间的紧密合作。应当明确所有使用和管理计算机化系统人员的职责和权限，并接受相应的使用和培训管理。

应当确保有适当的专业人员，对计算机化系统的设计、验证、安装和运行等方面进行培训和指导。

原文解读： 第五条：该条款特别强调在进行计算机化系统验证整个生命周期当中，一定要事先明确所有使用和管理这些系统人员的职责和权限，这一点很重要，如果事先不能很清晰地界定清楚大家的分工和职责，将会造成验证工作的混乱，相互扯皮、甚至会造成某些环节在管理上的真空。关于这一点，通常要在验证主计划中写明白、写清楚。

大伙除了清楚各自干什么还不够，你有没有能力把很专业的工作干好、做到位，这一点很关键，对于能力达不到的人员，培训就显得尤为重要。培训涉及到接受培训的人员和执行培训的老师二个角色，条款中用了一个词，叫“适当”，其实就是告诉我们对培训人员和培训老师要有适当的要求，包括课程设计、现场指导等。

说完对人员的要求，接下来再和大家说一说验证的整体框架性要求。 原文内容： 第六条：计算机化系统验证包括应用程序的验证和基础架构的确认，其范围与程度应当基于科学的风险评估。风险评估应当充分考虑计算机化系统的使用范围和用途。

应当在计算机化系统生命周期中保持其验证状态。 原文解读： 第六条：这里对计算机化系统的验证范围或对象再次进行了明确，同附录第一条是相呼应的。验证对象包括应用程序（就是软件）和基础架构（包括硬件和网络）。验证的具体范围和程度如何确定呢？答案是基于科学的风险评估，那么风险评估又如何进行呢？答案是要充分考虑该系统的使用范围和用途。这么说有点抽象哈，举例来说，某个系统的使用是否同GxP有关或对产品质量有影响，如果有，就需要进行风险评估，同时还要考虑该系统使用范围大小，范围越大，影响越大，风险越高。

此外，该条款特别强调了系统在整个生命周期中验证状态的保持，这一点告诉我们验证工作其实是个常态的工作，而不是一项运动，更不是一项阶段性的工作，需要我们终身坚持不懈地做下去，“不忘初心，方得始终”！

原文内容： 第七条：企业应当建立包含药品生产质量管理过程中涉及的所有计算机化系统清单，标明与药品生产质量管理相关的功能。清单应当及时更新。

原文解读： 第七条：这里提到了建立“计算机化系统清单”，这一点很重要，但往往容易被企业所忽视，这也是很多药企在GMP现场审核时，检查官开得最常见的一项主要缺陷项。为什么这一条在检查官看来很重要呢？原因就在于，作为CIO或IT部门负责人，你对你所管理的整个IT各个系统要有很清晰的一张管理地图，哪些系统需做验证，哪些系统不需做验证；需要做验证的系统，他们的硬件、网络和软件配置如何，能否满足验证和使用的要求，这些配置组件的更改有没有及时更新到清单上来，如果连这一点都做不到，我是检查官的话，我也会判缺陷项的，甚至是严重缺陷项！这一点，请CIO们务必重视起来。 原文内容：

第八条：企业应当指定专人对通用的商业化计算机软件进行审核，确认其满足用户需求。在对定制的计算机化系统进行验证时，企业应当建立相应的操作规程，确保在生命周期内评估系统的质量和性能。

原文解读： 第八条：这一条说的其实是对需要做验证的系统或软件进行一个分类，即商业化软件（无需定制开发）和定制开发软件这二大类。显然，这二大类的软件本身的技术复杂程度，我们无法评估，我们要考虑的其实是使用这些系统所带来的风险，前者成熟稳定，经过了长时间市场和时间的检验；后者新颖独创，很多潜在的Bug尚未被发现，需要经过实际的使用和时间的检验才能被证明是否稳定、可靠。所以，前者仅需做审核、确认就够了，而后者则需建立严格的操作规程，严格的测试，验证其系统的稳定性和产品的健壮性，二者验证的所要求的程度是不一样。

原文内容： 第九条：数据转换格式或迁移时，应当确认数据的数值及含义没有改变。 原文解读：