2. 临床表型定义与数据字典构建

在多组学临床表型建模中，最容易被低估、却最决定成败的环节，不是模型结构，而是“表型到底怎么定义”。同一份电子病历，如果结局变量定义不同、时间窗口不同、编码版本不同，最终训练出的模型可能给出完全相反的结论。本节围绕四件事展开：表型标准化（ICD、HPO、LOINC）、结局变量定义、时间窗口设定，以及数据字典与元数据管理。

一、三类标准术语各管什么

临床表型标准化不是把数据“翻译成统一编码”这么简单，而是为不同来源、不同粒度的信息找到可对齐的语义锚点。三类术语体系分工明确：

• ICD（国际疾病分类）：面向诊断与计费，粒度较粗，适合定义“患者是否患有某疾病”这类结局或合并症。注意 ICD-9、ICD-10、ICD-11 之间并非一一映射，跨版本合并必须先做映射表。
• HPO（人类表型本体）：面向临床异常表型，如“肌张力低下”“指（趾）过长”，粒度细、层级化，适合遗传病、罕见病表型建模，可与基因、变异关联。
• LOINC（观测指标标识符逻辑命名与编码）：面向检验与观测，回答“测的是什么、以什么方法、什么单位”，适合把不同医院的化验项目对齐到同一语义。

实践中常见做法是：用 ICD 定义疾病结局，用 HPO 描述精细表型，用 LOINC 对齐实验室指标，三者通过患者 ID 与时间戳串联成一张“表型—检验—诊断”关系网。

二、结局变量定义：从概念到可计算

结局变量必须写成“可被 SQL 或脚本执行”的形式，而不是一句临床描述。一个完整的结局定义至少包含：目标概念、编码集合、纳入条件、排除条件、时间锚点、事件判定规则。例如定义“2 型糖尿病新发”结局：

结局名称: T2DM_incident
编码集合: ICD-10 E11.* 或 ICD-9 250.x0/250.x2
纳入条件: 首次出现上述编码的住院或门诊记录
排除条件: 基线前已有 E11.* 记录（ prevalent 病例）
时间锚点: 基线日期 = 首次入组/首次采样日期
事件判定: 基线后 ≥ 30 天首次出现编码，且随访 ≥ 180 天

这里“基线后 ≥ 30 天”是为了排除“入院即确诊”的共病干扰，属于典型的洗脱期（washout）设计。洗脱期长度需根据疾病自然史设定，不能随意取 30 天。

三、时间窗口：表型的时间语义

多组学数据的时间戳往往不同步：基因组是静态的，转录组是采样时刻的，检验是某天的，诊断是某次就诊的。因此必须为每个变量定义时间窗口，常见三类：

• 点窗口：如“基线当天”的 LOINC 检验值，允许 ±1 天容差。
• 区间窗口：如“基线前 90 天内”的用药记录，用于构建合并症或暴露。
• 随访窗口：如“基线后 365 天内”是否发生结局事件，用于生存分析或二分类结局。

时间窗口的方向必须全文统一：本文约定“基线前”为负向、“基线后”为正向，所有窗口均以基线日期为原点。若某变量在窗口内有多条记录，需明确聚合规则——取最近一次、取均值、取最差值，还是取首次。不同聚合规则会显著改变特征分布，必须在数据字典中写明。

四、数据字典与元数据管理

数据字典是表型定义的“唯一事实来源”。它不应只是字段名列表，而应记录每个变量的语义、来源、编码、单位、时间窗口、缺失处理、聚合规则、版本。推荐字段如下：

元数据管理的关键是版本化与可追溯：每次修改编码集合、时间窗口或聚合规则，都应生成新版本并记录变更原因。否则当模型效果波动时，无法判断是数据变了还是定义变了。

五、从定义到可执行：一张关系图

下图把本节核心对象串起来：左侧是三类标准术语，中间是结局变量与时间窗口的判定逻辑，右侧是数据字典与元数据管理，底部是最终可执行的表型定义。图中标注了关键参数与方向约定，便于对照正文理解。

这张图的核心信息是：标准术语提供语义锚点，结局定义与时间窗口提供计算规则，数据字典提供版本化记录，三者共同产出可执行的表型定义。任何一环缺失，都会导致模型结果不可复现或不可解释。

完成本节工作后，应能交付一份包含变量名、标准编码、时间窗口、聚合规则、缺失策略和版本号的数据字典，以及对应的可执行结局定义脚本。这是后续特征工程与多组学融合建模的输入基础。