3. 临床证据数据工程的需求分析与方案设计

数字疗法（DTx）的临床证据数据工程，起点不是数据库，也不是统计软件，而是一个可被数据回答的研究问题。需求分析的本质，是把“我们想证明什么”翻译成“需要采集哪些变量、在什么时间点、以什么精度、受哪些约束”。方案设计则是把这份数据需求落到可执行的数据流、技术组件与合规边界上。本节围绕一条主线展开：研究问题 → 数据需求 → 证据链映射 → 数据流图 → 技术选型 → 合规约束。

一、从研究问题到可计算的数据需求

研究问题必须包含四个可操作要素：目标人群（P）、干预与对照（I/C）、结局指标（O）、时间框架（T）。以一款用于成人失眠的认知行为数字疗法（DTx-CBT-I）为例，假设研究问题为：“与常规睡眠卫生教育相比，DTx-CBT-I 能否在 8 周内使成人慢性失眠患者的失眠严重指数（ISI）较基线下降 ≥7 分？” 这里的 P 是符合 ICSD-3 慢性失眠诊断的成人，I 是 DTx-CBT-I，C 是睡眠卫生教育，O 是 ISI 变化量，T 是 8 周。

把这个问题拆成数据需求，需要逐项回答：

• 入排变量：年龄、ICSD-3 诊断结论、ISI 基线分值、既往 CBT-I 暴露史、合并精神障碍筛查（PHQ-9、GAD-7）。
• 干预暴露变量：模块完成数、每次会话时长、睡眠日记提交次数、治疗师消息交互次数。这些是数字疗法特有的“剂量”变量，必须与临床结局同步采集。
• 结局变量：ISI 总分（主要）、睡眠日记中的入睡潜伏期（SOL）、总睡眠时间（TST）、睡眠效率（SE）、以及不良事件记录。
• 时间点：基线、第 2、4、8 周，以及随访第 12 周。每个时间点对应一个评估窗口，窗口宽度需在方案中预先定义，例如 ±3 天。

这里的关键判断是：不是所有可采集的数据都值得采集。每增加一个变量，就增加一次数据清洗、一次缺失处理、一次合规审查。需求分析阶段应明确“主要结局、次要结局、探索性指标、安全性指标”四类优先级，并给出每个变量的采集频率、来源系统与责任人。

二、证据链映射：从原始信号到结论

证据链映射要回答的是：一条结论，究竟由哪些数据、经过哪些处理步骤支撑。以 ISI 下降 ≥7 分为例，证据链可以拆成四层：

1. 原始层：受试者在 App 内填写的 ISI 量表条目（7 个条目，0–4 分），带时间戳与设备标识。
2. 派生层：条目求和得到 ISI 总分；基线总分与第 8 周总分相减得到变化量。
3. 分析层：按意向性治疗（ITT）人群进行主要分析，缺失值采用多重插补；同时给出符合方案集（PP）的敏感性分析。
4. 结论层：组间变化量差异及 95% 置信区间，判断是否达到预设的临床意义阈值。

映射的价值在于暴露“断链”。例如，如果 App 只记录了总分而没有记录条目级数据，就无法做内部一致性检验，也无法在条目缺失时进行合理插补。因此，数据需求必须细化到条目级，而不是只到量表总分。

三、数据流图：从采集到分析的可追溯路径

数据流图应体现数据的来源、转换、存储与出口。下面这张图给出一个可落地的数据流结构，覆盖受试者端、研究团队端与分析端，并标注了关键合规控制点。

图中最值得注意的是“合规与质量约束层”横跨全链路。它不是某个单独模块，而是对每一段数据流的约束条件。例如，受试者端采集的每一条 ISI 记录，都必须绑定知情同意的版本号；研究数据库中的任何修改，都必须留下稽查轨迹；分析环境只能接触锁定后的数据集，且分析脚本需版本化。

四、技术选型：按数据特征与监管要求匹配

技术选型不是追求最新，而是匹配数据特征与监管要求。以下给出几个关键决策点及示例判断：

决策点	可选方案	示例判断依据
电子数据采集（EDC）	专用 EDC 系统 vs 通用表单工具	若需满足 21 CFR Part 11 稽查轨迹与电子签名，优先专用 EDC；若仅为内部探索性研究，可先用通用工具并明确局限。
数据存储	关系型数据库 vs 文档数据库	ISI 条目级数据高度结构化，关系型更利于约束与查询；睡眠日记中的自由文本备注可另存为文档字段。
分析环境	本地 SAS vs 云端 R/Python	若递交监管，需确保分析脚本可重复、环境可锁定；云端需额外评估数据出境与访问审计。
身份与访问	统一身份认证 + 角色权限	研究者、数据管理员、统计师、监查员权限分离，最小必要授权。

选型时还要考虑“数据量—复杂度—合规等级”三者的平衡。一个 200 例、8 周、以量表为主的研究，不需要引入实时流处理；但若 DTx 包含连续被动传感数据（如活动记录），则需评估时序数据库与降采样策略。

五、合规约束：把法规要求翻译成工程规则

合规约束必须在方案设计阶段就转化为可执行的工程规则，而不是等到递交前再补。常见约束包括：

• 知情同意：同意书版本号必须与数据记录绑定；受试者撤回同意时，需明确哪些数据必须保留（如安全性数据）、哪些必须删除。
• 数据最小化：只采集与研究问题直接相关的变量。例如，若研究不涉及地理位置分析，就不应采集精确 GPS。
• 可追溯性：任何数据修改不可覆盖原值，只可追加变更记录，并记录修改人、时间、原因。
• 数据保留与销毁：明确保留期限（如研究结束后 5 年），到期后按策略销毁或匿名化。
• 跨境传输：若使用境外云服务，需评估当地法律与数据出境要求，必要时采用本地化部署。

六、可执行的需求分析检查清单

以下清单可直接用于方案评审，逐项确认后再进入开发或配置阶段：

1. 研究问题是否包含 P/I/C/O/T 五要素？主要结局是否唯一且可计算？
2. 每个变量是否有明确的来源系统、采集频率、数据类型与允许范围？
3. 证据链是否从原始条目贯通到结论层？是否存在无法追溯的派生变量？
4. 数据流图中是否标注了加密、去标识化、审计日志与权限控制点？
5. 技术选型是否给出至少两个备选方案及选择理由？是否评估了合规等级？
6. 缺失值处理、离群值判定、分析人群定义是否在方案中预先声明？
7. 知情同意版本、数据保留期限、销毁策略是否已转化为系统规则？

需求分析与方案设计的产出，不是一份静态文档，而是一组可验证的约束：数据需求定义了“采什么”，证据链映射定义了“怎么连”，数据流图定义了“怎么走”，技术选型定义了“用什么”，合规约束定义了“边界在哪”。这五者对齐之后，后续的数据采集、清洗与分析才有稳定的基础。