信息速览
MIMIC-III 覆盖 2001 到 2012 年，MIMIC-IV 覆盖 2008 到 2019 年，两者在 2008 到 2012 这四年里收治的是同一批住院——同一张病床、同一次插管、同一个出院小结，在两个数据库里各存了一份。按理说把它们拼起来是最自然的事：样本翻倍，时间轴拉长到十九年。但真去拼的人会立刻撞上一堵墙：MIMIC-IV 换了日期偏移策略，为每名患者重新生成了 subject_id，MIMIC-III 与 MIMIC-IV 之间不存在任何可用来对齐的公共主键。于是你无法判断某个人是不是被数了两次，而「观测独立」恰恰是绝大多数统计方法写在第一行的前提假设。这不是精度问题，是能不能做的问题。
MIMIC-III Clinical Database CareVue 子集就是为拆这堵墙而生的。它的做法不优雅但极其有效：既然认不出谁是谁，那就把所有可能重叠的人整个删掉。先从 MIMIC-III v1.4 里取出 dbsource 标记为 carevue 的监护室住院，得到 2001—2008 年的患者集合；再把在 MIMIC-IV v2.0 里住过院的人都剔除，这一步移走了 6,636 名个体。剩下的这批人，可以确定性地断言：他们不在 MIMIC-IV 里。代价写在官方页的使用说明中——被移走的更可能是活下来的那一批，留下的人群偏向死亡结局。
一屏速览如下，全部字段均可在官方页面上下文中找到对应表述。
| 维度 | 内容 |
|---|---|
| 全名 | MIMIC-III Clinical Database CareVue subset |
| 发布方 | PhysioNet；由 MIT 计算生理实验室（Laboratory for Computational Physiology）维护 |
| 作者 | Alistair Johnson、Tom Pollard、Roger Mark（均署名 MIT） |
| 首次发布与版本 | 2022 年 9 月 21 日，版本 1.4（唯一版本） |
| 派生来源 | MIMIC-III Clinical Database v1.4（DOI 10.13026/C2XW26） |
| DOI | 10.13026/8a4q-w170（v1.4）；10.13026/yj38-pn40（latest 指向） |
| 许可 | PhysioNet Credentialed Health Data License 1.5.0 |
| 访问条件 | 仅凭证化用户，须完成 CITI「Data or Specimens Only Research」培训并签署 DUA 1.5.0 |
| 患者规模 | 官方页未直接给出；一篇外部文献报告为 23,692 名患者、26,836 次住院（二手值，见附录 A） |
| 剔除规模 | 6,636 名与 MIMIC-IV v2.0 重叠的个体被移走 |
| 时间跨度 | 2001—2008 年（Philips CareVue 系统在位期） |
| 表结构 | 26 张表，与 MIMIC-III 完全一致 |
| 空表 | inputevents_mv、procedureevents_mv 保留但为空 |
| 文件格式 | gzip 压缩的 CSV，解压后遵循 RFC 4180 |
| 主键层级 | subject_id（人）→ hadm_id（住院）→ icustay_id（监护室停留） |
| 标注情况 | 不含新增人工标注，继承 MIMIC-III 的编码与自由文本 |
| 已知偏倚 | 剔除存活者带来的死亡结局偏倚，官方页明确提示 |
| 典型用途 | MIMIC-III 与 MIMIC-IV 的合并分析、跨版本临床实践变迁、CareVue 期重症队列研究 |
§1 它要解决的具体麻烦
1.1 四年重叠与两套接号规则
重症公开数据库有一个很具体的尴尬：新版本不是旧版本的超集，也不是它的不相交延拓，而是与它有一段交集的交叠集。MIMIC-III 的采集期是 2001—2012 年，MIMIC-IV 是 2008—2019 年，交集落在 2008—2012 这四年。这四年里的住院记录，两个库都有。
重叠之所以被设计出来，是为了让 MIMIC-IV 的样本量最大化。但从使用者的角度看，它把一个本来清晰的决策变成了两难：
| 做法 | 后果 |
|---|---|
| 只用 MIMIC-III | 时间轴止于 2012，拿不到 2013 年之后的临床实践 |
| 只用 MIMIC-IV | 时间轴起于 2008，做不了 2008 年之前的长期对照 |
| 两者直接纵向拼接 | 2008—2012 的住院被算两次，样本独立性假设被破坏 |
| 两者直接横向合并 | 无公共主键，无法判定同一个人是否被重复计入 |
前三种做法的代价是信息损失，第四种的代价是结论不可用。真正卡住的是第四种——因为大多数人真正想要的正是「把两个库合起来用」。
把这件事说得更具体一点。假设你要研究某个评分在十年间的预测性能是否稳定，手上只有 MIMIC-III 时时间轴止于 2012，只有 MIMIC-IV 时起于 2008，两条路都做不出十九年的跨度。把两者纵向拼接看似解决了跨度，但 2008—2012 年的每一次住院都会被计两次：这些住院的两个版本来自同一批病人，却因为编号不通而无法去重。样本量凭空变大、置信区间凭空变窄，而变窄的那部分完全没有信息支撑。
第四种做法之所以最危险，恰恰因为它看起来最无损。前三种做法的代价写在明面上——数据量变少，谁都看得见；第四种的代价藏在方差估计里，审稿人不追问就发现不了。这也是为什么需要有人从数据供给端把这条路堵死，而不是靠每个研究者自觉。
1.2 为什么认不出同一个人
日期偏移（date shifting）是去标识化的标准动作：给每名患者的时间轴整体加一个随机偏移，保留间隔、抹掉绝对日期。MIMIC-III 与 MIMIC-IV 在这个动作上的取舍不同，差异直接决定了两者能否对齐。
| 取舍项 | MIMIC-III | MIMIC-IV |
|---|---|---|
| 保留的 | 星期几、大致季节 | 入院年份（带噪声） |
| 抹掉的 | 入院年份 | 星期几、季节 |
| 连带后果 | 无法按年份做趋势研究 | 无法研究星期效应与季节效应 |
| subject_id | 沿用旧编号体系 | 因换偏移策略而重新生成 |
MIMIC-III 当年选保留星期与季节，理由是这让「周末入院是否更危险」「冬季是否更忙」这类问题可以被研究，代价是必须模糊掉年份。发布之后社区的实践表明，保留年份的价值更大——它让人能研究临床实践随时间的迁移，而这正是重症医学里最常被追问的一类问题。于是 MIMIC-IV 改成保留年份、模糊星期与季节。
换偏移就要换号。新号一旦生成，MIMIC-III 的某个人与 MIMIC-IV 的某个人之间就不再有任何可计算的对应关系。官方页对这件事的表述很直接：由于无法识别同一个体，研究者在合并两个库时无法保证观测独立性这一假设成立。
值得强调的是，这个障碍不是工程上的麻烦，而是理论上的不可解。有人会想到用间接特征去匹配——性别加上年龄、入院诊断、住院天数，做成一条准标识符去两侧比对。这条路走不通的原因有两层：一是匹配必然有误配，而误配带来的偏差方向未知；二是这种做法本身正在尝试恢复被去标识化刻意抹掉的信息，与数据使用协议禁止再识别的条款直接冲突。与其在下游做不可靠的推断，不如在上游用确定性规则把重叠删干净。本子集选择的就是后者。
另一层影响常被忽略：不仅人连不上，连时间也对不上。MIMIC-III 侧保留星期与季节，MIMIC-IV 侧保留年份，这意味着即便你不在乎重复计数，也没法把两个库放在同一条日历轴上讨论「某年之后临床实践是否改变」。人连不上是主键问题，时间对不上是语义问题，两者叠加才是合并分析真正的难度。
1.3 三条常见的错误期待
第一条，以为它是「MIMIC-III 的 CareVue 部分」。 不完全是。它有两道过滤：第一道是 dbsource 等于 carevue，把范围收到 2001—2008；第二道是与 MIMIC-IV v2.0 求差集，把在 MIMIC-IV 里住过院的人移走。第二道过滤会移走一部分本属 2001—2008 年的人，因为有人在 2008 年之后又住过院、因而进了 MIMIC-IV。所以「CareVue 子集」不等于「MIMIC-III 里的 CareVue 期全部数据」，它比后者小。
第二条，以为它解决了两个库的时间对齐问题。 它没有。MIMIC-III 侧的日期仍是保留星期与季节、模糊年份的旧偏移；MIMIC-IV 侧是保留年份、模糊星期与季节的新偏移。两个库的时间轴在语义上仍不可直接拼接。它解决的只是「人会不会被数两次」，不解决「两个时间轴怎么对齐」。
第三条，以为它与 MIMIC-IV 拼起来就得到一个 2001—2019 的连续队列。 不能。中间被拿掉的不是某几年，而是「在 2008 年之后还住过院的那批人的全部历史」——包括他们 2008 年之前的住院。留下的这批人，其 2008 年之后的结局根本不在数据里。拼接后得到的是一个在人群构成上有系统性空洞的集合，而不是一条平滑的时间轴。
1.4 它能给到的与给不到的
| 你的需求 | 它给的 | 够不够 |
|---|---|---|
| 与 MIMIC-IV 合并且保证个体不重复 | 确定性不相交，官方页明确保证 | 够，这是它存在的唯一理由 |
| 2001—2008 年 CareVue 期重症队列 | 完整的 26 张表结构 | 够，但人群已偏向死亡结局 |
| 跨 2008 年前后的临床实践变迁 | 提供前段，后段需用 MIMIC-IV | 可做，但两段人群不同、时间轴不对齐 |
| 研究星期效应与季节效应 | 日期偏移保留了星期与季节 | 够，这是 MIMIC-III 体系的固有属性 |
| 研究年份趋势 | MIMIC-III 侧年份被模糊 | 不够，需改用 MIMIC-IV |
| MetaVision 期的输液与操作事件 | inputevents_mv 与 procedureevents_mv 为空表 | 不够，完全没有 |
| 新增的人工标注或金标准 | 无，全部继承自 MIMIC-III | 不够，需自建或改用派生标注集 |
| 无需审批即可下载 | 凭证化访问，需 CITI 与 DUA | 不够，审批通常需一周以上 |
1.5 你的处境与它能帮到的事
| 你的处境 | 它能帮你什么 | 下一步该做什么 |
|---|---|---|
| 你要同时用 MIMIC-III 与 MIMIC-IV，被审稿人质疑重复计数 | 提供一个可证明不相交的前段，差别只在人不在表结构 | 用它替换 MIMIC-III 全库，写作时明确写出「前段来自 CareVue 子集、后段来自 MIMIC-IV」 |
| 你只做 2008 年之前的问题，却嫌 MIMIC-III 太杂 | 单一信息系统来源，不必为同一概念写两套抽取逻辑 | 只用 inputevents_cv，不必处理 mv 表 |
| 你在复现一篇 2016—2020 年间基于 MIMIC-III 的论文 | 表结构逐字一致，旧 SQL 基本可直接迁移 | 先跑通原查询，再核对样本量差异是否来自被剔除的 6,636 人 |
| 你做死亡相关结局建模，担心人群偏倚 | 官方页已明示偏倚方向 | 在方法部分写明偏倚来源，或用 MIMIC-III 全库做敏感性分析 |
| 你要跨库做外部验证 | 与 MIMIC-IV 不相交，可当作真正的独立测试集 | 用它训练、用 MIMIC-IV 测试，或反过来 |
| 你要 2013 年之后的数据 | 完全没有 | 直接用 MIMIC-IV |
1.6 一句话判断与四条边界
它不是一个「更好的 MIMIC-III」，而是一把剪子：剪掉所有可能污染合并分析的人，剪完的那部分才是能安全与 MIMIC-IV 并排放的。
不适合拿来做需要与 MIMIC-IV 对齐时间轴的纵向研究。 两个库的日期偏移策略不同，年份在 MIMIC-III 侧被模糊、星期与季节在 MIMIC-IV 侧被模糊，任何依赖绝对日历位置的变量都拼不起来。
不适合拿来做生存结局的无偏估计。 剔除规则是「在 MIMIC-IV 里住过院的人不要」，而被再次收治的人群本身更可能是存活者，官方页直接指出这导致结果偏向死亡。任何以死亡率为结局的模型，都必须把这一点写进局限性。
不适合拿来研究 MetaVision 系统下的临床流程。 与 MetaVision 绑定的两张事件表被保留但清空，只有表头没有行。
不适合当作「MIMIC-III 精简版」来省事。 它的表结构与 MIMIC-III 逐字相同，体积并未因剔除而变得特别小，复杂程度也一点没降。省下的只是「要不要担心重复计数」这一件事。
1.7 一个反例：什么时候用它反而更糟
假设你要复现一篇 2018 年发表、基于 MIMIC-III 全库的脓毒症早期预测研究。原文的样本量、基线表与主要结局都建立在全库人群之上。此时改用本子集会出现三个麻烦：样本量对不上，旁人无法判断差异来自数据版本还是你的实现；原文可能纳入了 2008—2012 年 MetaVision 期的住院，而这部分在本子集里根本不存在；原文的死亡基线建立在未剔除人群之上，本子集因为剔除了存活者，死亡结局的基线会系统性偏高。
三个麻烦叠加的结果是：你无法用本子集去判断原文结论是否稳健，反而引入了新的解释负担。正确的做法是复现阶段用全库，把本子集留到「需要与 MIMIC-IV 联合分析」的那一步。这个反例说明一件事：本子集的优势是专用的，不是通用的。它在特定研究设计里不可替代，在其余设计里是纯粹的负担。
§2 数据构成与规格
2.1 二十六张表与三级主键
数据库是一套关系表，共 26 张，与 MIMIC-III 完全一致。表之间靠带 ID 后缀的标识符连接，构成三级层次：
| 层级 | 标识符 | 含义 | 典型承载表 |
|---|---|---|---|
| 人 | subject_id |
一名患者 | patients |
| 住院 | hadm_id |
一次入院 | admissions、diagnoses_icd、prescriptions |
| 监护室停留 | icustay_id |
一次 ICU 停留 | icustays、chartevents、outputevents |
派生的过滤动作正是按这三级做的。对每张表，取该表全部行都具备的最具体标识符来筛：patients 用 subject_id；admissions、callout、cptevents、diagnoses_icd、drgcodes、microbiologyevents、prescriptions、procedures_icd、services、transfers 用 hadm_id；chartevents、datetimeevents、icustays、inputevents_cv、inputevents_mv、outputevents、procedureevents_mv 用 icustay_id。
无患者信息的字典表（官方举例 d_items）整表保留，不做过滤。这带来一个值得注意的性质：字典表里会存在本子集根本用不到的项目，因为那些项目只对 MetaVision 期有意义。
labevents 与 noteevents 是例外中的例外。前者只带 subject_id 与 hadm_id，后者在 MIMIC-III 中本身的关联就松散，官方对这两张表改用时间截断：只保留记录时间早于子集中最后一次住院的出院日期的行。
为什么要对这两张表特殊处理？因为它们的数据来源不是床旁系统，而是全院级的检验系统与文档系统。一个人即便只在 2003 年住过一次院，他在此前的门诊检验、此后的影像报告，都仍挂在同一个 subject_id 下。若按 subject_id 过滤，这些住院之外的记录会被整包带进来，而它们既不属于这次住院，也不属于本研究的时间窗口。按时间截断是唯一能守住边界的办法。
这个设计带来一个必须记住的后果：本子集内的 labevents 与 noteevents 不再能用「属于某次住院」的逻辑去理解，只能用「发生在某个日期之前」去理解。写查询时如果习惯性地把它们与 admissions 内连接，会静默丢掉大量没有 hadm_id 的行。
2.2 字段字典（高频列）
下表列出实际写查询时绕不开的列。这不是全量字典，MIMIC-III 官方页给出了逐表的完整定义。
| 列 | 所在表 | 类型 | 含义 | 使用注意 |
|---|---|---|---|---|
subject_id |
patients 等 | 整数 | 患者编号 | 与 MIMIC-IV 的编号不可对齐 |
hadm_id |
admissions 等 | 整数 | 住院编号 | 一人多次住院各有独立编号 |
icustay_id |
icustays 等 | 整数 | ICU 停留编号 | 一次住院可能有多次 ICU 停留 |
dbsource |
icustays | 字符串 | 数据来源系统 | 本子集内取值为 carevue |
itemid |
chartevents 等 | 整数 | 测量概念编号 | 语义须查 d_items |
charttime |
chartevents | 时间戳 | 记录时刻 | 已做日期偏移 |
storetime |
chartevents | 时间戳 | 入库时刻 | 与 charttime 可能相差很远 |
value / valuenum |
chartevents | 字符串 / 浮点 | 测量值原文 / 数值 | 非数值测量只有 value |
valueuom |
chartevents | 字符串 | 单位 | 同 itemid 也可能有多单位 |
error |
chartevents | 整数 | 是否被标记为错误 | 非零通常应剔除 |
icd9_code |
diagnoses_icd、procedures_icd | 字符串 | ICD-9 编码 | 须查 d_icd_diagnoses 取标题 |
drg_code |
drgcodes | 字符串 | DRG 分组码 | 用于费用与分组研究 |
text |
noteevents | 自由文本 | 病历原文 | 已做去标识化，仍受 DUA 约束 |
expire_flag |
patients | 布尔 | 院内死亡标记 | 与死亡偏倚直接相关 |
2.3 一条记录的解剖
以 chartevents 的一行为例。这张表是护理记录的主体，也是 MIMIC 系列数据量最大的表。一行记录回答四个问题：谁（三级 ID）、什么时候（charttime 与 storetime）、测了什么（itemid）、测到多少（value、valuenum、valueuom）。
四个问题里最容易出错的是第二个。charttime 是护士在床旁确认的时刻，storetime 是数据落库的时刻，两者可以相差数小时——补录、批量补记、班次交接都会造成这个差。用 storetime 做时间对齐的研究，等于把补录延迟当成了生理事件延迟。
第三个问题则必须靠 d_items 翻译。chartevents 本身只有编号，d_items 给出编号对应的标签、所属类别与单位。同一生理量在不同时期、不同床旁设备下会有多个 itemid，这是 CareVue 期数据最常被低估的一个坑：只看一个 itemid 拿不到该生理量的全部记录。
2.4 主键映射与拼接顺序
三级主键不是并列关系，而是一条链。写多表查询时，顺序错了会得到行数暴涨的笛卡尔积。
| 拼接顺序 | 结果 | 说明 |
|---|---|---|
| patients ← admissions | 一人对多次住院 | 正确，一人可有多行 |
| admissions ← icustays | 一次住院对多次 ICU 停留 | 正确，转科会产生新 icustay_id |
| icustays ← chartevents | 一次停留对数千条记录 | 正确，这是最细粒度 |
| chartevents ← d_items | 多对一 | 正确，字典表是维度 |
| admissions ← diagnoses_icd | 一次住院对多个诊断 | 正确，诊断有先后序号 |
| patients ← icustays 直接连 | 需经 admissions | 若不经住院层，可能跨住院错配 |
判定拼接是否正确的经验法则：每往下一级，行数应当单调不减，且不该出现「一次住院对应多名患者」这类反向一对多。
2.5 与 MIMIC-IV 的字段差异
| 对比项 | MIMIC-III CareVue 子集 | MIMIC-IV |
|---|---|---|
| 组织方式 | 单一 26 表集合 | 按模块拆分（hosp、icu、ed、cxr、note） |
| 患者编号 | subject_id，旧偏移体系 | subject_id，重新生成 |
| 住院编号 | hadm_id | hadm_id，编号空间不同 |
| 输液事件 | inputevents_cv 有数据，inputevents_mv 为空 | 统一在 icu 模块的 inputevents |
| 操作事件 | procedureevents_mv 为空 | icu 模块的 procedureevents |
| 实验室 | labevents 单表 | hosp 模块的 labevents |
| 文本 | noteevents 单表 | note 模块，含 discharge 与 radiology 子表 |
| 时间语义 | 保留星期与季节，模糊年份 | 保留年份，模糊星期与季节 |
| 采集期 | 2001—2008 | 2008—2019 |
表结构层面的差异意味着：为 MIMIC-III 写的 SQL 不能直接搬到 MIMIC-IV，反之亦然。本子集的价值恰恰在于它在结构上与 MIMIC-III 逐字一致，因而大量既有的 MIMIC-III 代码（尤其是 MIMIC Code Repository 里的派生脚本）可以零改动迁移。
这种一致性带来的实际收益常被低估。重症临床研究里最耗时、最容易出错的往往不是建模，而是概念定义：某项生理量取哪些 itemid、某个合并症用哪组 ICD-9 码、某次住院算不算首次。MIMIC Code Repository 把这些定义沉淀成了可复用的 SQL，而复用它们的前提是表结构与列名不变。本子集在这一点上做到了逐字兼容，因此它不只是一个数据切片，还是一套可复用代码的兼容层。
2.6 列的物理含义：CareVue 期特有的两套概念
CareVue 与 MetaVision 是两家厂商的两套床旁信息系统，字段组织逻辑不同。MIMIC-III 的做法是把能合并的合并、不能合并的加后缀区分，这个设计在本子集里的表现是：
| 概念 | CareVue 侧 | MetaVision 侧 | 在本子集的状态 |
|---|---|---|---|
| 静脉输液与入量 | inputevents_cv | inputevents_mv | cv 有数据，mv 为空 |
| 操作事件 | 无独立表 | procedureevents_mv | 为空 |
| 出量 | outputevents | outputevents | 有数据 |
| 护理记录 | chartevents | chartevents | 有数据 |
| 实验室 | labevents | labevents | 有数据，按时间截断 |
对使用者来说，一个直接推论是：凡是要处理输液速率、血管活性药剂量的研究，在本子集里只能走 inputevents_cv 的列定义，而这套列定义与 inputevents_mv 不同。写通用抽取逻辑时，不能假设两者同构。
2.7 导出链路：从 PostgreSQL 到 CSV.gz
官方页说明，数据文件由 PostgreSQL 以 CSV 参数导出，再用 gzip 压缩；解压后遵循 RFC 4180。这条链路虽然只有两步，但每一步都会在下游留下痕迹。
导出这一步决定了三件事。一是空值以空字符串表示，而不是 NULL 字面量，因此读入时必须显式声明空值符号，否则数值列会被推断成字符串。二是引号与换行的转义遵循 RFC 4180，自由文本字段里出现逗号与引号是常态，用朴素的分隔符切分一定会错。三是列顺序与数据库建表顺序一致，不保证跨版本稳定，按位置取列不如按列名取列稳健。
压缩这一步决定了读取姿势。.csv.gz 是整体压缩而非分块压缩，因此支持流式顺序读，但不支持随机访问——想直接跳到文件中部必须先解压到那里。这解释了为什么 §5.3 推荐分块迭代：分块读一遍流的代价远小于先整体解压再读。
另外值得注意：官方未提供本子集自有的校验和清单页面（写作时因区域限制未能列出文件列表），完整性核对建议以登录后在文件目录下所见为准。
§3 它是谁的数据
3.1 贡献者与维护方
作者三人均署名 MIT：Alistair Johnson、Tom Pollard、Roger Mark。页面底部标注维护方为 MIT 计算生理实验室，资助来自美国国立生物医学影像与生物工程研究所（NIBIB）、国立心肺血液研究所（NHLBI）与 NIH 主任办公室，资助号 U24EB037545 与 R01EB030362。
原始临床数据来自波士顿贝斯以色列女执事医疗中心（Beth Israel Deaconess Medical Center，BIDMC）的重症监护室。项目经 BIDMC 与 MIT 两地的机构审查委员会（IRB）批准，因不影响临床诊疗且全部受保护健康信息已去标识化，免除了个体知情同意。
致谢部分列出 BIDMC 的 Carolyn Conti、Alvin Gayles、Larry Markson、Ayad Shammout、Lu Shen、Manu Tandon，并感谢 NIH 的支持。利益冲突声明为无。
3.2 时间线
| 时间 | 事件 |
|---|---|
| 2001 | Philips CareVue 系统在 BIDMC 重症监护室投入使用，成为床旁数据来源 |
| 2008 | 重症监护室换用 iMDsoft MetaVision 系统，CareVue 期结束 |
| 2012 | MIMIC-III 的采集期结束 |
| 2015 | MIMIC-III 首次发布 |
| 2016 | MIMIC-III v1.4 发布（DOI 10.13026/C2XW26），成为本子集的派生源 |
| 2020 | MIMIC-IV 首次发布，采集期 2008—2019 |
| 2022-09-21 | MIMIC-III Clinical Database CareVue 子集 v1.4 发布 |
3.3 采集场景
数据产生于常规诊疗过程，不是为了研究而额外采集的。床旁监护仪与护理工作站持续输出，护士在班次中确认并录入数值，医生写病程与出院小结，检验科回传结果，计费系统生成 ICD-9、DRG 与 CPT 编码。MIMIC-III 官方页把床旁生命体征的密度描述为大约每小时一个数据点，这个密度是护理记录惯例的产物，而不是设备采样率。
这一点决定了数据的两个性质。第一，它不是等间隔时间序列，两次记录之间可能隔十分钟，也可能隔三小时。第二，记录的有无本身就是临床信息——护士频繁记录的时段往往正是病情不稳定的时段，把「有没有记录」当缺失来处理会丢掉这层含义。
第二个性质值得展开。在重症监护里，测量频率本身就是治疗强度的函数：病情越不稳定，护士被要求记录得越勤；病情平稳后，记录间隔自动拉长。于是「某个时间窗内没有心率记录」既可能是设备故障、也可能是患者已转出、更可能是这个时段患者很平稳。把这三种情况一律当作「数据缺失」并做插补，等于把一个指示病情的信号抹掉，换成一个看起来完整但语义错误的序列。
对 2001—2008 年这一时段还要多考虑一层：床旁设备的数字化程度与今天不同，某些监测项的记录依赖于人工抄录再录入，因此同一 itemid 在不同年份的记录习惯可能不同。做跨年份比较时，记录密度的变化未必反映临床实践的变化，也可能反映录入流程的变化。
3.4 来源层次
| 层次 | 内容 | 影响 |
|---|---|---|
| 床旁信息系统 | Philips CareVue（型号 M2331A、M1215A） | 生命体征、护理记录、输液与出入量 |
| 医院电子病历 | BIDMC 院内系统 | 人口学、实验室、微生物、出院小结与影像报告 |
| 计费系统 | ICD-9、DRG、CPT 编码 | 诊断、操作与费用分组 |
| 社会保障局死亡主文件 | 院外死亡日期 | 长期生存结局 |
四层数据的采集目的各不相同，精度与时序也各不相同。计费编码是事后为报销生成的，其时间粒度通常是住院级而非小时级；实验室结果有明确的采集时刻与回报时刻；床旁数值是护理确认时刻。把它们放在同一条时间轴上比较时，必须区分这些时刻的语义。
第四层尤其值得单独说。院外死亡日期来自社会保障局的死亡主文件，它提供的不是临床事件，而是一条行政记录。这条记录让长期生存结局成为可能，但也带来两个限制：一是它只覆盖能够被匹配到的个体，未匹配到的人不会被标记为存活，而是没有记录；二是它给出的日期是行政登记日期，与临床死亡时刻之间存在不确定的间隔。用它做长期生存分析时，这两个限制都要写进方法部分。
§4 它最独特的东西
4.1 稀缺性：唯一一份「确定性不相交」的 MIMIC-III
MIMIC 家族里有很多派生数据集，绝大多数是加东西——加标注、加波形、加影像、加文本重排。这一份是减东西，而且减的是人。它的稀缺性不在于数据本身，而在于一个可以被证明的性质：子集中的每一个 subject_id，都不在 MIMIC-IV v2.0 里。
| 性质 | 普通 MIMIC-III | 本子集 |
|---|---|---|
| 与 MIMIC-IV 是否相交 | 2008—2012 段相交，但无法判定同一人 | 确定性不相交 |
| 能否与 MIMIC-IV 合并 | 不能保证观测独立 | 可以 |
| 需要自己判断重叠 | 需要，且无法判断 | 不需要 |
| 代价 | 无 | 6,636 人被移走，死亡结局偏倚 |
这个性质看似简单，实际上只有数据持有方才能给出。外部研究者无法自行构造，因为判定「某人是否在 MIMIC-IV 中」需要同时访问两侧的可标识信息，而两侧编号又不通用。换句话说，这是一件只能由发布方做的事，发布方做了。
4.2 差异化证据：三个库放在一处看
| 维度 | MIMIC-III 全库 | CareVue 子集 | MIMIC-IV |
|---|---|---|---|
| 采集期 | 2001—2012 | 2001—2008 | 2008—2019 |
| 患者规模量级 | 官方页表述为四万余名 | 官方页未列；外部文献报告为 23,692 | 官方页按其模块分别给出 |
| 信息系统 | CareVue 与 MetaVision 两套 | 仅 CareVue | MetaVision 及后续 |
| 表结构 | 26 张 | 26 张，逐字一致 | 按模块组织 |
| 与另一个库的关系 | 与 IV 相交且不可判定 | 与 IV 不相交 | 与 III 相交且不可判定 |
| 时间语义 | 保留星期与季节 | 同左 | 保留年份 |
| 空表 | 无 | inputevents_mv、procedureevents_mv | 无 |
4.3 具体案例：三种合并写法
| 写法 | 操作 | 风险 | 适用 |
|---|---|---|---|
| 纵向拼接（union） | 把两个库的住院行堆在一起 | 2008—2012 重复计数，且人群构成不一致 | 不推荐 |
| 分段使用 | 2008 前用本子集、2008 后用 MIMIC-IV | 两段人群不同质，时间轴语义不同 | 做实践变迁研究时的可行写法 |
| 互为外部验证 | 一个训练、一个测试 | 需确认两侧变量定义一致 | 推荐，这是本子集最稳的用法 |
| 全量 MIMIC-III + 敏感性分析 | 用全库跑主结果，用子集跑敏感性 | 工作量翻倍 | 结局为死亡时的推荐写法 |
4.4 标注粒度：没有新标注
本子集不含任何新增的人工标注。它继承 MIMIC-III 的既有编码体系：ICD-9 诊断与操作码、DRG 分组、CPT 编码、实验室项目编号、护理记录项目编号，以及自由文本病历。所有「标签」都是诊疗与计费的副产品，不是为研究而标注的金标准。
这个事实有两个直接后果。第一，讨论它的标注质量时，讨论的其实是 MIMIC-III 的编码质量，本子集未做任何增减。第二，任何需要人工判定的结局（例如某并发症是否发生）都仍需自建标注流程，子集本身不提供帮助。
4.5 边界条件：四条硬边界
时间边界。 只覆盖 2001—2008，且因第二道过滤，实际人群的住院史被截断在最后一次住院的出院日期之前——连 labevents 与 noteevents 也按这个日期做了截断。
系统边界。 只有 CareVue。inputevents_cv 有数据，MetaVision 侧的两张表为空，表头在、行不在。
人群边界。 剔除了 6,636 名与 MIMIC-IV 重叠的个体，这些人被移走的原因正是他们活到了 2008 年之后且再次住院，留下的人群因此偏向死亡结局。
访问边界。 凭证化。需完成 CITI「Data or Specimens Only Research」培训、签署 PhysioNet 凭证化健康数据使用协议 1.5.0，审批通常需要一周以上。
4.6 与派生标注集的分工
MIMIC 生态里有大量标注型数据集，它们从 MIMIC-III 或 MIMIC-IV 中抽取样本，附上人工判定的标签，用来支撑某个具体任务。本子集与它们不在同一层，也不构成竞争。
| 层次 | 做什么 | 是否含人工新标注 | 典型使用者 |
|---|---|---|---|
| 原始数据库 | 提供全部原始记录 | 否 | 所有人 |
| 本子集 | 清掉与 MIMIC-IV 的重叠 | 否 | 跨世代合并分析者 |
| 标注集 | 为具体任务产出金标准 | 是 | 做特定任务的建模者 |
| 基准集 | 定义任务、划分与指标 | 是 | 参加评测的团队 |
分工判据很清晰：如果你的瓶颈是「不知道标签对不对」，本子集帮不上忙，应去找标注集；如果你的瓶颈是「不知道人有没有被数两次」，标注集帮不上忙，应该用本子集。两者可以叠加——在已去重叠的人群上再做人工标注，得到的是既无重复计数又有可靠标签的样本，但这样的工作量需要自行承担。
§5 怎么拿到
5.1 目录结构
页面在 Files 区域按版本号组织，目录层级与 MIMIC-III 一致：每个版本目录下一批 .csv.gz 文件，表名即文件名。字典表与数据表同处一层，不做子目录拆分。
| 文件类别 | 例子 | 说明 |
|---|---|---|
| 患者与就诊定义 | PATIENTS、ADMISSIONS、ICUSTAYS、SERVICES、TRANSFERS | 五张表定义与追踪患者停留 |
| 字典表 | D_CPT、D_ICD_DIAGNOSES、D_ICD_PROCEDURES、D_ITEMS、D_LABITEMS | 五张表用于交叉查询编码含义 |
| 事件表 | CHARTEVENTS、LABEVENTS、MICROBIOLOGYEVENTS、OUTPUTEVENTS | 按事件粒度存放 |
| 输液与操作 | INPUTEVENTS_CV、INPUTEVENTS_MV、PROCEDUREEVENTS_MV | MV 两张为空 |
| 计费与编码 | DIAGNOSES_ICD、PROCEDURES_ICD、CPTEVENTS、DRGCODES | 诊断、操作、计费分组 |
| 文本与呼叫 | NOTEEVENTS、CALLOUT | 自由文本与转科呼叫记录 |
说明：本文写作时，PhysioNet 对当前网络出口返回了「因法律或政策限制，文件列表在你所在区域不可用」，因此上表为按 MIMIC-III 官方页描述的表分类，具体文件清单以登录后在 /files/mimic3-carevue/1.4/ 下所见为准。
5.2 批量下载
#-- 凭证化访问：先登录并接受 DUA，再用用户名密码递归拉取
wget -r -N -c -np --user <你的PhysioNet用户名> --ask-password \
https://physionet.org/files/mimic3-carevue/1.4/
#-- 官方推荐的另一种方式：用 PhysioNet 提供的下载工具按目录同步
#-- 注意 -np 防止爬到父目录，-c 支持断点续传
下载前必须完成三件事：注册并登录 PhysioNet 账号；完成 CITI「Data or Specimens Only Research」培训并在账号中关联；在项目页签署 PhysioNet Credentialed Health Data Use Agreement 1.5.0。三者缺一，文件请求会被拒绝。
5.3 流式读取
数据量不适合整体载入内存，按块读是标准做法。
import pandas as pd
#-- CHARTEVENTS 是本套表里最大的一张，必须分块处理
keep_icustay = set(icustays_sample['icustay_id']) #-- 先备好要保留的停留编号
chunks = []
for part in pd.read_csv('CHARTEVENTS.csv.gz',
chunksize=1_000_000,
low_memory=False,
usecols=['subject_id', 'hadm_id', 'icustay_id',
'itemid', 'charttime', 'valuenum', 'valueuom', 'error']):
#-- 先按停留编号缩范围，再剔除被标记为错误的行
part = part[part['icustay_id'].isin(keep_icustay)]
part = part[(part['error'].isna()) | (part['error'] == 0)]
chunks.append(part)
chartevents = pd.concat(chunks, ignore_index=True)
usecols 在这里不是优化技巧而是必需项：整行读入会让内存峰值翻倍。另一个常见写法是把 icustay_id 与 itemid 读成整数而非浮点——CSV 中有空值会让 pandas 推断成浮点，导致与字典表连接时类型不匹配。
5.4 转表与入库
官方页说明文件由 PostgreSQL 以 CSV 参数导出、再用 gzip 压缩，解压后遵循 RFC 4180。因此最省事的用法是照原样建库：
-- 建表后直接用 COPY 导入，分隔符为逗号、首行为表头
COPY chartevents
FROM '/data/CHARTEVENTS.csv'
WITH (FORMAT csv, HEADER true, NULL '');
-- MetaVision 两张空表也要建，否则旧脚本会因缺表报错
CREATE TABLE inputevents_mv (LIKE inputevents_cv);
CREATE TABLE procedureevents_mv (LIKE procedureevents_cv);
保留空表这一点不是冗余。大量基于 MIMIC-III 的社区脚本会以「全部 26 张表都存在」为前提写联合查询或视图，缺表会直接报错而不是返回空结果。官方明确说这两张表被保留是为了兼容 MIMIC-III 的查询。
5.5 项目编号映射
#-- 同一生理量在 CareVue 期可能对应多个 itemid，必须靠字典表展开
d_items = pd.read_csv('D_ITEMS.csv.gz', low_memory=False)
target = d_items[d_items['label'].str.contains('Heart Rate', case=False, na=False)]
print(target[['itemid', 'label', 'dbsource', 'unitname', 'category']])
#-- 拿到编号集合后再回到事件表取数，不要只用其中一个编号
hr_ids = set(target['itemid'])
映射的注意事项有三条：一是 label 有大小写与缩写变体，按包含匹配比按相等匹配稳；二是同 itemid 可能出现在不同 dbsource 下，dbsource 字段要一起看；三是单位列 unitname 可能为空，换算前要确认。
5.6 五个坑
下面五个坑的共同点是：它们都不会报错。数据能读进来，查询能跑出结果，行数看起来也合理，唯独结论偏了。这类问题在关系型临床数据里比程序错误更难发现，因为没有任何一处会抛异常。
第一个坑：把 storetime 当 charttime。 前者是入库时刻，后者是床旁确认时刻，可差数小时。凡涉及时序与生理动态的研究，一律用 charttime。
第二个坑：只用一个 itemid 取生理量。 CareVue 期同一概念常有多个编号，只用其一会系统性少取记录，而这个少取不是随机的——它通常与设备或病区绑定。
第三个坑：忘记 MV 两张表存在但为空。 写左连接时它们不会报错，只会静默返回空，结果看起来像「本子集没有操作数据」，其实是操作事件在 CareVue 期本来就走另一套表（procedureevents_mv 无对应的 cv 表，操作信息落在计费编码里）。
第四个坑：把字典表当成本子集实际用到的项目集合。 字典表整表保留，含大量仅对 MetaVision 期有意义的记录项。用字典表行数去推测数据覆盖度会高估。
第五个坑：忽略死亡偏倚直接做结局建模。 剔除规则与存活强相关，官方页明确要求研究者注意这一偏倚并在结果解释中加以限定。
§6 与库内其他资源的关系
6.1 关系图谱
| 库内资源 | 与本子集的关系 | 什么时候该用那个 |
|---|---|---|
| MIMIC-III 全库（mimiciii-legacy） | 本子集的派生母集 | 不需要与 MIMIC-IV 合并、或要做 2008—2012 段研究时用全库 |
| MIMIC-IV（mimiciv） | 本子集的补集来源 | 2008 年之后的数据一律用 IV |
| MIMIC-IV on FHIR（mimic-iv-fhir） | 另一条技术路线的 IV 表达 | 需要 FHIR 资源模型与互操作测试时用 |
| MIMIC-III 序列样本库（mimic-seqex） | 同为 MIMIC-III 派生，但做了序列化重排 | 需要直接可喂模型的序列张量时用 |
| MIMIC-III 波形数据库（mimic3wdb） | 同源患者群体的波形侧 | 需要原始生理波形而非护理记录时用 |
| MIMIC-II 导管临床表（mimic2-iaccd） | 更早期的 MIMIC 世代 | 做跨世代方法学对照时用 |
6.2 检索路径
按问题类型走，比按数据库名走更快：
| 你要回答的问题 | 走哪条路 |
|---|---|
| 2008 年前的重症结局，且要与 IV 合并 | 本子集 → MIMIC-IV |
| 2008 年前的重症结局，不关心合并 | MIMIC-III 全库 |
| 2013 年之后的问题 | MIMIC-IV |
| 需要波形而非数值 | MIMIC-III 波形数据库 / MIMIC-IV 波形数据库 |
| 需要互操作标准表达 | MIMIC-IV on FHIR |
| 需要现成的模型输入张量 | MIMIC-III 序列样本库 |
按问题走还有一层好处：它迫使你先回答「我到底要不要跨库」。这个答案决定了本子集是否登场，也决定了后面所有技术细节的走向。若答案是不要，那么本节其余内容都可以跳过，直接用 MIMIC-III 全库。
反过来，若答案是「要跨库，但我还想保留 2008—2012 这一段」，那么目前没有现成的资源能同时满足两条。你只能在「保留该段但接受重复计数风险」与「去掉该段但获得可证明的不相交性」之间选一个，本子集代表了后一种选择的成品形态。
6.3 分工判据
| 判据 | 选本子集 | 不选本子集 |
|---|---|---|
| 是否与 MIMIC-IV 联用 | 是 | 否 |
| 是否在意重复计数 | 是 | 否 |
| 是否需要 2008—2012 段 | 否 | 是 |
| 是否需要 MetaVision 期输液事件 | 否 | 是 |
| 能否接受死亡结局偏倚 | 能，且会写进局限性 | 不能 |
一句话概括：只有当「与 MIMIC-IV 联用」这件事出现在你的研究设计里时，本子集才比全库更合适。其余所有情形下，全库的样本量都更大、人群更完整。
§7 质量评估与局限性
7.0 使用前的三项前置校正
校正一：确认时间列语义。 明确区分采集时刻、记录时刻与入库时刻，在变量字典里写明用了哪一列。
校正二：确认编号语义。 subject_id 与 MIMIC-IV 不通，跨库分析不能按编号做连接，只能在人群层面并列。
校正三：确认人群定义。 写方法部分时，人群入选条件要写完整——不只要写「2001—2008 年 ICU 住院」，还要写「且未出现在 MIMIC-IV v2.0 中」。少写后一句，读者无法理解为何样本量与文献不一致。
7.1 五维评分
| 维度 | 评价 | 依据 |
|---|---|---|
| 结构完整性 | 高 | 26 张表与 MIMIC-III 逐字一致，旧脚本可迁移 |
| 时间覆盖 | 中 | 仅 2001—2008，且被第二道过滤进一步截断 |
| 人群代表性 | 中偏低 | 6,636 人被按「是否再次住院」剔除，构成系统性偏倚 |
| 文档完备度 | 中 | 官方页给出派生方法与偏倚提示，但未提供本子集自有的规模数字与文件清单 |
| 获取便利性 | 低 | 凭证化访问，需 CITI 培训与 DUA，审批一周以上 |
7.2 标注的两层
第一层是结构化编码，来自计费与诊疗流程：ICD-9 诊断与操作、DRG、CPT、实验室与护理项目编号。它们的准确性取决于编码员与临床记录，不是研究级标注。
第二层是自由文本，来自病程、护理记录、出院小结与影像报告。它们经过去标识化处理——按 HIPAA 要求移除十八类标识元素，自由文本部分用基于词典查表与正则模式匹配的系统清洗。文本里仍可能残留罕见表述，DUA 明确禁止尝试再识别。
两层都没有经研究级的一致性检验。这不是缺点，是本子集的性质：它是 MIMIC-III 的一个切片，不做任何质量增强。
7.3 可枚举的偏差
| 偏差 | 机制 | 影响方向 | 能否校正 |
|---|---|---|---|
| 死亡结局偏倚 | 被剔除者更可能是存活并再次住院者 | 高估死亡率一类的结局 | 可用全库做敏感性分析 |
| 时间截断偏差 | labevents 与 noteevents 按最后出院日截断 | 后期记录系统性缺失 | 不能，只能避免用此类分析 |
| 信息系统偏差 | 仅 CareVue 期 | 结论不可外推到 MetaVision 期 | 不能，需在结论中限定 |
| 单中心偏差 | 全部来自 BIDMC | 外推性受限 | 不能，可用 eICU 一类多中心库对照 |
| 记录密度偏差 | 记录有无本身反映病情 | 把无记录当正常会失真 | 部分可，需显式建模记录过程 |
7.4 外部验证的定位
本子集与 MIMIC-IV 不相交，这个性质让它在外部验证里有确定性的位置：用一侧训练、另一侧测试时，可以明确断言测试对象没有出现在训练集中。这一点在多数同类资源里只能靠声明，这里可以靠构造保证。
需要注意的反向问题：不相交不等于同分布。两个库的人群构成、信息系统、时间语义都不同，跨库性能下降里既含真实的泛化差距，也含分布漂移。把它当纯粹的外部验证集时，掉点幅度不能直接解读为模型泛化能力。
7.5 为什么它仍然值得存在
因为它把一个「无法验证的假设」换成了「可证明的事实」。在合并两个重叠数据库时，研究者原本只能声明「我们假设没有重复」，而现在可以用一个官方构造的子集让这句话变成「按构造不存在重复」。研究设计里能被证明的前提越多，结论的争议面就越小。
代价是 6,636 人和一个已知的偏倚方向。这笔交易是否划算，取决于你的结局变量是什么：死亡相关的研究要谨慎，其余研究大多划算。
7.6 把偏倚写进论文的三句话
第一句写在方法的人群部分：「为排除 MIMIC-III 与 MIMIC-IV 之间的个体重叠，本研究采用 MIMIC-III 的 CareVue 子集（v1.4），该子集已移除 MIMIC-IV v2.0 中出现过的 6,636 名个体。」这句话的作用是让读者立刻理解样本量为何小于文献。
第二句写在局限性部分：「由于剔除规则与患者是否再次住院相关，本队列的死亡结局比例高于未剔除人群，效应估计应在此前提下解读。」这句话的作用是 preempt 审稿人关于基线死亡率偏高的质疑。
第三句写在结论的适用范围部分：「本队列仅覆盖单一中心 2001—2008 年间由 CareVue 系统收治的住院，不可外推至 MetaVision 期或其他医疗机构。」这句话的作用是划清边界，避免结论被过度引用。
三句话都不长，但缺任何一句都会让同行对结果产生不同方向的误读。这也是使用本子集时最容易省掉、也最不该省掉的部分。
§8 生态位与历史
8.1 沿革：从两套系统到一个剪子
| 阶段 | 关键事件 | 遗留问题 |
|---|---|---|
| 2001—2008 | CareVue 在位，数据按一套逻辑组织 | 与后续系统字段不同构 |
| 2008 | 换用 MetaVision | 同一概念需两套抽取算法 |
| 2008—2012 | 两个库共同覆盖的四年 | 重叠且不可判定 |
| 2015—2016 | MIMIC-III 发布并定版 v1.4 | 保留星期与季节、模糊年份 |
| 2020 | MIMIC-IV 发布，换偏移换编号 | 与 III 无法对齐 |
| 2022 | 本子集发布 | 人群偏倚与体积缩小 |
MIMIC Code Repository 的出现，把「同一概念要写两套抽取算法」这件事从每个研究者各自的负担变成了社区共建的公共资产。本子集在某种意义上延续了同一思路：把「判断两个库是否重复」这件每个人都要做一遍、且谁都做不彻底的事，由发布方一次性做完。
8.2 与挑战赛的关系
MIMIC 家族长期是 PhysioNet 挑战赛的数据底座。本子集本身不挂挑战赛，也没有配套榜单。它的定位是基础设施而非基准：不提供任务定义、不提供评测指标、不提供划分好的训练测试集。要用它参加或复现挑战赛，需要自己按挑战赛的任务定义重建标签与划分。
8.3 生态位
| 层次 | 谁在这一层 | 本子集的位置 |
|---|---|---|
| 原始数据库 | MIMIC-III、MIMIC-IV | — |
| 去重叠切片 | 本子集 | 唯一一层 |
| 结构化重排 | MIMIC-IV on FHIR、序列样本库 | 下游 |
| 任务化标注 | 各类标注集与基准 | 下游 |
| 波形与影像 | 波形库、胸片库 | 平行 |
它卡在原始库与任务化数据集之间，做的是一件很窄的事：清掉重叠。窄到几乎没有替代品，也窄到适用范围有限。
这个生态位还有一个特点：它的价值随 MIMIC-IV 的存在而存在。若 MIMIC-IV 从未发布，就不会有重叠问题，本子集也就没有存在的理由。它是一个为「上一代与下一代并存」这段过渡期准备的工具。官方对 MIMIC-III 的态度是短期维护以便研究者过渡，因此本子集的生命周期与过渡期的长短绑定——一旦社区整体迁移到 MIMIC-IV，它作为合并工具的必要性就会下降，但它作为 2001—2008 年历史队列的独立价值仍然保留。
从这个角度看，本子集其实有两重身份：一重是过渡期的合并工具，另一重是 CareVue 期的历史档案。前者会随时间贬值，后者不会。在研究设计里区分自己用的是哪一重身份，能避免在过渡期结束之后仍在做不必要的解释。
8.4 谁在用
三类使用者。第一类是同时用两个 MIMIC 世代做时间跨度研究的人，他们需要可证明的不相交性。第二类是复现旧文献的人，他们需要一个与旧代码完全兼容的表结构，同时又能避开重复计数的质疑。第三类是做外部验证的人，他们需要一个与训练集确定不同源的测试人群。
页面记录的累计浏览量为 2,590 次，与全部版本浏览量相同（只有一个版本）。这个量级在凭证化的临床数据库里属于中等，与它极窄的适用范围相符。
§9 使用指引
9.1 三种角色的路径
| 角色 | 最短路径 | 要避开的坑 |
|---|---|---|
| 临床研究者 | 拿到凭证 → 建库导入 26 张表 → 用既有 MIMIC-III 脚本跑人群 → 与 MIMIC-IV 分段分析 | 忘记在方法部分写清人群剔除规则 |
| 数据工程师 | 下载 → 流式读 gz → 按三级主键建索引 → 保留空表 | 把空表删掉导致旧脚本报错 |
| 方法学研究者 | 用它做训练侧、MIMIC-IV 做测试侧 → 报告跨库掉点 | 把分布漂移全归因于泛化差距 |
9.2 最短流程
第一步，完成 CITI 培训并在 PhysioNet 账号关联；第二步，在项目页签署 DUA 1.5.0；第三步，下载 1.4 版本目录下的 .csv.gz 文件；第四步，建 PostgreSQL 库并用 COPY 导入，含两张空表；第五步，用既有的 MIMIC-III 查询脚本验证行数与人群；第六步，在方法部分写明「采用 MIMIC-III 的 CareVue 子集以排除与 MIMIC-IV 的个体重叠」。
9.3 引用方式
官方给出的引用格式为：
Johnson, A., Pollard, T., & Mark, R. (2022). MIMIC-III Clinical Database CareVue subset (version 1.4). PhysioNet. RRID:SCR_007345. https://doi.org/10.13026/8a4q-w170
对应的 BibTeX：
@article{PhysioNet-mimic3-carevue-1.4,
author = {Johnson, Alistair and Pollard, Tom and Mark, Roger},
title = {{MIMIC-III Clinical Database CareVue subset}},
journal = {{PhysioNet}},
year = {2022},
month = sep,
note = {Version 1.4},
doi = {10.13026/8a4q-w170},
url = {https://doi.org/10.13026/8a4q-w170}
}
按 PhysioNet 的要求，还需同时引用平台本身的文献，以及派生来源 MIMIC-III v1.4（DOI 10.13026/C2XW26）。若分析中还用到 MIMIC-IV，须一并引用 MIMIC-IV 的对应文献。
§10 AI 使用声明
| 项目 | 说明 |
|---|---|
| 文本生成 | 全文由 AI 撰写，结构、判断与措辞均为生成结果 |
| 数字来源 | 全部规模、结构与边界数字取自 PhysioNet 官方页面正文与版本页元数据 |
| 文件核验 | 写作时 PhysioNet 对当前网络出口返回区域限制，文件清单未能直接列出，表分类依据 MIMIC-III 官方页描述 |
| 不一致说明 | 官方页未给出本子集的患者数与住院数；正文中的 23,692 / 26,836 来自一篇外部文献，属二手值，未独立核验 |
| 论文信息 | 官方页列有三条参考文献：MIMIC-III v1.4、MIMIC Code Repository、MIMIC-IV v1.0 |
| 未核验内容 | 各表的具体行数、文件大小、校验和、逐列定义、实际人群构成 |
| 图像 | 封面由提示词生成，不来自数据集本体 |
| 免责 | 内容不构成医疗建议；数据使用受 DUA 约束，禁止再识别尝试 |
常见误读（避坑清单）
| 说法 | 实际 | 证据 |
|---|---|---|
| 它等于 MIMIC-III 的 CareVue 期全部数据 | 还额外剔除了与 MIMIC-IV 重叠的 6,636 人 | 官方页 Methods 段描述第二道过滤 |
| 它能让 MIMIC-III 与 MIMIC-IV 的时间轴对齐 | 两侧日期偏移策略不同，年份在 III 侧被模糊 | 官方页 Background 段 |
| 拼上 MIMIC-IV 就得到 2001—2019 连续队列 | 被拿掉的是一批人的全部历史，人群存在系统性空洞 | 由剔除规则推得 |
| 它是 MIMIC-III 的精简版，更好上手 | 26 张表逐字一致，复杂度未降 | 官方页 Data Description 段 |
| 里面有 MetaVision 的输液数据 | inputevents_mv 与 procedureevents_mv 保留但为空 | 官方页 Data Description 段明写 |
| 死亡结局可直接建模 | 剔除规则与存活相关，存在死亡偏倚 | 官方页 Usage Notes 段明确提示 |
| subject_id 可以跨库连接 | MIMIC-IV 重新生成了编号 | 官方页 Background 段 |
| 字典表行数反映本子集覆盖度 | 字典表整表保留，含 MetaVision 期项目 | 官方页 Methods 段说明字典表不过滤 |
| 用 storetime 做时序没问题 | storetime 是入库时刻，与 charttime 可差数小时 | MIMIC-III 表结构定义 |
| 只用一个 itemid 就能取全某生理量 | CareVue 期同一概念常有多个 itemid | 需查 d_items 展开 |
| 无需审批即可下载 | 凭证化访问，须 CITI 培训与 DUA 1.5.0 | 官方页 Access 区 |
FAQ
它和 MIMIC-III 全库到底差在哪？
差两件事：时间和人。时间上，它只留 2001—2008 年 CareVue 系统收治的住院，2008 年之后 MetaVision 期的记录不在其中；人这一层更关键，它把所有在 MIMIC-IV v2.0 里住过院的个体整人剔除，一共移走 6,636 人。表结构层面两者逐字一致，26 张表、三级主键、字典表组织方式都相同。所以你为 MIMIC-III 写的查询基本可以原样迁移，只是返回的行数会少。
为什么非要删掉那 6,636 人？不删行不行？
不删就没法保证观测独立。MIMIC-IV 换了日期偏移策略并重新生成了 subject_id，两个库之间没有任何可用于对齐的公共主键。既然认不出谁是谁，唯一能保证不重复计数的办法就是让两个集合不相交。代价是这 6,636 人恰好更可能是存活到 2008 年之后并再次住院的人，留下的人群因此偏向死亡结局——官方页把这一点写在使用说明里，要求研究者据此限定结论。
做 2008 年之前的研究，用它还是用 MIMIC-III 全库？
如果不涉及与 MIMIC-IV 合并，全库的样本量更大，人群更完整，通常更划算。只有当你的研究设计里出现「与 MIMIC-IV 联用」这一条时，本子集才提供全库给不了的东西：一个可证明的不相交性。此外，若你复现的文献用的是全库，改用本子集会让样本量对不上，需要在论文里解释。
能不能用它来做外部验证？
可以，而且这是它最稳的用法之一。用它训练、用 MIMIC-IV 测试（或反过来），可以明确断言测试对象未出现在训练集中，这一点在多数同类资源里只能靠声明。但要注意不相交不等于同分布：两个库的人群构成、信息系统、时间语义都不同，跨库性能下降里既含真实泛化差距也含分布漂移，掉点幅度不能简单解读为泛化能力。
拿到数据后第一步该做什么？
先建库导入，包括那两张空表。官方页说明文件由 PostgreSQL 以 CSV 参数导出、gzip 压缩，解压后遵循 RFC 4180，因此 COPY 导入最省事。空表必须建——大量社区脚本假定 26 张表齐全，缺表会直接报错。导入后先跑一条既有 MIMIC-III 查询核对行数与人群，确认下载完整。之后按 §7.0 做三项前置校正：确认时间列语义、确认编号语义、确认人群定义。
术语表
| 术语 | 解释 |
|---|---|
| CareVue | Philips 的床旁临床信息系统（型号 M2331A、M1215A），BIDMC 重症监护室 2001—2008 年在用 |
| MetaVision | iMDsoft 的临床信息系统，2008 年起接替 CareVue |
| date shifting | 日期偏移，去标识化手段：给每名患者的时间轴整体加随机偏移，保留间隔、抹掉绝对日期 |
| subject_id | 患者编号，MIMIC-III 与 MIMIC-IV 的编号空间互不通用 |
| hadm_id | 住院编号，一次入院一个号 |
| icustay_id | 监护室停留编号，一次住院可对应多次停留 |
| itemid | 护理与测量项目的编号，语义须查 d_items |
| ICD-9 | 国际疾病分类第九版，诊断与操作的编码体系 |
| DRG | 诊断相关分组，用于住院费用与资源消耗的分组 |
| CPT | 现行操作术语编码，用于计费 |
| RFC 4180 | 逗号分隔值文件的通用格式约定 |
| DUA | 数据使用协议，凭证化数据的法律约束文件 |
| HIPAA | 美国健康保险可携性与责任法案，规定去标识化需移除的十八类标识元素 |
| BIDMC | 贝斯以色列女执事医疗中心，波士顿，原始数据的来源医院 |
| CITI | 人体研究受试者保护的标准化培训课程体系 |
附录 A：核心数字核对表
| 数字 | 出处 |
|---|---|
| 版本 1.4 | 官方页标题与版本区（Published Sept. 21, 2022 · Version 1.4） |
| 发布日期 2022-09-21 | 官方页项目元信息与版本列表 |
| 6,636 名个体被剔除 | 官方页 Methods 段原文 |
| 2001—2008 年 CareVue 期 | 官方页 Background 段 |
| 2008—2012 年两库重叠 | 官方页 Abstract |
| MIMIC-IV 采集期 2008—2019 | 官方页 Background 段 |
| 26 张表 | MIMIC-III v1.4 官方页 Data Description 段；本子集官方页称格式与其一致 |
| 派生自 MIMIC-III v1.4 | 官方页 Parent Projects 区 |
| DOI 10.13026/8a4q-w170 | 官方页 Discovery 区（v1.4） |
| DOI 10.13026/yj38-pn40 | 官方页 Discovery 区（latest） |
| MIMIC-III DOI 10.13026/C2XW26 | 官方页 References 第 1 条 |
| 许可 1.5.0 / DUA 1.5.0 | 官方页 Access 区 |
| 培训要求 CITI Data or Specimens Only Research | 官方页 Access 区 |
| 累计浏览量 2,590 | 官方页 Project Views 区 |
| 资助号 U24EB037545、R01EB030362 | 官方页页脚 |
| 23,692 名患者 / 26,836 次住院 | 外部文献报告值，官方页未列，未独立核验 |
| 作者 3 人 | 官方页作者区 |
| 参考文献 3 条 | 官方页 References 区 |
附录 B：完整参考文献
下表为官方页面 References 区列出的全部文献，另附平台本身的标准引用。
| 序号 | 文献 | 用途 |
|---|---|---|
| 1 | Johnson, A., Pollard, T., & Mark, R. (2016). MIMIC-III Clinical Database (version 1.4). PhysioNet. https://doi.org/10.13026/C2XW26 | 派生母库，讨论表结构与字段定义时引用 |
| 2 | Johnson, A. E., Stone, D. J., Celi, L. A., & Pollard, T. J. (2018). The MIMIC Code Repository: enabling reproducibility in critical care research. Journal of the American Medical Informatics Association, 25(1), 32-39 | 派生脚本与概念定义，复用社区代码时引用 |
| 3 | Johnson, A., Bulgarelli, L., Pollard, T., Horng, S., Celi, L. A., & Mark, R. (2021). MIMIC-IV (version 1.0). PhysioNet. https://doi.org/10.13026/s6n6-xd98 | 合并分析的另一侧，联用时引用 |
| 4 | Pollard, T., Moody, B. E., Lehman, L., Gow, B., Fernandes, C., Xie, C., Johnson, A., Mark, R. G., & Heldt, T. (2026). PhysioNet as a global platform for biomedical research. Nature Health. https://doi.org/10.1038/s44360-026-00096-z | PhysioNet 平台标准引用，官方要求一并给出 |
引用时官方给出的是本子集自身的引用格式（Johnson, A., Pollard, T., & Mark, R.，2022，DOI 10.13026/8a4q-w170，RRID:SCR_007345），格式见 §9.3。若分析中同时用到母库或合并侧，须按上表一并列出。
相关数据集导航
- MIMIC-III 全库：https://www.qianfanghub.com/ai-ready-dataset/mimiciii-legacy/590
- MIMIC-IV：https://www.qianfanghub.com/ai-ready-dataset/mimiciv/592
- MIMIC-III 序列样本库：https://www.qianfanghub.com/ai-ready-dataset/mimic-seqex/1530
- MIMIC-IV on FHIR：https://www.qianfanghub.com/ai-ready-dataset/mimic-iv-fhir/1529
- MIMIC-II 导管临床表：https://www.qianfanghub.com/ai-ready-dataset/mimic2-iaccd/1531
- MIMIC-III 波形数据库：https://www.qianfanghub.com/ai-ready-dataset/mimic3wdb/586
- CliniQ 电子病历实体检索基准：https://www.qianfanghub.com/ai-ready-dataset/cliniq/1151
- MIMIC-III-Ext-PPG：https://www.qianfanghub.com/ai-ready-dataset/mimic-iii-ext-ppg/928
- MIMIC 出院医嘱幻觉标注集：https://www.qianfanghub.com/ai-ready-dataset/ann-pt-summ/1497
- MIMIC-IV-Ext-22MCTS：https://www.qianfanghub.com/ai-ready-dataset/mimic-iv-ext-22mcts/1373
导航说明：以上链接指向站内已发布的相邻资源，按「母集—并列—下游」的顺序排列。需要 2008 年之后的数据请转向 MIMIC-IV；需要现成模型输入请转向序列样本库；需要互操作标准表达请转向 FHIR 版本。
