五库合并只留老年 — ELDER-ICU-DB

5 源库 4 张 CSV / 209 站点 93,654 住院 / 65 岁起 2001–2022

来源 https://physionet.org/content/elder-icu-db/1.0.0/发布时间: 2026-10-28最后更新: 2026-10-28 阅读 8
五库合并只留老年 — ELDER-ICU-DB

信息速览

数据集名称五库合并只留老年 — ELDER-ICU-DB
数据类型表格数据,结构化,派生变量,跨库协调,CSV
规模93,654次ICU住院/65岁及以上
接入方式https://physionet.org/content/elder-icu-db/1.0.0/
AI 就绪度

一次 ICU 住院能不能撑过去,很大程度上取决于躺在床上的这个人有多老。官方页面引用的文献给出的数字是:八十岁以上患者已占重症人群的 36%,其 ICU 死亡率在 15—25% 之间,住院死亡率 25—45%,一年死亡率可达 70%。但真正卡住老年重症研究的,从来不是缺模型,而是缺一份能同时覆盖多个国家、并且用同一套变量口径描述患者的数据。MIMIC 来自波士顿一家医院,SICdb 来自奥地利萨尔茨堡,浙江重症库来自中国一家三级医院,只有 eICU-CRD 是多中心的——可它的两百多个站点全在美国。想做一次真正的跨国外部验证,研究者得先学会四套表结构、写四套 SQL、再把口径手动对齐,绝大多数团队在这一步就放弃了。

ELDER-ICU-DB 的做法是把这四套结构压平。它从 MIMIC-III、MIMIC-IV、eICU-CRD、SICdb、浙江重症库五个源库里各抽一次,按同一套变量名重新组织,落成四个 CSV 文件:每个文件一张宽表,一行对应一次 ICU 住院。合计 93,654 次住院、209 个临床站点、美国奥地利中国三国、2001 到 2022 年,全部患者年龄在 65 岁及以上。它的取舍同样写在明面上:每人每次住院只保留首个 ICU 停留;生理变量只看入 ICU 后的头 24 小时;五个源库不合并成一张总表,而是各占一个文件,另附一份变量可用性矩阵说明哪些列在哪些源库里真的存在。它不是更大的库,是一把"把五个库摆到同一张桌面上"的尺子。一屏速览见下表。

维度 内容
全名 ELDER-ICU-DB: A Comprehensive Critical Care Data Resource for International Multicenter Study on Elderly ICU Patients
发布方 PhysioNet(MIT 计算生理学实验室维护)
作者与机构 Sicheng Hao(新加坡国立大学 / MIT LCP)、Niklas Rodemund(萨尔茨堡帕拉塞尔苏斯医科大学)、Xiaoli Liu(MIT LCP)
首次发布 2026 年 10 月 27 日,版本 1.0.0
最近改动 即为首版,官方未列出修订记录
住院记录数 93,654 次 ICU 住院
源库贡献 MIMIC 48,708 / eICU-CRD 37,166 / SICdb 6,371 / 浙江 1,409
患者年龄阈值 ≥ 65 岁(精确年龄以岁计)
地理覆盖 209 个临床站点,美国、奥地利、中国三国
时间跨度 2001—2022 年
文件构成 4 张 CSV 数据文件 + 1 张 Variable_Availability_Matrix.csv
字段规模 MIMIC 78 列 / eICU-CRD 81 列 / SICdb 77 列 / 浙江 78 列
观察窗口 实验室自入 ICU 前 6 小时至入 ICU 后 24 小时;生命体征取入 ICU 后 24 小时
变量主题 人口学、住院特征、8 项生命体征、27 项实验室、7 项血气、治疗、4 类血管活性药、衰弱与营养、4 项评分
许可与访问 PhysioNet Contributor Review Health Data License 1.5.0;须认证用户、签署 DUA、贡献者逐项目审批
典型用途 老年 ICU 预后与死亡风险预测、跨医疗系统的比较效果研究、OASIS/SAPS II/SOFA/CCI 在老年人群中的验证

§1 它要解决的具体麻烦

1.1 老年重症研究卡在"外部验证"这一步

重症医学的预测模型数量极多,能被第二家医院复现的极少。官方页面把原因概括为两条:多数现有模型存在单中心偏倚,且外部验证不充分,因而难以进入临床。对老年亚群来说这个问题更尖锐,因为年龄本身就是最强的混杂因素之一——一个在平均年龄 55 岁的人群上校准过的评分,放到平均年龄 78 岁的人群上,校准曲线会整体偏移,而这件事只有在第二个、第三个独立人群上才能看出来。

更麻烦的是地理维度。已有的多中心研究主要用 MIMIC、eICU-CRD 与 AmsterdamUMCdb 做美国与欧洲人群之间的验证,亚洲人群基本缺席。ELDER-ICU-DB 的立意正是补上这个缺口:它纳入了中国浙江的重症库,让三国对照在同一份协调过的表里完成。

1.2 挡在前面的其实是一道工程门槛

官方页面在背景部分列了四条使用公开重症库的现实障碍:存储需求大、数据格式异构、需要具备专门的查询技能(数据库管理软件与 SQL)、以及需要医学与工程交叉的背景。这四条里,前两条是资源问题,后两条是人力问题,且后两条更难解决。

具体到这五个源库,差异体现在三个层面。命名层面,同一个"ICU 住院"在 MIMIC 里叫 stay_id,在 eICU-CRD 里叫 patientunitstayid,在 SICdb 里叫 hadm_id,在浙江库里叫 hospital_id;时间层面,MIMIC 用真实日期做过年代平移,eICU-CRD 用相对分钟偏移,SICdb 与浙江库各有各的时间基准;内容层面,同一个临床概念在不同库里的落表位置不同,比如"是否记录过抢救意愿"在 MIMIC 与 eICU-CRD 里能从 chartevents 与 careplangeneral 找到,在 SICdb 与浙江库里根本没有对应记录。

ELDER-ICU-DB 把这三层差异收拢到一个变量层:统一变量名、统一计算方法、并明确写出哪些变量在哪些源库不可用。这是它最实际的价值——省掉的不是算力,是几个月的表结构学习成本。

1.3 它能给到的与给不到的

你的需求 它给的 够不够
老年 ICU 患者的 28 天死亡预测 death_28d 二分类 + survival_time_28d 右删失生存时间,四源库统一口径 够,且可直接做跨库外测
跨库外部验证 四个独立源库、三国、209 站点,变量名一致 够,这是它的核心设计目标
严重程度评分的老年人群验证 oasis、saps、sofa、cci_score 四项现成 够,评分已由官方按入 ICU 头 24 小时参数算出
老年衰弱与营养风险研究 activity_stand / activity_sit / activity_bed + gnri 够做探索,注意各源库是否评估过(有 *_eva_flag)
抢救意愿(code status)相关研究 code_status + code_status_eva_flag 只够在两个源库上做,SICdb 与浙江库无此参数
长时间纵向轨迹研究 无 不够,每人每次住院只保留首个 ICU 停留,且只看头 24 小时
用药剂量与滴定过程 4 类血管活性药的二值使用标志 不够,只有用过/没用过,没有剂量与时长
波形或高分辨率生命体征 无 不够,全部为聚合后的均值/极值标量
同一个人多次住院的序列 源库标识保留,可回原库取 本包内不够,且标识不能跨库链接
65 岁以下人群 无 不够,纳入标准即 ≥65 岁

1.4 你的处境与它能帮到的事

你的处境 它能帮你什么 下一步该做什么
你有一个只在 MIMIC 上训练的老年死亡预测模型 提供 eICU-CRD、SICdb、浙江三个独立外部测试集,变量名已对齐 按源库做留一库交叉验证(leave-one-database-out),逐库报告而不是合并报告
你想知道某个评分在中国人群上还准不准 浙江库 1,409 次住院构成亚洲子集 先确认样本量是否支撑你的结局事件数,再决定是否合并三国一起报
你被五个源库的表结构劝退过 四张宽表、一行一次住院、变量名统一 直接读 CSV,跳过 SQL 建库;需要更多原始字段时再回源库
你在做衰弱或营养风险与预后的关联 activity_* 与 gnri 已算好,GNRI 公式与阈值官方给出 用 activity_eva_flag 先筛出真正被评估过的住院,否则"未评估"会被当成"不能站立"
你要比较不同医疗系统的重症结局 eICU-CRD 独有 hospitalid、teachingstatus、region 三个医院层变量 医院层比较只能在 eICU-CRD 子集内做,跨库没有可比变量
你想复现已有的跨国重症研究 提供与 ELDER-ICU 系列研究一致的协调口径 按 §9.3 同时引用本库与五个父库

1.5 一句话判断

它不是"把五个库拼成更大的一个库",而是"把五个库翻译成同一种语言"——规模没有变大,可比性变大了,而后者正是多中心研究真正缺的东西。

1.6 不适合谁:四条边界

不适合做纵向或时序建模。 每人每次住院只留首个 ICU 停留,生理变量只看入 ICU 后头 24 小时并聚合成均值或极值。想研究轨迹、拐点、治疗反应动态,这份数据给不了,必须回源库。

不适合做跨库个体链接。 官方明确说明源库标识只在各自库内唯一,不能用来把同一个人在不同库之间的记录连起来。任何"跨国追踪同一患者"的设计都不成立。

不适合拿来做全人群基线。 纳入标准即 65 岁及以上,且排除了 ICU 停留不足 24 小时、缺少年龄或结局、以及入 ICU 首日缺少六项基线生理参数中任一项的住院。它描述的是"住满一天的老年重症患者",不是所有老年重症患者。

不适合绕过源库的许可。 它沿用父库的访问政策、许可与使用要求。拿到它的访问权不等于拿到五个源库的访问权,反向也不成立:想回源库取更多字段,仍要单独申请对应源库。

§2 数据构成与规格

2.1 四张宽表加一份可用性矩阵

官方页面给出的数据文件清单如下。注意 MIMIC-III 与 MIMIC-IV 被合并进同一个文件,所以五个源库对应四个文件。

文件 源库 行数 列数 源库专属标识
MIMIC.csv MIMIC-III, IV 48,708 78 subject_id、hadm_id、stay_id
eICU-CRD.csv eICU-CRD 37,166 81 uniquepid、patientunitstayid
SICdb.csv SICdb 6,371 77 patientid、hadm_id
ZhejiangProvinceICU.csv ZhejiangProvinceICUdb 1,409 78 patient_sn、hospital_id

第五个文件 Variable_Availability_Matrix.csv 不是数据表,而是一份"变量 × 源库"的可用性说明。它的存在本身就是一条声明:这套数据不是完整协调,而是"尽力协调 + 显式标注缺口"。用法见 §5.5。

2.2 标识体系:一行是什么,怎么回源库

源库 患者标识 ICU 住院标识
MIMIC subject_id stay_id
eICU-CRD uniquepid patientunitstayid
SICdb patientid hadm_id
ZhejiangProvinceICU patient_sn hospital_id

除源库标识外,官方另设了一个复合标识 id,用于唯一定位每一次 ICU 住院。官方强调这些标识都是假名化的,不构成直接识别风险;但它们的唯一性严格限于各自源库之内。

这里有一个容易被忽略的技术细节:hospital_id 在浙江库里承担的是"ICU 住院标识"的角色,而在 eICU-CRD 的语义里 hospitalid 指的是医院。两处拼写只差一个下划线,含义完全不同,跨库写代码时极易混用。

2.3 一行记录的完整解剖

一行 = 一次 ICU 住院。按主题把列拆开看,结构是这样的:

人口学与身份:id(复合标识)、age(精确周岁)、gender(F/M)、源库专属的患者与住院标识。

入院与住院特征:weight(入院体重,千克)、height(入院身高,厘米)、anchor_year_group(入院年份分组)、admission_type(择期、紧急、急诊、观察四类)、first_careunit(本次住院中首个入住的 ICU 单元)、los_icu_day(本次 ICU 停留天数)、los_hospital_day(本次住院总天数)、pre_icu_los_day(入 ICU 前已住天数)。

结局:death_hosp(住院死亡,1 为死亡、0 为存活出院)、deathtime_icu_hour(入 ICU 至死亡的小时数,存活者为空)、death_28d(28 天全因死亡二分类)、survival_time_28d(28 天生存时间,右删失于 28 天)。

eICU-CRD 独有:hospitalid(医院编号)、teachingstatus(是否教学医院)、region(美国四大区域:东北、中西部、南部、西部)。

生命体征 8 项、实验室 27 项、血气 7 项、治疗 4 项、血管活性药 4 项、衰弱与营养 5 项、评分 4 项,分别见 2.4—2.8。

关于身高与体温,官方给出两段明确的值域说明,这是本数据集少有的、由官方直接披露的边界信息:身高在 MIMIC 与 eICU-CRD 中多数落在 121—226 厘米;SICdb.csv 有 4 条身高低于 100 厘米(60—95 厘米之间),ZhejiangProvinceICU.csv 有 1 条身高为 53 厘米。体温在 MIMIC 与 eICU-CRD 中多数落在 31—40 摄氏度;SICdb.csv 有 483 条低于 34 摄氏度、12 条高于 42 摄氏度。官方明确表示这些离群值被保留,交由研究者按自己的分析需要决定剔除标准。

2.4 生命体征:8 项,全部是聚合值

变量名 定义
spO2_min 脉搏血氧饱和度最低值(%)
heart_rate_mean 心率均值
mbp_mean 平均动脉压均值
sbp_mean 收缩压均值
resp_rate_mean 呼吸频率均值
temperature_mean 体温均值
gcs_min 格拉斯哥昏迷评分最低值
urineoutput 总尿量(毫升)

命名规则值得记牢:_mean 是 24 小时窗口内的算术平均,_min 与 _max 是窗口内的极值。这不是随意选的——收缩压用均值而血氧用最低值,反映的是临床上"最低血氧比平均血氧更能说明问题"的共识。做特征工程时不要把 spO2_min 当成"平均血氧"来解读。

2.5 实验室 27 项与血气 7 项

变量名 定义 变量名 定义
creatinine_max 肌酐最高值 alt_max 丙氨酸氨基转移酶最高值
bilirubin_max 胆红素最高值 ast_max 天冬氨酸氨基转移酶最高值
platelet_min 血小板最低值 alp_max 碱性磷酸酶最高值
bun_max 尿素氮最高值 pt_max 凝血酶原时间最高值
wbc_max 白细胞最高值 ptt_max 部分凝血活酶时间最高值
glucose_max 血糖最高值 inr_min 国际标准化比值最低值
hematocrit_max 血细胞比容最高值 chloride_min 血清氯最低值
potassium_max 血钾最高值 troponin_max 肌钙蛋白最高值
sodium_max 血钠最高值 lymphocytes_min 淋巴细胞最低值
bicarbonate_min 碳酸氢盐最低值 lymphocytes_max 淋巴细胞最高值
bicarbonate_max 碳酸氢盐最高值 neutrophils_min 中性粒细胞最低值
albumin_min 白蛋白最低值 magnesium_max 血清镁最高值
fibrinogen_min 纤维蛋白原最低值 bnp_max B 型脑钠肽最高值
aniongap_max 阴离子间隙最高值
变量名 定义
pao2_min 氧分压最低值
paco2_max 二氧化碳分压最高值
lactate_max 乳酸最高值
baseexcess_min 碱剩余最低值
fio2_max 吸入氧浓度最高值
pao2fio2ratio_novent 未机械通气时的氧合指数
pao2fio2ratio_vent 机械通气时的氧合指数

氧合指数拆成通气与未通气两个变量,是这套协调里少见的"语义层面"处理:同一个比值在两种状态下的临床含义与分布都不同,混在一个列里会引入可避免的偏倚。

2.6 治疗、用药与老年专属变量

类别 变量名 定义
治疗 electivesurgery 是否为择期手术后计划性入 ICU(1 是、0 否)
治疗 vent 是否接受机械通气(1 是、0 否)
治疗 code_status 抢救意愿(1 为部分抢救、0 为全力抢救)
治疗 code_status_eva_flag 是否评估并记录过抢救意愿
用药 norepinephrine 是否使用去甲肾上腺素
用药 epinephrine 是否使用肾上腺素
用药 dopamine 是否使用多巴胺
用药 dobutamine 是否使用多巴酚丁胺
衰弱 activity_stand 能否独立站立或行走
衰弱 activity_sit 能否独立坐起但限于轮椅
衰弱 activity_bed 是否只能床上活动
衰弱 activity_eva_flag 是否评估并记录过活动能力
营养 gnri 老年营养风险指数

code_status 的编码方向要特别小心:1 代表部分抢救(含不复苏、不插管或舒适护理),0 代表全力抢救。这与"1 表示更积极"的直觉相反。同时它只在 MIMIC 与 eICU-CRD 两个源库上存在,SICdb 与浙江库因源库本身不记录而无此参数。

2.7 四项评分

变量名 评分 构成与范围
cci_score Charlson 合并症指数 合并症加权计分
oasis 牛津急性疾病严重程度评分 年龄、心率、收缩压、体温、呼吸频率、氧合、意识水平、入 ICU 类型;不依赖实验室值
saps 简化急性生理评分 II 入 ICU 头 24 小时生理变量 + 年龄 + 严重合并症 + 入院类型
sofa 序贯器官衰竭评分 呼吸、循环、肝、凝血、肾、神经六个系统各 0—4 分,总分 0—24

gcs_min 既是生命体征之一,也是 SOFA 与 SAPS II 的组成部分;格拉斯哥昏迷评分范围 3(深昏迷)至 15(完全清醒)。评分由官方依据入 ICU 头 24 小时记录的生理参数计算,这一点在跨库比较时很重要——如果换成自己重算,口径会与官方列不一致。

2.8 派生变量是怎么算出来的

GNRI 的官方公式与配套定义如下,它是本数据集最具"老年专属"色彩的派生量:

GNRI = (14.89 × 白蛋白 [g/dL]) + (41.7 × min(IBW/ABW, 1))

#-- 白蛋白取本次 ICU 住院期间的实验室测量值
#-- 理想体重 IBW 用 Devine 公式估算:
#--   女性 IBW(kg) = 45.5 + 0.9 × (身高[cm] − 152)
#--   男性 IBW(kg) = 48.0 + 0.9 × (身高[cm] − 152)
#-- 判读阈值:GNRI < 92 为高营养风险,≥ 98 为低风险

衰弱三项的构造逻辑是从 chartevents 或 careplangeneral 表里、入 ICU 前后各 24 小时窗口内的事件做条件聚合:出现"行走"“步行十步以上"一类记录则 activity_stand 置 1;出现"轮椅”“转移至轮椅"一类则 activity_sit 置 1;出现"卧床”“仅能平卧”"床上翻身"一类则 activity_bed 置 1。三项互不排斥,同一个人可以同时被标记为能站立与能坐起。

28 天生存时间的删失规则官方写得很细:超过 28 天观察窗仍存活者记为 28 天,死亡者记实际生存时长(≤28 天)。值为 0 表示入 ICU 当天死亡,原因是源库 MIMIC 的死亡日期只精确到日,而入 ICU 时间精确到秒。源数据有误导致无法可靠判定的记录被赋为空值,官方建议按数据瑕疵处理并自行决定剔除。

2.9 与同类资源的字段差异

对比项 ELDER-ICU-DB 源库原生表格 通用协调框架产出
组织形态 四张宽表 CSV,一行一次 ICU 住院 多表关系型 schema,需 SQL 关联 长表或标准数据模型的垂直表
变量命名 跨源库统一,聚合口径写在名字里 各库自成体系 概念编码体系
时间粒度 入 ICU 头 24 小时的聚合标量 逐条事件带时间戳 常见固定时间栅格
标识 保留源库标识 + 复合 id,不可跨库链接 库内唯一 通常重新生成统一标识
缺口处理 用一份变量可用性矩阵显式标注 无显式说明 依框架而定
人群限定 65 岁及以上、ICU 停留 ≥24 小时 全人群 通常不限

§3 它的数据来自哪里

3.1 贡献者与机构

作者 机构 与源库的关系
Sicheng Hao 新加坡国立大学;MIT 计算生理学实验室(LCP) 协调与派生变量实现
Niklas Rodemund 奥地利萨尔茨堡帕拉塞尔苏斯医科大学 SICdb 原始贡献方一侧
Xiaoli Liu MIT 计算生理学实验室 ELDER-ICU 系列研究的延续

平台侧由 MIT 计算生理学实验室维护,受美国国立生物医学影像与生物工程研究所(NIBIB)、国家心肺血液研究所(NHLBI)及 NIH 主任办公室资助。

3.2 时间线

时间 事件 规模口径
2023 年 ELDER-ICU 研究发表(Lancet Digital Health),用机器学习做老年重症的严重程度评估并做亚组偏倚评价 跨国多中心方法学铺垫
2025 年 7 月 30 日 同名数据集在 figshare 首度公开,CC BY 4.0 六个源库、210 个站点、四国、96,668 次住院
2026 年 10 月 27 日 PhysioNet v1.0.0 正式发布 五个源库、209 个站点、三国、93,654 次住院

两个版本之间的差别不是笔误:figshare 版本纳入了 AmsterdamUMCdb,因而多出荷兰这一个国家、一个站点与 3,014 次住院;PhysioNet 版本去掉了它,许可也从 CC BY 4.0 换成需要审批的 Contributor Review 许可。引用时必须写清用的是哪一个版本(§9.3)。

3.3 五个源库各自的采集场景

源库 场景 时间跨度 站点规模
MIMIC-III / MIMIC-IV 美国波士顿贝斯以色列女执事医疗中心的电子病历 2001—2022 单一医疗中心
eICU-CRD 美国远程重症监护网络 2014—2015 两百余个站点
SICdb 奥地利萨尔茨堡,高分辨率重症数据 官方未列明 单一医院集团
ZhejiangProvinceICUdb 中国一家三级医院的中心 ICU 与急诊 ICU(EICU) 2012—2022 单一三级中心

合计 209 个站点。这个数字的含义要解释一下:它主要由 eICU-CRD 的两百余个站点贡献,另外三个源库各按一个到数个站点计。所以"209 个站点"并不等于"209 家医院各自有相当的样本量"——样本在站点间的分布极度不均,这一点在做医院层分析时是硬约束。

3.4 数据的三个层次

第一层是各医院的信息系统原始记录,研究者接触不到。第二层是五个公开源库,各自完成了去标识与结构化,各有各的表设计与变量口径。第三层才是 ELDER-ICU-DB:它在第二层之上做抽取与派生,产出统一命名的宽表。

MIMIC-III 与 MIMIC-IV 的关系需要单独说明。两者来自同一家医院、覆盖时间前后相接,官方把它们的抽取结果并进了同一个 MIMIC.csv,共 48,708 次住院。这对使用者是好事——不必自己处理两代 schema 之间的差异——但也意味着这个文件内部存在两个不同时期的数据源,如果研究问题对电子病历系统的版本敏感,需要回到源库区分。

理解这三个层次,才能理解它的权限结构。它没有引入任何新的受保护健康信息,去标识沿用源库提供方的标准;但它也没有绕过任何一道审批——访问它需要 PhysioNet 认证、签署数据使用协议、并由贡献者逐个项目审核研究问题。

§4 它最独特的东西

4.1 老年专属变量是它真正的增量

重症库里"年龄"几乎总是有的,但年龄只是一个数字。官方页面给这个数据集的独特性定位很清楚:除常规临床数据外,它整合了与老年脆弱性直接相关的变量——躯体衰弱、GNRI 与抢救意愿。

这三类变量在源库里都不以现成字段存在,必须从护理记录与护理计划文本里重建。官方的做法是:活动能力按入 ICU 前后 24 小时窗口内的事件做条件聚合成三个二值标志,抢救意愿从 chartevents / careplangeneral 里推出"全力抢救"与"部分抢救"两类,GNRI 则用白蛋白与理想体重比算出来。

这解释了为什么这类变量稀少:它们不在结构化的检验与用药数据里,而在最脏的自由文本护理记录里,且不同医院记录习惯差异极大。把它们跨库协调出来,是这份数据最不可替代的部分。

4.2 一个"评估过没有"的标志位,比变量本身更重要

code_status_eva_flag 与 activity_eva_flag 这两个标志位容易被当成冗余列跳过,其实它们是整套数据里最关键的守护字段。原因很简单:在护理记录里"没写"不等于"没有"。一个人没有被记录为"能站立",可能因为他确实卧床,也可能只是因为那天没人评估。没有 activity_eva_flag 就把 0 当作"不能站立",等于把记录行为的差异当成临床状态的差异。

正确用法是先用标志位筛出被评估过的子集,再在这个子集里解释 activity_* 与 code_status。这不是精细化的建议,是能不能得出结论的分界线。

4.3 案例:一次跨三国的外部验证怎么搭

假设你在 MIMIC 上训练了一个老年 ICU 患者 28 天死亡预测模型。传统做法要你去申请 eICU-CRD、SICdb、浙江库,各学一套 schema,各写一份抽取脚本,然后祈祷四边的变量口径一致。用 ELDER-ICU-DB 的话,流程变成:

第一步,读 MIMIC.csv,用统一变量名训练,源库标识先放一边。第二步,把 eICU-CRD.csv、SICdb.csv、ZhejiangProvinceICU.csv 各自的列对齐到训练时用的变量集合,只保留四个文件都存在的列。第三步,逐库评估而不是合并评估——每一份结果单独报告,差异本身就是研究结论。第四步,如果要回源库补充字段,用各自的患者与住院标识回去取,不要试图跨库链接同一个人。

这个流程的价值不在省时间,在于它让"跨国验证"从需要一支工程团队变成一个人能做的事。

4.4 协调的粒度:名字统一了,值域没有

要清醒地看到协调停在哪一层。变量名统一了,聚合口径统一了(均值还是极值写在名字里),派生方法统一了(GNRI 与评分的公式公开)。但值域没有统一:官方明确列出了身高与体温在不同源库里的离群情况,并把剔除权交给使用者。语义也没有完全统一:抢救意愿两个源库有、两个源库没有,活动能力评估的覆盖程度各库不同。

所以更准确的描述是"协调到可比较,但未协调到可合并"。把四个文件直接 concat 之后当成一个大样本跑模型,是把可比较误当成可合并——这也是本数据集最容易犯的错(§5.6)。

4.5 边界条件:什么情况下它不再适用

研究问题需要入 ICU 24 小时之后的生理演变时不适用;需要同一个人多次住院序列时不适用;需要用药剂量、滴定或持续时间时不适用;需要在 65 岁以下人群上验证时不适用;需要在医院层面做跨库比较时不适用(医院层变量只有 eICU-CRD 有);需要把同一个患者在不同国家的记录连起来时不适用。

还有一个隐含边界:所有住院都满足"入 ICU 首日具备心率、呼吸频率、平均动脉压、GCS、体温、血氧饱和度六项基线"。这意味着最危重、监测最不完整的那部分住院从一开始就不在库里。如果研究问题恰恰是关于"数据不全的患者怎么办",这份数据给不了答案。

§5 怎么拿到

5.1 文件构成与可见性

文件 角色 匿名可见
MIMIC.csv 数据(48,708 × 78) 否
eICU-CRD.csv 数据(37,166 × 81) 否
SICdb.csv 数据(6,371 × 77) 否
ZhejiangProvinceICU.csv 数据(1,409 × 78) 否
Variable_Availability_Matrix.csv 变量 × 源库可用性说明 否

整个数据包位于受控访问之下。直接请求文件目录会返回 403;项目页的"Files"区也会提示当前区域不可获取数据。这不是网络问题,是访问策略。

5.2 申请流程的五个步骤

步骤 做什么 注意
1 注册并通过 PhysioNet 认证(credentialed user) 需要身份证明与机构信息
2 完成 CITI “Data or Specimens Only Research” 培训 官方列出的必需培训项
3 签署 PhysioNet Contributor Review Health Data Use Agreement 1.5.0 与许可配套
4 提交项目申请,写明具体研究问题 官方明确要求"具体的研究问题"
5 等待贡献者审批通过后下载 逐项目审批,不是一个账号一次性放行

第四步值得强调:官方页面写的是"提交一份带有具体研究问题的项目申请,由贡献者审批"。泛泛的"探索性分析"很可能不会被批准,申请时把研究问题、变量清单与分析计划写清楚。

5.3 批量下载

获批后按常规方式下载即可。下面给出带断点续传的写法:

#-- 用 PhysioNet 账号名替换 <user>;执行后会提示输入密码
wget -r -N -c -np --user <user> --ask-password \
     https://physionet.org/files/elder-icu-db/1.0.0/

整包由四张宽表加一份矩阵构成,行数合计 93,654 行、列数在 77 到 81 之间,体量远小于任意一个源库原始包。官方未公布总字节数,本文不作估算。

5.4 读进来并做跨库对齐

import pandas as pd

FILES = {
    "MIMIC": "MIMIC.csv",
    "eICU":  "eICU-CRD.csv",
    "SICdb": "SICdb.csv",
    "ZJ":    "ZhejiangProvinceICU.csv",
}

frames = {}
for name, path in FILES.items():
    df = pd.read_csv(path, low_memory=False)
    df["source_db"] = name          #-- 源库标签必须自己加,包内没有这一列
    frames[name] = df
    print(name, df.shape)

#-- 只保留四个文件共有的列,避免把"某库没有"当成"该值为零"
common = None
for df in frames.values():
    cols = set(df.columns)
    common = cols if common is None else (common & cols)
common = sorted(common)

stack = pd.concat([df[common] for df in frames.values()], ignore_index=True)
print("共有列", len(common), "合并行数", len(stack))

这段代码里唯一非显而易见的一行是 df["source_db"] = name。包内没有任何一列标明这一行来自哪个源库,文件名是唯一的线索;一旦合并就必须自己带上,否则后面一切跨库分析都无从做起。

5.5 变量可用性矩阵怎么用

import pandas as pd

m = pd.read_csv("Variable_Availability_Matrix.csv")

#-- 找出只在部分源库存在的变量
partial = m[(m > 0).sum(axis=1) < m.shape[1]] if m.select_dtypes("number").shape[1] else m
print(partial.head(20))

#-- 更稳妥的做法:直接按源库实际列判断
have = {}
for name, path in {"MIMIC": "MIMIC.csv", "eICU": "eICU-CRD.csv",
                   "SICdb": "SICdb.csv", "ZJ": "ZhejiangProvinceICU.csv"}.items():
    have[name] = set(pd.read_csv(path, nrows=1).columns)

missing = {k: sorted(common_set - v) for k, v in have.items()}

矩阵的用法是筛变量,不是补数据。它告诉你哪些列在哪些源库里真的被填过;拿到这个信息后,要么只在共同列上做跨库分析,要么把缺列的源库排除出对应子分析。绝不能把缺失当成零值或阴性。

5.6 五个最容易出错的地方

第一,把四个文件直接合并当成一个大样本。 源库之间的病例构成、站点结构、记录习惯都不同,合并后会掩盖而不是解决异质性。正确做法是逐库评估、分别报告。

第二,把 _eva_flag 当成冗余列丢掉。 见 §4.2,丢掉它等于把"没评估"当成"不存在"。

第三,把 code_status 的编码方向读反。 1 是部分抢救,0 是全力抢救。

第四,把 hospital_id(浙江库的 ICU 住院标识)与 hospitalid(eICU-CRD 的医院编号)混为一谈。 两处拼写极近,语义完全不同。

第五,用 survival_time_28d 做连续回归却忘了它是右删失的。 存活超过 28 天的一律记为 28,值 0 表示入 ICU 当天死亡,另有因源数据错误被赋空的记录。做生存分析要按删失数据处理,做回归要先决定这些记录的去留。

§6 与站内数据集的关系

6.1 关系图谱

站内数据集 关系 判据
sicdb 直接上游源库 贡献 6,371 次住院,欧洲侧唯一来源
zhejiang-ehr-critical-care 直接上游源库 贡献 1,409 次住院,亚洲侧唯一来源
eicu-crd 直接上游源库 贡献 37,166 次住院,站点数的主要来源
eicu-collaborative-legacy 同源旧版 eICU 系列的早期形态
lacuna 同类协调工作,范围更大 九个源库、约六十万住院、概念层协调;不限年龄
mimic3-carevue MIMIC-III 子集 单一源库内的子集,不做跨库协调
mimic2-iaccd MIMIC-II 临床表 早期 MIMIC 系列,未纳入本库
mimicdb MIMIC 初代多参数库 波形侧,与聚合标量路线不同
mimic-seqex 序列抽取方向 强调纵向序列,本库强调跨库横截面
mimic-iv-fhir 同一源库的不同重写形态 FHIR 资源化,本库为扁平宽表
gossis-1 全球重症时序(对照) 多国重症,但组织方式与变量口径不同
cinc-2019 脓毒症早期预测挑战赛 任务导向,非老年限定
clif 重症数据协调框架 提供标准化口径,与本库的宽表产出不同层级
mimic-br 巴西 ICU 的 OMOP 形态 标准数据模型路线,本库不做模型化转换
chinese-critical-care-database 中国重症库(对照) 同为中文重症资源,未纳入本库
mimic-eicu-fiddle-feature 特征矩阵路线 自动特征工程产出,非人工协调变量

6.2 检索路径

想找"跨国多中心重症数据",先落到这里,再根据是否需要纵向序列决定去 lacuna 还是 mimic-seqex。想找"某个源库的更多细节",按上表第一列回到对应源库词条。想找"标准数据模型形态的重症数据",去 mimic-br 与 clif。想找"任务化基准",去 cinc-2019 与 gossis-1。

6.3 与其他库的分工判据

你的问题 该用哪个 理由
老年重症的跨国验证 本库 唯一的 ≥65 岁限定 + 三国 + 统一变量名
不限年龄的大规模重症协调 lacuna 九个源库、约六十万住院,规模与覆盖面更大
纵向轨迹与时序建模 源库原生或序列抽取版本 本库只保留头 24 小时聚合值
标准数据模型(OMOP 类)集成 mimic-br 一类 本库不采用标准数据模型的垂直表结构
单一源库内的深度挖掘 对应源库词条 本库是抽取层,字段数远少于源库
挑战赛式可复现基准 cinc-2019、gossis-1 有固定任务定义与评测口径

§7 质量评估与局限性

7.0 阅读本节前的一个前置校正

评价这份数据不能用"规模"这把尺子。93,654 次住院在任何单一源库面前都不算大,它的价值在于可比性与变量协调的完成度。用规模去衡量,会得出"不如直接用 MIMIC-IV"的错误结论——而那恰恰是它要解决的问题的反面。

7.1 五维评分

维度 评价 依据
规模 中等 93,654 次住院、209 站点,小于单个源库全量
结构清晰度 高 四张宽表、一行一次住院、变量名自带聚合口径
变量协调度 中上 命名与派生方法统一,值域与语义未统一,缺口显式标注
人群专属性 高 ≥65 岁限定 + 衰弱、GNRI、抢救意愿三类老年变量
获取成本 高(负向) 认证 + 培训 + DUA + 贡献者逐项目审批

7.2 协调的两层:做到了哪一层

第一层是"名字协调":同一个概念在四个文件里叫同一个名字,聚合方式写在后缀里。这一层做到了,且做得清楚。

第二层是"值协调":同一个变量在不同源库里的取值分布、单位、离群结构一致。官方没有宣称做到了这一层,反而主动披露了身高与体温的跨库离群情况,并声明把剔除权交给使用者。

第三层是"语义协调":同一个变量在不同医疗系统里是否真的在测量同一件事。抢救意愿在两种医疗文化里的记录习惯差异,官方没有展开,只是用 code_status_eva_flag 把"是否被评估"暴露出来,让研究者自己判断。

它做到了第一层,诚实标注了第二层的缺口,把第三层的判断权交给了使用者。这个姿态本身值得肯定——比宣称"完全协调"要可靠。

7.3 已知的、可枚举的偏差

偏差类型 具体表现 官方依据
纳入偏差 只纳入 ≥65 岁患者 纳入标准明文
时间窗偏差 只保留每次住院的首个 ICU 停留;生理变量只看头 24 小时 方法段明文
监测完整性偏差 排除入 ICU 首日缺少心率、呼吸频率、平均动脉压、GCS、体温、血氧中任一项的住院 排除标准明文
停留时长偏差 排除 ICU 停留不足 24 小时的住院 排除标准明文
站点分布偏差 209 个站点主要来自 eICU-CRD,另三个源库站点数很少 源库构成可推
地理代表偏差 三个国家、四个源库,无非洲、拉美、南亚等地区 源库清单
变量覆盖偏差 抢救意愿在 SICdb 与浙江库不可用 官方明文
值域偏差 身高与体温在部分源库存在离群值,官方保留未剔除 官方明文披露
时代偏倚 2001 至 2022 横跨二十二年,重症监护的理念、设备与记录规范在此期间多次更迭 时间跨度本身可推

上表最后一条常被忽略,但它是跨库比较时最容易出错的地方。四个源库的时间跨度并不对齐:eICU-CRD 集中在 2014 至 2015 两年,浙江库是 2012 至 2022 年,MIMIC 覆盖 2001 至 2022 年。当一次跨库比较发现差异时,差异既可能来自人群与医疗体系,也可能来自年份——两者在这份数据里是纠缠的。官方没有提供把年份拆开的现成方案,研究者需要自己把 anchor_year_group 纳入分层或敏感性分析,否则"跨国差异"有可能只是"跨年代差异"的另一种说法。

7.4 外部验证矩阵

验证场景 可行性 条件
在 MIMIC 训练、eICU-CRD 测试 高 变量重叠充分,样本量充足
在 MIMIC 训练、SICdb 测试 中 6,371 次住院,事件数需先核算
在 MIMIC 训练、浙江库测试 中 1,409 次住院,适合做方向性验证而非精确估计
留一库交叉验证(四折) 高 最贴合本库设计的用法
三国合并后随机划分 低 会掩盖跨库异质性,与数据设计意图相悖
与第五个源库(荷兰)对照 不适用 PhysioNet v1.0.0 已移除 AmsterdamUMCdb

7.5 它为何能持续

老年重症研究的需求在增长,而能做跨国验证的资源没有同步增长。这份数据的护城河不在数据量——93,654 行随时可以被更大规模的协调工作超过——而在于它把最难协调的三类老年变量做出来了,并且把每一步派生方法与每一个缺口都写进了文档。后来者要复现的不是那 93,654 行,而是那套从护理记录里重建衰弱与抢救意愿的规则。

§8 生态位与历史

8.1 历史沿革

它的学术起点是 2023 年发表在 Lancet Digital Health 的 ELDER-ICU 研究,那项工作用机器学习评估老年重症患者的疾病严重程度,并专门做了亚组偏倚评价。 coordination 的需求正来自那里:要评价亚组偏倚,就得有多个国家的可比数据。

2025 年 7 月,同名数据集以 CC BY 4.0 在 figshare 首次公开,当时纳入六个源库、210 个站点、四个国家、96,668 次住院。2026 年 10 月 27 日,它以 Contributor Review 许可登陆 PhysioNet,规模调整为五个源库、209 个站点、三个国家、93,654 次住院。

8.2 与挑战赛的关系

它不与任何挑战赛绑定。PhysioNet 上的重症类挑战赛(如脓毒症早期预测)有自己的任务定义、固定划分与评测口径,而这份数据是开放用途的协调资源:官方列出的用途是预后研究、死亡预测、风险分层、跨医疗系统的比较效果研究,以及四项评分在老年人群中的验证与基准比较。想做可比的排行榜式评测,需要自己定义划分口径并公开。

8.3 生态位:可比性的供应商

在公开重症数据的生态里,源库提供深度,协调层提供广度。它属于后者,且在后者里选择了一个窄而深的切口:不做全人群的大协调,只做老年人群;不追求最大规模,只追求变量可比;不隐藏缺口,用一份矩阵把缺口摆出来。

把它和范围更大的协调工作放在一起看,分工就更清楚了:后者追求源库数量与总住院数,用概念层把尽可能多的库拉到同一张桌子上,代价是变量粒度必须妥协到"大多数库都有"的水平;本数据集反其道而行,先把人群收窄到 65 岁及以上,再把变量往深处做——衰弱、营养风险、抢救意愿这些变量在大规模协调里通常第一批被舍弃,因为只有少数库记录它们。

这个切口的代价是它注定不会成为"最大"的那一个。收益是它对老年重症研究者来说几乎是唯一选择——规模更大的协调工作通常不限年龄,而限年龄的工作通常不跨三国。

8.4 谁在用它

官方列出的目标使用者是做老年重症预后、死亡预测、风险分层与跨系统比较效果研究的团队,以及需要验证 OASIS、SAPS II、SOFA、CCI 在老年人群里表现的团队。工程侧的典型使用者是想跳过 SQL 建库、直接用 CSV 做多中心实验的机器学习研究者。

由于它 2026 年 10 月才发布,目前还没有公开的第三方使用报告可供引用;本文不对其使用现状作任何推断。

§9 使用指引

9.1 三种角色的路径

角色 最短路径 要避开的坑
临床研究者 选一个源库做训练、其余做外测;用官方算好的四项评分做比较 不要把四库合并后随机划分
机器学习工程师 读四个 CSV,按共有列对齐,加 source_db 列,做留一库交叉验证 不要把变量名里的 _min/_max 当成均值
老年医学研究者 以 activity_eva_flag 与 code_status_eva_flag 筛出被评估子集,做衰弱与营养风险分析 不要把"未评估"当成"不存在"

9.2 一条最短的可用流程

第一步,完成 §5.2 的五个申请步骤。第二步,下载五个文件放到同一目录。第三步,按 §5.4 的代码读入并加源库标签。第四步,用 §5.5 的方法确定共有列集合。第五步,确定结局变量:death_28d 用于分类,survival_time_28d 用于生存分析并记得它是右删失于 28 天的。第六步,按源库分组评估,逐库报告。第七步,写论文时按 §9.3 同时引用本库与所用到的父库。

9.3 引用方式

引用本数据集:

@article{PhysioNet-elder-icu-db-1.0.0,
  author = {Hao, Sicheng and Rodemund, Niklas and Liu, Xiaoli},
  title  = {{ELDER-ICU-DB: A Comprehensive Critical Care Data Resource
             for International Multicenter Study on Elderly ICU Patients}},
  journal = {{PhysioNet}},
  year   = {2026},
  month  = oct,
  note   = {Version 1.0.0},
  doi    = {10.13026/126e-mx94},
  url    = {https://doi.org/10.13026/126e-mx94}
}

同时必须引用所用到的父库,官方在项目页的 Parent Projects 一节列出了五个:

父库 版本
MIMIC-III Clinical Database v1.4
MIMIC-IV v3.1
eICU Collaborative Research Database v2.0
Salzburg Intensive Care database (SICdb) v1.0.8
Establishment of a Chinese critical care database from electronic healthcare records in a tertiary care medical center v1.0

此外,PhysioNet 要求同时引用平台本身的文献(Pollard 等,2026,Nature Health)。如果引用的是 2025 年 figshare 版本的口径(六库、210 站点、四国、96,668 次住院),务必改引 figshare 记录并注明许可为 CC BY 4.0,不要与 PhysioNet v1.0.0 的口径混用。

§10 AI 使用声明

项目 声明
文本生成 本文由 AI 辅助撰写,编辑把关结构与事实
数字来源 规模、结构、边界三类数字全部来自 PhysioNet 官方项目页(v1.0.0)的摘要、方法、数据描述与使用说明各节
文件核验 官方页列出的五个文件名与行数、列数经项目页 Table 1 与正文确认;文件本体因受控访问无法匿名下载,未做逐列核验
版本不一致 figshare 2025 首版为六库、210 站点、四国、96,668 次住院、CC BY 4.0;PhysioNet v1.0.0 为五库、209 站点、三国、93,654 次住院、Contributor Review 1.5.0。本文以 PhysioNet v1.0.0 为准,差异已在 §3.2 与 §8.1 说明
论文信息 仅参考官方页列出的参考文献条目,未读全文
未核验内容 数据包总字节数、各变量在每个源库的实际填充行数、各源库站点的逐个数目、SICdb 与浙江库的时间跨度起止
图像 无配图;封面为生成式提示词,不含真实患者数据
免责 本文不构成临床建议;数据使用须遵守 PhysioNet Contributor Review Health Data License 1.5.0 与数据使用协议

常见误读(避坑清单)

说法 实际 证据
「它把五个库合并成了一张大表」 五个源库对应四个 CSV,MIMIC-III 与 IV 合一,其余各占一个文件 官方 Table 1
「它是 OMOP 或标准数据模型」 不是;它是扁平宽表 CSV,无标准数据模型的垂直表结构 官方文件清单只有四个 CSV 加一份矩阵
「93,654 是患者数」 是 ICU 住院次数;同一患者可多次住院,且只保留每次住院的首个 ICU 停留 官方"仅分析每次住院的首个 ICU 入住"
「四库可以直接 concat 成一个大样本」 可比较不等于可合并;跨库异质性会被掩盖 官方用途说明强调跨库分析而非合并建模
「code_status 为 1 表示全力抢救」 1 是部分抢救,0 是全力抢救 官方变量定义
「SICdb 和浙江库也有抢救意愿」 没有,两个源库均不评估此参数 官方明文说明
「身高低于 100 厘米的记录已被清洗」 保留了 4 条 SICdb 与 1 条浙江库的离群身高,交由使用者决定 官方变量说明
「survival_time_28d 是真实生存天数」 右删失于 28 天;存活超窗者一律记 28,值为 0 表示入 ICU 当天死亡 官方变量定义
「hospital_id 是医院编号」 在浙江库里它是 ICU 住院标识;eICU-CRD 的 hospitalid 才是医院编号 官方 Table 2
「拿到它就能拿到五个源库」 权限不互通;回源库取数仍需单独申请 官方伦理与访问说明
「它覆盖所有老年 ICU 患者」 排除了 ICU 停留不足 24 小时、缺年龄或结局、以及首日缺六项基线生理参数的住院 官方排除标准
「209 个站点意味着 209 家样本相当的医院」 站点数主要由 eICU-CRD 贡献,另三个源库站点数很少 源库构成与官方站点表述

FAQ

Q1:它到底有多少行?为什么有的地方写 96,668?
PhysioNet v1.0.0 是 93,654 次 ICU 住院。96,668 是 2025 年 7 月发布在 figshare 上的同名早期版本的数字,那一版额外纳入了荷兰的 AmsterdamUMCdb,因而站点是 210 个、国家是四个。AmsterdamUMCdb 在 PhysioNet 版本里被移除,两个数字相差 3,014 次住院。引用前先确认你用的是哪一版。

Q2:93,654 是患者数还是住院数?
是 ICU 住院次数。官方纳入了每位患者的全部住院事件,但为保
证观测独立,每次住院只分析其首个 ICU 入住。所以行数不等于人数,行与行之间可能存在同一患者的不同住院。

Q3:能不能把四个 CSV 合并后统一跑模型?
技术上可以,方法上不建议。四个源库的病例构成、站点结构、记录习惯都不同,合并后随机划分会把跨库异质性摊进训练集与测试集,得到的泛化性能既不能说明模型好,也不能说明模型差。官方设计的用法是跨库分析,正确姿势是留一库交叉验证,逐库单独报告。

Q4:code_status 只有两个源库有,还能用吗?
能用,但要把范围说清楚。抢救意愿在 MIMIC 与 eICU-CRD 里有系统性记录,SICdb 与浙江库没有。研究只能在前两个源库上做,而且必须先用 code_status_eva_flag 筛出真正被评估过的住院。把没记录的当作"默认全力抢救"是错的。

Q5:为什么只有入 ICU 头 24 小时的数据?
这是设计选择而不是技术限制。官方把生理变量的观察窗定为:实验室自入 ICU 前 6 小时至入 ICU 后 24 小时,生命体征取入 ICU 后 24 小时,治疗与用药以"入 ICU 首日是否使用"判定。这样换来的是四库口径一致且计算可复现;代价是做不了任何纵向轨迹分析。

Q6:GNRI 可以直接用吗?需要注意什么?
可以直接用,官方给了完整公式与阈值:GNRI = 14.89 × 白蛋白(g/dL) + 41.7 × min(理想体重/实际体重, 1),理想体重用 Devine 公式按性别与身高估算,小于 92 为高营养风险、不小于 98 为低风险。要注意的是它依赖白蛋白与身高,而身高在部分源库存在官方保留的离群值,是否剔除由你决定并在论文里写明。

Q7:为什么 survival_time_28d 会有 0 和空值?
0 表示患者在入 ICU 当天死亡,成因是源库 MIMIC 的死亡日期只精确到日、而入 ICU 时间精确到秒,两者相减可能落在同一天内。空值是源数据错误导致生存时间无法可靠判定,官方建议按数据瑕疵处理并自行决定剔除标准。做生存分析时要按右删失数据处理,做回归时要先决定这些记录怎么处置。

Q8:拿到它的访问权之后,还需要申请源库吗?
需要。官方明确说明它沿用父库的访问政策、许可与使用要求,权限不互通。如果研究需要本包之外的字段,用保留下来的源库标识回到对应源库取数,但那需要先获得该源库的访问权。

术语表

术语 解释
ICU 住院 一次进入重症监护病房的连续停留,本数据集的行单位
协调(harmonization) 把不同来源的数据按同一套变量名与计算方法重新组织
变量可用性矩阵 说明每个变量在哪些源库里真实存在的文件
宽表 一行一个观测、一列一个变量的扁平表结构
右删失 生存分析中观察窗结束时事件尚未发生,只知生存时间超过某值
GNRI 老年营养风险指数,用白蛋白与理想/实际体重比衡量营养风险
Devine 公式 按身高与性别估算理想体重的经验公式
躯体衰弱 以活动能力(站立、坐起、卧床)衡量的躯体功能状态
code status 抢救意愿,分为全力抢救与部分抢救(不复苏、不插管、舒适护理)
SOFA 序贯器官衰竭评分,六系统各 0—4 分,总分 0—24
OASIS 牛津急性疾病严重程度评分,不依赖实验室值
SAPS II 简化急性生理评分 II,基于头 24 小时生理变量与年龄等
CCI Charlson 合并症指数,按合并症加权计分
GCS 格拉斯哥昏迷评分,3 分为深昏迷,15 分为完全清醒
氧合指数 氧分压与吸入氧浓度之比,本库按通气与未通气分为两个变量
血管活性药 调节血管张力与心输出量的药物,本库记录去甲肾上腺素等四类
留一库交叉验证 每次留出一个源库做测试、其余做训练的多中心验证方式
假名化标识 经替换处理的患者编号,不能用于直接识别个人
Contributor Review PhysioNet 的受控访问层级,需认证并逐项目审批
DUA 数据使用协议,规定数据可做什么、不可做什么
CITI 培训 人体研究伦理与数据使用的标准化在线培训
eICU-CRD 美国远程重症监护协作研究数据库
SICdb 奥地利萨尔茨堡重症监护数据库
ZhejiangProvinceICUdb 中国浙江省一家三级医院的重症监护数据库

附录 A:核心数字核对表

项 值 出处
源库数量 5(MIMIC-III、MIMIC-IV、eICU-CRD、SICdb、ZhejiangProvinceICUdb) 官方摘要与方法段
数据文件数 4 个 CSV + 1 个变量可用性矩阵 官方数据描述段
ICU 住院总数 93,654 官方摘要与数据描述段
MIMIC 贡献 48,708 行 / 78 列 官方 Table 1
eICU-CRD 贡献 37,166 行 / 81 列 官方 Table 1
SICdb 贡献 6,371 行 / 77 列 官方 Table 1
ZhejiangProvinceICU 贡献 1,409 行 / 78 列 官方 Table 1
临床站点数 209 官方数据描述段
国家数 3(美国、奥地利、中国) 官方数据描述段
时间跨度 2001—2022 官方摘要
年龄阈值 ≥ 65 岁 官方方法段
ICU 停留下限 24 小时 官方排除标准
基线生理参数项数 6(心率、呼吸频率、平均动脉压、GCS、体温、血氧饱和度) 官方排除标准
实验室观察窗 入 ICU 前 6 小时至入 ICU 后 24 小时 官方方法段
生命体征项数 8 官方 Table 3
实验室变量数 27 官方 Table 4
血气变量数 7 官方 Table 5
严重程度评分 4(CCI、OASIS、SAPS II、SOFA) 官方方法段
血管活性药种类 4(去甲肾上腺素、肾上腺素、多巴胺、多巴酚丁胺) 官方方法段
GNRI 阈值 < 92 高风险,≥ 98 低风险 官方方法段
SOFA 范围 0—24(六系统各 0—4) 官方方法段
GCS 范围 3—15 官方方法段
生存时间删失点 28 天 官方变量定义
许可 PhysioNet Contributor Review Health Data License 1.5.0 官方 Access 区
DOI(v1.0.0) 10.13026/126e-mx94 官方 Discovery 区
发布日期 2026-10-27 官方项目头

附录 B:数字的来源分层

第一层:PhysioNet 官方项目页 v1.0.0。 住院总数、四个文件的行数与列数、站点数、国家、时间跨度、年龄阈值、排除标准、观察窗口、各类变量的数量与定义、GNRI 公式与阈值、评分范围、许可、DOI、发布日期。本文所有规模、结构、边界数字都出自这一层。

第二层:官方页列出的参考文献。 老年重症的流行病学背景数字(八十岁以上占重症人群 36%、ICU 死亡率 15—25%、住院死亡率 25—45%、一年死亡率可达 70%)来自官方背景段引用的文献条目,本文只作转述,未读原文。

第三层:figshare 早期版本记录。 六库、210 站点、四国、96,668 次住院、CC BY 4.0 这几个数字来自 2025 年 7 月的 figshare 记录,仅用于说明版本差异,不作为本词条主体的口径。

第四层:未核实。 数据包总字节数、各变量在每个源库的实际填充行数、各源库站点的逐个数目、SICdb 与浙江库的时间跨度起止。这些需要下载后在受控环境里统计,本文按要求只写官方页给出的规模、结构与边界数字。

附录 C:完整参考文献

编号 文献 链接 用途
1 ELDER-ICU-DB v1.0.0(PhysioNet) https://physionet.org/content/elder-icu-db/1.0.0/ 全部规模、结构、边界数字
2 Hao S, Rodemund N, Liu X. ELDER-ICU-DB v1.0.0. PhysioNet, 2026. https://doi.org/10.13026/126e-mx94 引用格式与 DOI
3 Liu X, et al. Illness severity assessment of older adults in critical illness using machine learning (ELDER-ICU). Lancet Digit Health 2023;5(10):e657-e67 官方页参考文献 14 学术起点与亚组偏倚评价
4 Johnson AEW, et al. MIMIC-IV. Sci Data 2023 官方页参考文献 7 MIMIC-IV 源库背景
5 Pollard TJ, et al. eICU Collaborative Research Database. Sci Data 2018 官方页参考文献 8 eICU-CRD 源库背景
6 Rodemund N, et al. Harnessing Big Data in Critical Care: SICdb. Sci Data 2024 官方页参考文献 9 SICdb 源库背景
7 Jin S, et al. Establishment of a Chinese critical care database. Sci Data 2023 官方页参考文献 10 浙江重症库背景
8 MIMIC-III Clinical Database v1.4 https://doi.org/10.13026/C2XW26 父库引用
9 eICU Collaborative Research Database v2.0 https://doi.org/10.13026/C2WM1R 父库引用
10 Salzburg Intensive Care database (SICdb) v1.0.8 https://doi.org/10.13026/8m72-6j83 父库引用
11 ZhejiangProvinceICUdb v1.0 https://doi.org/10.13026/901c-yv54 父库引用
12 ELDER-ICU-DB(figshare,2025-07-30,CC BY 4.0) https://doi.org/10.6084/m9.figshare.29673152 版本差异对照
13 Pollard T, et al. PhysioNet as a global platform for biomedical research. Nature Health 2026 https://doi.org/10.1038/s44360-026-00096-z 平台引用规范

附录 D:任务代码

任务一:留一库交叉验证骨架

import pandas as pd
from sklearn.linear_model import LogisticRegression
from sklearn.metrics import roc_auc_score

FILES = {"MIMIC": "MIMIC.csv", "eICU": "eICU-CRD.csv",
         "SICdb": "SICdb.csv", "ZJ": "ZhejiangProvinceICU.csv"}

#-- 只用四个文件共有的数值列做特征,避免把"某库没有"当零值
COLS = ["age", "heart_rate_mean", "mbp_mean", "resp_rate_mean",
        "temperature_mean", "spO2_min", "gcs_min", "sofa", "oasis", "saps"]

frames = {}
for name, path in FILES.items():
    df = pd.read_csv(path, low_memory=False)
    df["source_db"] = name
    frames[name] = df

shared = [c for c in COLS if all(c in f.columns for f in frames.values())]

for test_name in frames:
    train = pd.concat([f for n, f in frames.items() if n != test_name],
                      ignore_index=True)
    test = frames[test_name]

    #-- 简单中位数插补;真实分析请按源库分别插补并写清口径
    med = train[shared].median()
    Xtr = train[shared].fillna(med)
    Xte = test[shared].fillna(med)

    m = LogisticRegression(max_iter=2000).fit(Xtr, train["death_28d"])
    auc = roc_auc_score(test["death_28d"], m.predict_proba(Xte)[:, 1])
    print(f"测试库={test_name:6s} 训练行数={len(train):6d} "
          f"测试行数={len(test):6d} AUC={auc:.3f}")

任务二:用评估标志位筛出可比子集

import pandas as pd

def frailty_subset(path, eva_col="activity_eva_flag"):
    df = pd.read_csv(path, low_memory=False)
    if eva_col not in df.columns:
        return df.iloc[0:0], f"{path}: 无 {eva_col},该源库未系统评估"
    sub = df[df[eva_col] == 1].copy()      #-- 只保留被评估过的住院
    return sub, f"{path}: 评估过 {len(sub)} / 共 {len(df)}"

for path in ["MIMIC.csv", "eICU-CRD.csv", "SICdb.csv",
             "ZhejiangProvinceICU.csv"]:
    sub, msg = frailty_subset(path)
    print(msg)

#-- 同样的思路用于抢救意愿
for path in ["MIMIC.csv", "eICU-CRD.csv"]:
    df = pd.read_csv(path, low_memory=False)
    sub = df[df["code_status_eva_flag"] == 1]
    print(f"{path}: code_status 已评估 {len(sub)} / 共 {len(df)}")

第二段代码的作用不是产出结论,而是先把"被评估过"这个前提立住。只有在这个子集里,activity_stand、activity_sit、activity_bed 与 code_status 的 0 才可以被解释成临床状态,而不是记录行为的副产品。

附录 E:如果只记五件事

序号 记住什么 为什么
1 五个源库、四个 CSV、93,654 次住院、209 站点、三国、2001—2022 这六个数字定义了它的全部用法与限制
2 只纳入 ≥65 岁、只留每次住院的首个 ICU 停留、只看头 24 小时 三条纳排标准决定了它能回答什么
3 变量名统一了,值域与语义没有 可比较不等于可合并
4 *_eva_flag 必须先筛再用 否则"没记录"会被当成"不存在"
5 留一库交叉验证,逐库报告 这是它设计出来要支持的分析范式

编辑说明

本文的核验时间为 2026 年 10 月 28 日,核对方式为直接访问 PhysioNet 项目页(https://physionet.org/content/elder-icu-db/1.0.0/)并逐节提取摘要、背景、方法、数据描述、使用说明、发布说明、伦理、许可与访问政策。规模、结构、边界三类数字全部出自官方页面,未对文件本体做逐列核验——该数据包处于 Contributor Review 受控访问之下,匿名请求文件目录返回 403。

两处需要读者自行判断的地方已明确标出:一是 PhysioNet v1.0.0 与 2025 年 figshare 首版在源库数、站点数、国家数、住院数与许可上的差异,本文一律以 PhysioNet v1.0.0 为准;二是身高与体温的跨库离群值由官方保留未剔除,剔除标准交由使用者决定。

未覆盖的内容包括:数据包总字节数、各变量在每个源库的实际填充行数、各源库站点的逐个数目、SICdb 与浙江库的时间跨度起止。这些需要获批后在受控环境里统计,本文按要求只写官方页给出的数字。


相关数据集导航

以下为站内 AI-Ready 数据集百科中与本数据集共享多个主题标签的相关数据集,按相关度降序排列:

  • sicdb(共享标签:重症医学 / 多中心研究 / 电子病历)
  • zhejiang-ehr-critical-care(共享标签:重症医学 / 电子病历)
  • eicu-crd(共享标签:重症医学 / 多中心研究 / 电子病历)
  • eicu-collaborative-legacy(共享标签:重症医学 / 多中心研究)
  • lacuna(共享标签:重症医学 / 多中心研究 / 电子病历)
  • mimic3-carevue(共享标签:重症医学 / 电子病历)
  • mimic2-iaccd(共享标签:重症医学 / 电子病历)
  • mimicdb(共享标签:重症医学 / 电子病历)
  • mimic-seqex(共享标签:重症医学 / 电子病历)
  • mimic-iv-fhir(共享标签:重症医学 / 电子病历)
  • gossis-1(共享标签:重症医学 / 多中心研究)
  • cinc-2019(共享标签:重症医学 / 风险分层)
  • clif(共享标签:重症医学 / 电子病历)
  • mimic-br(共享标签:重症医学 / 电子病历)
  • chinese-critical-care-database(共享标签:重症医学 / 电子病历)
  • mimic-eicu-fiddle-feature(共享标签:重症医学 / 电子病历)

导航说明:本章节由全站统一标签体系自动计算生成(标签重合度算法),双向可达;点击链接可跳转至对应数据集词条。

返回 AI-Ready 数据集