1. OMOP CDM 与队列工程导论
OMOP CDM（Observational Medical Outcomes Partnership Common Data Model）是当前真实世界证据（RWE）研究中应用最广的通用数据模型之一。它的核心价值不在于“把数据存起来”，而在于把来自电子病历、医保理赔、检验系统、登记库等异构来源的数据，统一映射到一套标准化的表结构、标准词表与术语体系上，使不同机构、不同系统产生的数据能够被同一套分析代码读取。对队列构建而言，这意味着：一旦数据完成 ETL 与标准化，研究者就可以用相对稳定的 SQL 与工具链，从 PERSON、VISIT_OCCURRENCE、DRUG_EXPOSURE、CONDITION_OCCURRENCE、MEASUREMENT 等表中抽取目标人群，而不必为每个数据源重写一套抽取逻辑。
从演进脉络看，OMOP CDM 经历了从早期以理赔数据为主的 v4，到以 PERSON 为中心、引入 STANDARDIZED_ANALYTICAL 与 STANDARDIZED_HEALTH_SYSTEM 数据层的 v5.x，再到 v6 中强化 EPISODE、EPISODE_EVENT 等纵向病程表达能力的版本。版本差异直接影响队列工程：v5 中药物暴露通常以 DRUG_EXPOSURE 的起止日期表达，而 v6 的 EPISODE 可以把一次住院、一段用药或一个疾病阶段聚合为连续事件，便于做“治疗线”或“疾病阶段”分析。因此，在工程环境里必须先确认 CDM 版本，再决定队列逻辑的写法。
队列构建在 RWE 中的位置，可以理解为“从数据到证据”的中间层。原始数据经过 ETL 进入 CDM 后，仍然只是标准化的观测记录；只有通过队列定义，把“谁在什么时间、满足什么条件、进入哪个组、观察到什么结局”明确下来，才能形成可比较的分析集。一个典型的队列工程链路包括：确定研究问题与目标人群 → 选择索引日期（index date）→ 设定纳入/排除标准 → 从 CDM 表抽取事件 → 计算暴露、协变量与结局 → 形成分析队列。这个链路中，索引日期是最关键的锚点，它决定了“基线期”和“随访期”的切分方式。
下面这张图展示了一个最小可运行的队列工程数据流：从 CDM 核心表出发，经过索引事件、纳入排除、协变量与结局抽取，最终形成分析队列。图中同时标出了关键参数，例如索引日期、基线窗口、随访窗口和洗脱期，这些参数在后续章节会反复出现。
在工程环境与数据准备方面，课程使用一套可复现的本地环境：PostgreSQL 作为 CDM 存储，Python 负责 ETL 与队列逻辑编排，SQL 负责从 CDM 抽取。数据准备通常分三步：第一步，导入一份公开的 OMOP 示例数据集（例如 Synthea 生成的合成数据或 MIMIC-IV 的 OMOP 映射版本），确认 PERSON 表中有可用的 person_id、year_of_birth、gender_concept_id；第二步，检查 OBSERVATION_PERIOD 表，确保每位患者有连续的观察区间，否则后续洗脱期与随访期无法计算；第三步，核对标准词表 CONCEPT 与 CONCEPT_RELATIONSHIP，确认目标诊断或药物有对应的标准 concept_id。
一个常见的实操判断是：如果 OBSERVATION_PERIOD 中某患者的观察起点晚于索引日期，那么该患者不应进入队列，因为基线期不完整。类似地，如果 DRUG_EXPOSURE 中药物起始日期缺失，通常需要根据 drug_exposure_start_date 与 days_supply 推算结束日期，或直接排除该记录。这些判断在后续章节会以 SQL 和 Python 代码形式展开。
PERSON 行数、OBSERVATION_PERIOD 覆盖人数、目标 concept_id 在 CONDITION_OCCURRENCE 或 DRUG_EXPOSURE 中的出现频次。若目标事件频次过低（例如少于 100 人），需要重新评估研究问题或数据源是否合适。最后需要明确队列工程与统计分析的边界：队列工程负责“把正确的人、在正确的时间、以正确的分组方式组织成分析集”，而统计模型负责“在分析集上估计效应”。两者之间的接口是一张结构化的队列表，通常包含 subject_id、cohort_start_date、cohort_end_date、cohort_definition_id 等字段。只要这张表稳定、可复现，后续的倾向性评分、生存分析或负对照分析就可以在同一套数据上反复运行。这也是 OMOP CDM 在 RWE 中成为基础设施的根本原因。