# Perform CSV Assessment

> 按照 GAMP 5 方法执行计算机系统验证（CSV）评估。涵盖用户需求、 风险评估、IQ/OQ/PQ 规划、追溯矩阵创建和验证摘要报告。适用于 GxP 环境中引入新计算机化系统、现有已验证系统发生重大变更、 需要定期重新验证，或法规检查要求验证差距分析时使用。

- Skill: `pjt222/perform-csv-assessment-4` (Agent Skill)
- Install (CLI): `npx skillmds@latest add pjt222/perform-csv-assessment-4`
- Raw SKILL.md: https://api.skillmd.com/api/skills/pjt222/perform-csv-assessment-4/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Data & Analytics
- License: MIT
- Author: pjt222 (https://skillmd.com/u/pjt222)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/pjt222/perform-csv-assessment-4

---


# 执行 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 文档：

```markdown
# 用户需求规范
## 系统：[系统名称] 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 基于风险的方法：

```markdown
# 风险评估
## 文档 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 步：定义验证策略（验证计划）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

### 第 6 步：构建追溯矩阵

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

```markdown
# 追溯矩阵
## 文档 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 步：编写验证摘要报告

```markdown
# 验证摘要报告
## 文档 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` — 审计已验证系统