MCP HubMCP Hub
← 返回技能列表

design-compliance-architecture

pjt222
更新于 Yesterday
4 次查看
17
2
17
在 GitHub 上查看
设计design

关于

This skill designs compliance architectures that map regulatory requirements to computerized systems. It handles system inventory, criticality classification (GxP critical/support/non-GxP), GAMP 5 categorization, and establishes traceability and governance structures. Use it when establishing new regulated facilities, formalizing compliance across multiple systems, conducting gap analyses, or preparing site master files.

快速安装

Claude Code

推荐
主要方式
npx skills add pjt222/agent-almanac -a claude-code
插件命令备选方式
/plugin add https://github.com/pjt222/agent-almanac
Git 克隆备选方式
git clone https://github.com/pjt222/agent-almanac.git ~/.claude/skills/design-compliance-architecture

在 Claude Code 中复制并粘贴此命令以安装该技能

技能文档

name: design-compliance-architecture description: > 设计将适用法规映射到计算机化系统的合规架构。涵盖系统清单、 关键性分类（GxP 关键、GxP 支持、非 GxP）、GAMP 5 类别分配、 法规要求追溯性及治理结构定义。适用于建立新的受监管设施、 跨多个系统正式规范合规性、解决法规差距分析、在并购或重组后 协调合规性，或准备引用计算机化系统的场所主文件时使用。 locale: zh-CN source_locale: en source_commit: 6f65f316 translator: claude-opus-4-6 translation_date: 2026-03-16 license: MIT allowed-tools: Read Write Edit Bash Grep Glob metadata: author: Philipp Thoss version: "1.0" domain: compliance complexity: advanced language: multi tags: gxp, compliance, architecture, regulatory, gamp-5, governance

设计合规架构

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

适用场景

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

输入

  • 必填：范围内计算机化系统清单（名称、用途、供应商/自研）
  • 必填：适用法规框架（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 系统需要更多测试
  • 静态架构：合规架构是一份活文档。新系统、法规变更和审计发现均需要更新
  • 有名无实的治理：存在于纸面但从不召开会议的委员会不提供任何合规价值。定义会议节奏和法定人数要求

相关技能

  • perform-csv-assessment — 对此处定义的验证策略中的各系统执行验证
  • manage-change-control — 将治理中定义的变更控制流程操作化
  • implement-electronic-signatures — 实施法规矩阵中映射的电子签名控制措施
  • prepare-inspection-readiness — 以此架构作为检查准备的基础
  • conduct-gxp-audit — 以合规架构作为基线进行审计

GitHub 仓库

pjt222/agent-almanac
路径: i18n/zh-CN/skills/design-compliance-architecture
0
agentsagentskillsai-assisted-developmentclaude-codeskillsteams

相关推荐技能

executing-plans

设计

该Skill用于当开发者提供完整实施计划时，以受控批次方式执行代码实现。它会先审阅计划并提出疑问，然后分批次执行任务（默认每批3个任务），并在批次间暂停等待审查。关键特性包括分批次执行、内置检查点和架构师审查机制，确保复杂系统实现的可控性。

查看技能

requesting-code-review

设计

该Skill可在完成任务、实现主要功能或合并代码前自动调度代码审查子代理，确保实现符合需求和计划。它支持通过指定git SHA范围进行精准的代码变更审查，帮助开发者在关键节点及时发现潜在问题。核心原则是"早审查、勤审查"，适用于开发流程的各个关键阶段。

查看技能

connect-mcp-server

设计

这个Skill指导开发者如何将MCP服务器连接到Claude Code，支持HTTP、stdio和SSE三种传输协议。它涵盖了从安装配置到认证安全的完整流程，适用于集成GitHub、Notion、数据库等外部服务。当开发者需要添加集成、配置外部工具或提及MCP相关功能时，这个Skill能提供实用的操作指南。

查看技能

web-cli-teleport

设计

该Skill帮助开发者根据任务特性选择Claude Code的Web或CLI界面，并指导如何在两种环境间无缝迁移会话。它能分析任务复杂度、迭代需求等要素，推荐最优工作界面和工作流。关键特性包括会话状态管理、环境切换指导和上下文优化建议。

查看技能