管理变更控制

在维持已验证计算机化系统已验证状态的同时，对变更进行评估、审批、实施和验证。

适用场景

• 已验证系统需要软件升级、补丁或配置变更
• 基础设施变更（服务器迁移、操作系统升级、网络变更）影响已验证系统
• CAPA 或审计发现需要系统修改
• 业务流程变更需要系统重新配置
• 紧急变更需要快速审批和事后记录

输入

• 必填：变更描述（变更内容和原因）
• 必填：受影响的系统及其当前已验证状态
• 必填：变更申请人和业务理由
• 可选：供应商发布说明或技术文档
• 可选：相关 CAPA 或审计发现引用
• 可选：受影响系统的现有验证文档

步骤

第 1 步：创建并分类变更申请

# 变更申请
## 文档 ID：CR-[SYS]-[YYYY]-[NNN]

### 1. 变更描述
**申请人：** [姓名，部门]
**日期：** [YYYY-MM-DD]
**系统：** [系统名称和版本]
**当前状态：** [当前配置/版本]
**拟变更至：** [目标配置/版本]

### 2. 理由
[变更的业务、法规或技术原因]

### 3. 分类
| 类型 | 定义 | 审批路径 | 时间表 |
|------|------|---------|--------|
| **紧急** | 针对安全、数据完整性或法规合规性的紧急修复 | 系统负责人 + QA（事后 CCB） | 立即实施，5 天内完成记录 |
| **标准** | 可能影响已验证状态的计划变更 | 实施前获 CCB 批准 | 按 CCB 计划 |
| **轻微** | 对已验证状态无影响的低风险变更 | 系统负责人批准 | 实施前完成记录 |

**本变更分类为：** [紧急 / 标准 / 轻微]
**依据：** [为何作此分类]

预期结果： 变更申请有唯一 ID、明确描述和有理由支撑的分类。 失败处理： 若分类存在争议，默认选择标准类型，让 CCB 进行裁决。

第 2 步：执行影响评估

评估变更对已验证状态所有维度的影响：

# 影响评估
## 变更申请：CR-[SYS]-[YYYY]-[NNN]

### 影响矩阵
| 维度 | 是否受影响 | 详情 | 风险 |
|------|----------|------|------|
| 软件配置 | 是/否 | [正在变更的具体参数] | [高/中/低] |
| 源代码 | 是/否 | [受影响的模块、函数或脚本] | [高/中/低] |
| 数据库架构 | 是/否 | [正在变更的表、字段、约束] | [高/中/低] |
| 基础设施 | 是/否 | [受影响的服务器、网络、存储] | [高/中/低] |
| 接口 | 是/否 | [上下游系统连接] | [高/中/低] |
| 用户访问/角色 | 是/否 | [角色变更、新访问需求] | [高/中/低] |
| SOP/工作指令 | 是/否 | [需要更新的程序] | [高/中/低] |
| 培训 | 是/否 | [需要再培训的用户] | [高/中/低] |
| 数据迁移 | 是/否 | [所需的数据转换或迁移] | [高/中/低] |
| 审计追踪 | 是/否 | [对审计追踪连续性的影响] | [高/中/低] |

### 法规影响
- [ ] 变更影响 21 CFR Part 11 控制措施
- [ ] 变更影响 EU Annex 11 控制措施
- [ ] 变更影响数据完整性（ALCOA+）
- [ ] 变更需要法规通知

预期结果： 每个维度均已评估，有明确的是/否和依据。 失败处理： 若无法在不测试的情况下确定影响，将该维度分类为"未知——需要调查"，并要求在生产变更前在沙盒环境中进行评估。

第 3 步：确定重新验证范围

根据影响评估，确定所需的验证活动：

# 重新验证确定

| 重新验证级别 | 标准 | 所需活动 |
|------------|------|---------|
| **完整重新验证** | 核心功能变更、新 GAMP 类别或主要版本升级 | URS 审查、RA 更新、IQ、OQ、PQ、TM 更新、VSR |
| **部分重新验证** | 特定功能受影响、配置变更 | 针对受影响功能的目标 OQ、TM 更新 |
| **仅文档更新** | 无功能影响的行政变更 | 更新验证文档、变更日志条目 |
| **无需重新验证** | 对已验证状态无影响（如外观变更） | 仅变更日志条目 |

### CR-[SYS]-[YYYY]-[NNN] 的确定
**重新验证级别：** [完整 / 部分 / 仅文档 / 无需]
**依据：** [基于影响评估的具体理由]

### 所需活动
| 活动 | 负责人 | 截止日期 |
|------|--------|---------|
| [如执行 OQ 测试用例 TC-OQ-015 至 TC-OQ-022] | [姓名] | [日期] |
| [如更新 URS-007 的追溯矩阵] | [姓名] | [日期] |
| [如更新 SOP-LIMS-003 第 4.2 节] | [姓名] | [日期] |

预期结果： 重新验证范围与变更影响相称——不多不少。 失败处理： 若重新验证范围存在争议，倾向于更多测试。验证不足是法规风险；过度验证只是资源成本。

第 4 步：获得审批

通过适当的审批工作流程路由变更：

# 变更审批

### CR-[SYS]-[YYYY]-[NNN] 的审批

| 角色 | 姓名 | 决定 | 签名 | 日期 |
|------|------|------|------|------|
| 系统负责人 | | 批准 / 拒绝 / 推迟 | | |
| QA 代表 | | 批准 / 拒绝 / 推迟 | | |
| IT 代表 | | 批准 / 拒绝 / 推迟 | | |
| 验证负责人 | | 批准 / 拒绝 / 推迟 | | |

### 附加条件（如有）
[审批附加的任何条件]

### 计划实施窗口
- **开始：** [日期/时间]
- **结束：** [日期/时间]
- **回退截止点：** [无法回退的时间点]

预期结果： 实施开始前所有必要审批人均已签字（紧急变更除外）。 失败处理： 对于紧急变更，从系统负责人和 QA 处获得口头批准，实施变更，并在 5 个工作日内完成正式记录。

第 5 步：实施并验证

执行变更并进行变更后验证：

# 实施记录

### 实施前
- [ ] 当前系统状态备份已完成
- [ ] 回退程序已记录并测试
- [ ] 受影响用户已通知
- [ ] 测试环境已验证（如适用）

### 实施
- **实施人：** [姓名]
- **日期/时间：** [YYYY-MM-DD HH:MM]
- **执行步骤：** [详细实施步骤]
- **与计划的偏差：** [无 / 描述]

### 变更后验证
| 验证项 | 结果 | 证据 |
|--------|------|------|
| 系统可访问且正常运行 | 通过/失败 | [截图/日志引用] |
| 已变更功能按规定工作 | 通过/失败 | [测试用例引用] |
| 未变更功能未受影响（回归） | 通过/失败 | [测试用例引用] |
| 审计追踪连续性已维持 | 通过/失败 | [审计追踪截图] |
| 用户访问控制完整 | 通过/失败 | [访问审核引用] |

### 关闭
- [ ] 所有验证活动已成功完成
- [ ] 验证文档已按重新验证确定进行更新
- [ ] SOP 已更新并生效
- [ ] 受影响用户的培训已完成
- [ ] 变更控制系统中的变更记录已关闭

预期结果： 实施符合已批准计划，所有验证活动均通过。 失败处理： 若验证失败，立即执行回退程序并将失败记录为偏差。未经 QA 同意不得继续。

验证清单

• 变更申请有唯一 ID、描述和分类
• 影响评估涵盖所有维度（软件、数据、基础设施、SOP、培训）
• 重新验证范围已定义并有依据
• 实施前所有必要审批已获得（或紧急情况下 5 天内完成）
• 实施前备份和回退程序已记录
• 变更后验证证明变更有效且其他功能未受影响
• 验证文档已更新以反映变更
• 变更记录已正式关闭

常见问题

• 对"小"变更跳过影响评估：即使是轻微变更也可能有意想不到的影响。看似无害的配置开关可能禁用审计追踪或改变计算结果
• 紧急变更滥用：若超过 10% 的变更被分类为"紧急"，则变更流程正在被规避。审查并收紧紧急标准
• 回退规划不完整：假设回退"只是恢复备份"忽略了备份到回退之间创建的数据。为每种回退场景定义数据处置方案
• 实施后审批：回溯审批（已记录的紧急情况除外）是合规违规。CCB 必须在工作开始前批准
• 缺少回归测试：仅验证已变更功能是不够的，必须通过回归测试确认现有已验证功能未受影响

相关技能

• design-compliance-architecture

  — 定义包含变更控制委员会的治理框架

• write-validation-documentation

  — 创建变更触发的重新验证文档

• perform-csv-assessment

  — 需要完整重新验证的重大变更的全面 CSV 重新评估

• write-standard-operating-procedure

  — 更新受变更影响的 SOP

• investigate-capa-root-cause

  — 当变更由 CAPA 触发时