Agent-almanac implement-electronic-signatures

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/implement-electronic-signatures" ~/.claude/skills/pjt222-agent-almanac-implement-electronic-signatures-da6674 && rm -rf "$T"
manifest: i18n/zh-CN/skills/implement-electronic-signatures/SKILL.md
source content

实施电子签名

设计和实施满足 21 CFR Part 11 C 子部分及 EU Annex 11 受监管电子记录要求的电子签名控制措施。

适用场景

  • 计算机化系统需要对 GxP 记录进行具有法律约束力的电子签名
  • 在受监管工作流程中用电子签名替换手写签名
  • 实施批次放行、文件审批或数据签字的审批工作流程
  • 法规差距评估揭示缺少签名控制措施
  • 构建或配置必须符合 21 CFR 11.50–11.300 的系统

输入

  • 必填:系统描述和签名使用场景(哪些记录需要签名)
  • 必填:适用法规(21 CFR Part 11、EU Annex 11、具体 GxP 背景)
  • 必填:所需签名类型(审批、审核、确认、起草)
  • 可选:当前认证基础设施(Active Directory、LDAP、SSO)
  • 可选:现有电子签名政策或 SOP
  • 可选:关于签名功能的系统供应商文档

步骤

第 1 步:评估电子签名要求的适用性

确定适用的 21 CFR Part 11 C 子部分条款:

# 电子签名适用性评估
## 文档 ID:ESA-[SYS]-[YYYY]-[NNN]

### 法规范围
| 条款 | 章节 | 要求 | 适用? | 依据 |
|------|------|------|--------|------|
| 通用要求 | 11.50 | 已签名记录包含姓名、日期/时间、含义 | 是/否 | [依据] |
| 他人代签 | 11.50 | 签名不得共享或转让 | 是/否 | [依据] |
| 签名绑定 | 11.70 | 签名与记录绑定,使其无法被伪造 | 是/否 | [依据] |
| 电子签名通用要求 | 11.100 | 对个人唯一,使用前经验证 | 是/否 | [依据] |
| 非生物特征控制措施 | 11.200 | 首次签名时使用两个不同的标识组件 | 是/否 | [依据] |
| 生物特征控制措施 | 11.200 | 防止他人使用,仅限真正持有人 | 是/否 | [依据] |
| 向 FDA 认证 | 11.300 | 组织认证电子签名具有法律约束力 | 是/否 | [依据] |

### 签名使用场景
| 使用场景 | 记录类型 | 含义 | 频率 | 当前方法 |
|---------|---------|------|------|---------|
| 批次放行 | 批记录 | "批准放行" | 每日 | 手写签名 |
| 文件审批 | SOP | "已批准" | 每周 | 手写签名 |
| 数据审核 | 实验室结果 | "已审核并验证" | 每日 | 手写签名 |
| 偏差关闭 | 偏差报告 | "已关闭——CAPA 有效" | 按需 | 手写签名 |

预期结果: 每个签名使用场景均有记录的法规依据和明确的含义。 失败处理: 若某使用场景不需要 21 CFR 11 合规(如非 GxP 记录),记录排除依据并应用相应的控制措施。

第 2 步:设计签名表现形式

按照 21 CFR 11.50 定义签名必须显示的信息:

# 签名表现形式规范

### 必要表现形式要素(21 CFR 11.50)
每个电子签名必须显示:
1. 签名人的**印刷姓名**
2. 签名应用的**日期和时间**(ISO 8601 格式)
3. 签名的**含义**(如"已批准"、"已审核"、"起草人")

### 表现形式格式
| 要素 | 来源 | 格式 | 示例 |
|------|------|------|------|
| 姓名 | 用户目录(AD/LDAP) | "姓 名" | "张三" |
| 日期/时间 | 系统时钟(NTP 同步) | YYYY-MM-DDTHH:MM:SS±TZ | 2026-02-09T14:30:00+08:00 |
| 含义 | 签名类型定义 | 预定义列表 | "批准放行" |

### 签名含义注册表
| 代码 | 含义 | 用于 | 权限级别 |
|------|------|------|---------|
| APPROVE | "已批准" | 文件和记录的最终批准 | 经理及以上 |
| REVIEW | "已审核并验证" | 数据的技术审核 | 合格审核员 |
| AUTHOR | "起草人" | 文件创建 | 起草人 |
| CLOSE | "已关闭——纠正措施已验证" | CAPA 和偏差关闭 | QA |

预期结果: 签名表现形式无歧义——任何查看已签名记录的人都能确认签名人、签名时间和签名原因。 失败处理: 若系统无法在记录视图中显示所有三个要素,实施可从已签名记录访问的签名详情页面。

第 3 步:实施签名与记录绑定

确保签名不能从记录中删除、复制或转移(21 CFR 11.70):

# 签名绑定规范

### 绑定方法
| 方法 | 机制 | 强度 | 适用场景 |
|------|------|------|---------|
| **密码学** | 带 PKI 证书的数字签名 | 最强——防篡改 | 自定义应用、高风险记录 |
| **数据库引用** | 将签名表链接到记录表的外键约束 | 强——数据库强制执行 | 带关系数据库的已配置 COTS |
| **应用强制** | 应用逻辑防止签名修改 | 中等——依赖应用安全性 | 带签名模块的供应商系统 |

### 选定方法:[密码学 / 数据库引用 / 应用强制]

### 绑定要求
- [ ] 签名不能在未检测到的情况下从记录中删除
- [ ] 签名不能被复制到另一条记录
- [ ] 签名后的记录不能在不使签名失效的情况下被修改
- [ ] 签名审计追踪记录所有签名事件(应用、作废、重新签名)
- [ ] 绑定在记录导出时保留(PDF、打印件包含签名元数据)

预期结果: 已签名记录与其签名不可分割——修改其中任何一个都会使绑定失效。 失败处理: 若系统在技术层面无法强制绑定,实施程序性控制措施(双重监管、定期核对)并记录补偿性控制措施。

第 4 步:配置认证控制措施

按 21 CFR 11.100 和 11.200 实施身份验证要求:

# 认证配置

### 身份验证(11.100)
- [ ] 每个签名人有唯一用户身份(无共享账户)
- [ ] 身份通过至少两种方式验证:知道的、拥有的或具备的
- [ ] 身份分配已记录并由安全官员批准
- [ ] 定期身份重新验证(至少每年一次)

### 非生物特征控制措施(11.200(a))
对于非生物特征签名(用户名 + 密码):

**会话首次签名:**
- 同时要求标识(用户名)和认证(密码)
- 首次使用时的两个不同标识组件

**后续签名(同一会话):**
- 至少一个标识组件(如重新输入密码)
- 会话超时:[定义最大空闲时间,如 15 分钟]

**连续会话签名:**
- 若一个不间断会话中有多次签名,每次签名均需重新输入密码
- 系统检测会话连续性(未登出、未超时、未锁定工作站)

### 密码策略(支持 11.200)
| 参数 | 要求 |
|------|------|
| 最小长度 | 12 个字符 |
| 复杂性 | 大写 + 小写 + 数字 + 特殊字符 |
| 有效期 | 90 天(或按组织政策) |
| 历史记录 | 不能重复使用最近 12 个密码 |
| 锁定 | 5 次失败后锁定 30 分钟 |
| 初始密码 | 首次使用时必须更改 |

预期结果: 认证确保只有已标识的个人才能应用其签名。 失败处理: 若系统不支持会话感知签名控制措施,要求每次签名事件进行完整重新认证(用户名 + 密码)。

第 5 步:创建电子签名政策

# 电子签名政策
## 文档 ID:ESP-[ORG]-[YYYY]-[NNN]

### 1. 目的
本政策规定对 GxP 电子记录使用电子签名作为手写签名具有法律约束力等效物的要求。

### 2. 范围
适用于合规架构(CA-[SITE]-[YYYY]-[NNN])中列出的、需要对 GxP 记录签名的所有计算机化系统。

### 3. 定义
- **电子签名**:由个人执行、采用或授权的任何符号或符号系列的计算机数据编译,用于作为个人手写签名的具有法律约束力的等效物。
- **生物特征**:基于物理特征测量(指纹、视网膜、声纹)验证个人身份的方法。
- **非生物特征**:使用标识码(用户名)和密码组合的方法。

### 4. 要求
4.1 所有电子签名应包含印刷姓名、日期/时间和含义。
4.2 每个人应有唯一的电子签名,不得共享。
4.3 签名应与其各自记录绑定,使其无法被伪造。
4.4 在个人使用电子签名之前,组织应验证其身份。
4.5 个人必须证明其电子签名旨在作为手写签名的具有法律约束力的等效物。

### 5. 用户认证
每位用户在首次使用前必须签署电子签名认证表:

"本人 [全名] 证明,在 [系统名称] 中使用的电子签名是本人手写签名的具有法律约束力的等效物。本人了解本人对在电子签名下执行的所有操作负有个人责任。"

签名:_____________ 日期:_____________

### 6. FDA 认证(11.300)
组织应向 FDA 提交认证,证明其系统中使用的电子签名旨在作为手写签名的具有法律约束力的等效物。

预期结果: 政策文件在电子签名上线前获得质量、IT 和法律/监管事务部门的批准。 失败处理: 若法律顾问尚未审核政策,将其标记为合规风险,并在首次使用电子签名前获得法律审核。

第 6 步:验证实施

对所有签名控制措施执行验证测试:

# 电子签名验证协议

| 测试 ID | 测试用例 | 预期结果 | 实际结果 | 通过/失败 |
|--------|---------|---------|---------|---------|
| ES-001 | 对记录应用签名 | 显示姓名、日期/时间、含义 | | |
| ES-002 | 尝试修改已签名记录 | 系统阻止修改或使签名失效 | | |
| ES-003 | 尝试将签名复制到不同记录 | 系统阻止或签名无效 | | |
| ES-004 | 使用错误密码签名 | 签名被拒绝,失败尝试已记录 | | |
| ES-005 | 会话超时后签名 | 需要完整重新认证 | | |
| ES-006 | 连续会话中签名 | 需要重新输入密码 | | |
| ES-007 | 以其他用户身份查看已签名记录 | 签名详情可见但不可编辑 | | |
| ES-008 | 将已签名记录导出为 PDF | PDF 包含签名元数据 | | |
| ES-009 | 尝试使用他人凭据 | 系统检测并拒绝 | | |
| ES-010 | 验证审计追踪捕获签名事件 | 时间戳、用户、含义、记录 ID 已记录 | | |

预期结果: 所有测试用例通过,证明签名控制措施满足法规要求。 失败处理: 失败的测试用例在系统上线前需要整改,将失败记录为偏差并通过变更控制追踪解决。

验证清单

  • 适用性评估记录了适用的 21 CFR 11 C 子部分条款
  • 每个使用场景的签名表现形式包含姓名、日期/时间和含义
  • 签名绑定防止签名的删除、复制或转移
  • 认证要求在首次签名时使用两个不同的标识组件
  • 密码策略满足最低安全要求
  • 电子签名政策已由质量、IT 和法律部门批准
  • 所有签名人的用户认证表已收集
  • FDA 认证已提交(如 11.300 要求)
  • 所有签名控制措施的验证测试通过

常见问题

  • 混淆认证与电子签名:登录是认证;对记录签名是电子签名。两者有不同的法规要求
  • 共享账户:任何有共享账户的系统都无法拥有合规的电子签名,在实施电子签名前解决共享账户问题
  • 缺少含义:显示姓名和日期但不显示含义("已批准"、"已审核")的签名不满足 21 CFR 11.50
  • 会话处理:在不重新认证的情况下允许连续会话签名,会削弱签名的身份保证
  • 忘记 11.300 认证:在 FDA 受监管背景下使用电子签名的组织必须向 FDA 认证其签名具有法律约束力

相关技能

  • design-compliance-architecture
    — 跨系统映射电子签名要求
  • implement-audit-trail
    — 审计追踪捕获签名事件
  • write-validation-documentation
    — 验证测试是 OQ 文档的一部分
  • write-standard-operating-procedure
    — 电子签名使用的 SOP
  • manage-change-control
    — 签名配置的变更通过变更控制