Agent-almanac design-compliance-architecture

install

source · Clone the upstream repo

git clone https://github.com/pjt222/agent-almanac

Claude Code · Install into ~/.claude/skills/

T=$(mktemp -d) && git clone --depth=1 https://github.com/pjt222/agent-almanac "$T" && mkdir -p ~/.claude/skills && cp -r "$T/i18n/zh-CN/skills/design-compliance-architecture" ~/.claude/skills/pjt222-agent-almanac-design-compliance-architecture-b4b1e0 && rm -rf "$T"

manifest: i18n/zh-CN/skills/design-compliance-architecture/SKILL.md

source content

设计合规架构

建立顶层合规框架，将法规映射到系统，对关键性进行分类，并为受监管环境定义治理结构。

适用场景

建立新的受监管设施、部门或项目
现有组织需要跨多个系统正式规范其合规立场
法规差距分析揭示系统分类或验证策略缺失
并购或重组需要协调各实体的合规性
准备引用计算机化系统的场所主文件或质量手册

输入

必填：范围内计算机化系统清单（名称、用途、供应商/自研）
必填：适用法规框架（21 CFR Part 11、EU Annex 11、GMP、GLP、GCP、ICH Q7、ICH Q10）
必填：组织背景（部门、场所、产品类型）
可选：现有验证主计划或质量手册
可选：以往审计发现或法规检查观察
可选：含质量和 IT 汇报线的组织架构图

步骤

第 1 步：构建系统清单

创建所有计算机化系统的综合清单：

# 系统清单
## 文档 ID：SI-[SITE]-[YYYY]-[NNN]

| ID | 系统名称 | 版本 | 供应商 | 用途 | 部门 | 数据类型 | 用户数 |
|----|---------|------|--------|------|------|---------|--------|
| SYS-001 | LabWare LIMS | 8.1 | LabWare Inc. | 样品管理和检测 | QC | 检测结果、COA | 45 |
| SYS-002 | SAP ERP | S/4HANA | SAP SE | 批次放行和库存管理 | 生产 | 批记录、BOM | 120 |
| SYS-003 | 自研 R/Shiny | 2.1.0 | 内部 | 统计分析 | 生物统计 | 临床数据 | 8 |
| SYS-004 | Windows Server | 2022 | Microsoft | 文件服务器 | IT | 文档 | 200 |

预期结果： 所有创建、修改、存储、检索或传输 GxP 相关数据的系统均已列入清单。 失败处理： 若系统负责人无法提供完整信息，记录差距并安排发现研讨会。缺失的系统是关键合规风险。

第 2 步：对系统关键性进行分类

为每个系统分配关键性层级：

# 系统关键性分类
## 文档 ID：SCC-[SITE]-[YYYY]-[NNN]

### 分类标准

| 层级 | 定义 | 所需验证 | 示例 |
|------|------|---------|------|
| **GxP 关键** | 直接影响产品质量、患者安全或数据完整性，生成或处理 GxP 记录 | 按 GAMP 5 进行完整 CSV | LIMS、ERP（批次）、CDMS、MES |
| **GxP 支持** | 支持 GxP 流程但不直接生成 GxP 记录，故障有间接影响 | 基于风险的确认 | 电子邮件、文档管理、排班 |
| **非 GxP** | 对产品质量、安全或数据完整性无影响 | 仅 IT 标准控制措施 | 人力资源系统、餐厅、通用网络 |

### 系统分类矩阵

| 系统 ID | 系统 | 层级 | 依据 |
|--------|------|------|------|
| SYS-001 | LabWare LIMS | GxP 关键 | 生成用于批次放行的检测结果 |
| SYS-002 | SAP ERP | GxP 关键 | 管理批记录和物料追溯性 |
| SYS-003 | R/Shiny 应用 | GxP 关键 | 执行用于法规申报的统计分析 |
| SYS-004 | Windows Server | GxP 支持 | 存储受控文档但不生成 GxP 数据 |

预期结果： 每个系统均有带记录依据的层级分配。 失败处理： 若系统关键性存在争议，升级至质量委员会。有疑问时，选择高一级别并在正式风险评估后重新评估。

第 3 步：分配 GAMP 5 软件类别

为每个 GxP 关键和 GxP 支持系统分配 GAMP 5 类别：

# GAMP 5 类别分配

| 系统 ID | 系统 | GAMP 类别 | 依据 | 验证工作量 |
|--------|------|----------|------|----------|
| SYS-001 | LabWare LIMS | 4——已配置产品 | 带大量工作流配置的 COTS | 中至高 |
| SYS-002 | SAP ERP | 4——已配置产品 | 带自定义事务的 COTS | 中至高 |
| SYS-003 | R/Shiny 应用 | 5——自定义应用 | 内部开发 | 高——全生命周期 |
| SYS-004 | Windows Server | 1——基础软件 | 操作系统，无自定义配置 | 低——验证安装 |

类别参考：

Category 1：基础软件（操作系统、固件）——验证安装
Category 3：非配置 COTS——按原样验证功能
Category 4：已配置产品——验证所有配置
Category 5：自定义应用——全生命周期验证

预期结果： 类别分配反映系统的使用方式，而非仅是系统的性质。 失败处理： 若系统跨越多个类别（如带自定义插件的 COTS），对自定义部分按 Category 5 分类，基础部分按 Category 4 分类。

第 4 步：将法规要求映射到系统

创建法规要求追溯矩阵：

# 法规要求追溯矩阵
## 文档 ID：RRTM-[SITE]-[YYYY]-[NNN]

| 法规 | 条款 | 要求 | 适用系统 | 控制类型 |
|------|------|------|---------|---------|
| 21 CFR 11 | 11.10(a) | 验证 | SYS-001, SYS-002, SYS-003 | 程序性 + 技术性 |
| 21 CFR 11 | 11.10(d) | 访问控制 | SYS-001, SYS-002, SYS-003, SYS-004 | 技术性 |
| 21 CFR 11 | 11.10(e) | 审计追踪 | SYS-001, SYS-002, SYS-003 | 技术性 |
| 21 CFR 11 | 11.50 | 签名表现形式 | SYS-001, SYS-002 | 技术性 |
| EU Annex 11 | §4 | 验证 | SYS-001, SYS-002, SYS-003 | 程序性 + 技术性 |
| EU Annex 11 | §7 | 数据存储和备份 | 全部 | 技术性 |
| EU Annex 11 | §9 | 审计追踪 | SYS-001, SYS-002, SYS-003 | 技术性 |
| EU Annex 11 | §12 | 安全与访问 | 全部 | 技术性 |
| ICH Q10 | §3.2 | 变更管理 | 所有 GxP 关键系统 | 程序性 |
| ICH Q10 | §1.8 | 知识管理 | SYS-001, SYS-003 | 程序性 |

预期结果： 每个适用的法规条款至少映射到一个系统，每个 GxP 关键系统映射到相关法规条款。 失败处理： 未映射的条款代表合规差距。为每个差距制定带时间表的整改计划。

第 5 步：定义每个系统的验证策略

根据关键性、类别和法规映射：

# 验证策略摘要

| 系统 | 类别 | 关键性 | 验证方法 | 关键交付物 |
|------|------|--------|---------|---------|
| LabWare LIMS | 4 | 关键 | 前瞻性 CSV | URS, RA, VP, IQ, OQ, PQ, TM, VSR |
| SAP ERP | 4 | 关键 | 前瞻性 CSV | URS, RA, VP, IQ, OQ, TM, VSR |
| R/Shiny 应用 | 5 | 关键 | 前瞻性 CSV + 代码审查 | URS, RA, VP, IQ, OQ, PQ, TM, VSR, 代码审计 |
| Windows Server | 1 | 支持 | 安装确认 | IQ 清单 |

缩写说明：URS（用户需求）、RA（风险评估）、VP（验证计划）、IQ/OQ/PQ（安装/操作/性能确认）、TM（追溯矩阵）、VSR（验证摘要报告）。

预期结果： 验证工作量与风险相称——Category 5 GxP 关键系统进行全生命周期验证；Category 1 基础设施进行简化 IQ。 失败处理： 若利益相关方要求减少关键系统的验证，记录风险接受并由 QA 签字。

第 6 步：设计治理结构

定义维持合规的组织框架：

# 合规治理结构

## 角色与职责
| 角色 | 职责 | 权限 |
|------|------|------|
| 质量总监 | 整体合规责任 | 批准验证策略，接受风险 |
| 系统负责人 | 日常系统合规管理 | 批准变更，确保已验证状态 |
| 验证负责人 | 计划和协调验证活动 | 定义验证范围和方法 |
| IT 运营 | 技术基础设施和安全 | 实施技术控制措施 |
| QA 审核员 | 独立审核验证交付物 | 接受或拒绝验证证据 |

## 治理委员会
| 委员会 | 频率 | 目的 | 成员 |
|--------|------|------|------|
| 变更控制委员会 | 每周 | 审查和批准系统变更 | 系统负责人、QA、IT、验证 |
| 定期审核委员会 | 每季度 | 审核系统合规状态 | 质量总监、系统负责人、QA |
| 审计计划委员会 | 每年 | 规划内部审计计划 | 质量总监、主审计员、QA |

## 升级矩阵
| 问题 | 第一级升级 | 第二级升级 | 时间表 |
|------|----------|----------|--------|
| 关键审计发现 | 系统负责人 → QA 总监 | QA 总监 → 场所总监 | 24 小时 |
| 已验证状态破坏 | 验证负责人 → 系统负责人 | 系统负责人 → 质量总监 | 48 小时 |
| 数据完整性事故 | 系统负责人 → QA 总监 | QA 总监 → 监管事务 | 24 小时 |

预期结果： 每项合规活动均有明确责任人，无孤立职责。 失败处理： 若角色重叠或未分配，召开 RACI 研讨会解决。职责模糊是监管机构反复引用的问题。

第 7 步：汇编合规架构文档

将所有组件整合到主文档中：

# 合规架构
## 文档 ID：CA-[SITE]-[YYYY]-[NNN]
## 版本：1.0

### 1. 目的和范围
[组织、场所、产品范围、法规范围]

### 2. 系统清单
[来自第 1 步]

### 3. 关键性分类
[来自第 2 步]

### 4. GAMP 5 类别分配
[来自第 3 步]

### 5. 法规要求追溯性
[来自第 4 步]

### 6. 验证策略
[来自第 5 步]

### 7. 治理结构
[来自第 6 步]

### 8. 定期审核计划
- 系统清单刷新：每年
- 关键性重新评估：当新系统加入或法规变更时
- 法规映射更新：当新指南发布时
- 治理审核：每年或组织变更后

### 9. 批准
| 角色 | 姓名 | 签名 | 日期 |
|------|------|------|------|
| 质量总监 | | | |
| IT 总监 | | | |
| 监管事务 | | | |

预期结果： 单一文档作为整个受监管环境的合规蓝图。 失败处理： 若文档超出实际规模，创建主文档并按系统或领域引用子文档。

验证清单

系统清单包含所有处理 GxP 数据的系统
每个系统均有带记录依据的关键性层级
所有 GxP 关键和 GxP 支持系统已分配 GAMP 5 类别
法规要求追溯矩阵涵盖所有适用条款
每个 GxP 关键系统均已定义验证策略
治理结构定义了角色、委员会和升级路径
所有文档均有唯一 ID 和版本控制
合规架构文档已由质量和 IT 领导层批准

常见问题

清单不完整：缺失的系统对合规不可见。使用网络扫描、软件资产管理工具和部门访谈——不要仅询问 IT
非此即彼的思维：系统不简单地分为"GxP"或"非 GxP"。三层模型（关键、支持、非 GxP）避免了过度验证和验证不足
类别混淆：GAMP 5 类别描述软件是什么，但验证工作量应反映其使用方式。用于批次放行的 Category 4 系统比用于排班的 Category 4 系统需要更多测试
静态架构：合规架构是一份活文档。新系统、法规变更和审计发现均需要更新
有名无实的治理：存在于纸面但从不召开会议的委员会不提供任何合规价值。定义会议节奏和法定人数要求