← 吴兆华个人网站站内作者版本 · 本页为长期 canonical · 最近核验 2026-07-22
CUSTOMER SOLUTION · 2026.07.22

受试者招募平台 App
× e签宝电子签约解决方案

为计划约 9 月上线的初创平台设计:当前不增加不必要的系统负担,但从第一版就预留电子签约入口;当合作方协议、参与者授权或正式知情同意出现时,可以直接接入、快速上线。

专业版优先投入更轻,适合单平台先完成 API 签署与合同管理闭环
4 周可落地从需求确认、沙箱联调到一条真实业务试运行
不阻塞 9 月上线基础平台先发布,电子签按业务触发启用
团队阶段初创团队,基础功能仍在部署
上线目标预计约 2026 年 9 月推进
当前重点先把招募平台核心业务跑通
后续需求随业务增长增加电子签约
e签宝给出的直接建议现在预埋接口,业务出现时启用;首选专业版,不先建设重型方案。

把电子签设计成平台的标准能力:业务后台决定签什么、谁来签;e签宝负责身份核验、发起签署、过程回调、签后文件和证据。

01 · 客户具体需要签什么

不是只有“受试者知情同意”
这一种合同

对招募平台而言,电子签约会从低风险、容易落地的合作协议开始,再进入参与者授权,最后才是要求最高的正式临床知情同意。三类场景应使用同一套接口底座,但不能混成同一种模板。

场景 A平台 ↔ 申办方 / CRO / SMO / 研究中心建议最先落地
签署文件平台服务、项目合作、保密与委托协议

明确项目范围、招募服务、数据处理、费用、保密和责任。

e签宝动作企业认证 + 经办人授权 + 企业签章

从平台后台发起,对方在线签署,完成后自动回传合同。

客户价值最快形成业务闭环

不用先做临床 eConsent,也能马上解决合作协议签署与归档。

场景 B平台 ↔ 潜在参与者随招募业务启用
签署文件隐私授权、招募服务确认、资料使用授权

根据平台实际收集的数据与服务关系拆分,不用一次勾选代替全部授权。

e签宝动作个人身份核验 + 移动端签署

用户在 App/H5 内完成核验与签署,签后文件可下载并留存。

客户价值授权可证明、状态可追踪

平台知道谁授权了什么、哪一版、何时生效或撤回。

场景 C研究中心 / 研究者 ↔ 受试者正式项目后单独上线
签署文件正式临床试验知情同意书

必须使用项目与伦理批准的最新版本,并保留研究者解释和参与者提问路径。

e签宝动作参与者核验 + 双方签署 + 签后证据

平台控制版本和角色;e签宝完成身份、签署、回调和文件验证。

客户价值把签名放进完整业务链

避免只留一张 PDF,后续能按项目、中心、人员和版本追踪。

02 · 参与者实际怎么签

不用跳出 App,六步完成

平台前端保留自己的品牌和交互,所有密钥与 e签宝接口调用都放在业务后台。对参与者而言,是一条连续的移动端流程。

01进入签约任务

App 根据项目和参与者状态展示待签文件。

02查看最新版本

平台把正确项目、文件版本和签署角色传入流程。

03 · e签宝身份核验

按场景选择手机、人脸、银行卡等适合的认证方式。

04阅读与确认

平台负责解释、问答、必要阅读和特殊人群路径。

05 · e签宝本人签署

参与者签署;需要时由研究者或企业继续签署。

06回传与归档

完成状态、签后文件和业务编号回到平台。

e签宝真实身份核验界面
真实产品界面|身份核验
可根据项目人群与风险选择认证路径,并为失败场景设计备用通道。
e签宝真实签署意愿认证界面
真实产品界面|签署过程
示例展示签署任务、认证与流程状态。图片已脱敏,不包含真实个人信息。
03 · 平台具体怎么接

App 不直连密钥,
由业务后台接入 e签宝 SaaS API V3

这套架构可以在基础平台上线时先留好接口和字段,电子签需求确认后再打开流程,不需要改写参与者、项目和合同的核心业务模型。

参与者端

招募平台 App / H5

  • 项目浏览与报名
  • 签署任务展示
  • 签后文件查看
客户系统核心

平台业务后台

  • 项目、中心、参与者和文件版本
  • 决定签署人、顺序和触发条件
  • 保存 sign_flow_id 与业务状态
  • 回调幂等、重试与异常补偿
e签宝

SaaS API V3

  • 身份认证与授权
  • 文件签署与流程模板
  • 异步回调通知
  • 合同管理与签后验证
API 01身份认证
API 02发起签署
API 03状态回调
API 04文件与证据
部署原则:e签宝 AppSecret、Token 等凭据只放在客户服务端,不进入 App;参与者端只接收业务后台生成的签署链接或嵌入页面;回调必须校验、幂等、可重放。
e签宝 SaaS API V3 官方对接指南真实页面
真实官方材料|SaaS API V3 对接指南
官方文档列出实名认证、合同文件签署、流程模板、企业机构成员、合同管理和回调通知等接口能力。项目实施以接入当时的最新开放文档和合同权益为准。
04 · 客户现在怎么选版本

优先专业版,
高级版作为业务增长后的升级项

客户当前是单一初创平台、基础功能仍在建设、电子签尚未正式启用。此时最重要的是用较低投入跑通一条 API 签署链,而不是先购买复杂治理能力。

当前推荐

专业版

适合:单一平台、合同量尚在起步阶段,需要基础 API 电子签、移动端签署和合同管理。

  • 合作协议、参与者授权、基础签署流程
  • 从自有 App/后台发起和接收签署状态
  • 先完成一个平台的端到端闭环
  • 投入更可控,适合初创团队验证业务
采购前确认:当前专业版对应的 APPID、API 范围、合同份数、认证通道与存储权益,以当期产品清单和报价为准。
后续评估

高级版

适合:平台进入规模化,多项目、多主体、复杂权限和更深合同治理成为真实需求。

  • 多个机构/企业与更复杂的组织管理
  • 更精细的合同管理和治理需求
  • 特定高级签署或敏感文件场景
  • 需要更多项目和管理角色协同时
升级触发:不是“临床行业就必须高级版”,而是当多组织、复杂权限、规模与高级能力出现时再升级。
此阶段不建议旗舰版:客户尚未形成大规模集团治理、复杂集成矩阵或大量组织统一管理需求。先把专业版业务闭环跑通,更符合当前阶段。
05 · 怎么实施上线

四周交付一条真实业务链

不做大而全的项目,先选择一个最容易验证的场景:平台与合作方协议,或参与者授权确认。跑通后再复制到正式临床项目。

WEEK 01

定范围

  • 选定首个签署场景
  • 确定模板与签署角色
  • 完成字段/接口清单
WEEK 02

沙箱联调

  • 身份核验
  • 发起签署
  • 回调与文件下载
WEEK 03

业务验收

  • 正常与异常流程
  • 重复回调与失败重试
  • 移动端和后台验收
WEEK 04

小流量试运行

  • 真实但可控的业务
  • 运营与客服培训
  • 复盘后决定扩展
验收项客户能看到的结果通过标准
App 内签署参与者从任务进入、核验、签署、返回 App不中断、状态准确
版本与角色每次签署都绑定正确文件和签署人旧版/错角色不得发起
回调与异常重复、延迟、失败均不会产生错误业务状态幂等、可重试、可补偿
签后文件后台可按业务编号查看与下载合同和业务记录一一对应
正式知情同意项目、伦理版本、参与者、研究者与文件关联真实项目单独验收后启用
06 · 是否有相近项目经验

有医疗系统与临床资料场景,
但不把相近案例说成完全同型

公开可核验

医院电子签名系统集成

e签宝官网有医院将电子签名融入医疗业务系统的公开案例,说明身份与签署能力可以嵌入现有医疗系统。

查看官方案例 →

知识库可核验

临床试验协议与授权资料

内部案例库存在临床试验协议、授权书、项目资料接入自研与医药平台的相邻场景;对外不披露未经授权的客户名称。

需要项目验证

同型招募平台 eConsent

目前没有足够公开证据证明完全同型平台已完成整套生产验证,因此建议以一个脱敏流程联调和验收,而不是只依赖案例描述。

可直接回复客户:我们有医疗系统电子签名集成、临床研究相关协议/授权资料电子签约,以及自研平台 API 接入的经验。贵司现阶段可以先预留接口,待首个签署场景确定后,用专业版在 4 周内跑通一条真实链路;正式临床知情同意再按项目、伦理版本和研究者责任单独验收。