1. 真实世界研究队列构建工程导论
真实世界研究（Real-World Study, RWS）的核心资产不是某一次统计分析的结论，而是可复用、可追溯、可审计的队列数据集。本课程把"建队列"从一项依赖个人经验的数据处理工作，提升为一门有明确输入、明确工序、明确交付标准的工程学科。本章回答四个问题：这门课定位在哪里、工程对象是什么、学习路径如何组织、交付物达到什么标准才算合格。
一、课程定位：从"跑一次分析"到"建一条产线"
传统的数据分析模式是项目制的：拿到一份数据，写一段脚本，跑出一个结果，交付一份报告。这种模式在真实世界研究中会迅速失效，原因有三：数据源会持续更新（医院HIS每月新增就诊记录）、研究方案会修订（入排标准调整、随访窗口变化）、监管与期刊要求结果可复现（同一份数据、同一套代码，换个人跑必须得到同样的队列）。
因此本课程的定位是工程化：把队列构建拆解为可独立开发、可单元测试、可版本管理的模块，用软件工程的纪律约束流行病学设计的实现过程。学完本课程，你应当能够独立完成一条从原始数据到分析就绪队列（Analysis-Ready Cohort）的完整产线，并让第三方仅凭你的代码仓库和文档就能重建这条队列。
二、核心工程对象：队列构建的五类实体
整门课程围绕五类工程对象展开，它们之间存在明确的依赖与数据流关系。下图给出这五类对象及其在产线中的位置：源数据层提供原始表，映射层把源字段翻译为标准概念，队列层执行入排与索引日期确定，变量层派生暴露、结局与协变量，交付层产出可分析数据集与配套文档。
这五类对象不是五个独立步骤，而是五层可独立验证的工程制品。每一层都必须有明确的输入契约、输出契约和验证规则。例如映射层输出"标准概念表"时，必须附带映射覆盖率报告：源数据中95%以上的诊断编码应能映射到标准概念，未映射的5%需要逐条说明原因（编码缺失、本地扩展码、历史遗留码）。
三、学习路径：从单表处理到全链路交付
课程按"数据加工深度"和"工程复杂度"两条轴线推进，共30章，分为五个阶段：
- 阶段一（第1～6章）：基础与源数据理解。建立工程思维，掌握真实世界数据的典型结构（纵向就诊记录、宽表检验、长表用药），学会用SQL和Python做数据剖析（Profiling），识别缺失、重复、时间逻辑错误。
- 阶段二（第7～14章）：概念映射与标准化。把ICD、ATC、LOINC等编码体系映射到统一概念集，处理一对多映射、历史版本差异、本地扩展码，建立可维护的映射字典。
- 阶段三（第15～21章）：队列定义与索引日期。实现入排标准、确定索引日期、划分基线期与随访期，处理"首次诊断""连续用药""洗脱期"等流行病学操作化定义。
- 阶段四（第22～27章）：变量派生与质控。派生暴露、结局、协变量，处理时间依赖暴露与竞争风险，建立自动化质控规则（范围检查、逻辑一致性、时间顺序）。
- 阶段五（第28～30章）：交付与复现。打包分析就绪数据集、编写数据字典、建立代码仓库与版本管理、完成可复现性验证。
每个阶段都要求你产出一个可运行的代码模块，而不是一份笔记。课程不设"纯理论章"，所有章节都围绕一个可执行任务展开。
四、交付物标准：什么算"合格"
本课程对交付物的要求可以概括为四个维度：可运行、可追溯、可复现、可审计。具体到一条队列的最终交付，至少包含以下内容：
| 交付物 | 核心内容 | 合格标准（示例） |
|---|---|---|
| 分析就绪数据集 | 一行一患者（或一行一患者-时间段），含索引日期、暴露、结局、协变量 | 字段类型明确、无重复主键、时间逻辑自洽 |
| 数据字典 | 每个变量的名称、类型、来源、派生逻辑、缺失率、取值范围 | 第三方可据此理解每个字段的含义与生成方式 |
| 代码仓库 | 按层组织的SQL/Python脚本，含配置文件与运行入口 | 从原始数据到最终数据集可一键运行（或按文档顺序运行） |
| 质控报告 | 各层记录数变化、排除原因分布、缺失率、异常值清单 | 每一步的人数变化可解释，排除原因可追溯到具体标准 |
| 映射字典 | 源编码→标准概念的映射表，含未映射清单与处理说明 | 映射覆盖率≥95%，未映射项有明确处置记录 |
五、一个最小示例：从原始表到队列的轮廓
为了让后续章节有统一的参照，这里给出一个贯穿课程的示例场景（数据为合理假设，非实测）：某三甲医院HIS中提取2020年1月至2023年12月的2型糖尿病患者就诊记录，研究目标是"二甲双胍单药治疗与联合磺脲类治疗对心血管结局的影响"。
源数据包含三张核心表：patient（患者ID、出生日期、性别）、visit（就诊ID、患者ID、就诊日期、诊断编码）、prescription（处方ID、患者ID、开药日期、药品编码、剂量、天数）。队列构建的关键操作包括：用诊断编码筛选2型糖尿病患者、确定首次诊断日期为索引日期、要求索引日期前连续参保≥180天、排除索引日期前已有心血管事件的患者、从处方表派生暴露分组、从随访期就诊记录派生心血管结局。最终输出一张含约1200名患者、每行一名患者的分析数据集。
这个示例会在后续章节中逐步展开：第3章剖析这三张表的实际结构，第8章处理诊断编码映射，第16章实现入排标准，第23章派生暴露与结局，第29章完成交付打包。你现在不需要记住所有细节，只需要建立一条认知：队列构建的每一个环节，都可以被拆解、被验证、被复用。
六、开始之前：你需要准备什么
本课程假设你具备基础的SQL查询能力（SELECT、JOIN、GROUP BY、窗口函数）和Python数据处理经验（pandas或polars）。如果你对流行病学的基本概念（队列研究、暴露、结局、混杂、随访）还不熟悉，建议先补充相关背景知识，否则你会知道"怎么做"，但不知道"为什么这样做"。
工具方面，课程示例使用PostgreSQL作为数据仓库、Python 3.10+作为派生语言、Git作为版本管理工具。你可以用其他等价工具替代，但建议至少保持"数据库+脚本语言+版本管理"这三件套，因为它们是工程化队列构建的最小工具集。
最后一件事：本课程强调"可复现"，这意味着你需要养成一个习惯——任何手动操作都必须记录，任何临时修改都必须回写到代码。在真实世界研究中，最危险的往往不是技术难题，而是"我上次在数据库里直接改了一行，但忘了记下来"。