4. ETL需求分析与数据映射
临床数据ETL项目失败，很少是因为程序员不会写SQL，而是因为没人把“方案里写的”和“数据库里存的”对齐。方案说“筛选期第1天”，EDC里可能叫 SV1DAT；方案说“不良事件严重程度”，CRF上可能是下拉框 AESEV，取值 1/2/3，而SDTM要求 AESEV 存 MILD/MODERATE/SEVERE。需求分析与数据映射，就是把这些“人话”翻译成“机器可执行规则”的过程。
一、需求分析：从方案到变量清单
需求分析的输入是研究方案、CRF（或eCRF注释）、CDASH/SDTM/ADaM标准、以及数据管理计划（DMP）。输出是一份可追溯的变量清单，至少包含：变量名、标签、类型、长度、来源（CRF字段/派生/外部）、目标标准域、是否必填、受控术语（CT）。
实际操作中，建议按“域”组织需求。以人口学（DM）为例，方案要求收集年龄、性别、种族、出生日期。对应到SDTM IG，DM域必须包含 USUBJID、SUBJID、RFSTDTC、RFENDTC、SITEID、BRTHDTC、AGE、AGEU、SEX、RACE、ETHNIC、COUNTRY。其中 AGE 通常由 RFSTDTC 与 BRTHDTC 派生，AGEU 固定为 YEARS。这些规则必须在需求阶段就写清楚，而不是等到编程时“看着办”。
需求分析还要识别“方案未明说但标准强制”的变量。例如SDTM要求每个受试者必须有唯一的 USUBJID，格式通常为 STUDYID-SITEID-SUBJID。如果EDC只采集了 SUBJID，就需要在ETL中拼接。这类“隐性需求”是映射文档中最容易遗漏、也最容易在锁库前引发返工的部分。
二、数据映射：源字段到目标标准字段
映射的核心是“一对一、一对多、多对一、派生、常量、条件映射”六类关系。以不良事件（AE）域为例：
- 一对一：CRF的
AETERM直接映射到SDTM的AETERM。 - 常量：
AEDECOD由MedDRA编码后写入，AEBODSYS同理。 - 条件映射：CRF的
AESER（是否严重）为“是”时，AESER映射为Y；为“否”时映射为N。 - 派生：
AESTDTC由AE开始日期与时间组合，若时间缺失则按--STDTC规则补T00:00或保留部分日期。 - 多对一：CRF中“严重程度”与“是否严重”两个字段共同决定
AESEV与AESER的取值逻辑。
映射规则必须写成“可执行”的表达式，而不是自然语言描述。例如：
目标字段: AESEV
源字段: AETOXGR (CTCAE grade 1-5)
规则:
IF AETOXGR = 1 THEN AESEV = "MILD"
IF AETOXGR = 2 THEN AESEV = "MODERATE"
IF AETOXGR = 3 THEN AESEV = "SEVERE"
IF AETOXGR IN (4,5) THEN AESEV = "LIFE THREATENING"
ELSE AESEV = "MISSING"
对于日期类字段，要明确“部分日期”的处理策略。例如 BRTHDTC 只采集到年份“1980”，SDTM允许存为 1980，但 AGE 派生时需按 RFSTDTC 年份减 BRTHDTC 年份计算，并标注“年龄基于年份估算”。这类规则必须在映射文档中显式声明，否则不同程序员会写出不同结果。
三、映射文档的编写与版本管理
映射文档（Mapping Specification）是ETL的“施工图”。一份可用的映射文档通常包含：源系统、源表/字段、目标域、目标变量、类型、长度、CT、转换规则、派生逻辑、负责人、版本号、变更记录。建议用Excel或CSV维护，便于与SAS/Python程序做自动化比对。
版本管理的关键是“可追溯”。每次方案修订、CRF改版、标准升级，都必须产生新的映射文档版本，并记录：变更日期、变更人、变更原因、影响范围（哪些域、哪些变量、哪些程序）。推荐使用语义化版本：v1.0 为初始锁库版本，v1.1 为方案修订后的补丁，v2.0 为SDTM IG版本升级导致的结构性变更。
四、从映射到可执行ETL：一个最小闭环
以AE域为例，完整链路是：CRF字段 → 映射规则 → SDTM变量 → 程序实现 → 验证。验证时至少检查三点：① 变量是否存在于目标域；② 取值是否符合CT；③ 派生逻辑是否与映射文档一致。例如 AESEV 的CT为 MILD/MODERATE/SEVERE/LIFE THREATENING，若程序输出 1/2/3，则映射失败。
下面这张图展示了从方案到SDTM的映射链路与版本控制点，重点表达“源字段—规则—目标字段—验证”的数据流关系，以及版本变更如何影响下游程序。
最后强调一点：映射文档不是“写完就归档”的文档，而是贯穿建库、编程、验证、锁库、归档的活文档。每一次方案修订、每一次CRF改版、每一次标准升级，都要回到映射文档中更新规则、升版本、记变更。只有把“方案—变量—规则—程序—验证”这条链路管住，ETL的质量才有可追溯的根基。