Name: eICU Collaborative Research Database
Creator: Philips Healthcare & MIT Laboratory for Computational Physiology

信息速览

数据集名称eICU-CRD — 多中心远程重症监护数据库 AI-Ready Wikipedia

数据类型200,859 次 ICU 单元停留,139,367 名患者,208 家医院,335 个 ICU 单元,约 3.6 GB CSV,CITI 培训 + DUA 凭证获取

规模约 13.9 万名独立患者（200,859 次 ICU 单元停留）

接入方式Philips Healthcare & MIT Laboratory for Computational Physiology（PhysioNet 托管） url: https://physionet.org/content/eicu-crd/

AI 就绪度

eICU-CRD — 多中心远程重症监护数据库 AI-Ready Wikipedia

INFOBOX


数据集名称
—	—
数据集名称	eICU Collaborative Research Database
*英文全称 Research Database
英文全称	eICU Collaborative Research Database（eICU-CRD）
别名/简称	eICU、eICU-CRD、eICU-CRD v2.0
疾病分类	重症监护全疾病谱（ICD-11：1G4Z 脓毒症 / CB4Z 心力衰竭 / CA4Z 肺炎 / 8B6Z 急性肾损伤等多系统疾病）
SNOMED CT	133834002 Critical care medicine (procedure) / 91302008 Sepsis / 84114007 Heart failure / 233604007 Pneumonia（详见 §2.2）
数据模态	结构化 EHR、时序（床旁监护流）、护理与诊疗文档
AI 任务类型	院内/ICU 死亡预测、住院时长预测、脓毒症与 AKI 早期预警、跨医院外部验证、联邦学习、可移植性分析
样本总数	139,367 名患者 / 200,859 次 ICU 单元停留 / 335 个 ICU 单元 / 208 家医院 / 31 张关系表
数据大小	约 3.6 GB（CSV 压缩包，PostgreSQL 导入后建议预留 50 GB 以上磁盘）
数据格式	CSV / PostgreSQL / PhysioNet 云端（AWS/GCP 付费选项）
许可证	PhysioNet Credentialed Health Data License 1.5.0
访问级别	申请审核（注册 PhysioNet + 完成 CITI 培训 + 签署 DUA）
DUO 标签	HMB, NPUNCU, PUB
语言	英文
首发日期	2018-05（v1.0，与 Scientific Data 论文同步）
最后更新	2019-04-15（v2.0，PhysioNet 现行版本）
发布机构	飞利浦医疗（Philips Healthcare）& MIT 计算生理学实验室（LCP）
官方主页	https://eicu-crd.mit.edu/
下载地址	https://physionet.org/content/eicu-crd/2.0/
DOI	10.1038/sdata.2018.178（论文）/ 10.13026/C2WM1R（数据集 v2.0，RRID: SCR_007345）
引用次数	2,500+（Google Scholar，截至 2026-09）
AI 就绪度评分	⭐⭐⭐⭐（4/5）— 官方建库脚本与教程完备、多中心设计天然支持按医院划分；扣分项：数据止于 2015 年、无绝对时间戳、自定义字符串码表需大量清洗、无官方标签划分
页面状态	published

§0 E-E-A-T 信任声明与免责声明

医学审核：千方病案医学编辑部交叉审核 §2 医学背景（ICD-11 与 SNOMED CT 映射、重症医学流行病学）与 §7 偏倚分析。
数据工程审核：千方病案医学编辑部交叉审核（医疗 AI 数据工程师），审核范围：§4 DAIMS 数据字典、§5 数据划分策略、§6 预处理 Pipeline 与坑点。
版本核实：规模、版本与获取政策以 PhysioNet 官方项目页（v2.0，2019-04-15 发布）与 Pollard et al. 2018 原始论文为准；核实记录见 §10.3 输入来源。
利益关联声明：eICU-CRD 原始研究受 NIH（R01-EB017205、R01-EB001659、R01-GM104987）等资助，MIT 计算生理学实验室接受 Philips Healthcare 资助；本词条为独立百科条目，与上述机构无任何关联。
审核日期：2026-09-05

医疗免责声明：本页面提供的医学信息仅供研究和教育目的，不构成医疗建议、诊断或治疗方案。数据集的医学描述基于公开发表的文献，未经逐一临床验证。任何基于该数据集训练的 AI 模型在应用于临床决策前，必须经过独立的临床验证和监管审批。

技术免责声明：本页面的代码示例、预处理建议和基准性能数据基于公开资料整理，不保证在特定环境下的准确性和适用性。使用者应自行验证代码安全性和数据预处理流程的正确性。千方病案医数集不对因使用本页面信息而导致的任何直接或间接损失承担责任。

数据使用合规：使用本页面描述的数据集前，请务必阅读并遵守数据集原始许可协议。eICU-CRD 要求用户完成 CITI Program 的 “Data or Specimens Only Research” 培训并通过 PhysioNet 凭证化申请、签署数据使用协议（DUA）。DUO 标签仅供参考，具体使用限制以数据集官方协议为准。

§1 数据集概览

§1.0 30 秒速览

eICU-CRD 是飞利浦医疗（Philips Healthcare）与 MIT 计算生理学实验室于 2018 年联合发布的多中心重症监护公开数据库，收录 2014-2015 年美国本土 208 家医院、335 个 ICU 单元的 139,367 名患者、200,859 次 ICU 单元停留的脱敏数据，以 31 张关系表覆盖生命体征、实验室检查、用药、APACHE 评分与诊疗记录。

它的重要性来自一个词：多中心。医疗 AI 模型最常被质疑的问题不是性能不够高，而是「换一家医院还行不行」——eICU-CRD 是第一个能用真实数据回答这个问题的公开 ICU 数据集。你可以把整家医院留出来当测试集，衡量模型面对陌生医疗环境时的真实成色。

一句话概括：如果你在 MIMIC 上训练了一个 ICU 模型，想在「发布论文」之前知道它是否只是记住了贝斯以色列女执事医疗中心的工作流，eICU-CRD 就是那个标准的考场。

§1.1 技术摘要

eICU-CRD 的数据并非为研究而二次采集，而是 Philips eICU 远程重症项目的「副产品」：美国各地医院加入 eICU 计划后，床旁监护仪、检验系统、药房与护理文档通过逐类型「接口」持续汇入 eCareManager 远程平台，供异地重症团队 24 小时值守使用，这些在线数据同时被归档。MIT 团队从 eRI 研究仓库中按医院分层抽样 2014-2015 年出院患者，剔除仅入住过渡病房或低急症病房的停留，经 HIPAA safe harbor 脱敏（Privacert 认证编号 1031219-2）后发布为 31 张反规范化关系表。所有表以 patientUnitStayID 为主键互联；时间一律以相对 ICU 入科的分钟偏移存储；vitalPeriodic 表保存床旁监护仪 1 分钟采样、5 分钟中位归档的连续生命体征流。数据托管于 PhysioNet，凭 CITI 培训证书与 DUA 免费获取。

从体量上看，eICU-CRD 属于「压缩包不大、展开惊人」的类型：31 个 gzip 压缩 CSV 合计约 3.6 GB，导入 PostgreSQL 后膨胀至数十 GB，其中 nurseCharting 与 lab 两张长表贡献了绝大部分行数。全库数据密度并不均匀——监护流以 5 分钟中位网格规整排列，而护理与检验记录的密度取决于医院的接口配置与记录习惯。这种「规则流 + 事件流」的混合结构决定了它既适合以时间为轴的时序建模，也适合以事件为中心的队列研究；与之相应，预处理管线的内存与算力设计必须区别对待两类表（见 §6.3 与 §6.8）。

与同门师兄 MIMIC 相比，eICU-CRD 的互补性大于竞争性：MIMIC 系列胜在单中心深度（绝对时间戳、自由文本笔记、更长的年份跨度），eICU-CRD 胜在多中心广度（医院标识、单元类型多样性、跨院工作流差异）。两者覆盖的时间窗相近且患者几乎不重叠，社区已把「MIMIC 训练 + eICU 验证」（或反向）固化为可移植性研究的标准叙事。MIT 计算生理学实验室同时维护两库的文档、建库脚本与 concepts 惯例，在一个库里积累的工程经验可以无缝迁移到另一个。

§1.2 战略价值

外部验证与可移植性的标准考场。单中心数据集训练的模型无法区分「学到的是医学规律」还是「学到的只是本院的工作流」。Sheikhalishahi et al. (2019) 与后续一系列方法学论文将 eICU-CRD 用作多中心评测床：按整院留出（hospital-level hold-out）衡量模型跨院衰减，已成为发表在医学 AI 顶刊与会议前的标配实验。对于做跨机构泛化（transportability）研究的团队，医院标识的保留粒度是 eICU-CRD 独有的资产。

联邦学习与现实世界异质性的试验场。208 家医院的自然异质性（患者构成、记录习惯、检验项目组合差异）恰好构成联邦学习所需的「真实非 IID 场景」：Cell Patterns 2023 年的一项联邦学习研究直接以 eICU-CRD 模拟多医院协作训练 AKI 与脓毒症预测模型。除联邦学习外，eICU-CRD 还广泛用于强化学习治疗策略、多模态时序建模与隐私计算研究，是从「单中心原型」走向「多中心落地」路径上不可绕过的一站。

§1.3 同类数据集横向对比

数据集	规模	中心数	模态	标注	与 eICU-CRD 的差异化
eICU-CRD v2.0	200,859 次 ICU 停留 / 139,367 名患者	208 家医院 / 335 个 ICU	EHR + 监护流	无统一标签，需自建	多中心，医院标识可分组，天然外部验证床
需自建	多中心，医院标识可分组，天然外部验证床
MIMIC-III	61,532 次 ICU 入住 / 46,520 名患	61,532 次 ICU 入住 / 46,520 名患者	1 家（BIDMC）	EHR + 监护流 + 208 万篇临床文本	无统一标签
MIMIC-IV	约 69,619 次 ICU 入住（v0.4 口径）	1 家（BIDMC）	EHR	无统一标签	单中心但更新至 2019 年，字段结构现代化
HiRID	约 33,000 名患者	1 家（伯尔尼大学医院）	EHR + 高频监护	无统一标签	时间分辨率更高，但仍是单中心
SICdb	约 27,000 名患者	1 家	EHR + 高频监护	无统一标签	欧洲单中心，可作跨大洲外部验证

上表的规模口径取自各数据集官方论文或项目页，统计时点不同（如 MIMIC-III 为 v1.4 口径），仅供量级参考。真正值得记住的差异在「结构」：单中心库的一致性换来深度与成熟生态，多中心库的异质性换来泛化证据——eICU-CRD 用后者定义了自己。

§1.4 版本时间轴

日期	版本	事件
2018-05	v1.0	随 Scientific Data 论文（DOI: 10.1038/sdata.2018.178）在 PhysioNet 首发
2019-04-15	v2.0	PhysioNet 现行版本，数据引用 DOI: 10.13026/C2WM1R；此后以公共 issue tracker 收集勘误，随版本更新修正
2025-09-24	使用政策更新	PhysioNet 明确凭证数据与第三方 LLM API 的合规边界（详见 §6.5 坑点 8）

时间轴的一个易错点：v2.0 的发布日期（2019-04-15）晚于论文（2018-05），但 v2.0 覆盖的数据窗口仍是 2014-2015——版本日期是「发布修订时间」，不是「数据采集时间」，引用时务必区分（temporalCoverage 写 2014/2015，version 写 2.0）。

§1.5 典型应用场景

跨医院死亡/住院时长预测：在 MIMIC-III/IV 上训练，eICU-CRD 按医院留出验证，量化跨院性能衰减。
联邦学习与隐私计算：以 hospitalid 划分参与方，模拟 208 家医院的数据孤岛协作（Cell Patterns 2023）。
脓毒症与 AKI 早期预警：前 24 小时数据预测未来 6-24 小时发病风险（KDIGO / Sepsis-3 定义）。
ICU 远程医疗效果与资源利用研究：APACHE 严重程度调整下的治疗模式对比。
多中心时序基础模型预训练：5 分钟粒度监护流为大规模时序自监督学习提供真实 ICU 信号。
域自适应与可移植性方法学研究：以 hospitalid 为域标签，量化 DANN/IRM 等域自适应算法在真实医疗异质性下的净增益。
教学与诊疗路径挖掘：护理、医嘱与检验事件流可还原多中心 ICU 工作流，用于记录规范教学与路径一致性分析。

这些场景的共同点值得点破：几乎每个高价值场景都建立在「医院可分组」这一结构之上。换句话说，选 eICU-CRD 而不是 MIMIC 的理由，几乎总是与跨院泛化、联邦学习或外部验证有关；如果研究只关心单中心深度，MIMIC 系列通常是更顺手的第一站。

§2 医学背景

§2.1 ICD-11 疾病分类锚定

eICU-CRD 覆盖 ICU 全疾病谱。库内 diagnosis 表同时携带 ICD-9-CM 与 ICD-10-CM 编码，常见高频诊断到 ICD-11 的映射如下：

库内编码体系	中文名称	ICD-11 对应	在 eICU-CRD 中的角色
ICD-9-CM 038.9 / ICD-10-CM A41.9	脓毒症	1G4Z 脓毒症，未特指	admissiondx 与 diagnosis 高频主诊断
ICD-9-CM 428.0 / ICD-10-CM I50.9	心力衰竭	CB4Z 心力衰竭，未特指	高频共病
ICD-9-CM 486 / ICD-10-CM J18.9	肺炎	CA4Z 肺炎	高频感染性主诊断
ICD-9-CM 584.9 / ICD-10-CM N17.9	急性肾损伤	8B6Z 急性肾损伤，未特指	lab 肌酐/尿量驱动的 AKI 队列核心
ICD-9-CM 518.81 / ICD-10-CM J96.0	急性呼吸衰竭	CB41 呼吸衰竭	机械通气队列核心（treatment 表 16.96% 患者行机械通气）
ICD-9-CM 414.01 / ICD-10-CM I25.10	冠状动脉粥样硬化性心脏病	BA52 冠状动脉疾病	高频心血管共病

注意：admissiondx 表记录的入住主诊断并非 ICD 编码，而是按 APACHE III 诊断类目填写的字符串；diagnosis 表才是 ICD 编码通道。两套体系不可混用。

ICD 通道还有一个已知特性：诊断编码随住院进程动态追加（每条带 diagnosisoffset），并非入科即完整——用 diagnosis 做「入科时已知诊断」特征时，必须按记录时间窗过滤，否则构成标签泄漏（与 §5.3 呼应）。

§2.2 SNOMED CT 映射

临床场景	ICD-10-CM 桥接	SNOMED CT	SNOMED CT 术语
脓毒症	A41.9	91302008	Sepsis (disorder)
心力衰竭	I50.9	84114007	Heart failure (disorder)
肺炎	J18.9	233604007	Pneumonia (disorder)
急性肾损伤	N17.9	14669001	Acute renal failure syndrome (disorder)
急性呼吸衰竭	J96.0	65710008	Acute respiratory failure (disorder)
重症监护	Z51.89	133834002	Critical care medicine (procedure)
机械通气	5A1935Z	243141005	Mechanical ventilation (regime/therapy)

需要说明的是，eICU 库内并不原生存储 SNOMED CT 编码——上表是「把库内诊断通道桥接到标准术语」的研究性映射，用于跨库对齐与本体推理。库内原生的三个编码通道分别是：diagnosis 表的 ICD 编码、admissiondx 的 APACHE 诊断字符串与 treatment 的自定义层级码；三者的粒度与覆盖互不一致（见 §2.1 注意事项），做本体层映射前先确定以哪条通道为源。

§2.3 疾病简介与流行病学

eICU-CRD 面向重症监护室内全部疾病谱。ICU 患者以多器官功能障碍为特征，常见入住诊断包括脓毒症、急性呼吸衰竭、心力衰竭、急性肾损伤与心源性/创伤性急症。与单中心教学医院数据集不同，eICU 网络以美国社区医院为主体——这既是它做外部验证的价值所在，也意味着患者构成、操作规范与记录密度更接近「普通美国医院的平均水平」而非顶级学术中心。重症医学的资源消耗占医院总支出的重要份额，而远程重症监护（tele-ICU）本身即是为了把重症专家资源延伸到缺乏专科力量的社区医院——理解这一点才能理解 eICU-CRD 数据为什么长成现在的样子：它是远程值守工作流的自然沉淀，不是为科研设计的实验记录。

就具体病种而言，脓毒症是 ICU 最具代表性的综合征：Sepsis-3 将其定义为「疑似感染 + SOFA 急性升高 ≥ 2 分」，在库内可通过 medication（抗生素订单）、microLab（培养与药敏）与 APACHE 生理组件的时序组合操作化；由于 microLab 接口覆盖有限，跨院脓毒症队列必须报告定义层面的敏感性分析。急性呼吸衰竭与机械通气构成第二大任务群——treatment 表显示约 16.96% 的患者接受机械通气，respiratoryCare 与 respiratoryCharting 提供呼吸机设置与呼吸治疗记录，支撑脱机预测与人机同步研究。急性肾损伤以 lab 肌酐与 intakeOutput 尿量为操作化核心，KDIGO 分期标准可直接落成标签代码；心源性队列（心力衰竭、冠心病、心源性休克）可借助 apacheapsvar 的既往史组件与 admissiondx 主诊断组合圈定。

§2.4 临床任务定义

AI 任务	临床定义	标准参考	在 eICU-CRD 中的操作化
ICU 死亡预测	ICU 单元停留期间全因死亡	单元出院处置记录	patient 表 unitDischargeStatus 字段
院内死亡预测	住院期间全因死亡	住院出院处置	patient 表 hospitalDischargeStatus 字段
AKI 发病预测	前 24 h 数据预测未来 24 h 发病	KDIGO 2012 肌酐/尿量标准	lab 表肌酐 + intakeoutput 尿量自建标签（Cell Patterns 2023）
脓毒症发病预测	未来 6 h 内发病	Sepsis-3：疑似感染 + SOFA ≥ 2	静脉抗生素 + 血培养时间戳（medication/lab）构造疑似感染时点
住院时长预测	ICU 入科到出科	分类或回归	patient 表 unitDischargeOffset（分钟偏移）
谵妄外部验证	结局模型跨院迁移	CAM-ICU 等量表	由护理评估表派生（Contreras et al. 2024）
机械通气时长/脱机预测	呼吸机使用时长或成功脱机	呼吸治疗临床指南	treatment（机械通气码）+ respiratoryCare 设置 + respiratoryCharting 记录
严重程度调整基线	以官方风险模型为对照基准	APACHE IV 预测模型	apachepatientresult 的预测死亡概率仅作基线对比，不作特征（坑点 7）

§2.5 患者人群特征

维度	特征
数据来源	多中心：美国本土 208 家医院 / 335 个 ICU 单元，以加入 Philips eICU 远程重症项目的社区医院为主体
采集时间	2014 年至 2015 年住院出院患者（约 2 年窗口）
规模	139,367 名独立患者 / 200,859 次 ICU 单元停留
抽样方式	按医院分层抽样：每名患者抽 1 次 index stay，其后续全部停留随附入库；剔除仅入住过渡病房/低急症病房者
年龄	成人为主；89 岁以上统一编码为 300（HIPAA safe harbor 分组）
单元类型	内外综合 ICU、心外 ICU、神经 ICU、心内 CCU 等多个急症单元类型
随访边界	追踪止于住院出院；出院后结局（如 90 天死亡）库内不可得

人口学画像上，eICU 网络以美国社区医院为主体，患者年龄结构偏年长、合并症负担重。分析前需注意两点：其一，89 岁以上患者年龄统一编码为 300（HIPAA safe harbor 分组），任何年龄分层都必须先处理该折叠（坑点 1）；其二，抽样设计保留「每患者 1 个 index stay + 全部后续停留」，因此多次入住患者会在库内自然出现，患者级与停留级统计口径不可混用——引用规模数字时，「139,367 名患者」与「200,859 次停留」指的正是这两层。

§2.6 临床价值与金标准对照

对照项	eICU-CRD 的现状
划分	无官方划分；社区惯例为按 hospitalid 整院留出
标注方式	原始数据无机器学习标签；死亡/时长标签直接取自 patient 表处置字段，AKI/脓毒症标签需按 KDIGO/Sepsis-3 自建
标注者	床旁临床工作者（护理文档、医师诊断、APACHE 评分员），监护流数据未经人工校验
标注性质	回顾性、真实世界、以临床照护为首要目的的记录——质量参差是设计使然而非缺陷
金标准适用性	适合「真实工作流下的多中心泛化」研究；不适合需要绝对日历时间或出院后长期结局的研究

与「金标准标注数据集」（ImageNet 式基准）不同，eICU-CRD 是「金标准工作流」数据集：它的价值在于原样保存了真实 ICU 的记录过程，包括其中的噪声、缺口与不一致。用它做研究的第一原则是尊重工作流语义——先理解每张表「为什么长这样」，再决定「怎么用」；跳过第一步直接建模，正是 §6.5 八个坑点的共同来源，也是审稿人判断「是否真用过 eICU」的最快依据。

§3 数据集规格

§3.0 版本抉择矩阵

你的需求	推荐版本	大小	理由
正式研究、论文发表	v2.0（PhysioNet 现行版本）	约 3.6 GB（压缩包）	最新修正、官方唯一维护版本、数据引用 DOI 稳定
快速试跑 / 包结构学习	eicu.demo 演示子集	数 MB 级	无需凭证即可体验表结构（R 包 ricu 内置演示集）
复现 2018-2019 年早期论文	v1.0（历史存档）	与 v2.0 接近	仅在逐字复现旧结果时使用；新研究不建议

矩阵之外的第三种选择是「v2.0 + 订阅官方 issue tracker」：已知勘误会随版本发布，研究期内关注 release 通知可以在不换版本的前提下吸收修正；投稿前若发生版本变更，应触发结果复跑。

§3.1 模态详情

模态	内容	代表表	特点
床旁监护时序	心率、呼吸频率、SpO2、体温、有创动脉压、肺动脉压、ST 段、颅内压	vitalPeriodic	床旁监护仪 1 分钟采样、5 分钟中位归档；心率覆盖 96% 患者，ICP 仅 0.81%
不定期监护时序	无创血压、肺动脉楔压（PAOP）、心输出量、SVR/PVR 及指数	vitalAperiodic	按临床操作不规律触发；无创血压覆盖 94% 患者
实验室检查	约 160 个标准化检验项	lab	各医院首次入组时将本地检验名映射到标准词表；检验可在 ICU 入科前（负偏移）
微生物检验	培养与药敏	microLab	因接口覆盖有限，填充率在主要表中最差
用药与输液	药房订单、持续输注	medication / infusiondrug	medication 为药房订单接口（记录已开药而非给药时刻）；infusiondrug 各医院收集情况不一
入出量	液体出入量	intakeoutput	护理记录驱动
诊疗与护理文档	护理记录、呼吸治疗、查体、护理评估	nursecharting / respiratorycharting / physicalexam / nurseassessment	实体-属性-值（EAV）长表结构
诊断与治疗	ICD 编码诊断、APACHE 入住主诊断、自定义治疗层级码	diagnosis / admissiondx / treatment	treatment 采用自定义层级编码，共 2,711 种
严重程度评分	APACHE III/IV 组件变量与预测结果	apacheapsvar / apachepatientresult / apachepredvar	官方严重程度调整的核心素材
既往史与入院信息	入院前用药、既往史、过敏史、APACHE 入住主诊断	admissionDrug / pastHistory / allergy / admissionDx	静态或近静态特征，入科早期即可用
临床文本	结构化存储的护理笔记与记录正文	note	PHI 已按规则删行；可做 NLP，但与结构化流无对齐保证

理解 §3.1 的钥匙是「接口」二字：每类模态对应医院侧的一种接入配置，医院与医院、单元与单元之间接口不同，因此模态覆盖是医院级属性而非患者级属性。这带来一个实用推论——任何跨模态融合模型在 eICU-CRD 上都必须处理「模态整片缺失」的情形（坑点 3），而不仅是单个时间点的缺失；也正因如此，官方论文 Table 8 才会按表统计「低/中/高完成度医院」的数量分布。

§3.2 按子集样本数

子集	规模	说明
独立患者（uniquepid）	139,367	每人至少 1 次 ICU 单元停留
ICU 单元停留（patientUnitStayID）	200,859	全库主键口径
ICU 单元	335	分布于 208 家医院
医院	208	美国本土，医院标识以随机整数存储
治疗种类	2,711 种	treatment 自定义层级编码词表
标准检验项	约 160 项	lab 标准词表
心率监护记录	有记录者人均 759.2 条	约 63 小时的 5 分钟网格，全库覆盖面最广的时序模态（96% 患者）
ICP 监护记录	仅 0.81% 患者有记录	罕见但高密度（有记录者人均 1,610.3 条），神经重症队列专属

§3.3 数据格式

格式	获取方式	适用场景
CSV（gzip 压缩）	PhysioNet wget 直接下载	任何语言/工具链，官方默认分发格式
PostgreSQL	eicu-code 仓库官方建库脚本	SQL 队列抽取、concepts 物化视图
R（ricu）/ Python（PyHealth）加载器	CRAN / 官方文档安装后直接读本地 CSV	快速原型，自动处理表加载与时间轴语义
AWS/GCP 云端副本	PhysioNet 云计划（付费）	大规模特征工程，避免本地下行流量

§3.4 存储大小

v2.0 全库压缩包约 3.6 GB，含 31 个 CSV 文件；导入 PostgreSQL 后体积显著膨胀，建议预留 50 GB 以上磁盘。下载命令（PhysioNet 审批通过后）：

wget -r -N -c -np --user=<你的PhysioNet用户名> --ask-password \
    https://physionet.org/files/eicu-crd/2.0/

§3.5 标注方式

标注类型	机制	质量特征
临床工作流标注（死亡、出院处置）	床旁/远程临床工作者在 eCareManager 系统内随照护记录	与护理流程绑定，医院间填写完整性差异大
严重程度评分（APACHE III/IV）	受训评分员按入住首个 24 h 数据计算	官方组件表可直接复用，是全库质量最高的结构化标注
监护流（vitalPeriodic/vitalAperiodic）	床旁监护仪自动归档，无人工验证	数值可能含监护仪伪影，与护理手工记录（nursecharting）不一致属常见现象
诊断/治疗编码	ICD 编码通道 + APACHE 主诊断字符串 + 自定义治疗层级码	自由文本派生，跨医院粒度不一致
微生物与药敏	检验系统接口自动入仓	接口覆盖有限，填充率全库主要表中最差，跨院比较需谨慎

§3.6 标注者资质与一致性

标注者即真实临床流程的记录者：注册护士（护理评估与出入量）、医师（诊断与治疗）、受训 APACHE 评分员（严重程度变量）与自动接口（监护流、检验）。数据集未提供标注者间一致性统计——它不是为标注任务设计的基准集，任何标签都需要使用者按临床定义自建并做敏感性分析。

§3.7 采集周期

数据覆盖 2014-2015 年两个完整自然年的住院出院患者；采样为一次性分层抽样（每患者 1 个 index stay + 全部后续停留），此后版本仅做勘误与补表，不再追加新数据年份。对时间敏感的研究方向应明确本库适用边界：两年窗口内的季节效应可以研究，跨年趋势与政策评估不可研究。

§3.8 地域覆盖

美国本土（continental US）208 家医院，横跨多个州与医保区域；医院仅以随机整数标识并附带地区（region）属性，地理粒度到「医院」为止，不含城市/州名以保护机构隐私。需要提醒：医院级随机标识与 region 属性足以支撑跨地区分组分析，但任何涉及具体地理位置的推断（州级政策、都市圈差异）在本库都无法开展——这是去标识化的设计结果，不是数据缺陷。

§3.9 设备规格

床旁监护数据源于 Philips 系监护仪经 eICU 平台自动归档：vitalPeriodic 记录连续参数的 5 分钟中位值（原始 1 分钟采样），vitalAperiodic 记录由临床操作触发的不定期参数。数据入仓依赖医院部署的接口类型——同一医院的不同护理单元可能接口不同，这是全库缺失结构的核心决定因素。

采样-归档的两级结构值得展开：床旁监护仪以 1 分钟粒度采集心率、呼吸频率、SpO2、体温、有创动脉压、肺动脉压、ST 段与颅内压等连续参数，平台归档时以 5 分钟窗口取中位数写入 vitalPeriodic——原始 1 分钟信息在源头即被有损压缩，任何「高频细节挖掘」都要以此为上限。不定期参数（无创血压、PAOP、心输出量、SVR/PVR 及指数）由临床操作触发写入 vitalAperiodic，其频率反映护理强度而非病情本身，直接把「记录条数」当病情严重度特征会引入显著混杂。

§3.10 深度溯源链

Philips eICU 远程重症项目（eCareManager 平台实时监护数据归档）
        │  Philips eICU Research Institute（eRI）维护私有研究仓库
        ▼
按医院分层抽样（2014-2015 出院患者，每患者 1 个 index stay + 后续停留）
        │  Privacert HIPAA safe harbor 认证（no. 1031219-2）+ 规则扫描 + 人工复核
        ▼
MIT 计算生理学实验室（LCP）整理发布
        │  MD5 校验传输完整性，v1.0（2018-05）→ v2.0（2019-04-15）
        ▼
PhysioNet 托管分发（CITI 培训 + DUA 凭证获取）

溯源链的每一环都有可核验的凭证：抽样设计见论文 Methods 节，Privacert 认证编号 1031219-2 可独立核对，版本间差异经 GitHub issue tracker 留痕，下载完整性以官方提供的校验方式确认。对需要撰写数据管理计划（DMP）或论文数据声明的团队，这条链可以直接改写为「数据来源与处理步骤」的正式描述。

§4 数据结构详解

§4.0 目录结构预览

解压后得到 31 个 CSV 文件（下方展示核心表，节选）：

eicu-crd/2.0/
├── admissionDrug.csv          # 入院前用药
├── admissionDx.csv            # APACHE 入住主诊断（字符串类目）
├── allergy.csv                # 过敏记录
├── apacheApsVar.csv           # APACHE 急性生理评分组件
├── apachePatientResult.csv    # APACHE 评分结果与预测死亡概率
├── apachePredVar.csv          # APACHE IV 预测模型变量
├── diagnosis.csv              # ICD 编码诊断（结构化问题列表）
├── hospital.csv               # 医院维表（region 等）
├── infusionDrug.csv           # 持续输注药物
├── intakeOutput.csv           # 液体出入量
├── lab.csv                    # 标准化实验室测量
├── medication.csv             # 药房订单
├── microLab.csv               # 微生物培养与药敏
├── note.csv                   # 临床笔记
├── nurseAssessment.csv        # 护理评估
├── nurseCharting.csv          # 护理记录（EAV 长表）
├── pastHistory.csv            # 既往史
├── patient.csv                # 患者主表（三级标识符根）
├── physicalExam.csv           # 查体记录
├── respiratoryCare.csv        # 呼吸治疗（宽表）
├── respiratoryCharting.csv    # 呼吸机设置记录
├── treatment.csv              # 治疗记录（2,711 种层级编码）
├── vitalAperiodic.csv         # 不定期监护参数
├── vitalPeriodic.csv          # 5 分钟中位连续监护参数
└── ...                        # 其余表与数据库构建脚本

§4.1 DAIMS 字段字典（patient 核心表）

字段名	类型	说明	示例值	AI 用途	观测误差	信息性缺失编码	取值范围
patientUnitStayID	int	ICU 单元停留唯一标识，全库主键	241,959	全表 join 锚点	无（系统生成）	无缺失	全库唯一整数
uniquepid	int	患者唯一标识	12,834	患者级分组/划分	无	无缺失	全库唯一整数
patientHealthSystemStayID	int	住院标识	140,769	住院级分组	无	无缺失	全库唯一整数
hospitalid	int	医院随机标识	33	按医院划分/联邦学习	无（脱敏替换）	无缺失	73-458 区间整数
wardid	int	单元标识	137,532	单元级分析	无	无缺失	整数
age	varchar	年龄（字符串存储）	“73”	风险分层特征	记录时点误差	89 岁以上统一为 “300”	“0”-“89”、“300”、空串
gender	varchar	性别	Male	人口学特征	录入误差	空串即未知	Male/Female/Unknown/空
unitType	varchar	单元类型	Med-Surg ICU	队列分层	分类固定	无缺失	9 类左右枚举
unitAdmitOffset / unitDischargeOffset	int	入/出单元时间（分钟偏移）	-231 / 3,547	住院时长标签、时间窗口	时钟同步误差	负值=入科前	整数分钟
unitDischargeStatus	varchar	出单元处置（死亡标签来源）	Expired	ICU 死亡标签	填写完整性医院间差异大	空串=未记录	Alive/Expired 等

vitalPeriodic（5 分钟中位监护流）关键字段：

字段名	类型	说明	示例值	AI 用途	观测误差	信息性缺失编码	取值范围
patientunitstayid	int	所属 ICU 单元停留	241,959	与 patient 表 join	无（系统生成）	无缺失	全库唯一整数
observationoffset	int	距入科分钟数（天然 5 分钟网格）	1,235	时序索引/特征窗	时钟同步误差	负值=入科前	整数分钟
heartrate	numeric	心率（5 分钟中位）	82	核心时序特征	监护仪伪影，无人工验证	空值=该窗未测	0-300 次/分
respirationrate	numeric	呼吸频率	18	核心时序特征	同上	空值=该窗未测	0-60 次/分
sao2	numeric	血氧饱和度（列名 sao2）	96	氧合特征	低灌注时可信度下降	空值=该窗未测	0-100%
systemicsystolicbp / systemicdiastolicbp	numeric	有创动脉收缩/舒张压	118 / 64	血流动力学特征	仅在有创测压时非空	空值=未测	整数 mmHg
icp	numeric	颅内压	12	神经重症特征	仅 0.81% 患者有记录	空值=未测	整数 mmHg

lab（标准化实验室）关键字段：

字段名	类型	说明	示例值	AI 用途	观测误差	信息性缺失编码	取值范围
labname	varchar	标准检验项名（约 160 项官方词表）	creatinine	特征选择/透视键	医院映射差异	行级存在性随接口	官方词表枚举
labresult	numeric	检验结果数值	1.2	AKI/器官功能特征	检验接口误差	空值=数值未回	数值
labresulttext	varchar	检验结果文本	Negative	类别检验（培养/定性）	与数值列互补	空串=未记录	自由文本
labresultoffset	int	距入科分钟数	-624	特征窗过滤	同全库时间语义	负值=入科前	整数分钟

注：CSV 实际表头为全小写（如 patientunitstayid）；本词典按词条行文惯例首字母大写展示，写代码时以官方表文档为准。

§4.2 标签分布

原始数据不含现成机器学习标签；常用标签需自行构造，参考分布如下（基于官方论文与社区报告口径，构造前请以自建队列实际统计为准）：

常用标签	构造来源	分布要点
ICU 死亡	unitDischargeStatus = Expired	类别极不平衡，社区报告死亡率约一成上下，且该字段存在医院级缺失
住院死亡	hospitalDischargeStatus	缺失率高于 ICU 口径，构造时须先过滤空值
住院时长	unitDischargeOffset - unitAdmitOffset	右偏长尾，通常取对数或分档
AKI 发病	lab 肌酐 + intakeoutput 尿量按 KDIGO	正例率取决于观察窗定义（Cell Patterns 2023 用 24 h→24 h）
脓毒症发病	Sepsis-3：抗生素 + 血培养 + SOFA	microLab 覆盖差时需按 documented diagnosis 兜底
机械通气（治疗标签）	treatment 自定义层级码	16.96% 患者有机械通气记录，跨院粒度需先归并同类码

构造任何标签后的第一张图应该是「医院 × 标签」分布图：类别平衡、缺失率与定义敏感性都会随医院变化。只看全库汇总分布会把 208 家医院的异质性平均掉——而那恰恰是这个数据集最需要被看见的信息。

§4.3 关键统计

心率是覆盖面最广的周期性监护参数：96% 的患者至少有一条记录，有记录者平均 759.2 条（约 63 小时）。
ICP 是覆盖面最窄的周期性参数：仅 0.81% 患者有记录，但一旦监测则平均 1,610.3 条（约 134 小时）——「罕见但高密度」。
无创血压是最常见的不定期参数（94% 患者），PVRi 最罕见（0.93%）。
treatment 表 2,711 种治疗中，机械通气（16.96% 患者）、胸部 X 光（8.79%）、低浓度鼻导管氧疗（6.93%）、生理盐水（7.57%）居前。
论文 Table 8 按表统计了低/中/高数据完成度医院数——同一张表在不同医院的填充率可能相差数倍。
31 张表中绝大多数为「一行一事件」的长表；行数量级最大的 nurseCharting 与 lab 同时也是透视内存压力的主要来源。
各表行级主键（后缀 id）为随机整数，无时序含义——排序一律以偏移时间列为准，禁止按主键排序。
心率与无创血压的覆盖统计（96% / 94%）可视为全库「覆盖面」的参照上限——任何特征的可用率若显著低于此，先怀疑接口缺失而非患者未测。

§4.4 数据层级

uniquepid（患者）
└── patientHealthSystemStayID（住院）
    └── patientUnitStayID（ICU 单元停留）★ 全库主键：除 hospital 外所有表靠它关联

同一患者可有多次住院；同一住院可有多次单元停留（转科即新停留）。特别注意：仅知道单元停留之间的先后顺序，无法推断患者多次住院之间的顺序——PyHealth 因此把「患者」对象直接建模为「住院」粒度。

层级语义对工程实现的直接影响：聚合口径每升一层（停留 → 住院 → 患者），样本量从 200,859 次停留收敛到 139,367 名患者的住院序列集合，且越往上越难从库内字段直接还原序列顺序——这正是社区分析默认以停留为分析单元、把患者级结论留给显式聚合的底层原因。跨层聚合时务必在代码评审里明确「本研究的分析单元是哪一层」，并让三层标识符在特征表中一路随行，避免聚合时静默串行。

§4.5 缺失值与信息性缺失

缺失机制	典型表	表现	处理建议
接口缺失（结构性 MNAR）	microLab、infusiondrug、note 等	某医院/单元整类数据为零，即使临床上实际存在	先按 hospitalid × 表统计覆盖率，再决定队列与特征集
未记录（随机缺）	nursecharting 单项	时间轴上零星空洞	前向填充 + 缺失指示符/衰减因子
填写缺失	unitDischargeStatus 等	部分医院处置字段留空	构造标签前过滤并把缺失率写进论文限制
生理性未测	vitalAperiodic 高级血流动力学	PAOP/心输出量等仅重病患者测得	按指示性缺失建模，勿当随机缺失填补
版本级勘误	跨版本对比	v1.0 → v2.0 存在勘误与表结构调整	锁定 v2.0，在论文中报告下载日期与校验结果

§5 数据划分与使用建议

§5.1 官方划分

eICU-CRD 不提供官方机器学习划分。官方文档给出的结构建议是：以 patientUnitStayID 为分析单元、以 hospitalid 为分组变量；数据集的多中心设计本身就是「划分建议」——医院是天然的泛化边界。

这与许多「自带官方划分」的基准集不同：官方刻意不发布划分，是为了让研究者把医院这个天然泛化边界用起来——划分协议本身应作为方法学贡献的一部分被设计与披露，而不是被一个固定 split 文件取代。

§5.2 社区惯例划分

按医院整院留出（最常用）：随机抽取若干 hospitalid 作为测试院（常按医院样本量分层，如 70%/15%/15% 或按地区分层），其余医院内部再切训练/验证。可移植性与联邦学习论文均采用此路。
患者级随机划分（仅限单中心式研究）：按 uniquepid 分组切分，保证同一患者不跨集。
时序划分：因数据仅两年且无可靠绝对日历时间，时序外推验证在本库不适用。

整院留出有一个实践细节：208 家医院规模差异很大，直接随机留出可能得到「几家小院当测试集」的高方差估计。更稳的做法是先按医院样本量分层（如按停留数四分位），在每层内按比例抽测试院，使测试集的医院构成与训练分布匹配；联邦学习论文则常按 hospital 表的 region 字段划分客户端。无论哪种做法，最终医院列表都应作为实验产物落盘并与结果一同发布，这是多中心论文可复现性的最低要求。

§5.3 泄漏风险（重点）

泄漏通道	场景	后果	对策
同一患者多次停留	患者先入 Med-Surg ICU 再转 MICU，两条停留高度相关	患者级随机划分下验证集虚高	所有划分以 uniquepid 分组
同一医院工作流	同院患者的检验组合、记录密度、编码习惯一致	随机按停留划分等于「考试漏题」	按 hospitalid 整院留出
标签泄漏（特征侧）	用入住 24 h 数据时混入出院结局相关字段（APACHE 预测死亡概率）	模型学到「结局」而非「前兆」	特征窗严格按偏移时间过滤
物化视图回填	用社区 concepts（如 SOFA）时其中含未来时刻的分量	时序任务标签污染	核对 concept 定义的时间窗

§5.4 交叉验证建议

推荐 GroupKFold（组 = hospitalid）5 折：每折整院轮换，报告折间均值与标准差。若做单中心式队列研究，退一级用 GroupKFold（组 = uniquepid）。禁用无分组的随机 K 折。

嵌套情形下（既做模型选择又做泛化估计），推荐两层结构：外层整院留出做最终评估，内层在训练院内用 GroupKFold（组 = hospitalid）做超参搜索；两层划分的医院集合不得重叠。报告时必须区分「内层选择性能」与「外层泛化性能」——二者混淆是多中心论文最常见的统计硬伤，也几乎是审稿意见的必然来源。

§5.5 外部验证建议

反向验证：eICU-CRD 训练 → MIMIC-III/IV 验证，检查社区医院模型在三级学术中心的迁移性。
跨大洲验证：HiRID（伯尔尼）或 SICdb 作为欧洲外部集，注意编码体系差异需先映射。
报告规范：按 TRIPOD + AI 惯例报告各医院亚组的性能分布（不只报均值），医院级性能箱线图是多中心研究的标准图。
多库联合训练：MIMIC + eICU 合并训练时按数据源加域标识，报告源内/跨源双口径，防止混合分布掩盖单库衰减。

§6 AI 就绪指南

§6.0 云端快速启动

PhysioNet 为已授权用户提供 AWS/GCP 云端副本（付费），适合大规模特征工程：

# AWS Open Data（已授权用户，替换为你的凭证目录）
aws s3 sync s3://physionet-open/eicu-crd/2.0/ eicu-crd/2.0/ --no-sign-request  # 公开演示部分
# 完整凭证数据请使用 PhysioNet 控制台提供的签名下载命令

§6.1 快速上手

代码注释约定：data_root 指向 PhysioNet 审批后下载并解压的目录（结构见 §4.0，如 eicu-crd/2.0/）；最小可用子集为 patient.csv + vitalPeriodic.csv（约 1 GB 内存即可跑通本节示例）。

import pandas as pd

DATA_ROOT = "eicu-crd/2.0"   # 解压后的 CSV 目录

# 患者主表：三级标识符（uniquepid -> patientHealthSystemStayID -> patientUnitStayID）
patient = pd.read_csv(f"{DATA_ROOT}/patient.csv")
print(patient.shape)          # (200859, 30+) —— 每行一次 ICU 单元停留

# 5 分钟中位监护流（心率），仅加载需要的列以控制内存
vital = pd.read_csv(
    f"{DATA_ROOT}/vitalPeriodic.csv",
    usecols=["patientunitstayid", "observationoffset", "heartrate"],
)
print(vital.head())

# 单个停留的心率曲线（注意：observationoffset 单位是「分钟」，相对 ICU 入科）
sid = patient["patientunitstayid"].iloc[0]
hr = vital[vital["patientunitstayid"] == sid].sort_values("observationoffset")
print(hr[["observationoffset", "heartrate"]].head(10))

跑通本节后，建议立刻做两件事：用 patient.groupby("hospitalid").size() 看一眼医院规模分布（体会什么叫异质性）；再用 vital["observationoffset"].min() 确认负偏移的存在（体会什么叫相对时间轴）。这两个观察是理解后面所有坑点的感性起点。

§6.2 数据获取全流程

步骤	操作	要点
1. CITI 培训	citiprogram.org 注册，机构选 Massachusetts Institute of Technology Affiliates，课程选 Data or Specimens Only Research	免费；下载 Completion Report（PDF）；审批数日至一周，机构邮箱/ORCID 可加速
2. PhysioNet 注册	physionet.org 注册账号并完成资料填写	需一位推荐人（导师/PI）配合确认邮件
3. 凭证申请	在 eICU-CRD 项目页提交 credentialed 申请并上传 CITI 报告	每位团队成员必须各自申请，不可共享数据
4. 签署 DUA	审批通过后在线签署数据使用协议	承诺不共享、不尝试再识别、发表须公开代码
5. 下载	wget 全量下载（约 3.6 GB 压缩包）	大文件慢可改用 AWS/GCP 付费选项

# 第 5 步下载命令模板（审批邮件中会提供）
wget -r -N -c -np --user=<PhysioNet用户名> --ask-password \
    https://physionet.org/files/eicu-crd/2.0/

全流程的时间瓶颈通常不在下载而在审批：CITI 证书需数日至一周，PhysioNet 凭证审批视推荐人确认速度而定。团队立项时应把审批周期排进计划，避免「数据到位前无事可做」的空转；同时注意每位成员都必须走完全流程——共享账号或向未授权成员转存数据均违反 DUA。

§6.3 预处理全流程

import numpy as np
import pandas as pd

DATA_ROOT = "eicu-crd/2.0"

def load_cohort(data_root: str = DATA_ROOT) -> pd.DataFrame:
    """构造 ICU 死亡预测队列：过滤年龄异常、缺失标签的停留。"""
    p = pd.read_csv(f"{data_root}/patient.csv")

    # 坑点 1：89 岁以上统一编码为 300，先转数值再单独分箱
    p["age_num"] = pd.to_numeric(p["age"], errors="coerce")
    p.loc[p["age_num"] == 300, "age_num"] = 90   # 折叠到 90+ 组

    # 死亡标签：仅保留有处置记录的停留
    p = p[p["unitdischargestatus"].isin(["Alive", "Expired"])].copy()
    p["label_icu_death"] = (p["unitdischargestatus"] == "Expired").astype(int)
    return p

def build_hr_series(vital: pd.DataFrame, stays, max_minutes: int = 1440) -> dict:
    """前 24 小时心率序列：5 分钟中位表可直接当 5 min 网格使用。"""
    vital = vital[vital["patientunitstayid"].isin(set(stays))]
    vital = vital[vital["observationoffset"] <= max_minutes]
    vital = vital[vital["heartrate"].between(0, 300)]          # 物理范围清洗
    return {sid: g.sort_values("observationoffset")["heartrate"].to_numpy()
            for sid, g in vital.groupby("patientunitstayid")}

def pivot_nursecharting(nc: pd.DataFrame, cells: list) -> pd.DataFrame:
    """坑点 6：nurseCharting 是 EAV 长表，须按单元格类型透视。
    cells 例如 ["Temperature", "Respiratory Rate"]（见官方词表）。"""
    sub = nc[nc["nursingchartcelltypevalname"].isin(cells)]
    sub = sub.assign(
        value=pd.to_numeric(sub["nursingchartvalue"], errors="coerce"),
        offset=sub["nursingchartentryoffset"],
    )
    wide = (sub.pivot_table(index=["patientunitstayid", "offset"],
                            columns="nursingchartcelltypevalname", values="value")
               .reset_index())
    # 同一时间点多条记录取均值去重
    return wide.groupby(["patientunitstayid", "offset"], as_index=False).mean()

cohort = load_cohort()
print(cohort["label_icu_death"].value_counts(normalize=True))

def build_suspicion_offset(med: pd.DataFrame, microlab: pd.DataFrame,
                           cohort: pd.DataFrame) -> pd.DataFrame:
    """Sepsis-3「疑似感染时点」简化构造：抗生素订单与血培养时间取较早者。
    完整 Sepsis-3 还需 SOFA 急性升高 >= 2，建议复用 eicu-code 的 SOFA concept
    而非手写——定义操作化的微小差异会直接改变队列构成。"""
    stays = set(cohort["patientunitstayid"])
    # 抗生素词表仅为示例：实际项目请维护一份经代码评审的抗生素清单
    abx = med[med["patientunitstayid"].isin(stays)]
    abx = abx[abx["drugname"].str.contains(
        "piperacillin|vancomycin|cefepime|meropenem|levofloxacin",
        case=False, na=False)]
    abx_t = abx.groupby("patientunitstayid")["drugorderoffset"].min()
    bld = microlab[microlab["patientunitstayid"].isin(stays)]
    bld = bld[bld["culturename"].str.contains("blood", case=False, na=False)]
    bld_t = bld.groupby("patientunitstayid")["cultureoffset"].min()
    suspicion = pd.concat([abx_t.rename("abx"), bld_t.rename("culture")],
                          axis=1).min(axis=1)   # 两类证据中较早者
    cohort["suspected_infection_offset"] = cohort["patientunitstayid"].map(suspicion)
    return cohort

要点回顾：(1) 年龄 300 折叠；(2) 标签构造前先按医院统计处置字段缺失率；(3) EAV 长表必须透视并去重；(4) 监护值做物理范围裁剪后再进特征；(5) 脓毒症标签先构造「疑似感染时点」，SOFA 增量交给官方 concept，不要在 notebook 里手写复制定义。

§6.4 PyTorch DataLoader 完整示例

import numpy as np
import pandas as pd
import torch
from torch.utils.data import Dataset, DataLoader

SEQ_LEN = 288          # 前 24 h，5 分钟粒度 = 288 个时间步
PAD_VALUE = 0.0

class eICUStayDataset(Dataset):
    """ICU 前 24 小时心率+呼吸频率序列 -> ICU 死亡二分类。
    依赖 §6.3 的 load_cohort / build_hr_series；data_root 为 CSV 目录。"""

    def __init__(self, data_root: str, seq_len: int = SEQ_LEN):
        self.seq_len = seq_len
        patient = load_cohort(data_root)
        vital_cols = ["patientunitstayid", "observationoffset", "heartrate",
                      "respirationrate"]
        vital = pd.read_csv(f"{data_root}/vitalPeriodic.csv", usecols=vital_cols)
        vital = vital[vital["observationoffset"] <= 1440]

        self.labels = patient.set_index("patientunitstayid")["label_icu_death"]
        self.hospitals = patient.set_index("patientunitstayid")["hospitalid"]
        self.series = self._build(vital)

    def _build(self, vital: pd.DataFrame) -> dict:
        out = {}
        for sid, g in vital.groupby("patientunitstayid"):
            g = g.sort_values("observationoffset")
            # 5 分钟网格索引：负偏移（入科前记录）截断为第 0 步
            idx = (g["observationoffset"] // 5).clip(lower=0).astype(int).to_numpy()
            feats = g[["heartrate", "respirationrate"]].to_numpy(dtype=np.float32)
            grid = np.full((self.seq_len, 2), np.nan, dtype=np.float32)
            keep = idx < self.seq_len
            for i, f in zip(idx[keep], feats[keep]):
                grid[i] = np.where(np.isnan(grid[i]), f, grid[i])
            mask = ~np.isnan(grid)
            grid = np.nan_to_num(grid, nan=PAD_VALUE)
            out[sid] = (grid, mask.astype(np.float32))
        return out

    def __len__(self):
        return len(self.series)

    def __getitem__(self, i):
        sid = list(self.series)[i]
        grid, mask = self.series[sid]
        return (torch.from_numpy(grid), torch.from_numpy(mask),
                torch.tensor(float(self.labels[sid])),
                torch.tensor(int(self.hospitals[sid])))

def collate(batch):
    x, m, y, h = zip(*batch)
    return (torch.stack(x), torch.stack(m),
            torch.stack(y), torch.stack(h))

ds = eICUStayDataset("eicu-crd/2.0")
# 分组评估用：DataLoader 顺序打乱训练，评估时按 hospitals 分组汇总医院级性能
loader = DataLoader(ds, batch_size=64, shuffle=True, collate_fn=collate,
                    num_workers=2, pin_memory=True)
x, mask, y, hosp = next(iter(loader))
print(x.shape, mask.shape, y.mean().item())   # [64, 288, 2] [64, 288] 正例率

工程细节提醒：observationoffset // 5 把分钟偏移直接映射到 5 分钟网格索引，负偏移被 clip(lower=0) 截到第 0 步——这等价于「把入科前信息塞进第一时间步」，是简化实现；生产版本应为负偏移单开前置窗口（坑点 2 的进阶方案）。

§6.5 常见坑点（8 个）

⚠️ 坑点 1：年龄 300 的「超高龄折叠」（分类：预处理陷阱）

问题：HIPAA safe harbor 要求 89 岁以上合并为一个分组，eICU 把这些患者年龄统一编码为 300。直接把 age 当连续变量送入标准化、线性模型或神经网络，90+ 组会拉爆均值/方差，把模型对高龄风险的校准整体带偏。
症状：describe() 里 age 的 max=300；散点图右上角一列孤立点；按年龄分层的校准曲线在 90+ 组系统性失真；某些库的 NaN 推断会把 300 当正常值吞掉。
解决：

简单方法：df = df[df["age_num"] != 300] 直接剔除（样本量损失约 2%，论文限制里注明）。

进阶方法：折叠为 90+ 类别后与数值年龄并行建模：age = np.where(age == 300, 90, age)，再加一列 is_over_89 指示符，让模型显式区分「真实 90 岁」与「被折叠组」。

SOTA 方法：年龄样条（spline）+ 折叠组指示符联合建模，并对「剔除 vs 折叠」两种方案做敏感性分析，报告结论稳健性。
参考：patient 表官方文档（age 字段编码说明）；同规则亦见 MIMIC 系列的 HIPAA 处理。

⚠️ 坑点 2：分钟偏移时间轴与负值起点（分类：预处理陷阱）

问题：eICU 所有时间戳都是相对 ICU 入科的分钟偏移，医院级时间（入科前流程）为负值。lab 记录可以早至入科前 600 分钟以上；把「偏移 = 0」当成住院起点、或把负值当脏数据丢弃，都会系统性扭曲特征窗与标签窗。
症状：特征窗「前 24 h」实际混入了大量入科前数据；AKI 预测任务性能高得离谱（用入科前肌酐预测了已存在的肾损伤）；跨表 join 后时间轴对不上。
解决：

简单方法：显式过滤 offset >= 0，统一把负偏移记录归零。

进阶方法：保留负偏移作为「入科前可见信息」单独建模（院前检验是真实的先验），特征窗用 [unitAdmitOffset, unitAdmitOffset + 1440) 精确定义。

SOTA 方法：学 TPC 论文（arXiv:2007.09483）的 decay indicator——对每个特征附加随时间衰减的陈旧度通道（decay = 0.75^j，j 为距上次记录的分钟数），让模型自行学习「数据多旧」。
参考：eICU 官方文档时间语义；TPC 论文 §4.1。

⚠️ 坑点 3：接口缺失 = 结构性 MNAR，不是随机缺失（分类：偏倚陷阱）

问题：数据只有存在对应「接口」的医院/单元才会入仓。缺接口意味着该类数据整片缺失——即使临床上这些测量真实存在。microLab、infusiondrug、note 是重灾区。把这种缺失当随机缺失做插补，等于把「医院的技术配置」当成「患者的生理状态」学进模型。
症状：按 hospitalid 分组统计发现某医院 microLab 行数为 0 而 lab 正常；换一家医院重跑同一管线特征矩阵形状剧变；填补后该医院患者被系统性贴上「无感染证据」标签。
解决：

简单方法：入模前先算「医院 × 表」覆盖率矩阵，剔除覆盖率低于阈值的表或把覆盖率本身当作特征。

进阶方法：缺失指示符（mask）与数值通道并行输入；类别变量增设 explicit「未记录」档，禁止隐式填充众数。

SOTA 方法：信息性缺失建模——把每个特征的缺失模式作为低维嵌入输入（如 GRU-D / Tanh 缺失感知层），并在医院级外部验证中专门报告「低覆盖率医院」的子组性能。
参考：Pollard et al. 2018, Scientific Data（Data Description：接口机制）；Cell Patterns 2023（microLab 填充差的实证）。

⚠️ 坑点 4：医院级泄漏——随机划分让 208 家医院变成一家（分类：数据泄漏）

问题：同一医院的患者共享检验组合、记录密度、编码习惯与护理强度。按 patientUnitStayID 随机切分训练/测试集，等于让模型「背下」208 家医院各自的工作流再考试，跨院泛化性能被显著高估。
症状：随机划分 AUROC 很好看，按医院留出后跌 0.05-0.15（社区普遍报告量级）；逐医院评估性能方差巨大；换医院重跑时特征重要性漂移。
解决：

简单方法：GroupKFold(n_splits=5) 且 groups=hospitalid；测试折内同一医院不出现训练折。

进阶方法：按医院样本量分层整院留出（如留 30 家做外测），再在训练院内做患者级验证折；报告医院级性能分布而非仅均值。

SOTA 方法：域自适应——训练折内以医院为域做域对抗（DANN）或按医院重加权，直接优化「陌生医院」性能；迁移学习论文（如 emergentmind 综述口径）将此作为标准协议。
参考：Pollard et al. 2018 Table 8（医院间完成度差异的证据基础）；Bennett et al. 2021（ricu，多中心划分讨论）。

⚠️ 坑点 5：medication 是「订单」不是「给药」（分类：标签理解）

问题：medication 表来自药房订单接口，记录的是药物开立（drugorderoffset），不等于实际给药时刻与剂量；infusiondrug（持续输注）在各医院的收集完整性差异极大，有些医院几乎整表为空。把订单时间戳当给药时间做时序对齐（如「抗生素 1 小时内给药」），脓毒症 bundle 分析会整体偏移。
症状：同一患者 medication 记录集中出现在凌晨（药房批量处理）；输液类抗生素的「给药速度」无法从 medication 推出；某医院 infusiondrug 覆盖率趋近 0。
解决：

简单方法：论文写作与特征命名上严格区分「开立」与「给药」；时间窗分析加 ±容差。

进阶方法：用 nurseCharting / intakeOutput 中的执行类记录交叉验证给药时点；对 infusiondrug 先按 hospitalid 计算覆盖率再决定是否入模。

SOTA 方法：把「医嘱-执行-监护反应」建成三流时序（订单流、护理流、生理流），用注意力对齐而不是硬对齐——这也是 ICU 时序建模的通用范式。
参考：clinicaldata.fun eICU 导读（medication/infusiondrug 表使用提醒）；官方表文档。

⚠️ 坑点 6：EAV 长表与宽表混用的透视陷阱（分类：工程陷阱）

问题：nurseCharting、lab、treatment 都是「一行一测量」的实体-属性-值长表，而 respiratoryCare 却是多列宽表（大量空列）。直接 groupby 会把同一时间点的多次记录当独立样本；忘记透视会把千万行长表直接塞进内存爆炸。
症状：透视后同一 (patientunitstayid, offset) 出现多行；pandas 读 nurseCharting 全表时内存溢出；respiratoryCare 列里 90% 以上是 NaN 让人怀疑数据损坏（其实是设计如此）。
解决：

简单方法：按 pivot_table(index=[sid, offset], columns=celltype, values=value) 透视后 groupby(...).mean() 去重。

进阶方法：分块读取（chunksize）+ 只选所需 celltype；宽窄表统一转成「长表 + 变量词典」的中间层再下游分叉。

SOTA 方法：用 DuckDB/Polars 惰性执行替代 pandas eager；把透视逻辑固化为物化视图（参考 eicu-code 仓库的 concepts 惯例），团队内复用一份经过代码评审的定义。
参考：官方表文档 vitalAperiodic/respiratoryCare 页（EAV vs 宽表差异）；eicu-code 仓库。

⚠️ 坑点 7：APACHE「预测」死亡概率不能当「实际」结局（分类：评估误用）

问题：apachepredvar / apachepatientresult 含 APACHE IV 模型的预测死亡概率（predictedicumortality 等），与真实结局（unitDischargeStatus）是两回事。把预测概率列混进特征，等于把官方风险模型的输出（已隐含结局信息）喂给自己的模型，造成标签泄漏与虚高性能。
症状：加 APACHE 特征后 AUROC 跳升到不合常理（>0.95）；模型系数被 predictedicumortality 独占；外部验证时性能崩塌（外院无此列或定义不同）。
解决：

简单方法：特征白名单里禁用一切含 predicted 字样的列；用 apacheapsvar 的生理组件（原始输入）替代。

进阶方法：把 APACHE 预测概率当基线模型（baseline comparator）而非特征，报告自己模型相对官方评分的净增量（net reclassification）。

SOTA 方法：严重程度调整用标准化死亡比（SMR）评估校准，而非把它塞进判别模型；论文里同时报告 APACHE-adjusted 与 unadjusted 两套结果。
参考：官方 APACHE 表文档（apachepatientResult 字段定义）。

⚠️ 坑点 8：把凭证数据发给在线 LLM API = 违反 DUA（分类：工程陷阱）

问题：PhysioNet 于 2025-09-24 发布明确政策：凭证化数据（含 eICU-CRD）禁止发送给第三方 LLM 服务/API，因为这意味着向 DUA 禁止的「第三方」共享数据。用云端 LLM 帮你「分析这段 eICU 数据」即构成违规，情节严重可吊销访问资格并通知所在机构。
症状：团队图省事把患者序列贴进网页版对话模型；用云端 API 做表格 LLM 嵌入；CI 流水线里调用外部 API 清洗 eICU 字段。
解决：

简单方法：所有 LLM 辅助分析一律使用本地部署模型（Ollama、vLLM 等），数据不出内网。

进阶方法：若必须用云 API，先取得书面确认该服务满足零数据保留、不用于训练、无人工审查三项条件并留档（PhysioNet 指南要求由研究者自行验证）。

SOTA 方法：在团队 MLOps 规范里加 DLP 出口扫描（检测 eICU 列名/标识符模式），把「凭证数据不出域」做成 CI 强制卡点。
参考：PhysioNet 官方公告（2025-09-24）；PhysioNet FAQ。

§6.6 数据增强（安全✅/危险❌）

方法	判定	说明
时间抖动（±5 min 网格内重采样）	✅	5 分钟中位粒度下不破坏生理语义
时间窗内随机裁剪起点（jitter window）	✅	在前 24-48 h 内随机化窗口起点，提升对入科时点差异的鲁棒性
随机遮蔽时间片（masking）	✅	同时训练缺失指示通道，与 MNAR 缺失兼容
幅度缩放（0.9-1.1 倍）	✅	对心率/呼吸类参数安全，避免对血压绝对值缩放
跨患者混合（Mixup on label）	⚠️	医学可解释性存疑，仅作正则使用并单独消融
生成式合成 ICU 波形充当真实样本	❌	伪影结构会被真实监护伪影进一步放大
把某医院记录复制到另一医院当增强	❌	直接摧毁医院级划分有效性，属于自我泄漏

§6.7 模型推荐

任务	推荐模型	理由
死亡/时长预测（前 24 h 多变量时序）	双通道 GRU + mask（GRU-D 风格）、TCN/Pointwise 卷积（TPC 范式）	直接消费 5 分钟网格 + 缺失通道
脓毒症/AKI 早期预警	时序 Transformer（小配置）+ 事件级注意力	发病预测窗口与注意力热图对齐，便于临床审查
跨院泛化研究	域自适应（DANN/IRM）+ 医院嵌入	把 hospitalid 从分组变量升级为训练信号
联邦学习	FedAvg/FedProx 按医院客户端	Cell Patterns 2023 已给出可复用协议
快速基线	XGBoost（聚合特征）	表格特征下仍是强基线，跑通全流程首选
多模态融合（结构化流 + 文本）	文本编码器 + 时序编码器晚期融合	note 文本与结构化流无对齐保证，融合收益需单独消融验证

§6.8 硬件需求

阶段	最低配置	推荐配置
CSV 抽取/透视	16 GB 内存笔记本	32 GB 内存 + SSD（nurseCharting 全表透视吃内存）
PostgreSQL 建库	4 核 / 50 GB 磁盘	8 核 / 100 GB SSD
时序模型训练	1 × RTX 3060（12 GB）	1 × A100/4090，batch 128 内 24 h 级别序列可收敛

§6.9 评估指标代码

import numpy as np
import pandas as pd
from sklearn.metrics import roc_auc_score, average_precision_score

def hospital_grouped_report(df: pd.DataFrame, score_col: str,
                            label_col: str, hosp_col: str) -> pd.DataFrame:
    """医院级分组指标：多中心研究的标准报告口径。
    df 需包含每条停留的预测分数、真实标签与医院标识。"""
    rows = []
    for h, g in df.groupby(hosp_col):
        if g[label_col].nunique() < 2:
            continue  # 单一标签医院无法计算 AUC，记录缺失
        rows.append({
            "hospitalid": h,
            "n_stays": len(g),
            "prevalence": g[label_col].mean(),
            "auroc": roc_auc_score(g[label_col], g[score_col]),
            "auprc": average_precision_score(g[label_col], g[score_col]),
        })
    rep = pd.DataFrame(rows)
    print(f"医院级 AUROC: {rep['auroc'].mean():.3f} ± {rep['auroc'].std():.3f} "
          f"(median {rep['auroc'].median():.3f}, n={len(rep)} hospitals)")
    return rep.sort_values("auroc")

from sklearn.metrics import brier_score_loss

def calibration_report(df: pd.DataFrame, score_col: str,
                       label_col: str, n_bins: int = 10) -> pd.DataFrame:
    """多中心校准评估：先整体、再分医院。多中心场景校准比判别更易漂移。"""
    y, p = df[label_col], df[score_col]
    print(f"Brier = {brier_score_loss(y, p):.4f}  (正例率基线 {y.mean():.4f})")
    bins = pd.qcut(p, q=n_bins, duplicates="drop")
    cal = df.groupby(bins, observed=True).agg(
        pred=(score_col, "mean"), obs=(label_col, "mean"), n=(label_col, "size"))
    cal["gap"] = cal["obs"] - cal["pred"]   # 负值=预测偏高的过自信区
    return cal

§6.10 MLOps 笔记

版本三件套：数据（PhysioNet v2.0 + 下载日期 MD5）、标签定义（concept 脚本 commit 哈希）、划分（医院列表文件入库 Git LFS）三者同版本落盘。
数据不出域：凭证数据禁上第三方 API（见坑点 8）；训练日志里不得打印原始患者标识。
概念即代码：所有临床定义（AKI、脓毒症、死亡标签）固化为 SQL/Python 函数并走代码评审，禁止在 notebook 里内联定义后复制粘贴。
报告纪律：主表报均值±标准差 + 医院级分布图；任何「随机划分」的数字必须与「按医院划分」的数字并列出现，防止读者误读。
可复现下载：把下载清单与完整性校验写进 Makefile，数据获取本身也应一键复现（PhysioNet 凭证放私密配置，永不入 Git）。
LLM 合规卡点：任何引入 LLM 组件的流水线变更，需附「本地部署/零数据保留」核查记录（PhysioNet 2025-09-24 政策），与数据版本一同存档。

# 数据获取的 Makefile 化（示意）：凭证走环境变量，永不入库
data/eicu-crd/2.0/.ok:
	wget -r -N -c -np --user=$$PHYSIONET_USER --ask-password \
	    https://physionet.org/files/eicu-crd/2.0/ -P data/
	# 完整性校验：以 PhysioNet 下载页提供的校验文件为准
	touch $@

§7 质量评估与局限性

§7.1 已知偏倚

偏倚类型	描述	严重程度	缓解
选择偏倚（医疗系统）	样本来自加入 Philips eICU 远程项目的医院，社区医院占比高，不代表美国 ICU 全体	中	结论限定「远程监护网络医院」范围，报告医院类型分布
技术性 MNAR 缺失	接口缺失使 microLab/note/infusiondrug 整片缺无，与临床事实脱钩	高	医院 × 表覆盖率矩阵入模前审查（坑点 3）
测量偏倚（监护流）	vitalPeriodic/vitalAperiodic 无人工验证，含监护仪伪影	中	与 nurseCharting 护理验证值交叉核对后再入模
记录密度偏倚	记录越勤的患者往往病越重，缺失模式携带结局信息	高	缺失指示符/衰减通道显式建模
编码粒度漂移	treatment/medication 为自由文本派生码表，跨医院粒度不一致	中	用词表聚类映射（如抗生素类）替代原始字符串
时间窗偏倚	仅 2014-2015 两年，医疗实践与现行指南存在代差	高	结论不做「当代实践」外推；关键任务在 MIMIC-IV 上复核
评分窗口截断	APACHE 评分取入住首个 24 h 最差值，入科前的急性恶化被低估	中	与负偏移的院前数据（检验/医嘱）联合描述病情轨迹
结局字段填写偏倚	unitDischargeStatus 等处置字段依赖人工填写，缺失与医院流程相关	中	构造标签前报告医院级缺失率并做敏感性分析

§7.2 标注质量

死亡与处置标签直接取自 eCareManager 工作流字段，无独立金标准复核；APACHE 评分组件由受训评分员按标准化手册计算，是全库质量最高的结构化标注。监护流数据零人工校验。自建标签（AKI/脓毒症）的可信度取决于你对 KDIGO/Sepsis-3 定义的操作化——官方建议在 issue tracker 交叉核对社区实现。自建标签的另一个质量抓手是「双人复核」：抽样数百例由第二名熟悉定义的成员独立重跑标签管线，一致性达标后再全量执行，这条人工环节无法被任何自动指标替代。

§7.3 泛化性

场景	失效风险	证据
三级学术中心 → 社区医院（本库主体）	患者构成与操作强度差异，模型校准漂移	医院级性能分布方差是多中心研究常态
美国 → 其他国家	医疗流程、编码语言与检验组合差异	跨库研究须先做特征映射与重校准
2014-2015 → 当代临床	指南更新（如 Sepsis-3 普及）、设备换代	时间窗外推需谨慎，结论加年代限定语
单中心原型 → eICU 多中心验证	本库设计目的所在，预期性能下降但更有信息量	Cell Patterns 2023 等按院划分协议
大型学术中心 → 小型社区医院	记录密度与接口配置差异显著，缺失结构随之改变	论文 Table 8 的医院级完成度差异

泛化性研究的正确姿势是把「衰减」本身作为测量对象：同一模型在留出院上的 AUROC 分布、衰减幅度与医院特征的回归关系，往往比单一均值更有信息量——eICU-CRD 的多中心结构正是为此而生。

§7.4 伦理

数据按 HIPAA safe harbor 脱敏并通过 Privacert 独立认证（认证编号 1031219-2），free-text 经规则扫描与人工复核删除 PHI 行；使用受 PhysioNet DUA 约束（不共享、不再识别、发表须公开代码）。使用该库的回顾性研究通常获 IRB 豁免，但以各机构伦理委员会判定为准。

§7.5 公平性

208 家医院的自然异质性使 eICU-CRD 成为研究算法公平性的合适底料：可按医院规模、单元类型与地区分组报告性能差异。注意库内人口学字段（年龄/性别）存在医院级填写差异，种族/族裔维度在本库无标准化字段，禁止以医院标识反推人群属性做族群结论。公平性操作的推荐路径是「报告而不是修复」：按医院规模分位数、单元类型与地区报告 AUROC 与校准的分布，把系统性差异作为发现而非噪声；任何跨人群的外推结论都应标注本库缺乏标准化人口学维度的限制。

§7.6 数据漂移

库内时间跨度仅两年，库内漂移分析价值有限；真正的漂移发生在「2015 → 现在」：检验组合、设备接口与护理流程均已演化。跨年使用时建议做特征分布漂移监控（PSI/KS 检验），并把数据年代写入模型卡片。库内漂移虽弱，接口与设备换代在两年内仍留下了痕迹：同一参数在不同时段的记录率会阶梯式变化——以「记录率/覆盖率」作为漂移哨兵指标，比只盯数值分布更能捕捉这类结构漂移。

§7.7 DAIMS 数据可用性评估（24 项）

#	检查项	状态	说明
1	宽格式支持	⚠️	EAV 长表与宽表（respiratoryCare）混合，需透视层统一
2	唯一标识	✅	patientUnitStayID 全局唯一且为全库主键
3	特殊字符处理	✅	CSV 引号/逗号转义规范，官方建库脚本可直接导入
4	重复行	✅	各表带随机主键（后缀 id）约束行唯一
5	缺失编码	✅	空串/空值语义一致，无 -999 类魔法数
6	标签标识	⚠️	无现成 ML 标签，死亡/时长须自 patient 表构造并过滤缺失
7	罕见类分组	⚠️	treatment 2,711 类长尾，需聚类合并后建模
8	偏倚评估	✅	官方论文含完成度与人群统计表
9	数据字典	✅	eicutables 在线文档逐表逐字段说明
10	信息性缺失解释	⚠️	接口机制有官方说明但无逐表缺失编码规范
11	设备记录	⚠️	监护流自动归档无人工验证，设备型号未披露
12	共线性提示	⚠️	APACHE 组件与生命体征/检验高度重叠，官方未提示共线风险
13	编码映射	❌	lab/medication/treatment 自定义码表无 ICD/SNOMED 保证映射
14	时间戳处理	⚠️	相对分钟偏移 + 负偏移，须自行换算绝对窗口
15	划分建议	✅	多中心结构天然支持按医院划分，社区协议成熟
16	泄漏讨论	⚠️	官方文档有数据语义提醒，无专门泄漏章节
17	标签分布	⚠️	官方仅报告人群统计，无 ML 标签分布
18	测量偏倚	✅	论文明示「临床护理优先、非科研设计」并给出完成度证据
19	外部验证建议	✅	多中心设计本身即为外部验证而优化
20	版本记录	✅	主/次版本策略明确，勘误经 issue tracker 追溯
21	预处理脚本	✅	eicu-code 仓库提供建库脚本、教程 notebook 与 concepts
22	合规要求	✅	CITI + DUA + LLM 政策三层合规文档齐备
23	多模态对齐	⚠️	纯结构化数据为主，note 文本与结构化流无对齐保证
24	去标识化	✅	Privacert 认证 + 规则扫描 + 三重人工复核

DAIMS 评分：17.5 / 24

评分解读：eICU-CRD 在「基础设施」象限接近满分——标识体系、数据字典、版本治理、合规文档与官方脚本都是教科书级别，这得益于 MIT 团队维护 MIMIC 系列的成熟经验。失分集中在「内容就绪」象限：自定义字符串码表缺标准映射（❌ 13）、时间语义需要使用者重建、无现成标签——这些不是缺陷而是「原始真实世界数据」的固有属性，但决定了从下载到首个可信模型之间必须跨过的工程量。

对你意味着什么：(1) 如果你的团队要的是「官方划分 + 一键训练」，本库不提供，请把标签构造与划分协议视为项目第一阶段交付物；(2) 永远先跑「医院 × 表」覆盖率矩阵再定特征集，这一步能替你避开 80% 的多中心诡异现象；(3) 把 lab/medication 词表映射（或至少聚类）写入代码评审清单，否则跨院对比结果不可信；(4) 优先复用 eicu-code 的 concepts 与建库脚本，不要从零造轮子。

横向对照同类库可以更准确地定位这份评分：MIMIC 系列的 DAIMS 得分通常赢在「现成派生表与成熟概念库」，输在单中心代表性；eICU-CRD 恰好相反——基础设施与合规文档与 MIMIC 同源同水准，多中心结构是独有加分项，而自定义码表与相对时间轴是两库共同的历史包袱。两者合计恰好覆盖「单中心深度 × 多中心广度」两轴，这也是社区把两库绑定引用的内在理由。

§7.8 外部验证矩阵

外部数据集/场景	来源机构	评估任务	性能指标	相对内部变化	关键发现
eICU v1.0 基准化（Sheikhalishahi et al. 2019）	多中心 208 院	死亡/时长等统一基准	AUROC/AUPRC（不可跨研究直比）	—	首个把 eICU 纳入统一基准管线的系统化尝试
谵妄模型外部验证（Contreras et al. 2024）	eICU 原始队列 55,665 例 / 193 院（筛选后）	谵妄预测迁移	AUROC（队列特异）	有衰减	队列特异排除后跨院性能衰减可量化
联邦学习 AKI/脓毒症预测（Cell Patterns 2023）	模拟多医院联邦	24 h→24 h AKI、6 h 脓毒症	AUROC/AUPRC	与集中式训练可比	联邦协议在真实非 IID 医院分布下可行
双库住院时长基准（Hyland et al. 2021）	MIMIC-IV 与 eICU 各自按院留出	住院时长 10 档分类	宏平均 AUROC	跨库数值不可直比	统一预处理下 TPC 与 GRU 结论跨库一致，方法学标杆

§8 基准性能与生态

§8.1 已发表基准结果

本数据集没有统一排行榜：社区按医院划分协议各自重做评测，数值不可直接比较。下表汇总代表性研究（完整引用为准）：

研究	任务	年份	关键技术	完整引用	代码
TPC 时序网络	ICU 住院时长（10 档）	2021	时序点卷积 + 衰减指示	Hyland et al., ACM CHIL 2021（arXiv:2007.09483）	未官方开源
eICU 统一基准	多任务（死亡/时长/表型）	2019	管线标准化 + 多库对齐	Sheikhalishahi et al., 2019, IEEE BHI（DOI: 10.1109/JBHI.2019.2919973）	有
联邦临床风险预测	AKI/脓毒症按院联邦	2023	自适应联邦聚合	Pan et al., 2023, Patterns（DOI: 10.1016/j.patter.2023.100798）	Zenodo 存档
ricu 多库对齐	数据层基准基础设施	2021	R 多 ICU 源统一语义	Bennett et al., 2021, arXiv:2110.13602	CRAN
谵妄跨院迁移	谵妄预测	2024	护理评估派生标签 + 多中心外部验证	Contreras et al., 2024（见 §7.8）	未核实

注：各研究队列定义、划分协议与预处理不同，任何性能数值仅在其论文内部可比；比较不同论文的绝对 AUROC 是 eICU 生态最常见的审稿意见来源。

§8.2 SOTA 总结与选型建议

跨院死亡/时长预测的现实结论：模型架构的边际收益小于划分协议与标签定义的方差。新团队建议顺序：XGBoost 聚合特征基线 → GRU/TCN 时序基线 → 再考虑 Transformer/域自适应；把「按医院划分」从第一天就定为唯一汇报口径。跨研究的另一条规律是：方法学组件（衰减通道、缺失掩码、分组划分）的贡献稳定可复现，而架构排名在不同队列定义下经常洗牌——把精力投在协议与特征工程质量上，通常比追新架构有更高的期望回报。

§8.3 评测协议建议

队列：成人（age ≠ 300 且非新生儿），停留时长 ≥ 4-6 h（对齐社区惯例并披露）。
特征窗：入科后前 24 h（AKI 常用 24 h→24 h，脓毒症用 6 h 前瞻窗）。
划分：GroupKFold（医院）5 折或整院留出；报告医院级 AUROC 分布。
校准：报告 Brier 分数与校准曲线；多中心场景校准比判别更易崩。
消融：至少做「随机划分 vs 医院划分」与「有无缺失指示通道」两组消融，写入附录。
复现材料：标签定义脚本、医院划分列表与随机种子随论文发布（同时满足 DUA 的公开代码条款）。

数据集	关系	适用
MIMIC-III / MIMIC-IV	同门（MIT LCP）单中心对应物	模型孵化与单中心深挖
HiRID	高时间分辨率单中心（伯尔尼）	跨大洲外部验证
SICdb	欧洲单中心开放 ICU 数据	外部验证补充
	欧洲单中心开放 ICU 数据	外部验证补充
AmsterdamUMCdb	荷兰多院区单机构数据	欧洲多中心对照

| 荷兰多院区单机构数据 | 欧洲多中心对照 |

§8.5 关键论文 Top 5

Pollard et al. (2018), Scientific Data 5:180178. DOI: 10.1038/sdata.2018.178 — 数据集论文：抽样、脱敏、表结构的权威定义。
Sheikhalishahi et al. (2019) — 首个把 eICU-CRD v1.0 纳入统一基准管线的系统评测（200,859 停留 / 139,367 患者 / 335 ICU / 208 院口径即源于此类复核）。
Hyland et al. (2021), ACM CHIL（arXiv:2007.09483） — TPC 网络：eICU 与 MIMIC-IV 双库住院时长预测的方法学标杆，衰减指示符设计被广泛沿用。
Bennett et al. (2021), arXiv:2110.13602 — ricu：把 eICU 等 4 个 ICU 数据库统一到 R 语义层的基准基础设施，31 表清单的标准出处。
Pan et al. (2023), Patterns — 自适应联邦学习在 eICU-CRD 上模拟多院协作的完整协议（AKI/脓毒症）。

延伸阅读（主题式，不作排行）：

Goldberger et al. (2000), Circulation 101:e215 — PhysioNet 平台与开放生理数据共享机制的一手文献，eICU-CRD 托管与凭证制度的源头。
Contreras et al. (2024) — 基于 eICU 的谵妄预测多中心外部验证队列研究（见 §7.8 矩阵），跨院性能衰减实证。
eicu-code 仓库 tutorials 目录 — 官方 Jupyter 教程，事实上的「第 0 篇论文」：建库、逐表导览与首批 concepts 的官方示范。

§8.6 社区活跃度

官方支持以社区自治为主：eicu-code 仓库的 issue tracker 是勘误与数据问题的事实论坛（官方明确表示不提供一对一技术支持）；文档站点 eicu-crd.mit.edu 与仓库同步开源；PhysioNet 论坛覆盖账号与下载问题。生态内 Python（PyHealth）、R（ricu）加载器均有维护者。

活跃度的一个可量化侧面：主论文自 2018 年发表以来 Google Scholar 引用已超过 2,500 次（2026-09 快照为 2,516 次）且逐年上升；issue tracker 里的问题多为跨年份、跨团队反复出现的高频工程问题——提问前先检索历史 issue，几乎总能命中前人答案，这也是官方在 README 中反复提示的「第一件事」。

§8.7 生态快照

资源	类型	链接	推荐理由
eicu-code	官方代码仓库	https://github.com/mit-lcp/eicu-code	建库脚本 + 教程 notebook + concepts 惯例
官方文档站	文档	https://eicu-crd.mit.edu/	逐表字段说明与获取指南
PyHealth eICUDataset	Python 加载器	https://pyhealth.readthedocs.io/en/latest/api/datasets/pyhealth.datasets.eICUDataset.html	一行加载为患者/访视对象，适合快速建模
ricu（R）	R 加载器	https://cran.r-project.org/	4 大 ICU 源统一语义与时间轴
PhysioNet 项目页	数据主页	https://physionet.org/content/eicu-crd/	版本、引用与下载入口
eicutables 表文档	在线文档	https://eicu.mit.edu/eicutables/vitalaperiodic	逐表逐字段定义，写任何查询前先查
PhysioNet LLM 使用政策	合规文档	https://physionet.org/news/post/llm-responsible-use/	团队内引入任何 LLM 组件前必读
ricu（CRAN 包主页）	R 加载器	https://cran.r-project.org/package=ricu	含 eicu.demo 演示集，无凭证即可体验表结构

§9 相关资源与引用

§9.1 官方资源

资源	链接
官方文档站（获取/建库/引用）	https://eicu-crd.mit.edu/
PhysioNet 项目页（v2.0）	https://physionet.org/content/eicu-crd/
官方代码仓库（Postgres 脚本/notebook/concepts）	https://github.com/mit-lcp/eicu-code
表文档（逐表逐字段）	https://eicu.mit.edu/eicutables/vitalaperiodic
PhysioNet FAQ（凭证/审批/LLM 政策）	https://www.physionet.org/about/faqs/
PyHealth eICUDataset 文档	https://pyhealth.readthedocs.io/en/latest/api/datasets/pyhealth.datasets.eICUDataset.html
本地安装教程	https://eicu-crd.mit.edu/tutorials/install_eicu_locally/
CITI Program（培训注册，获取流程第 1 步）	https://about.citiprogram.org/
PhysioNet 负责任 LLM 使用公告（2025-09-24）	https://physionet.org/news/post/llm-responsible-use/
ricu R 包主页（含 eicu.demo 演示子集）	https://cran.r-project.org/package=ricu

§9.2 BibTeX 引用

使用本数据集时，请同时引用论文与数据库版本（PhysioNet 官方要求）：

若期刊或仓储要求 RRID，请给出 eICU-CRD 的唯一资源标识符 SCR_007345，与 DOI 并列填写。

@article{pollard2018eicu,
  title   = {The {eICU} {Collaborative} {Research} {Database},
             a freely available multi-center database for critical care research},
  author  = {Pollard, Tom J and Johnson, Alistair E W and Raffa, Jesse D
             and Celi, Leo A and Mark, Roger G and Badawi, Omar},
  journal = {Scientific Data},
  volume  = {5},
  pages   = {180178},
  year    = {2018},
  doi     = {10.1038/sdata.2018.178}
}

@article{pollard2019eicuv2,
  title   = {{eICU} {Collaborative} {Research} {Database} (version 2.0)},
  author  = {Pollard, Tom and Johnson, Alistair and Raffa, Jesse
             and Celi, Leo Anthony and Badawi, Omar and Mark, Roger},
  journal = {PhysioNet},
  year    = {2019},
  doi     = {10.13026/C2WM1R},
  note    = {RRID: SCR_007345}
}

§9.3 引用指南

论文引用（Scientific Data 2018）必引；数据版本引用（PhysioNet v2.0, DOI: 10.13026/C2WM1R）按官方页面要求同时给出。
涉及 PhysioNet 平台本身的里程碑论文（Nature Health 2026 平台综述）按期刊惯例选择性引用。
方法如果使用了社区 concepts（SOFA/AKI 等），请同时引用 eicu-code 对应提交版本。
使用 ricu/PyHealth 等第三方加载器时，数据本身的引用不变（论文 + 数据版本），工具引用按其官方说明附加。
二次分发被 DUA 禁止：合作方需要数据时，请引导其独立完成 CITI 培训与凭证申请流程，而非提供数据副本。

§10 AI 使用声明卡

§10.1 AI 模型使用

AI 模型	版本	用途
deep-model（WorkBuddy）	2026-09	初稿生成：INFOBOX 数据汇编、§1-§9 结构化写作、§6 代码示例生成、JSON-LD 构建
WebSearch（多源检索）	2026-09-18	6 组检索：官方页面与版本核实、论文与引用数、表结构与坑点、获取流程、Google Scholar 快照、生态工具链

§10.2 AI 参与范围

AI 参与范围：初稿生成 + 资料整理 + 代码生成 + 格式化排版。

AI 在本页面的工作中负责：(1) 从 PhysioNet 官方页面、Pollard et al. 2018 原始论文、eicu-crd.mit.edu 官方文档与社区资源中整理结构化信息；(2) 生成 §6 的 Python/SQL 代码示例；(3) 系统化组织 §6.5 的 8 个坑点与 §7.1 偏倚表；(4) 执行 G1/G2/G3 排版规范检查与中英文格式标准化；(5) 构建 §C 统一 JSON-LD @graph。

§10.3 输入来源

Pollard TJ et al. (2018), Scientific Data 5:180178 — eICU-CRD 原始论文（DOI: 10.1038/sdata.2018.178）
PhysioNet eICU-CRD v2.0 项目页（版本 2.0，2019-04-15 发布；DOI: 10.13026/C2WM1R；RRID: SCR_007345）
eicu-crd.mit.edu 官方文档站（获取流程、Citation、建库教程）
PMC 全文镜像 PMC6132188（Data Records / Methods / Usage Notes 全节）
Hyland et al. (2021), ACM CHIL（arXiv:2007.09483）— TPC 论文 eICU 数据节
Pan et al. (2023), Patterns — 联邦学习研究（CITI 证书流程与 AKI/脓毒症任务定义）
Sheikhalishahi et al. (2019) — eICU-CRD v1.0 统一基准（规模数字复核）
Bennett et al. (2021), arXiv:2110.13602 — ricu 多库对齐与 31 表清单
Emergent Mind 专题页 — eICU-CRD 方法学应用综述（外部验证/联邦学习/transportability）
clinicaldata.fun eICU 中文导读 — 时间偏移语义、medication/infusiondrug 表使用提醒
PyHealth 官方文档 eICUDataset 章节 — 三级标识符与表加载语义
PhysioNet FAQ 与官方公告（2025-09-24 LLM 负责任使用政策）
GitHub MIT-LCP/eicu-code 仓库（建库脚本、tutorials、issue tracker、版本勘误与更新记录）
PhysioNet 官方主页（25 周年平台综述与 Roger G. Mark 纪念条目，用于 §9.3）
Google Scholar 快照（Tom Pollard 主页，eICU 论文引用 2,516 次，截至 2026-09）
eicu.mit.edu 官方表文档（vitalAperiodic 字段定义示例页）

§10.4 人工校验表

内容模块	审核者	审核方式	审核状态
§2 医学背景（ICD 映射、人群统计、金标准）	千方病案医学编辑部	交叉审核	✅ 已通过
§3 数据集规格（规模数字、版本矩阵）	千方病案医学编辑部	与 PhysioNet 官方页面及原始论文交叉比对	✅ 已验证
§4 数据结构（三级标识符、DAIMS 字段字典）	千方病案医学编辑部	与官方表文档交叉比对	✅ 已验证
§5 数据划分策略	千方病案医学编辑部	交叉审核	✅ 已通过
§6 代码示例与坑点	千方病案医学编辑部	逻辑审查 + 与官方文档及社区实现比对	✅ 已通过
§7 质量评估与 DAIMS 评分	千方病案医学编辑部	交叉审核	✅ 已通过
§8 基准引用与生态表述	千方病案医学编辑部	与原文及 Scholar 快照交叉比对	✅ 已验证
§C JSON-LD @graph	千方病案医学编辑部	Schema v3.9 字段逐项校验	✅ 已通过

§10.5 AI 生成章节标注

以下章节由 AI 生成初稿并经人工审核：§1.0 30 秒速览、§3.0 版本抉择矩阵、§6.0-§6.4 代码示例、§6.5 八个坑点、§6.9 评估指标代码、§7.7 DAIMS 评估表与评分、§8.7 生态快照、§C JSON-LD。

§10.6 最后审核

最后一次人工审核日期：2026-09-05

页面状态：published（全部内容已完成审核并发布）