2. 临床试验数据流与清理触发点

临床试验的数据清理不是数据库锁定前才启动的“收尾工作”，而是贯穿数据从产生到定稿全过程的持续活动。要理解质疑（Query）从哪里来、什么时候该发、发给谁，必须先看清数据在系统之间的流动路径，以及每个阶段会引入哪类“脏数据”。本节以一张典型的多中心Ⅱ期试验为例，梳理从CRF设计到数据库锁定的完整数据流，并标出各阶段的清理需求与质疑产生节点。

一、数据流的四个阶段与责任边界

临床数据从受试者访视开始，到进入分析数据库为止，大致经过四个阶段：CRF设计与建库、中心录入与本地核查、外部数据对接与整合、集中清理与数据库锁定。每个阶段的数据形态不同，清理动作和质疑来源也不同。

在CRF设计阶段，数据以“字段+逻辑规则”的形式被定义。此时清理需求体现为预防性设计：把可预判的错误挡在录入之前。例如，受试者年龄字段设定为18～75的整数范围，若录入80则系统直接拒绝；访视日期设定不得早于知情同意日期，若违反则触发即时提示。这一阶段的质疑不是发给研究者的，而是发给建库人员的——通过测试用例验证规则是否按方案实现。

在中心录入阶段，数据以“已提交的CRF页面”形式存在。清理需求是及时性与完整性：访视后应在规定窗口内录入，缺失字段应被标记。此阶段的质疑主要来自系统自动核查（Edit Check），例如“收缩压记录为0”这类明显异常值，或“合并用药开始日期晚于访视日期”这类逻辑冲突。质疑直接发往研究者，要求核实或更正。

外部数据对接阶段，数据来自中心实验室、心电图核心实验室、药物发放系统等。这些数据以文件或接口形式批量导入，清理需求是一致性与可追溯性。典型问题是：中心实验室报告的受试者编号在EDC中不存在，或同一受试者的两次检测结果时间戳重叠。此阶段质疑往往发给数据管理员或实验室协调员，而非直接发给研究者。

集中清理与锁定阶段，数据已基本齐全，清理需求转向跨字段、跨访视、跨数据源的系统性核查。例如，不良事件转归日期与访视日期矛盾、方案偏离未记录、SAE与AE记录不一致。此阶段质疑数量可能下降，但每一条都更关键，直接决定数据库能否锁定。

二、各阶段清理需求的具体落地

把上述框架落到操作层面，需要明确每个阶段“查什么、怎么查、谁来处理”。

CRF设计阶段的核心交付物是核查规则清单。以某降压药试验为例，规则可包括：坐位收缩压范围70～250 mmHg；若收缩压<90 mmHg且伴有头晕，需触发“是否记录为不良事件”的提示；访视日期与知情同意日期差值不得为负。这些规则在建库时写入EDC系统，并通过测试用例验证——测试用例应覆盖边界值、空值和逻辑冲突场景，例如输入“89”和“90”分别观察是否触发不同分支。

录入阶段的清理重点是及时响应系统质疑。系统质疑通常分为“硬核查”和“软核查”：硬核查阻止保存，如受试者编号格式错误；软核查允许保存但标记质疑，如“体重较上次访视增加超过10%”。研究者对软核查的回复有三种：确认数据正确、更正数据、或说明原因（如“受试者近期饮食变化”）。数据管理员需定期查看未关闭质疑列表，对超过7天未回复的质疑进行催办。

外部数据对接阶段的关键是匹配与去重。中心实验室数据通常以受试者编号+访视点+检测项目为键。导入前应执行三项检查：编号是否在EDC受试者列表中、访视点是否与方案一致、检测日期是否落在对应访视窗口内。若中心实验室报告了EDC中不存在的编号，需先确认是否为筛选失败受试者或编号录入错误，再决定是补充建库还是退回实验室更正。

集中清理阶段应执行跨源一致性核查。典型场景包括：AE记录中“转归”为“痊愈”，但转归日期晚于数据库锁定日期；SAE报告中的发生日期与EDC中AE页面记录不一致；合并用药的适应症与AE记录不匹配。这类问题往往需要医学判断，质疑应同时发给研究者和医学经理，由双方确认后关闭。

三、质疑产生节点的判断依据

并非所有异常都需要发质疑。判断是否发起质疑，可依据三条标准：是否影响受试者安全、是否影响主要疗效指标、是否违反方案或法规要求。例如，一次访视的体温记录为“36.5”但单位误选为“℉”，虽然数值异常，但属于单位选择错误，应发质疑要求更正；而“收缩压160 mmHg”在高血压试验中可能是真实数据，不应仅因数值偏高就发质疑，除非方案规定该值需报告为AE。

质疑的优先级也需分级：影响安全性的质疑（如SAE漏报）应在24小时内发出；影响主要终点的质疑（如主要疗效指标缺失）应在3个工作日内发出；一般数据不一致可在定期数据审查会上集中处理。所有质疑的发起、回复、关闭均应在EDC系统中留痕，形成完整的稽查轨迹。

理解数据流与清理触发点，本质上是把“数据从哪来、经过谁的手、在哪个环节可能出错、出错后找谁”这条链路固化下来。下一阶段的工作，就是基于这条链路设计具体的质疑管理流程和时限标准。