药审中心发布临床试验计算机化系统和电子数据指导原则，解读其验证与数据可靠性要求

做临床试验数据管理的朋友这些年一直有个尴尬：GMP 侧早就有《药品记录与数据管理要求》、有计算机化系统附录可查，GCP 侧却长期缺少一份专门讲 「系统怎么验、电子数据怎么管」 的文件。遇到检查，大家只能拿 FDA 的 Part 11 问答、EMA 2023 年那份计算机化系统指南往上套。

这个空白现在补上了。

2026 年 9 月，药审中心发布《药物临床试验计算机化系统和电子数据指导原则》（https://www.cde.org.cn/main/news/viewInfoCommon/2c5d9c3f1afef1605b6a6d3a9df7b5ae），上接 ICH E6(R3) 和 2026 年修订版 GCP 新增的计算机化系统与电子数据章节，下接 EDC、IWRS、ePRO、eTMF 这些天天在用的系统。虽然文里照例写了「不具有强制性的法律约束性」，但做过迎检的都懂—— 指导原则就是检查员的出题范围 。

这篇把全文拆开，讲清楚四个问题： 它管什么、新要求在哪、和 EMA/FDA 比有什么不同、各方现在该做什么。

01

SCOPE

适用范围：比你想的宽

文件管的是「涉及临床电子数据生成或采集、保存、传输、分析、处理、报告及管理」的所有系统，原文用了 「包括但不限于」 ：

采集试验数据的电子系统

EDC、eCRF、ePRO/电子日记

随机分组与药物分配系统

IWRS/RTSM

临床试验电子文档管理系统

eTMF

注意「分析、处理、报告」也在范围内。统计编程环境、医学编码工具、药物警戒系统、中心实验室的数据传输接口，严格讲都落在这条线上。如果你所在机构还认为「只有 EDC 需要验证」，这份文件会逼着大家 把边界重新画一遍 。

02

DATA RELIABILITY

ALCOA++：两个加号不是笔误

文件把数据可靠性原则写成了 ALCOA++ ，十个要素：可归因、易读、同时、原始、准确、完整、一致、持久、可获得、 可追溯 。

原文

数据可靠性是指以安全的方式收集、访问和维护数据，并满足 ALCOA++ 原则……从而使数据能够在全生命周期内充分支持稳健的结果和良好的决策。

比常见的 ALCOA+ 多了「可追溯性」（Traceable）。这个写法与 EMA 2023 指南一脉相承，落到实操上就是一个要求： 任何数据点，都要能从报告值一路倒推回源数据、倒推到谁在什么时间为什么改过它。 只靠稽查轨迹开关打开是远远不够的， 稽查轨迹（对，原文就叫这个，怎么看都像是Audit Trail的机翻直译~）本身要可读、可导出、要定期审 。

03

RESPONSIBILITY

职责划分：一句话定调，委托不免责

原文

一般情况下，申办者负责提供和管理计算机化系统以及它们生成的记录，研究者负责使用申办者或自己的计算机化系统生成并存储数据，形成记录。……若委托供应商，委托方应承担最终责任。

「责任方」这个词贯穿全文 ，指申办者、研究者和临床试验机构。三句话记住：

1

系统是申办者的，数据责任是研究者的——研究者对自己录入 eCRF 的数据负责；

2

委托 CRO 或供应商不转移最终责任——验证做得好不好，最终板子打在委托方身上；

3

供应商验证只能「评估」，不能「采信」——责任方要评估供应商的验证活动和文件是否充分，不够的部分自己补。这与 GMP 侧「供应商评估+差距分析」的思路完全一致。

04

VALIDATION

系统验证：这是最「重」的一章

第三章「验证」一节把临床系统验证的骨架完整搭出来了，做过 GMP CSV 的人会觉得非常眼熟——本质上就是一套 基于风险的 V 模型思路 平移到了临床侧：

验证计划

写清验证方法、基于风险的策略、责任方与供应商的分工；

用户需求（URS）

覆盖操作、功能、数据可靠性、技术、界面、性能、可用性、安全、法规要求；责任方要「采纳并完全负责」URS，哪怕是供应商代写的；系统功能变了，URS 要在全生命周期内维护更新；

试验特定配置与定制

这是临床侧特有的重头戏——系统平台验过不算完， 每个试验的 eCRF 建库、逻辑核查配置、随机化参数都要单独验证 ，与方案、数据管理计划核对一致后才能上生产环境；

需求可追溯性

URS 到测试用例要有追溯链；

测试用例四要素

被测软件版本、先决条件、操作步骤、预期结果；要记录实际结果、证据（截图）和通过/失败结论；建议用例编写人与执行人分开；失败的测试要有偏差评估；

发布放行

未解决偏差和已知问题要在验证报告中评估， 责任方批准验证报告后系统才能发布 。

「以后临床系统『供应商说验过了』就上线的做法，在这份文件下站不住了。」

配置级的验证文档 （建库测试、UAT 记录、逻辑核查验证）会成为检查标配。

05

ACCOUNT & TIME

用户管理和时间戳：两条硬线

共享账户被明确判了死刑

原文

所有系统用户都应具有个人账户，共享账户（组账户）是不可接受的，并且违反了数据可靠性原则，因为数据应该是可归因的。

配套要求还有：权限按最小权限规则分配；权限要在培训记录确认后授予；系统要能随时输出「当前和既往」的权限清单并定期审核； 管理员账号要独立于试验管理和数据生成 ——这一条对很多小团队的打击是实质性的，一个人既当 DBA 又当 DM 又做医学审阅的模式该收一收了。盲态信息只允许预先定义的角色访问。

时间戳 三条：系统自动生成、定期与标准时间同步（多终端一致）、跨时区试验要记录本地时间并标注时区或转 UTC。时间戳本身要防篡改。多中心、多国家的项目，这条值得专门拉一次检查—— 终端设备时间不同步导致的数据时间混乱 ，在核查中是真出现过的。

06

DATA LIFECYCLE

电子数据：从采集到销毁的全生命周期

第四章占了全文一半篇幅，按数据生命周期组织。挑几个实操影响最大的点：

1. 稽查轨迹要「定期审」，而且要防破盲

稽查轨迹至少要含：改前的原始值、改后的新值、操作时间、操作人、 操作原因 。要能导出为动态文件， 保留期限与源数据一致 。特别提醒了一句：危及盲态的信息不能出现在盲态用户可见的稽查轨迹里——随机化系统的稽查轨迹权限设计，建议现在就自查一遍。

2. 元数据审核被单独点名

元数据审核（含稽查轨迹、访问日志、事件日志、质疑）要成为数据审核的 固定组成部分 。访问日志在含关键非盲数据的系统里被视为重要元数据， 必须可查看 。

3. 数据签署：不允许「锁库前一次性签」

原文

不应仅在数据库锁定前进行一次性数据签署，而应及时对直接录入 eCRF 的数据进行阶段性审阅和签署。试验中的数据采集工具应设计具备支持阶段性数据签署的功能。

期中分析和最终分析前必须完成签署；SAE、待裁定的重要事件、主要终点、DMC 审阅的数据要及时签署；递交上市申请前，所有拟递交数据先签署、再提取分析。 这直接影响 EDC 选型和建库时的功能确认——系统不支持阶段性签署，就是不合规风险。

4. ePRO 更正的特殊逻辑

受试者在 App 里通常改不了自己的数据，所以要专门建数据澄清流程；更正由受试者或研究者及时发起，但不能一刀切禁止更正——「 不应禁止在合理的情况下更正试验参与者数据 」。

5. 核证副本（Certified Copy）有了正式定义

经验证与原始记录一致、带认证标识（签名/时间戳/认证声明）、与原始记录同等法律效力。 复制数据默认不能替代原始记录 ，除非走完核证副本流程。归档或申报用的新副本，要启动核证副本程序并纳入 TMF。数据库退役前必须保留核证副本。

6. 云解决方案三句话

数据存储位置要明确（数据主权）；供应商要经资格评估、接受稽查，合同写清数据所有权、SLA、安全、迁移与销毁条款；云平台本身要经过验证。技术要求至少包括：加密传输与存储、完整稽查轨迹、多因素认证、可配置权限、灾备恢复。

7. 退役与销毁：补上生命周期的最后一段

数据库退役建议放在上市递交完成后的归档阶段；退役前完成归档并确保数据（含稽查轨迹在内的元数据）以动态文件形式可访问。销毁必须满足：保存期限届满、相关检查已完成、获相应批准、有正式销毁计划；电子数据用行业标准擦除工具，物理介质粉碎焚烧， 销毁记录作为稽查轨迹的一部分保存 、可供监管查阅。

07

LANDSCAPE

和 EMA、FDA 比，什么定位

文件的参考文献列表已经很说明问题：ICH E6(R3)、2026 版 GCP、EMA 2023 计算机化系统指南、FDA 2024 电子系统问答、Part 11。整体框架与 EMA 2023 指南高度对齐——甚至可以说，这就是 EMA 那套要求的 中国 GCP 语境落地版 ，再叠加了几个本土化的点：

与 2026 版 GCP 的章节直接挂钩，检查时有国内法规抓手；

跨境数据传输明确要遵守中国法律法规并告知受试者；

数据签署、核证副本、数据库退役和销毁写得比 EMA 更细、更可操作；

对供应商管理、云服务的合同要素列得更具体。

对出海做国际多中心试验的团队，一个好消息是：按这份文件建起来的体系，与 EMA/FDA 的期望基本同构， 一套验证包可以两边用 。

08

CHECKLIST

现在该做什么：按角色列个清单

申办方 / CRO（数据管理、IT、QA）：

☐ 盘点全部在用的临床试验系统，划定哪些落入本指导原则范围， 建立系统清单和验证状态台账

☐ 评估现有供应商（EDC/IWRS/ePRO/云）验证包的充分性，差距部分安排补充验证

☐ 建立或修订试验特定配置的验证规程（建库测试、UAT、逻辑核查验证、方案修订的再验证）

☐ 检查 EDC 是否支持阶段性数据签署，不支持的在升级或换型时列入硬性需求

☐ 清理共享账户，确认管理员账号独立于试验运营角色

☐ 建立稽查轨迹和元数据（访问日志、事件日志）的定期审核机制并留痕

☐ 复核供应商合同：数据所有权、SLA、验证文档访问权、迁移与销毁条款、归档责任

☐ 制定/演练应急计划，定期做备份恢复测试并记录

研究者 / 临床试验机构：

☐ 确认能直接访问本中心受试者的原始电子记录和稽查轨迹（含外部数据），不行就向申办方提出

☐ 明确数据签署的责任人和授权流程， 按方案节点及时签署，不要攒到锁库前

☐ 数据更正只由研究者或其授权代表执行，原因记录具体、可追溯

☐ 落实法定期限内数据独立副本（核证副本）的保存方式

供应商：

☐ 验证文档准备好接受申办方评估和监管检查，别再用「商业机密」挡

☐ 确认系统功能：完整稽查轨迹（含操作原因）、阶段性签署、权限最小化配置、审计轨迹导出为动态文件、多因素认证

∞

EPILOGUE

写在最后

这份指导原则真正传递的信号是：临床试验数据和 GMP 数据，在监管眼里已经是 同一套数据可靠性标准 。过去靠「GCP 没细说」来回避验证、回避稽查轨迹审核、共享账户凑合用的空间，正在快速收窄。

对从业者来说，GMP 侧 CSV 和数据完整性的那套方法论——风险评估、URS、配置验证、审计追踪审核、生命周期管理——现在可以 原封不动地搬来临床侧用了 。