医院门口：身份对了，授权范围对吗？
一名医药代表准备进入医院开展学术交流。备案信息能查到，身份也一致；但企业授权是否仍有效、治疗领域与活动内容是否匹配、医疗机构是否同意接待，现场没人能快速核清。
问题不是“有没有备案”，而是备案、授权与这一次业务行为能不能对上。
2026 医药合规窗口
药企迎接8月1日与9月1日两项新规：
责任链与证据链改造总图
一边管理医药代表，一边管理药物临床试验。它们不是一套规则，也不能混为一谈。但当检查继续追问，企业最终都要回答五件事：谁负责、谁授权、如何执行、留下什么、谁来复核。
08.01《医药代表管理办法》施行
09.01新版《药物临床试验质量管理规范》施行
先做
不要先买系统，也不要先重写全部制度。先选一条高风险业务链，用十分钟复原一次真实事件：谁、基于什么授权、对哪个版本、在什么时间完成了什么，异常如何关闭。
直接看生效日前最低控制门、30/60天路线与供应商十问 →
01 · 两扇门，一个检查问题
“已经备案”和“已经签名”，为什么仍可能答不上来？
真正的合规断点，经常不在动作有没有发生，而在企业能否把责任、权限、版本、过程和异常重新拼回来。
线上知情：签名是本人，签的是正确版本吗？
一名试验参与者完成线上知情同意。系统能证明签名动作来自本人；但能否证明使用的是伦理委员会批准版本、谁完成了说明、试验参与者是否有提问机会、为什么后来又重新同意？
问题不是“有没有签名”，而是这枚签名是否处在完整、可还原的知情过程里。
上面是根据两项制度抽象出的合成检查场景，不对应任何单一客户或真实检查案件。它的作用是暴露同一类管理缺口：最终结果存在，不代表过程已经可验证。
02 · 先把两项制度彻底分开
法规不是一套，业务不是一条，责任更不能合并
全文所有“共同点”都发生在企业实施层，而不是把两项制度拼成一个监管要求。
医药代表管理办法｜2026年8月1日
国家药监局等七部门发布；聚焦药品上市许可持有人、医药代表、受托专业机构和医疗卫生机构。
新版GCP｜2026年9月1日
国家药监局等四部门发布；适用于经国务院药品监督管理部门批准或者备案、为研制药品而开展的药物临床试验，相关活动也应遵守本规范。
医药代表管理：管“谁能以什么范围开展什么活动”
- 核心对象
- 药品上市许可持有人、医药代表、受托专业机构、医疗卫生机构
- 责任主线
- 任职或委托、资格培训、企业授权、统一备案、机构核验、活动规范、变更与退出
- 不是
- 医疗器械推广人员管理规则；备案也不是医院必须接待的通行证
新版GCP：管“药物临床试验怎样被可靠地设计、执行与记录”
- 核心对象
- 申办者、临床试验机构、主要研究者、伦理委员会及相关服务供应商
- 责任主线
- 方案与伦理、职责委派、知情同意、研究执行、数据治理、监查稽查、偏差与CAPA（纠正和预防措施）
- 不是
- 全部医学研究的统一规则；也不是所有文件都必须电子签名的强制令
只涉及医药代表管理从第04节开始，先闭环任职、授权、备案、机构核验与退出。点击直达 →
只涉及药物临床试验从第05节开始，先闭环职责、伦理版本、知情、数据与系统验证。点击直达 →
两项业务都涉及先看共同底座，再使用责任矩阵、生效日前最低控制门和30/60天建议路线。点击直达 →
先认识10个读图词
MAH药品上市许可持有人，对医药代表管理承担主体责任。
PI主要研究者，是临床试验现场的最终责任人。
CRO合同研究组织，通常承接申办者侧部分临床试验任务。
SMO试验现场管理组织，行业常用称谓，责任要按真实委托关系判断。
CAPA纠正和预防措施，要求从原因调查走到有效性验证与关闭。
MCRM医药客户与代表业务管理系统，企业命名和功能范围可能不同。
CTMS临床试验管理系统，常用于项目、中心、进度和任务管理。
eTMF / EDC / eConsent分别支持试验主文件、电子数据和电子知情同意管理。
唯一A对结果最终负责且只能有一个的负责人；其他角色可以执行、协作或复核。
go / no-go内部放行或不放行判断，不是监管机关统一下达的停办命令。
03 · 为什么现在必须重看“管理链”
监管没有要求企业买同一套系统，但仅保留最终PDF往往不足以支持复核
从两项制度的责任、委托、记录和数据条款往回看，可以看到一条清晰的因果链。
一个动作由多方完成
药品上市许可持有人、受托专业组织、医疗卫生机构，或申办者、临床试验机构、服务供应商共同推进业务。合同能分工，但不能自动转移最终责任。
授权和版本不是静态文件
人员离职、授权到期、治疗领域变化、伦理版本更新、任务重新委派，都可能让昨天有效的记录今天失效。
最终PDF解释不了过程
一份签完的文件常常回答不了：谁说明过、谁审批过、使用什么权限、对应哪一版规则、异常为什么关闭。
管理必须能被重新播放
企业需要把责任人、业务主键、授权范围、文件版本、操作时间、异常与复核结果串成一条可调取的事件链。
两项制度共同抬高的，不是“电子化率”，而是管理可验证的颗粒度。这是本文基于正式条款结构作出的实施分析，不是监管机关发布的统一系统模型。
04 · 医药代表管理链
备案只是链条中间的一站，不是起点，也不是终点
真正需要被管理的是代表从进入体系到退出体系的完整生命周期，以及每一次活动是否落在有效授权范围内。
任职或委托
核验劳动合同或授权书；委托专业组织时，另行签订医药代表管理协议，并由持有人与具体医药代表签署授权书。
资格与培训
核验资格条件、培训与考核结果，防止“人已开展业务，资格材料还在补”。
企业授权
把产品类别、治疗领域、活动区域、权限范围和有效期写进可验证授权。
统一备案
将身份、照片、任职或授权信息、产品与区域等信息形成可查询备案。
机构核验
医疗卫生机构核验身份与备案信息，并按自身制度决定是否同意接待。
开展活动
在授权的药品类别、治疗领域和区域范围内活动，并完成备案、机构登记且取得机构同意。
变更与终止
备案信息有变更的，持有人应当在30日内完成备案信息变更；不再从事医药代表工作或者停止授权的，应当在30日内删除备案信息。
监督与处置
及时纠正违规；情节严重时，终止授权、删除备案并在平台公示删除原因。
主体责任没有因为委托而消失。办法要求药品上市许可持有人建立覆盖任职、授权、备案、培训和活动的管理机制。委托专业机构可以改变执行者，却不能把企业应当承担的主体责任一并“外包”。
备案也没有自动打开医院的大门。医疗卫生机构仍需建立接待制度、核验代表身份与备案信息，并对学术交流活动进行管理。换句话说：身份真实、备案有效、授权匹配、机构同意是四个不同问题。
边界提醒
既有已确认备案信息继续有效，不需要全部重新备案。官方政策解读同时提出，办法施行后持有人应补充完善既有备案信息，并按新规办理新聘任或新授权人员备案；发生信息变化或停止任职、授权时，仍需遵守法定30日内变更或删除要求。
05 · 药物临床试验链
签名只是知情同意过程中的一个节点
新版GCP把关注点放在试验参与者权益、安全、试验质量和数据可靠性上。电子签名可以参与，但不能替代前后全部专业活动。
方案与伦理
确定科学方案、风险与受益，取得伦理批准并冻结正确版本。
角色与委派
明确申办者、机构、PI与服务方职责，记录任务委派和系统权限。
招募与筛选
控制招募材料、渠道、试验参与者资格与隐私处理，避免营销替代医学判断。
知情说明
使用伦理批准版本，给出充分说明、提问机会和不受不当影响的决定空间。
签署与再次同意
试验参与者或法定代理人与执行知情同意人员在知情同意书上签名并注明日期；病历记录知情同意的具体时间和人员；参与者获得已签署原件。出现新风险或版本变化时，应先判断是否需要再次取得同意，而不是把任何改版都机械等同于重签。
研究与源数据
形成可靠、可追溯的源记录；任何更正都不应掩盖原记录及理由。
偏离与安全
记录方案偏离和安全事件，完成报告、调查、纠正预防与复核。
监查与归档
申办者监督服务供应商并保存其负责的必备记录，书面告知机构、PI和服务供应商保存要求；PI与临床试验机构保存现场必备记录；伦理委员会独立保存伦理审查记录。对伦理记录和现场必备记录，新版GCP区分用途与结局：用于申请药品注册且试验药物获批的，至少保存至上市批准后5年；用于申请注册但未获批，以及未用于申请注册的，至少保存至试验终止后5年；其他要求更长时从其规定。
申办者是临床试验相关活动的最终责任人，应把试验参与者权益和安全以及数据可靠性作为基本考虑。主要研究者是临床试验现场的最终责任人，对试验参与者权益和安全及临床试验质量负责；主要研究者和临床试验机构对其授权、委托事项承担最终责任。
电子知情同意不是“发链接—刷脸—签名—完成”。它必须把伦理批准版本、说明过程、提问机会、自愿决定、签署时间、重新同意触发条件和版本变化一起管理。签名可以记录行为节点，但不能单独证明试验参与者真正理解。
电子签名不是新版GCP的强制统一形态
新版GCP要求纸质和电子材料可靠、可追溯，并对计算机化系统提出权限、验证、备份、应急和稽查轨迹（行业也常称审计追踪或 audit trail）等要求；只有在使用电子签名时，才需要同时符合我国电子签名相关要求。
06 · 可以共用底座，但不能共用责任
两条业务链，最后都要落在五个可验证问题上
这不是为了把法规“平台化”，而是让不同部门使用相同的管理语言，避免每一套系统都只保留自己的半截事实。
谁负责？
业务主体、最终责任人和执行人是否分清；委托后谁仍要监督。
谁授权？
授权主体、范围、期限和撤销条件是什么；系统权限是否同步。
怎么执行？
使用哪一版规则和文件；执行动作与授权、审批是否一致。
留下什么？
身份、时间、版本、业务主键、原始记录、稽查轨迹是否齐全。
谁来复核？
异常怎样发现、升级、调查、CAPA、复核和关闭。
企业可以共享“身份、授权、版本、签署、时间、证据调取”的技术底座；但不能因为底座共用，就把MAH、申办者、机构、PI和伦理的责任规则合并。
07 · 角色矩阵
可以委托的是任务，不能自动转移的是最终责任
系统建设前先回答“谁必须决定、谁可以执行、必须留什么证据”，比先列功能更重要。
药品上市许可持有人
- 决定聘用或授权关系，核验医药代表是否满足法定资格条件，并管理培训、考核、授权、备案与活动
- 监督受托专业机构，处理变更、违规与终止
- 主体责任不因委托而转移
医药代表 / 受托专业机构
- 在有效授权、产品类别、治疗领域和区域内开展活动
- 配合提供并更新任职、授权、培训、备案等必要信息
- 市场称谓不能替代真实合同关系
医疗卫生机构
- 建立接待制度，核验身份和备案信息
- 决定是否同意接待并管理活动记录
- 备案有效不等于自动准入
申办者
- 设计质量管理、选择机构、监督服务供应商
- 管理风险、监查、稽查、安全、数据与归档
- 是临床试验相关活动的最终责任人，应把试验参与者权益和安全以及数据可靠性作为基本考虑
机构 / 主要研究者
- 机构建立质量体系，PI是临床试验现场最终责任人
- PI对试验参与者权益和安全及临床试验质量负责
- PI与机构对其授权、委托事项承担最终责任；PI负责的临床试验决策、关键确认，以及向伦理审查委员会、药物临床试验机构和申办者提交的正式报告，原则上不得授权
伦理审查委员会
- 形成包含审查文件版本信息的书面意见；对实施中的试验持续跟踪审查，间隔不超过12个月
- 关注安全信息、严重不依从和影响试验参与者权益的变化，必要时暂停或终止试验
- 独立保存伦理审查记录；伦理决定不能由申办者、研究团队或技术平台替代
CRO / SMO / 外部协作方
- 应按真实委托位置区分申办者侧或机构侧任务
- 按实际委托落实合同、职责、权限、监督与退出
- 申办者侧服务供应商转包须事先取得申办者书面同意；PI与临床试验机构确需委托机构外单位承担相关职责和功能时，须事先取得申办者同意，并仍对授权、委托事项承担最终责任
“CRO”“SMO”是行业常用称谓。落到新版GCP时，应根据实际委托关系分别映射为申办者侧服务供应商，或研究机构/研究者侧外部协作单位，不能用一个标签直接替代责任判断。
把角色翻译成七个可验收事件
这张表不是法规原表，而是把两项制度转换成企业实施对象：谁承担责任、谁执行、什么条件下才放行、留下什么、何时必须复核。
| 业务事件 | 责任主体 / 最终责任人 | 独立审查 / 执行 / 受托角色 | 版本或授权门槛 | 关键证据 | 权威系统 | 复核 / 失效触发 |
|---|---|---|---|---|---|---|
| 【医药代表】代表聘任或授权变更 | 药品上市许可持有人 | 业务、合规、人力或受托专业机构 | 资格核验完成；任职或委托关系有效；产品类别、治疗领域、区域与期限明确 | 关系文件、资格材料、培训考核、授权、审批、备案状态 | MCRM / HR / LMS / 备案平台 | 离职、到期、岗位、产品、治疗领域、区域或委托关系变化 |
| 【医药代表】机构接待与代表活动 | 持有人负责代表活动；医疗机构负责接待与活动台账 | 代表、机构接待部门及相关科室 | 身份与备案可核；授权范围匹配；医疗机构同意 | 核验结果、预约或登记、活动主题、材料版本、参与记录 | MCRM + 机构接待 / 访客系统 | 授权撤销、备案变化、机构拒绝、投诉或违规 |
| 【两线分别判断】专业机构或服务方委托 | 持有人或申办者；PI与临床试验机构对其授权、委托事项承担相应最终责任 | 专业机构、CRO、现场协作方及其他供应商 | 真实委托关系、职责边界、人员能力与监督计划明确；申办者侧供应商转包须事先取得申办者书面同意；PI与机构委托机构外单位须事先取得申办者同意 | 合同、职责矩阵、人员清单、权限、监督、适用时的转包书面同意或机构外委托同意及退出记录 | 合同系统 / QMS / MCRM / CTMS | 范围、人员、分包、绩效、风险或合同变化 |
| 【GCP】伦理批准后版本发布与切换 | 申办者负责整体质量；机构与PI负责现场实施 | 独立审查：伦理审查委员会；业务执行：申办者临床运营、PI及研究团队；系统执行：经授权的系统管理员 | 伦理批准有效；生效日期明确；旧版本停止新发起使用，历史记录完整保留 | 伦理决定、批准文件、版本号、生效时间、发布审批、旧版停用规则及历史记录 | CTMS / eTMF / eConsent | 方案、风险信息、伦理意见或文件内容变化 |
| 【GCP】重新知情同意 | PI负责现场；申办者负责整体质量与监督 | 获授权的研究人员 | 经风险、方案和伦理要求判断确有再次同意的必要；使用当前伦理批准版本 | 触发事件与必要性判断、说明与提问；知情同意书上的签署人、执行人员及日期；病历中的具体时间和人员；交付参与者的已签署原件；非本人签署时记录关系与依据 | eConsent / CTMS / eTMF | 新风险信息、版本变化、身份或代理关系变化 |
| 【GCP】方案偏离与CAPA | 申办者与机构 / PI按各自责任范围承担 | 研究中心、监查、质量与服务供应商 | 分类、升级、报告与审批路径明确 | 偏离、影响评估、原因调查、CAPA、有效性检查与关闭 | CTMS / QMS / eTMF | 逾期、重复发生、严重程度变化或措施无效 |
| 【共用实施建议】系统访问授权与撤销 | 业务 / 数据所有者及对应制度责任主体 | IT、系统管理员、供应商管理员 | 岗位职责、最小权限、培训与审批完成 | 申请、审批、授权、变更、撤销、周期复核与稽查轨迹 | IAM / 各业务系统 / QMS | 离职、调岗、项目结束、长期未用或异常访问 |
使用方法：选中一行，用一个真实事件现场重开全部证据；任何一列答不上来，都意味着流程、系统或责任边界仍有断点。表内超出法规明确列举范围的字段属于本文实施建议，不构成统一法定材料清单。
08 · 六个最容易断掉的连接点
企业真正丢失的往往不是文件，而是文件之间的关系
身份、授权、版本、业务事实、系统日志和异常闭环任一处脱节，最终都可能只剩一份“看起来完整”的PDF。
身份正确，授权已经失效
系统证明是本人操作，却没有验证他当前是否仍代表该企业、该项目或该治疗领域。
补：授权对象、范围、期限、撤销事件与系统权限联动。
有授权文件，实际范围已变化
产品、区域、岗位、项目或委托关系变化后，旧文件仍在被继续使用。
补：变更触发器、版本号、生效时间和旧授权停用。
签署成功，文件版本不对
知情同意、授权书或协议签完了，却无法与伦理批准版或企业批准版一一对应。
补：审批状态、文件哈希、业务主键与签署任务绑定。
最终文件完整，过程无法复原
没有说明记录、审批链、提问与回答、签署人、执行人员、日期、具体时间，或非本人签署时的关系与依据。
补：过程节点、操作者、准确时间和必要上下文。
系统有日志，日志不能独立解释
缺少唯一身份、最小权限、稽查轨迹、备份和版本基线，日志只说明“发生过点击”。
补：身份目录、权限基线、验证、备份恢复与留存策略。
异常被发现，却没有真正关闭
投诉、偏离或违规停在聊天群和邮件里，没有调查、CAPA、复核与关闭证据。
补：异常编号、责任人、原因、措施、验证结果和关闭人。
09 · 系统边界
不是一个平台包办合规，而是四层各负其责
把电子签名放在正确的位置，才能既发挥价值，又避免“接入即合规”的错误期待。
决定“可不可以做”
制度、SOP、角色、业务审批、风险判断、监督与CAPA，必须由企业及法定责任主体完成。
记录“发生了什么”
MCRM、OA、CTMS、eTMF、EDC、eConsent等保存业务主键、状态、版本、任务与结果。
绑定“谁、何时、签哪一版”
身份核验、签署权限、签署行为、可信时间、文件完整性与技术验证，通过接口嵌入业务事件。
保证“多年后仍可解释”
系统验证、权限复核、稽查轨迹、备份恢复、留存、迁移、独立验签与供应商退出共同完成。
10 · e签宝应该进入哪些节点
它应当是一层“可信绑定服务”，而不是医药合规判断引擎
在企业已经完成资格、职责和业务授权判断，并把有效授权记录写入MCRM、OA、CTMS等权威业务系统之后，e签宝最自然的位置，是把授权记录、签署权限、文件版本、签署动作、时间和验证结果可靠地绑在一起，并保留可调取证据。
身份核验
确认个人或企业是谁，为代表、研究者、试验参与者、法定代理人或企业经办人建立可信入口。
授权记录与签署权限绑定
把业务系统已经有效批准的授权文件、范围、期限和撤销状态，与签署任务或签章调用权限关联。
文件签署
绑定签署人、签署意愿、文件版本、业务单据与签署结果。
时间与完整性
以可信时间、文件哈希和签名验证支持文件未被篡改的判断。
报告与接口
形成签署、验签或存证类材料，并可基于通用API开展与MCRM、OA、CTMS、eTMF等业务系统的项目集成；实际兼容性、连接器和验证状态需逐项验收。
e签宝医药知识库检索说明：相关实践线索包括医药系统集成、临床试验协议与授权材料、讲者协议、质量通知与召回、医护或患者签署。它们只说明供应商能力映射，不证明具体客户通过监管验证，也不替代法规原文。
脱敏演示界面 01｜身份核验
产品界面采集于2026年7月；个人二要素、银行卡、手机号、人脸等核验方式可按项目接入。具体通道与可用性需以实际配置和当时官方接口为准，不代表任何客户部署。
可支持复核：在核验配置、底层日志和结果记录完整的前提下，形成某次核验动作与结果的技术材料。
不能证明：医药代表资格、临床角色或业务授权天然成立。
脱敏演示界面 02｜验证与报告
产品界面采集于2026年7月；验签输出可用于查看签名数量、签名状态及文档变化，并为争议或检查提供技术复核材料，不代表任何客户部署。
可支持核验：结合原文件、签名数据、证书链、文件哈希和独立验签工具，复核签名与文件完整性。
不能证明：活动真实发生、费用真实或临床数据结论正确。
集成边界
e签宝开放平台提供身份、签署授权、签署、模板、印章、合同与回调等通用API，但这不等于现成的CTMS、eTMF、EDC或医药代表管理系统连接器。企业仍需完成需求规格、业务授权、权限、计算机化系统验证、稽查轨迹、备份、变更、归档与退役治理。
11 · 企业建议路线：30天盘清，60天跑通
前30天盘清责任和证据，后30天接通系统与供应商
下面是企业实施建议，不是法规统一规定的整改期限。顺序应从责任和证据对象出发，而不是从采购清单出发。
8月1日前：医药代表线最低控制门
至少能核验代表资格、任职或授权关系、备案状态、产品类别、治疗领域、区域范围和机构是否同意接待。任一关键条件无法确认时，企业内部应暂停该人员新增学术推广活动，直至完成受控补证与批准。
这是本文建议的内部 go / no-go 风险控制，不是对所有企业作出的统一停办命令。
9月1日前：新版GCP线最低控制门
至少完成适用项目清单、高风险差距登记、PI与机构授权委托复核、伦理批准版本确认、知情同意控制和关键计算机化流程风险评估。未经评估或验证的新电子流程，不直接扩大到关键业务。
具体过渡安排、项目处置和验证深度，应由申办者、机构、PI、伦理、质量与IT结合真实风险决定。
Day 0启动会：由一名管理层发起人召集商业合规、临床质量、法务、业务、IT、档案和采购质量；会前带来适用业务清单、人员与供应商清单、现有SOP及一条真实事件。90分钟内必须决定两条业务线各自唯一的A角色、最低控制门、首批穿透样本和升级路径；会后24小时形成责任矩阵与断点台账。
把两个法规日期与30/60天路线对齐
如果以本文成稿日2026年7月23日作为Day 0：医药代表线应在7月31日完成8月1日前的内部放行判断；新版GCP线应在8月31日完成9月1日前的内部放行判断。30天节点落在8月22日，60天节点落在9月21日，用于继续补齐系统、供应商和长期验收，不得理解为“等30天后再处理生效日前风险”。上述提前一天签字和30/60天日期均为本文建议的内部项目节奏。
可签字的 go / no-go 最小字段
每条业务线逐项记录：控制项、状态、证据位置、缺陷等级、临时控制、唯一A、复核人、决策日期和最终结论。本文把“关键资格、授权、备案/机构同意、伦理批准版本、PI/机构授权委托、知情同意控制或关键系统验证无法确认，且没有获批有效临时控制”建议列为重大缺陷；这是企业内部风险分级建议，不是监管统一缺陷分类。真实人名、授权范围和证据位置必须由企业在Day 0填入，通用文章不能替代企业签字。
下载可执行项目台账 CSV
模板同时承接任务、缺陷、临时控制和最终放行结论；所有“企业必填”项未完成前不得作为正式决策记录。
前30天 · 盘清适用范围与断点
先回答“谁负责、现在缺什么”
1. 建立双规适用性清单
参与角色：法规 / 合规 / 临床质量
交付物：受医药代表办法、新版GCP或两者影响的业务、主体与项目清单。
验收：每个业务对象都能说明适用规则、责任主体和判断依据。
临时控制：适用性未确认的高风险新流程不直接放行。
2. 画出角色—事件—责任矩阵
参与角色：商业合规 / 临床运营 / 质量
交付物：代表任职授权、机构接待、方案与伦理版本、知情、偏离、安全事件等关键事件矩阵。
验收：每个事件都有唯一A、执行者、放行条件和复核触发器。
临时控制：责任不清的事件回到责任主体逐单批准。
3. 盘点身份、授权、版本与证据
参与角色：业务系统所有者 / IT / 档案
交付物：身份目录、授权台账、文件版本、日志、异常、档案和系统主键清单。
验收：按预设抽样规则选择正常、异常和权限撤销事件，均能从业务记录追到签署、版本和复核证据。
临时控制：仅有最终PDF而缺过程关系的节点增加人工复核。
4. 建立断点与临时控制台账
参与角色：合规 / 质量 / IT
交付物：断点、风险、责任人、期限、临时控制和验收标准。
验收：每个高风险断点都有可执行的兜底措施和关闭条件。
临时控制：证据不足人员、错版风险流程和失控权限暂停新增任务。
后30天 · 接通系统与验收
再回答“怎样长期稳定证明”
1. 明确四层系统职责
参与角色：业务 / 质量 / IT / 档案
交付物：质量体系、MCRM/CTMS/eTMF等业务系统、电子签约服务和长期档案的职责边界图。
验收：每类数据都有权威来源、关联键、保留位置和唯一A。
临时控制：权威来源冲突时停止自动流转，转人工复核。
2. 把供应商责任写进合同和验收
参与角色：采购质量 / 法务 / IT安全
交付物：能力边界、接口、日志、变更、退出、数据导出、支持与责任清单。
验收：供应商能演示失败、撤回、重签、过期、权限撤销和证据调取，并提交对应材料。
临时控制：无法回答边界问题的能力不进入关键流程。
3. 测试版本、权限与异常
参与角色：质量 / IT / 业务验收人
交付物：需求、测试、验证、最小权限、稽查轨迹、备份恢复及异常用例记录。
验收：旧版停用、越权阻断、撤回重签、断网恢复和离职停权均通过预设用例并留有签字记录。
临时控制：未通过的能力由受控人工流程和双人复核兜底。
4. 完成端到端穿透演练
参与角色：业务责任人 / 合规 / 质量 / IT / 档案
交付物：真实事件穿透报告、剩余差距、CAPA和上线后监测计划。
验收：十分钟内复原责任、授权、版本、行为、时间、异常与归档；重大缺陷为0，其他缺陷有获批临时控制和关闭期限。
临时控制：演练未通过的场景不得扩大使用范围。
卡片中的“参与角色”不是并列A。每条业务线必须由管理层指定唯一A：医药代表线通常由商业合规负责人承担，新版GCP线通常由申办者临床质量负责人承担；跨线冲突由Day 0确定的管理层发起人升级裁决。
统一验收口径
不挑“最好看的单一样本”。每类高风险事件至少抽取一个正常样本、一个异常样本和一个权限或版本失效样本；重大缺陷必须清零，其他缺陷须有唯一A批准的临时控制、到期日和关闭人。验收结果由业务、质量和IT分别签字。
临时控制也必须可审计
每条临时控制登记触发条件、动作、唯一A、执行人、证据位置、复核频率、最长有效期、例外审批和关闭条件。临时控制只用于降低整改期间风险，不替代法规要求、伦理决定、正式审批或上线前系统验证。
业务供应商先过五道门
对专业组织、CRO、SMO及其他业务服务方，先核查真实委托关系与人员能力、职责矩阵、转包或机构外委托所需同意、监督与CAPA机制、数据和权限退出。下面十问则专门面向电子签约与数字系统供应商，两类尽调不能混用。
数字系统供应商核查十问：不要只问“能不能签”
1身份核验结果、企业代表权和医药业务授权怎样关联，而不是只证明“是这个人”？
2怎样锁定授权书、方案、伦理批准文件或业务模板的正确版本，并阻止旧版继续新发起？
3怎样证明签署意愿、具体时间、签署状态和原文完整性；证据报告由谁、在何处独立验证？
4拒签、失败、撤回、过期、重签、断网和重复提交怎样处理，原记录是否保留？
5审批日志、签署日志、接口回调和真实业务事件怎样用唯一主键关联？
6平台证据能证明什么、不能证明什么；是否会误导业务人员把“签署成功”当成“业务合规”？
7怎样嵌入MCRM、OA、CTMS、eTMF等现有系统；哪些是通用API，哪些需要项目开发与验证？
8数据保存、导出、备份、迁移、独立验签和供应商退出机制是什么？
9产品版本、接口、认证通道或底层服务变化时，谁通知、谁评估、哪些流程必须复验？
10请供应商明确其对系统验证支持、培训、变更通知、故障响应和证据调取承担什么；企业内部的业务验收、SOP、持续监测与CAPA仍由哪个唯一A负责？
10′
最简单也最诚实的验收门
随机选择一次医药代表活动，或一次临床试验关键签署。如果企业不能在十分钟内回答“谁、基于什么授权、对哪个版本、在什么时候、完成了什么、异常如何关闭”，问题就不在制度数量，而在治理链仍然断着。
十分钟是本文建议的内部演练标准，不是法规法定时限。
12 · 容易被忽略但决定成败的边界
六句话，防止系统从第一天就建错
并非所有企业同时适用两项制度
先按真实业务判断是否涉及医药代表管理、药物临床试验，还是只有其中一项。
医疗器械推广不在该办法范围
不能把药品医药代表管理办法直接套到医疗器械推广人员。
备案不等于准入
医疗卫生机构仍要核验身份和备案信息，并按自身制度决定接待。
委托不等于卸责
MAH、申办者和PI的主体或最终责任，不会因为合同、平台或第三方而自动消失。
电子签名不等于全部合规
它不替代伦理、知情质量、科学判断、活动内容、源数据、系统验证与CAPA。
平台副本不等于长期档案
还要设计留存期限、独立验签、元数据、备份恢复、迁移、退役和供应商退出。
技术最有价值的时候，不是把责任藏进系统，而是让责任在系统里变得更清楚、更难越界、也更容易被验证。
13 · 证据、方法与阅读边界
本文如何保证“看得懂”与“说得准”同时成立
法规事实来自官方公告与正式附件；e签宝能力来自官方产品页、开放平台文档、经敏感分级的医药业务知识库和脱敏真实界面；治理模型、十分钟测试与行动顺序明确标注为本文分析。
国家药监局｜医药代表管理办法公告2026年第42号；核验发布机关、正式正文和8月1日施行。
《医药代表管理办法》正式附件用于主体责任、授权备案、机构接待、活动规范、变更退出和监督处置等条款级核验。
国家药监局｜新版GCP公告2026年第50号；核验9月1日施行、正式附件及2020版废止。
新版GCP正式附件用于适用范围、职责、知情同意、数据治理和计算机化系统等条款级核验。
e签宝｜身份认证实名核验服务供应商官方材料；证明核验方式和接入能力，不证明行业业务合规。
e签宝开放平台｜电子签名能力供应商官方材料；用于签名、时间戳、原文保护和过程证据能力说明。
e签宝开放平台｜签署证据与验签报告供应商官方材料；报告支持技术核验，但不能证明业务事实或临床判断正确。
e签宝开放平台｜SaaS API V3能力清单用于系统集成范围说明；不代表现成行业连接器或已完成验证。
中华人民共和国电子签名法电子签名法律边界的官方材料；不能替代医药行业专业义务。
表达规则：本文严格区分正式法规事实、e签宝供应商能力主张、知识库案例线索、编辑分析与未知边界。知识库检索命中的医药案例只用于提炼去标识化的实施模式，不作为监管认可、客户公开背书或项目合规结论。任何产品截图、电子签名、时间戳、存证或验签报告，都不能单独证明企业已经符合医药代表管理办法或新版GCP。本文也没有对任何具体企业的系统、流程、合同、人员资格、历史记录或实施效果做现场验证；这些未知项必须通过真实事件重开、系统验证、合同与权限复核才能确认。具体项目仍应由企业合规、法务、质量、业务、IT和档案团队结合真实流程完成判断、验证与批准。
把制度变成可以运行、可以检查、可以持续的业务链
如果你正在梳理医药代表管理、临床试验电子签署，或需要把身份、授权、文件版本和证据服务嵌入现有 MCRM、OA、CTMS、eTMF 等系统，可以一起做一次真实业务链穿透。
