如果把新版《药物临床试验质量管理规范》只理解为“电子签名规则变严了”，就会低估这次变化。2026年9月1日起，监管追问的不再只是一份文件有没有签名，而是：签署人是谁、看的是哪一版、为什么有权签、是否真正理解并作出意思表示、签后有没有被改动，以及多年后能否完整还原。
签名有效解决的是一个法律与技术节点；临床试验合规面对的，却是一条由研究方案、受试者保护、数据治理、授权管理、系统验证和检查证据共同组成的责任链。本文把新版GCP、ICH E6(R3)与电子签约工程放进同一张图里，给申办者、研究机构、SMO/CRO、伦理委员会与信息化团队一套可以直接用于整改立项和验收的框架。
监管人员抽查一份电子知情同意书，真正会问什么？
最危险的答案不是“我们没有电子签名”，而是“系统显示签署成功”，除此以外再也解释不清。
设想一次现场检查：检查员抽取某位受试者的电子知情同意书。系统能够打开PDF，页面上有签名图片、有签署时间，甚至还有第三方存证编号。表面看起来万无一失。但检查不会停在这里。
文件问题
受试者看到的是否为当时伦理批准、已生效且适用于该中心的版本？版本升级后，旧链接是否失效？
主体问题
谁完成身份核验、谁取得签名证书、谁被授权代表研究方签署？账号、手机号和实际操作人能否对应？
意愿问题
受试者是否获得解释、是否有提问机会、是否完成必要阅读，并对具体版本作出可还原的同意表示？
系统问题
签署、失败、重试、撤回、补签、换版等事件是否留有审计轨迹？权限变化是否受控？
数据问题
原始文件、签名值、可信时间、元数据和审计日志是否关联同一业务主键，签后变更能否被识别？
归档问题
系统或供应商更换后，能否在规定保存期内读取、验签、导出并向检查人员解释整个过程？
新版GCP、ICH E6(R3)与电子签名法，必须同时看
三套规则解决三个不同层面的问题：临床试验质量体系、国际通行的风险与数据治理原则，以及电子签名本身的法律效力。
2026年6月8日，国家药品监督管理局、国家卫生健康委员会、国家中医药管理局、国家疾病预防控制局联合发布2026年第50号公告；新版GCP自2026年9月1日起施行，2020年第57号公告同时废止。文件共六章五十四条，并单列“数据治理”一章。官方原文
与此同时，国家药监局已明确ICH E6(R3)在中国的适用安排：2026年3月31日之后开始实施的药物临床试验适用E6(R3)。这意味着不少项目在9月1日前已经进入E6(R3)框架，而9月1日后又必须满足新版GCP；二者不是二选一。适用公告
2026版GCP
规定受试者保护、研究者和申办者职责、数据治理、计算机化系统以及监督检查等国内合规底线，是药物临床试验组织实施与监管检查的直接依据。
ICH E6(R3)
强调质量源于设计、风险相称、关键质量因素、数据生命周期和适配目的的系统控制。它把“为什么这样设计”放在“有没有做”之前。
《电子签名法》
解决可靠电子签名与手写签名或盖章的法律效力问题，但不替代GCP对知情过程、角色权限、系统验证、数据完整性和责任链的要求。
2020版与2026版，变化不只是多了一章
| 观察维度 | 过去常见理解 | 2026版应建立的新能力 | 项目落点 |
|---|---|---|---|
| 质量管理 | 按流程完成、把文件存齐 | 识别关键质量因素，按风险配置控制 | 将质量风险写进流程、权限、测试与监测规则 |
| 数据治理 | 数据库和归档部门的技术工作 | 覆盖数据生成、处理、传输、变更、核查、保存全周期 | 统一业务主键、版本、元数据、审计轨迹与导出规则 |
| 计算机化系统 | 系统能用、账号能登录 | 适合预定用途、风险相称验证、权限受控、变更可追踪 | 需求规格、验证、变更、故障和业务连续性形成闭环 |
| 电子签名 | 把纸上签字搬到手机 | 电子签名符合中国法律要求，并嵌入身份、权限、意愿和数据治理体系 | 签名值、证书、文件哈希、可信时间和业务事件绑定 |
| 外部服务 | 供应商有资质即可转移风险 | 委托不转移申办者、研究者等主体的最终责任 | 供应商评估、职责协议、服务监控、退出与数据迁移 |
效力层级提示：新版GCP属于规范药物临床试验活动的部门规范性文件/监管规则，不宜在对外材料中表述为“新法律”。项目制度中还应结合药品管理法、电子签名法、个人信息保护法、数据安全法以及适用的伦理、网络与档案要求综合判断。
电子化可以外包，主体责任不能外包
临床试验数字化最容易犯的错，是从采购功能开始；真正正确的起点，是先确认每个决定由谁作出、谁能授权、谁要解释。
电子签约平台、eConsent系统、CTMS、EDC、eTMF、CRO和SMO都可以承接具体工作，但它们不能代替申办者确定质量策略，不能代替主要研究者对中心研究实施负责，也不能代替伦理委员会作出伦理审查判断。技术平台可以输出证据，不能生成原本不存在的业务事实。
申办者
建立质量管理体系，选择和监督受托方，定义关键质量因素与数据治理要求，对委托工作保留最终责任。
主要研究者 / 研究机构
确保中心研究依方案和GCP实施；关键医学判断、受试者保护和正式报告等职责不能因电子化而被稀释。
伦理委员会
审查知情同意材料和过程安排。电子知情同意的页面、远程方式、身份核验和版本变化应进入伦理审查视野。
受试者 / 合法代表
获得充分、易懂、可选择的说明，并能证明对特定版本作出自主同意；不能把一个登录动作推定为全部知情事实。
CRO / SMO与其他服务方
依据书面职责和授权范围执行工作，人员资格、账号权限、操作行为和异常处理应被持续监督。
技术与电子签名服务方
提供身份核验、证书、电子签名、可信时间、文件防篡改、审计轨迹、存证验证和证据导出等专业能力。
| 关键事项 | 必须由业务主体控制 | e签宝可提供的能力 | 验收证据 |
|---|---|---|---|
| 文件适用性 | 伦理批准、中心适用、语言与版本生效 | 模板与版本固化、文件哈希、签署顺序 | 批准记录、模板ID、版本号、哈希值 |
| 签署资格 | 角色认定、授权范围、账号归属、替代签署条件 | 身份核验、组织认证、授权核验、证书服务 | 认证流水、授权链、证书标识、权限快照 |
| 知情过程 | 说明内容、沟通方式、答疑、退出与重新同意规则 | 页面编排、强制阅读、视频/交互、意愿事件留痕 | 阅读与确认事件、问答记录、版本关联 |
| 电子签名 | 决定何处需要签、签署含义及风险分层 | 数字签名、可信时间、签后验签、防篡改 | 签名结果、时间戳、验签报告、签署日志 |
| 检查响应 | 解释业务事实、质量判断和偏差处置 | 证据链查询、原文与报告导出、司法/技术验证支持 | 订单级证据包、导出记录、验证报告 |
数据治理不是“系统留日志”，而是事实从出生到退役都受控
新版GCP把数据、元数据、审计轨迹、盲法和计算机化系统连续写进同一组条款，本身就在提示：不能再分散建设、分散解释。
第五十一条至第五十三条构成数字化整改的核心段落：数据和元数据应当可追溯；审计轨迹应能够记录创建、修改或删除等操作；涉及盲法的数据处理不得破坏盲态；计算机化系统要经过与风险相称的验证，具备权限管理、数据备份、灾难恢复和变更控制等能力。第五十三条同时明确：如使用电子签名，应当符合我国关于电子签名的有关要求。
“如使用”非常重要。它不是“所有文件都必须电子签”，也不是“只要用了电子签就天然合规”。机构需要基于文件属性、签署目的、角色风险和系统场景，形成一份经质量、医学、法务、信息安全共同批准的电子签名适用矩阵。
每一步都要回答四个问题
谁做的？
用户身份、角色、权限、账户归属、代理或授权关系是否清楚。
对什么做？
数据或文件版本、业务主键、来源系统和适用中心是否唯一。
做了什么？
创建、确认、签署、修改、撤回、删除、导出等动作及原因是否留痕。
结果能否还原？
原始记录、前后版本、时间、签名和关联元数据是否在保存期内可读可验。
异常怎么处置？
失败、重复回调、网络中断、身份过期和补传失败是否进入偏差与恢复流程。
谁来解释？
业务、质量、IT和服务方能否从同一订单还原同一事实，而不是给出四套答案。
eConsent不是一份电子合同，而是两条证据链的交汇
一条证明“这个人签了这份文件”；另一条证明“这个人是在充分知情、可以选择的前提下同意参加”。少任何一条，都可能留下解释缺口。
知情过程链
- 使用伦理批准且当时有效的材料版本
- 信息以受试者可理解的语言和方式呈现
- 完成必要阅读、说明、互动与答疑
- 受试者有拒绝、暂停、退出和选择纸质方式的空间
- 方案或风险发生重大变化时触发重新知情同意
签署真实性链
- 身份核验结果与参与业务的主体对应
- 研究者或授权人员具有当时有效的权限
- 签名证书、签名值和可信时间可以验证
- 签署对象的文件哈希与归档原文一致
- 签后变更、撤回、补签和重签过程完整留痕
ICH E6(R3)承认纸质或电子形式的知情同意记录，也允许在适当条件下采用远程过程，但仍强调信息提供、理解、提问机会、自愿决定和记录保存。电子化不应成为增加受试者负担或排除数字能力较弱人群的门槛；需要时应提供纸质或现场替代路径。ICH E6(R3)
“必须刷脸”不是新版GCP的原文要求
人脸核验可以作为高风险场景的一种增强手段，但不应被写成所有受试者、所有研究、所有文件的单一入口。老年人、疾病状态特殊人群、境外主体、未成年人或网络条件不稳定场景，都可能需要差异化核验和人工兜底。正确做法是由机构建立风险分层：核验强度与身份冒用风险、文件法律后果、场景可替代性和受试者便利性相匹配，并保留选择依据。
十类最容易在检查中暴露的电子签约缺口
这些问题往往不会单独出现。一个版本控制失效，通常还会同时暴露权限、签署意愿和归档关联的缺口。
伦理批准版与签署版不一致
模板在业务系统内被手工改字，或新版本上线后旧链接仍可继续签署。
同一账号多人共用
账号显示为研究者，实际由协调员操作；系统无法区分准备、发送、确认与签署。
授权与证书有效期脱节
人员离岗或授权失效，账号和签名能力仍然可用，权限回收没有证据。
把点击“同意”当作全部知情
没有阅读、说明、答疑和异常路径记录，无法证明受试者理解特定版本。
只存最终PDF，不存过程
签名结果可见，但身份、证书、时间、事件、原始哈希和失败重试无法关联。
签后换版或补传覆盖原文
归档文件与签名对象不一致，系统没有把原文、签名值和版本锁定。
异常分支绕过门禁
认证过期、重复回调、设备切换或离线补传后，状态仍被错误推进为完成。
供应商替代主体判断
把平台认证结果直接视为受试者适格、研究者有权签或知情过程充分。
“上链”被当成当然有效
区块链可以辅助证明某个数据在某时存在且未变，但不能补齐身份、权限和业务真实性。
系统更换后证据不可用
只有在线查询入口，没有可迁移的原文、元数据、验签工具或标准化证据导出。
整改判断：任何一项都不应只通过“补一份制度”关闭。至少要同时落实页面门禁、接口校验、状态控制、事件留痕、异常测试和证据导出。
从一枚签名，扩展为可以逐层验收的可信体系
每一层都有业务控制，也都有最小证据输出。只有把两者成对设计，系统才不会在检查时出现“功能有、证据没有”。
四层目标架构：把专业能力接进机构控制，而不是另建一座孤岛
理想架构不是让用户在更多系统间跳转，而是由临床业务系统掌握决策和状态，e签宝提供可验证的身份、签名、时间和证据能力。
新版GCP电子签约四层架构
左侧是机构必须掌握的规则与责任，右侧是可以通过标准接入获得的专业能力。项目验收同时看两边。
在已有eConsent、CTMS、EDC、eTMF或院内门户的项目里，电子签名服务更适合以SDK/API、H5或受控页面方式被编排，而不是要求业务迁移到另一个孤立后台。业务系统在签署前完成版本、角色、适用性和状态校验；e签宝完成身份、证书、签名、可信时间及证据服务；结果回调后，业务系统再次校验订单、文件哈希和状态，才允许进入“完成”。
本地PDF摘要签：减少原文传输，也不能跳过业务校验
对数据出域敏感、文件较大或需要在机构环境内保留原文的场景，可以由本地系统生成定稿文件并计算摘要，由电子签名能力完成摘要签名，再把签名结果与本地原文绑定。它有助于降低原文跨域暴露，但前提是：摘要计算前文件已经定稿；摘要、订单和版本唯一对应；签署结果回传后本地完成验签；原文、摘要、签名和审计记录在保存期内可以共同恢复。否则“只传哈希”会变成另一种证据断裂。
电子签章与个人签名应分开治理
申办者、研究机构等组织用章，可以根据企业授权制度采用经批准的自动签章、审批后签章或人工确认签章；受试者、研究者等个人的签署，则需要与个人身份和当次意思表示关联。二者不能用同一套“自动化”逻辑处理。尤其是知情同意、主要研究者确认和关键医学判断，不应通过后台静默动作替代本人真实行为。
不要验收一张“成功页”，要验收一台签约状态机
签署完成只是终态之一。真正决定系统能否上线的，是每个前置条件、失败分支和恢复动作是否被定义。
任何一步失败，都不能把订单直接推进到下一状态。例如：文件版本变化后，原知情完成状态是否仍然有效？签名完成但验签失败时，是自动重试、人工复核还是形成偏差？存证失败是否影响业务完成，后补存证如何保证原文未变？这些都需要在上线前由业务、质量和技术共同批准。
订单级最小字段，不是越多越好，而是能把事实串起来
验收至少覆盖九组异常
页面绕过
跳过阅读、回退修改、旧链接直达、脚本重复提交，系统是否阻断并记录。
版本变化
签署前、签署中和签署后换版，原订单如何失效、重建或触发重新同意。
身份过期
认证超过有效期、证件变化、手机号更换或核验失败时，是否重新认证。
权限变化
授权到期、离岗、角色调整后，进行中的任务和签署资格如何处理。
设备切换
跨手机、跨终端或多人使用同一设备，身份会话和意愿事件是否串单。
重复回调
重复、乱序、延迟回调是否幂等，避免一个签署结果推动多次状态变化。
签名失败
证书申请、签名计算、可信时间或验签失败时，能否明确失败点和恢复动作。
存证失败
不允许用新文件补传旧订单；补传必须核对同一哈希并保留恢复事件。
退出与回退
受试者撤回、系统故障、供应商不可用时，纸质或人工路径是否可启动并对账。
上线门禁：每个用例都要有前置数据、执行步骤、预期状态、前端表现、后台日志、证据字段和恢复结果。只截一张“签署成功”页面，无法证明系统适合预定用途。
有Part 11签名样式，不等于整个系统已经符合Part 11
“打印姓名、日期、签署含义”只是电子记录和电子签名控制中的可见部分；系统范围、验证、访问控制和审计轨迹才是更大的主体。
如果项目涉及向美国FDA提交受监管电子记录，21 CFR Part 11的适用判断应基于记录类型、系统边界和使用方式进行。常见控制不仅包括签名与记录的绑定，还包括系统验证、准确完整副本、记录保护、访问限制、审计轨迹、操作顺序、权限检查、人员培训、责任政策和文档控制等。签名服务可以承担其中部分技术控制，却不能替代申办者或机构对整个受监管计算机化系统的验证。
| 常见误解 | 应当如何理解 | 项目需要补什么 |
|---|---|---|
| 有一张Part 11证书即可 | 没有一张通用证书可以覆盖所有客户配置、接口、流程和使用场景 | 系统边界、预定用途、配置与集成风险评估 |
| 签名样式符合就够了 | 呈现姓名、日期、含义只是签名控制的一部分 | 身份、唯一性、绑定、防抵赖、权限与审计控制 |
| 供应商验证替代客户验证 | 供应商材料可以支持客户验证，不能替代客户对其预定用途的确认 | 供应商评估、风险分析、UAT、变更与持续监控 |
| 上线一次验证终身有效 | 配置、接口、版本、基础设施和业务流程变化可能触发再评估 | 变更控制、影响评估、回归测试与周期性复核 |
对仅在中国境内实施、并不属于Part 11适用范围的项目，也不应为了宣传而把所有要求都笼统称作“Part 11合规”。更准确的做法是分别说明：哪些是新版GCP要求，哪些是中国电子签名法律要求，哪些是机构质量体系选择采用的国际控制。
检查时不应临时拼截图，而应一键还原一笔业务
理想证据包不是日志压缩包，也不是平台自己写的一页结论；它要让质量、法务、技术和检查人员都能按同一顺序读懂。
e签宝可基于项目配置提供签署过程记录、数字证书与签名验证、可信时间、文件完整性校验、存证及验证报告等能力。不同报告回答的问题不同：电子签章验证关注签名、证书、文件完整性；电子数据验证关注过程数据和证据链；业务报告则把技术结果放回订单与业务时间线。不能用其中任意一份替代其他全部事实。
证据包还要满足“离开平台后可以理解”
长期保存不能只依赖供应商在线页面。机构应在合同、接口和退出方案中明确：原始文件及其哈希、签名值、证书链、可信时间、审计轨迹、验证报告、字段说明、导出格式、验签方式和迁移支持。涉及算法或证书生命周期变化时，还要评估长期验证策略。区块链存证可以增强时间与完整性证明，但它证明的是“某个摘要在某时存在且之后未变”，并不自动证明业务事实真实、授权有效或知情充分。
先关高风险缺口，再把数字证据链纳入常态治理
六周不适合推倒重来，但足以完成范围盘点、风险分层、关键门禁改造、异常测试和上线证据包。
范围与责任盘点
列出知情同意、研究协议、授权、培训、访视、偏差、报告等所有签署场景；确认业务主体、系统、文件版本和当前证据。
适用矩阵与风险分层
形成电子签名适用矩阵、身份核验分层、个人/组织签署策略、数据出域和保存要求；高风险场景先冻结规则。
目标流程与接口门禁
确定状态机、订单字段、版本与授权校验、签署顺序、回调幂等、失败恢复和纸质替代路径；同步修订职责协议。
配置、集成与数据迁移
完成模板、身份、证书、签名、存证和证据导出的配置；对在途订单、旧版本、历史证据和账号权限进行清理。
全链路与异常验证
按真实角色和真实终端试点，覆盖版本变化、身份过期、权限回收、签名失败、重复回调、存证失败和系统回退。
上线批准与检查演练
生成验证总结、风险接受、培训记录和订单级证据包；由业务、质量、医学、法务、IT共同签署上线批准并完成模拟检查。
9月1日以后，整改才真正进入第二阶段
上线不是终点。机构还需要持续监控认证失败率、异常订单、权限回收时效、旧版本拦截、证据导出成功率和供应商服务变化；通过偏差、CAPA、变更控制和周期性复核，把电子签约纳入既有质量体系。对于新研究、新中心、新人群或新终端，应重新评估风险，而不是直接复制历史配置。
把一笔签署，做成一条经得起检查的证据链
可围绕临床试验电子知情同意、研究者签署、组织授权、系统集成、本地PDF摘要签、长期存证与监管证据包开展现状评估、方案设计和项目验证。
e签宝吴兆华
- 邮箱：tuobaye@tsign.cn
- 杭州天谷信息科技有限公司｜商务总监
- 扫码添加微信，可发送现状系统图或典型流程进一步交流
正式政策与研究来源
- 国家药监局、国家卫生健康委、国家中医药局、国家疾控局：《药物临床试验质量管理规范》（2026年第50号），2026年9月1日起施行。官方转载与附件
- 国家药监局：《关于适用〈E6(R3)：药物临床试验质量管理规范〉国际人用药品注册技术协调会指导原则的公告》（2025年第125号）。官方公告
- International Council for Harmonisation, ICH E6(R3) Guideline for Good Clinical Practice, Final Guideline, 6 January 2025. 原文PDF
- 《中华人民共和国电子签名法》（2019年修正）及与密码、数据、个人信息、网络安全相关的现行法律规范。
- 本文产品界面为e签宝相关能力的实际示意，已对个人及业务可识别信息进行脱敏；具体能力、接口、配置和适用范围以项目评估及当期正式产品文件为准。
阅读说明：本文用于行业研究与项目方法交流，不构成针对具体临床试验、法律争议或监管检查的法律意见。机构应结合研究类型、受试者特征、系统范围、数据流向和监管区域作个案判断。