MEDS 版 MIMIC 演示库 — 一百人先跑通一遍

做电子病历研究的人迟早会撞上同一堵墙：真正值钱的那部分数据，拿不到手。MIMIC-IV 要求使用者完成伦理培训、签署数据使用协议并通过资质审核才能下载，而在审核通过之前，你没法确认它到底适不适合你的课题——偏偏"它适不适合"正是申请之前最该回答的问题。MIMIC-IV Clinical Database Demo v2.2 就是为了拆这堵墙做的：取 100 名患者的全部结构化表，免申请、按 ODbL 1.0 开放，让任何人在提交申请之前就能看清 MIMIC-IV 长什么样。

拆掉资质门槛之后，第二堵墙立刻露出来：拿到 CSV 只是开始。MIMIC-IV 的原生结构是三十来张关系表，hosp 与 icu 两个模块各有一套主键，化验项目散落在 itemid 字典里，医嘱、执行与计费分表存放。任何一次建模，真正耗时的第一步都是把这套关系结构摊平成"某个病人在某个时刻发生了什么"。这段代码换个库就作废，换个人就重写，跨论文几乎无法复用，而且它恰恰是最容易出错、最不容易被发现出错的部分。

MEDS 版 MIMIC 演示库要拆的是第二堵墙。它的正式名称是 MIMIC-IV demo data in the Medical Event Data Standard (MEDS)，由 MEDS 工作组的五位成员署名，2025 年 9 月 29 日发布在 PhysioNet 上，版本 0.0.1。它把同一批 100 名患者的记录压成一条五列的事件流，训练、调优、留出三段的划分随数据一起分发，全部文件解压后 5.7 MB。它不解决"数据不够"的问题——100 人无论如何训不出模型；它解决的是"管线跑不起来"的问题：让你在几分钟之内确认自己的 ETL、特征抽取与评测代码在真实的重症监护数据上确实能跑通。一屏速览见下表。

维度	内容
全名	MIMIC-IV demo data in the Medical Event Data Standard (MEDS)
发布平台	PhysioNet，由 MIT 计算生理实验室（MIT LCP）托管
署名作者	van de Water、Steinberg、Wornow、Rockenschaub、McDermott 五人
上游来源	MIMIC-IV Clinical Database Demo v2.2（DOI 10.13026/dp1f-ex47）
首次发布	2025 年 9 月 29 日，版本 0.0.1
患者数	100 名重症患者（官方称 subjects）
数据划分	train 80 / tuning 10 / held_out 10，由 subject_splits.parquet 固定
事件流列	5 列：subject_id、time、code 必填；numeric_value、text_value 可选
实际文件列	以 data/tuning/0.parquet 计为 25 列，五列之外还有 ETL 附带属性列
文件格式	Apache Parquet，单分片（官方说明因体量小未做分片）
元数据文件	codes.parquet、dataset.json、subject_splits.parquet
标准与管线版本	MEDS 0.3.3；ETL 名 MEDS_transforms，版本 0.0.9
总体积	解压后 5.7 MB，ZIP 包 4.7 MB；训练集分片 4,860,946 字节
许可	Open Data Commons Open Database License v1.0（ODbL），免注册免申请
DOI	10.13026/t2y8-ea41（v0.0.1）
是否含自由文本病历	不含，随上游演示库一并排除
典型用途	MEDS 管线联调、跨库特征抽取代码复用、教学演示、申请 MIMIC-IV 前的可行性判断

§1 它要解决的具体麻烦

1.1 两堵墙：资质与整形

第一堵墙是准入。MIMIC-IV 全库包含数万名患者的去标识化病历，访问它要走完整的资质流程，这在隐私伦理上是必要的，代价是研究与数据之间多出一道以周计的等待。演示子集的存在就是为了让这道等待不至于变成盲投：先用 100 人把问题问清楚，再决定要不要投入申请。

第二堵墙是整形。即便数据已经到手，"把关系表变成模型能吃的东西"这一步仍然无法绕过。这堵墙有两个特点，使它比第一堵更顽固。第一，它是隐性的：资质审批有明确的流程与时间点，整形代码没有，它散落在每个人的仓库里，没有标准，也没有人审查。第二，它是不可比的：两个研究组在同一份 MIMIC 数据上做同一个预测任务，若各自的摊平口径不同（入院时间取 admitttime 还是 edregtime、化验值取首次还是均值、出院后事件是否保留），得到的数字就不可比，而这种差异往往要到复现失败时才被发现。

MEDS 的定位是这两堵墙中的第二堵。它不替你申请权限，它替你把"某人在某时刻发生了什么"这句话定义成一个所有参与方都同意的最小结构。

第二堵墙的具体麻烦可以再拆细一层。摊平代码出错的方式有几种典型形态：把一次住院的多条诊断按时间戳排序当成时序（其实诊断是出院时一次性给出的，顺序无意义）；把用药医嘱的开始时间与执行时间混为一谈（前者是决定，后者是事实）；把化验值的单位忽略掉直接比较（同一项目在不同时期可能换过单位）；把 icu 与 hosp 两个模块的时间基准接错（两者对"第零天"的定义不同）。这四类错误都不会报错，都会给出看起来合理的数字，也都会让两份本该一致的结果对不上。

这类错误的共同点是：它们发生在"数据变成张量"之前，而论文的可复现性检查几乎总是从"模型代码公开没有"开始。于是出现了一种尴尬的局面——模型代码公开了、随机种子固定了、超参数写全了，复现依然失败，因为真正决定结果的那段摊平代码从来不在公开的范围内。MEDS 把这段代码的输出格式标准化之后，它才有可能被单独公开、单独审查、单独复用。

1.2 三条常见的错误期待

第一条，期待它是"可以拿来做实验的 MIMIC 替代品"。100 名患者只够跑通代码，不够得出任何关于模型性能的结论。官方页面把它定位为"便于试验 MEDS 并理解该格式的官方演示数据集"（official demo dataset），措辞里没有任何训练语料的含义。

第二条，期待它保留 MIMIC-IV 的表结构。转换是一次有损压平：原来的三十来张表被折进一条事件流，表与表之间的外键关系退化为同一时刻、同一 subject 下的并列事件。想按 MIMIC-IV 教程照着做 SQL 练习，应该用上游的演示库而不是这一份。

第三条，期待划分可以自己重新切。三段划分由 subject_splits.parquet 随数据分发，官方对三段的用途有明确规定，且明确要求 held_out 段的任何信息都不得进入预处理、训练与调优。自己重切等于放弃与其他研究者可比的前提。

1.3 它能给到的与给不到的

你的需求	它给的	够不够
确认自己的 MEDS 读取代码写得对不对	100 人、5.7 MB、单分片，秒级读入	够，这正是它的设计目的
学会 MEDS 五列的语义	官方页面逐列说明，另有 codes.parquet 可查	够
验证跨库特征抽取代码的可移植性	任意机构的数据转成 MEDS 后列结构一致	够，前提是上下游都用 MEDS
训练一个重症预测模型	100 人	不够，量级差三到四个数量级
做 MIMIC-IV 的表结构练习与 SQL 教学	表结构已被压平	不够，请用上游演示库
做临床叙述文本相关的研究	上游演示库已排除自由文本	不够
得到与已发表 MEDS 基准可比的划分	划分随数据分发，train 80 / tuning 10 / held_out 10	够，这正是它相对自切划分的优势
追溯这批数据由哪个 ETL、哪个标准版本生成	dataset.json 四个溯源字段	够，且是它相对一般演示集的加分项

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

你的处境	它能帮你什么	下一步该做什么
你要把本院数据转成 MEDS，不确定转得对不对	给出一份"正确答案"级别的参照实现，columns 与 metadata 齐全	先跑通官方 ETL 命令复现本集，再套自己的数据
你在写 MEDS 读取与切窗代码	5.7 MB 单分片，可以快速反复试错	按 §5.3 读入后先在 tuning 段上验证，别一上来就读 train
你要判断 MIMIC-IV 是否值得申请	事件流形态已足够看清数据密度与编码体系	结合上游演示库的 31 张表一起看，再决定
你要做跨机构、跨库的可比实验	五列结构提供了共同的中间层	确认所有数据源都转成同一 MEDS 版本（0.3.3）
你在教 EHR 机器学习	免申请、体积小、划分已定，一节课能跑完	让学生先在 tuning 段上做探索，held_out 只交一次
你在复现某篇用 MEDS 的论文	划分固定，排除了切分口径这一变量	核对论文的 MEDS 与 ETL 版本是否与 0.3.3 / 0.0.9 一致

1.5 一句话判断

它不是给你更多数据的，是给你一把尺子的：用它量出"我的代码在真实重症数据上跑不跑得通"，而不是量出"我的模型好不好"。

1.6 不适合谁：四条边界

不适合拿来做方法学比较。 100 名患者、单一中心、单一演示切片，任何性能差异都会被样本量淹没。用它比较两种模型的优劣，得到的排序没有意义。

不适合拿来练习关系型查询。 表结构在这一版里已经不存在了。要做 SQL、要做表连接、要理解 MIMIC-IV 的模块划分，请回到上游演示库。

不适合拿来做任何流行病学或临床结论。 上游演示库的 100 名患者本身就不是随机抽样，页面与 README 都未说明抽样规则；再经过一次格式转换，人群代表性只会更弱。

不适合当作 MIMIC-IV 全库的预览。 事件流形态掩盖了原始数据的组织复杂度。看过这一版再去看全库，会低估上手成本。

§2 数据构成与规格

2.1 目录只有两层

官方文件目录的结构非常扁平，根目录下一个 data 文件夹、一个 metadata 文件夹，加三个说明性文本文件：

路径	内容	体积
data/train/0.parquet	训练分片，80 名患者的事件流	4,860,946 字节
data/tuning/0.parquet	调优分片，10 名患者	424,019 字节
data/held_out/0.parquet	留出分片，10 名患者	271,428 字节
metadata/codes.parquet	码表，描述 code 及其父码	390,097 字节
metadata/dataset.json	数据集与 ETL 的溯源信息	约 270 字节
metadata/subject_splits.parquet	患者到分段的映射	1,349 字节
LICENSE.txt	ODbL 1.0 全文	25.2 KB
README.txt	划分说明，并附上游演示库原始 README	1.4 KB
SHA256.txt	各文件校验和	540 B
SHA256SUMS.txt	校验和清单（2025-11-04 更新）	763 B

三个分片的文件名都是 0.parquet。这直接体现了官方页面那句说明：MEDS 支持分片（sharding），但演示集因为体量太小只用了单个分片。分片的价值在于让大数据的处理可以并行，而这个优点的代价——要处理多个文件、要处理跨分片的患者——在 5.7 MB 的量级上完全不值得。

2.2 五列与二十五列

官方页面的措辞是：MEDS 数据模式很简单，只包含三个必填列 subject_id、time、code，以及两个可选列 numeric_value、text_value。这句话描述的是标准的最小要求，不是文件的实际列数。

把 data/tuning/0.parquet 的 schema 打印出来，实际是 25 列：

subject_id                int64
time                      timestamp[us]
code                      string
numeric_value             float
insurance                 large_string
language                  large_string
marital_status            large_string
race                      large_string
hadm_id                   int64
drg_severity              int64
drg_mortality             int64
emar_id                   large_string
emar_seq                  int64
text_value                large_string
priority                  large_string
route                     large_string
frequency                 large_string
doses_per_24_hrs          int64
poe_id                    large_string
icustay_id                int64
order_id                  int64
link_order_id             int64
unit                      large_string
ordercategorydescription  large_string
statusdescription         large_string

五列之外的二十列，是 ETL 从上游表里带过来的属性列，它们的命名直接沿用 MIMIC-IV 的原始字段名。这个设计是有意的：MEDS 规定的是最低要求与列的语义，允许数据集在五列之外自加属性列，这样既保证了跨库的最小公约数，又不丢掉源数据里的结构化信息。

列名	类别	类型	含义	使用注意
subject_id	MEDS 必填	int64	患者标识	与上游 MIMIC-IV 的 subject_id 同源
time	MEDS 必填	timestamp[us]	事件发生的时刻	微秒精度；跨库比较时先统一时区口径
code	MEDS 必填	string	事件类型的编码	具体取值见 codes.parquet
numeric_value	MEDS 可选	float	事件携带的数值	只在有数值的事件上出现
text_value	MEDS 可选	large_string	事件携带的文本	本演示不含自由文本病历
hadm_id	ETL 附带	int64	住院标识	把事件归到一次住院的关键
icustay_id	ETL 附带	int64	重症监护停留标识	做 ICU 内任务时的分组键
emar_id / emar_seq	ETL 附带	混合	电子用药记录标识与序号	区分同一医嘱下的多次给药
order_id / link_order_id	ETL 附带	int64	医嘱标识与关联医嘱	处理医嘱的延续与修改
poe_id	ETL 附带	large_string	医嘱录入标识	医嘱级去重时使用
drg_severity / drg_mortality	ETL 附带	int64	DRG 严重度与死亡风险分级	来自住院结算相关表
race / language / marital_status / insurance	ETL 附带	large_string	患者的社会人口学与管理属性	上游表里的静态字段
unit / route / frequency / priority / doses_per_24_hrs	ETL 附带	混合	用药的剂量单位、途径、频次等	只在用药类事件上有值
ordercategorydescription / statusdescription	ETL 附带	large_string	医嘱类别与状态描述	用来筛掉已取消的医嘱

这张表里最有价值的一行是 hadm_id。MEDS 标准本身没有"住院"这个概念，它的粒度只有"患者—时刻—事件"；而绝大多数重症预测任务其实是以一次住院为单位的。ETL 把 hadm_id 保留下来，等于替使用者把这个坑提前填了。

2.3 一条记录的四种形态

把一条事件流按 code 的前缀拆开看，能看清"关系表被压平"之后留下的四种事件形态。

形态	举例的 code 前缀	在原生 MIMIC-IV 里的位置	压平后的表现
诊断编码	DIAGNOSIS//ICD//9//...	hosp 模块的诊断表	一次住院里每个诊断各占一行
操作编码	PROCEDURE//ICD//9//...	hosp 模块的操作表	同上，带序号信息
化验与生命体征	LAB//<itemid>//<unit>	hosp 的检验表与 icu 的图表事件	数值落在 numeric_value 上
用药与医嘱	用药相关 code	hosp 的医嘱表与 icu 的输液表	附带 unit、route、frequency 等属性列

上表的 code 写法不是作者的即兴发挥，而是 MEDS 社区约定的命名惯例：用双斜杠 // 把"类别 / 词表 / 版本 / 具体码"串成扁平字符串。这样设计的好处是码本身自带层次，不需要额外的列；代价是 code 变成了需要解析的字符串，做聚合前要先按 // 切分。

codes.parquet 里能直接看到这个结构。以三个真实取值为例：

code	description	parent_codes
PROCEDURE//ICD//9//8854	Combined right and left heart angiocardiography	ICD9Proc/88.54
DIAGNOSIS//ICD//9//70723	Pressure ulcer, stage III	ICD9CM/707.23
LAB//51491//units	pH of Urine by Test strip	LOINC/5803-2

第三列是这套设计里最巧妙的地方：MEDS 自己的码不负责统一词表，它只负责给每个码挂上"父码"，父码可以指向外部本体（LOINC、ICD-9-CM、ICD-9 操作码）。于是跨库统一词表的难题，被推迟到"要不要沿 parent_codes 上卷"这一步，使用方可以自己决定上卷到哪一层。

把 code 拆开看还能发现一个细节：化验类的码里带了单位信息，比如 LAB//51491//units 的末段是 units。这是因为 MIMIC-IV 里同一个 itemid 在不同时期可能对应不同单位，把单位编进码，等于用一个字符串解决了"同码不同单位"的歧义。代价是同一个检验项在单位变更前后会变成两个不同的 code——做长时程建模时如果不处理这一点，会把同一项当成两项。

这里要提醒一句：上表只列出了 code 的四种主要形态，用来说明"关系表被压平"之后留下的痕迹。官方页面没有给出 code 命名规则的完整规范，具体的分层约定应以 MEDS 标准文档为准。

2.4 三份元数据文件

文件	官方页面声明的列	文件实际列	说明
codes.parquet	code、description、parent_codes	同上 3 列，另有 itemid、valueuom、possibly_cpt_code	后三列是 ETL 附带的映射辅助信息
dataset.json	dataset_name、dataset_version、etl_name、etl_version、meds_version、created_at	同上 6 个键	JSON 格式，created_at 为 ISO 8601 字符串
subject_splits.parquet	subject_id（int64）、split（string）	同上 2 列	行数与患者数一致，一行一个患者

注意第一行的差异：官方页面说 codes.parquet 有三列，实际文件是六列。多出来的 itemid 直接指向 MIMIC-IV 的 itemid 字典，valueuom 给出该检验项的默认单位，possibly_cpt_code 给出可能的 CPT 对应码。三列都是给想回溯到 MIMIC-IV 原始语义的人准备的。

subject_splits.parquet 的存在意义常被低估。医学机器学习里最常见的不可比来源不是模型，是划分：同样一份数据，甲按随机切、乙按时间切、丙按患者切，三个数字放在一起毫无意义。MEDS 把划分写进数据分发包，等于把"用哪一批患者做最终评测"这个决定提前固定下来。官方对三段的用途规定得很硬：

split 取值	官方规定的用途	常见别名
train	模型构建的任何用途；有监督训练时标签可见	训练集
tuning	超参数调优，或用于最终模型的训练；不得用于最终评测	dev、val、validation
held_out	仅供最终评测；其患者数据不应假定在预处理、训练或调优阶段可用	test

第三行的措辞值得逐字读：“No data about these patients should be assumed to be available during data pre-processing, training, or tuning.”——连预处理阶段都算在内。这句话直接否定了一种常见做法：先把全量数据读进来做归一化、做词表统计、做缺失值填补，再按划分切开。按官方口径，这是违规的。

2.5 与上游演示库的结构差异

对比项	MIMIC-IV Clinical Database Demo v2.2	本数据（MEDS 版）
组织方式	关系型，31 张表（22 张 hosp + 9 张 icu）	事件流，3 个 Parquet 分片
文件格式	gzip 压缩的 CSV	Apache Parquet
解压后体积	15.5 MB	5.7 MB
核心标识	subject_id、hadm_id、stay_id 等各表主键	subject_id、time、code 三列
时间表达	各表各自的 *_time / charttime 列	统一到一列 time
编码表达	各表各自的 itemid / icd_code 列	统一到一列 code，配 codes.parquet
划分	无	train / tuning / held_out，随包分发
上游版本标识	2.2	dataset.json 记 3.1:0.0.2（见 §7.4）
许可	ODbL 1.0	ODbL 1.0
是否含自由文本病历	不含	不含

体积从 15.5 MB 降到 5.7 MB，是列式存储加字典编码的常规结果，不代表信息被删掉；但表结构确实被折掉了，这一点必须说清楚。

2.6 三个分片文件夹与"单分片"

官方页面专门用一段解释了分片：MEDS 支持分片，演示集因为体量有限只用了单个分片；分片对大数据集有用，可以并行处理任务。

这句话要反过来读：分片是 MEDS 给大数据准备的机制，而演示集恰好绕开了它。于是用它练手时你会遇到一个隐性偏差——你写的读取代码如果假设"一个患者的所有事件都在同一个文件里"，在本演示集上完全正确，换成打了几十个分片的真实 MEDS 数据集就会错。官方页面没有给出分片与患者的对应关系规则，因此跨分片的处理方式应以 MEDS 标准文档为准，本文不做推断。

§3 它是谁的数据

3.1 贡献者与机构

作者	机构	在 MEDS 生态中的角色
Robin Philippus van de Water	Hasso Plattner Institute；Icahn School of Medicine at Mount Sinai	MEDS 与 MEDS-DEV 成员，MEDS-Inspect 作者
Ethan Steinberg	Stanford	MEDS 与 MEDS-DEV 成员
Michael Wornow	Stanford	MEDS 与 MEDS-DEV 成员
Patrick Rockenschaub	Medical University of Innsbruck	MEDS 与 MEDS-DEV 成员
Matthew McDermott	Harvard Medical School	MEDS 与 MEDS-DEV 成员

这份数据没有临床机构署名，因为它不是一次采集，而是一次自动转换。上游 MIMIC-IV 数据的采集机构是 Beth Israel Deaconess Medical Center（README.txt 原文：patients admitted to the Beth Israel Deaconess Medical Center），去标识化与发布由 MIT 计算生理实验室体系完成。因此这份资源的作者链条是分层的：采集者在上游，格式转换者在这一层，托管方是 PhysioNet。

官方页面还单列了 MEDS 与 MEDS-DEV 两个社区名单，前者十人，后者三十余人。这个名单的分量在于：它说明 MEDS 不是某一家机构的内部格式，而是一份有明确维护群体的公开标准。

3.2 时间线

时间	事件	来源
2023-01-31	上游 MIMIC-IV Clinical Database Demo v2.2 发布	上游官方页面
2024	MEDS 标准在 ICLR 时间序列与健康学习研讨会上提出	官方参考文献 [1]
2025-01-13T11:02:53	dataset.json 记录的生成时刻	metadata/dataset.json
2025-07-11	README.txt 与 SHA256.txt 的修改日期	官方文件目录
2025-09-22	LICENSE.txt 的修改日期	官方文件目录
2025-09-29	本数据在 PhysioNet 正式发布，版本 0.0.1	官方页面
2025-11-04	SHA256SUMS.txt 更新	官方文件目录

这张表里唯一需要解释的是第三行与第五行的先后关系：dataset.json 里记的生成时刻在 1 月，而正式发布在 9 月。两者相差八个多月，期间 README、许可与校验文件都有改动。这说明元数据里的 created_at 指的是数据生成的时刻，不是发布的时刻——用 created_at 做版本标识时要意识到这一点。

3.3 采集场景：一家医院的百人切片

README.txt 里保留了上游演示库的原始说明，把这条链路讲得很清楚：MIMIC-IV 由 Beth Israel Deaconess Medical Center 的去标识化电子病历构成，访问受资质限制；为了让外界能在申请之前评估这份数据是否适合自己的研究，也便于教学工作坊使用，提供了一个包含 100 名患者的公开演示子集。它的内容与 MIMIC-IV 相似，但排除了自由文本的临床叙述。

README 还提到上游包含一份 demo_subject_id.csv，列出了用于筛选 MIMIC-IV 的 subject_id，只有这些编号出现在演示集里。这份文件属于上游，不在本 MEDS 版本的目录里。

由此可以推出本数据的人群画像的边界：全部为重症监护相关患者，来自美国一家学术医疗中心，不含临床叙述文本，且不是按任何公开规则抽样的随机样本。这三个限定条件决定了它能回答什么、不能回答什么。

3.4 数据来源的四个层次

理解这份数据要先分清四层：Beth Israel Deaconess 的原始病历（不可得，受资质保护）、MIMIC-IV 全库（需申请）、MIMIC-IV 演示子集 v2.2（免申请，31 张表）、MEDS 事件流（本数据，免申请，5 列起）。

这四个层次里，每一层的降级都丢掉一些东西：第一层到第二层丢掉身份与叙述的完整性，第二层到第三层丢掉规模，第三层到第四层丢掉表结构。使用者要清楚自己站在第几层——站在第四层去回答第二层才能回答的问题，是这份数据最常见的误用。

分层的另一个用处是定位责任。一份数据从采集到落到你的磁盘上，中间经过的每一步都可能引入偏差：采集环节决定人群，去标识化环节决定哪些字段被泛化或移位，抽样环节决定演示子集的构成，转换环节决定哪些字段被保留、哪些被折叠。这四个环节由四批不同的人完成，各自的文档也分散在四处。

对使用者来说，这意味着两件事。第一，引用链条要写全——只引用本数据而不引用上游，等于把采集者的贡献抹掉了，官方页面也正是因此才在 Parent Projects 段明确要求"使用本项目时请一并引用它们"。第二，出问题时要能定位到是哪一层：如果某个检验值明显不合理，可能是采集环节的设备问题，也可能是转换环节的单位处理问题，两者的排查路径完全不同。

§4 它最独特的东西

4.1 五列标准的取舍

MEDS 的核心主张可以用一句话概括：把电子病历压成"谁、什么时候、发生了什么、数值是多少、文本是什么"，其余交给工具。这个主张的激进之处在于它的克制——没有患者表、没有住院表、没有字段级的类型系统，连"住院"这个概念都不在标准里。

被刻意省略的东西	通常的做法	MEDS 的处理
患者人口学表	单独一张表存性别、种族等	变成事件，挂在某个时刻
住院 / 就诊概念	一张 admissions 表	标准不管，需要时由 ETL 加属性列
字段类型系统	每个字段声明类型	只区分数值与文本两列
单位系统	每张化验表带 unit 列	编进 code（如 LAB//51491//units）
词表统一	强制映射到标准术语	只提供 parent_codes，上卷与否由使用方决定

这种克制换来的是极高的可移植性：任何数据源，只要能回答"谁、什么时候、发生了什么"，就能转成 MEDS；任何模型，只要能读五列，就能读所有 MEDS 数据。代价是富语义被推到了标准之外——所以它才允许加属性列（§2.2 里那二十列），用"最小核心加可选扩展"的方式同时照顾两件事。

这套取舍可以直接从五列的性质上读出来：

列	它回答的问题	为什么必须在标准里
subject_id	是谁	没有它，事件无从归属，也就无从分组与划分
time	什么时候	没有它，事件流退化成词袋，所有时序模型失效
code	发生了什么	没有它，事件无从区分，只剩一串数值
numeric_value	数值是多少	可选，因为诊断、操作等事件天然没有数值
text_value	文本是什么	可选，因为结构化事件通常不带文本

前三列之所以必填，是因为缺了任何一列，"事件流"这个概念本身就不成立；后两列之所以可选，是因为它们描述的是事件的载荷，而载荷的有无取决于事件类型。这条分界线就是 MEDS 对"最小"的定义：只把让概念成立的东西设为必填。

值得留意的是，标准里没有"事件来源表"这一列。也就是说，压平之后你无法从五列本身判断一条事件原来出自哪张表——这个信息要么被编进 code 的前缀（§2.3 的四种形态），要么丢失。这是极简标准必须付的代价之一。

4.2 划分随数据一起分发

这是它相对一般演示集最实质的加分项。医学 EHR 研究里，划分口径是一个长期被低估的变量：同样是"80/10/10"，随机按事件切与按患者切，得到的评测数字可以差出好几个点；而论文里往往只写一句"我们按 8:1:1 划分"，不写按什么切的。

MEDS 的做法是把划分变成数据的一部分。subject_splits.parquet 有 100 行，每行一个 subject_id 加一个 split 取值。官方页面对三段的用途给了明确规定（§2.4 表），并对 held_out 加了"预处理阶段也不得假定其数据可用"的硬约束。

这个设计的价值在于把"划分"从一个研究者的私人决定，变成了数据集的公共属性。它的代价是灵活性的丧失——如果你需要五折交叉验证，官方划分就不够用。官方对这种情况也给了说法：允许把 tuning 合并进 train 后自行重新洗牌。

4.3 codes.parquet 与"上卷"的自由

码表是这份数据里最容易被忽略、也最见设计功力的部分。它的三列官方列各有分工：code 是事件流的取值，description 是给人读的解释，parent_codes 是给机器用的层次。

真正重要的是 parent_codes 指向什么。从 §2.3 的三个例子可以看到，它指向的是外部本体节点：ICD-9 操作码、ICD-9-CM、LOINC。这意味着 MEDS 不试图建立自己的统一词表，而是承认现实——各家数据本来就用各自的码，强行统一要么丢失细节，要么引入错误。它的策略是保留原码、挂上父码，把"是否上卷、上卷到哪一层"的决定权留给使用方。

对建模者来说，这是一个可以调的旋钮：不做上卷，保留最细粒度的区分度，但跨机构几乎无法对齐；上卷到 LOINC 或 ICD 章级，牺牲细节换取跨库可比。这个旋钮在多数公开数据里是焊死的，在这里是活的。

4.4 dataset.json 里的溯源四件套

字段	值	作用
dataset_name	MIMIC-IV	标注源数据集
dataset_version	3.1:0.0.2	标注源数据集版本
etl_name	MEDS_transforms	标注转换管线
etl_version	0.0.9	标注管线版本
meds_version	0.3.3	标注标准版本
created_at	2025-01-13T11:02:53.383398	标注生成时刻

这六个字段合起来解决了一个具体问题：同一份数据、不同版本转换出来的 MEDS 文件，长得完全一样，但内容可能不同。五列结构不变，code 的命名规则可能变，划分可能变，连哪几条事件被保留都可能变。没有溯源字段，两年后拿到一个名叫 0.parquet 的文件，无从判断它对应哪次转换。

dataset.json 把这个判断变成了读一个 JSON 的事。这也是它比"README 里写一句版本号"更可靠的地方——它是机器可读的，可以被管线自动校验。

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

条件	是否适用	判断依据
验证 MEDS 读取与切窗代码	适用，且是首选	5.7 MB，秒级读入，划分已定
教 MEDS 格式与事件流建模	适用	官方定位为演示数据集
训练任何预测模型	不适用	100 名患者
练习 MIMIC-IV 的关系型查询	不适用	表结构已压平
做文本相关的临床研究	不适用	上游已排除自由文本
跨机构泛化验证	不适用	单一中心
做流行病学或临床结论	不适用	演示切片非随机抽样
评估分片并行处理的代码	不适用	只有单分片

这张表最需要注意的是最后两行。第八行是个陷阱：正因为演示集是单分片，用它验证过的读取逻辑在真实的大规模 MEDS 数据上可能直接出错。

§5 怎么拿到

5.1 下载面

官方给出了三种取数通道，另有整包下载：

通道	命令	适用场景
浏览器整包	页面上的 Download 按钮，ZIP 4.7 MB	只想看一眼、不想装工具
wget 递归	wget -r -N -c -np https://physionet.org/files/mimic-iv-demo-meds/0.0.1/	本地一次性取全，支持断点续传
S3 匿名同步	aws s3 sync --no-sign-request s3://physionet-open/mimic-iv-demo-meds/0.0.1/ DEST	云端批量、带宽要求高
逐文件 curl	见 §5.2 第三段	只要六件核心文件，不要许可与校验

三条通道都不需要 PhysioNet 账号。这一点与上游演示库一致，与 MIMIC-IV 全库不同。

5.2 批量下载

#-- 整目录递归；-N 做时间戳比对，-c 支持断点续传
wget -r -N -c -np https://physionet.org/files/mimic-iv-demo-meds/0.0.1/

#-- 匿名 S3，适合在云主机上直接同步到目标目录
aws s3 sync --no-sign-request s3://physionet-open/mimic-iv-demo-meds/0.0.1/ ./mimic-iv-demo-meds/

#-- 只取三个分片与三份元数据；curl 不会自动建目录，先 mkdir
BASE=https://physionet.org/files/mimic-iv-demo-meds/0.0.1
for p in data/train/0.parquet data/tuning/0.parquet data/held_out/0.parquet \
         metadata/codes.parquet metadata/dataset.json metadata/subject_splits.parquet; do
  mkdir -p "$(dirname "$p")"
  curl -sL "$BASE/$p" -o "$p"
done

#-- 取回后核对校验和
curl -sL "$BASE/SHA256SUMS.txt" -o SHA256SUMS.txt
sha256sum -c SHA256SUMS.txt

最后一段的 sha256sum -c 会检查全部九个文件。注意目录里存在两份校验文件：SHA256.txt（540 B，2025-07-11）与 SHA256SUMS.txt（763 B，2025-11-04）。后者更新，且文件名是 sha256sum -c 的默认期望格式，用后者。

5.3 读一份 Parquet

import pyarrow.parquet as pq

#-- 先看结构再看数据，这一步能避免绝大多数类型假设错误
pf = pq.ParquetFile('data/tuning/0.parquet')
print(pf.schema_arrow)
print('列数 =', len(pf.schema_arrow.names))

import polars as pl

#-- 三个分片各一个文件，全量一次读入毫无压力
ev = pl.read_parquet('data/tuning/0.parquet')
print(ev.select(['subject_id', 'time', 'code', 'numeric_value']).head(3))

#-- 只看 MEDS 定义的五列，其余二十列是 ETL 附带属性
core = ev.select(['subject_id', 'time', 'code', 'numeric_value', 'text_value'])

#-- 划分表随包分发，直接用，不要自己重切
sp = pl.read_parquet('metadata/subject_splits.parquet')
print(sp.group_by('split').len().sort('split'))     #-- train/tuning/held_out 各多少患者

第二段最后一行会打印每个 split 下的患者数。这个数字应该是 80、10、10，与官方页面一致；如果不一致，说明你下载的文件与页面描述的版本对不上，先去核对 dataset.json（§4.4）与 SHA256SUMS.txt。

5.4 从事件流到特征矩阵

import polars as pl

CORE = ['subject_id', 'time', 'code', 'numeric_value', 'text_value']

def load_split(split):
    #-- 分片文件夹名与 split 取值一一对应
    ev = pl.read_parquet(f'data/{split}/0.parquet').select(CORE)
    return ev

def subject_level(ev):
    #-- 最朴素的聚合：每个患者、每个 code 取最后一次观测的时刻与数值
    return (ev.sort(['subject_id', 'code', 'time'])
              .group_by(['subject_id', 'code'])
              .agg(pl.col('time').max().alias('last_time'),
                   pl.col('numeric_value').last().alias('last_value')))

train = subject_level(load_split('train'))
tuning = subject_level(load_split('tuning'))

#-- 划分由 subject_splits.parquet 决定，不要按行随机切
sp = pl.read_parquet('metadata/subject_splits.parquet')
held_ids = set(sp.filter(pl.col('split') == 'held_out')['subject_id'].to_list())

这段代码是刻意写得粗陋的：它只用"最后一次观测"这一个聚合口径。真正做研究时至少有三处要改。第一，聚合口径（首次、末次、最值、时间窗内计数）要写进方法节，因为不同口径给出的矩阵差异极大。第二，划分必须走 subject_splits.parquet，不能按行随机切——后者会让同一个患者的事件同时落在训练与测试里，这是事件流数据上最容易犯、也最难察觉的泄漏。第三，官方明确要求 held_out 段的数据在预处理阶段都不得假定可用，所以归一化参数、词表统计都只能在 train（必要时加 tuning）上算。

5.5 接进 MEDS 生态

官方页面列出了一批兼容工具，这是这份数据相对"一个普通 Parquet 文件"的真正优势所在：

工具	用途	它能替你做什么
MEDS-Reader	高效 EHR 处理	按 MEDS 约定读取与遍历事件流
MEDS-Transforms	数据转换	把任意数据源转成 MEDS，或把 MEDS 转成任务张量
MEDS-Tab	自动制表	自动完成表格化与特征准备
MEDS-Inspect	交互式查看	交互式浏览 MEDS 数据
ACES	队列抽取	用配置语言可复现地抽取任务队列

这五个工具覆盖了从"拿到数据"到"得到任务张量"的全链路。它们的存在也是 MEDS 主张的直接证据：标准极简，是为了让工具链可以做厚。

5.6 五个最容易出错的地方

位置	错误写法	后果	正确做法
列数	以为文件只有五列	漏掉 hadm_id、icustay_id 等关键分组键	先打印 schema，见 §2.2
划分	按行随机切训练测试	同一患者的事件跨集泄漏	用 subject_splits.parquet
预处理	全量算归一化参数再切分	违反官方对 held_out 的规定	只用 train（可加 tuning）拟合
分片	假设一个患者只在一个文件里	换到多分片数据集即失效	按 MEDS 标准文档处理跨分片
校验	用 SHA256.txt 而不是 SHA256SUMS.txt	校验文件较旧，格式也不匹配 sha256sum -c	用 SHA256SUMS.txt

第二行与第三行是同一件事的两个面：事件流数据里，患者才是划分单位，行不是；而"预处理不得使用留出段"这条规定，正是为了让这个划分真正起作用。

第四行的坑值得单独说。事件流数据的一个隐含诱惑是"反正都是行，随机打乱就好"。在关系表里，主键与外键的存在会不断提醒你患者是一个实体；而在一条扁平的事件流里，subject_id 只是众多列中的一列，很容易在切窗、采样、增广的环节被忽略。一旦按行切分，同一个患者的早段与晚段会同时出现在训练与测试里，模型只要记住这个人的基线特征就能白拿分——而它学到的东西，在任何一个新患者身上都无效。

第五行则是纯粹的工程细节，但它的代价很实在：用旧校验文件核对，可能因为文件更新而报校验失败，然后你会花时间去查一份根本没坏的数据。目录里同时存在两份校验文件这件事本身，也说明这份数据在发布后又被动过——包内文件的修改日期一直排到 2025-11-04，晚于 9 月 29 日的发布日期。下载时取最新的 SHA256SUMS.txt，并在论文里注明下载日期，是更稳妥的做法。

§6 与库内条目的关系

6.1 关系图谱

相关资源	与它的关系	该看哪个
MIMIC-IV Clinical Database Demo v2.2（rid 1629）	直接上游，同一批 100 名患者	要看表结构与 SQL，看上游；要看事件流，看本数据
MIMIC-IV（rid 592 / rid 4）	上游的上游，全库需申请	要真做研究，最终要用它
MIMIC-IV on FHIR（rid 1529）	同一家族的另一种标准改写	要比较不同标准的取舍，两者对照看
MIMIC-III Demo（rid 591）	上一代演示子集	要理解演示子集的沿革
MIMIC-III（rid 590 / rid 106）	上一代主库	文献里的历史基线多在这里
MIMIC-III 序列样本库（rid 1530）	另一种序列化思路	要比较不同的 EHR 序列化方案
MIMIC-III CareVue 子集（rid 1534）	上游的另一类子集	要理解子集划分的口径差异
MIMIC-BR（rid 156）	MIMIC 家族的 OMOP 化分支	要理解 OMOP 与 MEDS 的分工

这条关系线上最值得停留的是第三行。MIMIC-IV 家族里现在至少存在三种"标准改写"：原生的关系型 CSV、FHIR 资源、MEDS 事件流。三者不是竞争关系，而是面向三种不同的工作：SQL 查询与教学用原生表，系统互操作与接口对接用 FHIR，机器学习建模用 MEDS。选错标准不是错误，但会让每一步都变慢。

6.2 检索路径

你要找的东西	检索词	会落到哪里
上游演示库	MIMIC-IV demo、演示库	rid 1629
MIMIC-IV 全库	MIMIC-IV、重症监护	rid 592、rid 4
另一种标准改写	FHIR、互操作	rid 1529
序列化方案比较	序列、样本库	rid 1530
上一代对照	MIMIC-III	rid 590、rid 106
OMOP 路线	OMOP、通用数据模型	rid 156
演示子集的沿革	MIMIC-III demo	rid 591

6.3 分工判据

任务	用哪一份	原因
学会 MIMIC-IV 的表结构与查询	上游演示库（rid 1629）	表结构完整保留
跑通 MEDS 管线	本数据	唯一目的就是这件事
复现已发表的 MEDS 基准	本数据	划分固定，口径可比
训练重症预测模型	MIMIC-IV 全库（rid 592）	需要申请，但量级够
做系统对接与接口开发	FHIR 版（rid 1529）	FHIR 面向互操作
做观察性队列研究	OMOP 化数据（rid 156）	OMOP 面向流行病学

这张表的阅读方式是：先确定你的工作属于哪一行，再去取对应的那份。四行里只有第二行和第三行属于本数据——它的地盘很小，但在这两行里没有替代品。

§7 质量评估与局限性

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

先纠正一个常见误判：把"只有 100 人"当成这份数据的缺陷。它不是数据集，是参照实现——一个被用来验证"MEDS 长什么样、工具能不能读、ETL 转得对不对"的最小可信样本。评价它的尺子不是规模，而是"它是否忠实地体现了标准"。

这个校正会改变下面五维评分的读法。规模这一项必然拿不到高分，但它在"格式保真度"这一项上几乎无可挑剔：五列齐全、三份元数据齐备、四个溯源字段写满、划分随包分发。

7.1 五维评分

按常用维度打分，每项 1–5 分，分数针对"作为 MEDS 管线参照实现"这个用途：

维度	分数	理由
数据规模	1	100 名患者，仅够跑通代码
结构保真	5	五列齐全，元数据三件齐备，溯源字段完整
任务适配	3	只适配"学格式、验管线"，不适配任何建模任务
文档完整	4	逐列说明、划分用途、工具清单都有；版本口径有一处不一致（§7.4）
可获取性	5	免注册、ODbL、5.7 MB，三条通道任选

五项合计 18 分（满分 25）。这个分数结构说明它是一件专器：规模拉到底，结构与可获取性拉满。

7.2 转换保真度的两层

第一层是结构保真：五列在不在、类型对不对、划分有没有随包。这一层可以直接核验，结论是全部到位——schema 打印出来列齐全，subject_splits.parquet 行数与患者数一致，dataset.json 六个字段无缺。

第二层是语义保真：上游的每一个字段是否都被正确映射到了某个 code。这一层无法从文件结构判断，只能靠两点间接支撑：一是 ETL 出自 MEDS 工作组核心成员之手，二是同一套 MIMIC-IV ETL 代码库（MIMIC_IV_MEDS）在社区公开。官方页面没有给出逐字段的映射对照表，因此"某个具体的 MIMIC-IV 字段被转成了什么 code"这类问题，需要回到代码库或 codes.parquet 里逐条确认。

这两层的区分很重要。说"它转得对"，通常指的是第一层；而研究里真正会出问题的往往是第二层。

判断第二层有一个实操办法：拿 codes.parquet 当检查表用。它带有 itemid 列，直接指向 MIMIC-IV 的原始项目编号；又带有 description 与 valueuom，给出人可读的解释与默认单位。把你关心的那几个 MIMIC-IV 字段的 itemid 查一遍，看它落到了哪个 code、描述是否相符、单位是否正确，就完成了一次最小可行的语义核验。这个办法不能覆盖全部字段，但能把最容易出错的检验类项目过一遍。

需要说清的是，这种做法只能验证"码挂得对不对"，验证不了"值转得对不对"——后者需要把 MEDS 里的 numeric_value 与上游 CSV 的同一条记录逐条比对，那已经超出了本数据自带材料能支撑的范围。官方页面没有给出这类对照结果，本文也不做这个比对。

7.3 已知的、可枚举的偏差

偏差	表现	影响
规模极小	100 名患者	任何性能数字都不可用
单中心	数据来自一家美国学术医疗中心	不能代表其他机构
抽样规则未公开	官方未说明 100 人的选取规则	人群代表性无法评估
无临床叙述文本	上游演示库已排除	所有文本任务不可用
表结构被压平	外键关系退化为并列事件	关系型查询不可做
单分片	只有 0.parquet	跨分片处理逻辑无法在此验证
静态属性被事件化	人口学字段进入事件流	需要额外的聚合口径
版本口径不一致	见 §7.4	引用时需注明依据

7.4 版本口径不一致：三处必须知道

这是本数据最需要提醒使用者的地方，三处不一致全部出自官方自己的材料：

出处	写的版本
页面标题、引用块、DOI	Version 0.0.1
Release Notes 小节	「Version 0.1.1：Initial release. Added dataset in MEDS 0.3.3 with MIMIC-IV ETL 0.0.6」
Methods 段	使用 MIMIC-IV-MEDS 0.0.6（PyPI 上的 MEDS Python 包）生成
metadata/dataset.json	etl_name = MEDS_transforms，etl_version = 0.0.9，meds_version = 0.3.3
页面 Ethics 与 Parent Projects	上游为 MIMIC-IV Clinical Database Demo V2.2
metadata/dataset.json	dataset_version = 3.1:0.0.2

第一处是版本号：页面与 DOI 都是 0.0.1，Release Notes 却写成 0.1.1。引用时以页面标题与 DOI 为准（0.0.1），并留意文献里可能出现的 0.1.1 写法。

第二处是 ETL 版本：页面两处提到 0.0.6（pip 安装 MIMIC_IV_MEDS==0.0.6，release notes 写 MIMIC-IV ETL 0.0.6），而 dataset.json 记的是 etl_name = MEDS_transforms、etl_version = 0.0.9。两者连管线名都不一样。要复现这份数据，dataset.json 是更可靠的依据，因为它写在数据里。

第三处是上游版本：页面写明上游是 MIMIC-IV Clinical Database Demo v2.2，而 dataset.json 的 dataset_version 写的是 3.1:0.0.2。这两个数字代表什么关系，官方材料没有解释，本文不做推断。引用上游时，应同时注明页面口径的 v2.2 与 dataset.json 里的 3.1:0.0.2。

7.5 它为何值得存在

因为它把一件通常需要几天的事压缩到了几分钟。要让一个人相信"MEDS 这条路线可行"，讲一百页标准文档不如给一份 5.7 MB、免注册、划分已定、元数据齐备的真实数据。它是标准的样品，不是数据的样品。

这份样品还承担了第二个功能：它是"什么叫一份合格的 MEDS 数据集"的模板。数据文件放 data、元数据放 metadata、划分单独成表、溯源信息写成机器可读的 JSON——这套组织方式被每一个后来者照抄。官方页面在 Background 段里说得很明白，提供官方演示数据集的目的是"to better facilitate experimenting with MEDS and improve understanding of the format as a whole"，即既方便试验，也帮助理解整个格式。

从这个角度看，它保存下来的版本口径不一致（§7.4）反而是有用的：它告诉所有准备做 ETL 的人，版本号是最容易失控的元数据。dataset_version、etl_version、meds_version 三个字段分属三个不同的东西，任何一个写错，两年后都无法追溯。这份数据把错误留在了明面上，反而给后来者上了一课。

§8 生态位与历史

8.1 MEDS 的来路

MEDS 于 2024 年提出，论文发表在 ICLR 的时间序列与健康学习研讨会上，作者阵容与本文五位署名者高度重合（Arnrich、Choi、Fries、McDermott、Oh、Pollard、Shah、Steinberg、Wornow、van de Water）。论文的核心主张在官方页面里被复述得很直白：MEDS 是一个存储医疗事件流的数据模式，事件可来自电子病历或理赔记录；它刻意做成最小标准，以求在数据集、现有工具与模型架构之间取得最大互操作性。

"刻意最小"这四个字是关键。EHR 标准化的历史上不缺雄心勃勃的方案，缺的是能被不同机构、不同工具、不同模型都接受的那一层薄薄的共识。MEDS 的赌注是：只做最薄的那一层，反而最可能被接受。

这个赌注的具体内容，可以从它给自己设定的四条约束里读出来：跨数据集互操作、兼容现有工具、兼容不同模型架构、以及让研究更可复现、更稳健、更省算力、更可协作。官方 Abstract 段把后四条并列写出，其中"computationally performant"（计算上高效）这一条常被忽略——它解释了为什么 MEDS 选择列式存储与事件流，而不是更常见的宽表：宽表在字段数量增长时会迅速膨胀，而事件流的行数虽多，列数却恒定。

理解这一条，就能理解本数据的很多设计决定：为什么用 Parquet 而不是 CSV，为什么五列之外允许加列而不是强制统一，为什么分片是可选的。它们都指向同一件事——让大规模 EHR 数据在普通算力上跑得动。演示集本身只有 5.7 MB，但它演示的是一条为大规模数据准备的通路。

8.2 与 OMOP 的分工

同一批 MIMIC-IV 演示数据在 PhysioNet 上还有一个 OMOP CDM 版本（Kallfelz 等，2021，version 0.9，DOI 10.13026/p1f5-7x35）。官方页面在 Background 段主动提到了它，措辞是"the MIMIC-IV demo has been converted to the OMOP standard"。两个标准并存，是因为它们解决的是不同的问题：

对比项	OMOP CDM	MEDS
主要用途	观察性研究、队列与流行病学分析	机器学习建模
组织方式	规范化关系表，几十张表	事件流，五列起
词表策略	强制映射到标准术语	保留原码，父码可选上卷
分析入口	SQL	张量与工具链
学习成本	高，表多	低，列少
对 MIMIC 的适配	有官方转换版本	本数据

这张表不该读成"二选一"。真实的工作流往往是：用 OMOP 做队列定义与人群描述，用 MEDS 做模型训练。两者共用同一批源数据，服务于同一项研究的两个阶段。

8.3 生态位

角色	参照实现	训练语料
典型用法	验管线、学格式、做教学	训练模型、评测性能
需要的条件	格式正确、元数据齐备、可获取	规模大、人群多样、标签可信
代表	本数据	MIMIC-IV 全库、各机构 MEDS 数据集
失败模式	拿它下结论	拿它当格式说明

本数据坐在左边这一列的最顶端。它的价值恰恰在于它不承担右边那一列的任何责任。

8.4 谁在用它

从官方材料能看到的使用面有三类。第一类是 MEDS 工具链的开发者与使用者——页面列出的 MEDS-Reader、MEDS-Transforms、MEDS-Tab、MEDS-Inspect、ACES 五个工具，都需要一份标准样例来验证。第二类是准备把自己机构的数据转成 MEDS 的团队，本数据提供了"转完之后应该长什么样"的参照。第三类是教学场景，5.7 MB 与免注册的组合让它可以直接放进课程材料。

官方页面显示当前版本的访问量为 1,321 次。这个数字相对上游演示库的两万余次访问量要小得多，符合它"专器"而非"入口"的定位。

§9 使用指引

9.1 三种角色的路径

角色	第一天	第一周	注意事项
数据工程师	下全六个文件，打印 schema，核对 dataset.json	用官方 ETL 命令复现本集，再套自己的数据	别用 0.0.6 还是 0.0.9，见 §7.4
机器学习研究者	只读 tuning 段，跑通五列读取	按 subject_splits.parquet 建划分，接通 MEDS-Tab 或 ACES	归一化参数只在 train 上拟合
教师	整包下载，让学生自己读 Parquet	布置"用 tuning 段探索、held_out 只交一次"的作业	提醒学生这是单分片，真实数据不是

9.2 一条最短的可用流程

#-- 1. 取全部文件（免注册）
wget -r -N -c -np https://physionet.org/files/mimic-iv-demo-meds/0.0.1/

#-- 2. 核对校验和与溯源信息
cd physionet.org/files/mimic-iv-demo-meds/0.0.1
sha256sum -c SHA256SUMS.txt
cat metadata/dataset.json
#-- 期望看到：etl_name=MEDS_transforms、etl_version=0.0.9、meds_version=0.3.3

import polars as pl

CORE = ['subject_id', 'time', 'code', 'numeric_value', 'text_value']
sp = pl.read_parquet('metadata/subject_splits.parquet')

#-- 3. 按官方划分读三段，不要自己切
parts = {}
for s in ['train', 'tuning', 'held_out']:
    ids = set(sp.filter(pl.col('split') == s)['subject_id'].to_list())
    parts[s] = pl.read_parquet(f'data/{s}/0.parquet').select(CORE)
    print(s, '患者数 =', len(ids))

#-- 4. 看一眼码表怎么挂父码
codes = pl.read_parquet('metadata/codes.parquet')
print(codes.columns)
print(codes.select(['code', 'description', 'parent_codes']).head(3))

跑完这四步，你已经确认了三件事：文件完整（校验和通过）、版本清楚（dataset.json）、划分可用（subject_splits.parquet）。这三件事正是这份数据存在的全部意义。

9.3 引用方式

引用对象	内容
本数据	van de Water, R. P., Steinberg, E., Wornow, M., Rockenschaub, P., & McDermott, M. (2025). MIMIC-IV demo data in the Medical Event Data Standard (MEDS) (version 0.0.1). PhysioNet. RRID:SCR_007345. https://doi.org/10.13026/t2y8-ea41
上游数据	Johnson, A., Bulgarelli, L., Pollard, T., Horng, S., Celi, L. A., & Mark, R. (2023). MIMIC-IV Clinical Database Demo (version 2.2). PhysioNet. RRID:SCR_007345. https://doi.org/10.13026/dp1f-ex47
标准论文	MEDS Working Group（2024）. Medical Event Data Standard (MEDS): Facilitating machine learning for health. ICLR 2024 Workshop on Learning from Time Series For Health.
平台	PhysioNet 平台综述论文（2026 年发表于 Nature Health），按官方页面 Cite 按钮生成

PhysioNet 页面明确要求：使用本资源时，同时引用上游的 MIMIC-IV Clinical Database Demo（页面 Parent Projects 段的原话是 “Please cite them when using this project”）。写论文时建议再补三项：所用版本（0.0.1）、dataset.json 里的 meds_version 与 etl_version、以及划分是否直接采用随包分发的 subject_splits.parquet。

§10 AI 使用声明

项目	声明
文本生成	本文由 AI 辅助撰写，编辑把关结构与事实
数字来源	规模、结构、边界三类数字来自 PhysioNet 官方页面与随包分发的文件
文件核验	SHA256SUMS.txt、README.txt、metadata/dataset.json、三个分片与两份元数据 Parquet 的 schema 经直接访问确认
不一致说明	版本号页面 0.0.1 与 Release Notes 0.1.1 不一致；ETL 版本页面 0.0.6 与 dataset.json 0.0.9 不一致；上游版本页面 v2.2 与 dataset.json 的 3.1:0.0.2 不一致。三处均已如实列出，本文不做推断
论文信息	仅参考官方页面给出的文献与链接，未读全文
未核验内容	每个 code 的具体出现次数；各分片的事件行数；code 与 MIMIC-IV 原始字段的逐条映射；跨分片的处理规则
图像	无配图；封面为生成式提示词，不含真实病历内容
免责	本文不构成临床建议；数据使用须遵守 ODbL 1.0 的署名与相同方式共享要求

常见误读（避坑清单）

说法	实际	证据
「MEDS 文件只有五列」	标准只要求五列，实际文件有 25 列	data/tuning/0.parquet 的 schema 打印结果
「100 人可以拿来训模型」	官方定位是便于试验 MEDS 与理解格式的演示数据集	官方 Background 段
「划分可以自己重新切」	划分随包分发，官方对三段用途有硬性规定	subject_splits.parquet 与官方 Data Description 段
「预处理时可以用全量数据算参数」	官方明确 held_out 段数据在预处理阶段也不得假定可用	官方 Data Description 段原话
「codes.parquet 只有三列」	官方页面写三列，文件实际六列	metadata/codes.parquet 的 schema
「ETL 版本是 0.0.6」	页面写 0.0.6，dataset.json 写 0.0.9	两处材料对比
「上游是 MIMIC-IV demo v2.2，版本很清楚」	页面写 v2.2，dataset.json 写 3.1:0.0.2	两处材料对比
「它含临床叙述文本」	上游演示库就排除了自由文本，本数据自然不含	README.txt 原文
「一个患者的所有事件一定在同一个文件里」	本集是单分片才成立；MEDS 支持分片，大数据集会拆	官方 Data Description 段的分片说明
「5.7 MB 说明信息被删掉了」	是列式存储与字典编码的常规结果，上游 CSV 解压后 15.5 MB	两个官方页面的体积说明
「用它比较两种模型的优劣」	100 人，任何性能差异都被样本量淹没	§1.6 与 §7.0

FAQ

Q1：MEDS 到底有几列？为什么官方说五列，我读出来二十五列？
五列是标准的必填与可选核心列，即 subject_id、time、code、numeric_value、text_value；二十五列是这份具体文件在核心之外附加的属性列。MEDS 的设计是"最小核心加可选扩展"：核心列保证跨库可读，扩展列保留源数据的结构化信息，比如 hadm_id、icustay_id、unit、route。写通用代码时按五列写，做具体研究时再取需要的扩展列。

Q2：训练、调优、留出三段能不能自己重新划分？
官方不禁止，但代价是失去与其他 MEDS 使用者的可比性。subject_splits.parquet 把划分变成了数据的一部分，这正是 MEDS 相对"各自随机切"的改进所在。官方还额外给了灵活空间：如果需要不同的划分比例，允许把 tuning 合并进 train 后自行重新洗牌，但 held_out 段始终不应进入训练或调优。

Q3：它的上游到底是 MIMIC-IV 的哪个版本？
两处官方材料口径不同。页面的 Ethics 与 Parent Projects 段写明上游是 MIMIC-IV Clinical Database Demo v2.2（给出的引用也指向 v2.2 的 DOI）；而随包分发的 dataset.json 里，dataset_version 写的是 3.1:0.0.2。官方没有解释这两个数字的关系，本文不做推断。引用时建议两者都注明。

Q4：我想做 ICU 内的预测任务，事件流里还有住院与 ICU 停留的标识吗？
有，但不在 MEDS 的五列里，而在 ETL 附带的扩展列里：hadm_id 是住院标识，icustay_id 是重症监护停留标识。这两个列正是"标准极简、扩展补位"这一设计的直接体现——MEDS 标准里没有"住院"这个概念，需要它的数据集就自己加一列。

Q5：为什么只有 5.7 MB？是不是被删掉了很多内容？
体积变化主要来自存储格式：上游演示库分发的是 gzip 压缩的 CSV，解压后 15.5 MB；MEDS 版是 Parquet，列式存储加字典编码对这种"长表、低基数字符串"的结构压缩效果很好。真正被去掉的是表结构——三十来张表被折成一条事件流，外键关系退化为并列事件——而不是大量的数据行。

术语表

术语	解释
MEDS	Medical Event Data Standard，医疗事件数据标准，用五列描述患者事件流
事件流	把病历拆成"某人在某时刻发生了什么"的扁平记录序列
subject	MEDS 里的患者单位，对应 MIMIC-IV 的 subject_id
code	事件类型编码，用双斜杠分层，如 LAB//51491//units
numeric_value	事件携带的数值，如检验结果
text_value	事件携带的文本值
parent_codes	码的上级节点，可指向 LOINC、ICD 等外部本体
shard / 分片	把大数据集切成多个文件以便并行处理；本集只有一个分片
Parquet	Apache 列式存储格式，压缩率高，适合分析型读取
ETL	抽取、转换、加载，把源数据加工成目标格式的过程
MEDS-Transforms	在任意数据与 MEDS 之间做转换的函数与脚本集
MEDS-Reader	按 MEDS 约定高效读取 EHR 的软件包
MEDS-Tab	把 MEDS 数据自动表格化的软件包
MEDS-Inspect	交互式查看 MEDS 数据的软件包
ACES	用配置语言可复现地抽取任务队列的软件包
tuning	MEDS 三段划分中的调优段，相当于 dev 或 val
held_out	MEDS 三段划分中的留出段，相当于 test，仅供最终评测
OMOP CDM	观察性医疗结果伙伴关系通用数据模型，面向观察性研究
itemid	MIMIC-IV 里标识检验与观察项的编号
ODbL	Open Database License，开放数据库许可，本数据用 v1.0

附录 A：核心数字核对表

项	值	出处
患者数	100 名（subjects）	官方 Data Description 段；README.txt
训练段患者数	80	官方 Data Description 段；README.txt
调优段患者数	10	同上
留出段患者数	10	同上
MEDS 核心列数	5（3 必填 + 2 可选）	官方 Data Description 段
tuning 分片实际列数	25	data/tuning/0.parquet 的 schema
codes.parquet 列数	官方页面声明 3，文件实际 6	官方 Data Description 段；文件 schema
subject_splits.parquet 列数	2（subject_id、split）	官方 Data Description 段；文件 schema
dataset.json 键数	6	官方 Data Description 段；文件原文
分片数	1（单分片）	官方 Data Description 段；文件目录
解压后总体积	5.7 MB	官方 Files 段
ZIP 包体积	4.7 MB	官方 Files 段
train 分片体积	4,860,946 字节	文件响应头
tuning 分片体积	424,019 字节	文件响应头
held_out 分片体积	271,428 字节	文件响应头
codes.parquet 体积	390,097 字节	文件响应头
subject_splits.parquet 体积	1,349 字节	文件响应头
MEDS 标准版本	0.3.3	dataset.json；Release Notes
ETL 名与版本	MEDS_transforms / 0.0.9	dataset.json
页面所述 ETL 版本	MIMIC-IV-MEDS 0.0.6	官方 Methods 段
数据生成时刻	2025-01-13T11:02:53.383398	dataset.json
发布日期	2025 年 9 月 29 日	官方页面
版本号	0.0.1	官方页面标题与 DOI
DOI	10.13026/t2y8-ea41	官方 Discovery 段
上游 DOI	10.13026/dp1f-ex47	官方 Parent Projects 段
上游解压后体积	15.5 MB	上游官方页面
许可	ODbL v1.0	官方 License 段
当前版本访问量	1,321 次	官方页面