简介面向重症医学研究者与数据科学家的轻量源码包聚焦eICU、PIC、AmsterdamUMCdb与HiRID四大免费重症数据库系统说明各库的覆盖范围、获取流程、数据特点及适用研究方向。压缩包共3个文件以HTML说明页为核心配合inscode项目配置与gitignore版本管理配置整体仅6KB便于快速浏览与二次整理。目前已有120人学习使用适合临床科研人员、医学信息学学生及数据竞赛选手参考。页面并非泛泛介绍而是逐库拆解eICU涵盖美国208家医院重症数据、发文量可观但申请流程复杂PIC专注儿科重症、获取简便且竞争较小AmsterdamUMCdb数据量庞大但需完成培训课程HiRID时间分辨率高、发文量少但含金量突出。读者可据此快速匹配自身研究条件少走弯路并为后续数据申请与论文选题提供明确方向。 开头要进入状态。重症医学数据库这两年已经成了临床AI和医学信息学研究的“兵家必争之地”但凡你想做脓毒症预测、ICU死亡风险模型、急性肾损伤预警这一类工作手头没有一份高质量的重症数据集基本寸步难行。目前公开可申请、影响力最大的四个重症医学数据库分别是来自美国的MIMIC-IV、eICU-CRD来自欧洲的AmsterdamUMCdb和HiRID。这篇文章不是泛泛介绍这几个库有多牛而是从我个人实际下载、申请、导入、提数和建模的经验出发把四个库的差异、申请流程、表结构、常见坑一次讲透文末附上可直接跑的SQL和建模示例代码适合正在入门重症数据挖掘的临床研究者、数据科学研究生以及想在公开数据集上做医疗AI验证的工程师。1. 四大重症医学数据库全景对比1.1 四个库的身世和定位先快速梳理一下四个库的来源避免很多人一上来就“MIMIC和eICU选哪个”这种问题。MIMIC-IVMedical Information Mart for Intensive Care是目前全球使用最广泛的重症公开数据库由麻省理工学院计算生理学实验室和贝斯以色列女执事医疗中心联合发布。数据覆盖2008至2019年包含超过38万次住院记录、约9万例ICU入住记录。除了常规的人口学、诊断、医嘱、化验还有生命体征、护理记录、影像报告甚至自由文本。MIMIC-IV的另一个优势是配套了非常完善的官方代码库mimic-code从表结构建模到特征提取都有现成脚本。eICU-CRDeICU Collaborative Research Database是飞利浦医疗和MIT合作的多中心数据库采集了2014至2015年间美国200多个ICU的超过20万次住院记录。它的最大价值在于“多中心”——不同医院的设备和临床流程差异会自然引入数据异质性非常适合做模型外部验证。AmsterdamUMCdb来自荷兰阿姆斯特丹大学医学中心是目前欧洲最大的公开重症数据库覆盖2011至2017年约2.3万名患者。它的杀手锏是高频波形数据包括1kHz的ECG和动脉血压波形这在其他三个库里是拿不到的做信号处理方向的人重点关注。HiRIDHigh-Resolution ICU Dataset来自瑞士伯尔尼大学医院覆盖2008至2016年约3.4万例ICU患者。它的特点是没有人工干预的原始记录生命体征的采样精度可以达到分钟级甚至更高加上完整的自由文本笔记做高时间分辨率动态预测非常舒服。1.2 核心差异对比表维度MIMIC-IVeICU-CRDAmsterdamUMCdbHiRID所属国家美国美国荷兰瑞士时间范围2008-20192014-20152011-20172008-2016ICU入住例数约9万超20万住院约2.3万患者约3.4万患者中心数量单中心多中心200单中心单中心数据粒度分钟级记录分钟级记录1kHz高频波形分钟级/秒级申请方式PhysioNetCITI认证PhysioNetCITI认证签署DUA协议签署使用协议特色数据院内外完整轨迹、自由文本多中心异质性高频生命体征波形无干预原始记录1.3 为什么我建议四个库都学很多人只看MIMIC这本身就是一种研究偏见。MIMIC是单中心ICU数据单库训练出来的模型往往在换一个医院之后性能大幅下降这是重症AI论文被拒的高频原因。我的习惯是MIMIC-IV做训练集eICU-CRD做外部验证集AmsterdamUMCdb或HiRID看具体任务再补充。这样的“一训练一验证”结构审稿人看着舒服模型泛化性问题也在早期就暴露了。2. 申请与合规准备这一步卡了很多人2.1 不同数据库的申请路径先讲最关键的合规门槛。MIMIC-IV和eICU-CRD都在PhysioNet平台申请核心流程是先完成CITICollaborative Institutional Training Initiative的“数据或样本研究”课程并通过考试再在PhysioNet注册账号提交包含证书编号和项目用途的申请问卷等待约1到2周审核。AmsterdamUMCdb和HiRID则走数据使用协议DUA路线不需要CITI但需要你签署正式协议承诺数据仅用于学术研究、不尝试识别患者身份、不二次分发。HiRID还要额外提交研究计划和伦理审查证明如果你的单位没有IRB部分学校用课程指导老师签字的声明也可以替代具体要看官方最新要求。2.2 申请被拒的常见原因我帮实验室好几个同学处理过申请问题被拒的高频原因基本是这几类CITI课程只完成了基础模块缺少HIPAA隐私保护相关模块成绩单不完整申请用途填写太模糊只写“想要做机器学习研究”没有说明具体疾病方向、预测目标、验证方法使用QQ邮箱、临时邮箱注册审核系统对这类邮箱的通过率很低PhysioNet账号姓名和CITI证书姓名拼写不一致系统比对不上。注意CITI证书是有效期制的一般超过3年就失效。如果之前考过但已经过期建议重新刷一遍别因为证书过期导致申请被拖一个月。2.3 数据使用的边界问题拿到权限之后要克制。四个库都明确禁止任何形式的患者重识别尝试也禁止把原始数据打包分享给未授权的人。发表论文时必须在方法部分写清楚数据库版本号比如“We used MIMIC-IV v2.2”因为不同版本的表结构差异很大不写版本别人无法复现你的实验。3. 核心数据表结构与提取实操从MIMIC-IV入手3.1 一张图理清MIMIC-IV的表关系MIMIC-IV实际上分成了三个模块hosp住院数据、icuICU内数据、ed急诊数据。最常用的核心表如下表名所属模块作用patientshosp患者基础信息含性别、出生年、死亡时间admissionshosp住院记录含入院时间、转出时间、住院死亡标志icustaysicuICU入住记录含ICU时间、护理单元d_icd_diagnoses / diagnoses_icdhosp诊断编码及对应ICD编码d_itemsicu所有item项的字典表查生命体征编号必用charteventsicu生命体征、护理观察等时序数据量级最大labeventshosp实验室检验结果prescriptionshosp用药医嘱microbiologyeventshosp微生物培养和药敏结果transfershosp病区转科记录可用来计算转出时间初次接触的人最容易犯的错是先去看数据文件而不是先看d_items和官方文档。记住MIMIC-IV所有的生命体征都不是直接按名称存的而是通过itemid关联到chartevents所以第一步永远是查字典表。3.2 SQL示例筛选成年ICU首次住院队列WITH first_stay AS ( SELECT subject_id, hadm_id, stay_id, ROW_NUMBER() OVER (PARTITION BY subject_id ORDER BY intime) AS rn FROM mimiciv_icu.icustays ) SELECT fs.subject_id, fs.hadm_id, fs.stay_id, CASE WHEN p.gender M THEN 1 ELSE 0 END AS gender_male, p.anchor_age, adm.hospital_expire_flag, adm.admission_type FROM first_stay fs LEFT JOIN mimiciv_hosp.patients p ON fs.subject_id p.subject_id LEFT JOIN mimiciv_hosp.admissions adm ON fs.hadm_id adm.hadm_id WHERE fs.rn 1 AND p.anchor_age 18;这段代码的逻辑是先给每个患者的所有ICU入住记录按进入时间排序只保留第一次入住然后关联人口学信息和住院结局。anchor_age是MIMIC-IV中患者的基准年龄大于等于18就能精准排除儿科病例。结果里hospital_expire_flag是住院死亡标志很多死亡率预测模型就是拿它做二分类标签。3.3 提取生命体征的正确姿势提取心率、血压这类时序变量是重灾区。很多人直接SELECT * FROM chartevents WHERE subject_id ...然后卡死半小时。chartevents在MIMIC-IV里是几十亿行级别的表不隔离条件就是灾难。正确做法是先查d_items确定itemidSELECT itemid, label, unitname, category FROM mimiciv_icu.d_items WHERE lower(label) LIKE %heart rate% LIMIT 20;拿到itemid后再按患者和时间窗口提取并且只保留需要的列SELECT ce.subject_id, ce.stay_id, ce.charttime, ce.valuenum FROM mimiciv_icu.chartevents ce WHERE ce.itemid 220045 AND ce.stay_id IN (SELECT stay_id FROM cohort) AND ce.valuenum IS NOT NULL AND ce.charttime BETWEEN 2110-01-01 AND 2110-12-31;一个隐藏细节是chartevents只记录“发生变化”的值不是等间隔采样。临床上护士可能每小时记录一次但中间如果有一次异常血压会额外多一条。所以后续做时序建模前必须做重采样一般取每小时的均值或最后一次观测值。3.4 labevents和prescriptions的关联注意点labevents表的坑在于它不只包含住院期间的数据还混合了门诊数据。只看住院相关检验需要用labevents里的specimen_id关联或者加上时间过滤。prescriptions表在MIMIC-IV中归属hosp模块但它和ICU的时间对齐要小心的点在于医嘱的开始时间可能早于ICU入住时间。做用药特征时一定截取starttime和stoptime与ICU时间窗口的交集别把转入ICU之前的历史用药也算进去。4. 从提数到建模一个可复现的死亡率预测小项目4.1 研究任务和整体流程下面我用一个实际跑通的预测任务来说明整个链路目标是在ICU入住后24小时内利用当时的生命体征、人口学和部分化验数据预测患者是否会在住院期间死亡。整体流程是用SQL构建队列和基础特征在Python中做特征清洗、缺失值处理划分训练集和验证集注意按患者ID分组用LightGBM训练5折交叉验证计算AUC、PR-AUC。4.2 Python特征构造与建模骨架import pandas as pd import numpy as np from sklearn.model_selection import GroupKFold from sklearn.preprocessing import StandardScaler import lightgbm as lgb from sklearn.metrics import roc_auc_score, average_precision_score # df 来自SQL查询结果包含subject_id, stay_id, 特征列, label features [heart_rate_mean, sbp_mean, spo2_min, age, gender_male, creatinine_max, gcs_min] X df[features].copy() y df[label].astype(int) # 缺失值中位数填充 X X.fillna(X.median()) gkf GroupKFold(n_splits5) aucs, prs [], [] for train_idx, val_idx in gkf.split(X, y, groupsdf[subject_id]): X_train, X_val X.iloc[train_idx], X.iloc[val_idx] y_train, y_val y.iloc[train_idx], y.iloc[val_idx] model lgb.LGBMClassifier(n_estimators200, learning_rate0.05, max_depth5) model.fit(X_train, y_train) y_prob model.predict_proba(X_val)[:, 1] aucs.append(roc_auc_score(y_val, y_prob)) prs.append(average_precision_score(y_val, y_prob)) print(fAUC: {np.mean(aucs):.3f} ± {np.std(aucs):.3f}) print(fPR-AUC: {np.mean(prs):.3f} ± {np.std(prs):.3f})注意我用了GroupKFold而不是普通的KFold分组变量是subject_id。这是因为同一个患者可能多次入住ICU如果同一患者既出现在训练集又出现在验证集模型会通过记住个体特征来“作弊”造成虚高的AUC。这是重症建模里最常见的泄漏之一。4.3 时序特征的窗口设计做重症时序预测窗口划分决定了问题定义。ICU入住后24小时内的生命体征窗口可以这样定义以intime为起点取[intime, intime 24h]内的数据。但如果ICU入住时间本身就比真实入院时间晚你还得考虑急诊滞留时间。MIMIC-IV里有admittime和intime的差值这个差值可以作为pre_icu_los_hours特征加进模型实测对死亡率预测有提升。4.4 时间序列模型的前瞻性偏倚如果做更复杂的LSTM或Transformer要小心时间泄漏。比如你不能用患者第36小时的数据去预测第24小时是否死亡。正确的做法是特征窗口固定为前24小时标签为后续住院死亡结局并且在训练集和验证集之间设置时间间隔比如用前80%时间段的患者训练后20%时间段的患者验证模拟真实部署场景。5. 常见问题与排查技巧实录5.1 环境搭建相关这四个库的高效打开方式都是PostgreSQL。MIMIC-IV官方提供了完整的建表脚本建议直接git clone mimic-code仓库按README步骤执行不要自己手写建表语句。官方脚本会顺带建好所有主键、外键和索引省掉大量时间。数据导入慢的问题也很常见。MIMIC-IV源文件解压后几十GB直接copy会很痛苦。我的经验是先去掉原CSV的表头直接COPY ... FROM导入完成再一次性建索引比边导入边建索引快好几倍。报错信息可能原因解决方案relation mimiciv_patients does not existschema搜索路径不对执行SET search_path TO mimiciv_hosp, mimiciv_icu;chartevents查询内存溢出没过滤itemid或患者范围必须带itemid 时间/患者过滤条件labevents数据量巨大且混有门诊没区分住院/门诊样本结合admissions时间窗口过滤患者死亡标签不完整只看patients.dod列改用admissions.hospital_expire_flag模型AUC虚高到0.99同患者数据泄漏到训练验证集用GroupKFold按subject_id分组5.2 关于死亡结局的细节MIMIC-IV中patients表有一个doddate of death字段但很多人用这个字段当死亡率标签时会发现大量缺失。正确的做法是优先用admissions.hospital_expire_flag它明确表示该次住院期间是否死亡。如果想做ICU内死亡得用transfers表或icustays与死亡时间交叉判断不能直接用dod因为dod包含的是所有来源的死亡信息时间上不一定落在本次住院内。5.3 时间字段和时间区间的坑MIMIC-IV的时间字段是医院本地时间不需要额外做时区转换这一点和MIMIC-III一致。但AmsterdamUMCdb和HiRID的部分时间字段是协调世界时需要跟官方文档核对。我第一次用AmsterdamUMCdb时直接把时间拿去和MIMIC对齐看趋势结果差了2小时讨论了很久才发现是时区问题后来统一转成时间戳再比较问题才解决。5.4 多库迁移的隐藏成本不同数据库的字段名称和编码体系差异很大做多中心验证时最花时间的是数据标准化。比如性别字段MIMIC-IV是字符串M/FeICU-CRD是数字编码HiRID又是另一种编码。我的建议是刚拿到数据先写一个统一的标准化映射函数把所有库的性别、生死结局、ICU类型字段统一到同一套编码后面做融合特征才不会乱。5.5 资源占用和查询性能优化chartevents这种超大表在自有服务器上建议按stay_id做表分区或者直接转成列式存储格式处理。我自己的做法是从PostgreSQL导出关键特征到Parquet文件后续读取用DuckDB或Pandas处理速度比直接连原库快一个数量级而且不会把实验室的数据库压垮。最后分享一点个人经验如果你刚开始接触重症数据库我的建议是不要把四个库同时铺开先把MIMIC-IV的表结构和官方示例代码跑通用它的数据完整做一遍死亡率预测或AKI预测再扩展到eICU做外部验证。AmsterdamUMCdb和HiRID可以在你明确需要高频波形数据或超高时间分辨率时再啃前期的学习成本会低很多。等模型在MIMIC上的AUC稳定在0.85以上并且你能清楚解释每个特征的临床含义之后再考虑用其他库做泛化验证。重症数据挖掘这个方向算法不是瓶颈对表结构、临床语义和数据生成过程的理解才是真正拉开差距的地方。本文还有配套的精品资源点击获取
