易迪希 Clinflash EDC 电子数据采集系统

🎯 产品定位与核心价值

EDC 定位为临床研究的数据采集底座：以 eCRF 建库为起点，把录入、核查、质疑与导出串成标准流程，让数据质量问题在产生环节被发现，而不是留到锁库前集中清理。

⚙️ 工作原理与运行机制

电子数据采集系统容易被理解成“把纸质 CRF 换成网页表单”。如果只是这样，它没必要遵循 21 CFR Part 11，也不必支持 CDISC ODM。EDC 真正处理的是三件事：录入的数据能不能被质疑、质疑能不能闭环、闭环后的数据能不能直接进统计。

建库：为什么强调 CDASH

CRF 设计决定后续所有工作量。按 CDASH 标准建库，字段命名与结构对齐行业惯例，统计分析计划落地时不必再做一次字段映射；项目之间也能复用标准库。反之，每个项目自造一套字段，转换成本会在锁库前集中爆发。Clinflash EDC 支持 eCRF 动态控制与自定义标准库，本质是把建库从“画表单”变成“配置标准”。

核查：跨页面与跨访视才是难点

单字段的范围校验任何工具都能做。真正吃人力的是跨访视一致性——比如基线收缩压与随访收缩压的突变、合并用药开始日期早于首次给药日期。这类规则要在访视之间建立引用关系，且规则变更后能对存量数据重跑。系统支持跨页面、跨访视核查，把这类判断从人工翻页变成规则执行。

溯源：动态 SDV 把监查资源放在该放的地方

100% SDV 在大型 III 期里既不经济也不必要。DSDV 允许按字段、页面、访视、受试者四个层面设定规则，再通过随机分层决定需要溯源的样本。结果是监查员的时间集中到高风险数据上，而不是平均分配给每一行。

导出：能被统计直接接走才算完成

锁库不是终点，数据要能进 SAS。系统支持 ODM V1.3 原始数据导出、Unicode SAS、SAS XML 与 Excel 导出，遵循 CDISC ODM 模型意味着导出结构可预期。若导出还要人工整理列名，前面省下的时间会在这里还回去。

🏗️ 架构分层与数据流向

把 EDC 拆成五层看，更容易判断一个系统能撑多大的项目。自下而上是：数据模型层、录入与核查层、质疑与编码层、导出与集成层、运维与合规层。

数据模型层：eCRF 与标准库

这一层定义“采什么”。包括表单结构、字段类型、访视与时间窗、动态控制逻辑。标准库决定复用程度：有标准库的项目，建库周期以天计；没有标准库的项目，每个字段都要重新讨论。

录入与核查层：多端录入 + 规则引擎

录入端覆盖试验、中心、受试者三个层级，兼容移动设备且无需安装 APP，这对床旁录入与受试者自填场景是硬要求。核查引擎负责在保存与冻结两个时点执行规则，规则可按项目版本管理。

质疑与编码层：独立质疑中心

质疑不是附在字段旁的备注，而是独立对象：有发起人、责任人、时限、状态。独立质疑中心的价值在于可以按中心、按访视、按字段统计未关闭质疑，这是项目会上真正被追问的数字。医学编码模块与 Coder 打通，AE 与合并用药可直接进入标准词典。

导出与集成层：ODM 与外部系统

对外提供 ODM 与多种 SAS 格式导出；对内与 IRT、RTSM、CTMS 集成，避免受试者编号、随机号、访视计划在多套系统里各存一份。集成做得好，锁库前的对账工作量会显著下降。

运维与合规层：等保与容灾

系统通过公安部三级等保并配置实时异地容灾备份，这部分平时看不见，但在核查与数据泄露事件中是底线。合规层还包括稽查轨迹、权限矩阵与电子签名挂接。

⭐ 核心能力详解

📋 技术规格

📊 规格参数横向对比

选 EDC 时常被拿来横向比较的有四种做法：纸质 CRF 加双人录入、通用在线表单工具、自研采集系统、专业 EDC。四者在成本结构与风险点上完全不同，用一张表对比比逐项问功能更有效。

选择的关键不在功能数量，而在“锁库前的返工量”。纸质与通用表单省下的是采购环节，付出的是数据清理；自研省下的是许可费，付出的是验证与维护。III 期注册研究还应额外确认系统是否有同类项目经验——核查现场被问到系统验证文档时，这一项无法临时补。

🎯 典型应用场景

🏬 典型场景深描

EDC 的适配度取决于研究类型，而不是企业规模。以下四类场景对系统的要求差别明显，可对照自身项目判断。

疫苗 III 期国际多中心

这类研究的特征是中心多、访视密、受试者量大，且数据要同时满足国内与海外监管。系统需要多语言界面、按国家配置访视时间窗、支持 MRCT 的数据结构。易迪希公开资料显示其 EDC 参与过新冠疫苗 III 期 MRCT 项目并支持紧急使用申请，这类经验的价值在于知道各国核查关注点差异。

肿瘤药注册申报

肿瘤研究的难点在疗效终点判定与影像数据的关联。RECIST 评估要按访视留痕，PFS 事件日期要与影像、用药、死亡信息交叉核对。系统需要支持复杂访视结构与派生变量，且锁库后仍能追溯每一次判定变更。

医疗器械与 IVD 研究

器械研究样本量通常不大，但随访周期长、终点事件少，对数据完整性的要求反而更高。此类项目更适合轻量建库 + 强提醒机制，避免因单个受试者失访导致整体效力不足。

上市后真实世界研究

真实世界数据来源杂、字段不齐，往往需要与医院 HIS、随访平台对接。此时 EDC 的角色从“主采集工具”变成“结构化归集工具”，集成能力比建库速度更重要。

📦 接入方式

⚔️ 产品差异化特点

• 面向复杂研究设计对多访视、多中心与动态逻辑的支持较完整。
• 核查前置把质量问题拦在录入环节，减少后期清理成本。
• 可配置溯源溯源范围按规则设定，兼顾质量与工作量。
• 生态衔接与随机化、文档与安全报告系统形成组合。

✅ 使用最佳实践

🧩 选购与适配建议

EDC 采购容易陷入比功能清单的循环。以下五项按“会不会导致项目失败”排序，前两项不满足时，后续功能再全也难补救。

• 一看法规与验证文档是否齐备。21 CFR Part 11 符合性、GAMP5 验证材料、稽查轨迹完整性，这三样在核查现场会被直接索要。要提前确认能否提供系统验证报告与变更记录，而不是上线后再补。
• 二看核查引擎的表达能力。让对方用你手上真实项目的一条跨访视规则现场配置，观察是否需要开发介入。规则只能由厂商写，意味着每次方案修订都要排期。
• 三看导出是否直通统计。要求提供一份 ODM 与 SAS 导出样例，让统计师判断能否直接使用。这一步能过滤掉大量“看起来能用”的系统。
• 四看质疑管理的颗粒度。能否按中心、按访视、按字段统计未关闭质疑，决定了项目例会能不能开出有效结论。
• 五看集成与迁移。是否需要与 IRT、CTMS、eTMF 打通；历史项目数据能否迁移进新系统。迁移方案不清晰的，往往在第二个项目才暴露问题。

两类情况建议先不上 EDC

一是样本量极小、单中心的探索性研究，用规范的表单加双人核对即可，上系统反而增加验证负担。二是数据管理团队尚未建立标准操作流程的机构——系统会把流程缺失放大成质疑堆积，建议先理顺建库与锁库的 SOP。

🚀 实施与上线路径

EDC 上线不是装完就能用，真正的周期从建库开始。按五个阶段推进，每个阶段都有明确交付物，可以避免“上线即返工”。

阶段一：方案拆解与建库（约 2–4 周）

把方案中的入排标准、访视计划、疗效与安全性终点翻译成字段清单，再映射到 CDASH 标准库。交付物是 eCRF 规格说明与字段字典。此阶段最容易被压缩，但压缩的代价会在测试阶段成倍出现。

阶段二：规则配置与内部测试

配置逻辑核查、派生变量、动态 SDV 规则，然后用构造数据跑一轮完整流程：录入、触发质疑、回复、关闭、冻结。交付物是测试用例与问题清单。建议至少覆盖三类边界：日期跨访视、剂量调整、缺失值处理。

阶段三：中心培训与首例入组

培训重点不是界面操作，而是“什么情况该发质疑”。首例入组建议安排数据管理员同步盯场，把首周的问题集中解决，避免同类错误扩散到全部中心。

阶段四：中期清理

按中心输出质疑清单与 SDV 完成率，识别录入质量偏低的中心并针对性复训。此阶段要开始准备锁库清单：哪些字段必须 100% 核查、哪些可以抽样。

阶段五：锁库与归档

锁库前完成全部质疑关闭、编码确认、导出验证。锁库后数据不可修改，任何变更走解锁流程并留痕。交付物是锁库报告、导出数据集与稽查轨迹归档。

❓ 常见问题扩展

以下是采购与实施阶段最常被问到的十个问题，答案基于系统公开能力与临床数据管理的通行做法。

❓ 常见问题

📜 信息来源与免责声明