MIMIC-IV 演示库 — 一百个患者的门钥匙

拿到 MIMIC-IV 之前要先过三道手续：在 CITI Program 上修完人体受试者保护课程并上传证书、在 PhysioNet 上签署数据使用协议、等待审核方批准。这三步通常耗时数天到数周，换版本时还要重新确认协议范围。真正让人为难的却不是手续本身，而是一个更朴素的问题：在决定要不要花这几周之前，你怎么知道 MIMIC-IV 的表名、列名、主键关系与编码体系，确实是你要的那一个？MIMIC-IV Clinical Database Demo 就是为这个问题准备的。它不是 MIMIC-IV 的"精简版"，而是 MIMIC-IV 的一把同构门钥匙：100 名患者的全部结构化住院与重症监护表，表名、列名、主键关系与母库逐字相同，唯一被拿掉的是自由文本病历。它挂在 PhysioNet 上免申请开放，许可为 ODbL 1.0，解压后合计 15.5 MB，一台笔记本十分钟内就能把它装进 SQLite 跑通。

它的价值与它的限制来自同一个源头——100 个人。这个数字小到不可能支撑任何临床结论，却大到足以暴露 MIMIC-IV 的全部工程细节：三级主键怎么串联、字典表怎么接、时间偏移怎么反推、哪些字段会大片留空。想先看清全貌再签字的人，要的就是它；想直接拿它出结果的人，会在第一步就撞墙。一屏速览见下表。

维度	内容
全名	MIMIC-IV Clinical Database Demo
发布方	PhysioNet（MIT 计算生理实验室维护；原始数据来自贝斯以色列女执事医疗中心）
首次发布	2022 年 6 月 22 日，版本 1.0
最近版本	2023 年 1 月 31 日，版本 2.2
患者数	100 名
表结构	31 张 CSV 表：hosp 模块 22 张、icu 模块 9 张（官方摘要另表述为 26 张）
字典表	5 张 d_ 前缀表，随母库完整保留，未按患者过滤
筛选口径	anchor_year_group 取 2011 - 2013 或 2014 - 2016 的前 100 个 subject_id
主键层级	subject_id → hadm_id → stay_id 三级
文件体积	解压后合计 15.5 MB；ZIP 包 15.4 MB
文件格式	gzip 压缩的 CSV，遵循 RFC 4180
缺失部分	自由文本病历（note 模块）与急诊模块未纳入
许可	Open Data Commons Open Database License v1.0（ODbL 1.0），免申请
获取方式	网页下载 / wget 递归 / 静态 ZIP / Google BigQuery
母库	由 MIMIC-IV v1.0 派生；MIMIC-IV 现行版本为 v3.1，需凭据访问
典型用途	教学与工作坊、SQL 与建模管线试跑、申请全量前的适用性评估

§1 它要解决的具体麻烦

1.1 门槛问题：三道手续挡在真正的问题前面

重症监护领域最有名的公开病历库，几乎都把访问权限设成了"先证明你是研究者，再给你数据"。这套机制的合理性无须讨论——它保护的是真实患者。但它带来了一个副作用：研究者在投入时间之前，无法低成本地验证自己的假设是否成立。

具体来说，一个团队想用 MIMIC-IV 做一项研究，需要先判断三件事。第一，MIMIC-IV 的模块化组织方式（hosp 管住院、icu 管重症监护、note 管文本）是否符合自己的取数习惯；第二，它的字段命名与主键设计能否支撑自己想做的表连接；第三，它的编码体系（ICD-9 与 ICD-10 并存、itemid 字典表、药物以处方与给药两条链路记录）会不会让取数工作量超出预算。这三件事在没有数据的情况下只能靠读文档猜，而文档往往写的是"应该怎样"，不是"实际怎样"。

demo 把这三件事的成本压到了一次下载。因为它的表结构与母库逐字相同，你在 demo 上写通的 SQL、建好的特征管线、摸清的字典表映射，拿到全量凭据后几乎不需要重写。官方页对它的定位写得很克制：适合办工作坊，适合在提交访问申请之前评估 MIMIC-IV 是否适用于某项研究。这两句话其实就是它的全部使命。

把这三件事再展开一层，就能看清它的适用边界。想判断表结构是否顺手，需要的是真实的列名与真实的连接关系，这一点 100 人足够。想判断字段命名能否支撑取数，需要的是真实的字典表与真实的编码取值，这一点 100 人也足够，因为字典表本来就是整表保留的。想判断工作量会不会超预算，需要的是真实的脏乱程度——空值长什么样、编码有没有历史残留、时间字段有没有相互矛盾——这一点 100 人同样足够，因为脏乱是系统性产生的，不随样本量变小而消失。唯独判断"某件事在人群里有多常见"，100 人不够，而这件事恰恰是它不打算帮你做的。

1.2 三条常见的错误期待

第一条，把它当成"小一号的 MIMIC-IV"。它是同构子集，不是等比缩小版。全量库里急诊模块与文本模块都是独立模块，demo 两者都没有；全量库里每一张业务表的行数来自几十万患者，demo 里只来自 100 人。等比缩小的假设会让人以为在 demo 上算出来的比例能外推，而这在 100 人的样本上不成立。

第二条，期待它有出院小结。官方摘要明确写"剔除自由文本病历"（excludes free-text clinical notes）。想做临床文本抽取、病历生成、命名实体识别的人，在 demo 里找不到任何一句自然语言病程记录——它只有结构化字段。要做文本任务，必须走 MIMIC-IV-Note 那条独立路径。

第三条，期待它跟着母库一起升级。MIMIC-IV 现行版本已经推进到 v3.1，而 demo 的最新版本停在 v2.2，发布日期是 2023 年 1 月 31 日。demo 的版本节奏跟的是 MIMIC-IV v2.x 那一代，母库后续的住院与重症监护表结构调整、字段增删改，不会同步出现在 demo 里。

1.3 它能给到的与给不到的

你的需求	它给的	够不够
摸清 MIMIC-IV 的表名与列名	31 张表全部列名与母库一致	够，这正是它的设计目的
练习三级主键的多表连接	subject_id / hadm_id / stay_id 齐全	够，且字典表完整
试跑文本到 SQL 的评测	真实表结构 + 真实编码	够，已有共享任务直接采用它
教学演示与工作坊	15.5 MB，一次下载，免申请	够，官方明确推荐此用途
验证 ICD-9 / ICD-10 并存的处理逻辑	icd_version 字段与字典表都在	够写逻辑，不够验分布
做死亡率预测的建模实验	100 人的完整住院与 ICU 记录	不够，样本量不足以支撑结论
做临床文本 NLP	无	不够，无任何自由文本
做急诊流程研究	无	不够，急诊模块未纳入
迁移到 MIMIC-IV v3.1 的字段	止于 v2.2 的字段集	不够，需另核版本差异

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

你的处境	它能帮你什么	下一步该做什么
你正准备申请 MIMIC-IV 全量，纠结要不要花这几周	免申请拿到同构副本，先验证假设	下载后按 §9.2 装成 SQLite，把你打算写的取数 SQL 先跑一遍
你在教一门临床数据科学课，缺一个可分发的数据集	学生不需要考证、不需要签字就能拿到真实表结构	直接发静态 ZIP 链接，让全班用同一份数据
你在做文本到 SQL 的研究	表结构与母库一致，可做真实语义解析评测	关注已有共享任务采用的口径，先对齐它们的问题集定义
你要把数据转成 MEDS 或其他标准格式	体积足够小，可以整库一次性读入迭代	先按官方建议建 SQLite，再逐表导出
你只想看看 MIMIC 长什么样，不做研究	免申请、免注册即可下载	直接下载 ZIP，用任意表格软件打开 CSV
你已有 MIMIC-IV 全量权限	可当轻量沙盒，在改动管线前先在小库上跑	把 demo 作为回归测试集，注意版本停在 2.2

1.5 一句话判断

它不是一个能出结论的库，而是一份能让你提前把工程问题问完的样本——真正稀缺的不是那 100 个人，是它替你省下的那几周试错。

1.6 不适合谁：四条边界

不适合用来产出临床结论。 100 名患者，且被 anchor_year_group 限制在 2011 - 2013 与 2014 - 2016 两个时间段。任何基于它算出的发生率、死亡率、用药比例，都不具备外推意义。它的官方用途定位里没有"发表研究结果"这一项。

不适合做文本任务。 没有自由文本，任何以自然病历为输入的方向都要另找来源。

不适合当 v3.1 的替身。 如果你的目标库是 MIMIC-IV v3.1，用 demo v2.2 验证的字段映射需要逐条复核；版本间的表结构变化不会体现在 demo 里。

不适合做跨中心的泛化验证。 它来自单一医疗中心，与母库同源同构，因此它能验证"你的代码对不对"，不能验证"你的模型换一家医院还行不行"。

§2 数据构成与规格

2.1 目录由两个模块加四个根文件组成

解压后的目录很干净：两个子目录 hosp/ 与 icu/，外加四个根目录文件。hosp/ 装的是住院侧的业务表与字典表，icu/ 装的是重症监护侧的业务表与字典表。这个两分法继承自 MIMIC-IV 的模块化设计——母库把数据来源按业务系统拆开，而不是堆成一张大宽表。

根目录的四个文件各有分工。LICENSE.txt 是 ODbL 1.0 许可全文；README.txt 是简短说明；SHA256SUMS.txt 是全部数据文件的校验和清单，下载之后应当先用它验一遍再开工；demo_subject_id.csv 是本库最特殊的一个文件——它记录了从母库筛出的那 100 个 subject_id，也就是整个过滤操作的原始依据。官方页 Data Description 里单独点出了这个文件。

值得注意的是，demo_subject_id.csv 的存在意味着两件事。第一，过滤逻辑是可审计的：你拿到的是"哪些人被留下了"的清单，而不是一个黑箱抽样结果。第二，它提醒你这是一次顺序截取而非随机抽样意义上的分层设计——筛选规则是先按 subject_id 排序，再取满足 anchor_year_group 条件的前 100 个。

官方页对这条筛选规则的表述有一个容易被忽略的细节：因为 subject_id 本身是随机生成的，按它排序就等于随机排序，所以"取前 100 个"在技术上等价于一次随机截取。但随机截取只保证选取动作无偏，不保证结果代表总体——100 人的样本无论怎么选，抽样误差都远大于你可能想测量的效应。这条区别在统计课上讲得很清楚，在实际取数时却最容易被忘掉。

还有一个实践层面的后果：既然筛选是按 subject_id 顺序做的，那么这 100 人在母库里的分布就不受任何临床条件控制。他们不会因为病情重被选进来，也不会因为是某个科室而被排除——唯一的筛选条件是与影像库的时间重叠。这既是优点（没有额外的选择偏倚）也是限制（无法按临床特征构造队列）。

2.2 表清单与主键字典

下表列出 hosp 模块的全部 22 张表。定位键一列给出该表的记录粒度——它决定了这张表与谁连接、连完之后行数会不会膨胀。

表名	定位键	内容
admissions	subject_id + hadm_id	每次住院一行，含入出院时间、保险、语种、种族
patients	subject_id	每人一行，含性别、anchor 年龄与年份组、死亡日期
diagnoses_icd	subject_id + hadm_id + seq_num	住院的 ICD 诊断编码序列
procedures_icd	subject_id + hadm_id + seq_num	住院的 ICD 操作编码序列
drgcodes	subject_id + hadm_id	住院的 DRG 分组编码
labevents	subject_id + labevent_id	实验室检验事件，每条一个检验项目
microbiologyevents	subject_id + order_id	微生物检验与药敏结果
prescriptions	subject_id + hadm_id + pharmacy_id	住院医嘱的药物处方
pharmacy	subject_id + hadm_id + pharmacy_id	药房配药与计费链路
poe	subject_id + hadm_id + poe_id	电子医嘱录入主记录
poe_detail	subject_id + poe_id + poe_seq	电子医嘱的逐字段明细
emar	subject_id + hadm_id + emar_id	电子给药记录主表
emar_detail	subject_id + emar_id + emar_seq	电子给药记录的逐次执行明细
hcpcsevents	subject_id + hadm_id + hcpcs_seq	HCPCS 计费项目事件
omr	subject_id + omr_seq_num	门诊来源的体征与结果
services	subject_id + hadm_id	住院期间转科的临床服务记录
transfers	subject_id + hadm_id + transfer_id	床位与病区流转事件
d_icd_diagnoses	icd_code + icd_version	ICD 诊断编码字典
d_icd_procedures	icd_code + icd_version	ICD 操作编码字典
d_labitems	itemid	检验项目字典
d_hcpcs	hcpcs_cd	HCPCS 计费代码字典
provider	provider_id	医护人员标识，无患者信息，完整保留

下表列出 icu 模块的全部 9 张表。

表名	定位键	内容
icustays	subject_id + hadm_id + stay_id	每次 ICU 驻留一行，含进出时间与驻留时长
chartevents	subject_id + stay_id + itemid + 时间	床旁体征与观察项，本模块体积最大的表
datetimeevents	subject_id + stay_id + itemid	记录为时间点而非时间段的事件
inputevents	subject_id + stay_id + itemid	液体与药物入量记录
outputevents	subject_id + stay_id + itemid	各类出量记录
ingredientevents	subject_id + stay_id + itemid	输注药物的成分级记录
procedureevents	subject_id + stay_id + itemid	ICU 内的操作事件
d_items	itemid	ICU 观察与事件项目字典
caregiver	caregiver_id	护理人员标识，无患者信息，完整保留

31 张表合计 22 + 9。业务表里凡含患者信息的一律按那 100 个 subject_id 过滤，凡不含患者信息的（d_ 前缀的字典表、provider、caregiver）一律整表保留——官方页 Methods 把这条规则写得很清楚。

2.3 一条记录的完整解剖

以 patients 表为例，这是整个库唯一一张"一人一行"的表，也是所有连接的起点。它的列名与母库逐字相同：

subject_id,gender,anchor_age,anchor_year,anchor_year_group,dod

每一列都有明确语义。subject_id 是随机密码替换后的患者整数标识；gender 是性别；anchor_age 是患者在锚定年份的年龄；anchor_year 是被平移后的去标识年份，落在 2100 - 2200 区间；anchor_year_group 是真实就诊年份的分箱标签，取值包括 2008 - 2010、2011 - 2013、2014 - 2016、2017 - 2019、2020 - 2022；dod 是去标识后的死亡日期，可留空。

MIMIC-IV 官方文档给出的反推规则可以直接套用到 demo 上：若某患者的 anchor_year 为 2158、anchor_year_group 为 2011 - 2013，则该患者在 2158 年发生的住院，实际发生在 2011 至 2013 年之间。另有两条边界必须记住——每位患者只有一个 anchor_year，因此不同患者之间不可做时间上的横向比较；若患者在锚定年份超过 89 岁，anchor_age 一律记为 91，因此 91 不是真实年龄而是"89 岁以上"的分组值。

这套设计的后果在 demo 身上同样成立：100 个人的时间轴各自平移了不同的随机整数，你无法用"两个人都住在 2130 年"推出"他们是同一年入院的"。任何跨患者的时序对齐，都必须先落到 anchor_year_group 这个分箱标签上。

反过来说，同一位患者内部的时间是可信的，而且是精确地可信。官方页写明日期平移是"用一个随机整数一致地平移"，因此对单个患者而言，两次测量之间相隔四小时，在库里算出来还是四小时。这意味着所有只依赖患者内时间差的量——住院时长、ICU 驻留时长、给药间隔、检验复查间隔——在 demo 上与在母库上一样可用。可用的是间隔，不可用的是绝对日期。这条分界线写在一张六列的患者表里，却是整个库最容易被误读的地方。

2.4 三级主键与它们的连接方式

MIMIC-IV 的关系模型是三层向下收窄的树，demo 完整继承了这个结构。

层级	主键	出现在哪些表	一次患者对应几条
患者层	subject_id	全部业务表	一人一条
住院层	hadm_id	admissions 及住院侧业务表	一人可多条
重症驻留层	stay_id	icu 模块业务表	一次住院可多条
事件层	各类事件 id 或 itemid + 时间	chartevents 等事件表	一次驻留可多条

连接路径是固定的：从 icustays 拿到 stay_id 反查 hadm_id，再用 hadm_id 去 admissions 取住院上下文，用 subject_id 去 patients 取人口学信息。反过来从患者往下钻时，join 会被事件表放大——chartevents 是取代价最大的一张表，因为它的粒度是"一次驻留里的一个项目在一个时间点上的一个值"。

放大倍数是可以事先估算的，而估算本身不需要数据。一次 ICU 驻留期间，床旁监护会按固定频率记录若干体征，护理记录会按班次录入若干观察项，两者叠加后单次驻留的 chartevents 行数通常达到千级。若一次住院含多次 ICU 驻留，再放大一档；若一个人有多次住院，又放大一档。三级 join 写反顺序——比如先 join 事件表再 join 住院表——中间结果集会先膨胀到顶点再被过滤，这是 MIMIC 系列最常见的性能事故。

在 demo 上做这件事的体验与在母库上完全一致，只是行数少。这恰恰是它最有价值的地方：你在 15.5 MB 上把 join 顺序、索引、内存峰值调对，拿到全量时这套代码还能用。同理，你在 demo 上把"该先过滤哪些行"想清楚，拿到全量时就不必在几十亿行上重新调试。

2.5 与 MIMIC-III 的字段差异

很多教程是按 MIMIC-III 写的，直接搬到 demo 上会报错。下表列出最常见的几处差异。

事项	MIMIC-III	MIMIC-IV 及本演示库	搬代码时要注意
ICU 驻留主键	icustay_id	stay_id	列名变了，语义不变
患者表主键	也是 subject_id	subject_id	但两者的 subject_id 不是同一套编号
ICD 版本	只有 ICD-9	ICD-9 与 ICD-10 并存	必须带 icd_version 条件
字典表	d_icd_diagnoses 单一	诊断与操作各有 ICD-9/10 两版共存于同一字典	用 icd_version 限定后再 join
模块划分	单库平铺	hosp / icu 分模块	路径不同，表名相同
年龄字段	直接给 age	给 anchor_age 与 anchor_year_group	需按锚定年反推
药物链路	prescriptions 一张表	prescriptions、pharmacy、poe、emar 四条链路	四张表口径不同，别混用
时间平移	平移至 2100 - 2200	同样平移至 2100 - 2200	仍需 anchor 字段还原

其中"四条药物链路"是最容易踩的一坑。prescriptions 记录医生开了什么，pharmacy 记录药房怎么配与怎么计费，poe 与 emar 记录医嘱录入与护士实际给药。四者描述的是同一件事的四个环节，取数前必须先想清楚要的是"医嘱"还是"实际给到的药"。

2.6 字典表为什么必须整表保留

五个 d_ 前缀表是这座库里唯一没有被 100 人过滤的部分，原因很简单：它们不含患者信息，只有编码与名称的映射。

字典表	键	覆盖范围	保留方式
d_icd_diagnoses	icd_code + icd_version	母库诊断编码全集	整表
d_icd_procedures	icd_code + icd_version	母库操作编码全集	整表
d_labitems	itemid	母库检验项目全集	整表
d_hcpcs	hcpcs_cd	母库 HCPCS 代码全集	整表
d_items	itemid	母库 ICU 项目全集	整表

这带来一个必须提前接受的事实：字典表里的绝大多数编码，在 demo 的 100 名患者身上永远不会出现。你在 demo 上写通"按 icd_code 取疾病名称"的 join 逻辑是有效的，但你无法借此判断某个编码在真实人群里常不常见——那需要全量库。字典表保留的是映射关系的完整性，不是使用频次的代表性。

这条事实反过来又给了本库一个不太被提及的用途：它可以当一份完整的编码词典来用。如果你只是想查"某个 ICD-10 码对应的标准描述是什么"“某个 itemid 对应哪个检验项目”，字典表给的答案与母库完全一致，而它不需要任何申请。对写数据字典、写映射表、做编码对齐的人来说，这个用途可能比那 100 个患者本身更实用。当然，前提是你清楚自己在用的是字典表而不是业务表——两者的体量差了几个数量级。

§3 它是谁的数据

3.1 贡献者

署名作者	署名时所属机构
Alistair Johnson	Massachusetts Institute of Technology
Lucas Bulgarelli	Massachusetts Institute of Technology
Tom Pollard	Massachusetts Institute of Technology
Steven Horng	Beth Israel Deaconess Medical Center / Harvard Medical School
Leo Anthony Celi	Massachusetts Institute of Technology
Roger Mark	Massachusetts Institute of Technology

六位署名作者中有四位来自 MIT 计算生理实验室，第五位是贝斯以色列女执事医疗中心的临床医生，第六位是 MIMIC 系列长期的负责人。这个构成说明了它的性质：由工程团队主导、由临床机构供数、由长期维护者把关。

3.2 时间线

时间	事件
2020 年	母库 MIMIC-IV 首次发布，替代 MIMIC-III
2021 年	母库 v1.0 定稿，本演示库即由 MIMIC-IV v1.0 派生
2022 年 6 月 22 日	本演示库 v1.0 发布
2023 年 1 月 31 日	本演示库 v2.2 发布，为现行版本
2023 年	母库 MIMIC-IV 主论文发表于 Scientific Data
2024 年	母库推进至 v3.1，本演示库未跟进

值得单独记一笔：官方页 Parent Projects 一栏写明本演示库派生自 MIMIC-IV v1.0，而当前对外可下载的版本号是 2.2。也就是说，版本号 2.2 指的是与 MIMIC-IV v2.2 那代表结构对齐，而不是说它重新从 v2.2 抽了一遍人。抽人发生在 v1.0 时代，后续升级的是结构。

3.3 采集场景

原始数据的场景是固定的：美国波士顿贝斯以色列女执事医疗中心的急诊科与重症监护病房。母库的纳入范围是 2008 至 2022 年间入住 ICU 或急诊科的患者，本演示库在此之上再收窄到 anchor_year_group 为 2011 - 2013 或 2014 - 2016 的 100 人。

官方页给出的收窄理由很具体：为了保证与 MIMIC-CXR v2.0.0 有重叠。这意味着这 100 人不是随机抽出来的代表性样本，而是为了满足跨库影像-病历配对这一特定目标而截取的一段。如果你的研究依赖时间跨度，这个口径本身就是一条硬约束。

把这条约束摊开看，会看到一个连锁效应。影像可得性不是随机的——拍了胸片的患者，其就诊路径本身就与没拍片的人不同。因此"与影像库重叠"这个筛选条件，实际上是通过影像这条通道间接筛了一遍人群。本演示库继承了这个筛选，也就是说它的人群构成与母库并不完全一致。这一点官方页没有展开，但它是使用本库做人群分析时必须自己记着的。

3.4 来源层次

数据经过三层加工。第一层是原始电子健康记录，来自医院的业务系统。第二层是母库 MIMIC-IV 的抽取与去标识：按 HIPAA 安全港条款移除受保护健康信息，患者标识用随机密码替换成整数，日期用随机整数整体平移，文本字段经人工维护的允许清单与屏蔽清单过滤。第三层是本演示库自己的加工：按 subject_id 过滤业务表，剔除自由文本模块。

官方页 Methods 对第二层的描述里有几个值得单独记住的动作。日期平移被明确说明是为了"移除季节性、星期几与年份信息"——三个信息点被同时抹掉，因此你不只不能做年份比较，也不能做星期效应或季节效应的分析。结构化列则"按数据类型施加了严格规则"，比如含剂量值的列被过滤成只保留数值。文本字段走的是人工维护的允许清单与屏蔽清单，外加针对具体语境的正则表达式；必要时再上去标识算法处理自由文本，而算法的处理结果经过人工复核确认。

三层加工留下的痕迹在 demo 上依然可见。字典表是第二层的产物所以整表保留，业务表是第一层的产物所以要过滤，note 模块是第二层的产物但在第三层被整体拿掉。理解这三层，就能理解为什么有些表现在看着"大而空"——字典表完备得几乎可以用作独立编码词典，而业务表只有 100 人的痕迹。这也是为什么把字典表当成"本库的常用编码清单"来读，会得到完全错误的印象。

§4 它最独特的东西

4.1 稀缺性：唯一免申请的 MIMIC-IV 同构副本

MIMIC 家族里，“免申请就能拿到真实表结构"这件事只有少数几条路径，而本演示库是其中最完整的一条。它与母库的关系不是"类似"而是"逐字相同”——官方页 Data Description 的原话是"演示库与对应版本的 MIMIC-IV 共享完全一致的模式与结构"。

这个性质决定了它的不可替代性。合成数据能给出表结构，但字段间的真实相关性、缺失的杂乱形态、编码的脏乱写法，合成不出来。文档能给出字段定义，但读文档无法替代"自己写一条 SQL 跑通"的确信。本演示库是这两者之间唯一真实的中间态。

"真实"这个词在本库上是有具体所指的，可以拆成四条。其一，脏乱是原样的：编码有历史残留、同一项目在不同时期用了不同 itemid、某些列在不同病区写法不一。其二，缺失是原样的：缺失与"未测"与"零值"在物理形态上混在一起，需要靠上下文区分。其三，冗余是原样的：同一件事在四条链路上各记一遍，四条记录并不总是一致。其四，规模关系是原样的：事件表相对住院表的放大倍数，在 demo 上与在母库上是同一个数量级。这四条里任何一条，都是合成数据造不出来的。

4.2 与同类演示库的差异化证据

对比对象	母库	版本	表结构	免申请	自由文本
本演示库	MIMIC-IV	2.2	hosp 22 + icu 9	是	无
MIMIC-III 演示库	MIMIC-III	未公布	沿用 MIMIC-III 单库平铺	是	视版本而定
eICU 演示库	eICU-CRD	2.0.1	多中心 ICU 表结构	是	无
MIMIC-IV 全量	MIMIC-IV	3.1	含急诊与文本模块	否，需凭据	有

本演示库与 MIMIC-III 演示库最容易被混为一谈，但两者母库不同、结构代际不同、字段命名规则不同（ICU 驻留主键一个是 icustay_id 一个是 stay_id）。把它们当成可互换的入门材料，是新手最常见的时间浪费。

4.3 具体案例：它被哪些外部工作当成了标准沙盒

第一个案例是 EHRSQL-2024 共享任务。该任务的组织方来自 KAIST，在官方说明中直接使用 MIMIC-IV 演示库作为评测数据库，参赛者提交的是 SQL 查询本身，评测指标包含"不可回答问题的弃权能力"。选择它的理由与官方定位高度一致：免 DUA，任何人都能拿到同一份数据跑同一套问题。

第二个案例是 MEDS（Medical Event Data Standard）的转换教程。该教程在讲"如何把一个原始数据源转成 MEDS 格式"时，明确选用 MIMIC-IV Demo v2.2 作为示例的原始数据，理由写得很直白——体量足够小，可以整库一次性读入并快速迭代。

第三个案例是各类教学与工作坊。官方页 Usage Notes 直接建议：CSV 可以用任意文本编辑器或表格软件打开，但因为有些表很大，最好还是放到关系型数据库里操作，推荐 Google BigQuery 或用 CSV 自建 SQLite。这句话本身就是一套教学方案。

4.4 粒度：字段级对齐带来的可迁移性

本演示库的真正粒度优势不在"细"，而在"对齐"。它的每一张表、每一个列名、每一个字典表记录，都与同版本的 MIMIC-IV 逐字相同。因此你在它上面写的东西，迁移成本接近于零：

• 取数 SQL 可以直接搬，改的只有连接目标；
• 特征工程代码可以直接搬，只要特征定义不依赖人群分布；
• 字典表映射可以直接搬，因为字典表本来就是整表保留的；
• 单元测试可以直接搬，demo 还能长期当回归测试集。

反过来，凡是依赖人群分布的东西都不能搬：任何阈值、任何比例、任何需要先看数据再定参数的步骤，都得在全量库上重做。这条分界线是使用本库最重要的判断依据。

把这条分界线再推一层，可以给出一个可操作的自检方法。写下你打算做的每一步，问一句"这一步的答案会不会因为把 100 人换成 40 万人而变"。如果不会——比如"这条 SQL 语法对不对"“这个 join 会不会产生笛卡尔积”“这个编码在字典表里叫这个名字”——那么它可以而且应该先在 demo 上做完。如果会——比如"这个阈值定在哪里"“这个特征重要不重要”“这个模型的 AUC 是多少”——那么在 demo 上得到的答案不仅是错的，而且错得毫无提示：它会给出一个看起来很正常的数字，然后你带着这个数字去申请全量，做完才发现要重来。

4.5 边界条件

边界	取值	后果
患者数	100	无法支撑任何比例类结论
时间分箱	仅 2011 - 2013 与 2014 - 2016 两组	时间外推不成立
模块	仅 hosp 与 icu	无急诊、无文本
版本	与 MIMIC-IV v2.2 对齐	不适用于 v3.1 的字段
中心	单一医疗中心	无跨中心泛化意义
字典表	整表保留	映射可用，频次不可用

§5 怎么拿到

5.1 目录结构

解压后是两层：hosp/ 22 张、icu/ 9 张，根目录 4 个文件。每张业务表都是 .csv.gz，即 gzip 压缩的 CSV。官方页指明这些 CSV 遵循 RFC 4180 标准，也就是说引号包裹、逗号分隔、换行转义都按通例处理，标准解析库都能直接读。

这个目录结构里有两处值得先记住，因为它们决定了后面所有脚本怎么写。第一，业务表与字典表混在同一个目录里，只靠 d_ 前缀区分，所以任何"遍历目录逐表导入"的脚本都会把字典表一起导进去——这通常是你想要的结果，但如果你打算按行数排序来猜哪些表重要，字典表会骗你。第二，hosp 与 icu 两个模块里有重名的字段、却没有重名的表，因此建库时如果选择把两个模块合成一个 schema 而不是两个，表名冲突不会发生，但 itemid 这类键的语义会跨表漂移：hosp 里的 itemid 指向 d_labitems，icu 里的 itemid 指向 d_items，两者不是同一套编号。

5.2 批量下载

官方页给出的终端下载命令如下，注意 -np 是不向上回溯父目录的关键参数：

#-- 递归下载 v2.2 全部文件，加 -np 防止顺手把父目录一起拖下来
wget -r -N -c -np https://physionet.org/files/mimic-iv-demo/2.2/

#-- 下载完成后先按官方清单校验，再解压
cd physionet.org/files/mimic-iv-demo/2.2
sha256sum -c SHA256SUMS.txt

#-- 逐目录解压，保留原始 .gz 以免二次下载时重复传输
find . -name '*.gz' -exec gunzip -k {} \;

不要漏掉校验那一步。SHA256SUMS.txt 是官方随包发布的，一次 sha256sum -c 就能确认 31 张表全部完整，成本几乎为零。

5.3 静态 ZIP

不想递归的话，官方在静态目录发布了一个整包：

#-- 静态目录下的整包，文件名带版本号与数据集全名
wget https://physionet.org/static/published-projects/mimic-iv-demo/mimic-iv-clinical-database-demo-2.2.zip

#-- 解开后逐目录 gunzip
unzip mimic-iv-clinical-database-demo-2.2.zip
find . -name '*.gz' -exec gunzip {} \;

整包方式的优点是只有一次 HTTP 连接，在受限网络里更稳；缺点是拿不到逐文件的校验清单，需要在解压后另行核对。

5.4 云上读取

官方页 Usage Notes 把 Google BigQuery 排在 SQLite 之前推荐，理由是有些表很大，用关系型数据库比用文本编辑器更合适。官方页同时说明：在 BigQuery 上访问数据集的操作指引写在 MIMIC-IV 在线文档的 cloud 页面下。需要注意，BigQuery 通道需要单独申请，与"免申请下载"不是同一件事。

5.5 转成 SQLite

官方页建议用 CSV 自建 SQLite，理由是轻量、单文件、与多种软件互通。

import sqlite3, gzip, csv, pathlib

#-- 指向解压后的根目录
root = pathlib.Path("mimic-iv-clinical-database-demo-2.2")
con = sqlite3.connect("mimic_iv_demo.sqlite")

for mod in ("hosp", "icu"):
    for p in sorted((root / mod).glob("*.csv")):
        table = p.stem
        with p.open(newline="", encoding="utf-8") as f:
            rd = csv.reader(f)
            cols = next(rd)
            #-- 全部暂存为 TEXT，避免 CSV 空串被类型推断搞坏
            ddl = "CREATE TABLE IF NOT EXISTS {} ({})".format(
                table, ",".join('"{}"'.format(c) for c in cols))
            con.execute(ddl)
            con.executemany(
                "INSERT INTO {} VALUES ({})".format(table, ",".join("?" * len(cols))),
                rd)
        print("loaded", mod, table, len(cols))
con.commit()
con.close()

全部存成 TEXT 是刻意的。MIMIC 系列的表里空值与零值、缺失与"未测"混在一起，让 SQLite 自己做类型推断会把空串转成 NULL 或 0，事后分不清。存成 TEXT，用到哪一列再在哪一列上做 CAST，是更安全的选择。

装好之后，先跑一条贯穿三层的查询确认主键连通：

#-- 验证三级主键连通性，这条查询本身不产出任何结论
SELECT p.subject_id,
       p.gender,
       p.anchor_year_group,
       a.hadm_id,
       a.admittime,
       i.stay_id,
       i.intime,
       i.outtime
FROM icustays i
JOIN admissions a ON i.hadm_id = a.hadm_id
JOIN patients  p ON i.subject_id = p.subject_id
LIMIT 20;

这条查询跑通，说明三级主键的引用完整性没问题，可以开始真正的取数。若它直接报"列不存在"，先检查是不是把 icustay_id 写成了 stay_id——那是照 MIMIC-III 教程写的代码最典型的症状。若它返回空行，多半是把 join 方向写反了：icu 模块的表必须靠 stay_id 起手，反查回 hadm_id，不能反过来从 admissions 直接找 stay_id。

5.6 五个坑

坑	现象	处理
忘记 -np	wget 把整个项目父目录都拖下来，多出几百兆无关文件	递归命令必须带 -np
跳过校验	网络中断导致某个 .gz 截断，解压后 CSV 最后一行残缺	解压前先跑 sha256sum -c
类型推断	SQLite 或 pandas 把空串当 0，把编码当整数丢前导零	先全 TEXT 导入，按需 CAST；ICD 码按字符串读
版本错配	按 MIMIC-III 教程写的 icustay_id 报"列不存在"	换成 stay_id，并注意 ICD 需带 icd_version
指望文本	想找 discharge summary，翻遍目录没有 note 文件夹	文本任务另走 MIMIC-IV-Note 路径

§6 与库内其他数据集的关系

6.1 关系图谱

相关词条	与本库的关系	分工
MIMIC-IV	母库，本库由其 v1.0 派生	全量需凭据；本库免申请验证结构
MIMIC-III	上一代母库	字段命名代际不同，教程不可直接互搬
MIMIC-III 演示库	另一条演示路径	对应 MIMIC-III 结构，与本库不互换
MIMIC-IV on FHIR	同一母库的另一种表达	本库为 CSV 关系表，那份为 FHIR 资源
MIMIC-IV 波形库	同院波形数据源	本库只有结构化表格，无波形
MIMIC-IV-Ext-22MCTS	母库之上的派生事件序列	本库用于上手，那份用于建模
MIMIC-IV-ECHO	母库之上的心超子集	本库无影像
MIMIC-III CareVue 子集	母库的历史采集系统切片	本库对应 MetaVision 时代结构
MIMIC-III 序列样本库	母库之上的序列化样本	本库提供原始表，那份提供样本
MIMIC-IV-Ext-BHC	母库之上的文本标注集	本库无文本，那份有

6.2 检索路径

想在本站里找配套材料，路径取决于你要什么。要表结构与取数练习，本词条就是终点。要真实规模，跳到 MIMIC-IV。要影像，去 MIMIC-IV-ECHO。要波形，去 MIMIC-IV 波形库。要文本标注，去 MIMIC-IV-Ext-BHC 或 MIMIC-III 相关标注集。要现成的建模输入，看 MIMIC-IV-Ext-22MCTS 或 MIMIC-III 序列样本库。

还有一条反向路径很少被提到：从别的词条回到本词条。当你读到某个基于 MIMIC-IV 的派生数据集、却不确定它的上游表结构长什么样时，本词条可以当作那张结构底图。因为本库与母库 v2.2 同构，绝大多数派生数据文档里提到的表名，都能在本库里找到对应物并直接打开看一眼。这个用途不需要下载、不需要申请，只需要一份表清单。

6.3 分工判据

判断该用本库还是母库，只看一条：你的目的需不需要人群规模。需要——比如要算发生率、要训练模型、要外推结论——必须用母库；不需要——比如要验证代码、要教课、要试跑管线——本库更合适，因为它免申请、体积小、上手快。

再往下分一层：如果你的目标是"验证代码"，本库是最优解；如果你的目标是"验证假设"，本库只能帮到一半，因为很多假设本身就是关于人群分布的，那部分必须回到母库。

§7 质量评估与局限性

7.0 前置校正

评价本库之前必须先做一次校正：它不是研究数据集，是工程样本。用研究数据集的标准（样本量、代表性、标注质量）去评价它，会得出"处处不行"的结论，而这个结论没有意义。反过来，用工程样本的标准（结构保真度、获取成本、可迁移性）去评价它，它几乎处处优秀。

7.1 五维评分

维度	评分	说明
结构保真度	高	与母库逐字同构，列名主键全对齐
获取成本	高	免申请、免注册，15.5 MB，含校验清单
可迁移性	高	SQL 与特征代码可直接搬到全量
规模支撑力	低	100 人，不足以支撑结论
版本时效性	低	停在 v2.2，母库已至 v3.1

五项里三项高、两项低，且低的那两项恰恰是它不打算解决的部分。这个评分分布本身就是它的定位证明。

值得把这个评分的用法说清楚。它不该被读成"三分优点两分缺点"，而应被读成两组不同的评价对象：前三项评价的是"它作为结构样本是否合格"，后两项评价的是"它作为数据来源是否够用"。一个人对它的满意度，几乎完全取决于他心里问的是哪一个问题。带着"我想看清 MIMIC-IV 长什么样"来的人会给它高分，带着"我想用它算出一个能发表的数"来的人会给它低分，而这两种评价说的其实不是同一件事。

7.2 去标识的两层

第一层是母库的去标识：按 HIPAA 安全港条款移除受保护健康信息，患者标识用随机密码替换成整数，日期整体平移随机整数以抹掉季节、星期与年份信息，文本字段经人工维护的允许清单与屏蔽清单过滤，必要时再上去标识算法处理自由文本。官方页 Methods 说明本演示库沿用与母库相同的去标识方法。

第二层是本演示库自己的收窄：剔除自由文本模块，把攻击面再缩小一圈。两层叠加的结果是，本库的三类标识（患者、住院、ICU 驻留）都是无意义的随机整数，时间轴各自平移且互不对此，文本通道整体缺失。

7.3 可枚举的偏差

偏差来源	具体形态	影响
时间分箱偏差	只含 2011 - 2013 与 2014 - 2016	不能谈时间趋势
截取偏差	按 subject_id 顺序取前 100	不是分层抽样，无统计代表性
跨库对齐偏差	筛选理由是与 MIMIC-CXR v2.0.0 重叠	人群被影像可得性间接筛选过
单中心偏差	全部来自同一家医疗中心	换中心需重新验证
版本偏差	结构停在 v2.2	与 v3.1 存在字段差异

这五条都是可以在取数之前就列出来的，不需要看数据。这也是它作为教学素材的一个优点：偏差来源清晰、可枚举、可讲清楚，初学者能一次性把"数据集偏差"这件事学明白。

它们之间还有一条共同的性质值得指出：五条偏差全部写在取数动作之前，而不是藏在结果之后。时间分箱偏差来自筛选规则，你读一遍 Methods 就知道；截取偏差来自按主键顺序取前一百，你读一遍 Methods 也知道；跨库对齐偏差来自筛选动机，同样写在 Methods 里；单中心偏差与版本偏差则写在来源与版本号里。也就是说，本库的偏差是显式的、文档化的、可预防的，这与那些偏差只能通过事后检查才发现的数据集形成鲜明对比。用它做教学，讲偏差这件事会讲得特别干净。

7.4 外部验证

本库自身没有独立论文，这是核实过的结论——PhysioNet 官方页给出的引用对象是版本号 DOI（10.13026/dp1f-ex47），而不是某篇描述该演示库的文章。母库 MIMIC-IV 的主论文则是 Scientific Data 2023 年那篇（Johnson AEW 等，Scientific Data 10, 1），官方页 References 中列出。

外部验证因此体现在使用侧而非论文侧：EHRSQL-2024 共享任务把它当评测库、MEDS 教程把它当转换示例、各类教学材料把它当入门数据。这些使用本身证明了它在"结构教学"这一用途上的有效性。

7.5 为何它至今仍在

母库已经到 v3.1，本库停在 v2.2，但它没有被取代，原因有三。其一，门槛优势不依赖版本——哪怕结构旧一代，它依然是唯一免申请拿到 MIMIC-IV 表结构的途径。其二，教学用途对版本不敏感——教三级主键怎么连、字典表怎么接，v2.2 与 v3.1 讲法一样。其三，生态已经形成——已有共享任务与教程围绕它建好了材料，换了版本反而是负担。

§8 生态位与历史

8.1 沿革

阶段	时间	状态
母库立项	2020 年前后	MIMIC-IV 替代 MIMIC-III，改为模块化组织
本库 v1.0	2022 年 6 月 22 日	由 MIMIC-IV v1.0 派生，首次发布
本库 v2.2	2023 年 1 月 31 日	与 MIMIC-IV v2.2 结构对齐，现行版本
母库 v3.1	2024 年	母库继续推进，本库未跟进

MIMIC 系列的组织方式在第四代发生了一次关键转向：从单库平铺改为模块化，把住院、重症监护、文本、急诊各自独立成模块，并明确数据出处。本演示库继承的正是这个模块化结果——所以它只有 hosp 与 icu 两个模块，而不是一张大表。

这次转向对使用者有两个直接后果。好的一面是出处清晰：一张表属于哪个业务系统，看它在哪个模块就知道，混用不同来源的数据之前会自然停顿一下。坏的一面是路径变长：同样一句"取这个人的体温"，在 MIMIC-III 里可能只需一张表，在 MIMIC-IV 里要先判断体温记在 icu 的 chartevents 还是 hosp 的 omr，再决定 join 路径。本演示库把这件事保留了原样，因此在它上面练熟这套路径判断，比在任何简化材料上练都更接近实况。

8.2 与挑战赛

本库与挑战赛的关系是"被采用"而非"为赛事而生"。EHRSQL-2024 的组织方在任务说明中直接把 MIMIC-IV 演示库作为评测数据库使用，参赛系统提交 SQL 查询，评测同时考察可执行正确率与对不可回答问题的弃权能力。这类任务选择它，看中的是两点：表结构真实且公开可得，任何参赛者都能拿到完全相同的数据库。

8.3 生态位

位置	代表	定位
免申请入门	本演示库	结构教学、管线试跑
凭据全量	MIMIC-IV	真实研究
派生产品	MIMIC-IV-Ext 系列	面向具体任务的加工品
其他表达	MIMIC-IV on FHIR	互操作格式
上一代入门	MIMIC-III 演示库	对应旧结构

本演示库占据的是"入口"这个位置：它上面不产出结论，它决定你后面要不要投入几周。一个健康的生态需要有这么一个低成本的入口，否则所有新来者都要在不确定中先赌一次。

这个位置还有一个容易被低估的作用：它把"入门"与"入门之后"分成了两个可分别优化的问题。入门阶段要的是低成本、低门槛、低风险，本库三项全中。入门之后要的是规模、时效、代表性，那三项恰恰是母库的事。分层带来的结果是，母库不必为了照顾新手而降低门槛，本库也不必为了照顾研究而扩充规模——两者各自把自己那一层做好，中间靠"同构"这根管子连接。理解了这个结构，就不会再问"它为什么不做成 1000 人"这类问题：做成 1000 人只会让它两头都不占。

8.4 谁在用

第一类是需要先验证再投入的研究团队。第二类是需要可分发素材的教师——学生不用考证、不用签字，全班拿到同一份数据。第三类是做文本到 SQL 的 NLP 研究者，需要真实的数据库 schema 做语义解析。第四类是做数据标准转换的人，需要一个小到可以反复迭代的真实数据源。第五类是老手，把 15.5 MB 的它当成回归测试集，改管线前先在小库上跑一遍。

这五类用户有一个共同点：他们都不指望从这 100 人身上得出结论。这个共同点比他们各自的用途更能说明本库的性质——它是一个被用来"验证"的数据集，不是被用来"发现"的数据集。验证型用途关心的是确定性与可重复性，本库恰恰在这两点上表现极好：任何人下载到的文件完全一致，有官方校验和可以比对，表结构与母库逐字相同，因此别人在他的机器上跑通的东西，你在你的机器上也能跑通。发现型用途关心的则是新颖性与代表性，那是母库的领域。

§9 使用指引

9.1 三种角色的路径

角色	该拿它做什么	别拿它做什么
想申请全量的研究者	下载装库，把计划中的取数 SQL 先跑通	别用它估算效应量
教师	直接分发静态 ZIP，让全班环境一致	别让学生用它做统计分析作业
文本到 SQL 研究者	对齐已有共享任务的问题集口径	别假设问题集可跨版本复用
数据工程师	当回归测试集与转换演练对象	别把它当 v3.1 的结构基准
初学者	从三级主键与字典表开始练 join	别照抄 MIMIC-III 教程的列名

9.2 最短流程

第一步，下载。网页点 ZIP，或 wget -r -N -c -np 递归，或直接取静态包。第二步，校验。sha256sum -c SHA256SUMS.txt。第三步，解压。逐目录 gunzip。第四步，装库。按 §5.5 建 SQLite，或上传 BigQuery。第五步，跑一条跨三层的 SQL 验证主键连通——从 icustays 取 stay_id 反查 hadm_id 与 subject_id，再取人口学信息。第六步，把这套 SQL 原样留着，拿到全量凭据后直接复用。

这六步里真正值得花时间的只有第四步与第五步。第四步决定你后面所有的查询好不好写：装成 SQLite 之后，本地查询没有网络往返，改一句 SQL 重跑一次几乎是瞬时的，这种反馈速度是做结构探索的必要条件。第五步则是唯一一次"验证"动作——它验证的不是数据对不对，而是你对主键关系的理解对不对。这一步通了，后面无论写多复杂的取数逻辑，出错都只会是业务理解上的错，不会再是结构理解上的错。

9.3 引用方式

官方页给出的 BibTeX 如下，引用时要连 PhysioNet 自身的标准引用一起给：

@article{PhysioNet-mimic-iv-demo-2.2,
  author = {Johnson, Alistair and Bulgarelli, Lucas and Pollard, Tom and Horng, Steven and Celi, Leo Anthony and Mark, Roger},
  title  = {{MIMIC-IV Clinical Database Demo}},
  journal = {{PhysioNet}},
  year   = {2023},
  month  = jan,
  note   = {Version 2.2},
  doi    = {10.13026/dp1f-ex47},
  url    = {https://doi.org/10.13026/dp1f-ex47}
}

如果引用的是母库本身而非演示库，另应引 MIMIC-IV 主论文（Scientific Data 10, 1, 2023）。官方页同时要求附 PhysioNet 平台的标准引用（Nature Health, 2026，doi:10.1038/s44360-026-00096-z）。本演示库没有独立论文，因此不应为它编造一个文献出处。

§10 AI 使用声明

项目	说明
文本生成	全文由 AI 依据 PhysioNet 官方页面与官方文件清单撰写，未使用任何未经核实的二手描述
数字来源	患者数、表数、文件大小、发布日期、许可、DOI 均取自 PhysioNet 官方页对应栏目
文件核验	表清单依据 v2.2 版官方目录树与校验和清单，未逐个下载解压核验内容
不一致说明	官方摘要表述"MIMIC-IV 由 26 张表构成"，而 v2.2 文件清单实为 31 张（hosp 22 + icu 9）；本文两者并存，未擅自取其一
论文信息	母库论文为 Scientific Data 10, 1 (2023)；本演示库本身无独立论文，仅有版本 DOI
未核验内容	各表的具体行数、住院次数、ICU 驻留次数、字段个数、逐表体积，均未在官方页公布，本文不予给出
图像	封面提示词为文本描述，未生成图片
免责	本文为数据集说明，不构成诊疗建议；数据使用须遵守 ODbL 1.0 与 PhysioNet 使用条款

常见误读（避坑清单）

说法	实际	证据
它就是"小一号的 MIMIC-IV"	是同构子集，但剔除了文本与急诊模块	官方页 Data Description 明示剔除自由文本
用它能发临床结论	100 人且不具统计代表性	官方页 Abstract 定位为工作坊与适用性评估
免申请等于没有任何使用条件	ODbL 1.0 有署名与相同方式共享要求	官方页 Access 栏许可为 ODbL 1.0
它跟母库同步升级	停在 v2.2，母库已至 v3.1	官方页 Versions 与母库版本页
它有 26 张表	官方摘要写 26，v2.2 文件清单为 31 张	官方页 Data Description 与 v2.2 目录树
里面有出院小结可以练 NLP	无任何自由文本	官方页 Abstract 明示剔除
字典表也被切成 100 人	d_ 前缀表无患者信息，整表保留	官方页 Methods
它和 MIMIC-III 演示库是一回事	母库不同、结构代际不同、主键命名不同	两库官方页结构描述
免申请下载就等于能免申请上 BigQuery	BigQuery 需单独申请	官方页 Usage Notes
它等于母库的随机抽样	按 subject_id 顺序截取，且被 anchor_year_group 限定	官方页 Methods

FAQ

Q1：它和 MIMIC-IV 全量到底是什么关系？

它是母库的同构子集，由 MIMIC-IV v1.0 派生，当前对外版本 2.2 表示与 MIMIC-IV v2.2 的表结构对齐。全部业务表按 100 个 subject_id 过滤，不含患者信息的字典表整表保留，自由文本模块整体剔除。关键是"同构"二字：表名列名与母库逐字相同，所以在它上面写通的代码可以直接搬到全量；不能搬的是任何依赖人群规模的结论。还有一个容易被忽略的时间差——它派生自 v1.0，而母库现行版本是 v3.1，因此"同构"指的是与 v2.2 那一代同构，不是与当前版本同构。

Q2：我没有 CITI 证书，能用它吗？

能。它的访问策略是"任何人只要遵守许可条款即可访问"，无需凭据、无需签署数据使用协议。获取方式有三种：网页下载、wget 递归、静态 ZIP。只有 Google BigQuery 通道需要单独申请，那与下载不是同一件事。

Q3：100 个人到底够做什么？

够做三件事：验证你的取数 SQL 与特征管线是否正确；教学生认识 MIMIC-IV 的表结构与主键关系；做文本到 SQL 这类依赖 schema 而非数据量的研究。不够做三件事：算任何比例或发生率；训练任何需要规模的模型；把结论外推到真实人群。判断标准很简单——你的目的依赖不依赖人群规模。还有一个中间地带值得单独说：做方法学的原型验证是够的。比如你要验证"这个特征提取函数能不能正确处理 ICD-10 与 ICD-9 并存的情况"，100 人里只要存在这两类编码，验证就成立；至于这两类编码各占多少，那不是这个函数要回答的问题。

Q4：为什么剔除了自由文本病历？

官方页只说明演示库包含与 MIMIC-IV 相似的内容但剔除自由文本，未给出进一步理由。从工程角度看结果是明确的：文本模块是去标识链条上风险最高、体量最大的一块，剔除它使演示库既能免申请开放，又能把体积压到 15.5 MB。代价是文本类任务必须另走 MIMIC-IV-Note 路径。反过来讲，这个剔除也让本库的定位变得非常干净——它是一个纯结构化的数据源，你不需要在读表结构的同时还要处理文本解析、分句、去标识残留这些额外负担。对只想学关系型取数的人来说，这是优点而不是缺陷。

Q5：我该用它的版本号还是 DOI 引用？

两者都要。官方页给出 v2.2 的版本 DOI 10.13026/dp1f-ex47，以及指向最新版本的 DOI 10.13026/ng9m-3n32。引用时应明确写出版本号，因为演示库的结构随版本变化。此外官方页要求附 PhysioNet 平台的标准引用。本演示库没有独立论文，不要为它编造文献出处；若研究实际基于母库，另需引用 MIMIC-IV 主论文。

术语表

术语	含义
MIMIC-IV	Medical Information Mart for Intensive Care IV，贝斯以色列女执事医疗中心的去标识重症与急诊病历库
demo	演示子集，与母库同构但规模受限，用于免申请入门
subject_id	患者层主键，随机密码替换后的整数标识
hadm_id	住院层主键，一次住院一条
stay_id	重症驻留层主键，一次 ICU 驻留一条，MIMIC-III 中名为 icustay_id
itemid	字典表主键，指向检验项目或床旁观察项目
d_ 前缀	无患者信息的字典表命名规则，母库中整表保留
anchor_year	去标识后的年份，落在 2100 - 2200 区间
anchor_year_group	真实就诊年份的分箱标签，如 2011 - 2013
anchor_age	患者在锚定年份的年龄，超过 89 岁一律记为 91
ODbL 1.0	Open Data Commons Open Database License v1.0，本库采用的开放数据库许可
DUA	Data Use Agreement，数据使用协议，母库需要而本库不需要
CITI Program	人体受试者保护培训课程，母库申请的前置条件
RFC 4180	CSV 格式的通用标准，本库遵循此标准
MEDS	Medical Event Data Standard，医疗事件数据标准，其教程以本库为示例
HCPCS	Healthcare Common Procedure Coding System，美国的医疗操作计费编码体系
DRG	Diagnosis Related Group，按诊断相关分组的住院付费分类
EMAR	Electronic Medication Administration Record，电子给药记录
POE	Provider Order Entry，医护人员医嘱录入系统
文本到 SQL	把自然语言问题转成可执行 SQL 查询的任务方向

附录 A：核心数字核对表

数字	出处
100 名患者	官方页 Abstract
31 张数据文件（hosp 22 + icu 9）	v2.2 版官方目录树与校验和清单
26 张表	官方页 Data Description 原文表述
anchor_year_group 取 2011 - 2013 与 2014 - 2016	官方页 Methods
解压后合计 15.5 MB	官方页 Files 面板
ZIP 包 15.4 MB	官方页 Files 面板
demo_subject_id.csv 911 B	官方页 Files 面板
LICENSE.txt 25.2 KB	官方页 Files 面板
README.txt 978 B	官方页 Files 面板
SHA256SUMS.txt 2.9 KB	官方页 Files 面板
v1.0 发布于 2022 年 6 月 22 日	官方页 Versions
v2.2 发布于 2023 年 1 月 31 日	官方页 Versions
DOI 10.13026/dp1f-ex47（v2.2）	官方页 Discovery
DOI 10.13026/ng9m-3n32（最新版本）	官方页 Discovery
许可 ODbL 1.0	官方页 Access 栏
派生自 MIMIC-IV v1.0	官方页 Parent Projects
母库 MIMIC-IV v3.1 记录 364,627 名唯一患者（截至 v3.0）	MIMIC-IV v3.1 官方页 Usage Notes
6 位署名作者	官方页 Authors
当前版本浏览数 20,062，全部版本 21,738	官方页 Project Views