执行 CSV 评估

使用 GAMP 5 基于风险的方法，对受监管环境进行计算机系统验证评估。

适用场景

• GxP 环境中引入新计算机化系统
• 现有已验证系统发生重大变更
• 需要定期重新验证
• 法规检查准备需要验证差距分析

输入

• 必填：系统描述（名称、用途、供应商、版本）
• 必填：预期用途说明及法规背景（GxP 范围）
• 必填：GAMP 5 软件类别（1–5）
• 可选：现有用户需求规范（URS）
• 可选：供应商文档（设计规范、发布说明、SOP）
• 可选：以往验证文档

步骤

第 1 步：确定 GAMP 5 软件类别

对系统进行分类：

类别	类型	示例	验证工作量
1	基础软件	操作系统、固件	低——验证安装
3	非配置产品	原版 COTS	低至中——验证功能
4	已配置产品	带配置的 LIMS	中至高——验证配置
5	自定义应用	定制 R/Shiny 应用	高——全生命周期验证

预期结果： 已明确分配类别并记录依据。 失败处理： 若类别不明确，默认选择更高类别并记录依据。

第 2 步：编写用户需求规范（URS）

创建含编号需求的 URS 文档：

# 用户需求规范
## 系统：[系统名称] v[版本]
## 文档 ID：URS-[SYS]-[NNN]

### 1. 目的
[预期用途说明]

### 2. 功能需求
| ID | 需求 | 优先级 | 来源 |
|----|------|--------|------|
| URS-001 | 系统应根据身高和体重输入计算 BMI | 必须 | 法规 SOP-xxx |
| URS-002 | 系统应为所有数据更改生成审计追踪条目 | 必须 | 21 CFR 11.10(e) |
| URS-003 | 系统应以 PDF 格式导出结果 | 应该 | 用户请求 |

### 3. 非功能需求
| ID | 需求 | 优先级 | 来源 |
|----|------|--------|------|
| URS-010 | 标准查询的系统响应时间应在 3 秒以内 | 应该 | 可用性 |
| URS-011 | 系统应通过基于角色的身份验证限制访问 | 必须 | 21 CFR 11.10(d) |

### 4. 数据完整性需求
[ALCOA+ 需求：可归因、清晰、及时、原始、准确]

### 5. 法规需求
[具体适用的 21 CFR Part 11、EU Annex 11 或其他要求]

预期结果： 所有需求均有唯一 ID、优先级及对来源的追溯。 失败处理： 将来源或优先级不明确的需求标记以供利益相关方审核。

第 3 步：执行风险评估

使用故障模式及影响分析（FMEA）应用 GAMP 5 基于风险的方法：

# 风险评估
## 文档 ID：RA-[SYS]-[NNN]

| 需求 ID | 故障模式 | 严重性 (1-5) | 概率 (1-5) | 可检测性 (1-5) | RPN | 风险等级 | 缓解措施 |
|--------|---------|------------|----------|--------------|-----|---------|---------|
| URS-001 | BMI 计算错误 | 4 | 2 | 1 | 8 | 低 | OQ 测试用例 |
| URS-002 | 审计追踪条目缺失 | 5 | 3 | 3 | 45 | 高 | IQ + OQ + 监控 |
| URS-011 | 未经授权访问 | 5 | 2 | 2 | 20 | 中 | OQ 测试 + 定期审核 |

风险优先数（RPN）= 严重性 × 概率 × 可检测性。

RPN 范围	风险等级	测试要求
1–12	低	基本验证
13–36	中	有记录的测试用例
37+	高	完整 IQ/OQ/PQ 并重新测试

预期结果： 每个 URS 需求均有对应的风险评估行。 失败处理： 在继续前将未评估的需求升级至验证负责人。

第 4 步：定义验证策略（验证计划）

# 验证计划
## 文档 ID：VP-[SYS]-[NNN]

### 范围
- 系统：[名称] v[版本]
- GAMP 类别：[N]
- 验证方法：[前瞻性 / 回顾性 / 并发性]

### 确认阶段
| 阶段 | 范围 | 适用？ | 依据 |
|------|------|--------|------|
| IQ | 安装正确性 | 是 | 验证安装、依赖项、配置 |
| OQ | 操作需求 | 是 | 验证 URS 中的功能需求 |
| PQ | 真实条件下的性能 | [是/否] | [依据] |

### 角色与职责
| 角色 | 姓名 | 职责 |
|------|------|------|
| 验证负责人 | [姓名] | 计划、协调、批准 |
| 测试人员 | [姓名] | 执行测试脚本 |
| 系统负责人 | [姓名] | 批准用于生产 |
| QA | [姓名] | 审核和签字 |

### 验收标准
- 所有关键测试用例通过
- 无未解决的关键或重大偏差
- 追溯矩阵完整

预期结果： 验证计划在测试执行前获得所有利益相关方批准。 失败处理： 未获批准的验证计划不得进行测试执行。

第 5 步：创建测试协议（IQ/OQ/PQ）

为每个确认阶段编写测试脚本：

# 操作确认协议
## 测试用例：TC-OQ-001
## 追溯至：URS-001

**目标：** 验证 BMI 计算准确性

**前提条件：**
- 系统已按 IQ 协议安装
- 测试数据集已准备好

**测试步骤：**
| 步骤 | 操作 | 预期结果 | 实际结果 | 通过/失败 |
|------|------|---------|---------|---------|
| 1 | 输入身高=180cm，体重=75kg | BMI 显示为 23.15 | | |
| 2 | 输入身高=160cm，体重=90kg | BMI 显示为 35.16 | | |
| 3 | 输入身高=0，体重=75kg | 显示错误消息 | | |

**测试人员：** _________ 日期：_________
**审核人员：** _________ 日期：_________

预期结果： 每个中等和高风险需求至少有一个测试用例。 失败处理： 在执行开始前补充缺失的测试用例。

第 6 步：构建追溯矩阵

创建需求追溯矩阵（RTM），将每个需求通过风险评估链接到测试用例：

# 追溯矩阵
## 文档 ID：TM-[SYS]-[NNN]

| URS ID | 需求 | 风险等级 | 测试用例 | 测试结果 | 状态 |
|--------|------|---------|---------|---------|------|
| URS-001 | BMI 计算 | 低 | TC-OQ-001 | 通过 | 已验证 |
| URS-002 | 审计追踪 | 高 | TC-IQ-003, TC-OQ-005 | 通过 | 已验证 |
| URS-003 | PDF 导出 | 低 | TC-OQ-008 | 通过 | 已验证 |
| URS-011 | 基于角色的访问 | 中 | TC-OQ-010, TC-OQ-011 | 通过 | 已验证 |

预期结果： 100% 的 URS 需求出现在追溯矩阵中并链接了测试结果。 失败处理： 没有链接测试结果的任何需求均被标记为验证差距。

第 7 步：编写验证摘要报告

# 验证摘要报告
## 文档 ID：VSR-[SYS]-[NNN]

### 1. 执行摘要
[系统名称] v[版本] 已根据 [VP 文档 ID] 完成验证。

### 2. 已执行的验证活动
| 活动 | 文档 ID | 状态 |
|------|--------|------|
| 用户需求 | URS-SYS-001 | 已批准 |
| 风险评估 | RA-SYS-001 | 已批准 |
| 验证计划 | VP-SYS-001 | 已批准 |
| IQ 协议/报告 | IQ-SYS-001 | 已执行——通过 |
| OQ 协议/报告 | OQ-SYS-001 | 已执行——通过 |
| 追溯矩阵 | TM-SYS-001 | 完整 |

### 3. 偏差
| 偏差 ID | 描述 | 影响 | 解决方案 |
|--------|------|------|---------|
| DEV-001 | [描述] | [影响评估] | [解决方案和依据] |

### 4. 结论
该系统满足 [URS ID] 中记录的所有用户需求，验证被认为[成功/有条件成功]。

### 5. 批准
| 角色 | 姓名 | 签名 | 日期 |
|------|------|------|------|
| 验证负责人 | | | |
| 系统负责人 | | | |
| 质量保证 | | | |

预期结果： 报告引用了所有验证交付物，并有明确的通过/失败结论。 失败处理： 若偏差未解决，报告必须说明"有条件"状态并引用 CAPA。

验证清单

• GAMP 5 类别已分配并记录了依据
• URS 有带优先级和来源追溯的编号需求
• 风险评估涵盖每个 URS 需求
• 验证计划在测试执行前获得批准
• 测试协议具有前提条件、步骤、预期结果和签名字段
• 追溯矩阵将每个需求链接到风险和测试结果
• 验证摘要报告记录了所有活动、偏差和结论
• 所有文档均有唯一文档 ID 和版本控制

常见问题

• 过度验证：对 Category 3 软件应用 Category 5 的工作量浪费资源，应根据风险匹配工作量
• 缺少追溯性：不追溯到测试用例的需求是看不见的差距
• 无计划执行测试：在验证计划批准前执行测试会使结果无效
• 忽视非功能需求：安全、性能和数据完整性需求经常被遗漏
• 静态验证：将验证视为一次性事件，变更需要重新评估

相关技能

• setup-gxp-r-project

  — 已验证 R 环境的项目结构

• write-validation-documentation

  — IQ/OQ/PQ 协议和报告编写

• implement-audit-trail

  — 电子记录的审计追踪实施

• validate-statistical-output

  — 统计输出验证方法

• conduct-gxp-audit

  — 审计已验证系统