计算机化系统的风险评估管理规程

李凯12

基于ISPE GAMP5第二版（中文版）文件，特别是其中第5章“质量风险管理”和附录M3“基于科学的质量风险管理”的核心原则，我将为您撰写一份具有实用性、可直接作为企业文件基础的《计算机化系统风险评估管理规程》。这份规程旨在将GAMP5倡导的“基于风险的方法”落地为可操作的程序，帮助团队将精力聚焦在真正影响患者安全、产品质量和数据完整性的关键领域，避免“一刀切”或“为了评估而评估”的形式主义。

---

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

版本号： 1.0

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

建立一套系统的、基于科学的质量风险管理程序，用于识别、分析、评估、控制、沟通和审查计算机化系统在其整个生命周期（概念、项目、运行、退役）中对患者安全、产品质量和数据完整性的潜在风险。本规程旨在确保风险管理活动的深度、形式和文件化程度与风险水平相称，从而高效、有效地指导验证活动、变更管理及持续运维决策。

2.0 范围

本规程适用于公司内所有GxP相关计算机化系统的整个生命周期。

• 涵盖的系统类型： 包括基础设施软件（第1类）、标准系统组件（第3类）、可配置软件产品（第4类）以及定制应用（第5类）。
• 涵盖的生命周期阶段： 初始概念与项目规划、供应商评估、需求定义、设计与开发、测试验证、运行维护与变更、系统退役。
• 涵盖的风险类型： 主要关注对患者安全、产品质量和数据完整性的风险。业务连续性、财务或信息安全风险可作为补充考虑，但不作为本规程的主要强制范围。
  
  

3.0 职责

• 业务流程负责人： 最终负责批准风险评估结果，确保评估基于对业务流程的深刻理解，并接受最终的残余风险。
• 系统所有者： 负责组织并执行风险评估，提供系统技术架构和功能方面的输入，并确保风险控制措施在技术上得以实施。
• 质量保证部： 负责确保风险管理流程得到遵循，提供方法指导，参与高风险评估的评审，并批准关键的风险评估文件。
• 主题专家： 来自业务、IT、工程、开发等领域的专家，负责具体执行风险评估活动，识别风险，分析根本原因，并建议有效的控制措施。
• 数据所有者： 负责提供数据流和数据使用方面的输入，确保数据完整性风险被充分识别和评估。
• 供应商： 在适用时，提供其产品设计、开发过程和已知缺陷的相关信息，参与风险评估讨论。
  
  

4.0 定义与缩略语

• 危害： 对健康的损害，包括因产品质量或供应损失可能产生的损害。在计算机化系统背景下，指系统可能对患者或产品质量造成伤害的潜在源。
• 风险： 危害发生的概率和该危害的严重程度的组合。
• 严重性： 危害一旦发生，其潜在后果的严重程度。
• 发生概率： 导致危害的故障或错误发生的可能性。
• 可检测性： 在危害发生前，发现并防止故障或错误的能力。
• 风险优先级： 综合考虑严重性、发生概率和可检测性后，确定的风险等级，用于指导行动优先级。
• 控制措施： 为将风险降低到可接受水平而采取的行动。可以是技术控制（如系统内置的权限控制、报警）或程序控制（如SOP中的复核步骤、培训）。
• 残余风险： 实施控制措施后仍然存在的风险。
• 功能风险评估： 针对系统中对患者安全、产品质量或数据完整性有影响的特定功能进行详细风险评估的过程。
  
  

5.0 流程

本规程遵循ICH Q9和GAMP5推荐的五步风险管理过程，并将其应用于计算机化系统的具体场景。

5.1 步骤1：启动与初步风险评估（系统级）

在项目概念阶段或验证计划编制初期进行。

• GxP关键性评估： 确定系统是否影响GxP活动。若非GxP相关，则本规程不强制适用，可参考良好工程实践进行管理。
• 系统影响评估： 基于系统所支持的流程，初步确定其对患者安全、产品质量和数据完整性的总体影响。
  • 高影响系统示例： 支持批次放行的LIMS、控制关键工艺参数的DCS、生成临床试验数据的EDC系统、处理不良事件的PV系统。
  • 低影响系统示例： 仅用于内部培训跟踪的系统、非关键性参考文件库。
    
    
• 确定进一步评估需求：
  • 根据系统影响、复杂性和新颖性（结合GAMP分类），决定是否需要更详细的功能风险评估。
  • 决策逻辑：
    • 低影响系统 + 标准产品（第3类）： 通常一次初步评估即可覆盖所有风险，无需进一步详细评估。记录结论即可。
    • 中/高影响系统 + 可配置产品（第4类）或定制应用（第5类）： 必须进行详细的功能风险评估（步骤2-4）。
      
      
    
    
• 输出： 《系统初步风险评估报告》或在《验证计划》中记录评估结论，明确系统影响等级及后续详细评估的范围。
  
  

5.2 步骤2：识别关键功能（功能级）

在需求基本明确、设计阶段进行。

• 组建多功能团队： 召集业务流程负责人、SME（业务用户）、系统SME（IT/工程）、数据所有者、必要时QA参与。
• 识别GxP关键功能： 以用户需求和/或功能规格为基础，识别出那些一旦发生故障，将直接或间接影响患者安全、产品质量或数据完整性的功能。
  • 关键功能示例：
    
    
    • 数据录入、计算和报告功能
    • 审计跟踪功能
    • 电子签名功能
    • 与关键设备或其他GxP系统的接口
    • 用户权限管理功能
    • 系统时钟同步功能
      
      
    
    
• 输出： 一份关键功能列表，作为下一步详细评估的基础。
  
  

5.3 步骤3：功能风险评估与确定控制措施（详细级）

对步骤2中识别的每个关键功能进行分析。

• 识别潜在危害与故障模式： 针对每个关键功能，采用头脑风暴或结构化方法（如FMEA），识别“如果...会怎样？”的故障模式。
  
  
  • 示例（LIMS中的结果录入功能）： 故障模式可能包括“操作员输错数值”、“数据保存失败”、“审计跟踪未记录修改”等。
    
    
• 评估风险等级： 对每个已识别的故障模式，评估其严重性、发生概率和可检测性。可采用简单的“高/中/低”三级评分系统，或更精细的数值评分（如1-5分）。
  • 严重性评估： 基于业务流程。例如，导致错误批次放行 → 严重性高；导致生成错误的管理报表 → 严重性中/低。
  • 发生概率评估： 基于系统复杂性（GAMP类别）、供应商成熟度、历史经验。例如，定制代码的接口 → 发生概率高；成熟的标准功能 → 发生概率低。
  • 可检测性评估： 基于现有控制。例如，有系统内置的报警 → 可检测性高；仅靠人工事后抽查 → 可检测性低。
    
    
• 确定风险优先级： 综合严重性、发生概率和可检测性，得出风险优先级。通常将“严重性高”的风险作为最高优先级，无论其概率和可检测性如何。
• 定义控制措施： 针对不可接受的风险，提出控制措施。控制措施应遵循以下优先顺序：
  • 首选：通过设计消除风险（如修改流程或系统设计，使该故障模式不再存在）。
  • 次选：通过技术控制降低风险（如增加数据有效性检查、实施自动报警、加强权限控制）。
  • 末选：通过程序控制降低风险（如制定SOP要求双人复核、加强培训、增加人工审核点）。
    
    
• 评估残余风险： 在应用控制措施后，重新评估风险等级。若残余风险仍不可接受，则需引入新的或更强的控制措施，直至风险降至可接受水平。
• 输出： 《功能风险评估报告》或《风险管理记录》，其中至少包含：关键功能列表、故障模式、初始风险等级、拟采取的控制措施、控制措施实施后的残余风险等级。
  
  

5.4 步骤4：实施与验证控制措施

在系统构建、配置和测试阶段进行。

• 实施控制： 将步骤3中确定的控制措施落实到系统设计、配置、代码或程序中。
• 验证控制有效性： 在验证测试阶段，设计专门的测试用例来挑战这些控制措施，证明它们被正确实施并能有效降低风险。
  • 例如： 如果控制措施是“系统应拒绝超出范围的数值输入”，那么测试脚本必须包含尝试输入超出范围值并验证系统拒绝的用例。
    
    
• 追溯性： 在追溯矩阵中，建立从“风险”到“控制措施”再到“测试用例”的关联，确保证据链完整。
• 输出： 包含风险控制验证结果的《测试总结报告》或《验证报告》。
  
  

5.5 步骤5：风险审查与持续监测

在系统运行阶段持续进行，并作为定期评审的一部分。

• 定期风险审查： 在定期评审时，审查原有的风险评估记录，确认：
  
  
  • 现有的控制措施是否仍然有效？（例如，SOP是否被遵守？）
  • 是否有新的风险出现？（例如，系统用途变更、法规更新、发现新的安全漏洞）
  • 以前识别的风险是否已不再适用？
    
    
• 变更触发再评估： 当提出任何变更请求时，必须审查原有的风险评估，评估变更是否会引入新风险或改变现有风险等级。根据评估结果确定变更验证的严格程度。
• 事件/问题驱动再评估： 当系统发生重大事件或问题时，应在根本原因分析后，回顾风险评估，判断是否有未识别的风险或控制措施失效。
• 输出： 《定期评审报告》中包含风险审查结论；变更控制记录中体现风险评估结果；事件/CAPA记录中关联风险评估更新。
  
  

6.0 风险的可接受标准

• 高风险： 通常不可接受，必须采取控制措施将其降低。所有“严重性高”的风险均应视为高风险，无论其概率。
• 中风险： 应采取措施将其降低。若因客观原因无法进一步降低，需由业务流程负责人和QA共同批准接受，并持续监测。
• 低风险： 可通过良好工程实践或标准程序进行管理，无需采取额外的专门控制措施。可作为残余风险接受。
  
  

7.0 相关文件/记录

• 《计算机化系统管理规程》
• 《供应商评估管理规程》
• 《变更控制管理规程》
• 《定期评审管理规程》
• 《验证计划》与《验证报告》模板
• 《功能风险评估报告》模板
  
  

大南风

谢谢分享，学习

、银

学习。。。。。。。。。。。。。。。。。