计算机化系统管理规程

李凯12

基于ISPE GAMP5第二版（中文版）文件，结合其中的核心原则（特别是基于风险的方法、批判性思维、生命周期方法及利用供应商活动），为您撰写一份具有实用性、可直接作为企业文件基础的《计算机化系统管理规程》。这份规程旨在跳出传统的“为了合规而合规”的框架，强调如何在实际工作中高效、有效地管理计算机化系统，确保其始终处于适合预期用途的受控状态。

---

SOP编号： [公司内部编号]

版本号： 1.0

生效日期： [YYYY-MM-DD]起草部门： [如：IT合规部/质量保证部]
1.0 目的

建立一套基于风险的方法，用于管理公司范围内所有GxP相关计算机化系统的整个生命周期，从概念、项目、运行到退役。本规程旨在确保这些系统始终符合预定用途，保障患者安全、产品质量和数据完整性，同时通过鼓励批判性思维和高效实践，避免不必要的官僚主义和资源浪费。

2.0 范围

本规程适用于公司内所有用于GxP（GMP、GLP、GCP、GDP、GVP等）相关活动的计算机化系统，包括但不限于：

• IT基础设施（如服务器、网络、云服务）;
• 标准软件产品（如某些实验室仪器）;
• 可配置软件系统（如LIMS、ERP、MES、WMS、DMS）;
• 定制开发的应用程序;
• 最终用户计算工具（如复杂的电子表格、小型数据库）;
• 软件即服务（SaaS）、平台即服务（PaaS）和基础设施即服务（IaaS）。
  
  

3.0 职责

• 业务流程负责人： 对所支持的业务流程的合规性负最终责任。负责定义用户需求，批准关键文件（如验证计划、报告），并确保系统在运行中持续适用。
• 系统所有者： 负责系统的技术可用性、支持和维护。管理系统的技术状态，协调变更，并确保系统文档的准确性。
• 数据所有者： 负责系统内数据的完整性。通常由业务流程负责人或其指定人员担任，确保数据在整个生命周期内符合ALCOA+原则。
• 质量保证部： 负责建立和维护本规程，提供质量监督，批准关键的质量文件，确保整个过程的合规性，并运用批判性思维评估风险决策的合理性。
• 主题专家： 来自业务、IT、工程等领域的专家，负责在系统生命周期的各个阶段提供专业知识，主导风险评估，定义测试策略并审查结果。
• 供应商： 根据合同约定，提供产品、开发、配置、测试或支持服务。其工作成果可被公司评估和利用。
  
  

4.0 定义与缩略语

• GxP： 泛指药品生产、临床、实验室、分销等质量管理规范。
• 计算机化系统验证： 通过建立和记录客观证据，确保一个特定的计算机化系统始终如一地符合其预定用途和GxP要求。
• 质量风险管理： 在整个产品生命周期中，对药品质量风险进行评估、控制、沟通和审核的系统过程。
• 批判性思维： 基于对产品和流程的理解，有目的地对在何处以及如何应用质量和合规活动做出合理判断。
• ALCOA+： 数据完整性原则，即可归属、清晰、同步、原始、准确，以及完整、一致、持久、可获得。
• 可扩展方法： 根据系统的风险、复杂性和新颖性调整生命周期活动的深度和广度。
  
  

5.0 规程5.1 核心原则：从“文档驱动”转向“证据驱动”

在应用本规程时，所有相关人员必须运用批判性思维。文件的数量和形式不是合规的唯一标准。关键在于能否提供充分、可信的证据，证明系统处于受控状态并适用于其预期用途。证据可以是传统的纸质文件，也可以是经过验证的电子工具（如需求管理工具、测试自动化工具、配置管理数据库）中产生的记录。

5.2 基于风险的分类与可扩展方法

在启动任何计算机化系统项目前，必须进行初步风险评估。

• GxP影响评估： 确定系统是否直接影响患者安全、产品质量或数据完整性。如果是，则定义为GxP相关系统，适用本规程。
• 系统分类：
  • 第1类（基础设施软件）： 操作系统、数据库、网络监控工具等。管理重点在于配置标准化、服务管理和持续监控，而非逐个项目验证。
  • 第3类（标准系统组件）： 不可配置的固件或软件。采用简化的生命周期，重点是明确的用户需求、正确的安装和证明其适用于业务流程的测试。
  • 第4类（可配置软件）： 通过配置工作流以满足特定需求的商业软件（如LIMS, ERP）。这是管理的重点区域。验证应聚焦于配置的正确性及对业务流程的支撑。
  • 第5类（定制应用）： 为满足特定需求而开发编码的软件。需要覆盖完整的软件开发生命周期，包括设计、代码审查和全面的测试。
    
    
  
  

5.3 系统生命周期管理5.3.1 概念与项目阶段

• 供应商评估： 在选择供应商前，必须基于风险对其进行评估。
  
  
  • 高风险/复杂系统： 应进行详细的供应商审计（现场或虚拟），评估其质量管理体系和软件开发实践。
  • 中/低风险系统： 可通过调查问卷、审查其认证（如ISO 9001, SOC2报告）或利用其市场声誉进行评估。
  • 核心思想： 评估的目的在于决定可以在多大程度上“利用”供应商的文档和测试结果，以避免重复工作。
    
    
• 验证计划： 对于每个GxP相关系统，必须制定一份验证计划。该计划应简洁、聚焦，明确说明：
  • 系统的范围和预期用途。
  • 将采用的可扩展方法（基于风险评估结果）。
  • 关键角色和职责。
  • 关键交付物清单（如URS、风险记录、测试总结）。
  • 如何利用供应商的活动。
    
    
• 需求规格：
  • 必须清晰、可验证地定义用户需求。避免使用模糊、无法测试的语言（如“系统必须符合GMP”），而应描述具体的功能（如“系统应记录所有对关键批次数据的修改，包括旧值、新值、修改人和时间戳”）。
  • 需求可以迭代发展，特别是在敏捷项目中，可以以用户故事的形式在工具中管理。
    
    
• 设计与配置：
  • 对于第4类系统，重点记录关键的配置决策及其与用户需求的追溯关系。
  • 对于第5类系统，必须进行设计审查和代码审查，审查的深度基于风险。
    
    
• 验证测试：
  • 制定测试策略： 基于功能风险评估的结果制定测试策略。高风险功能需要更严格、更详细的测试（如脚本化测试），而中低风险功能可采用更高效的测试方法，如：
    
    
    • 探索性测试： 允许有经验的测试人员在没有详细脚本的情况下自由探索系统，发现脚本测试难以发现的缺陷。
    • 基于覆盖的测试： 记录测试了哪些功能和场景，而非记录每一步操作。
      
      
  • 利用供应商测试： 将供应商提供的测试报告作为验证证据的一部分。只需评估和补充测试，确保其覆盖了公司特有的业务流程和风险。
  • 测试证据： 鼓励使用电子证据（如系统截图、审计跟踪、自动化测试日志）。避免不必要地打印大量纸质记录。
    
    

5.3.2 运行阶段

系统上线后，管理重点转向维持其验证状态。

• 移交： 项目组必须将系统平稳移交给运维团队。移交内容包括完整的竣工配置基线、操作和维护手册、已知问题清单以及知识转移（培训）。
• 变更管理：
  • 所有对系统及其运行环境的变更（包括配置更改、补丁更新、用户权限变更）都必须遵循正式的变更管理流程。
  • 可扩展的变更： 变更的严格程度应与变更的风险和复杂性相称。
    • 标准/低风险变更（如增加非关键用户、应用常规安全补丁）： 可采用预定义的快速流程。
    • 中/高风险变更： 必须进行影响评估、适当的测试（回归测试）和审批。
      
      
  • 紧急变更： 针对紧急安全漏洞或系统故障，应有流程允许在控制风险的前提下快速实施变更，并事后补全记录。
    
    
• 事件和问题管理： 记录所有系统故障、用户错误或异常事件。对事件进行分析，识别根本原因，并采取纠正和预防措施，防止复发。
• 定期评审：
  • 定期（如每年或每两年，频率基于风险）对系统进行评审，以确认其仍处于验证状态。
  • 评审内容应基于现有数据，如变更记录、事件/问题记录、备份恢复日志、用户访问审计报告等。
  • 评审结果应形成报告，确认系统是否继续适合预期用途，或是否需要采取补救措施（如再验证、升级或退役）。
    
    
• 安全管理与数据备份：
  • 建立并执行用户访问管理程序，确保权限基于角色，并及时撤销离职人员权限。
  • 制定并测试数据备份和恢复计划，确保在灾难发生时能够及时恢复系统和数据。备份和恢复测试应定期进行并记录。
    
    
  
  

5.3.3 退役阶段

• 退役计划： 在系统停止使用前，必须制定退役计划，明确数据迁移、数据归档或数据销毁的方案。
• 数据保留： 必须确保所有需要长期保存的GxP记录在系统退役后，仍能以可读的格式进行检索和访问。这可能涉及将数据迁移到长期归档系统或将其转换为标准格式。
• 退役报告： 系统退役完成后，应形成总结报告，记录退役过程、数据处置情况以及系统配置的最终状态。
  
  

6.0 相关文件/记录

• 《供应商评估管理规程》
• 《变更控制管理规程》
• 《偏差与CAPA管理规程》
• 《计算机化系统清单》
• 各系统的《验证计划》与《验证报告》