【蒲公英微信w+文章】计算机化系统整体及条款解读 (精华版)

小洁

文章题目：计算机化系统整体及条款解读 (精华版)
原文作者： 景升平

内容提要：本篇文章是作者“90天助力企业打造计算机化系统合规验证体系（CSV）知识分享计划”四大板块：道（法规、原理）、术（方法、指南）、器（系统、工具）、用（案例、总结）中的第一个板块“道”（共九讲）的核心内容，对2010版GMP附录 计算机化系统，进行了整体解读和条款解读，内容详实、有框架、更有细节，可作为CSV入门必读材料。

一、整体解读

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

章节	条款数	主要内容
第一章范围	1条	讲到什么样的计算计化系统才是需要被验证的，以及计算机化系统的定义和构成
第二章原则	3条	讲到计算机化系统验证的目的、风险控制以及对供应商的管理要求
第三章人员	1条	讲到验证相关人员的职责、权限和培训要求
第四章验证	4条	再次强调验证范围、程度，要建立计算机化系统清单，以及不同类别软件的验证策略和数据迁移要求
第五章系统	14条	从验证系统的安装、测试、使用、变更、数据打印、系统故障应急预案、系统的产品放行以及电子签名作出了明确要求
第六章术语	1条	涉及电子数据、系统生命周期、数据审计跟踪和数据完整性等名词

从上述总结的内容分布来看，笔者认为该附录的核心思想体现为企业在采用计算机化系统来替代手工操作时，对药品生产质量管理过程中的一种风险控制。本质上是药企对自身生产经营风险的管控，从风险管理的角度来看，本附录内容可进行重新编排为

1、风险识别（第一章范围 & 第四章验证  计算机化系统范围的确定）：

2、风险评估（第二章原则需考虑患者安全、数据完整性和产品质量）

3、风险控制（第五章系统  基于系统的复杂度、新颖性和类别确定验证方案）

4、风险跟踪（第三章人员  明确人员职责和权限，对风险控制措施效果跟踪）

从流程管理的角度来看，该附录可以从另外一个视角来进行重新解读

1、目的：控制同GxP有关的计算机化系统的使用风险

2、范围；药企生产质量管理过程中涉及到的各类计算机化系统

3、原则：系统替代手工不增加总体风险，风险管理贯穿系统的全生命周期

4、方法：采用基于科学的风险评估，确定系统验证方案、执行验证活动

5、重点：不光是验证的硬件、软件本身，更是验证系统所管控的流程；

不光确保某一个阶段系统验证合格，更要确保整个生命周期内系统处于验证的受控状态，例如在系统运行阶段采用变更和配置管理，安全管理和再验证等。

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

二、条款解读

原文内容：

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

原文解读：

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

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

原文内容：

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

原文解读：

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

原文内容：

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

原文解读：

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

原文内容：

第四条：企业应当针对计算机化系统供应商的管理制定操作规程，供应商提供产品或服务时（如安装、配置、集成、验证、维护、数据处理等），企业应当与供应商签订正式协议，明确双方责任。企业应当基于风险评估的结果，提供与供应商质量体系和审计信息相关的文件。

原文解读：

第四条：这一条其实是明确了对IT产品或服务供应商的具体管理要求，包括供应商管理SOP,正式的协议或合同。同时，企业应当基于对风险评估的结果，对供应商进行相应的调查、评估，并有实施审计形成文件化的记录，这一条其实还是在强调对供应商的风险管控，风险管理也从内部延伸到了外部。风险管理的影子无处不在，真的是深入到IT合规管理的骨髓了。

原文内容：

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

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

原文解读：

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

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

原文内容：

第六条：计算机化系统验证包括应用程序的验证和基础架构的确认，其范围与程度应当基于科学的风险评估。风险评估应当充分考虑计算机化系统的使用范围和用途。

   应当在计算机化系统生命周期中保持其验证状态。

原文解读：

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

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

原文内容：

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

原文解读：

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

原文内容：

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

原文解读：

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

原文内容：

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

原文解读：

第九条：这一条很好理解，举例来说在做系统升级时，升级后的系统迁移过来的数据的数值和含义必须是同升级前系统的数据保持一致。这是最基本的要求，否则系统升级就是不成功的。

原文内容：

第十条：系统应当安装在适当的位置，以防止外来因素干扰。

原文解读：

第十条：该条款首先从环境和安全的角度，提出了系统安装的位置，以防止外来因素的干扰。这其实是说系统对机房或其他办公环境的要求，包括室内的温度、湿度、防尘、防潮、防盗等要求，所以，企业应首先建立《机房管理规程》，保障机房、机房内软硬件及相关附属设备安全、稳定运行。

原文内容：

第十一条：关键系统应当有详细阐述的文件（必要时，要有图纸），并需及时更新。此文件应当详细描述系统的工作原理、目的、安全措施和适用范围、计算机运行方式的主要特征，以及如何与其他系统和程序对接。

原文解读：

第十一条：该条款对关键系统的技术资料提出了具体要求，比如功能说明书、硬件设计说明、系统概要设计和详细设计，目的是要表述清楚整个系统的工作原理、安全措施、运行方式以及与外部系统的接口等，为后续系统的升级、维护提供技术交底材料。

原文内容：

第十二条：软件是计算机化系统的重要组成部分。企业应当根据风险评估的结果，对所采用软件进行分级管理（如针对软件供应商的审计），评估供应商质量保证系统，保证软件符合企业需求。

原文解读：

第十二条：该条款是在强调对软件的分级管理，为何要做分级管理呢？根本原因还是要做软件的风险管控。如果软件是向供应商购买的或委托供应商定制开发的，基于风险评估结果，必要时企业需对该软件供应商进行审计，评估供应商的质量保证体系，确保软件功能可靠、性能稳定、数据完整，满足企业使用需求。

原文内容：

第十三条：在计算机化系统使用之前，应当对系统进行全面测试，并确认系统可以获得预期的结果。当计算机化系统替代某一人工系统时，可采用两个系统（人工和计算机化）平行运行的方式作为测试和验证内容的一部分。

原文解读：

第十三条：这里强调了系统正式使用前，应该经过充分而全面的测试，并最终测试合格，通过验收。至于需要做哪些类型的测试以及测试做到什么程度，取决于上一条款提到的风险评估结果和软件分级管理。最常见的测试类型，包括模块单元测试、系统集成测试以及用户接受测试等。条款提到的人工和计算机化系统平行运行的方式，其实是系统切换上线后，有一个试运行阶段，该阶段结束后，将试运行期间人工记录数据和系统运行数据进行比对，根据比对后的结果，做最终的验证结论，本质上也是验证系统是否可靠的一种手段。

原文内容：

第十四条：只有经许可的人员才能进入和使用系统。企业应当采取适当的方式杜绝未经许可的人员进入和使用系统。

应当就进入和使用系统制订授权，取消以及授权变更的操作规程。必要时，应当考虑系统能记录未经许可的人员试图访问系统的行为。对于系统自身缺陷，无法实现人员控制的，必须具有书面程序、相关记录以及相关物理隔离手段，保证只有经许可的人员方能进行操作。

原文解读：

第十四条：该条款对系统的权限管理，提出了二个方面的管控：一个是进入系统，另一个是使用系统。前者只是浏览系统，获取信息，比如相关人员和领导；后者则要实实在在要在系统中进行业务操作。这是需要考虑的权限控制范围，具体该如何进行权限控制的操作呢？

条款明确指出要制定系统权限管理SOP,内容包括授权、取消授权以及权限变更流程。同时，在系统设计时，需具备记录未经许可的人员试图访问系统行为的功能。但如果系统之前的设计和功能存在缺陷，不能对人员的权限进行控制的话，则必须制定书面程序，线下做好相关的记录和手续，做到人员在物理上进入和使用系统的控制。

原文内容：

第十五条：当人工输入关键数据时，应当复核输入记录以确保其准确性。这个复核可以由另外的操作人员完成，或采用经验证的电子方式。必要时，系统应当设置复核功能，确保数据输入的准确性和数据处理过程的正确性。

原文解读：

第十五条：该条款强调关键数据的输入，需要有人复核，本质上还是防止差错。具体的做法有二种：一种方式是让另外的操作的人员完成复核，这种方式绝大多数药企都是这样做的；另一种方式，就是采用经验证的电子方式（即系统自带的功能），比如经过验证的称重配料系统，通过系统报警提示“超重”或“欠重”，又比如SAP系统中录入检验数据时，系统会自动校验长度和小数位数，以保证数据输入的准确性和处理的正确性。个人认为，保险的做法是将人工复核和系统校验二者结合起来，宁可在数据入口多做检查，也比后面发现错误去处理，无论从时间上还是成本上来说，都更为划算。

原文内容：

第十六条：计算机化系统应当记录输入或确认关键数据人员的身份。只有经授权人员，方可修改已输入的数据。每次修改已输入的关键数据均应当经过批准，并应当记录更改数据的理由。应当根据风险评估的结果，考虑在计算机化系统中建立数据审计跟踪系统，用于记录数据的输入和修改以及系统的使用和变更。一句话总结“系统权限的合规管理需从用户进入系统-》录入数据-》更改数据-》审计追踪进行完整管控才行，任何环节的管理缺失，都将带来质量风险。

原文解读：

第十六条：上一条说到数据的输入，这里提到了数据的更改，其实都是在强调对人员权限的控制，而修改则更为严格，特别是关键数据的修改需经过批准，并记录更改数据的理由（这一点，很多企业在操作过程中执行得不是很好，甚至无缘无故就把数据给改了，这样做既不合规，又埋下了风险隐患）。此外，应当根据风险评估结果，建立系统数据审计跟踪系统，对原始数据的输入和修改能够通过系统日志进行查询，这一点很重要，事实上很多的业务系统设计不是很完善，修改后的数据直接覆盖了原始录入的数据，这其实是违规的！

原文内容：

第十七条：计算机化系统的变更应当根据预定的操作规程进行，操作规程应当包括评估、验证、审核、批准和实施变更等规定。计算机化系统的变更，应经过该部分计算机化系统相关责任人员的同意，变更情况应有记录。

原文解读：

第十七条：该条款对系统变更作出了明确要求，需建立变更操作规程。并依据该操作规程进行变更评估、验证、审核、批准和实施，并最终形成变更记录。

原文内容：

第十八条：对于电子数据和纸质打印文稿同时存在的情况，应当有文件明确规定以电子数据为主数据还是以纸质打印文稿为主数据。

原文解读：

第十八条：对于此条款，在我看来纸质记录和电子数据其实没有主次之分，只有先后之分。原因在于如果电子数据（比如图谱）直接由系统生成，那么可以在提供电子数据的同时，将该电子数据打印出来进行存档、备查。而如果之前是现场的纸质记录的话，那么也可以将该纸质记录数据扫描后，上传到文档服务器进行集中存储。这里需要强调的就一点，不管先有电子数据还是先有纸质记录，二者的版本号和数据必须保持一致，这也是数据完整性的要求。

原文内容：

第十九条：以电子数据为主数据时，应当满足以下要求：

（一）为满足质量审计的目的，存储的电子数据应当能够打印成清晰易懂的文件。（二）必须采用物理或电子方法保证数据的安全，以防止故意或意外的损害。日常运行维护和系统发生变更（如计算机设备或其程序）时，应当检查所存储数据的可访问性及数据完整性。（三）应当建立数据备份与恢复的操作规程，定期对数据备份，以保存存储的数据供将来调用。备份数据应当存储在另一个单独的、安全的地点，保存时间应当至少满足本规范中关于文件、记录保存时限的要求。

原文解读：

第十九条：这里对电子数据提出三个方面的合规要求，一是能够将电子数据打印出清晰易懂的纸质文档；二是需采取物理或者电子的方式，保证其数据的安全；同时，还应在日常运维和系统变更时，检查存储数据的可访问性和数据完整性；三是需建立数据备份和恢复SOP，包括本地备份和远程备份，以确保数据安全和调用。

原文内容：

第二十条：企业应当建立应急方案，以便系统出现损坏时启用。应急方案启用的及时性应当与需要使用该方案的紧急程度相关。例如，影响召回产品的相关信息应当能够及时获得。

原文解读：

第二十条：“凡事预则立，不预则废”，该条款明确提出对系统可能出现各种的损坏提前考虑，包括当遇到自然灾害、意外事故、操作系统崩溃、数据库错误等原因造成SAP系统无法正常运行，导致公司业务无法正常运转且用常规修复方法无法修复时，将启用灾难应急预案。应急方案启用的及时性应当与需要使用该方案的紧急程度相关，包括立即启用、24小时启用等。

原文内容：

第二十一条：应当建立系统出现故障或损坏时进行处理的操作规程，必要时对该操作规程的相关内容进行验证。

  包括系统故障和数据错误在内的所有事故都应当被记录和评估。重大的事故应当进行彻底调查，识别其根本原因，并采取相应的纠正措施和预防措施。

原文解读：

第二十一条：企业除了需建立突发情况下的系统应急方案外，条款还提出要建立日常情况下的故障或损坏处理的操作规程，以保证业务的连续性。系统故障和数据错误应当作为事件被记录和评估，根据需要完成相应的CAPA流程，直至问题处理闭环。

原文内容：

第二十二条：当采用计算机化系统放行产品时，计算机化系统应当能明示和记录放行产品人员的身份。

原文解读：

第二十二条：在系统中做放行产品时，系统应当能明示和记录放行产品人员的身份，比如质量受权人，此过程可以通过电子签名来实现。

原文内容：

第二十三条：电子数据可以采用电子签名的方式，电子签名应当遵循相应法律法规要求。

原文解读：

第二十三条：电子数据即系统生成的所有电子文档，可以采用电子签名的方式，包括用户系统二次密码验证、第三方媒介如U盾签名或确认等。不管哪种方式都必须遵循《中华人民共和国电子签名法》的规定要求。

（注：第二十四条 术语 解读 略）

    蒲公英微信公众号“ouryaoinfo” 2016年共发布文章2345篇，总字数485万字，累计阅读近1100万人次，发布天数365天（全年共366天）。在蒲公英论坛各位蒲友的支持下，2016年蒲公英微信运营团队取得了优异的成绩，2017向各位蒲友继续征稿，欢迎关注！

    感谢上海凌致赞助发布并提供所有作者奖品。

xqliu

学习一下啦，谢谢提供分享。

baiyinqiang

谢谢分享        

热血青年

很好啊，刚培训完这个课题的内容。再看看其他人是怎么理解的

hhxx2018

谢谢分享。

老马-QC

感谢分享