INFOBOX


数据集名称	eICU Collaborative Research Database (eICU-CRD)
英文全称	The eICU Collaborative Research Database, a freely available multi-center database for critical care research
别名 / 简称	eICU-CRD、eICU、eICU v2.0、eICU Database
疾病分类	多疾病覆盖。核心：KB20-KB2Z 呼吸衰竭 / 1G40 脓毒症 / 8B20-8B2Z 脑血管疾病 / BA80-BA8Z 急性冠脉综合征 / 心脏骤停（MC82）
SNOMED CT	91302008 Sepsis / 410429000 Cardiorespiratory arrest / 230690007 Cerebrovascular accident / 394659003 Acute coronary syndrome / 426656000 Respiratory failure 等（详见 §2.2）
数据模态	结构化 EHR（人口统计 + 生命体征 + 实验室 + 药物 + 微生物 + 护理记录 + 诊断 + APACHE IV 评分）
AI 任务类型	死亡预测、住院时长预测、脓毒症检测、再入院预测、疾病表型分型、跨医院泛化评估、外部验证基准
样本总数	200,859 次 ICU 住院（来自 139,367 名患者，208 家美国医院，335 个 ICU 单元）
数据大小	~3.6 GB（压缩 CSV）/ ~35 GB（解压后 PostgreSQL）
数据格式	CSV（31 个表）/ 可导入 PostgreSQL / MySQL / BigQuery / SQLite
许可证	PhysioNet Credentialed Health Data License 1.5.0
访问级别	注册审核后开放（需 CITI 培训 + PhysioNet 凭证申请 + 签署 DUA，审批约 1-3 个工作日）
DUO 标签	HMB, NPUNCU
语言	英文
首发日期	2018-05-17（v1.0）/ 2018-09-11（Scientific Data 论文发表）
最后更新	2018-05-17（v2.0，当前最新版本）
发布机构	MIT 计算生理学实验室（Laboratory for Computational Physiology）与 Philips Healthcare 合作
官方主页	https://eicu-crd.mit.edu/
下载地址	https://physionet.org/content/eicu-crd/2.0/（需完成凭证申请后可见）
DOI	10.1038/sdata.2018.178
引用次数	1,900+（OpenAlex，截至 2026-07）
AI 就绪度评分	⭐⭐⭐⭐（4/5）— 31 表 CSV 统一格式 + 3 种医院级数据划分 + APACHE IV 金标准；扣分项：仅 2 年数据、时间以偏移量表示、患者跨住院追踪受限、自由文本被删除
页面状态	published

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

医学审核者：[千方病案医学编辑部]交叉审核：§2 医学背景（ICD-11/SNOMED CT 映射、临床任务定义、金标准描述）、§7 偏倚分析。

数据工程审核者：[千方病案医学编辑部交叉审核] 医疗 AI 数据工程师，审核范围：§4 DAIMS 数据字典、§5 数据划分策略、§6 预处理 Pipeline 和坑点。

审核日期：2026-07-28

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

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

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

§1 数据集概览

§1.0 30 秒速览

eICU Collaborative Research Database (eICU-CRD) 是 MIT 计算生理学实验室与 Philips Healthcare 于 2018 年联合发布的多中心重症监护公开数据集，覆盖 2014-2015 年间美国 208 家医院 335 个 ICU 单元中超过 20 万次 ICU 住院的高粒度数据。

它是全球唯一支持按医院划分训练/测试集的公开 ICU 数据库——研究人员可以将某些医院的全部数据作为外部验证集，真正评估模型在"从未见过"的机构中的泛化能力，而非仅在随机划分的同一医院患者间测试。这一特性使其成为 MIMIC 系列（单中心）的标准外部验证伴侣：eICU 训练→MIMIC 验证（或反之）已成为重症监护 ML 论文的标准审稿要求。

你可以用它来：开发跨医院泛化的 ICU 死亡预测模型、将 MIMIC 模型在 200+ 医院上做外部验证、利用 APACHE IV 金标准评分进行基准效果对照、或者研究护理文档跨机构差异对模型预测的影响。

§1.1 摘要

eICU-CRD 源自 Philips Healthcare 的 eICU 远程监护项目（TeleICU Program）。在 eICU 工作模式下，远程临床团队通过 eCareManager 系统集中监控多个医院的 ICU 患者数据——包括每分钟更新的生命体征、实验室结果、药物管理和护理记录。这些原本用于实时临床决策支持的数据经过 MIT LCP 的脱敏管道处理后，转换为 31 个 CSV 关系表公开发布。

数据集的核心创新在于多中心天然泛化评估框架：每个 patientUnitStayID（ICU 住院）都附有 hospitalID，允许在机构层面创建训练/验证/测试划分，模拟真实世界中模型部署到新医院的场景。这种"留一医院"（Leave-One-Hospital-Out）的实验设计正日益成为 ICU ML 研究的方法论标准。

§1.2 为什么重要

技术创新维度：在 eICU-CRD 发布之前，全球仅有一个大规模公开 ICU 数据库——MIMIC-III，且为单中心数据（Beth Israel Deaconess Medical Center，波士顿）。MIMIC 模型能否在其他医院复现？这是一个悬而未决的问题。eICU-CRD 以 208 家医院的多中心覆盖、335 个 ICU 单元的地理多样性，将"验证泛化性"从理论问题变为实际操作。

方法论维度：eICU-CRD 引入了一种新的研究范式——“按医院划分"替代"按患者随机划分”。传统 ML 中随机打乱所有患者再 8:2 切分训练/测试集，在同一医院内来自同一医生群体、同一设备、同一护理流程的数据间评估性能，可能严重高估真实世界泛化能力。eICU 的 hospitalID 使得 leave-one-hospital-out 成为可能，这已经成为 NeurIPS/ICML 等顶级会议的 ICU ML 论文标配��验设计。

生态推动维度：MIMIC 与 eICU 形成了互补的"双数据集评估体系"：MIMIC 提供深度（单中心、长跨度、多模态：文本+影像+波形），eICU 提供广度（多中心、跨机构变异性洞察）。两数据集间的交叉验证已产出数个高影响力研究——如 Johnson et al. (2018) 发现同一个死亡预测模型在 MIMIC 上训练后在 eICU 上测试 AUROC 下降 0.05-0.10，这揭示了"内部验证过拟合"的系统性风险。

§1.3 与同类数据集对比

数据集	样本量	中心数	时间跨度	模态	核心差异化
eICU-CRD	200,859 住院	208 家医院	2014-2015	结构化 EHR（31 表）	唯一的公开多中心 ICU 数据集，支持按医院划分
MIMIC-IV	546,028 住院	1 家医院	2008-2022	结构化 EHR + 文本 + CXR + ECG	单中心深度数据，附带影像与自由文本
AmsterdamUMCdb	23,106 住院	1 家医院	2003-2016	结构化 EHR	GDPR 合规欧洲数据，约 10 亿观测值
HiRID	~33,905 住院	1 家医院	2008-2016	结构化 EHR（681 变量）	全球最高时序分辨率（2 分钟），瑞士数据

§1.4 版本演进

时间	事件
2018-05	eICU-CRD v1.0 发布（PhysioNet）
2018-09-11	Pollard et al. 在 Scientific Data 发表数据描述论文，正式向学术社区介绍 eICU-CRD
2018-05-17	v2.0 发布（当前版本）——修复了部分数据问题，schema 微调，提供 Jupyter Notebook 示范代码
2020+	社区工具链成熟化：ricu R 包（Bennett et al. 2021）、eICU-code GitHub 仓库、BigQuery 公开数据集镜像
2025+	持续更新讨论中：新表、纠正已知问题、添加当代入院数据

§1.5 典型 AI 应用场景

跨医院死亡预测：在 200 家医院上训练，在剩余 8 家上测试，评估模型在未见机构的死亡预测性能
MIMIC→eICU 外部验证：将 MIMIC 训练的模型直接应用于 eICU 全量数据，检测分布偏移下的性能退化
脓毒症早期检出：利用高粒度生命体征数据（vitalPeriodic，5 分钟中位数）训练脓毒症预警模型
APACHE IV 基准对照：以 APACHE IV 评分作为传统方法的性能锚点，对比 DL/ML 模型的增量价值
护理文档跨机构异质性研究：利用 nurseCharting / carePlan 系列表的跨医院覆盖差异，分析机构文档实践对预测模型的影响

§2 医学背景

§2.1 ICD-11 编码

核心覆盖：KB20-KB2Z 呼吸衰竭 / 1G40 脓毒症 / 8B20-8B2Z 脑血管疾病 / BA80-BA8Z 急性冠脉综合征 / MC82 心脏骤停 / CB01-CB0Z 心力衰竭

eICU-CRD 的诊断数据存储于 diagnosis 表中，使用 eICU 专有诊断分类体系（非 ICD 编码），包含 3,933 种独特活动问题（Active Problems）。诊断以自由文本字符串存储，按层级分类：diagnosisString（具体诊断）嵌套在 diagnosisPath（分类路径）中。

§2.2 SNOMED CT 映射

eICU-CRD 的诊断体系不直接使用 SNOMED CT，但主要诊断可通过临床术语映射到标准 SNOMED CT 编码：

eICU 诊断文本	ICD-11	SNOMED CT	SNOMED CT 术语
Sepsis, pulmonary	1G40	91302008	Sepsis (disorder)
Cardiac Arrest	MC82	410429000	Cardiorespiratory arrest (disorder)
Cerebrovascular accident	8B20	230690007	Cerebrovascular accident (disorder)
Acute Coronary Syndrome	BA80	394659003	Acute coronary syndrome (disorder)
Respiratory Failure	KB20	426656000	Respiratory failure (disorder)
CHF (Congestive Heart Failure)	CB01	42343007	Congestive heart failure (disorder)

§2.3 疾病描述与流行病学

重症监护病房（ICU）收治因生命威胁性疾病或损伤需要持续监测和生命支持的患者。在美国，每年约有 500 万患者入住 ICU，ICU 床位占医院总床位的 10%-15%，却消耗了约 30% 的医院总费用。ICU 死亡率因疾病类型和严重程度而异，整体约为 8%-15%——在 eICU-CRD 中，整体住院死亡率为 6.5%（eICU 远程监护的患者群体可能对重症选择有偏倚）。

脓毒症是 ICU 中最常见的死亡原因之一，eICU-CRD 中脓毒症占合格住院的 16.4%（n=18,087）。脑血管意外（8.85%）、心脏骤停（8.28%）和急性冠脉综合征（7.57%）紧随其后，构成了 ICU 入院的主要疾病类别。

§2.4 临床任务定义

AI 任务	临床定义	数据中的操作化
死亡预测	预测 ICU/住院死亡结局	`hospitalDischargeStatus = ''''''''Expired''''''''`（住院死亡）；或 `unitDischargeStatus = ''''''''Expired''''''''`（ICU 内死亡）
住院时长（LOS）预测	预测 ICU 住院天数	`unitDischargeOffset / 1440`（分钟→天）
脓毒症检测	基于临床标准识别脓毒症	通过 `diagnosis` 表中脓毒症相关诊断 + `lab` 表中乳酸/血培养 + `vitalPeriodic` 生理异常组合
再入院预测	预测 ICU 出院后的重返概率	同一 uniquepid 下多个 patientUnitStayID 之间的 `unitDischargeOffset` 间隔
疾病严重程度分层	按死亡风险分群患者	APACHE IV 预测死亡率可作为分层标签的近似金标准

§2.5 患者人群

维度	特征
数据来源	美国 208 家医院的 335 个 ICU 单元，覆盖美国东北部、南部、中西部和西部多个地理区域
采集时间	2014-2015（2 年）
年龄分布	成人为主，年龄中位数约 65 岁，>89 岁按 HIPAA 规定分箱为"> 89"
性别比例	男性约 54%，女性约 46%
种族分布	高加索人（~77%）、非洲裔（~11%）、西班牙裔（~5%）、亚裔（~2%）、原住民（~1%）、未知/其他（~4%）
就医类型	成人 ICU 住院，含 MICU、SICU、CCU、CTICU、CSICU、Neuro ICU、Cardiovascular ICU 等 15+ 种 ICU 类型
入排标准	APACHE IV 评估时有排除标准：烧伤、ICU 停留 <4 小时、再入院、心脏手术患者（部分）等

§2.6 金标准/参考标准

数据划分	标注方式	标注者	金标准性质
全部数据	自动采集	床旁监护设备自动记录 + 护士验证	生命体征：vitalPeriodic（5 分钟自动中位数，未经验证）vs nurseCharting（护士人工验证并录入）——两者存在系统性差异
全部数据	APACHE IV 评分系统	eCareManager 自动计算（基于入院首 24 小时数据）	严重程度金标准，但仅约 60% 患者具有有效 APACHE IV 评分
全部数据	临床文档	医生诊断录入 + 护士护理记录	出院诊断（diagnosis 表）有临床权威性；护理流程记录（carePlan 系列）反映实际操作而非研究标准

§3 数据集规格

§3.0 版本抉择矩阵

你的需求	推荐版本	大小	理由
标准多中心研究	eICU-CRD v2.0	~3.6 GB (CSV)	当前唯一可用版本，含全部 31 表与完整 APACHE IV 数据
需要当代数据	❌ 暂无	—	v2.0 仅覆盖 2014-2015。FUture updates 计划中但尚未发布
BIGQUERY 快速探索	eICU-CRD on BigQuery	云端	Google Cloud 公开数据集镜像，免下载直接 SQL 查询
与 MIMIC 联合分析	v2.0 + ricu R 包	~3.6 GB	ricu 提供统一 API 同时查询 eICU 和 MIMIC-IV/III

§3.1 数据模态详细说明

eICU-CRD 是纯结构化关系型数据（31 个 CSV 表），无影像、无波形、无自由文本。数据可归纳为以下大类：

人口统计（patient 表）：年龄（分箱）、性别、种族、身高体重、入出院时间偏移
生命体征（vitalPeriodic + vitalAperioric）：心率、呼吸频率、SpO₂、血压（有创/无创）、体温——vitalPeriodic 为每 5 分钟固定间隔中位数，vitalAperioric 为非周期性观测
护士验证生命体征（nurseCharting）：护士人工录入的验证后生命体征值，与床旁自动采集值存在系统性差异
实验室检查（lab 表）：158 种检验类型，以人工可读名称存储（labname），非 LOINC 编码
APACHE IV 评分（apachePatientResult + apacheApsVar + apachePredVar）：急性生理学评分、预测死亡率、预测 LOS
药物与输液（medication + infusionDrug + intakeOutput）：药物管理记录、持续输液参数、出入量
诊断（diagnosis 表）：3,933 种活动问题，按层级路径组织
微生物学（microLab 表）：培养与药敏结果，跨医院覆盖率高度不均
护理与呼吸（nurseAssessment + nurseCare + respiratoryCare + respiratoryCharting 等）：护理评估、呼吸机设置、呼吸治疗

§3.2 按表拆分样本规模

表名	记录行数（约）	核心内容	跨医院覆盖率
patient	200,859	ICU 住院主记录	100%
vitalPeriodic	~146,000,000	5 分钟间隔生命体征	99.04%
vitalAperioric	—	非周期性生命体征	99.04%
nurseCharting	—	护士验证体征	99.52%
lab	—	158 种检验类型	99.52%
medication	—	药物管理	83.65%
diagnosis	~200,859+	3,933 活动问题	99.52%
apachePatientResult	~136,236	APACHE IV 评分	~60%
microLab	—	微生物培养	10.58%
customLab	—	非标准检验	7.21%

§3.3 数据格式详情

形式	格式	说明
分发格式	CSV（31 个文件）	每表一个 .csv 文件，gzip 压缩
推荐数据库	PostgreSQL	官方提供 load scripts，MIT-LCP 维护的 schema 文档以 PostgreSQL 为准
备选数据库	MySQL / BigQuery / SQLite	社区适配方案
时间编码	整数（分钟偏移）	所有时间列以 `Offset` 结尾，代表距 ICU 入院时刻的分钟数
字段命名	CamelCase	如 `patientUnitStayID`, `hospitalDischargeStatus`（与 MIMIC 的 snake_case 不同）

§3.4 存储大小

版本	压缩后	解压后
v2.0 (CSV)	~3.6 GB	~35 GB（PostgreSQL）
BigQuery	云端	按查询量计费

§3.5 标注方式

eICU-CRD 的数据非人工标注——所有数据来自临床常规工作流的电子健康记录。数据分为三个可信度级别：

自动采集级（vitalPeriodic, vitalAperioric）——床旁监护仪每 5 分钟自动计算中位数，未经过临床验证，可能包含运动伪影、断连零值、传感器脱落导致的异常
护士验证级（nurseCharting）——护士查看监护数据后人工录入 EHR，经过临床判断过滤，但存在录入延迟和选择性记录偏倚
临床诊断级（diagnosis, apachePatientResult）——医生/临床系统生成，具有最高临床权威性，但诊断编码为 eICU 专有体系而非 ICD-10

APACHE IV 评分由 eCareManager 系统根据入院首 24 小时的最差值自动计算，被视为疾病严重程度评估的金标准参考。

§3.6 数据采集者信息

数据采集者为各参与医院的临床工作人员，在正常 ICU 工作流程中生成数据。eICU 远程监护团队（Philips eICU Program 运营）提供额外的远程监控和数据聚合。数据经过 Philips eRI（eICU Research Institute）转换为研究数据库格式，再由 MIT LCP 执行 HIPAA Safe Harbor 脱敏。

§3.7 采集时间范围

2014 年至 2015 年，共 2 年。当前 v2.0 仅覆盖此时间段。论文表明 Future updates 将添加当代数据，但截至 2026-07 尚未发布新版本。

§3.8 地理覆盖

208 家美国医院，分布于多个地理区域（东北部约 6.25% 被确认，其余区域通过 Philips eICU 客户网络覆盖）。医院涵盖学术医疗中心、社区医院和农村医院，但整体偏向采用 eICU 远程监护技术的机构群体——这并非美国医院体系的随机样本。

§3.9 采集设备

数据主要来源于 Philips 床旁监护仪和 eCareManager 信息管理系统。由于所有参与医院均使用 Philips eICU 基础设施，数据采集设备具有单一厂商偏倚——不同设备品牌的测量差异（如不同厂家的血压计系统误差）无法在此数据集内评估。实验室设备则因医院而异。

§3.10 深度溯源链

患者入院 → 医院 EHR 系统采集
    ↓
医院信息系统 → Philips eCareManager 数据传输（实时）
    ↓
eCareManager → Philips eICU 远程监护中心聚合
    ↓
Philips eRI → 数据归档 + 研究数据库格式转换
    ↓
MIT LCP → HIPAA Safe Harbor 脱敏（日期偏移、ID 替换、>89 年龄分箱、自由文本删除、医院标识去除）
    ↓
PhysioNet → 发布 CSV（v2.0, 2018-05-17）
    ↓
学术社区 → 下载 + PostgreSQL 导入 → 二次分析

§4 数据结构详解

§4.0 目录结构预览

eicu-crd-2.0/
├── admissionDx.csv
├── admissionDrug.csv
├── allergy.csv
├── apacheApsVar.csv
├── apachePatientResult.csv
├── apachePredVar.csv
├── carePlanCareProvider.csv
├── carePlanEOL.csv
├── carePlanGeneral.csv
├── carePlanGoal.csv
├── carePlanInfectiousDisease.csv
├── customLab.csv
├── diagnosis.csv
├── hospital.csv
├── infusionDrug.csv
├── intakeOutput.csv
├── lab.csv
├── medication.csv
├── microLab.csv
├── note.csv
├── nurseAssessment.csv
├── nurseCare.csv
├── nurseCharting.csv
├── pastHistory.csv
├── patient.csv              # 核心表——所有查询的入口
├── physicalExam.csv
├── respiratoryCare.csv
├── respiratoryCharting.csv
├── treatment.csv
├── vitalAperiodic.csv
├── vitalPeriodic.csv        # 最关键表——5 分钟间隔高粒度生命体征

§4.1 核心表字段描述（DAIMS 标准化）

patient 表（ICU 住院主记录）

字段名	数据类型	说明	示例值	AI 用途	观测误差	信息性缺失编码	取值范围
patientUnitStayID	int	ICU 住院唯一标识，全库主外键	141234	连接所有表的键	无	—	正整数
uniquepid	int	患者唯一标识（跨住院链接）	45891	患者级去重、再入院追踪	链接算法可能不完美	无	正整数
patientHealthSystemStayID	int	医院住院标识	8912	同次住院内多次 ICU 转移	无	—	正整数
gender	varchar(25)	性别	Female	公平性分析	录入偏倚（Unknown 占比）	NULL 表示未录入	Male, Female, Unknown, Other, NULL
age	varchar(10)	年龄	“68”, “> 89”	年龄调整风险建模	>89 分箱造成老年信息损失	—	整数或 “> 89”
ethnicity	varchar(50)	种族	Caucasian	公平性分组	非标准化录入，医院间不一致	NULL 表示未录入	Asian, Caucasian, African American, Native American, Hispanic, Other/Unknown, NULL
hospitalID	int	去标识医院代码	73	按医院划分训练/测试集	无	—	1-208
unitType	varchar(50)	ICU 类型	MICU	亚组分析	不同医院相同标签可能指不同配置	—	MICU, SICU, CCU, Neuro ICU 等 15+ 种
apacheAdmissionDx	varchar(1000)	APACHE IV 入院诊断路径	“Sepsis, pulmonary”	队列筛选	路径字符串格式不一致	NULL 表示未录入	自由文本
hospitalDischargeStatus	varchar(10)	出院状态	Alive, Expired	死亡预测标签	出院后死亡不记录	NULL 表示未录入	Alive, Expired, NULL
unitDischargeOffset	int	ICU 出院时间偏移（分钟）	4320	LOS 标签计算	含转科等待时间	—	正整数
admissionHeight	decimal(10,2)	入院身高 (cm)	170.2	BMI 计算	部分患者无测量	NULL 表示未录入	>0
admissionWeight	decimal(10,2)	入院体重 (kg)	75.3	药物剂量归一化	体液复苏后称重偏倚	NULL 表示未录入	>0

vitalPeriodic 表（5 分钟间隔生命体征）

字段名	数据类型	说明	示例值	AI 用途	观测误差	信息性缺失编码
patientUnitStayID	int	外键	141234	连接键	无	—
observationOffset	int	观测时间（分钟偏移）	120	时序建模	间隔固定为 5 分钟 ± 小抖动	—
heartrate	int	心率 (bpm)	78	循环状态特征	运动伪影、断连=0、传感器脱落	-1 = 无法获取
respRate	int	呼吸频率 (/min)	16	呼吸状态特征	自发性 vs 机械通气呼吸混淆	-1 = 无法获取
sao2	int	SpO₂ (%)	97	氧合状态特征	低灌注（指尖发冷）导致假性降低	-1 = 无法获取
systemicsystolic	int	无创收缩压 (mmHg)	125	循环状态特征	袖带尺寸不当导致偏倚	-1 = 无法获取
systemicdiastolic	int	无创舒张压 (mmHg)	72	循环状态特征	同上	-1 = 无法获取
temperature	decimal(4,1)	体温 (°C)	37.1	感染/炎症特征	口腔/腋下/直肠体温计不可比	-1 = 无法获取

关键差异：vitalPeriodic（自动 5 分钟中位数，-1 编码缺失）vs nurseCharting（护士人工验证，NULL 编码缺失）——同一生理参数的两种获取方式可能给出不同的值和时间。不能假设两者等价。 详见 §6.5 坑点 2。

lab 表（实验室检查）

字段名	数据类型	说明	示例值	AI 用途	观测误差	信息性缺失编码
patientUnitStayID	int	外键	141234	连接键	无	—
labResultOffset	int	检验时间偏移（分钟）	360	时序对齐	可能是采样时间而非报告时间	—
labname	varchar(255)	检验项目名	“creatinine”	特征映射（需文本匹配）	非标准化字符串，同一项目有多种写法	—
labresult	varchar(255)	检验结果	“1.2”, “NEGATIVE”	数值特征提取	文本与数值混合存储	空字符串表示未检出
labmeasurenamesystem	varchar(50)	单位	“mg/dL”	单位归一化	单位字符串不统一	—

diagnosis 表（诊断）

字段名	数据类型	说明	示例值	AI 用途
patientUnitStayID	int	外键	141234	连接键
diagnosisString	varchar(255)	具体诊断文本	“Sepsis, pulmonary”	诊断分类、表型定义
diagnosisPath	varchar(1000)	诊断层级路径	"Infectious Diseases	Sepsis
activeUponDischarge	varchar(3)	出院时是否仍为活动诊断	“Yes”	出院诊断筛选

§4.2 数据层级关系

uniquepid (患者) 1:N patientHealthSystemStayID (医院住院)
                                   1:N patientUnitStayID (ICU 住院) ← 全库核心
                                                       1:N 各临床表记录

关键约束：

患者可在不同医院住院——uniquepid 跨 hospitalID 有效
同一医院住院内可有多个 ICU 住院——patientHealthSystemStayID 可关联多个 patientUnitStayID
ICU 住院偏移量互不重叠——每个 patientUnitStayID 的时间偏移从 0 独立开始
患者跨医院追踪不可靠——uniquepid 的去重算法基于概率匹配，可能产生假阳性或假阴性

§4.3 缺失值分析

缺失模式	原因	影响	建议
vitalPeriodic = -1	床旁监护断连、传感器脱落	见 §6.5 坑点 1	必要时用 nurseCharting 补全或前向填充
APACHE IV 不可用	排除标准（住院<4h、烧伤、再入院等）	无法对约 40% 患者使用 APACHE 基准	仅在有 APACHE 的子集中报告 APACHE 对照结果
microLab 全医院缺失	医院未接入微生物学电子上报	社区医院更常见	在按医院划分时标记医院的数据完备性
carePlan 系列表现稀疏	护理计划录入取决于医院政策，非患者临床需求	部分医院无任何护理计划数据	不要假设缺失意味着不需要护理计划

§4.4 信息性缺失编码

表中的编码	含义	不等于
-1	无法获取（监护设备未连接/信号中断）	不等于"正常值"
NULL	未录入/未记录	不等于"不存在"
“> 89”	年龄超过 89 岁（HIPAA Safe Harbor）	不等于"恰好 90 岁"
“” (空字符串)	未检出/未测试	不等于"阴性"
“” in carePlan 列	护理计划未在此机构实施	不等于"患者不需要此护理"

§5 数据划分与使用建议

§5.1 官方划分

eICU-CRD 不提供官方 train/val/test 划分。这正是其设计哲学的一部分：研究人员通过 hospitalID 自行定义划分策略，模拟真实部署场景。

§5.2 推荐划分策略

eICU-CRD 的建模实验有三层递进：

Level 1：随机划分（不推荐） ——按 patientUnitStayID 随机 7:1:2 切分。可读性最高，但存在来自同一医院的患者同时出现在训练和测试集中的问题，可能严重高估泛化性能。

Level 2：按医院划分（推荐） ——将全部 208 家医院分为 train (150)、val (28)、test (30)。确保训练集医院与测试集医院完全不重叠。这是 eICU-CRD 的标准使用方式，也是审稿人期望看到的实验设计。

Level 3：留一医院逐次验证（Gold Standard） ——对每一家测试医院，用其余 207 家训练模型。可产出"在任一新医院上的平均性能"，但计算成本高（需训练 30+ 次）。

§5.3 与 MIMIC 联合使用的划分策略

策略	训练集	验证集	测试集	解决的问题
跨数据集验证	eICU 150 家	eICU 28 家	MIMIC-IV 全集	跨数据集泛化
反向验证	MIMIC-IV 全集	—	eICU 30 家	从深度→广度的泛化
双数据集训练	eICU 150家 + MIMIC-IV	各自验证集	eICU 30家 + MIMIC holdout	数据量优势能否克服分布差异？

§5.4 数据获取流程

完成 CITI 培训：在 citiprogram.org 注册，选择 “Massachusetts Institute of Technology Affiliates”，完成 “Data or Specimens Only Research” 课程（免费），保存 PDF 完成报告
注册 PhysioNet 账户：在 physionet.org 创建账号
提交凭证申请：访问 physionet.org/content/eicu-crd/，点击 “credentialed user” 链接，上传 CITI 完成报告，填写申请表单（学生/博后需提供导师信息）
签署 DUA：审批通过后（通常 1-3 个工作日），在线签署 Data Use Agreement（含不得再分发、不得尝试重识别、公开发表代码等条款）
下载数据：通过 PhysioNet 提供的 wget 命令下载 ~3.6 GB 压缩包

§5.5 许可证约束

仅限研究用途
不得商业使用
不得再分发数据（团队成员需各自独立申请）
不得尝试重识别患者或医院
发表论文时须公开代码（GitHub/Zenodo）
须引用 Pollard et al. (2018) 论文
LLM 使用限制：API 服务需零数据保留政策，本地模型无限制（详见 physionet.org/news/post/llm-responsible-use）

§6 AI 就绪指南

§6.1 快速上手

# ========================================
# eICU-CRD 快速上手 — PyTorch/Pandas 版
# 环境要求: pandas, numpy, torch>=2.0
#
# ⚠️ 目录结构预期：
#   将 CSV 文件解压至 ./data/eicu/ 目录，确保以下结构：
#   ./data/eicu/
#   ├── patient.csv
#   ├── vitalPeriodic.csv
#   ├── lab.csv
#   └── ...
#
#   本示例加载 patient 表 + 关键 vitalPeriodic 变量，
#   按 hospitalID 划分为 train/val/test（非随机），
#   训练一个简单的 MLP 进行 24h 死亡预测。
# ========================================

import pandas as pd
import numpy as np
import torch
import torch.nn as nn
from sklearn.preprocessing import StandardScaler
from sklearn.metrics import roc_auc_score

# 1. 加载主表
patient = pd.read_csv(''''''''./data/eicu/patient.csv'''''''')

# 2. 定义标签：住院死亡
patient[''''''''label''''''''] = (patient[''''''''hospitalDischargeStatus''''''''] == ''''''''Expired'''''''').astype(int)

# 3. 筛选条件（最小 ICU 停留时间 >24h，成人）
patient = patient[patient[''''''''unitDischargeOffset''''''''] > 1440]  # >24h in minutes
patient = patient[patient[''''''''age''''''''] != '''''''''''''''']  # remove missing age

# 4. 按 hospitalID 划分（非随机！）
hospital_ids = patient[''''''''hospitalID''''''''].unique()
np.random.seed(42)
np.random.shuffle(hospital_ids)
n_train = int(len(hospital_ids) * 0.7)
n_val = int(len(hospital_ids) * 0.15)

train_hospitals = hospital_ids[:n_train]
val_hospitals = hospital_ids[n_train:n_train+n_val]
test_hospitals = hospital_ids[n_train+n_val:]

train_patients = patient[patient[''''''''hospitalID''''''''].isin(train_hospitals)]
val_patients = patient[patient[''''''''hospitalID''''''''].isin(val_hospitals)]
test_patients = patient[patient[''''''''hospitalID''''''''].isin(test_hospitals)]

print(f"Train: {len(train_patients)} stays from {n_train} hospitals")
print(f"Val: {len(val_patients)} stays from {n_val} hospitals")
print(f"Test: {len(test_patients)} stays from {len(test_hospitals)} hospitals")

# 5. 提取 vitalPeriodic 的前 24h 聚合特征
def extract_vital_features(patient_df):
    vital = pd.read_csv(''''''''./data/eicu/vitalPeriodic.csv'''''''')
    vital = vital[vital[''''''''observationOffset''''''''] <= 1440]  # first 24h
    vital = vital[vital[''''''''patientUnitStayID''''''''].isin(patient_df[''''''''patientUnitStayID''''''''])]

    # 处理 -1 为 NaN
    for col in [''''''''heartrate'''''''', ''''''''respRate'''''''', ''''''''sao2'''''''', ''''''''systemicsystolic'''''''', ''''''''systemicdiastolic'''''''']:
        vital[col] = vital[col].replace(-1, np.nan)

    # 聚合：均值 + 标准差 + 最小值 + 最大值
    agg = vital.groupby(''''''''patientUnitStayID'''''''').agg(
        hr_mean=(''''''''heartrate'''''''', ''''''''mean''''''''),
        hr_std=(''''''''heartrate'''''''', ''''''''std''''''''),
        rr_mean=(''''''''respRate'''''''', ''''''''mean''''''''),
        spo2_mean=(''''''''sao2'''''''', ''''''''mean''''''''),
        sbp_mean=(''''''''systemicsystolic'''''''', ''''''''mean''''''''),
        sbp_min=(''''''''systemicsystolic'''''''', ''''''''min''''''''),
    ).reset_index()

    return patient_df.merge(agg, on=''''''''patientUnitStayID'''''''', how=''''''''inner'''''''')

train_data = extract_vital_features(train_patients)
val_data = extract_vital_features(val_patients)
test_data = extract_vital_features(test_patients)

# 6. 训练简单 MLP
feature_cols = [''''''''hr_mean'''''''', ''''''''hr_std'''''''', ''''''''rr_mean'''''''', ''''''''spo2_mean'''''''', ''''''''sbp_mean'''''''', ''''''''sbp_min'''''''']
X_train = train_data[feature_cols].fillna(0).values
y_train = train_data[''''''''label''''''''].values

scaler = StandardScaler()
X_train = scaler.fit_transform(X_train)

model = nn.Sequential(
    nn.Linear(len(feature_cols), 32),
    nn.ReLU(),
    nn.Dropout(0.3),
    nn.Linear(32, 16),
    nn.ReLU(),
    nn.Linear(16, 1),
    nn.Sigmoid()
)

optimizer = torch.optim.Adam(model.parameters(), lr=0.001)
criterion = nn.BCELoss()

X_t = torch.FloatTensor(X_train)
y_t = torch.FloatTensor(y_train)

for epoch in range(50):
    optimizer.zero_grad()
    loss = criterion(model(X_t).squeeze(), y_t)
    loss.backward()
    optimizer.step()
    if epoch % 10 == 0:
        print(f"Epoch {epoch}, Loss: {loss.item():.4f}")

# 7. 评估
X_test = scaler.transform(test_data[feature_cols].fillna(0).values)
y_test = test_data[''''''''label''''''''].values
with torch.no_grad():
    y_pred = model(torch.FloatTensor(X_test)).squeeze().numpy()
auroc = roc_auc_score(y_test, y_pred)
print(f"Test AUROC (leave-hospitals-out): {auroc:.4f}")

§6.2 数据获取

步骤	详情	预计耗时
CITI 培训	在线课程，约 2-3 小时	1 天
PhysioNet 凭证	提交 CITI 报告 + 表单	1-3 个工作日
签署 DUA	在线签署	即时
下载数据	wget 下载 ~3.6 GB	~30 分钟-数小时
导入 PostgreSQL	使用官方 load scripts	~1-2 小时

§6.3 预处理 Pipeline

原始 CSV (31 files)
    ↓ load 到 pandas 或 PostgreSQL
    ↓ 选择患者群体（§5.2 筛选条件）
    ↓ 时间窗口裁剪（如前 24 小时：observationOffset <= 1440）
    ↓ 处理特殊缺失编码（-1 → NaN、""> 89" → 定值处理）
    ↓ 聚合时序特征（均值/标准差/最小值/最大值/趋势斜率）
    ↓ 合并 lab + medication 等表（通过 patientUnitStayID JOIN）
    ↓ 按 hospitalID 划分 train/val/test
    ↓ 标准化（StandardScaler 或按训练集统计）
    ↓ 模型输入

§6.4 框架加载

PyTorch 自定义 Dataset（时间序列版）：

class eICUDataset(torch.utils.data.Dataset):
    def __init__(self, patient_ids, data_dir, window_hours=24):
        self.patient_ids = patient_ids
        vital = pd.read_csv(f''''''''{data_dir}/vitalPeriodic.csv'''''''')
        self.vital = vital[vital[''''''''patientUnitStayID''''''''].isin(patient_ids)]
        self.vital = self.vital[self.vital[''''''''observationOffset''''''''] <= window_hours * 60]
        self.patient = pd.read_csv(f''''''''{data_dir}/patient.csv'''''''')
        self.patient = self.patient[self.patient[''''''''patientUnitStayID''''''''].isin(patient_ids)]

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

    def __getitem__(self, idx):
        pid = self.patient_ids[idx]
        p_row = self.patient[self.patient[''''''''patientUnitStayID''''''''] == pid].iloc[0]
        label = 1.0 if p_row[''''''''hospitalDischargeStatus''''''''] == ''''''''Expired'''''''' else 0.0

        v_data = self.vital[self.vital[''''''''patientUnitStayID''''''''] == pid]
        features = v_data[[''''''''heartrate'''''''',''''''''respRate'''''''',''''''''sao2'''''''',
                           ''''''''systemicsystolic'''''''',''''''''systemicdiastolic'''''''']].values
        features[features == -1] = np.nan
        features = np.nan_to_num(features, nan=0.0)

        return torch.FloatTensor(features), torch.FloatTensor([label])

§6.5 常见坑点

⚠️ 坑点 1：vitalPeriodic 列中的 -1 ≠ 零 ≠ 正常值（分类：数据理解）

问题：eICU 的生命体征表（vitalPeriodic / vitalAperioric）使用 -1 编码"无法获取"，而非 NULL。如果直接将 -1 输入模型，模型会学到"心率 = -1 预测死亡"的伪关联——因为监护信号丢失本身就与临床恶化相关。

症状：模型特征重要性给"虚假缺失"特征极高权重；训练集 AUROC 异常高而验证集骤降。

解决：预处理时统一将 -1 替换为 NaN，然后选择插补策略（前向填充、均值填充或标记为缺失指示变量）。决不能保留 -1 作为有效数值。
vital[vital == -1] = np.nan
# 或创建单独的缺失指示器
vital[''''''''hr_missing''''''''] = (vital[''''''''heartrate''''''''] == -1).astype(int)
参考：eICU 官方文档 — eicu.mit.edu/eicutables/vitalperiodic/

⚠️ 坑点 2：nurseCharting ≠ vitalPeriodic — 同参数两来源不可互换（分类：数据理解）

问题：eICU 中同一生命体征（如心率）同时记录在 vitalPeriodic（5 分钟自动中位数）和 nurseCharting（护士验证后录入）中。两者的值和时序不同——vitalPeriodic 更密集但不验证，nurseCharting 经过人工但稀疏且有录入延迟。直接合并二者会产生时间错位和系统性偏差。

症状：同时使用两表后发现"护士验证心率"系统性低于"自动采集心率"——这不是生理变化，而是护士倾向于录入稳定状态的值。

解决：选择一种来源作为主特征，另一种作为辅助验证。推荐方案：vitalPeriodic 为主要时间序列输入（高密度），nurseCharting 用于质量控制校验。

参考：Johnson et al. (2018), “A Comparative Analysis of Sepsis Identification Methods”, Critical Care Medicine

⚠️ 坑点 3：patientUnitStayID 不是按时间顺序分配（分类：工程陷阱）

问题：与 MIMIC 的 stay_id 不同，eICU 的 patientUnitStayID 不代表时间顺序——ID=2 的住院可能发生在 ID=10 之后。按 ID 排序并不能还原患者的时间轨迹。医院住院的正确时间顺序必须通过 hospitalAdmitOffset + unitDischargeOffset 推导。

症状：按 patientUnitStayID 升序分析时间趋势会得到完全错误的结论。

解决：使用 hospitalAdmitOffset（越接近 0 表示越接近入院时间）推断同一患者多次 ICU 住院的时序。
SELECT * FROM patient
WHERE uniquepid = 45891
ORDER BY hospitalAdmitOffset DESC;   第一次住院 hospitalAdmitOffset 最大

⚠️ 坑点 4：医院级数据覆盖率差异巨大 — 不是所有表在所有医院都可用（分类：数据理解）

问题：microLab 表仅 10.58% 的医院有数据、customLab 仅 7.21%。如果在按医院划分的策略中不检查每张表的覆盖率，某些医院的模型输入特征会系统性缺失。

症状：测试集中某医院的所有患者均缺失微生学数据 → 模型逻辑分支退化 → 性能异常波动。

解决：

训练前检查每张表在各医院的覆盖情况

剔除非核心表完全缺失的医院，或使用缺失指示变量显式编码

在论文中报告 train/val/test 各医院的数据完备性

参考：eICU 论文 Table 1 中的 “Hospital-level coverage matrix”

⚠️ 坑点 5：labname 非标准化 — 同一检验项目有多个名称（分类：预处理陷阱）

问题：lab 表中的 labname 是自由文本字符串，同一检验（如肌酐）可能以 “creatinine”、“Creatinine”、“CREAT”、“creatinine, serum” 等形式出现。直接按名称过滤会遗漏大量数据。

症状：提取 “creatinine” 后发现仅有 60% 的预期记录数。

解决：使用大小写不敏感的模糊匹配 + 社区维护的 labname 映射表。
lab_names = lab[''''''''labname''''''''].str.lower().str.strip().unique()
creatinine_names = [n for n in lab_names if ''''''''creatinine'''''''' in n or ''''''''creat'''''''' in n]

⚠️ 坑点 6：时间偏移量不可用于日历日期分析（分类：数据理解）

问题：eICU-CRD 的最小时间单位是"距 ICU 入院时刻的分钟偏移量"。季节效应、节假日效应（如 7 月新住院医师交接）、流行病暴发时间点等日历相关分析无法进行——因为绝对日期已被脱敏。

症状：无法判断 2014 vs 2015 数据差异是真实趋势还是不同日历年的差异——两年的数据混在一起，没有年标识符。

解决：接受这一限制。eICU-CRD 不适合时间序列的季节性或趋势分析。如需此类分析，使用 MIMIC-IV（时间跨度 2008-2022，含年份信息）。

⚠️ 坑点 7：APACHE IV 患者选择偏倚 — 不要假设缺失是随机的（分类：偏倚陷阱）

问题：仅约 60% 的患者具有 APACHE IV 评分——其余 40% 因排除标准（住院<4h、烧伤、再入院等）被系统性地排除。如果仅在有 APACHE 的患者上训练和评估，结果不能泛化到短住院和高周转 ICU 场景。

症状：APACHE 子集上的 AUROC 显著高于全量数据——因为排除了最短暂、最轻和最复杂的病例。

解决：分别报告"全量患者"和"有 APACHE 患者"两套性能。如果使用 APACHE 变量作为特征，务必标记这一选择偏差。

⚠️ 坑点 8：eICU 是 TeleICU 数据 — 不等于标准 ICU 数据（分类：数据理解）

问题：eICU-CRD 的数据来自远程监护（TeleICU）工作流而非传统床旁 ICU。远程监护团队在筛选和记录数据时有不同于本地护士的优先级——例如，远程团队可能更关注早期恶化信号，而对日常护理记录较少。这意味着 eICU 的数据密度模式不代表普通 ICU 的数据密度。

症状：基于 eICU 训练的模型在普通 ICU 场景下可能性能下降，因为训练数据的采集上下文不同。

解决：在论文中明确讨论 TeleICU vs 床旁 ICU 的数据差异。使用 MIMIC-IV（床旁 ICU）进行外部验证，比较两种数据采集模式下的模型泛化性。

§6.6 推荐数据增强策略

对于时序数据，传统的图像增强不适用。以下是 ICU 时序特定的增强方法：

✅ 时间窗口滑动：截取住院期间不同时间段的前 24 小时作为多个样本，增加有效样本量
✅ 随机缺失注入：按真实缺失率随机移除部分观测值，训练模型对缺失鲁棒
✅ 按医院重采样：对样本不均衡的医院进行过采样
❌ SMOTE 类合成插值：对高维时序几乎无效，可能产生不生理的合成生命体征组合
❌ 随机翻转/镜像：生理信号不对称，翻转后失去意义

§6.7 模型推荐

任务	推荐模型	原因	预期 AUC
静态死亡预测（24h 聚合特征）	XGBoost / CatBoost	解释性强、训练快、社区广泛验证	0.85-0.90
时序死亡预测（原始体征波形）	LSTM / GRU	适合不规则采样时序	0.88-0.93
跨医院泛化评估	LSTM + Domain Adversarial Training	可对抗医院特异性偏倚	跨医院 AUC 提升 0.02-0.04
多任务预测（死亡+LOS）	Transformer	共享表示学习	与单任务 LSTM 持平

§6.8 计算需求

配置	最低要求	推荐配置
磁盘	50 GB（解压后 + 中间数据）	100 GB SSD
内存	16 GB	32-64 GB
GPU	不需要（树模型足够）	1× NVIDIA T4/L4（如需训练 LSTM）
训练时间	1-2 小时（XGBoost 全量）	6-12 小时（LSTM，留一医院验证 30 轮）

§6.9 评估指标

from sklearn.metrics import (
    roc_auc_score, average_precision_score,
    brier_score_loss, balanced_accuracy_score
)

def evaluate_classification(y_true, y_pred, y_prob):
    metrics = {
        ''''''''AUROC'''''''': roc_auc_score(y_true, y_prob),
        ''''''''AUPRC'''''''': average_precision_score(y_true, y_prob),
        ''''''''Balanced Accuracy'''''''': balanced_accuracy_score(y_true, y_pred),
        ''''''''Brier Score'''''''': brier_score_loss(y_true, y_prob),
    }
    return metrics

# ⚠️ eICU 死亡率为 ~6.5%，对不平衡分类敏感。
# AUPRC 在低发病率场景下比 AUROC 更有区分力。

§7 质量评估与局限性

§7.1 已知偏倚

偏倚类型	描述	严重程度	缓解措施
选择偏倚	参与 eICU 项目的医院非随机——偏向有财力投资远程监护设施的中大型医院	高	外部验证时使用不同类型医院的独立数据
厂商偏倚	所有数据通过 Philips 设备和软件采集，不同厂商设备的测量差异不可评估	中	在论文中声明设备厂商一致性可能是过拟合源
时间偏倚	仅 2 年（2014-2015），可能不反映当代 ICU 实践	中	用 MIMIC-IV 的后期数据（2018+）做时间泛化测试
文档偏倚	护士验证生命体征存在选择性记录——病情越重记录越密集	中	nurseCharting 密度本身可作为严重程度的代理特征
种族偏倚	约 77% 高加索人，非白人群体欠代表	中	对少数群体单独报告性能，如差异显著则需讨论
年龄信息损失	>89 岁分箱使得老年医学研究无法利用精确年龄	低-中	将 “> 89” 作为分类变量处理

§7.2 标注质量评估

数据来源	标注类型	质量	局限性
vitalPeriodic	自动采集	高密度，低验证	含运动伪影、断连零值、传感器故障——未经临床核验
nurseCharting	人工验证	高可信度	选择性记录、录入延迟、不同护士有不同记录标准
APACHE IV 预测死亡率	系统计算	金标准	仅 60% 患者可用，排除标准引入系统性选择偏倚
diagnosis (出院诊断)	医生录入	高权威性	eICU 专有编码非 ICD，跨研究标准化困难
lab (实验室)	仪器自动	高精度	158 种检验以非标准文本名存储，跨项目映射费时

§7.3 泛化性讨论

场景	失效风险	证据
eICU 训练 → 非 eICU 医院	高	TeleICU 数据采集模式与床旁 ICU 有系统性差异
eICU 训练 → 小型社区医院	中-高	eICU 医院偏向中大型机构，社区医院实践差异大
美国 → 非美国	极高	美国 ICU 实践、人群特征、保险制度均有特殊性
2014-2015 → 2020+	中	脓毒症定义（Sepsis-3）和临床实践在 2016 年后更新
大医院训练 → 同网络小医院测试	低	同网络内医院有相似的流程和文档标准

§7.4 伦理考量

数据为回顾性、去标识数据，MIT IRB 和 Philips IRB 已豁免审查
独立隐私专家（Privacert, Cambridge, MA）认证符合 HIPAA Safe Harbor 标准（认证号 1031219-2）
医院标识符已去标识——无法从数据中推断具体医院名称或位置
数据集使用协议要求签署 DUA，承诺不尝试重识别
自由文本临床笔记被完全删除以消除 PHI 风险——代价是 NLP 研究不可用

§7.5 公平性评估

eICU-CRD 已在多项研究中展示出跨种族和性别的性能差异：

种族：非洲裔患者的死亡预测模型 AUROC 可能低于高加索人（差异 0.02-0.05），部分归因于疾病表现差异和系统性文档偏倚
性别：男女间模型性能差异较小，在大部分研究中 95% CI 重叠
年龄：>89 岁分箱组的模型校准较差，因为无法使用精确年龄

建议：始终按性别、种族和年龄段分层报告模型性能。使用 Equalized Odds 或 Demographic Parity 等公平性指标评估模型。

§7.6 数据漂移提示

由于数据仅覆盖 2014-2015 年，无法评估同一医院内的时序漂移。但如果将 eICU 模型应用于 2020 年以后的数据，以下方面的漂移应特别关注：

脓毒症定义变更：2016 年 Sepsis-3 定义（SOFA≥2）取代了 SIRS 标准
COVID-19 影响：2020 年后 ICU 病例构成发生了根本性变化
远程监护普及：COVID 期间 TeleICU 采用率大幅增加，使 eICU 数据采集模式更普遍

§7.7 DAIMS 24 项数据就绪度评估

#	DAIMS 检查项	评分	说明
1	数据集名称与版本	✅ 1	eICU-CRD v2.0，明确版本号
2	数据采集目的	✅ 1	临床远程监护运营 → 研究二次利用
3	数据来源与机构	✅ 1	208 家医院，MIT LCP + Philips eRI
4	患者人群描述	✅ 1	详细的 demographics、入排标准
5	数据采集时间范围	✅ 1	2014-2015（明确但有限）
6	数据模态说明	✅ 1	31 表结构化 EHR
7	样本量统计	✅ 1	全部 + 按表分别统计
8	字段级数据字典	✅ 1	官方文档 + SchemaSpy 交互字典
9	缺失值文档化	✅ 1	-1/Null 编码有文档，覆盖率矩阵
10	标注方法描述	✅ 1	自动 vs 人工验证明确区分
11	数据划分建议	✅ 1	按 hospitalID 划分（强烈推荐）
12	已知偏倚	✅ 1	厂商/选择/文档偏倚在论文中充分讨论
13	伦理审批	✅ 1	HIPAA 认证 + IRB 豁免
14	许可证与访问	✅ 1	PhysioNet Credentialed + DUA
15	数据格式标准化	⚠️ 0.5	labname 非标准文本，诊断编码为专有体系
16	数据预处理建议	✅ 1	Jupyter Notebooks 提供示范
17	版本控制	✅ 1	v1.0→v2.0，GitHub 管理
18	跨数据集兼容性	⚠️ 0.5	ricu 支持，但 camelCase 和 offset 时间与 MIMIC 不直接兼容
19	公平性评估资源	⚠️ 0.5	有性别/种族/年龄字段但无内置公平性基准
20	外部验证资源	✅ 1	MIMIC-IV 是天然外部验证集
21	代码与工具链	✅ 1	eicu-code GitHub + Jupyter Notebooks + ricu
22	社区活跃度	✅ 1	~2,000 引用，活跃 GitHub issues
23	更新与维护计划	⚠️ 0.5	论文承诺更新但截至 2026-07 未实现
24	基准性能参考	✅ 1	E-CatBoost / RealMIP / HCNet 等提供权威基准

DAIMS 评分：21.0 / 24

评分解读：优秀 — 在结构化 ICU 数据集中处于最高水平。

对你意味着什么：eICU-CRD 在文档化、可访问性和社区生态方面非常成熟。主要扣分项集中在：lab 和 diagnosis 的文本名称未映射到标准术语体系（LOINC/SNOMED CT）、字段命名惯例与 MIMIC 不兼容增加跨数据集开发成本、数据 2014-2015 的时间范围略显陈旧且更新未兑现。建议在训练前：(1) 使用 ricu R 包统一 eICU 和 MIMIC 的变量提取逻辑；(2) 对 labname 做社区映射表标准化；(3) 始终使用 hospitalID 划分而非随机划分。

§7.8 外部验证矩阵

外部数据集/场景	来源机构	样本量	评估任务	性能指标	关键发现
MIMIC-IV	BIDMC（单中心）	69,111 住院	死亡率预测	AUROC 0.968 (RealMIP)	eICU 模型在 MIMIC 上表现稳健，两者互补
SICdb	萨尔茨堡（多中心）	27,137 住院	死亡率预测	AUROC 0.932 (RealMIP)	欧洲验证显示性能轻度下降
NWICU	西北大学（单中心）	—	脓毒症 ARDS 死亡率	—	多数据库验证提高了模型可信度
MIMIC-III	BIDMC（单中心）	60,000+ 住院	死亡预测迁移	ΔAUROC -0.05~-0.10	MIMIC→eICU 跨中心性能系统性下降

§8 基准性能与生态

§8.1 排行榜

死亡预测（24h 静态特征，按医院划分验证）

排名	模型	AUROC	年份	关键技术	完整引用	代码
1	RealMIP	0.957	2025	生成式缺失值动态插补 + 持续风险预测	Ren et al. (2025), npj Digital Medicine. DOI: 10.1038/s41746-025-02114-y	—
2	HCNet	0.941	2026	时序深度学习 + 静态特征融合	Tao et al. (2026), World J Emerg Med. DOI: 10.5847/wjem.j.1920-8642.2026.065	—
3	LSTM	0.911	2026	标准 LSTM 基准（HCNet 论文对照）	同上	—
4	CatBoost	0.916	2022	12 疾病分组优化 XGBoost 变体	Safaei et al. (2022), PLOS ONE. DOI: 10.1371/journal.pone.0262895	—
5	E-CatBoost	0.86-0.92	2022	仅 10 特征的高效 CatBoost	同上	GitHub

注意：以上 AUROC 值来自不同论文的不同队列定义和划分策略，不可直接作为绝对数值比较。RealMIP 使用 generative imputation，HCNet 专注高血糖危象亚组，E-CatBoost 按 12 个疾病组分别评估。选择模型时请参考具体适用场景而非仅看 AUROC 排名。

§8.2 SOTA 总结

场景	推荐方案	理由
最快原型	E-CatBoost (10 特征)	仅需 10 个聚合特征，训练 5 分钟，AUROC 0.86-0.92
最高准确率	RealMIP（生成式插补）	动态缺失值恢复 + 持续预测，跨数据集验证优异
多任务学习	LSTM + 多输出头	同时预测死亡率 + LOS + 再入院
可解释性优先	XGBoost + SHAP	树模型天然可解释，ICU 临床团队易于接受
跨医院泛化	Domain Adversarial LSTM	显式对抗医院特异性偏倚

§8.3 评估协议

社区共识评估协议：

筛选：成人（≥18 岁）、ICU 住院 >24 小时、首次 ICU 入院
预测窗口：基于入院首 24 小时数据预测住院死亡率
划分：按 hospitalID 而非随机划分（硬性要求）
缺失值处理：vitalPeriodic 中 -1 替换为 NaN，使用前向填充+均值插补
评估指标：AUROC + AUPRC（死亡率 ~6.5%，不均衡分类）+ Brier Score（校准度）
公平性分析：按性别/种族/年龄分层的 AUROC

§8.4 相关数据集

数据集	关系	用途
MIMIC-IV	互补 — 单中心深度数据	标准外部验证集，MIMIC↔eICU 交叉验证
MIMIC-III	前代单中心	历史对照，eICU 发布前的主要 ICU ML 数据源
AmsterdamUMCdb	互补 — 欧洲 GDPR 合规	跨大洲外部验证
HiRID	互补 — 高分辨率	时序分辨率 + 多中心广度对比
SICdb（萨尔茨堡）	互补 — 中欧多中心	欧洲多中心验证

§8.5 关键论文 Top 8

Pollard TJ et al. (2018) — 数据描述论文。Scientific Data, 5:180178. “The eICU Collaborative Research Database, a freely available multi-center database for critical care research.” 贡献：发布数据集，定义 schema 和访问流程。
Johnson AEW et al. (2018) — “A Comparative Analysis of Sepsis Identification Methods in an Electronic Database.” Critical Care Medicine, 46(4):494-499. 贡献：首次系统比较 eICU 中不同脓毒症定义的效果差异。
Safaei N et al. (2022) — “E-CatBoost: An efficient machine learning framework for predicting ICU mortality.” PLOS ONE, 17(5):e0262895. 贡献：仅用 10 个特征达到 SOTA 性能的轻量级方法。
Sheikhalishahi S et al. (2019) — “Benchmarking machine learning models on multi-centre eICU critical care dataset.” arXiv, 1910.00964. 贡献：首个 eICU 公开基准，12 个 ML 模型在多��任务上的系统评测。
Bennett N et al. (2021) — “ricu: R Interface to Intensive Care Unit Data.” GitHub. 贡献：R 包 ricu，提供了 MIMIC-III/IV 和 eICU 的统一 API。
Raffa JD et al. (2022) — 继续研究 eICU 中 APACHE IV 评分的衍生与应用。
Johnson AEW et al. (2018) — “Mortality prediction and transportability across ICUs.” Annals ATS. 贡献：系统量化 MIMIC→eICU 跨数据集性能迁移的下降幅度。
Ren et al. (2025) — “RealMIP: Real-time ICU mortality prediction with dynamic imputation.” npj Digital Medicine. 贡献：当前 eICU 上最高性能的死亡预测模型。

§8.6 社区活跃度

指标	数据（截至 2026-07）
论文引用	1,900+（OpenAlex）
GitHub Stars (eicu-code)	活跃社区维护
PhysioNet 下载	持续增长
相关 GitHub 仓库	ricu ®, mimic-code (Python), eicu-code (官方)
Google BigQuery 公开数据集	可用
已发表研究	250+（Google Scholar 搜索 “eICU-CRD”）

§8.7 生态快照

资源	类型	链接	为什么值得关注
eICU 官方文档	文档	eicu-crd.mit.edu	SchemaSpy 交互式数据字典 + 每表详细说明
eicu-code	工具库	github.com/MIT-LCP/eicu-code	官方代码库：load scripts、Jupyter notebooks、概念提取 SQL
ricu	工具库	github.com/eth-mds/ricu	统一 API 同时操作 eICU + MIMIC，消除字段不一致痛苦
eICU on BigQuery	云端数据	Google Cloud Public Datasets	无需下载即可 SQL 查询全量数据
PhysioNet eICU 论坛	社区	physionet.org	数据使用问题讨论 + issue tracking

§9 相关资源与引用

§9.1 官方资源

官方网站：https://eicu-crd.mit.edu/
PhysioNet 页面：https://physionet.org/content/eicu-crd/2.0/
官方代码仓库：https://github.com/MIT-LCP/eicu-code
交互式数据字典：https://eicu.mit.edu/eicutables/patient/
数据访问指南：https://eicu-crd.mit.edu/gettingstarted/access/

§9.2 必引论文

使用 eICU-CRD 发表论文时，必须引用以下文章：

主引用：Pollard TJ, Johnson AEW, Raffa JD, Celi LA, Mark RG, Badawi O. “The eICU Collaborative Research Database, a freely available multi-center database for critical care research.” Scientific Data 5, 180178 (2018). DOI: 10.1038/sdata.2018.178
PhysioNet 基础引用：Goldberger AL et al. “PhysioBank, PhysioToolkit, and PhysioNet: Components of a New Research Resource for Complex Physiologic Signals.” Circulation 101(23):e215-e220 (2000).

§9.3 伦理声明模板

论文中应包含以下声明：

The study is exempt from institutional review board approval due to the retrospective design, lack of direct patient intervention, and the security schema, for which the re-identification risk was certified as meeting safe harbor standards by an independent privacy expert (Privacert, Cambridge, MA) (Health Insurance Portability and Accountability Act Certification no. 1031219-2).

§9.4 推荐教程

Getting Started with eICU-CRD (Jupyter Notebook) — 官方提供，涵盖 patient 表遍历、vitalPeriodic 可视化、lab 提取
eICU Data Extraction Skill (clawhub.ai) — 社区维护的 SQL + Python 代码模板
ricu 教程 — 在 R 中用统一 API 分析 eICU 和 MIMIC 的入门指南

§9.5 类似数据集（替代方案）

MIMIC-IV：如果需要单中心深度数据 + 影像 + 自由文本
AmsterdamUMCdb：如果需要欧洲数据 GDPR 合规 + 更长时间跨度
HiRID：如果需要 2 分钟级高分辨率时序数据
SICdb：如果需要中欧多中心 ICU 数据

§10 AI 使用声明卡

§10.1 使用的 AI 模型

模型	版本	用途
大语言模型	2026	基于 v3.9 模板生成 Wikipedia 页面初稿

§10.2 AI 参与范围

AI 辅助撰写：基于公开文献（Pollard et al. 2018 Scientific Data 论文、eICU 官方文档、社区教程和基准论文）生成初稿，人工审核后修改。

§10.3 输入参考文献

Pollard TJ et al. (2018) — Scientific Data 5:180178
MIT-LCP eICU 官方文档 (eicu-crd.mit.edu)
PhysioNet eICU-CRD 页面 (physionet.org/content/eicu-crd/)
Safaei N et al. (2022) — PLOS ONE 17(5):e0262895
Ren et al. (2025) — npj Digital Medicine
Sheikhalishahi S et al. (2019) — arXiv 1910.00964
Bennett N et al. (2021) — ricu R 包文档
Johnson AEW et al. (2018) — Critical Care Medicine 46(4)
千方病案医数集 — AI Ready 数据集 Wikipedia Schema 模板 v3.9

§10.4 人工校验机制

内容模块	审核者	审核方式	审核状态
§2 医学背景	千方病案医学编辑部	交叉审核	✅ 已通过
§6 代码示例	千方病案医学编辑部	逻辑审查	✅ 已通过
§3 数据规格	千方病案医学编辑部	与官方文档交叉比对	✅ 已验证
§4 数据字典	千方病案医学编辑部	与 SchemaSpy 文档比对	✅ 已验证
§8 基准排行榜	千方病案医学编辑部	与原始论文核验	✅ 已验证
§7 偏倚与 DAIMS	千方病案医学编辑部	与 Scientific Data 论文核验	✅ 已验证

§10.5 AI 生成章节

§1.0 速览、§1.2 战略价值分析、§6.1 快速上手代码、§6.5 坑点、§7.7 DAIMS 评估（初稿）由 AI 生成——所有数值和事实已经人工交叉核验。

§10.6 最后人工审核日期

2026-07-28

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

返回 AI Ready 数据集