退役已验证系统

计划和执行已验证计算机化系统的受控退役，同时保持数据完整性并满足法规保留要求。

适用场景

• 已验证系统被新系统取代
• 系统到达寿命终止且无替代系统（业务流程终止）
• 供应商停止对已验证产品的支持
• 多个系统整合到单一平台
• 法规或业务变更导致系统过时

输入

• 必填：待退役系统（名称、版本、验证状态）
• 必填：按法规分类的数据保留要求（21 CFR Part 11、GLP、GCP）
• 必填：替代系统（如适用）和迁移范围
• 可选：当前验证文档包
• 可选：数据量和格式清单
• 可选：业务负责人和利益相关方名单

步骤

第 1 步：评估数据保留要求

确定数据必须保留多长时间及以何种形式保留：

# 数据保留评估
## 文档 ID：DRA-[SYS]-[YYYY]-[NNN]

### 法规保留要求
| 法规 | 数据类型 | 保留期 | 格式要求 |
|------|---------|--------|---------|
| 21 CFR 211（GMP） | 批记录、检测结果 | 产品到期后 1 年或分销后 3 年 | 可读、可检索 |
| 21 CFR 58（GLP） | 研究数据和记录 | 研究期 + 保留协议 | 原件或认证副本 |
| ICH E6（GCP） | 临床试验记录 | 最后一次上市批准或正式终止后 2 年 | 可供检查访问 |
| 21 CFR Part 11 | 电子记录 | 按前提法规要求 | 原始格式或已验证迁移 |
| EU Annex 11 | 计算机化系统记录 | 按适用 GxP | 可读且可获取 |
| 税务/财务 | 财务记录 | 7-10 年（按司法管辖区） | 可读 |

### 系统数据清单
| 数据类别 | 数量 | 格式 | 必须保留至 | 处置方式 |
|---------|------|------|----------|---------|
| [如批记录] | [如 50,000 条] | [如数据库 + PDF 报告] | [日期] | 迁移 / 归档 / 销毁 |
| [如审计追踪] | [如 200 万条] | [如数据库] | [与父记录相同] | 归档 |
| [如用户数据] | [如 200 个档案] | [如 LDAP/数据库] | [在职 + 2 年] | 匿名化并归档 |

预期结果： 每个数据类别均有明确的保留期、格式要求和计划处置方式。 失败处理： 若保留要求不明确，咨询监管事务和法律部门。默认选择最长的适用保留期。

第 2 步：规划数据迁移（如适用）

若数据将迁移到替代系统：

# 数据迁移计划
## 文档 ID：DMP-[SYS]-[YYYY]-[NNN]

### 迁移范围
| 来源 | 目标 | 数据类别 | 记录数 | 迁移方法 |
|------|------|---------|-------|---------|
| [旧系统] | [新系统] | [类别] | [数量] | ETL / 手动 / API |

### 数据映射
| 源字段 | 源格式 | 目标字段 | 目标格式 | 转换 |
|--------|--------|---------|---------|------|
| [如 test_result] | FLOAT(8,2) | [如 result_value] | DECIMAL(10,3) | 精度转换 |
| [如 operator_id] | VARCHAR(20) | [如 user_id] | UUID | 查找表映射 |

### 验证方法
| 检查 | 方法 | 验收标准 |
|------|------|---------|
| 记录数核对 | 源计数与目标计数 | 100% 匹配 |
| 字段级比较 | 随机抽取 5% 记录，检查所有字段 | 转换后 100% 匹配 |
| 校验和验证 | 对关键字段的源和目标进行哈希 | 校验和匹配 |
| 业务规则验证 | 验证目标中的关键计算 | 结果与源匹配 |
| 审计追踪连续性 | 验证历史审计追踪已迁移 | 所有条目以原始时间戳存在 |

预期结果： 迁移计划包含映射、转换规则和验证检查，证明数据完整性已维持。 失败处理： 若迁移验证失败，不得继续退役。修复迁移问题并重新验证。

第 3 步：定义归档策略

对于将归档而非迁移的数据：

# 归档策略

### 归档格式
| 考虑因素 | 决定 | 依据 |
|---------|------|------|
| 格式 | [PDF/A、CSV、XML、数据库备份] | [为何此格式能在保留期内存活] |
| 介质 | [网络存储、云归档、磁带、光盘] | [耐用性和可访问性] |
| 加密 | [是/否——若是则说明方法] | [安全性与长期可访问性的权衡] |
| 完整性验证 | [SHA-256 校验和、定期验证计划] | [证明归档未损坏] |

### 归档验证
- [ ] 归档数据无需源系统即可读取
- [ ] 所有必需的数据类别均包含在归档中
- [ ] 归档时已记录校验和
- [ ] 归档可在 [规定的服务级别协议，如 5 个工作日] 内搜索和检索
- [ ] 已安排定期完整性检查（每年）

### 归档访问
| 角色 | 访问级别 | 授权 |
|------|---------|------|
| QA 总监 | 所有归档数据读取权限 | 常设授权 |
| 监管事务 | 检查支持的读取权限 | 常设授权 |
| 系统负责人（前任） | 业务查询的读取权限 | 按需申请 |
| 外部审计员 | 读取权限，有监督 | 按审计计划 |

预期结果： 归档数据无需原始系统即可读取、搜索和验证。 失败处理： 若数据无法脱离源系统独立读取，该归档不合规。在退役前考虑导出为开放标准格式（PDF/A、CSV）。

第 4 步：执行退役

# 退役清单
## 文档 ID：DC-[SYS]-[YYYY]-[NNN]

### 退役前
- [ ] 所有利益相关方已收到退役日期和数据处置通知
- [ ] 数据迁移已完成并经验证（如适用）
- [ ] 数据归档已创建并验证（如适用）
- [ ] 已单独存储完整系统的最终备份
- [ ] 所有未解决的变更申请已解决或转移
- [ ] 所有未解决的 CAPA 已解决或转移到继任系统
- [ ] 所有活跃用户已通知并引导至替代系统（如适用）

### 退役执行
- [ ] 所有账户的用户访问权限已撤销
- [ ] 系统已从生产环境中移除
- [ ] 网络连接已断开
- [ ] 许可证已归还或终止
- [ ] 系统条目已从活跃系统清单中移除
- [ ] 系统在合规架构中状态已更新为"已退役"

### 退役后
- [ ] 验证文档已归档（URS、VP、IQ/OQ/PQ、TM、VSR）
- [ ] SOP 已退役或更新以删除对已退役系统的引用
- [ ] 培训记录已归档
- [ ] 变更控制记录已归档
- [ ] 审计追踪已归档
- [ ] 退役报告已完成并获得批准

### 退役报告
| 章节 | 内容 |
|------|------|
| 系统描述 | 名称、版本、用途、GxP 分类 |
| 退役理由 | 系统退役的原因 |
| 数据处置摘要 | 数据去向（迁移、归档、销毁） |
| 验证证据 | 迁移验证结果、归档验证 |
| 残余风险 | 任何持续的数据保留义务 |
| 批准 | 系统负责人、QA、IT 签名 |

预期结果： 退役是受控的、有记录的、经批准的——不仅仅是"关机"。 失败处理： 若任何清单项无法完成，记录例外情况并在继续前获得 QA 批准。

验证清单

• 所有数据类别的数据保留要求已评估
• 数据迁移已通过记录数、抽样和校验和验证（如适用）
• 归档以无需源系统可读的格式创建
• 归档完整性已通过校验和验证
• 所有用户访问权限已撤销
• 验证文档已归档并有明确的保留期
• SOP 已更新以删除对已退役系统的引用
• 退役报告已由系统负责人、QA 和 IT 批准

常见问题

• 过早退役：在数据迁移验证之前关闭系统可能导致永久性数据丢失。在拔掉电源之前完成所有验证
• 归档不可读：以需要原始系统才能读取的专有格式存储数据，使归档失去意义。使用开放格式
• 遗忘审计追踪：归档数据但不归档审计追踪意味着数据来源无法证明，始终将审计追踪与其父记录一起归档
• 孤立 SOP：仍然引用已退役系统的 SOP 会使用户困惑并产生合规差距。更新或退役所有受影响的 SOP
• 无定期归档验证：归档会降级，没有定期完整性检查，数据丢失可能在检查需要数据时才被发现

相关技能

• design-compliance-architecture

  — 退役后更新系统清单和合规架构

• manage-change-control

  — 退役是需要变更控制的重大变更

• write-validation-documentation

  — 迁移验证遵循相同的 IQ/OQ 方法

• write-standard-operating-procedure

  — 退役或更新引用已退役系统的 SOP

• prepare-inspection-readiness

  — 归档数据必须在法规检查时保持可访问