MCP HubMCP Hub
← Retour aux compétences

design-compliance-architecture

pjt222
Mis à jour Yesterday
3 vues
17
2
17
Voir sur GitHub
Designdesign

À propos

Cette compétence conçoit des architectures de conformité qui cartographient les exigences réglementaires sur les systèmes informatisés. Elle gère l'inventaire des systèmes, la classification de criticité (critique GxP/de support/non-GxP), la catégorisation GAMP 5, et établit des structures de traçabilité et de gouvernance. Utilisez-la lors de la mise en place de nouvelles installations réglementées, de la formalisation de la conformité sur plusieurs systèmes, de la réalisation d'analyses d'écart ou de la préparation de dossiers maîtres de site.

Installation rapide

Claude Code

Recommandé
Principal
npx skills add pjt222/agent-almanac -a claude-code
Commande PluginAlternatif
/plugin add https://github.com/pjt222/agent-almanac
Git CloneAlternatif
git clone https://github.com/pjt222/agent-almanac.git ~/.claude/skills/design-compliance-architecture

Copiez et collez cette commande dans Claude Code pour installer cette compétence

Documentation

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 — 以合规架构作为基线进行审计

Dépôt GitHub

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

Compétences associées

executing-plans

Design

Utilisez la compétence executing-plans lorsque vous disposez d'un plan de mise en œuvre complet à exécuter par lots contrôlés avec des points de contrôle de revue. Elle charge et examine le plan de manière critique, puis exécute les tâches par petits lots (3 tâches par défaut) tout en rapportant la progression entre chaque lot pour une revue par l'architecte. Cela garantit une mise en œuvre systématique avec des points de contrôle de qualité intégrés.

Voir la compétence

requesting-code-review

Design

Cette compétence délègue un sous-agent réviseur de code pour analyser les modifications apportées au code par rapport aux exigences avant de poursuivre. Elle doit être utilisée après avoir terminé des tâches, implémenté des fonctionnalités majeures, ou avant une fusion vers la branche principale. La revue aide à détecter précocement les problèmes en comparant l'implémentation actuelle avec le plan initial.

Voir la compétence

connect-mcp-server

Design

Cette compétence fournit un guide complet permettant aux développeurs de connecter des serveurs MCP à Claude Code via les transports HTTP, stdio ou SSE. Elle couvre l'installation, la configuration, l'authentification et la sécurité pour intégrer des services externes tels que GitHub, Notion et des API personnalisées. Utilisez-la lors de la configuration d'intégrations MCP, de la configuration d'outils externes ou du travail avec le Protocole de Contexte de Modèle de Claude.

Voir la compétence

web-cli-teleport

Design

Cette compétence aide les développeurs à choisir entre les interfaces Web et CLI de Claude Code en fonction de l'analyse des tâches, puis permet une téléportation transparente des sessions entre ces environnements. Elle optimise le flux de travail en gérant l'état et le contexte de la session lors du passage entre le web, la CLI ou le mobile. Utilisez-la pour des projets complexes nécessitant différents outils à diverses étapes.

Voir la compétence