4. 患者身份与同意管理工程

在去中心化临床试验（DCT）中，患者不再集中出现在单一研究中心，而是通过手机、平板或家用电脑完成注册、身份核验、签署同意书并持续接收随访任务。身份与同意管理因此从“纸质表单+现场签字”的行政动作，升级为贯穿整个试验生命周期的工程子系统。它要同时回答三个问题：这个人是不是他声称的那个人、他是否在充分理解后自愿同意、他此刻的同意范围是否仍然有效。三者缺一不可，且必须留下可独立验证的审计证据。

远程身份验证：分层核验而非单点判断

远程身份验证的目标不是“证明患者存在”，而是把受试者与一个唯一、可追溯的身份绑定，并满足法规对身份确认（identity confirmation）的要求。工程上通常采用分层策略：第一层是账户层，用邮箱或手机号加一次性验证码建立联系通道；第二层是证件层，通过证件 OCR 提取姓名、证件号、有效期，并与患者自填信息比对；第三层是活体层，用自拍视频或动作指令（如眨眼、转头）做活体检测，再与证件照片做人脸比对，输出相似度分值。

以某远程试验的示例参数为例：证件 OCR 字段置信度阈值设为 0.90，低于阈值转人工复核；人脸比对相似度阈值设为 0.75，0.75～0.85 之间进入人工复核队列，高于 0.85 自动通过。这些阈值属于示例配置，实际项目需依据监管要求、人群特征和供应商能力校准。核验结果应写入身份事件表，记录时间戳、设备指纹、IP 归属地、算法版本和分值，而不是只存一个“通过/不通过”的布尔值。当患者更换设备或长时间未登录时，应触发再核验，防止账户被他人接管。

eConsent 工作流：从签署到生效的完整链路

电子知情同意（eConsent）不是把 PDF 搬到网页上，而是一条有状态的工作流。典型链路为：研究者发起同意任务 → 患者收到带时效的签署链接 → 患者阅读分层知情材料 → 完成理解力测验 → 电子签名 → 系统生成带哈希的同意记录 → 研究者或授权人员复核并激活。其中理解力测验是 DCT 场景的关键补强，因为缺少现场研究者的即时答疑，必须用题目确认患者真正理解了风险、退出权和数据使用范围。

签署完成后，系统应对同意书正文、附件、签名图像和元数据计算 SHA-256 哈希，并将哈希写入审计日志。任何后续修改都会导致哈希变化，从而可被检测。同意记录应包含：受试者编号、同意书版本号、签署时间（含时区）、签署方式（手写、键入、点击确认）、IP 与设备信息、理解力测验得分、复核人及复核时间。这些字段共同构成“同意是否有效”的证据链。

动态同意管理：同意不是一次性事件

传统知情同意在签署那一刻结束，而 DCT 中的同意是持续状态。患者可能先同意主试验，之后被询问是否参加可选子研究、是否允许样本长期保存、是否同意将数据用于未来研究。这些范围应被建模为独立的同意项（consent item），每项有独立的状态：未询问、已同意、已拒绝、已撤回。当方案修订导致同意书升级时，系统应识别哪些患者受影响，自动生成再同意任务，并设定截止时间；逾期未再同意的患者，其数据采集范围应被自动收窄，而不是继续按旧版本收集。

撤回同样需要工程化处理。患者撤回“未来研究使用”但保留“主试验参与”时，系统应停止向生物样本库传输新数据，但保留已合法收集的数据，并在审计日志中记录撤回时间、撤回范围、执行人和下游系统同步结果。这种“部分撤回”能力是动态同意区别于静态表单的核心。

版本控制与审计追踪

版本控制要解决三个对象的版本：同意书文档版本、同意项配置版本、系统算法版本（如人脸比对模型）。三者应分别编号并相互引用。审计追踪则要求任何对同意记录的读取、修改、导出都留痕，且日志本身不可被普通管理员删除。工程实现上常用追加写（append-only）存储或哈希链：每条日志包含前一条的哈希，形成链式结构，篡改任一条都会导致后续哈希不匹配。

多语言与可访问性

多语言不是简单翻译。医学术语、风险描述和退出权说明必须经过术语表统一、母语者审校和回译校验，确保不同语言版本语义等价。每个语言版本应独立计算哈希并绑定版本号，避免“中文版更新了、英文版没更新”导致同意范围不一致。可访问性方面，应支持屏幕阅读器语义标签、字幕、大字号模式和高对比配色；理解力测验题目也需本地化，不能只翻译题干而忽略文化差异。对于老年或低数字素养人群，可提供语音朗读和图示化摘要作为辅助通道，但辅助通道不能替代正式签署记录。

可参考的同意记录字段清单

把上述字段、状态机和审计链落到系统里，身份与同意管理才真正成为 DCT 平台的可信基座：患者身份可核验、同意范围可动态调整、版本可追溯、日志可审计、语言与无障碍通道可覆盖更广泛人群。任何一环缺失，都会在监管核查或患者权益保护上留下风险敞口。