信息速览
INFOBOX — CLIF 一屏速览
维度 内容 本质 开源重症监护数据标准（格式）+ 联邦研究联盟——不是单一数据集；产出 = schema + mCIDE 词表 + ETL 工具 + 联邦分析代码 全称 Common Longitudinal ICU data Format（论文展开式：“A Common Longitudinal Intensive Care Unit data Format”） 团队 CLIF Consortium（2023-07 成立）；UChicago 牵头，联席主席 Nicholas Ingraham（Minnesota）/ Catherine Gao（Northwestern） 论文 Intensive Care Med. 2025;51(3):556-569，doi:10.1007/s00134-025-07848-7，PMID 40080116（另有更正函 doi:…07869-2） 规模（官网 2026-09） 939,328 患者 / 67 医院 / 13 机构（“16 Sites、13 Active Sites”） 规模（论文） 111,440 例 ICU 入院 / 9 health systems / 39 hospitals（2020-2021 队列） schema 关系型 23 表（论文 v1.0 ERD）；encounter-centric，以 patient_id/hospitalization_id 关联 标注机制 mCIDE（最小通用 ICU 数据元素， _category）+ 源 EHR 原始标签（_name）双列并存核心范式 联邦分析：代码分发到站点本地跑，患者级数据永不出院，仅聚合结果共享 许可 标准本体 Apache-2.0（GitHub 公开）；站点数据不公开；MIMIC-IV-Ext-CLIF 走 PhysioNet 凭证访问 公开参考实现 MIMIC-IV-Ext-CLIF：MIMIC-IV v3.1 转为 14 张 CLIF 表（Parquet），PhysioNet v1.1.0，doi:10.13026/j481-g420 版本链 CLIF 2.0.0（论文）→ 2.1.0（当前数据字典）→ 3.0（2026-07，Going Multimodal）；mCIDE v3.0 投票中 库内互链 MIMIC-IV（rid 4/592，上游来源）、eICU-CRD（rid 552，多中心对照范式）、HiRID（rid 7）、NWICU（rid 146）
CLIF 要解决的问题，一句话就能讲清：世界上最好的 ICU 数据（MIMIC）只有一家医院，而重症医学的结论需要很多家医院。想凑多家医院的数据，传统做法是把各自的患者数据搬到一个地方，于是要签一堆数据使用协议（DUA），还要为每家的数据格式差异重写一遍清洗代码。CLIF 的答案是换一条路——不搬数据，搬代码：联盟各站点把本地 EHR 按同一套"通用纵向重症监护格式"（Common Longitudinal ICU data Format）整理好，分析脚本写一次、分发到每个站点本地运行，只有聚合后的统计结果跨站点流动，患者级数据永不离开医院。这套思路把"假设→多中心结果"的周期从"以年计"压到"以周计"，并已在联盟内跑通了死亡率模型外部验证与体温轨迹分型两个概念验证研究。
导语读法三则：
- 把它当数据集下：CLIF 本体数据下载不到——联邦架构决定了它没有集中式数据包。想拿"CLIF 格式的示例数据"，去 PhysioNet 取 MIMIC-IV-Ext-CLIF（凭证访问），这是官方参考实现（§6）。
- 想理解它和 MIMIC/eICU 的区别：直奔 §1 与 §9——CLIF 是"格式/标准层"，MIMIC/eICU 是"数据本体层"，三者是互补而非替代。
- 要做多中心 ICU 研究：直奔 §2（schema）与 §3（mCIDE 标注机制），再读 §6 的三层获取门槛与 §10 的坑。
§0 导读：这个数据集解决什么问题
重症监护室（ICU）是临床 AI 最诱人的场景之一：数据密集、时序性强、结局标签齐全。但 ICU 数据科学有一个结构性瓶颈——数据被锁在各自的电子健康记录（EHR）系统里。文献里反复出现的困境是：医院的数据仓库（EDW）各有各的架构、语法与术语体系，一份分析脚本换一家医院就得重写；想把多家医院的数据合并，先要签复杂的 DUA，还要解决隐私合规。结果是大多数"多中心 ICU 研究"要么样本量受限于单中心，要么耗在数据协调上——从提出问题到拿到多中心结果，动辄以年计。
已有的解法是通用数据模型（CDM），典型如 OMOP（Observational Medical Outcomes Partnership）。OMOP 让分析脚本可以跨数据源复用，但它为整个 EHR 设计、偏行政与计费口径，用于 ICU 研究时需要大量数据工程投入，且容易损失 ICU 特有的临床颗粒度（呼吸机参数、血管活性药物滴定、频繁的生命体征）。
CLIF 的回答是专为重症设计的轻量标准 + 联邦执行。它做了三件事：
第一，定义一套 ICU 专用 schema。CLIF 是一个以 encounter（就诊）为中心的关系型数据库格式，表结构围绕"照护过程—临床结局—细粒度生理测量"组织（论文图 1 的实体关系图，v1.0 共 23 张表）。它不是把 EHR 全盘搬入，而是精选 ICU 研究最需要的那部分。
第二，用 mCIDE 锁住关键变量。对每张表，联盟的临床专家共识定义一组"最小通用 ICU 数据元素"（minimum Common ICU Data Elements, mCIDE），每个元素有精确临床定义和有限的允许取值（permissible values）。同时保留源 EHR 的原始标签——标准化字段供跨站分析，原始标签供质控核查，鱼与熊掌兼得。
第三，用联邦架构绕过数据共享。分析代码分发到各站点在本地运行，只有聚合结果跨站点流动。患者数据一次都不用挪窝，隐私风险从"如何合规共享数据"简化为"如何合规共享结果"。
0.1 一个类比：ICU 数据的"欧盟翻译机制"
想象一个研究问题需要 13 个国家的医院共同回答。传统做法是把各国病历翻译成同一种语言后运到一处——翻译工作繁重，运输有隐私风险，各国法规不一。CLIF 的做法是：先制定一份"共同语言规范"（schema + mCIDE），让各国医院在自己的院内把本地病历整理成规范形式；然后把"提问的脚本"（分析代码）发往各国就地执行，只把"统计答案"（聚合结果）寄回。病历原件从不出国。
这个类比的三个要点：① 规范先行——没有共同语言，代码无法复用；② 就地执行——数据不动，动作动；③ 答案聚合——个体不可还原，隐私可控。
0.2 为什么这件事值得关注
三个数字说明 CLIF 的分量：
- 5,000,000+——论文开篇：危重症（需要生命支持的急性器官衰竭）每年威胁超过五百万美国人的生命；
- 111,440——论文中纳入 2020-2021 队列的 ICU 入院数（9 家 health systems / 39 家医院）；
- 939,328——官网 2026-09 口径的联盟累计患者数（67 医院 / 13 机构）。
单中心 ICU 研究常受样本量与人群单一性限制；多中心研究则卡在数据共享。CLIF 瞄准的正是这个"想要多中心、又搬不动数据"的死结。
§0 读法三则：
- 这个条目讲的是"标准 + 联盟"，不是"一个能下载的数据集"——如果你要找的是"下下来就能训练模型的数据"（MIMIC、eICU），本条目会告诉你 CLIF 与它们的分工（§9）。
- CLIF 的核心产出是可执行的规范（schema、词表、ETL、clifpy 等工具，Apache-2.0），这些你随时能从 GitHub 拿走；唯一能拿到的"数据"是物理上可下载的 MIMIC-IV-Ext-CLIF 参考实现（§6）。
- 全文规模数字有多个并存口径（预印本/正式论文/官网），已在 §4 与 §10 逐条存照——引用前先确认口径，别把 94,356、111,440、939,328 混着用。
§1 数据集速览：十问十答
Q1：CLIF 到底是什么？是数据集还是标准？
标准，且是带联盟的活标准。CLIF 是"通用纵向重症监护数据格式"（Common Longitudinal ICU data Format）——一套开源的关系型数据库 schema + 受控词表 + ETL/分析工具。它配套一个跨机构研究联盟（CLIF Consortium），联盟站点把各自的数据按此格式整理，用于联邦研究。它不是一份放在服务器上供下载的患者数据。
Q2：全称到底怎么写？
官方存在几种等价变体：GitHub README 写 “Common Longitudinal ICU data Format (CLIF)”，论文标题写 “A Common Longitudinal Intensive Care Unit data Format (CLIF)”（把 ICU 展开）。两者指同一标准，不是两样东西（坑 6）。
Q3：谁做的？规模多大？
CLIF Consortium，2023 年 7 月组建，由 University of Chicago 牵头（联络邮箱 clif_consortium@uchicago.edu）。联席主席是 Nicholas Ingraham（University of Minnesota）与 Catherine Gao（Northwestern University），创始执行主任 William Parker（UChicago）。官网 2026-09-28 口径：939,328 名患者、67 家医院、13 个机构（“16 Sites / 13 Active Sites”）。
Q4：数据都在哪儿？我能下全量吗？
下不到，这是设计使然。CLIF 用联邦架构：患者级数据留在各机构本地，永不集中。你能公开获取的是标准规范本身（Apache-2.0，GitHub），以及一份格式参考实现——MIMIC-IV-Ext-CLIF（PhysioNet，凭证访问）。
Q5：联邦架构具体怎么转？
站点把本地 EHR 按 CLIF schema 转换（用 CLIF-MIMIC、CLIF-C2D2 等 ETL 管线），把分析代码部署到本地环境执行，只把聚合统计（模型 AUC、队列计数等）回传。论文用两个概念验证研究演示：院内死亡率预测模型的外部验证，以及 72 小时体温轨迹分型。
Q6：schema 长什么样、多少张表？
论文 v1.0 实体关系图共 23 张表（期刊版图注计 22 张）：patient、hospitalization、adt（入出转）、provider、vitals、labs、respiratory_support、medication_orders/medication_admin_continuous/medication_admin_intermittent、crrt_therapy、ecmo_mcs、microbiology_culture/susceptibility/nonculture、patient_assessments、position、therapy_details 等，以 patient_id / hospitalization_id（论文语境亦写 encounter_id）关联。
Q7：mCIDE 是什么、为什么重要？
mCIDE = minimum Common ICU Data Elements（最小通用 ICU 数据元素）。每张表用 _category 后缀字段承载标准化元素（有限允许值），同时用 _name 字段保留源 EHR 原始标签。例：源系统里叫 “UCM_LAB HEMOGLOBIN - AUTOMATED”，映射到标准 lab_category = “Hemoglobin”。这可跨站分析，又可回头质控。联盟把 mCIDE 视为"科学诚信的基石"。
Q8：MIMIC-IV-Ext-CLIF 是什么？
是把 MIMIC-IV v3.1 整库转换为 CLIF 格式的公开参考实现（PhysioNet，2026-03-23 发布，v1.1.0，doi:10.13026/j481-g420）。含 14 张 CLIF 表（Parquet）+ 1 张未插补 GCS 补充表。意义在于：没有机构 EHR 权限的研究者也能用 CLIF 标准开发和测试分析代码，代码再"升维"到联盟真实数据上跑。
Q9：许可怎么算？
分三层：标准本体 Apache-2.0（GitHub，宽松、可商用）｜联盟站点数据不公开（联邦、各机构 IRB）｜MIMIC-IV-Ext-CLIF 走 PhysioNet 凭证访问（需 CITI 培训 + DUA）。别一揽子引用"CLIF 是开源的"——开源的是标准，不是患者数据。
Q10：那 CLIF 和 MIMIC、eICU 到底是什么关系？
互补的三层：MIMIC / eICU 是"数据本体"（单中心/多中心的成品数据），CLIF 是"格式标准"（让多机构数据能说同一种话）。CLIF 甚至把 MIMIC-IV 转成自己的格式当参考实现——这恰好说明二者是"标准"与"被标准化对象"的关系（§9）。
1.1 一表看懂 CLIF 的位置
| 维度 | MIMIC-IV | eICU-CRD | CLIF |
|---|---|---|---|
| 是什么 | 单中心 ICU 数据本体 | 多中心 ICU 数据本体 | 多中心数据格式标准 + 联盟 |
| 数据集中？ | 是（可下载） | 是（可下载） | 否（联邦，数据不出院） |
| 机构数 | 1（BIDMC） | 多中心（集中发布） | 跨 12+ 站点（分布式） |
| 许可 | PhysioNet 凭证访问 | PhysioNet 凭证访问 | 标准 Apache-2.0；数据需入盟 |
| 与研究者的关系 | 你给我数据 | 你给我数据 | 你给我"统一格式"，代码我去跑 |
| 参照角色 | 单中心金标准 | 集中式多中心 | 联邦式多中心 |
一句话区分：想下载数据→找 MIMIC/eICU；想跨机构协同研究又不搬数据→用 CLIF。
1.2 CLIF 的四件产出
CLIF 项目实际产出四类资产，用途与获取方式各不相同：
- 规范（schema + 数据字典 + mCIDE 词表）——"数据长什么样"的定义，Apache-2.0 公开；
- 工具（ETL 管线 + clifpy + 分析模板）——“怎么转、怎么用”，Apache-2.0 公开；
- 公开参考实现（MIMIC-IV-Ext-CLIF）——“格式长什么样的实物样板”，PhysioNet 凭证访问；
- 联邦网络（联盟站点数据 + 治理机制）——“真实多中心数据”，需入盟。
认清这四件产出的边界，是避免"CLIF 到底能不能下载"这类困惑的关键。
1.3 一句话记住 CLIF
CLIF = ICU 数据的"普通话"。各家医院说各自的方言（本地 EHR 术语），CLIF 定了一套普通话（schema + mCIDE），让分析脚本（说普通话的"指令"）能在每家医院本地执行；而病人数据本身（方言的"原话"）从不出门。
1.4 五个最易混淆的"不是"
- 不是一个能下载的患者数据集（数据不集中）；
- 不是集中式多中心数据库（那是 eICU-CRD 的模式）；
- 不是联邦学习框架（那是运行在 CLIF 上的一种方法）；
- 不是 FHIR 的替代品（FHIR 面向系统互操作，CLIF 面向研究分析）；
- 不是 MIMIC 的竞争品（CLIF 反而把 MIMIC-IV 转成自己的格式当样板）。
§1.5 为什么重症监护需要专用标准
在正式进入 schema 细节前，有必要回答一个前置问题：为什么不能直接用 OMOP 这样的通用 CDM，而要专门造一个 CLIF？ 论文对此有明确论证，也是理解 CLIF 设计取舍的钥匙。
1.5.1 通用 CDM 的代价
OMOP（Observational Medical Outcomes Partnership）CDM 是成熟的通用数据模型，它让分析脚本可以跨数据源复用，缓解了数据协调的负担。但论文指出了两条局限：
- 需要大量数据工程投入：OMOP 为覆盖全 EHR 而设计，把 ICU 数据映射进去需要大量工程工作；
- 可能损失 ICU 关键颗粒度：OMOP 偏行政与计费口径，ICU 特有的细粒度信息——呼吸机参数、血管活性药物的持续滴定、高频生命体征——在映射过程中容易被稀释或丢失。
论文的原话是：通用 CDM"可以支持标准化分析脚本，但需要高级数据工程技能，且有丢失关键粒度临床信息的风险"。
1.5.2 ICU 数据的特殊性
ICU 研究对数据有独特要求，这正是 CLIF 的设计出发点：
- 纵向性（longitudinal）——患者的生理状态在小时甚至分钟尺度上变化，事件必须带精确时间戳，能还原完整轨迹；
- 照护过程密集——呼吸支持、血管活性药、镇静、CRRT、ECMO 等干预高频且需精确时序；
- 结局明确且易捕获——院内死亡、机械通气时长、ICU 停留时长等标签齐全，这也是 ICU 适合临床 AI 的原因；
- 生理测量细粒度——生命体征与检验的高频采集是 ICU 数据最有价值的部分。
CLIF 的共识决策因此明确三大优先级：① 常规临床数据的完整性；② 时间粒度；③ 一致测量的临床结局。表结构"强调照护过程、临床结局和细粒度的临床生理测量"。
1.5.3 标准的三个技术选择
在上述取舍下，CLIF 做了三个关键技术选择，后文会逐一展开：
- 关系型 + encounter-centric（§2）：以就诊为中心，纵向事件围绕锚表挂接；
- mCIDE 双层结构（§3）：
_category标准化 +_name保真，兼顾可比性与可核查性； - 语言无关 + 联邦执行（§5/§6）：schema 可用 SQL 视图或任意数据库结构实现（“CLIF is language agnostic”），分析代码跨站点分发。
理解了"为什么是重症专用"，就能理解 CLIF 的每一处设计不是在重复造轮子，而是在为一个被通用模型牺牲掉的场景重建合适的工具。
§2 数据构成与规格
2.1 关系型 schema：以 encounter 为中心
CLIF 的数据库设计原则是"以就诊为中心"（encounter-centric）：一行代表一次住院/一次 ICU 停留，围绕它挂接纵向的临床事件。“Relational CLIF”（R-CLIF）是官方对这套关系型结构的称法。论文 v1.0 的实体关系图（ERD）列出了 23 张表，按临床语义分为若干列类别——人口学、客观测量、呼吸支持、医嘱与出入量。
锚表（anchor tables） 三张，构成骨架：
- patient：患者级人口学（去标识），承载跨住院稳定的属性；
- hospitalization：住院级信息，入院与出院详情；
- adt（Admission-Discharge-Transfer）：患者在院内各地点之间的移动轨迹，是从"住院"定位到"ICU 停留"的桥梁。
纵向事件表 按临床域组织：
| 临床域 | 表 | 内容 |
|---|---|---|
| 临床监测 | vitals、labs、patient_assessments、position |
生命体征、检验结果、评估量表、体位 |
| 呼吸照护 | respiratory_support |
呼吸支持设备与参数（含机械通气模式） |
| 药物 | medication_orders、medication_admin_continuous、medication_admin_intermittent |
医嘱与持续/间断给药 |
| 器官支持 | crrt_therapy、ecmo_mcs |
连续性肾脏替代治疗、ECMO 与机械循环支持 |
| 微生物 | microbiology_culture、microbiology_susceptibility、microbiology_nonculture |
培养、药敏、非培养微生物学 |
| 其他治疗 | therapy_details、procedures |
治疗细节、操作 |
| 出入量 | input、output |
液体入量与出量 |
| 行政/诊断 | provider、hospital_diagnosis、admission_diagnosis |
提供者、诊断 |
关联键：论文预印本图注写"主要关联键（primarily encounter_id）"，而期刊版图注改写作 hospitalization_id——这是 ERD 版本演进留下的口径差异（坑 8），落地数据集（如 MIMIC-IV-Ext-CLIF）实际以 patient_id 与 hospitalization_id 双键关联。
2.1.1 完整表清单（论文 v1.0 ERD 口径）
论文图 1 逐张列出了 v1.0 ERD 的表，按编号还原如下（这是理解 CLIF 覆盖范围最权威的清单）：
- Patient（患者）2. Hospitalization（住院）3. Admission Diagnosis（入院诊断）4. Provider（提供者）5. ADT（Admission, Discharge, Transfer，入出转）6. Vitals（生命体征）7. Scores（评分）8. Dialysis（透析）9. Intake/Output（入量/出量）10. Procedures（操作）11. Therapy Session（治疗疗程）12. Therapy Details（治疗细节）13. Respiratory Support（呼吸支持）14. Position（体位）15. ECMO & MCS（体外膜肺氧合与机械循环支持）16. Labs（检验）17. Microbiology Culture（微生物培养）18. Sensitivity（药敏）19. Microbiology Non-culture（非培养微生物学）20. Respiratory Support（呼吸支持，图中重复出现）21. Medication Orders（药物医嘱）22. Medication Admin Intermittent（间断给药）23. Medication Admin Continuous（持续给药）
注意：该清单中 Respiratory Support 出现两次（编号 13 与 20），“23 张表"的计数包含这一重复；期刊版图注随后称"22 张表”，很可能是修正了重复计数。这解释了论文内部 23 vs 22 的表数差异（坑 5）。无论 22 还是 23，CLIF v1.0 覆盖的临床域是一致的。
2.1.2 三张锚表详解
patient（患者表）：患者级人口学与稳定属性。这是 CLIF 里粒度最粗的一层——一行一个患者，承载跨多次住院不变的信息。MIMIC-IV-Ext-CLIF 的一个已知处理难点正在此表：MIMIC-IV 的种族/族裔是逐次就诊记录、同一患者可能在不同就诊有不同值，而 CLIF 的 patient 表要求每个患者一个唯一值。派生数据集采取的策略是"选择出现频率最高的有效值（排除 Unknown 与 Other），同频时取最近一次"。
hospitalization（住院表）：住院级信息——入院与出院详情。这是纵向事件的直接宿主。
adt（入出转表）：患者在院内各地点间的移动轨迹。这张表是从"住院"精确定位到"ICU 停留"的桥梁——论文的队列识别脚本正是用 ADT 与 patient 表共同筛选出"住院 48 小时内入 ICU 且停留 ≥24 小时"的成人。
2.1.3 数据模型的实现方式
CLIF 刻意保持实现无关（language agnostic）：schema 可以落地为 SQL 视图，也可以映射到其他数据库结构。这意味着医院不需要更换现有数据平台，只需在其上建立符合 CLIF 定义的视图/表集合。这是 CLIF 降低采用门槛的一个务实设计——不要求机构推倒重来。
2.1.4 与源 EDW 的关系
CLIF 不是要取代医院的电子数据仓库（EDW）。论文明确，ER 模型"也包含其他标准住院 EDW 表（如 vitals、labs）"，即 CLIF 在源 EDW 之上提供一层重症专用的标准化视图。这种"叠加而非替换"的定位，使 CLIF 能适应机构从传统数据仓库向数据湖（data lake）迁移的演进趋势。
2.2 数据架构工具的补充说明
CLIF 的关键贡献之一是一个开源 Web 应用，用于把关系型数据库转成纵向数据集、选择研究特定变量、并生成多种编程语言的代码。它让数据处理流程化，并支持跨中心比较而无需集中患者级数据。GitHub 组织下 65 个仓库构成完整工具生态（§7）。
2.3 MIMIC-IV-Ext-CLIF 的 14 表规格
公开参考实现落在一份具体的表清单上，值得精确记录（这是多数人唯一能实际下载的 CLIF 数据）：
mimic-iv-ext-clif/
├── README.md
├── clif_patient.parquet
├── clif_hospitalization.parquet
├── clif_adt.parquet
├── clif_vitals.parquet
├── clif_labs.parquet
├── clif_respiratory_support.parquet
├── clif_patient_assessments.parquet
├── clif_patient_assessments_raw_gcs.parquet ← 未插补 GCS 补充表
├── clif_medication_admin_continuous.parquet
├── clif_medication_admin_intermittent.parquet
├── clif_position.parquet
├── clif_crrt_therapy.parquet
├── clif_code_status.parquet
├── clif_hospital_diagnosis.parquet
└── clif_patient_procedures.parquet
即 14 张 CLIF 表（patient、hospitalization、adt、vitals、labs、respiratory_support、patient_assessments、medication_admin_continuous、medication_admin_intermittent、position、crrt_therapy、code_status、hospital_diagnosis、patient_procedures）+ 1 张补充表（clif_patient_assessments_raw_gcs，直接取自 chartevents 的未插补 GCS 评分）。全部 Parquet，按 patient_id 与 hospitalization_id 关联。
注意：14 表实现 < 23 表完整 schema。参考实现是从 MIMIC-IV 能映射出的子集——不是全部 CLIF 表都有 MIMIC 对应源。这也解释了为什么论文 ERD 的表数（23/22）与公开实现（14）不同：一个是标准的野心，一个是单个数据源的映射能力。
2.4 版本的演进：从 2.0.0 到 3.0（Going Multimodal）
- CLIF 2.0.0：论文正文引用的版本，发布在 clif-consortium.github.io/website；
- CLIF 2.1.0：官网当前数据字典版本（Data Dictionary CLIF 2.1.0），也是 PhysioNet 页面指路的"最新版"；
- CLIF 3.0（Release: 2026 年 7 月）：定位"Going Multimodal"——影像（imaging）与临床笔记（clinical notes） 加入既有结构化 ICU 表。这是 CLIF 从"结构化时序数据标准"迈向"多模态重症数据标准"的关键一步。
3.0 的新增方向在 GitHub 表级负责人（POC）列表中已可见端倪：clinical_notes_facts、clinical_notes_text、clinical_trial、key_icu_orders、invasive_hemodynamics、transfusion、validated_diagnosis、place_based_index 等新表进入维护视野。mCIDE 也同步升至 v3.0，官网开放 expansion request period（扩词投票）——允许研究者浏览类别、提议新的 permissible values、并背书他人提案。
§3 mCIDE：CLIF 的标注核心机制
3.1 什么是 mCIDE
CLIF 最核心的方法学创新是 mCIDE（minimum Common ICU Data Elements，最小通用 ICU 数据元素）。概念借用自美国 NIH 对 Common Data Elements（CDE，通用数据元素）的定义——“标准化的、精确定义的问题，配以一组允许的应答，跨站点、跨研究、跨临床试验系统化使用，以保证数据采集的一致性”。CLIF 为每张表定义一组最小 ICU 专用 CDE，以 _category 后缀标识。
每个 mCIDE 满足两个条件：① 代表一个与重症相关的精确定义临床实体；② 具备有限的允许取值集合。凡是 NIH 已背书的 CDE，CLIF 尽量采用。
3.2 双列结构：标准化 + 原始标签并存
CLIF 的关键设计是不丢弃源数据。用论文的原例说明：
lab_category（mCIDE 标准字段）= “Hemoglobin”——有限的允许取值之一，跨站点可比；lab_name（源标签保留字段）= “UCM_LAB HEMOGLOBIN - AUTOMATED”——站点本地的具体检验名称。
这套"_category 标准化 + _name 保真"的双列结构，同时满足两个目标：跨机构分析可复用（用 _category），数据质量可回溯核查（用 _name 对照原始标签）。论文把它概括为"在创建标准化 ICU 元素的同时保留原始数据标签以供质量控制"。
3.3 联盟自创的元素
并非所有 mCIDE 都能从现有 CDE 借来。联盟创建了若干新元素，例如机械通气模式（mode_category）——因为呼吸机模式的语义与粒度在通用术语体系里缺乏适配的现成定义。这类自创元素是 CLIF 相对 OMOP 等通用 CDM 的差异化价值：它是临床专家为重症场景量身定制的词汇表。
3.4 异常值处理
CLIF 配套联盟统一制定的 outlier ranges（异常值范围）与标准化处理脚本，用于清除明确的录入错误（论文举例：心率 1,000 bpm 这类明显错误）。这套规则是跨站点数据可比性的前提之一。
3.5 为什么 mCIDE 是"科学诚信的基石"
CLIF 官网把 mCIDE 提升到科学诚信的高度：如果没有统一的、精确定义的数据元素，各站点上报的"同一个变量"可能语义不一致，聚合结果就会失真。mCIDE 的价值不在于收集更多数据，而在于确保收集的是同一个东西——这是任何多中心研究成立的前提。因此官网把 mCIDE 的持续维护（v3.0 的扩词投票机制）视为联盟治理的核心环节。
3.6 mCIDE 的治理演进（v3.0）
mCIDE 不是一次定死的词表，而是持续演进的公共资产。v3.0 的 expansion request period（扩词请求期）设置了一套社区共治流程：研究者可以浏览现有类别、提议新的 permissible values（允许取值）、并背书他人的提案。这套机制的意义在于：
- 临床新知的接入——新的通气模式、新的治疗手段需要新词；
- 众包式共识——不是由中心机构单方面拍板，而是由使用它的临床专家群体投票；
- 版本可追溯——每次扩展对应新版本，保证历史分析可复现。
mCIDE Explorer 工具让研究者可以浏览词表结构。官网称"mCIDE 是科学诚信的基石"，并把扩词流程作为联盟开放性的标志。
3.7 一个具体例子：血红蛋白的标准化
用论文给的例子把整条链路走一遍：
| 环节 | 内容 |
|---|---|
| 站点源系统标签 | UCM_LAB HEMOGLOBIN - AUTOMATED（UChicago 的本地检验名） |
| CLIF 保留字段 | lab_name = “UCM_LAB HEMOGLOBIN - AUTOMATED” |
| CLIF 标准字段 | lab_category = “Hemoglobin” |
| 跨站分析 | 所有站点的 lab_category = “Hemoglobin” 行可合并统计 |
| 质控回溯 | 若某站映射错误，可用 lab_name 反查原始标签核对 |
这个"双名并存"的模式，是 CLIF 在"标准化"与"保真"之间找到的折中点。它的代价是每张表都要维护两套字段，收益是任何跨站分析都可追溯到源标签。
3.8 词表覆盖的临床域
从 GitHub 表级 POC 可推断 mCIDE 覆盖的临床域：生命体征（vitals）、检验（labs）、呼吸支持（respiratory_support，含机械通气模式）、药物（medication_orders/admin_continuous/admin_intermittent 的给药途径 med_route_category）、微生物与药敏（microbiology_*）、器官支持（crrt_therapy、ecmo_mcs）、患者评估（patient_assessments）、体位（position）、出入量（input/output）、治疗细节（therapy_details）、输血（transfusion）等。每一域都有其临床专家负责维护词表（§7.3）。
3.9 mCIDE 与"数据可比性"的因果链
理解 mCIDE 为什么重要，可以沿一条因果链推演：
- 多中心研究的结论建立在"合并统计"上——把各站点的同类患者放在一起算死亡率、算药物效应；
- 合并统计的前提是变量语义一致——"机械通气"在一家医院指有创通气，在另一家可能含无创，合并即失真；
- 语义一致需要精确定义 + 有限取值——这正是 mCIDE 的两条设计准则；
- 精确定义需要临床专家共识——所以 CLIF 每张表配一位临床 POC，词表由专家群体维护；
- 共识需要可演进机制——所以有 mCIDE v3.0 的扩词投票。
从这条链可以看出：mCIDE 不是一个技术细节，而是"多中心结论是否可信"的根基。这也是官网称其为"科学诚信基石"的原因。
3.10 双层结构的工程代价与收益
_category + _name 双列结构并非没有代价：
| 维度 | 代价 | 收益 |
|---|---|---|
| 存储 | 每变量存两列 | 可追溯、可质控 |
| ETL 复杂度 | 需维护映射表 | 映射错误可事后发现 |
| 分析代码 | 需选用 _category |
跨站脚本可复用 |
| 词表治理 | 需持续维护 permissible values | 语义稳定、可比 |
论文把它概括为"在创建标准化 ICU 元素与保留原始数据标签之间取得平衡"，实质是用一点工程冗余换取跨机构可比性 + 可核查性。
§4 规模与发展史：三个口径的数字
CLIF 的规模数字随联盟扩张而持续变化，导致不同来源给出不同数字。理解这些数字的口径差异是正确使用 CLIF 的关键。
4.1 三个并存口径
| 来源 | 时点 | 患者/入院 | 机构/站点 | 医院 | 队列/说明 |
|---|---|---|---|---|---|
| medRxiv 预印本 | 2024-09 | 94,356 patients | 8 health systems | 33 hospitals | 2020-2021 队列 |
| Intensive Care Med 正式论文 | 2025-03 | 111,440 admissions | 9 health systems | 39 hospitals | 2020-2021 队列（修订后） |
| 官网首页 | 2026-09-28 | 939,328 patients | 13 institutions（16 Sites） | 67 hospitals | 联盟累计格式化全量 |
三者的关系需要分清：
- 94,356 → 111,440：这是同一"2020-2021 队列"从预印本到正式发表（含更正函）期间的修订与扩充。预印本纳入了 8 个 health systems 的 33 家医院，正式版扩展到 9 个 systems 的 39 家医院，患者数随之从 94,356 升到 111,440。这个差异正是 2025 年更正函（Correction, doi:10.1007/s00134-025-07869-2）涉及的范围之一。
- 111,440 → 939,328：这是两个完全不同的量——111,440 是概念验证研究纳入分析的队列（严格纳入标准：成人、住院 48 小时内入 ICU、停留 ≥24 小时、2020-2021），939,328 是联盟累计已格式化的全部患者（不限年份、不限队列筛选）。混用这两个数字会导致严重误读。
4.2 队列纳入标准
概念验证研究的队列定义（论文 Figure E1）：全部成人（≥18 岁），在住院 48 小时内入 ICU 且停留至少 24 小时，时间窗为 2020-01-01 至 2021-12-31，横跨联盟全部站点。这些标准旨在捕获"一般 ICU 人群"，排除入院后很快死亡的患者、以及因非重症原因（如为做操作）入 ICU 的患者。
4.3 人口学特征（两口径）
- 预印本：mean age 60.6 岁（SD 17.2），30% Black，7% Hispanic，45% female；
- 正式论文：mean age 60.7 岁（SD 17.1），28% Black，7% Hispanic，44% female。
两组数字高度接近，微小差异反映站点与队列的修订。这是"同一研究两个时点快照"的典型情形，引用时应与所选版本一致。
4.3.1 分站点构成（预印本 Table 2）
预印本 Table 2 逐站列出了纳入队列的构成，这是理解"多中心异质性"的最佳证据：
| 站点 | 入院数 | 医院数 | 年龄均值(SD) | 女性 | Black 占比 | 白人占比 | 西班牙裔 |
|---|---|---|---|---|---|---|---|
| Emory University | 19,923 | 4 | 61.2 (16.5) | 47% | 45% | 45% | 3.8% |
| JHHS（Johns Hopkins） | 18,325 | 5 | 60.6 (17.4) | 46% | 32% | 55% | 6.6% |
| University of Minnesota | 11,576 | 11 | 61.8 (17.3) | 44% | 7.1% | 82% | 1.9% |
| Northwestern Medicine | 10,625 | 8 | 63.2 (17.5) | 46% | 12.0% | 75.3% | 9.4% |
| Rush University | 9,905 | 1 | 59.6 (16.9) | 47% | 41% | 38% | 20% |
| OHSU | 9,046 | 2 | 59.9 (17.3) | 42% | 8.6% | 83% | 8.7% |
| University of Chicago | 8,079 | 1 | 56.4 (18.5) | 42% | 66% | 25% | 6.2% |
| University of Michigan | 6,877 | 1 | 59.0 (16.2) | 41% | 12% | 79% | 2.9% |
| 联盟合计 | 94,356 | 33 | 60.6 (17.2) | 45% | 30% | 59% | 7.0% |
关键观察——种族构成的极强异质性：各站点的黑人患者占比从 7%（Minnesota）到 66%（UChicago），跨度近十倍。论文的评价是"正如预期，各站点人口在种族上差异显著"。这种异质性正是联邦多中心研究的价值：单中心数据无法代表的人群构成，在多站点合并后得到覆盖。同时也意味着任何分站点结果都可能受人群构成影响。
4.3.2 临床结局的跨站差异
预印本口径（2020-2021，94,356 例）：
- 机械通气：35,789 例接受有创机械通气，占 38%（站点范围 28-50%）；
- 院内死亡：8,920 例，占 9.5%（站点范围 7.4-13%）。
年龄（均值 60.6，范围 56.4-63.2）与性别（女性 45%，范围 41-47%）跨站点较为接近，但机械通气率与死亡率有中等程度差异——论文称"临床结局在各系统间存在中度差异"。这为后文死亡率模型的跨站性能波动提供了背景：不同站点的病例组合（case mix）本就不同。
4.4 联盟发展时间线
- 2023-07：联盟组建启动——地理上多样化的美国临床科学家与数据科学家线上集结；
- 2023-2024：识别跨机构使用 EHR 做重症研究的实际挑战，制定标准化操作规程、共享术语与稳健质控方法；官网 About 时间线记 “Institutions 18+”、“808K+ Patients”、“1.03M hospitalizations”；
- 2024-09：medRxiv 预印本发布；
- 2025-03：Intensive Care Med 正式发表框架论文并附更正函；
- 2026-03-23：MIMIC-IV-Ext-CLIF 上 PhysioNet（v1.1.0）；
- 2026-07：CLIF v3.0 发布（Going Multimodal）；
- 2026-09：官网口径 939,328 患者 / 67 医院 / 13 机构。
4.5 机构数字的官网内部不一致
需特别标注：官网首页 hero 区显示 “13 institutions / 67 hospitals / 16 Sites / 13 Active Sites / Coming Soon (3)”，而 About 页写 “17 institutions and 63 hospitals”，Team 页写 “17 institutions” + “Twelve sites have already contributed CLIF-formatted data, with 6 more actively preparing”。同一官网三个页面给出不一致的机构/医院数，很可能是不同更新时点的静态文案未同步（坑 4）。本条目如实记录这种并存，建议引用时指明来源页面与时点。
4.6 为什么规模数字会持续变化
理解 CLIF 规模数字的多口径，还要理解其内生动态性：
- 联盟在扩张——从 8 个 health systems（2024）到 13-17 个机构（2026），每加入一个站点，累计患者数就跳升；
- 数据在回填——已加入的站点可能继续补录历史年份数据；
- 队列筛选不同——“累计格式化患者”（官网口径）与"符合某研究纳入标准者"（论文口径）是不同量级；
- 版本修订——正式论文相对预印本修订了数字（94,356→111,440），并有正式更正函。
所以任何 CLIF 规模数字都应带时间戳与口径说明。本条目在 INFOBOX 与 §4 均同时给出论文口径与官网口径，正是为此。
4.7 覆盖人群的代表性
从 §4.3.1 的分站点表可见，CLIF 联盟的人群覆盖相当多样：
- 地理：横跨美国东西（Oregon、Minnesota、Michigan、Emory/Atlanta、Chicago 多家、Johns Hopkins/Baltimore）；
- 种族：黑人占比 7%-66%，跨度极大；
- 机构类型：从单医院机构（Michigan、UChicago、Rush）到多医院系统（Minnesota 11 家、Northwestern 8 家、JHHS 5 家、Emory 4 家）。
论文评价各站点人群"in terms of age and sex 相似，但种族差异显著（as expected）"。这种多样性既是 CLIF 的价值（更可泛化的结论），也是挑战（病例组合差异导致模型跨站性能波动，见 §5.1）。
§5 概念验证研究：CLIF 能跑通什么
论文用两个联邦概念验证（proof-of-concept）研究展示 CLIF 的实用性——它们既是技术演示，也是"多中心研究"范式的样板。
5.1 研究一：院内死亡率预测模型的外部验证
设计：开发一个多变量 AI ICU 死亡率预测模型，在一个 health system 派生，然后在联盟其余站点做外部验证。
结果（正式论文摘要口径）：
- 派生站点表现良好：AUC 0.81，Brier score 0.06；
- 跨 CLIF 联盟各站点表现有波动：AUC 0.73-0.81，Brier score 0.06-0.10；
- 相对派生站点，出现性能衰减（degradation）——这是多中心验证的经典现象，也恰是 CLIF 的价值所在：它让"模型在不同机构还准不准"变成一个可量化、可复现的问题。
注：预印本口径的跨站点 AUC 为 0.74-0.83、Brier 0.06-0.01（后者疑为排版笔误，Brier 不可能小于 0.06 而写 0.01 却与正式版 0.10 对应——正式版已修正为 0.06-0.10）。以正式论文为准。
评估三方面（论文方法）：① 区分度（discrimination）——用 ROC 曲线下面积 AUC；② 校准度（calibration）——用 Brier score 与校准图；③ 临床效用（clinical utility）——用决策曲线分析（decision curve analysis）。
分站点性能（预印本全文口径）：模型在派生站点 Rush University 的内部验证队列上区分度与校准良好。在其他七个站点的表现则有波动：
- 较高的站点 AUC 达到 0.84（95% CI 0.83-0.84）与 0.81（95% CI 0.79-0.82）；
- 最低的两个站点是 Emory 与 University of Minnesota，AUC 均为 0.74（Emory 95% CI 0.73-0.75；Minnesota 95% CI 0.72-0.75）。
校准度：Brier score 从 OHSU 的 0.059（校准最好）到 University of Michigan 与 University of Chicago 的 0.097（校准最差），跨度约 1.6 倍。
临床效用：决策曲线分析显示各站点净获益（net benefit）为正但水平不一。关键失败案例：OHSU 与 Emory 的测试集出现显著的校准斜率误差（calibration slope error），表现为高估死亡率，导致在预设决策阈值下的净获益降低、临床效用下降。论文据此指出：将预后模型"一刀切"地推广到多样化医疗环境是困难的。
方法学意义：这个案例展示了 CLIF 在"严谨多站点预测模型评估"上的价值。论文给出的自然下一步是——用去中心化联邦学习（decentralized federated learning） 在整个联盟上训练与验证一套可泛化的 ICU 预测模型。
5.2 研究二：72 小时体温轨迹与结局
设计：用**基于组的轨迹模型（group-based trajectory models, GBTM）**评估危重症患者入院后 72 小时的体温轨迹，及其与机械通气和院内死亡率的关联。
模型来源：外部验证的是一个先前开发的非监督模型（Bhavani 等的体温轨迹亚表型模型），它依据住院患者 72 小时体温趋势，把每次就诊归入四个互斥亚表型之一：
- NT（normothermic，正常体温）；
- HT（hypothermic，低体温）；
- HFR（hyperthermic fast-resolver，高热-快消退）；
- HSR（hyperthermic slow-resolver，高热-慢消退）。
归类算法：开发分析脚本，标准化 ICU 入院后前 72 小时的体温测量，把每位患者归入"观测体温与该亚表型参考轨迹之间均方误差和最小"的亚表型组。
结果：体温轨迹在各 health systems 之间高度相似（这是跨机构可比性的好消息）；低体温（HT）与高热-慢消退（HSR） 两类患者一致地死亡率最高——无论在哪家医院。论文用多变量 logistic 回归（校正年龄、性别、种族、族裔）评估亚表型与院内死亡、有创机械通气的关联。
与原始研究的关系：Bhavani 等在脓毒症特异性队列（以及 COVID-19、疑似感染人群）中识别出这四个亚型，并证明它们有独特的免疫与炎症特征、以及不同的 ICU 使用与死亡结局；但该模型此前未在更广泛的危重人群中验证。CLIF 这个案例把它扩展到"未分化的重症患者"，发现低体温组死亡率最高这一模式在一般危重人群中依然稳健——说明该亚表型是稳健的结局预测因子。
意义：这个研究演示了 CLIF 支撑"疾病亚表型（sub-phenotyping）"发现的能力——一个在单中心可能因样本不足而无法稳健识别的表型，在联邦多中心框架下可以跨机构验证。
5.3 两个研究共同证明的事
- CLIF 能支撑模型外部验证——量化跨机构泛化能力；
- CLIF 能支撑亚表型发现——识别跨机构稳健的临床分型；
- 联邦架构真的可行——两个研究全程没有任何患者级数据跨站点流动。
论文展望的后续应用包括：实用型 EHR 临床试验（pragmatic EHR-based trials）、目标试验仿真（target trial emulations）、危重症基础多模态 AI 模型、以及实时重症质控仪表盘。
5.4 MIMIC-IV-Ext-CLIF 已支撑的实际项目
PhysioNet 页面列举了参考实现已经支撑的 CLIF 项目（每个有独立代码仓库）：
- 肺保护性通气依从性的异质性——不同站点对肺保护通气策略的依从差异；
- ICU 再入院率与相关结局；
- 机械通气患者早期活动（mobilization）机会识别；
- 呼吸机相关肺炎短期风险 ML 模型验证。
这四项说明 CLIF 已从"格式演示"进入"产出具体临床发现"的阶段。GitHub 上还有 40+ 具名项目（§7），覆盖 ARF/NIV、脓毒症识别、CRRT 流行病学、镇静轨迹、心脏骤停结局、CAR-T 体温节律等广泛主题。
5.5 论文自述的局限与改进方向
论文专设"局限与改进领域（Limitations and areas for improvement）"一节，坦诚列出 CLIF 的不足——这些是引用 CLIF 时必须知晓的边界：
-
实施门槛高：CLIF 在每个联盟站点的落地都需要大量数据科学与重症临床专业知识。联盟正在开发开源工具，帮助各类医疗机构以自动化、可扩展、灵活的方式采用 CLIF。这些 ETL 工具还需适应医疗数据存储的演进趋势（机构从传统数据仓库向灵活可扩展的数据湖 data lake 迁移）。
-
尚未对接互操作性标准：CLIF 目前尚未与 HL7 FHIR（Fast Healthcare Interoperability Resources）等既有互操作性标准建立链接。这是未来数据工程的重要方向——与 FHIR 对接能让 CLIF 融入更广泛的医疗数据交换生态。
-
理想是公开去标识数据，现实是联邦：论文写道，虽然本工作展示了联邦分析的好处，但"理想情况下我们会发布 CLIF 数据库的去标识版本供公众使用"。一旦 CLIF 的格式价值得到充分确立，作者希望说服各 health system 领导层，投入所需的大规模投资，"以 MIMIC 为鼓舞人心的榜样"公开数据。这最后一点最能说明 CLIF 与 MIMIC 的关系——CLIF 把 MIMIC 视为公开数据共享的典范，并表达了向之看齐的愿望，但目前尚未实现。
5.6 论文的展望方向
论文列出 CLIF 的四个理想化未来方向：
- 实用型 EHR 临床试验（pragmatic EHR-based trials）的数据格式；
- 严谨的目标试验仿真（target trial emulation）；
- 危重症基础多模态 AI 模型（foundational multi-modal AI models）；
- 实时重症监护质量仪表盘（real-time critical care quality dashboards）。
论文特别指出，因果推断方法（如目标试验仿真）“为 CLIF 联盟提供了清晰的路线图”。这四个方向勾勒出 CLIF 从"数据标准化"走向"临床决策支持基础设施"的野心。
5.7 两个案例合起来说明了什么
把两个概念验证研究放在一起看，可以读出 CLIF 的三层价值：
第一层——技术可行性：跨 8-9 家 health systems、30+ 家医院的数据，用同一套 schema 与代码跑通，全程无患者数据跨站。这证明联邦架构在真实多中心场景可落地。
第二层——科学产出：
- 案例一产出了"模型跨机构泛化会衰减"的量化证据（AUC 0.73-0.84，校准误差在 OHSU/Emory 显著）；
- 案例二产出了"体温亚型在一般危重人群中稳健"的验证结论（低体温组死亡率最高这一模式跨机构一致）。
第三层——范式示范：两个研究展示了"写一次代码、跨多站执行、回收集合结果"的工作流，为后续 40+ 项目提供了模板。论文作者自己也指出，下一步是用去中心化联邦学习在整个联盟训练可泛化模型——即把联邦分析推向联邦建模。
一个反直觉的结论：案例一的"性能衰减"不是 CLIF 的缺陷，而是它的核心价值——正因为 CLIF 让多站点验证变得容易，才让"某个在网上很准的模型换家医院就不准"这件事被系统性地暴露出来。单中心研究无法发现这个问题。
§6 获取与许可：三层门槛
CLIF 的"获取"和其他数据集完全不同——它不是"下载一个文件"，而是进入一个分层体系。理解这三层是使用 CLIF 的第一步。
6.1 第一层：标准本体（Apache-2.0，公开即取）
你随时能拿的：CLIF 的 schema 定义、mCIDE 词表、数据字典、ETL 管线代码、联邦分析代码、clifpy 等工具。
- 许可：Apache License 2.0——宽松开源许可，允许商用、修改、再分发（需保留版权与许可声明）。官网明示 “CLIF is open source software licensed under the Apache License 2.0”。
- 入口：GitHub 组织
Common-Longitudinal-ICU-data-Format（65 个仓库）；官网资料区（CLIF 101、ETL Guide、DQA Framework、mCIDE Explorer、Data Dictionary）。 - 这一层不需要任何申请，克隆即用。
6.2 第二层：MIMIC-IV-Ext-CLIF 参考实现（PhysioNet 凭证访问）
想拿"CLIF 格式的真实数据"跑通代码，唯一公开路径是这份参考实现。
- 地址：https://physionet.org/content/mimic-iv-ext-clif/
- DOI：10.13026/j481-g420；版本 1.1.0；发布 2026-03-23
- 获取方式：Credentialed Access（凭证访问）——需在 PhysioNet 完成认证（通常含 CITI 培训 + 签署数据使用协议 DUA），不是 open access。
- 内容：MIMIC-IV v3.1 转换的 14 张 CLIF 表（Parquet）+ 1 张未插补 GCS 补充表。
- 许可：沿用 MIMIC-IV 的 PhysioNet Credentialed Health Data License 口径（MIMIC 派生数据）。
- 引用：Liao, Z., Guleria, S., Smith, K., Baccile, R., Chhikara, K., Therese, D., Chaudhari, V., Burkhart, M. C., Beaulieu-Jones, B., Jain, S., Connell, K., Buell, K., Rojas, J., Lyons, P., Bhavani, S., Gao, C. A., Hochberg, C., Ingraham, N., Parker, W., & Consortium, C. (2026). (version 1.1.0). PhysioNet. RRID:SCR_007345.
它为什么重要：对没有机构 EHR 权限的研究者，这是"低门槛进入 CLIF 生态"的入口。代码在这个数据集上开发测试通过后，可以直接升维到联盟真实数据上运行——因为两者用同一个 schema。
6.3 第三层：联盟站点真实数据（不公开，需入盟）
联盟各站点的患者级 CLIF 数据不对外分发。获取方式是：
- 成为联盟成员（联系 clif_consortium@uchicago.edu，走官网 Governance 流程）；
- 各站点独立取得 IRB 批准（observational study 或 research EDW 建设/质控）；
- 联邦架构：数据始终留在本地，你提交分析代码，站点本地执行并回传聚合结果。
论文明确：“No patient-level data was shared between sites at any point.”（任何时点站点间都不共享患者级数据）——这不是限制，而是 CLIF 的设计核心。
6.4 三层门槛一览
| 层级 | 内容 | 许可 | 获取方式 |
|---|---|---|---|
| 标准本体 | schema、mCIDE、工具、分析代码 | Apache-2.0 | GitHub 公开即取 |
| 参考实现 | MIMIC-IV-Ext-CLIF（14 表 Parquet） | PhysioNet 凭证许可 | PhysioNet 认证 + DUA |
| 真实多机构数据 | 站点本地 CLIF 数据库 | 各机构 IRB + 联盟协议 | 入盟 + 联邦执行 |
6.5 DAIMS 评分
参照 Data Assimilation and Information Management Standards（DAIMS）框架对 CLIF 的数据管理成熟度评估：
| 维度 | 评分 | 说明 |
|---|---|---|
| 可发现性（Findability） | 高 | 官网 + GitHub + PhysioNet + 论文多渠道可查；DOI（PhysioNet 参考实现）稳定可解析 |
| 可访问性（Accessibility） | 中 | 标准本体完全开放（Apache-2.0）；患者级数据需入盟，公开参考实现需 PhysioNet 凭证——非"一键下载" |
| 互操作性（Interoperability） | 高 | schema + mCIDE 受控词表 + 保留源标签，专为跨机构互操作设计；与 OMOP/CDE 体系有明确衔接 |
| 可复用性（Reusability） | 高 | 明确许可（Apache-2.0）、完整文档（数据字典/101/ETL 指南/DQA）、可执行工具链（clifpy/clifpy 等） |
| 治理（Governance） | 高 | Steering Committee + 表级 POC + 版本管理（git）+ mCIDE 扩词投票机制 |
| 版本管理 | 高 | git 版本控制；2.0.0→2.1.0→3.0 清晰版本链；变更日志 |
| 隐私保护 | 极高 | 联邦架构，患者级数据永不集中；各站点独立 IRB |
| 数据质量 | 高 | DQA Framework + 联盟统一 outlier ranges + 标准化脚本 |
综合定位：CLIF 是一个治理成熟、隐私设计先进、但数据获取门槛较高的多中心数据标准体系。它的"低可访问性"是隐私保护架构的必然代价，而非缺陷。
6.6 引用规范
- 标准本体：引用论文 Rojas JC, et al. Intensive Care Med. 2025;51(3):556-569（doi:10.1007/s00134-025-07848-7），注意同时引用更正函；
- 参考实现：引用 PhysioNet 条目（doi:10.13026/j481-g420）+ PhysioNet 平台标准引用；
- mCIDE 词表：引用对应版本的数据字典（当前 2.1.0）。
6.7 与 MIMIC-IV 获取流程的对比
| 环节 | MIMIC-IV | CLIF 参考实现（MIMIC-IV-Ext-CLIF） |
|---|---|---|
| 平台 | PhysioNet | PhysioNet |
| 访问级别 | Credentialed Access | Credentialed Access |
| 前置要求 | CITI 培训 + DUA | 同（MIMIC 派生同口径） |
| 内容 | MIMIC-IV 原始 schema | 转成 CLIF schema 的 14 表 |
| 获得后能做 | 用 MIMIC 原格式分析 | 用 CLIF 格式开发/测试代码 |
| 版本 | v3.1（作为转换源） | v1.1.0（CLIF 数据集版本） |
要点：如果你已经拥有 MIMIC-IV 访问权限，仍需单独申请 MIMIC-IV-Ext-CLIF——它是独立的 PhysioNet 资源条目，有独立 DOI。两者不自动互通。
6.8 谁适合走哪条路径
- 只想看/学格式：GitHub 取 CLIF 数据字典 + mCIDE Explorer，无需任何申请；
- 想开发代码但无机构数据：PhysioNet 申请 MIMIC-IV-Ext-CLIF（凭证访问），在 clifpy 上开发；
- 已有本地 ICU 数据、想接入联盟：走 ETL 管线（CLIF-MIMIC/C2D2/MEDS）把本地数据转 CLIF，联系联盟；
- 想主导多中心研究：成为联盟成员，用联邦架构分发代码。
这四条路径对应不同的角色与门槛，选错路径会浪费大量时间。
§7 生态与工具链
7.1 GitHub 组织（65 仓库）
CLIF 的全部开源资产集中在 GitHub Common-Longitudinal-ICU-data-Format 组织下：
核心文档
- CLIF：数据标准文档仓库（Jupyter Notebook，Star 23/Fork 10 抓取时点）；
- CLIF-Project-Template：项目仓库模板（R），规定一致的结构与协作规范。
工具
- clifpy：CLIF 数据交互 Python 包（Star 16/Fork 7）——操作 CLIF 数据的官方 Python 入口；
- CLIF_cohort_identifier：队列识别工具；
- CLIF-TableOne：从 CLIF 数据生成 Table 1（描述统计表）；
- CLIF Claude skills plugin：Claude 技能插件——把 LLM 接入 CLIF 工作流的尝试。
ETL 管线（把各家数据转成 CLIF）
- CLIF-MIMIC：MIMIC-IV → CLIF 的工作流（Jupyter Notebook，Star 13/Fork 20）；
- CLIF-C2D2：C2D2 数据源 → CLIF；
- CLIF-MEDS：MEDS 数据源 → CLIF。
项目仓库（40+ 具名研究项目）：ARF-NIV Treatment Location、Checkpoint Inhibitor–Associated Critical Illness Phenotyping、CAR-T Temperature Trajectory & Circadian Analysis、CLIFATRON、Clinical Implications of Sepsis Definitions、Code Status、Differential Severity (PaO2/FiO2 vs SpO2/FiO2)、Distinct Sedation Trajectories、Early Warning Score Validation in Oncology、Epidemiology of CRRT、Epidemiology of Sedation、Epidemiology of Vasopressor Escalation、FLAIR、FLAME-ICU、ICU Readmission、OHCA Detection/RL、Prolonged Respiratory Failure (ITRACH)、Sepsis Identification、SIPA、Temperature Trajectory Subphenotypes After CAR T-Cell Administration、Ventilation Variation 等。
7.2 官网资源区
- CLIF 101：入门课程（“Start your CLIF project”）；
- ETL Guide：数据转换指南；
- DQA Framework：数据质量评估框架；
- mCIDE Explorer：受控词表浏览器；
- Data Dictionary（2.1.0）：完整字段规格；
- Cohort Dashboard：联盟队列数据可视化；
- 3.0 Change Log：v3.0 变更日志。
7.3 治理结构
- Steering Committee：联席主席 + 三名 Vice-chair + 创始成员；
- Senior Advisory Committee：外部资深顾问（OHSU、Wisconsin-Madison、Minnesota、Johns Hopkins）；
- 表级 POC：每张 CLIF 表指派一位临床负责人（§3/§1 已列）；
- mCIDE 扩词机制：v3.0 开放的 expansion request period——研究者提新 permissible values、背书他人提案。
7.4 影响力与传播
CLIF 论文发表于 Intensive Care Medicine（重症医学顶刊），并进入该领域主流讨论；官网宣称"Research in top-tier journals"。联盟通过"分发分析代码"而非数据，使多中心研究从"以年计"缩短到"以周计"，这一范式对重症医学之外的多中心临床研究亦具借鉴意义。
7.5 工具链的使用顺序（给新手的路标）
面对 65 个仓库容易迷路。推荐按以下顺序上手：
- 读懂规范：
CLIF仓库的 README（含 ERD 与表级 POC 列表）→ 官网 Data Dictionary 2.1.0； - 跑通数据：
CLIF-Project-Template建项目骨架 → PhysioNet 取 MIMIC-IV-Ext-CLIF →clifpy载入操作； - 理解队列：
CLIF_cohort_identifier做队列筛选 →CLIF-TableOne出描述统计表； - 接入自有数据：按来源选 ETL——MIMIC 用
CLIF-MIMIC，C2D2 用CLIF-C2D2，MEDS 用CLIF-MEDS； - 扩展分析：参考 40+ 项目仓库里与己课题相近的一个作为模板。
7.6 与 FHIR / OMOP 的生态位
CLIF 在医疗数据标准生态中占据一个独特位置：
| 标准 | 目的 | 覆盖 | 与 CLIF 关系 |
|---|---|---|---|
| HL7 FHIR | 系统间数据交换 | 全医疗 | CLIF 尚未对接（论文自述局限） |
| OMOP CDM | 观察性研究通用模型 | 全 EHR | CLIF 的对照物（重症专用 vs 通用） |
| mCIDE/CDE | 精确定义数据元素 | 变量级 | CLIF 的内置机制 |
| MIMIC/eICU schema | 单库/多库数据本体 | ICU | CLIF 的输入/参照 |
CLIF 的差异化在于"重症专用 + 联邦执行 + 开源自建"。它不与 FHIR/OMOP 竞争，而是填补"ICU 领域跨机构研究"这一细分需求。
7.7 谁在推动：从机构到人
CLIF 的推动力量由三层人物构成，理解这张网络有助于找到合作入口：
- 治理层：联席主席（Ingraham、Gao）+ Vice-chairs + 创始成员（Parker、Rojas、Lyons）；
- 执行层：表级 POC（每张表一位临床负责人）+ 技术团队（Chaudhari、Chhikara、Liao 等）；
- 顾问层：Senior Advisory Committee（Hough、Afshar、Churpek、Dudley、Iwashyna 等重症与数据科学资深学者）。
联系入口统一为 clif_consortium@uchicago.edu。
§8 方法学启示：三条可迁移经验
8.1 代码出行，数据留家
CLIF 最根本的洞见是把"数据共享"问题重构为"结果共享"问题。传统多中心研究必须集中数据，从而触发冗长的 DUA、隐私合规与安全审查；CLIF 让代码在每个数据源本地执行，只回传聚合统计。这把隐私风险从"如何安全地移动敏感数据"降级为"如何确保聚合结果不泄露个体"——后者是更可控的问题。任何受隐私约束的多机构协作都可借鉴：移动计算而非移动数据。
8.2 标准化的代价要算清
标准化不是免费的。CLIF 用 mCIDE 换来跨站可比性，代价是：
- 站点必须投入 ETL 工程把本地异构数据映射到标准 schema；
- 标准词表的有限取值意味着部分临床细节被聚合或丢弃；
- 版本演进（2.0→2.1→3.0）要求站点持续维护映射。
CLIF 的应对是"双列结构"（_category 标准化 + _name 保真）与版本管理——既允许快速跨站分析，又保留回头精查原始标签的能力。这是标准化设计里一个可复制的平衡技巧。
8.3 双层入口降低参与门槛
CLIF 的"公开参考实现"（MIMIC-IV-Ext-CLIF）是一个精妙设计：它让没有机构数据的人能在真实规模的 CLIF 格式数据上开发、调试、验证代码，然后无缝升维到联盟真实多中心数据。这把"加入联盟"的门槛从"先有数据才能开发"降到"先用示例数据开发，代码成熟后再接数据"。任何数据平台都值得借鉴这种**“示例数据做跳板”**的策略。
8.4 治理先于技术
CLIF 的另一条隐性经验是：多中心数据协作的瓶颈往往不是技术，而是治理。CLIF 在技术之上建了完整的治理层——Steering Committee 决策、表级 POC 负责、Senior Advisory Committee 外部监督、mCIDE 众包扩词、版本管理与变更日志。正是这套治理机制让"统一的词表"和"统一的 schema"能真正被执行，而不是各行其是。技术标准若无治理，会迅速碎片化。
8.5 "标准"的价值曲线
CLIF 的采用存在明显的网络效应：参与站点越多，单站点接入的价值越大（可比较的队列越大、可复用的代码越多）。这解释了为什么 CLIF 从 8 个 health systems（2024）快速扩张到 13-17 个机构（2026）。对潜在采用者的启示是：早接入的边际收益递增——越早接入，越早积累可复用的分析资产，也越早影响标准的走向（mCIDE 扩词投票权）。
8.6 三条可迁移经验的边界
需要提醒的是，这三条经验都有适用边界：
- 移动代码的前提是分析可归约为"本地计算 + 聚合回传"，涉及需要个体级数据交互的算法（如某些深度学习训练）时联邦方案更复杂；
- 标准化的收益随参与方增加而出现，小规模协作（2-3 家）可能不值得建立完整标准；
- 示例数据跳板要求示例数据与真实数据同 schema——这恰是 CLIF 的参考实现严格遵循 CLIF 格式的原因。
§9 与库内条目的关系
9.1 家族图谱
- MIMIC-IV Clinical Database（rid 4）/ mimiciv（rid 592）/ mimic-iii（rid 106）：最直接互链。CLIF 官方的公开参考实现 MIMIC-IV-Ext-CLIF 正是从 MIMIC-IV v3.1 转换而来，CLIF-MIMIC 工具仓库即转换管线。区别在于层次：MIMIC 是单中心成品数据本体（可下载），CLIF 是跨机构格式标准（schema）。两者是"标准 × 被标准化对象"的关系。
- eICU-CRD（rid 552）/ eicu-collaborative（rid 9）：多中心 ICU 研究的范式对照组。eICU-CRD 是"集中式多中心数据发布"（2014-2015 美国 ICU，聚合后统一发布），CLIF 是"数据不出院、代码跨站跑"的联邦标准。二者代表多中心 ICU 数据共享的两条技术路线——集中 vs 联邦，是理解 CLIF 独特性的最佳参照。
- HiRID（rid 7）：伯尔尼单中心高分辨率 ICU 数据。与 CLIF 一样关注 ICU 细粒度时序，但为单中心；可作 CLIF 格式潜在转换源（CLIF 生态有 CLIF-C2D2 等非 MIMIC 管线，体现标准的多源性）。
- NWICU（rid 146）：Northwestern ICU 数据库——与 CLIF 领导机构 Northwestern（Catherine Gao 任联席主席）同源，是 CLIF 联盟成员机构的数据资源。
- ehrshot（rid 11）：MIMIC-IV 派生的 EHR 少样本基准。与 MIMIC-IV-Ext-CLIF 同属"从 MIMIC-IV 派生的可复用资产"，但目的不同（少样本评测 vs 格式参考）。
- MIMIC-IV-ED（rid 116 / 567）：MIMIC-IV 急诊模块。CLIF 的总体目标（Overarching Goal）明确要覆盖"从 ICU 到急诊科、到病房"的全流程——与急诊模块形成"标准 × 场景"互链。
- MIMIC-IV-Note（rid 47）/ MIMIC-IV-Waveform（rid 65）/ MIMIC-IV-ECG（rid 172）：MIMIC-IV 的文本与波形模态。CLIF v3.0 新增影像与临床笔记后，与这些模态条目形成"多模态格式标准 × 多模态数据"互链。
- Chinese Critical Care Database（rid 166）/ Zhejiang EHR Critical Care（rid 598）：中国 ICU 数据库。作为非美国的多中心/单中心 ICU 数据，与 CLIF（北美联盟）形成地域互链，也是"中国 ICU 数据能否/是否需要 CLIF 式标准化"的讨论参照。
- Phenotype Annotations MIMIC（rid 594）/ Nosocomial Risk MIMIC（rid 593）：MIMIC 表型注释类数据集。与 CLIF 的 mCIDE 受控词表/表型定义形成方法论互链——如何在标准化数据上定义可复现的临床表型。
9.1.1 库内 ICU 生态全景标注
为便于检索，把库内主要 ICU/重症相关条目按"与 CLIF 的关系类型"归类：
A. 直接上游/下游（强互链）
- MIMIC-IV Clinical Database（rid 4）、mimiciv（rid 592）——CLIF 参考实现的转换来源；
- MIMIC-III（rid 106）、mimiciii（rid 590）、mimiciii-demo（rid 591）——上一代 MIMIC，同源谱系。
B. 多中心范式对照（强互链）
- eICU-CRD（rid 552）、eicu-collaborative（rid 9）——集中式多中心 vs CLIF 联邦式。
C. 单中心/区域 ICU 数据（中互链）
- HiRID（rid 7，伯尔尼）、NWICU（rid 146，Northwestern）、Chinese Critical Care Database（rid 166）、Zhejiang EHR Critical Care（rid 598）。
D. MIMIC 派生资产（中互链）
- MIMIC-IV-ED（rid 116/567）、MIMIC-IV-Note（rid 47）、MIMIC-IV-Waveform（rid 65）、MIMIC-IV-ECG（rid 172）、MIMIC-CXR（rid 16 / 617 / 616）、ehrshot（rid 11）、MIMIC-BR（rid 156）、MIMICEL（rid 589）。
E. 表型/基准类（弱-中互链）
- Phenotype Annotations MIMIC（rid 594）、Nosocomial Risk MIMIC（rid 593）、Stroke Scale MIMIC-III（rid 596）、Synthetic MIMIC-III Health Gym（rid 597）、Chest-CT-Sepsis-ER（rid 600）。
9.1.2 一个"用 CLIF 打通库内多条目"的研究设想
假设你想研究"ICU 获得性脓毒症的跨机构异质性"，库内条目可这样协同：
- 用 CLIF-MIMIC 把 MIMIC-IV（rid 4） 转成 CLIF 格式，作为方法验证数据（对应 PhysioNet 参考实现）；
- 用 mCIDE 定义的 sepsis 相关元素（GitHub 有 Sepsis Identification 项目）统一表型定义；
- 参照 eICU-CRD（rid 552） 的脓毒症队列做外部对照（集中式多中心）；
- 用 Nosocomial Risk MIMIC（rid 593） 的院感风险标签交叉验证；
- 最终把代码升维到 CLIF 联盟真实多站点数据。
这个设想展示了 CLIF 作为"格式枢纽"连接库内多条目的可能性。
9.2 检索路径建议
- 精确检索词：“CLIF” + “critical care” / “Common Longitudinal ICU data Format”；避免与 “Cliff”（人名/其他缩写）、“CLIF bar”（能量棒品牌）混淆。
- 要先跑通代码：PhysioNet 取 MIMIC-IV-Ext-CLIF（凭证访问）→ GitHub 取 clifpy + CLIF-Project-Template → 官网 CLIF 101。
- 要看规范：GitHub
Common-Longitudinal-ICU-data-Format/CLIF（数据字典）+ 官网 Data Dictionary 2.1.0 + mCIDE Explorer。 - 要引用规模：先确认口径——论文用 111,440（2020-2021 队列，9 systems/39 hospitals），官网用 939,328（累计，13 机构/67 医院），别混用。
§10 避坑清单：十二个已踩过的坑
坑 1：CLIF 不是一个能下载的数据集。 最常见的误解是把它当"下一个 MIMIC"去找下载链接。它不是——CLIF 是数据格式标准 + 联邦联盟，患者级数据不集中、不公开。你唯一能公开下载的"CLIF 数据"是 MIMIC-IV-Ext-CLIF（PhysioNet 凭证访问）。
坑 2：规模数字三口径，别混用。 94,356（预印本 2024-09）/ 111,440（正式论文 2025-03）/ 939,328（官网 2026-09）是三个不同口径：前两者是 2020-2021 队列纳入规模（含修订），后者是联盟累计格式化全量。把 111,440 和 939,328 当同一个量引用会严重误导。
坑 3：论文与更正函成对，别漏引或误读为两篇。 主论文 PMID 40080116（Intensive Care Med 2025;51(3):556-569，doi:10.1007/s00134-025-07848-7）配一份更正函 PMID 40163136（51(4):836-839，doi:10.1007/s00134-025-07869-2）。搜索引擎曾把二者并列呈现，易误读为两篇独立研究——实为"主论文 + Correction"。
坑 4：官网自己三个页面数字打架。 首页 hero 写 “13 institutions / 67 hospitals / 16 Sites”，About 页写 “17 institutions and 63 hospitals”，Team 页写 “17 institutions”。同一官网内部不一致，疑为不同时点静态文案未同步。引用机构/医院数时必须注明来源页面与时点。
坑 5：表数口径 23 vs 22 vs 14。 论文预印本图注计 23 张表，期刊版图注计 22 张（同一 v1.0 ERD 的计数差异）；公开参考实现 MIMIC-IV-Ext-CLIF 只含 14 张（+1 补充表）。三者不矛盾——完整 schema（23/22）是标准的全集，14 是单个数据源能映射出的子集。别用 14 去质疑 23"不存在"。
坑 6：名称大小写/展开式变体不是两个东西。 GitHub README “Common Longitudinal ICU data Format” vs 论文 “A Common Longitudinal Intensive Care Unit data Format”——同一标准。检索时两种写法都要试。
坑 7：MIMIC-IV-Ext-CLIF 的版本号 ≠ CLIF 标准版本号。 PhysioNet 数据集版本是 1.1.0，而它指路的数据字典是 CLIF 2.1.0。这是两套独立编号（数据集发布版本 vs 标准规范版本），不要以为"数据集 1.1.0 说明 CLIF 还是 1.x"。
坑 8：关联键口径在版本间演进。 论文预印本图注写主要关联键是 encounter_id，期刊版图注改写作 hospitalization_id，而实际落地数据集（MIMIC-IV-Ext-CLIF）以 patient_id + hospitalization_id 关联。写跨表查询前先查当前版本数据字典，别照搬某一版图注。
坑 9：官网 GitHub Pages 镜像可能连不上。 clif-consortium.github.io/website/ 与 clif-icu.com 是同一官网的两个入口。2026-09-28 抓取时 GitHub Pages 版 SSL 握手失败（curl exit 35），clif-icu.com 正常。检索与引用优先用 clif-icu.com。
坑 10：v3.0 的"多模态"不是回填。 CLIF v3.0（2026-07）新增影像与临床笔记表，指的是标准新增了这些表类型；不等于所有站点的历史数据都有影像/笔记。用某站点数据前需确认该站点实际映射了哪些表。
坑 11：mCIDE 是"最小"而非"完整"。 mCIDE 的 M 是 minimum——它保证跨站可比的关键变量，但不覆盖全部临床细节。若研究需要 mCIDE 之外的变量，需回到 _name 原始标签层或源 EHR，别假设 CLIF 有你要的一切。
坑 12：别把"联盟体量"当"可用样本量"。 官网 939,328 患者是累计格式化体量；任何具体研究的可用样本取决于纳入标准、站点参与情况与表映射完备度，通常远小于该数。研究设计时以"实际可参与者"为准。
10.1 一页避坑决策树
你要用 CLIF 做什么？
├─ 只学格式 → GitHub 数据字典 + mCIDE Explorer（无需申请）
├─ 开发代码 → PhysioNet 取 MIMIC-IV-Ext-CLIF（凭证访问）
└─ 多中心研究
├─ 已有本地 ICU 数据 → 选 ETL（CLIF-MIMIC/C2D2/MEDS）→ 联系联盟
└─ 想要联盟数据 → 入盟申请 → 联邦执行（数据不出院）
引用时：
├─ 规模 → 论文口径(111,440) 还是官网口径(939,328)？二选一，注明
├─ 论文 → 主论文 + 更正函成对
└─ 机构数 → 注明来源页面（首页/About/Team 不一致）
§11 总结
11.1 三句话总结
- CLIF 是专为重症监护设计的开源数据标准 + 联邦研究联盟：统一 schema 与 mCIDE 词表让多机构数据"说同一种话"，联邦架构让患者数据永不出院。
- 它的公开可及部分是标准规范（Apache-2.0） 与 MIMIC-IV-Ext-CLIF 参考实现（PhysioNet 凭证访问）；真实多机构数据需入盟并走联邦执行。
- 它验证了"移动代码而非移动数据"的多中心研究范式——两个概念验证研究（死亡率模型外部验证、体温轨迹分型）证明这条路径可行且能产出临床发现。
11.2 适合谁
- 做多中心 ICU 研究、苦于数据共享合规的团队：CLIF 提供了可落地的联邦技术方案与现成工具链。
- 想用 CLIF 标准开发分析代码的研究者：MIMIC-IV-Ext-CLIF 参考实现可开箱开发，代码可无缝升维到联盟数据。
- 临床数据工程师：ETL 管线（CLIF-MIMIC/C2D2/MEDS）、mCIDE 词表、DQA 框架有直接的工程参考价值。
- 医疗数据标准制定者：CLIF 是"领域专用 CDM vs 通用 CDM（OMOP）"的一个成功案例研究。
11.3 不适合谁
- 只想下载大规模 ICU 数据直接训练模型的团队：CLIF 本体数据不公开，MIMIC-IV-Ext-CLIF 也需凭证访问——请直接用 MIMIC-IV、eICU-CRD。
- 需要患者级多机构真实分布的分析：联邦架构只回传聚合结果，做不了集中式个体级建模。
- 需要临床文本/影像的（2025 之前）：结构化数据为主；v3.0（2026-07）才开始纳入影像与笔记，早期版本无多模态支持。
11.4 30 秒决策卡
| 你的情况 | 行动 |
|---|---|
| 要立刻下载 ICU 数据 | 去 MIMIC-IV（rid 4）/ eICU-CRD（rid 552），不是 CLIF |
| 要做多中心联邦研究 | 联系 clif_consortium@uchicago.edu 入盟；先读官网 Governance |
| 要用 CLIF 标准开发代码 | PhysioNet 取 MIMIC-IV-Ext-CLIF + GitHub 取 clifpy（§6） |
| 要看数据规范 | GitHub Common-Longitudinal-ICU-data-Format/CLIF + 官网 Data Dictionary 2.1.0 |
| 要引用 CLIF 论文 | Intensive Care Med 2025;51(3):556-569，doi:10.1007/s00134-025-07848-7（+更正函） |
| 要引用规模 | 论文口径 111,440（9 systems/39 hospitals）或官网口径 939,328（13 机构/67 医院）——注明口径 |
11.5 本条目的一句话定位
CLIF 不是一个你要"下载"的数据集，而是一套你要"加入"或"采用"的 ICU 数据基础设施。 它的价值不在数据量（虽然联盟累计患者已近百万），而在让多机构 ICU 数据在不移动患者数据的前提下协同分析——这是重症医学乃至整个临床研究在隐私约束时代的一条关键路径。
11.6 三条最该记住的事实
- CLIF = 标准 + 联盟，不是可下载数据集；公开可及的是 Apache-2.0 的规范与 PhysioNet 凭证访问的参考实现；
- 联邦架构是灵魂——“代码出行，数据留家”，患者级数据永不跨站；
- 规模数字多口径——论文 111,440（2020-2021 队列）vs 官网 939,328（累计），引用必标口径。
11.6.1 与库内最易混淆条目的三句话区分
- 对 MIMIC-IV：MIMIC 是数据，CLIF 是格式——CLIF 的公开样板就是把 MIMIC-IV 转成 CLIF 格式。
- 对 eICU-CRD：eICU 集中发布多中心数据，CLIF 让多中心数据留在原地——集中式 vs 联邦式两种范式。
- 对 HiRID/NWICU：它们是单中心的 ICU 数据本体，CLIF 是跨机构的数据标准——层次不同，不构成重复。
11.7 一个判断：CLIF 会不会成为 ICU 数据的"通用语言"？
从趋势看有三点支撑：① 参与机构从 8 个 health systems（2024）扩到 13-17 个（2026）；② 公开参考实现降低了新人门槛；③ v3.0 的"多模态化"让它跟上基础模型时代的需要。制约因素同样存在：④ 与 FHIR 尚未打通（论文自述局限）；⑤ 实施门槛对小机构偏高；⑥ 数据不公开使外部研究者只能"用格式"不能"用全量数据"。短期内 CLIF 更像"联盟内的通用语"，而非"全球 ICU 数据的唯一标准"——但它为"联邦式临床研究"提供了可复制的范本。
留给读者的判断点：若 CLIF 未来实现论文所愿——发布去标识化的公开数据版本——它将同时具备"标准"与"数据"双重吸引力，届时很可能成为 ICU 领域事实上的通用格式；若止步于联盟内部，则更可能作为一个成功但局部的协作范式被引用。这个岔路口，取决于各 health system 领导层是否愿意像 MIMIC 那样投入公开数据的成本。
附录清单
附录 T — 术语速查表
| 缩写 | 全称 | 含义 |
|---|---|---|
| CLIF | Common Longitudinal ICU data Format | 通用纵向重症监护数据格式（本条目主题） |
| mCIDE | minimum Common ICU Data Elements | 最小通用 ICU 数据元素（CLIF 的受控词表机制） |
| CDE | Common Data Elements | 通用数据元素（NIH 定义，mCIDE 的上位概念） |
| CDM | Common Data Model | 通用数据模型（如 OMOP） |
| OMOP | Observational Medical Outcomes Partnership | 观察性医疗结果合作组织通用数据模型 |
| FHIR | Fast Healthcare Interoperability Resources | HL7 的医疗数据互操作性标准 |
| ADT | Admission–Discharge–Transfer | 入出转（患者院内地点移动） |
| EDW | Electronic Data Warehouse | 电子数据仓库 |
| ETL | Extract–Transform–Load | 数据抽取-转换-加载（把源数据转成 CLIF 的管线） |
| ECMO | Extracorporeal Membrane Oxygenation | 体外膜肺氧合 |
| MCS | Mechanical Circulatory Support | 机械循环支持 |
| CRRT | Continuous Renal Replacement Therapy | 连续性肾脏替代治疗 |
| GBTM | Group-Based Trajectory Modeling | 基于组的轨迹模型（体温亚型识别用） |
| GCS | Glasgow Coma Scale | 格拉斯哥昏迷量表 |
| AUC | Area Under the ROC Curve | ROC 曲线下面积（区分度指标） |
| NT / HT / HFR / HSR | normo-/hypo-/hyperthermic fast/slow resolver | 体温轨迹四亚型 |
| DUA | Data Use Agreement | 数据使用协议 |
| IRB | Institutional Review Board | 机构审查委员会（伦理审批） |
| DQA | Data Quality Assessment | 数据质量评估 |
| POC | Point of Contact | 表级负责人 |
附录 C — 版本链与时间线
| 时间 | 事件 |
|---|---|
| 2023-07 | 联盟组建启动（线上集结美国临床与数据科学家） |
| 2023-2024 | 挑战识别、规范制定、质控方法建立 |
| 2024-09-04 | medRxiv 预印本发布（94,356 patients / 8 systems / 33 hospitals） |
| 2025-03 | Intensive Care Med 正式论文发表（111,440 admissions / 9 systems / 39 hospitals）+ 更正函 |
| 2026-03-23 | MIMIC-IV-Ext-CLIF 上 PhysioNet（v1.1.0，doi:10.13026/j481-g420） |
| 2026-07 | CLIF v3.0 发布（Going Multimodal：影像 + 临床笔记） |
| 2026-09 | 官网口径 939,328 患者 / 67 医院 / 13 机构；mCIDE v3.0 扩词投票中 |
| 版本 | CLIF 2.0.0（论文）→ 2.1.0（当前数据字典）→ 3.0（多模态） |
附录 S — 规模口径对照卡
| 口径 | 数字 | 机构 | 医院 | 时点/说明 |
|---|---|---|---|---|
| 预印本 | 94,356 patients | 8 health systems | 33 | 2024-09，2020-2021 队列 |
| 正式论文 | 111,440 admissions | 9 health systems | 39 | 2025-03，2020-2021 队列（含更正） |
| 官网 About 时间线 | 808K+ patients / 1.03M hospitalizations | 18+ institutions | — | 2025 节点 |
| 官网首页 | 939,328 patients | 13 institutions（16 Sites） | 67 | 2026-09，累计全量 |
使用规则：引用"研究队列规模"用论文口径；引用"联盟体量"用官网口径；永不混用。
附录 L — 许可与获取三层速查
| 资产 | 许可 | 获取 |
|---|---|---|
| schema / mCIDE / 工具 / 分析代码 | Apache-2.0 | GitHub 公开即取 |
| MIMIC-IV-Ext-CLIF | PhysioNet 凭证许可（MIMIC 派生） | PhysioNet 认证 + DUA |
| 联盟站点真实数据 | 各机构 IRB + 联盟协议 | 入盟 + 联邦执行 |
| 官方论文 | 期刊版权（有更正函） | Intensive Care Med / PMC |
附录 W — 引用信息（BibTeX）
@article{rojas_clif_2025, title = {A common longitudinal intensive care unit data format ({CLIF}) for critical illness research}, volume = {51}, number = {3}, pages = {556--569}, doi = {10.1007/s00134-025-07848-7}, journal = {Intensive Care Medicine}, year = {2025}, author = {Rojas, Juan C. and Lyons, Patrick G. and Chhikara, Kaveri and others} } @misc{liao_mimic_iv_ext_clif_2026, title = {{MIMIC-IV-Ext-CLIF}: {MIMIC-IV} in the Common Longitudinal ICU data Format ({CLIF})}, doi = {10.13026/j481-g420}, version = {1.1.0}, publisher = {PhysioNet}, year = {2026}, author = {Liao, Zewei and Guleria, Shan and Smith, Kevin and others} }
附录 A — 关键来源 URL
- 官网：https://clif-icu.com/
- 官网 GitHub Pages 镜像：https://clif-consortium.github.io/website/
- GitHub 组织：https://github.com/Common-Longitudinal-ICU-data-Format
- 数据标准文档：https://github.com/Common-Longitudinal-ICU-data-Format/CLIF
- PhysioNet 参考实现：https://physionet.org/content/mimic-iv-ext-clif/
- 主论文 DOI：https://doi.org/10.1007/s00134-025-07848-7
- 更正函 DOI：https://doi.org/10.1007/s00134-025-07869-2
- 预印本 DOI：https://doi.org/10.1101/2024.09.04.24313058
- 联络邮箱：clif_consortium@uchicago.edu
FAQ（高频问答 50 问）
A. 基础认知
Q1：CLIF 是什么的缩写？
Common Longitudinal ICU data Format（通用纵向重症监护数据格式）；论文展开式为 “A Common Longitudinal Intensive Care Unit data Format”。CLIF = Common Longitudinal ICU Format。
Q2：它是数据集还是标准？
标准 + 联盟。一套开源关系型数据库 schema + mCIDE 受控词表 + ETL/分析工具，配套跨机构联邦研究联盟。不是一份可下载的患者数据。
Q3：谁做的、什么时候？
CLIF Consortium，2023 年 7 月组建，University of Chicago 牵头。联席主席 Nicholas Ingraham（Minnesota）/ Catherine Gao（Northwestern），创始执行主任 William Parker（UChicago）。
Q4：规模多大？
官网 2026-09-28 口径：939,328 患者 / 67 医院 / 13 机构（“16 Sites、13 Active Sites”）。论文口径（2020-2021 队列）：111,440 例入院 / 9 systems / 39 hospitals。两个口径不同。
Q5：发表在哪里？
Intensive Care Medicine 2025;51(3):556-569，doi:10.1007/s00134-025-07848-7，PMID 40080116。另有预印本 medRxiv（2024-09，doi:10.1101/2024.09.04.24313058）与一份更正函（doi:10.1007/s00134-025-07869-2）。
Q6：CLIF 和 OMOP 什么关系？
理念相关但定位不同。OMOP 是覆盖全 EHR 的通用 CDM（偏行政/计费），CLIF 是重症专用轻量标准，强调照护过程、结局与细粒度生理测量，并保留源标签（_name）。CLIF 承认 OMOP 的标准化价值，但指出其对 ICU 研究需大量工程投入且损失颗粒度。
Q7：CLIF 和 MIMIC 什么关系？
互补。MIMIC 是单中心成品数据体，CLIF 是跨机构格式标准。CLIF 甚至把 MIMIC-IV v3.1 转成自己的格式当公开参考实现（MIMIC-IV-Ext-CLIF）——正是"标准 × 被标准化对象"的关系。
Q8：CLIF 和 eICU-CRD 什么关系？
多中心 ICU 数据共享的两条路线：eICU-CRD 是集中式多中心数据发布，CLIF 是联邦式（数据不出院、代码跨站跑）。强对照条目。
B. 数据与 schema
Q9：schema 有多少张表？
论文 v1.0 ERD 计 23 张（期刊版图注 22 张）。公开参考实现 MIMIC-IV-Ext-CLIF 含 14 张（+1 补充表）——是完整 schema 的子集。
Q10：表怎么关联？
论文预印本图注写 encounter_id，期刊版写 hospitalization_id；实际数据集以 patient_id + hospitalization_id 关联。锚表是 patient / hospitalization / adt。
Q11：mCIDE 是什么？
minimum Common ICU Data Elements（最小通用 ICU 数据元素）。每表一组，以 _category 后缀承载标准字段（有限允许值），同时用 _name 保留源 EHR 原始标签。
Q12：为什么保留原始标签？
质控与回溯。标准化字段（_category）供跨站分析，原始标签（_name）供核查映射是否正确。论文称此结构"在创建标准元素的同时保留原始标签以供质量控制"。
Q13：有哪些自创的 mCIDE 元素？
例如机械通气模式（mode_category）——通用术语体系里缺乏适配定义，由联盟临床专家新造。
Q14：数据是纵向的吗？
是。“Longitudinal” 是名字的核心——表设计强调时间粒度，事件带精确时间戳，可还原 ICU 停留全过程。
C. 获取与许可
Q15：我能下载 CLIF 数据吗？
不能直接下载联盟数据（联邦架构，不集中）。能公开获取的是标准本体（Apache-2.0，GitHub）与 MIMIC-IV-Ext-CLIF 参考实现（PhysioNet 凭证访问）。
Q16：MIMIC-IV-Ext-CLIF 怎么拿？
PhysioNet（https://physionet.org/content/mimic-iv-ext-clif/），需完成凭证访问认证（CITI 培训 + DUA）。doi:10.13026/j481-g420，版本 1.1.0。
Q17：许可是什么？
三层：标准本体 Apache-2.0（宽松、可商用）；联盟站点数据不公开（各机构 IRB）；MIMIC-IV-Ext-CLIF 走 PhysioNet 凭证许可（MIMIC 派生）。别一揽子说"CLIF 开源可商用"——开源的只是标准。
Q18：怎么加入联盟？
邮件 clif_consortium@uchicago.edu，走官网 Governance 流程，各站点需独立 IRB 批准。
Q19：有 API 吗？
有 Python 包 clifpy（GitHub），是操作 CLIF 数据的官方 Python 入口；另有 CLIF_cohort_identifier、CLIF-TableOne 等工具。
D. 使用场景
Q20：我想开发多中心 ICU 模型，怎么用 CLIF？
先用 MIMIC-IV-Ext-CLIF 开发/测试代码（无机构 EHR 权限也能做），代码成熟后通过联盟分发到各站点本地执行，回收集合结果。
Q21：联邦架构下我怎么调试？
这就是参考实现的价值——在 MIMIC-IV-Ext-CLIF 上完整调试，逻辑确认后再上联盟数据。
Q22：CLIF 能做什么类型的研究？
论文演示了模型外部验证与亚表型发现；GitHub 上有 40+ 项目覆盖呼吸衰竭、脓毒症、CRRT、镇静轨迹、心脏骤停、CAR-T 等。
Q23：CLIF v3.0 加了什么？
影像（imaging）与临床笔记（clinical notes）——从结构化数据标准迈向多模态重症数据标准（2026-07 发布）。
Q24：v2.1.0 和 v3.0 该用哪个？
看需求：结构化 ICU 分析用 2.1.0（当前数据字典版本，也是 MIMIC-IV-Ext-CLIF 指路版本）；需要文本/影像用 v3.0。
E. 常见误解
Q25：CLIF 是"重症版 FiHR"吗？
不是。FHIR 是通用的医疗数据交换标准（面向系统间互操作），CLIF 是研究用的重症领域数据仓库 schema（面向跨机构分析复用）。目的与技术路线不同。
Q26：CLIF 数据是不是都在 PhysioNet？
不是。PhysioNet 上只有 MIMIC-IV-Ext-CLIF 这一份参考实现；联盟真实数据在各机构本地，永不上传。
Q27：为什么官网机构数字前后不一？
疑为不同时点静态文案未同步（首页 13 机构 vs About 17 机构）。引用时注明来源页面与时点（坑 4）。
Q28：论文有两个 PMID，是两篇论文吗？
不是。40080116 是主论文，40163136 是它的更正函（Correction），成对存在（坑 3）。
Q29：mCIDE 和 CDE 什么关系？
mCIDE 是 CDE 概念在 ICU 场景的具体化：每个 mCIDE 是一个精确定义、有限取值的临床数据元素，尽量采用 NIH 背书的 CDE，必要时自创。
Q30：CLIF 会取代 MIMIC/eICU 吗？
不会，也不打算。它们是互补的：MIMIC/eICU 提供数据本体，CLIF 提供让多机构数据协同分析的格式与架构。CLIF 的价值恰恰建立在 MIMIC 等数据源之上。
F. 进阶与辨析
Q31：CLIF 和联邦学习（federated learning）是一回事吗？
不完全是。CLIF 是数据格式标准 + 联邦分析架构；联邦学习是一种具体的分布式建模技术。CLIF 论文的下一步正是"用去中心化联邦学习在整个联盟训练模型"——即 CLIF 提供数据/执行基础，联邦学习是运行在其上的一种方法。目前 CLIF 的两个案例主要是"分发代码 + 回收集合结果"，属联邦分析（federated analytics），尚未全面进入联邦学习。
Q32：CLIF 的数据颗粒度比 MIMIC 高还是低？
不好一概而论。CLIF 是标准化子集——它精选 ICU 研究最需要的变量并统一词表，因此某些字段的粒度可能不如源 EHR 原始数据；但它通过 _name 保留源标签、通过纵向设计保住时间粒度。论点是：用可控的粒度损失换取跨机构可比性。
Q33：CLIF 支持儿童 ICU（PICU）吗？
论文与公开材料聚焦成人 ICU（队列纳入标准明确为 ≥18 岁）。儿科是否覆盖需查最新数据字典/联系联盟。
Q34：CLIF 的数据有去标识吗？
各站点数据在本地按其 IRB 与合规要求处理；公开参考实现 MIMIC-IV-Ext-CLIF 源自已去标识的 MIMIC-IV。联邦架构下无需跨站共享原始数据，本身即是隐私保护设计。
Q35：为什么参考实现选 MIMIC-IV 而不是 eICU？
MIMIC-IV 是单中心但颗粒度极细的公开数据，适合作"格式参考"。eICU 是多中心但颗粒度较粗。参考实现的目标是"让人能在真实数据上学 CLIF 格式"，MIMIC-IV 更合适。CLIF 生态另有 CLIF-C2D2、CLIF-MEDS 等对接其他源的管线。
Q36：CLIF 的 schema 是固定的吗？
不是。它用 git 版本控制，从 2.0.0 演进到 2.1.0、3.0，每版有变更日志。3.0 还加入了影像与临床笔记。采用者需跟踪版本。
Q37：“encounter” 和 “hospitalization” 有什么区别？
encounter（就诊）通常指一次医疗服务接触，hospitalization（住院）指一次住院。论文 v1.0 图注用 encounter_id 关联，后续版本转而以 hospitalization_id 为主键——反映了模型对"分析单元"定义的明确化。
Q38：CLIF 能用于非 ICU 场景吗？
设计目标是"覆盖危重症始发的一切场景"（官网 Overarching Goal：从 ICU 到急诊到病房），但核心表与词表为 ICU 优化。用于普通病房需评估适配度。
Q39：physionet 的 CLIF 参考实现数据量多大？
公开材料未给出精确体积；内容为 14 张 CLIF 表 + 1 补充表的 Parquet 文件（源自 MIMIC-IV v3.1 的 ICU 相关子集）。实际体积取决于 MIMIC-IV v3.1 的 ICU 子集规模。
Q40：CLIF 的名字里为什么没有"consortium"？
CLIF 指格式标准（Common Longitudinal ICU data Format），"CLIF Consortium"指使用该标准的联盟。二者一个指标准、一个指组织，日常简称都叫 “CLIF”，需按语境区分。
Q41：如果我只想引用"CLIF 这个概念"，引什么？
引主论文 Rojas et al. Intensive Care Med 2025;51(3):556-569（注意配套更正函），以及官网 clif-icu.com。若要引用具体数据，再引 PhysioNet 参考实现。
Q42：CLIF 和"通用数据元素（CDE）"是什么关系？
CLIF 的 mCIDE 是 CDE 概念在 ICU 场景的落地：尽量采用 NIH 背书的 CDE，不足处自创。可以说 mCIDE ⊂ 重症领域的 CDE 实践。
Q43：为什么 CLIF 要做"镜像"在 GitHub Pages？
clif-icu.com 与 clif-consortium.github.io/website/ 是同一官网的两个入口（后者为 GitHub Pages）。2026-09-28 抓取时 GitHub Pages 版 SSL 握手失败，clif-icu.com 正常——检索时优先用 clif-icu.com（坑 7）。
Q44：CLIF 的门槛对小型机构友好吗？
中等。论文承认实施需要"大量数据科学与重症专业知识"，这也是联盟开发自动化 ETL 工具（CLIF-MIMIC/C2D2/MEDS、clifpy）的原因。小型机构可先从参考实现学起，再用工具降低接入成本。
Q45：CLIF 有没有商业许可问题？
标准本体 Apache-2.0 允许商业使用与修改（需保留声明）；数据层面——联盟数据不公开（无商业分发问题），参考实现受 PhysioNet 凭证许可约束（非商业/受限用途，详见其 DUA）。引用"CLIF 开源可商用"时务必区分标准与数据。
G. 收尾问答
Q46：一个完全的新手，第一小时该做什么？
读本条目 §0 与 §1 → 打开 GitHub Common-Longitudinal-ICU-data-Format/CLIF 的 README 看图 1 ERD → 打开官网 Data Dictionary 2.1.0 随便看一张表（建议 vitals）→ 明白"锚表 + 纵向事件表 + mCIDE 双列"三件事。这一小时的目标是建立心智模型，不是动手。
Q47：什么时候该放弃 CLIF 改用别的？
若你只需要单中心数据分析（直接用 MIMIC-IV）；若你只需要集中式多中心数据（用 eICU-CRD）；若你的研究需要患者级原始多机构数据做个体建模（联邦架构不适合）；若你需要的是文本/影像为主且不需跨机构标准化（直接找对应模态数据集）。
Q48：CLIF 最容易被误用的地方？
把"标准开源"误解为"数据开源"，进而以为能下载联盟全量数据——这是最常见的错误。其次是混用规模数字口径。第三是忽略版本差异（2.1.0 vs 3.0 的表结构不同）。
Q49：本条目与该领域未来趋势的关系？
CLIF 代表的"联邦数据标准 + 隐私保护协作"是临床研究基础设施的一个重要方向。随着监管趋严与跨机构研究需求增长，这类方案的重要性只会上升。关注 CLIF 的版本演进（尤其是 v3.0 多模态与 FHIR 对接进展）可观察这一方向的实际落地。
Q50：如果只记一句话？
CLIF = 重症数据的普通话 + 联邦协作的规则书；它不开源数据，但开源让数据能一起说话的方法。
本条目为 AI-Ready Dataset 百科（千方病案医数集）第 clif 号条目，事实核验时点 2026-09-28；所有规模数字与版本信息均标注来源与时点，冲突处见 §10 存照。
相关数据集导航
以下为站内 AI-Ready 数据集百科中与本词条共享多个主题标签的相关数据集，按相关度降序排列：
- mimic-iv-clinical-database — 共享标签：电子健康记录 / 重症监护 / 时序数据 / 多模态
- mimic-iii — 共享标签：电子健康记录 / 重症监护 / 时序数据 / 评测基准
- cinc-2019 — 共享标签：电子健康记录 / 重症监护 / 时序数据 / 评测基准
- cinc-2012 — 共享标签：电子健康记录 / 重症监护 / 时序数据 / 评测基准
- ehrshot — 共享标签：电子健康记录 / 时序数据 / 评测基准
- chronic-kidney-disease-uci — 共享标签：电子健康记录 / 队列研究 / 评测基准
- hirid — 共享标签：电子健康记录 / 重症监护 / 时序数据
- eicu-collaborative — 共享标签：电子健康记录 / 重症监护 / 时序数据
- mimic-iv-ed — 共享标签：电子健康记录 / 重症监护 / 时序数据
- mimic-iv-ed — 共享标签：电子健康记录 / 重症监护 / 时序数据
导航说明：本章节由全站统一标签体系自动计算生成（标签重合度算法），双向可达；点击链接可跳转至对应数据集词条。
