EClinCloud 与出海授权交易：EDC 导出怎样变成接收方可复核的临床数据交接包

中国创新药对外授权（License-out）里，临床数据包经常被写成“已经锁库、可以交割”。出让方的商业拓展（BD）团队把临床总结报告（CSR）、方案草案和锁库后的 SAS 分析数据集放进虚拟数据室（VDR），交接看起来已经具备基础。接收方（Licensee）的临床数据管理（Data Management, DM）与质量保证（QA）卡住的，往往不是文件名，而是一串更底层的问题：

这批导出的数据，能否在完全断开原 EDC 租户环境的情况下，由接收方独立重建当时的试验状态？数据字典与受控术语编码表是否保留完整版本映射？锁库时的逻辑核查规则、未解决或已关闭的质疑历史、带有时戳的动态稽查轨迹（Audit Trail），以及锁库瞬间的用户角色权限快照在哪里？

如果出让方只能交出一堆静态的 SAS 数据集或不可检索的 PDF 扫描件，接收方在未来面对美国食品药品监督管理局（FDA）或欧洲药品管理局（EMA）检查时，将很难独立证明试验记录的完整性与不可篡改性。分析用数据集回答的是“终点统计结果是什么”，而监管级可复核交接包回答的是“这个结果是如何一步一步记录、核实并锁定下来的”。交易结构、首付款和里程碑怎么拆，不是本文的题目，本站已有创新药 License-out 交易全流程。

本文立足中国申办方出海授权的数据交割边界，依据截至 2026 年 9 月仍现行的 FDA 2024 年 10 月电子系统问答指南、ICH 于 2025 年 1 月 6 日发布的 E6(R3) Step 4 文本，以及 EMA 2023 年计算机化系统指南，先给出可操作的临床数据交接验收矩阵。后文会以 EClinCloud EDC 临床数据采集系统公开页上的锁库与导出步骤作为公司描述的例子，说明向供应商索取“代表性导出演示”时应核验什么；这不是我们实测过该平台导出的结论。

分析用 SAS/CSV 快照和可复核交接包差在哪一层？

许多团队在首次主导跨境授权时容易陷入一种误区：以为统计团队用于跑分析脚本的 SAS 传输文件（如 .xpt 格式）或逗号分隔值（.csv）文件，就是临床试验的全部数据资产。监管逻辑里，这两套对象差的不是“有没有表”，而是接收方离开原系统界面之后还能不能解释这张表是怎么来的。

对象	分析用数据快照	监管级可复核交接包
形态	原始记录经过提取、清洗、派生后的平铺二维表（常见为分析用 SAS/CSV，后续也可能再做成 SDTM 或 ADaM）	带运行期上下文的动态数字档案
服务目标	供统计程序员运行模型，生成疗效与安全性表格、图表、列表（TFLs）	使独立第三方在不依赖原软件厂商运行界面的前提下，追溯并重建试验记录
通常带什么	终态分析值、受试者级分析变量	分析数据 + 数据字典 + 注释 eCRF + 动态稽查轨迹 + 质疑库 + 权限快照 + 锁库日志
缺了会怎样	统计还能跑，但无法回答“这个值曾经被谁改过、为什么改”	尽调可以降级；检查时很难提供重建试验所需的记录、元数据和稽查轨迹

美国 FDA 在 2024 年 10 月定稿的《临床试验中电子系统、电子记录和电子签名的问答》（Electronic Systems, Electronic Records, and Electronic Signatures in Clinical Investigations: Questions and Answers）是现行非约束性指南。第 Q5 问的英文原文大意是：作为检查的一部分，FDA 可能要求受监管实体提供重建临床试验所需的全部记录和数据，包括相关元数据和稽查轨迹；也可能要求这些人可读副本（例如截屏或纸质打印），副本应包含元数据和稽查轨迹信息。当系统退役且无法重新启用，或与托管系统的合同结束时，申办者应确保取得元数据并留存，且能与每个对应数据元素关联。以上为中文转述，不是 FDA 官方中文译本。人可读副本并不能单独否定 EMA 对动态格式的要求，后文会并列说明。

这一定性直接否定了“只要导出结果表就万事大吉”的侥幸心态。美国联邦法规 21 CFR 11.10(b) 规定，封闭式系统必须有能力生成准确、完整的记录副本，同时具备人可读形式和电子形式，供监管机构检查、审查和复制；11.10(e) 要求使用安全的、计算机生成的、带有时戳的稽查轨迹，且任何修改不得掩盖原先记录的信息。把 11.10 的监管审查能力类比到接收方尽调，是操作判断，不是法条把 licensee 写成 FDA。

国际人用药品注册技术协调会（ICH）在 2025 年 1 月 6 日发布的 ICH E6(R3) Step 4 文本中，第 4.2.5 节要求：在计算机化系统之间传输电子数据（包括相关元数据）时，应通过经验证的程序或对账等适当过程保持完整性与保密性，交换/传输或系统迁移应被记录以确保可追溯。第 3.16.3(a) 节写明：申办者（或数据的后续所有人）应按适用监管要求留存申办者侧必需记录。该文本日期是 2025-01-06，各区域实施节奏不同，不能写成当天全球自动强制生效。

商业交割签字本身，并不自动把原试验申办者的身份改写成接收方。如果协议把必需记录的所有权转过去，后续所有人的留存义务才会进入画面；原申办者对已经产生的记录，通常也不能只靠“已经点过导出”来脱身。如果中国出让方提供的交接包无法支撑独立复核，接收方的法规尽调会亮红灯。

接收方最低要能重建哪些对象：编码表、质疑史、稽查轨迹、权限快照与锁库记录

为了让出海授权交易中的临床数据交割脱离口头承诺，双方需要一份清晰、颗粒度明确的验收标准。结合 FDA、EMA 与中国国家药监局（NMPA）在 2016 年发布的第 112 号、第 114 号通告，以及 2026 年 9 月 1 日施行的最新版《药物临床试验质量管理规范》，一个合格的可复核交接包，最低应当包含以下十二项核心对象。

临床数据交接验收矩阵（Handover Acceptance Matrix）

下表总结了跨境授权中临床数据交割的关键对象、技术形态、验收要求与常见断裂点：

交接对象	核心内容与技术形态	接收方可复核能力	缺失后的关键断裂点	出具方与签署主体	尽调演示核查重点
1. 分析数据集	锁定版本的数据表（SAS .xpt / CSV / 关系数据库转储）	独立重跑统计分析，验证主要与次要终点计算结果	无法复现临床总结报告（CSR）中的疗效与安全性指标	出让方生物统计团队 / 委托 CRO	数据行数、受试者总数与锁定协议是否一致
2. 数据字典与受控术语	数据库架构规范、变量名定义、赋值代码表、单位转换规则	解释每一列变量的业务含义与有效取值范围	面对数值编码（如 1=缓解，2=进展）无法确认真实临床含义	数据管理团队（DM）	字典版本是否与试验方案及 eCRF 终稿版本保持一致
3. 空白与注释 eCRF	Blank eCRF 及标注变量映射名称的 Annotated eCRF（PDF）	将页面录入项与后台数据库字段精确锚定	无法核验临床试验方案中的观察项是否全覆盖录入	数据管理团队（DM）	注释变量名与分析数据集中的原始变量名是否逐一匹配
4. 动态稽查轨迹	包含字段名、旧值、新值、修改原因、操作人ID、时戳的导出文件	还原任意数据点自初次录入至最终锁库的变更全过程	无法应对监管关于关键疗效指标被修改的历史溯源	系统平台自动生成 / DM 导出	是否为可过滤、可检索的动态格式，而非截断静态图
5. 质疑库与关闭历史	系统自发逻辑核查质疑与人工质疑明细，含提问人、答复、关闭状态	确认全部关键数据差异在锁库前已达成临床一致并合规关闭	无法证明未解决的数据矛盾是否影响分析终点有效性	数据管理团队（DM） / 临床协调员（CRC）	检查是否存在为赶锁库进度而批量强制关闭的异常标记
6. 用户角色与权限快照	锁库时刻所有研究中心、CRO、申办方人员的权限清单与操作范围	排除未经授权者录入数据，或锁库后非受控编辑的可能	无法向检查员解释某条关键记录修改者的真实系统授权	系统管理员 / 质量保证（QA）	确认锁库触发后，中心端录入权限是否按时变更为只读
7. 锁库与解锁审批流	锁库申请表、各方签字确认函、软锁/硬锁执行记录、解锁日志	证明数据冻结程序的合规性，核查解锁期间变更的必要性	解锁改数若无受控审批日志，整批数据可信度将受质疑	申办方代表、PI、统计师、DM 共同签署	解锁后是否重新执行完整盲态核查并再次正式签字锁定
8. 逻辑核查与派生规则	Edit Check 规格说明书、派生变量生成逻辑与算法文档	复核系统自动报错与派生计算（如无进展生存期 PFS）的准确性	接收方若重新部署系统，无法重现自动化质量控制规则	数据管理团队（DM） / 程序员	规格说明书是否包含修改生效日期与对应测试记录
9. 医学编码词典映射	不良事件与伴随用药编码库（如 MedDRA、WHODrug）及版本记录	验证首选术语（PT）、系统器官分类（SOC）与商品名归类	跨监管机构重新递交时，词典版本不一致导致安全信号偏移	编码专员 / 医学审评人员	记录所用 MedDRA / WHODrug 的具体版本号及未编码清单
10. 外部数据对账记录	中心实验室、PK/PD、影像核心实验室与 EDC 对账关闭签字表	证明非 EDC 直接录入的客观检查数据已无缝合并且无遗漏	出现受试者有化验结果却在分析中被遗漏的重大偏差	数据管理团队（DM） / 实验室项目经理	访视时间窗口错位与受试者编号不符的异常处置单
11. 中心受试者留存副本	研究中心归档的完整受试者 eCRF 副本（通常为带时戳只读 PDF）	确保研究者持有一致记录，防范中心与申办方数据“两张皮”	监管进行机构现场核查（BIMO）时，与中心原始病历不符	系统自动归档 / 机构监查员（CRA）分发	是否包含研究者电子签名、页面产生时间及所有依附质疑
12. 系统配置与版本说明	EDC 软件版本号、补丁记录、部署配置说明与关键验证总结摘要	证明数据产生于受控、经过验证的计算机化系统运行环境	缺少试验级验证摘要时，很难把系统控制与这次导出对上号	系统供应商（Vendor） / 验证团队	区分通用商用版本功能与针对该试验定制开发的特定逻辑

失败导出重建场景：一个假设的境外尽调红旗案例

为了更具象地说明交接漏洞的破坏力，我们构建一个在境外尽调中常见的假设情景（注：本案例为分析用虚构场景，用于说明技术逻辑，非特定企业真实事件）：

在 2026 年初，中国某创新药企 Biotech A 拟将其自主研发的双抗抗肿瘤资产全球权益对外授权，某跨国药企 Buyer B 开展全面质量与数据尽调。Biotech A 的商业拓展（BD）团队向虚拟数据室上传了 II 期临床试验的最终 SAS 数据集、已签署的临床总结报告（CSR）以及一份由合作 CRO 出具的简短锁库备忘录。

在数据室中，Buyer B 的临床数据尽调官抽检了一项关键疗效数据：某中心一名晚期实体瘤受试者在第 16 周的影像学肿瘤评估由“疾病稳定（SD）”转为“部分缓解（PR）”。这例 PR 使得该队列的客观缓解率（ORR）刚好突破 30% 的统计学预设阈值。

尽调官要求核对该数据点的产生历史，随后出现了一连串断链反应：

【核查环节 A：查阅 SAS 统计分析表】
尽调官打开数据集，字段 AVAL 显示为 "PR"，基线靶病灶长径总和缩小 32%。
数据本身规整平滑，无法直接看出具体录入过程。

【核查环节 B：调取该字段的稽查轨迹（Audit Trail）】
出让方仅能从数据室中找到一份导出的静态 Excel 表格。表格显示，在 2025 年末数据库
锁库日前 3 天，该受试者靶病灶长径总和被修改过一次，旧值为 48mm，新值为 43mm，
刚好由缩小 26% 变为缩小 32%。修改原因栏仅显示下拉框默认文本“录入笔误”。

【核查环节 C：追查修改人身份与真实授权】
导出的静态表格仅标注系统工号 "USER_082"。出让方未能同步交接锁库时刻的
用户权限快照与人员映射表，无法在离线状态下证明该账号究竟属于中心主要研究者、
临床研究协调员（CRC），还是 CRO 的远程数据管理员。

【核查环节 D：核实当时的原始质疑与答复往来】
由于交接包内未包含系统运行期的全局质疑库（Query History），出让方无法出具
中心临床医生曾对测量值变化进行书面确认的凭据，无法排除数据管理员擅自改数的嫌疑。

【核查环节 E：比对锁库与解锁受控记录】
尽调官比对时间戳发现，该操作发生在临床数据库“软锁（Soft Lock）”之后、“硬锁（Hard Lock）”
之前，但交接材料中没有任何解锁审批单、偏差记录或重新盲态核查的记录。

尽调结论直接将该缺陷标记为严重合规红旗。

Buyer B 的法规顾问明确提出：若以此数据直接作为后续在美国或欧盟申报注册的基础，一旦遭遇 FDA 生物研究监督检查（BIMO），申办方将无法证明数据记录符合 21 CFR 11.10(e) 的完整追溯要求。

最终，该笔授权交易的技术交割被迫延宕近 60 天。出让方不得不紧急协调原系统平台调取底层日志、重新检索历史质疑存档、由涉事中心研究者出具书面补充说明，才得以勉强完成交割。这不仅耗费了数十万元的技术补救成本，也严重削弱了出让方在后续里程碑付款谈判中的主动地位。

静态 PDF 列表能不能代替动态稽查轨迹和质疑库？

在数据交割过程中，一些出让方为了省事，往往选择将 EDC 里的稽查轨迹或质疑列表一键打印为数十本动辄数千页的 PDF 文件。许多非技术背景的管理人员常有疑问：既然 PDF 也是电子文档且带有系统生成时间，为什么跨国接收方通常拒绝接受这种形式？

欧洲药品管理局（EMA）在 2023 年发布的《临床试验中计算机化系统和电子数据指南》（Guideline on computerised systems and electronic data in clinical trials, EMA/INS/GCP/112288/2023）把这件事写得很具体。这是欧盟检查员工作组指南，不是 21 CFR 原文。

第 6.12 节讨论数据库退役：退役后应归档注明日期的核证副本，并确保归档格式提供恢复数据库的可能，包括恢复动态功能以及全部相关元数据（稽查轨迹、事件日志、已实施的逻辑核查、质疑、用户日志等）；若无法重新启用，则全部数据及元数据文件应以动态数据文件提供。该节原文写明：动态数据的静态格式将不被认为充分。PDF 打印件是行业里最常见的静态形态，指南文本本身说的是 static formats，并不单点 PDF。

第 6.2.1 节补充了动态稽查轨迹要干什么：轨迹应在在线系统中于数据点级可见，并应能将完整稽查轨迹导出为动态数据文件，以便识别跨受试者、跨中心的系统性模式；轨迹应显示初始录入与变更（旧值与新值）、何字段、何人（用户名、角色、组织）、何时，以及在适用时为何。

把动态数据压成静态 PDF 之后，接收方面对的通常是三件事叠在一起。海量变更没法用查询或脚本批量筛异常；排版切断了稽查记录与受试者编号、访视、表单、字段主键的关联；版面宽度还常截断修改原因或长文本质疑答复。在我们看来，交接包里的稽查轨迹与质疑库应以结构化、可检索的动态格式为底线。静态 PDF 可以给人翻阅，但不能替代核心动态文件。

SDTM/ADaM 递交包能不能替代 EDC 运营导出？

另一个在出海企业中极为普遍的疑问是：“我们已经请统计编程团队把临床数据转换成了 CDISC 标准的 SDTM 和 ADaM 数据集，并且通过了 OpenCDISC/Pinnacle 21 校验，生成了完整的 Define.xml。这套可以直接递交给 FDA 的数据包，难道还不够用于授权交割吗？”

答案是：递交包必不可少，但它无法替代 EDC 原始运营重建包。

这两套数据包在监管审查链条中承担着截然不同的法定职责。下表清晰界定了两者的边界：

运营重建包、监管递交包与中心归档包对照表

比较维度	EDC 运营重建包 (Operational Reconstruction Pack)	CDISC 监管递交包 (Submission Pack: SDTM/ADaM)	研究中心归档包 (Site Archive Pack: Subject PDF)
主要服务对象	现场核查员、接收方 QA/DM、数据审计专家	审评中心统计学家（Reviewer）、流行病学审评员	临床试验机构（Site）、主要研究者（PI）
核心数据形态	数据库原始转储、动态稽查轨迹、底层质疑库、配置字典	经过清洗、重构、标准化的领域表（Domains）与衍生变量表	冻结的受试者独立电子病例报告表（eCRF）只读集合
对修改历史的还原	极高：精确记录每个单元格被谁在何时更改、因何更改	极低：通常仅保留终态清洗值，不记录中间纠错往来	中等：直观展示最终页面与依附在该页的质疑/修改摘要
能证明什么	证明临床试验在运行期间真实发生、受控记录且不可篡改	证明临床试验结果符合审评格式标准，便于监管运行模型验证	证明研究者在现场对录入数据进行过审查，未发生信息背离
不能证明什么	通常不能作为 CDISC 申报结构直接进入审评工具链	无法自证数据录入过程的真实性（原始瑕疵数据转换后仍是标准的瑕疵数据）	无法供独立第三方进行大规模批量计算与统计模型重新拟合
主要法规与依据	FDA 2024 电子系统 Q&A Q5；EMA 指南 6.12 动态归档	FDA Study Data Technical Conformance Guide；21 CFR 314.50	21 CFR 312.62；ICH E6(R3) 3.16.2 研究者留存要求

递交包是对原始数据进行清洗、衍生和格式重构的产物。在从 EDC 导出向 SDTM 转换的过程中，数据管理员执行了大量字段映射、编码替换与算法派生。若交割时仅提供递交包，一旦海外监管机构在审评期间对某个关键衍生逻辑提出问询（例如某类伴随用药是否被合理归类为抗肿瘤治疗），申办方必须向上溯源至原始 EDC 字段及每次修改的历史轨迹。

缺乏运营重建包作为根基，递交包就成了悬空的数据产物。接收方一旦被切断了与底层运营环境的技术联系，后续面临任何深度审查都将陷入被动。

申办者所有权、CRO 经手和供应商导出功能分别保证什么、不保证什么？

在多方参与的临床开发中，数据往往由云端系统承载，日常清洗由 CRO 团队操作，而对外签署授权协议的是申办方。这种多层委托关系极易模糊合规责任边界。在授权交割时，三者的法定与合同责任必须划分明确：

申办方、CRO 与系统供应商在数据交割中的责任分工表

参与主体	法定身份与责任范畴	能保证什么（能力边界）	不能保证什么（常见误区）
申办方（出让方 / Sponsor）	法定数据所有权人与最终合规责任人，承担 21 CFR 312.57 及 ICH E6(R3) 留存义务	有义务向接收方交付可重建的记录，并按合同承担交割不符的责任	不能以“系统由第三方开发、数据由 CRO 录入”为由推卸适用法下的责任
CRO（合同研究组织）	受托业务执行方，按合同执行数据核查、质疑管理、对账与锁库操作	保证按临床数据管理计划（DMP）与操作规程（SOP）执行日常清洗	不因受托服务而自动承担申办者的最终法定留存责任；服务范围受限于合同工时与预算
EDC 软件供应商（Platform Vendor）	计算机化系统技术提供方，提供系统架构、验证环境与数据导出功能	保证系统功能符合设计规格，具备支持锁库与提取动态元数据的技术能力	不保证特定试验中用户配置的合理性，不担保数据录入质量，亦不保证监管机构接受该试验

申办者这边，底线看的是留存时钟，不是导出按钮。美国 21 CFR 312.57(c) 要求申办者保留本部分规定的记录和报告：药品上市申请获批后 2 年；若申请未获批，则保留至试验用药品停止装运交付并通知 FDA 后 2 年。对象是 IND 框架下的申办者记录，不要写成全球统一年限。欧盟第 536/2014 号法规（EU CTR）第 58 条要求临床试验主文件（TMF）内容至少保存至试验结束后 25 年（除非其他欧盟法律要求更长），主文件所有权的任何转移均应记录，新所有人承担该条责任。25 年时钟针对的是 TMF 内容完整可读，不要直接写成“EDC 原始库必须在线 25 年”。商业协议里的免责声明，通常也撤不掉适用法下的记录留存义务。

CRO 是受托操作者。出让方有时以为“CRO 交了锁库报告，数据包就自然过关”。履约范围仍受服务任务书（SOW）约束。当初没约定完整元数据与动态底表提取，结项时拿到的往往只是标准平铺数据集。

系统供应商能保证的，是平台具备设计规格里的控制功能与导出能力。它不能代替申办方核实入组标准执行情况，也不能担保境外监管机构接受某一项试验的临床结果。

锁库证明、解锁日志和锁库时的用户角色为什么必须一并交接？

在诸多交接材料中，最容易被出让方忽视的是围绕“锁定”动作本身的过程凭证。

许多申办方认为，既然最终导出的是锁定状态的数据，为什么接收方还要详细查验锁库审批单与解锁日志？

锁库是把试验从数据收集清洗阶段切到统计分析阶段的受控节点。ICH E6(R3) 第 4.2.6 节要求，分析前定稿活动须按预先程序确认并记录。它是协调指南里的过程要求，不是单独一条名叫“锁库”的法条。

在交接包中，以下三类过程凭据至关重要：

正式锁库证明（Lock Certification）：行业常见做法是由主要研究者（PI）、数据管理负责人、生物统计负责人和申办方项目代表联合书面确认：预设质疑已关闭、外部中心化检测数据已合并对账、盲态审核（如适用）已完成。具体签字人组合以该试验 DMP 和 SOP 为准，不是法规点名的固定四人组。
解锁与再锁定记录（Unlock & Re-lock Records）：因紧急安全性核实或重大逻辑修正而解锁，并非一律禁止；每一次解锁应留下变更申请、风险评估和再锁定前的数据差异比对。若交接数据来自一次没有记录的解锁，整批数据的客观性会很难辩护。
锁库瞬时的权限快照（Role Snapshot at Lock）：锁定指令执行时，拥有编辑/录入权限的账户是否已被收成只读。没有这份快照，接收方很难排除锁库签字后仍有人改数的可能。

EClinCloud 公开材料里的锁库导出该怎么引用，演示导出该怎么要？

验收标准应先独立于任何一家供应商成立。讨论到导出功能时，可以引用公司公开材料，但不能把营销数字当成重建证据。以 EClinCloud（一临云）官方页面为例：公开材料描述了 EDC 数据流转和合规对齐，部署方式与数据存放方案写明在评估阶段与团队确认，页面没有列出具体托管国家或导出文件扩展名。

EClinCloud 公开材料的功能定位与引用边界

其 EDC 临床数据采集系统英文工作流第 5 步写的是：清理、锁定并导出数据库，随后交接给数据管理与生物统计服务，以形成可供递交的输出（submission-ready outputs）。中文对应页概括为“锁库与交付”。这是公司对产品步骤的描述，不是 FDA 或 EMA 已经接受某一次导出。

EClinCloud 专业服务页面列出研究构建、数据与商业智能（BI）、实施与托管等服务。数据与 BI 写的是质量分析与跨研究报表，不能直接等同于授权交割包。EDC 页把建库工时缩减 60%、OCR 整体识别率 95% 写成产品指标；公司首页另列超过 20,000 名全球用户、300 余家机构等业务数据。这些都是公司自述，不是独立测试，也不能证明某一次 License-out 导出可重建。

EClinCloud 信任与合规页面写明面向受监管临床试验验证使用，并列举 21 CFR Part 11、EU Annex 11、ICH E6(R3)、GAMP 5、CDISC 以及 2026 年中国 GCP。这是对齐陈述。FDA 或 EMA 不对第三方商业软件颁发“合规批准证书”；某一试验是否站得住，仍取决于申办方在该试验中的计算机化系统验证（CSV）和实际使用。

服务边界也要分开：量表管理（Scale Management）是围绕临床终点量表的运营服务；资源管理（Resource Management, RM）处理合同、人员与收支，二者不是同一件事。公开材料未列出导出格式，向供应商要的应是代表性导出演示，而不是假定已经输出 CDISC ODM 或某一国家的托管实例。

申办方与接收方：向供应商索取“代表性导出演示”的提问清单

无论用哪一家 EDC，授权签字前或尽调期间，比白皮书更有用的是：基于已锁库的测试库，做一次现场或远程的代表性导出演示（Representative Export Demonstration）。DM 与 QA 可以按下面六个问题核对。演示问的是“能不能当场导出并离线打开”，不是“我们是否已经测过某平台”。

问题 1：稽查轨迹的导出颗粒度与动态性。 不登录原界面时，能否把某位受试者的完整稽查轨迹导出为包含字段旧值、新值、修改人、系统角色、精确到秒的时间戳、修改原因的结构化文件？文本有没有被截断？

问题 2：数据库字典与数据架构。 元数据包是否包含代码变量与受控术语映射？数据表里的“1”能否直接对应到“完全缓解（CR）”？变量定义是否带字段格式、单位和逻辑校验规则？

问题 3：质疑处理与关闭记录。 能否独立导出全局质疑报告？系统逻辑质疑与人工质疑的提出时间、答复、重新打开以及关闭人和关闭时间戳是否都在？

问题 4：用户权限快照。 系统能否出具执行锁定那一刻的活跃账户清单？锁库时间之后，中心录入人员的编辑权限是否已终止？

问题 5：外部实验室数据标识。 对经 API 或批量传入的中心实验室、PK 或影像数据，导出记录能否区分现场录入与外部导入？对账完成标记是否留在导出包里？

问题 6：脱离原平台的归档能力。 是否提供 CDISC ODM 或等价的动态归档？ODM 是供应商中立的交换/归档格式，不是法规点名的唯一合法介质。原租户停用后，接收方能否用这套文件在中立环境中恢复带稽查轨迹和表单结构的数据库？公开页未写 EClinCloud 已输出 ODM，演示里要当场看，不能写成已经具备。

这六个问题问完，双方大致能判断导出是可重建包还是一张无法离线解释的表。

PIPL、人类遗传资源和境外监管接受是相邻红线，为什么不能写成平台自动过关？

在聚焦技术可复核性的同时，中国申办方出海团队必须清醒地认识到：技术上成功导出一个完美的交接包，绝不等于该数据包可以自动、合法地传输至境外，更不等于该数据包会被海外监管机构自动认可。

在出海授权交易中，横亘在临床数据交割面前的，还有三道互不替代的法制红线：

                    ┌──────────────────────────────────────────────┐
                    │    维度一：国内数据合规与出境行政许可        │
                    │    - 个人信息保护法（PIPL）与数据出境安排     │
                    │    - 人类遗传资源国际合作或向境外提供的审批   │
                    └──────────────────────┬───────────────────────┘
                                           │
                                           ▼
                    ┌──────────────────────────────────────────────┐
                    │    维度二：技术层面的可复核性与完整性        │
                    │    - FDA 21 CFR Part 11 / 2024 Q&A Q5 重建    │
                    │    - EMA 6.12 动态归档与元数据关联要求       │
                    │    - 编码表、质疑史、稽查轨迹、权限快照齐全  │
                    └──────────────────────┬───────────────────────┘
                                           │
                                           ▼
                    ┌──────────────────────────────────────────────┐
                    │    维度三：海外监管科学层面的临床数据接受    │
                    │    - FDA 21 CFR 312.120：外国临床试验数据标准│
                    │    - ICH E5 / E17：种族敏感性与跨区域外推    │
                    │    - 临床医疗实践差异与主要终点测量一致性    │
                    └──────────────────────────────────────────────┘

中国数据跨境合规红线

受试者健康信息与人类遗传资源受《中华人民共和国个人信息保护法》（PIPL）、《数据出境安全评估办法》以及《中华人民共和国人类遗传资源管理条例》等规则约束。技术上能重建，不等于已经取得出境或国际合作所需的行政许可。去标识化做到哪一步、走安全评估还是标准合同、人类遗传资源要不要单独立项，属于法务和监管事务要单独判断的红线，本文不提供操作步骤，也不能把平台导出写成已经过关。跨境个人数据的欧盟侧讨论，见生命科学企业的 GDPR 跨境数据合规。

境外监管的数据接受与科学互认红线

即使数据包在技术上完整重建、在法律上完成出境安排，也不代表 FDA 或 EMA 会把中国境内临床数据直接当作批准依据。美国 21 CFR 312.120 适用于外国未在 IND 下进行的临床试验：要靠这类数据支持 IND 或上市申请，申办者须确保试验符合该条，且数据可信、准确。FDA 2024 年电子系统问答第 Q2 问还写明，非 IND 外国试验的数据质量、完整性和真实性，应与 IND 下采集的数据相当。科学外推仍要看 ICH E5、E17 以及医疗实践是否对得上，这是另一篇文章的题目，见临床数据桥接与互认。

技术交接包解决的是记录能不能还原。科学桥接解决的是结论能不能外推。把两者混成“某平台能让中国临床数据直接通行海外”，会把交割验收做成错误的通行证。

常见问题解答（FAQ）

Q1：只给锁定后的 SAS 数据集，接收方能不能做后续申报和检查准备？

不能。 锁定后的 SAS 数据集（如分析用的 flat files）只够统计人员跑代码、生成表格和核对数值终点。进入审评或现场检查后，监管要看这些数据如何被收集、清洗和确认。缺少数据字典、注释 eCRF、未截断的动态稽查轨迹和质疑处理历史，接收方很难回答关键数据为何被改。这不等于检查员会自动写上“违反 21 CFR 11.10(b)(e)”——11.10 约束的是受监管实体的系统控制能力——但交接包若不能生成准确完整的可审查副本和不可掩盖的稽查轨迹，检查准备会明显被动。

Q2：CDISC ODM 是不是法定唯一的强制交接格式？没有 ODM 是不是就不能交割？

不是法定强制，但它是极具价值的中立标准。 法规（如 FDA 21 CFR Part 11 或 ICH E6(R3)）并未指定某一种专有格式为唯一合法归档介质，法规的硬性要求是“能完整还原数据、元数据和稽查轨迹的人可读与机器可读格式”。CDISC 的运营数据模型（Operational Data Model, ODM）因其具备厂商中立性，并能将表单结构、管理数据、审计轨迹整合在一个 XML 规范中，常被作为优质归档的技术参考。没有 ODM 并不会导致交割在法律上被直接否决，前提是出让方能够提供等效的、无技术壁垒的关系型数据转储及完备的元数据文档。

Q3：把受试者 eCRF 打成只读 PDF 交给研究中心，能不能代替申办者侧的动态归档？

完全不能。 两者具有截然不同的法规责任主体。向研究中心提供带有电子签名的受试者 eCRF 副本，是为了满足 21 CFR 312.62 及中国 GCP 关于“研究者应当保留病例记录”的法规要求，防止机构数据与申办方数据产生不一致。而申办方（及后续数据所有人）依照 21 CFR 312.57 和 ICH E6(R3) 4.2.7 承担的是申办者级必需记录留存责任。中心留存的静态 PDF 无法供接收方进行全库检索、跨中心分析或算法稽查。

Q4：授权协议签了数据所有权转移，原申办方是不是就不用再保留原 EDC 访问？

依然需要保留阶段性通道或完整的离线核证镜像。 在商业合同层面，数据所有权可以从交割日起转移；在监管层面，原试验开展期间已经产生的记录，原申办者在适用留存期内仍可能被问到。E6(R3) 第 3.16.3(a) 节把后续数据所有人写进留存义务，第 3.16.3(c) 节还要求按适用监管规定报告必需记录所有权转移。这不等于原申办者可以立刻销户。若接收方后来要溯源，或 NMPA 做回顾性检查，原账户和归档一旦被切断，出让方自己也会失去应答材料。较稳妥的合同安排是约定过渡期访问，或在交割时制作一份注明生成时间、经双方技术团队核对的核证副本（certified copy），由双方各自留存。FDA 2024 年问答第 Q3 问对核证副本的要求是：经核实、含复制日期和时间，并具有与原件相同的信息（包括描述语境、内容和结构的数据）。任意一份 PDF 导出，都不能自动当成核证副本。

Q5：EClinCloud 官方材料提到了锁库与导出，是不是等于其导出的数据已经通过 FDA/EMA 认可？

不等于。 EClinCloud 官方材料描述的锁库、导出及相关专业服务，代表该软件产品具备支撑合规临床数据管理的技术机制。FDA、EMA 及 NMPA 从不针对任何单一软件产品颁发“监管通过认证”。任何临床数据的合规性与可接受性，均取决于申办方在特定试验中是否执行了严格的计算机化系统验证（CSV）、数据管理计划（DMP）是否被不折不扣地执行、质疑与修改是否合规且完整留痕。软件功能是实施的工具，而非监管豁免的保证。

Q6：在交割验收时，怎样核验稽查轨迹导出文件没有被截断或篡改？

应核对数据记录行数、校验哈希值并抽样比对时间戳。 接收方应要求出让方在导出稽查轨迹的同时，生成对应的安全散列算法校验码（如 SHA-256 Checksum）。接收方技术团队应核对稽查记录总行数是否与 EDC 系统日志计数完全吻合，并随机抽取若干例有多次修改记录的复杂变量（如伴随用药起始日期、不良事件严重度判定），与系统原始界面截图或中心源文件进行三重比对，确认修改原因与操作人代码完整无损。

Q7：如果原临床试验由多家外部中心实验室提供检验数据，交接包应怎样确认外部数据对账状态？

必须包含完整的外部数据传输规约与双方项目经理签署的对账确认函。 外部实验室数据（如 PK/PD 浓度、中心化生化检验）通常通过批量传输导入 EDC。交接包中必须包含原始数据传输协议（DTA）、字段映射说明表，以及每一批次数据传输的对账日志。最重要的是，必须具备在锁库前由 CRO 数据管理负责人与中心实验室负责人共同签字的“最终数据对账关闭确认单”，确认没有悬而未决的受试者编号错位或标本遗漏记录。

站内相关参考

创新药 License-out 交易全流程 — 梳理授权许可中的条款设置与交易结构
EDC 供应商 Part 11 验证包尽调 — 了解首例受试者入组前必须向系统供应商核验的验证文件
试验中途更换 CRO 或 eTMF 的迁移尽调 — 对比文档级系统迁移与数据库级数据交接的差异
EDC 与中心实验室、eCOA、安全数据库的接口风险 — 掌握多源外部数据接入 EDC 时的接口断裂与对账盲区
中心实验室与 EDC 数据对账 — 详解外部检验数据在锁库前必须完成的对账与签字确认标准
2026 版 GCP 与出海数据双轨切换 — 深入理解新版中国 GCP 数据治理专章与出海法规的衔接
临床数据桥接与互认 — 掌握数据完整性之外的种族敏感性与临床科学桥接原则
FDA 21 CFR Part 11 电子记录合规 — 详述电子记录完整性与稽查轨迹的核心监管要件
生命科学企业的 GDPR 跨境数据合规 — 了解数据交割涉及海外受试者时的隐私法律红线
百科：License-out — 查阅创新药对外许可核心概念与术语释义

参考法规与权威来源

U.S. FDA: Electronic Systems, Electronic Records, and Electronic Signatures in Clinical Investigations: Questions and Answers (October 2024) — 现行非约束性指南。着陆页标注 content current as of 10/02/2024。Q2、Q3、Q5 是交接包主源。
U.S. eCFR: 21 CFR 11.10 Controls for closed systems — 封闭系统控制：11.10(b) 准确完整的人可读和电子副本；11.10(e) 计算机生成、带时戳、不可掩盖的稽查轨迹。
U.S. eCFR: 21 CFR 312.57 Recordkeeping and record retention — 申办者 IND 记录留存：上市申请获批后 2 年，或停止装运交付并通知 FDA 后 2 年。
U.S. eCFR: 21 CFR 312.62 Investigator recordkeeping and record retention — 研究者病例病史与 CRF 留存；交接包不能取代中心源文件。
U.S. eCFR: 21 CFR 312.120 Foreign clinical studies not conducted under an IND — 外国非 IND 试验作为支持材料的 GCP 与检查可核验条件；单独依据外国数据批准另见 21 CFR 314.106。
ICH: Guideline for Good Clinical Practice E6(R3), Step 4 (6 January 2025) — 数据治理、传输可追溯性、分析前定稿及后续数据所有人的留存义务。各区域实施节奏不同。
European Medicines Agency: Guideline on computerised systems and electronic data in clinical trials (EMA/INS/GCP/112288/2023) — 欧盟检查员工作组指南。第 6.12 节：动态数据的静态格式不被认为充分。
EUR-Lex: Regulation (EU) No 536/2014, Article 58 Archiving of the clinical trial master file — TMF 内容至少保存 25 年；所有权转移须记录。不要写成 EDC 必须在线 25 年。
国家药品监督管理局：关于发布临床试验数据管理工作技术指南的通告（2016年第112号） — 官方发布页。锁库清单细节在附件；通告 HTML 通常不含附件全文。
国家药品监督管理局：关于发布临床试验的电子数据采集技术指导原则的通告（2016年第114号） — 发布 EDC 技术指导原则的官方通告页。锁库、导出等操作细节见所附原则，不在通告正文里假装已经展开。
CDISC: Operational Data Model (ODM) — 供应商中立的交换与归档格式。不是法规强制的唯一格式。
EClinCloud EDC 临床数据采集系统 — 公司官方产品页。英文第 5 步为清理、锁库并导出后交接数据管理与生物统计服务；中文为“锁库与交付”。
EClinCloud 专业服务（Professional Services） — 公司官方服务页。研究构建、数据与 BI、实施与托管；量表管理是独立服务，不要写成 RM。
EClinCloud 信任与合规页面（Trust & Compliance） — 公司列出面向受监管试验验证使用，并列举 Part 11、Annex 11、E6(R3) 等。对齐陈述，不是 FDA 批准。