信息速览

数据集名称把重症病历压成序列 — MIMIC-III 序列样本库

数据类型TFRecord,序列样本,结构化EHR,派生数据集,词表文件

规模MIMIC-III v1.4 全部 24 小时以上住院

接入方式https://physionet.org/content/mimic-seqex/1.0.0/

AI 就绪度

几乎所有用过 MIMIC-III 的人都会在某一步停下来：把那张二十六张表的关系型数据库，切成模型能吃的东西。切法有无数种——化验值取哪几个、用药怎么编码、时间窗多宽、既往住院算不算进当前样本、死亡标签从哪张表里取。每一种切法都合理，每一种都写进了某篇论文的方法段，于是同一个「MIMIC-III 上的死亡率预测任务」，在不同论文里对应着不同的输入张量。复现的困难不在模型，而在模型之前那段没人愿意完整公开的预处理。

MIMIC-III 序列样本库（MIMIC-III - SequenceExamples for TensorFlow modeling）就是把这个「之前」冻结成文件的一次尝试。它由谷歌健康（Google Health）的三名研究者制作，2020 年 9 月 29 日交给 PhysioNet，只有一个版本。做法是把 MIMIC-III v1.4 先映射到 HL7 FHIR 标准，再从 FHIR 转成 TensorFlow 的 tf.SequenceExample：每一次住院变成一条带时间轴的样本，标签塞在同一份样本里。你拿到的不再是表，而是四个已经切好的 TFRecord 文件集合。

这件事的价值与它的局限是同一件事的两面。它省掉的正是最容易出错的那段工程，代价是你也就失去了对那段工程的控制权——预处理的口径被固定进二进制，改一个字段就要回到上游重做。下面先给一屏速览，再说清楚哪一半是它替你决定的、哪一半必须由你自己补。

维度	内容
全名	MIMIC-III - SequenceExamples for TensorFlow modeling
中文简称	MIMIC-III 序列样本库
发布方	PhysioNet；制作方为 Google Health 的 Jonas Kemp、Kun Zhang、Andrew Dai
首次发布	2020 年 9 月 29 日，版本 1.0.0
最近改动	无。至今只有 1.0.0 一个版本
样本数量	官方页未给出数字；以 MIMIC-III v1.4 中住院时长满 24 小时的住院为池，需登录后在目录内清点
患者规模	继承 MIMIC-III v1.4，超过四万名重症患者
预测任务	4 个，对应 4 个顶层文件夹
预测时点	2 种：入院后 24 小时、出院时
标签种类	3 种：住院死亡、全部出院诊断 ICD-9 码、主要诊断 CCS 分组
纳入边界	仅住院时长 ≥ 24 小时；CCS 任务另剔除 1.3% 主要诊断属不可计费 ICD-9 码的住院
划分方式	约 80% 训练 / 10% 验证 / 10% 测试，按患者 ID 切分
文件格式	TFRecord，逐条为 `tf.SequenceExample` 协议缓冲
词表	每个任务文件夹内一份 ZIP，含 `{特征名}.txt` 与 `{特征名}_freqs.csv`
上游来源	MIMIC-III Clinical Database v1.4（贝斯以色列女执事医疗中心，2001–2012）
许可	PhysioNet Credentialed Health Data License 1.5.0
访问门槛	仅凭证用户；须完成 CITI 培训并签署 DUA 1.5.0
DOI	本版 10.13026/n2v5-5b32；latest 10.13026/6jx9-cy34
典型用途	序列模型的基线复现、EHR 预处理口径对照组、教学用的「已就绪」样本

§1 它要解决的具体麻烦

1.1 同一份 MIMIC-III，四种预处理，四个结果

MIMIC-III 自 2016 年发布后迅速成为电子病历机器学习的事实基准。它的问题从来不是数据不够，而是数据太自由：二十六张表之间用 SUBJECT_ID、HADM_ID、ICUSTAY_ID 三级主键相连，事件表按 ITEMID 存放，具体含义要回字典表查。研究者面对的第一道工序不是建模，是决定「什么算一个事件」。

这道工序里每一个决定都会改变结果。化验值是否做对数变换、异常值截断在哪个分位、用药是按成分还是按商品名编码、每小时的聚合用均值还是末值、既往住院是否拼接到当前样本、死亡标签取住院内死亡还是 30 天死亡——这些选择在论文里通常只占方法段的两三句话，却足以让同一个模型在两个复现之间差出好几个百分点。作者在背景段把这一点写得很直白：不同分析采用不同的预处理方法，精确复现跨研究的结果因此变得困难。

举一个最小的例子。同一条住院，甲研究把每小时的生命体征取均值作为该小时的向量，乙研究取末值；当某小时只有一次记录时两者相同，有六次记录时两者不同。丙研究干脆不做小时聚合，把每次测量当成一个事件，于是同一段住院的序列长度是甲的三倍。三份数据都叫「MIMIC-III 的小时级序列」，模型结构相同，指标却不可比。这类差异不会写在摘要里，只会藏在方法段的一句「we aggregated hourly」里。

社区并非没有尝试收敛。官方参考文献里点了两个可复用的开源流水线：MIMIC-Extract 与 Sjoding 等人提出的通用化流程。但它们都是「工具箱」而不是「成品」：工具箱给你一组可调参数，成品给你一组已经调好的文件。前者灵活，后者可复现。这个库选择了后者，并且把选择做得更彻底——它不只固定了特征工程，还固定了容器格式（TFRecord）与序列语义（feature_lists）。

1.2 三条常见的错误期待

第一条，期待它是 MIMIC-III 的另一种打包。它只包含住院时长满 24 小时的那部分住院，而且每条样本都在某个预测时点被截断。MIMIC-III 里那些时长不足一天的短住院、没有被映射进 FHIR 的字段、以及不属于住院级记录的字段，一条都不在这个库里。

第二条，期待它是时序生理信号。它的「序列」是事件的序列，不是波形的序列。每个时间步上是一次或几次离散事件（一条化验、一条医嘱、一段被分词的自由文本），数值型特征只占少数。想拿它做心电或呼吸波形的任务，方向就错了。

第三条，期待它能直接替代 MIMIC-III 做任何研究。四个任务文件夹共享同一批住院，但标签不同、截断时点不同、词表也不同。把它们拼起来当成「更多数据」会让同一次住院在训练集里出现四次，评估结果随之失真。

1.3 它能给到的与给不到的

你的需求	它给的	够不够
住院死亡预测的可复现基线	24 小时与出院两个时点的现成标签与序列	够，这是它最直接的用法
出院诊断的多标签分类	全部诊断的 ICD-9 码作为 context 标签	够做，但 ICD-9 编码体系本身已退场
主要诊断的粗粒度分类	CCS 分组，一份标签对应一个分组	够，且类别数远少于 ICD-9
从零设计特征工程	不提供，特征口径已固定	不够，要改就得回上游重做
波形或影像任务	不含任何波形与影像	不够，一条都没有
短住院或急诊留观研究	只收 ≥24 小时住院	不够，直接被排除在外
文本模型预训练	自由文本只以分词后的 token 序列存在	可做，但拿不到原文，无法做字符级或句法分析
跨机构泛化验证	单一医学中心、单一国家	不够，只能做时间外推不能做空间外推

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

你的处境	它能帮你什么	下一步该做什么
你要复现某篇用序列模型做死亡预测的论文，但作者的预处理代码没开源	提供一份口径明确的现成输入，可作为「作者可能这么做」的近似	先用它跑出量级，再逐项替换成论文描述的细节，记录每一步的差异
你在做一个新的 EHR 基础模型，需要快速验证想法	数据已成张量，省掉两周的 ETL	只在验证集上迭代，测试集留到最后一次性用
你在教临床机器学习，学生卡在数据清洗	四个任务的样本可直接进 `tf.data`，第一节课就能训练	用它的四个包讲「同一批住院、不同标签」的差别
你在评测自己写的预处理流水线	提供一组外部参照：同样的上游，别人的口径长什么样	对齐任务定义后比较，不要比较绝对指标
你要做 FHIR 相关的互操作实验	它是 MIMIC-III 经 FHIR 中转后的产物，特征名保留了 FHIR 路径	注意：只给结果不给映射代码，FHIR 资源本身不在包里
你在核对某份数据使用协议的边界	许可与 DUA 版本写得清楚，可与上游 MIMIC 对照	先办 CITI 与 DUA，再谈技术细节

1.5 一句话判断

它不是更大的 MIMIC-III，而是一份「别人替你把预处理做完了」的 MIMIC-III：省下的时间是真的，被锁死的口径也是真的。

1.6 不适合谁：四条边界

不适合要改特征的人。 特征集合由上游流水线决定，词表以文件形式给出，能做的只有选择解析哪些键、丢掉哪些时间步。想加一个新特征，等于重跑整条 FHIR 流水线，而那套工具官方明确说没有公开。

不适合做原始文本研究。 自由文本在进入样本前已被分词，词表里只有 token 与它的出现次数。想找回原句、做命名实体识别或句法分析，必须回到 MIMIC-III 的 NOTEEVENTS 表。

不适合把四个包合并计数。 四个文件夹描述的是同一批住院的四种视图。把它们当作四份独立数据，会让患者级划分失效——同一个患者在四个包里都在训练侧，模型学到的是人，不是病。

不适合需要 2020 年之后口径的研究。 MIMIC-III v1.4 覆盖 2001 至 2012 年，诊断编码是 ICD-9。任何以 ICD-10 为前提、或以近年诊疗常规为前提的结论，都不能直接套用。

§2 数据构成与规格

2.1 四个文件夹，一套格式

库的顶层不是按患者或按年份分，而是按预测任务分。官方数据描述列出四个文件夹名，每个文件夹对应一个标签或预测任务：

文件夹	标签	预测时点	标签体系
`in_hospital_death_at_24hrs`	住院死亡	入院后 24 小时	二分类
`in_hospital_death_at_end_of_encounter`	住院死亡	出院时	二分类
`inpatient_icd9_at_end_of_encounter`	全部出院诊断	出院时	ICD-9 多标签
`primary_ccs_at_end_of_encounter`	主要出院诊断	出院时	CCS 单标签

四个文件夹的内部结构一致：一组 TFRecord 文件，加一份词表 ZIP。文件夹之间的差别，官方归纳为两处：标签不同；预测时点不同，超过该时点的本次住院数据会被丢弃。这句话值得反复读：它不是把数据过滤掉，而是把时间轴截断。同一次住院在两个包里都出现，但 24 小时包里的样本在入院第 24 小时处戛然而止，出院包里的样本则延伸到出院。

按任务分文件夹、而不是在一张表里塞多列标签，是一个有意为之的取舍。同一条住院若要同时承载四种标签，就得在每次建模时手动挑出哪一列算标签、哪一列必须屏蔽；一旦写错，标签会从 context 泄漏进特征。分成四个独立文件夹之后，每个包内部只有一种标签语义，泄漏的可能性被结构性地排除了。代价是磁盘上存了四份高度重叠的数据，以及任何跨任务的分析都要自己做样本对齐。

还有一处容易漏掉的差别：primary_ccs_at_end_of_encounter 剔除了 1.3% 的住院，理由是这些住院的主要诊断对应不可计费的 ICD-9 码，无法映射到 CCS 分组。这是全库唯一一处官方给出的剔除比例，其余三个包没有这类剔除。

2.2 SequenceExample 的两半：context 与 feature_lists

tf.SequenceExample 是 TensorFlow 早期为序列任务设计的协议缓冲，结构上只有两块：context 与 feature_lists。理解这两块的分工，基本就理解了这个库的全部设计。

组成部分	类型	装什么	在本库中的例子
`context`	`map<string, Feature>`	整条样本只有一个值的特征	患者编号、性别、出生日期、预测时点、标签
`feature_lists`	`map<string, FeatureList>`	随时间变化、每个时间步可能有零个或多个值的特征	化验值、用药剂量、分词后的文本

官方对稀疏性有一句关键说明：在任意给定时间步上，一个 feature_list 可能有很多值，也可能一个值都没有。这句话决定了解析代码的写法——不能假设所有特征在每个时间步都对齐，必须先把所有特征的事件时间收集起来，形成统一的时间轴，再按时间轴去做聚合或嵌入。这也解释了为什么库里要单独给一个 sequenceLength：它是「不同事件时刻的个数」，也就是时间轴的刻度数。

2.3 字段字典

官方使用说明把可用特征分成输入特征与元数据两组，并明确列出哪些应当作为 context、哪些应作为序列。下表把这些说明逐项落到字段上。需要说明：完整特征清单在词表目录内，需凭证登录后才可枚举，下表只覆盖官方页面点名的那部分。

字段	归属	取值形态	含义	使用注意
`patientId`	context	字符串	患者在样本中的唯一编号	同一患者可出现在多条样本里，切分必须按它
`currentEncounterId`	context	Unix 秒	本次住院的起始时刻	官方描述为「当前住院开始的时间戳」
`timestamp`	context	Unix 秒	预测时点，即序列的结束时刻	与标签时间戳相减可得前置窗口
`label.*.timestamp_secs`	context	Unix 秒	标签发生时刻	前缀固定，后缀随任务变化
`eventId`	序列	Unix 秒数组	每个事件的时刻	与 `sequenceLength` 一一对应
`sequenceLength`	context	整数	不同事件时刻的个数	是时间轴长度，不是特征总数
`Patient.birthDate`	context	时间	出生日期	与 `timestamp` 相减得到年龄
`Patient.gender`	context	字符串	性别	离散值，走词表
`Observation.value.quantity.value`	序列	浮点	化验或生命体征的数值	必须与 `Observation.code`、`.unit` 联用才有意义
`Observation.code`	序列	token	测量项目	走词表，具体码值在词表文件内
`Observation.value.quantity.unit`	序列	token	计量单位	同上
`MedicationAdministration.dosage.dose.value`	序列	浮点	实际给药剂量	与途径、部位、单位特征联用
`MedicationAdministration.dosage.rate.quantity.value`	序列	浮点	给药速率	常用于泵入类医嘱
`MedicationRequest.dosageInstruction.dose.quantity.value`	序列	浮点	医嘱剂量	与给药记录不是同一件事
`MedicationRequest.dosageInstruction.dose.range.low.value`	序列	浮点	剂量区间下界	与上界成对出现
`MedicationRequest.dosageInstruction.dose.range.high.value`	序列	浮点	剂量区间上界	同上
`Composition.section.text.div.tokenized`	序列	token	自由文本的分词结果	官方举的例子，原文不可得

字段名本身就是一份设计文档。它们全部是 FHIR 的资源路径：Patient、Observation、MedicationAdministration、MedicationRequest、Composition 都是 FHIR 的资源类型，后接的每一段是该资源里的元素路径，最后一段是字段。看到 Composition.section.text.div.tokenized 就该明白：临床文书在 FHIR 里被组织成 Composition 资源，正文落在 section.text.div，再被分词成 token。

这种命名方式还带来一个隐性约束：特征的含义由它在 FHIR 中的位置决定，而不由 MIMIC 的 ITEMID 决定。同一种化验在 MIMIC 里可能对应多个 ITEMID（不同系统、不同年代的录入习惯），一映射到 Observation.code 就合并成了一个概念。合并的好处是跨年代可比，坏处是原本的细粒度差异被抹平，而且这个合并过程只在映射工具里，使用者看不到合并表。

2.4 一条样本的完整解剖

把上述字段串起来，一条样本的形状是这样的：context 里有患者编号、性别、出生日期、预测时点、时间轴长度和标签；feature_lists 里有若干条长度不等、彼此不对齐的事件流，它们共享 eventId 这条时间轴。官方给出的语义是「一位患者的这次住院、以及此前所有住院」的历史，截至某个时点，超过该时点的数据被丢弃，时点之后发生的事情由标签描述。

这条设计里有两个值得单独拎出来的决定。

第一个是历史拼接。样本不只含本次住院，还含同一患者既往住院的全部数据。这让模型能看到「这个人上次因为什么住进来、用过什么药」，而不是只看当前这一段。代价是样本长度分布差异极大：一次住院的患者可能只有几十个时间步，反复入院者可能有几百个。

第二个是时间戳的绝对化。官方明确说所有时间与日期特征都以 Unix 时间戳的秒数给出。这意味着跨样本的时间对齐是显式的，也意味着任何「距入院多少小时」的派生量都要由使用者自己用 timestamp 与 currentEncounterId 相减得到，库里不预先算好。

读取骨架如下。这段代码不依赖任何私有工具，只用到 TensorFlow 自带的解析原语：

import tensorflow as tf

#-- 一条样本的解析骨架：context 与 feature_lists 分开取
def parse_one(path, int_keys, byte_keys, seq_keys):
    ds = tf.data.TFRecordDataset([path])
    for raw in ds.take(1):
        ex = tf.train.SequenceExample.FromString(raw.numpy())
        ctx = ex.context.feature            #-- map<string, Feature>
        fl  = ex.feature_lists.feature_list #-- map<string, FeatureList>

        meta = {k: ctx[k].int64_list.value[0] for k in int_keys if k in ctx}
        meta.update({k: ctx[k].bytes_list.value[0].decode("utf-8") for k in byte_keys if k in ctx})
        lens = {k: len(fl[k].feature) for k in seq_keys if k in fl}
        return meta, lens

#-- 词表是按特征名切分的，文件名就是特征键
def load_vocab(zip_path, feature_key):
    import zipfile
    with zipfile.ZipFile(zip_path) as z:
        name = f"{feature_key}.txt"
        toks = z.read(name).decode("utf-8").splitlines()
    return {t: i for i, t in enumerate(toks)}

第二段函数说明了一个容易被忽略的事实：词表文件名与特征键同名。想知道某个包里有哪些离散特征，列出 ZIP 内文件名即可，不必逐条解析二进制。

2.5 词表与 token

每个任务文件夹附一份 ZIP，内含两类文件，命名规则一致：

文件名形态	内容	用途
`{特征名}.txt`	该特征的全部 token	建索引、确定嵌入表大小
`{特征名}_freqs.csv`	每个 token 在数据中出现的次数	判断哪些 token 值得保留
`Composition.section.text.div.tokenized.txt`	自由文本的 token 表	文本特征专用，体量最大

这套设计把「特征」与「词表」绑在一起：特征名既是 feature_lists 的键，也是词表的文件名。好处是自解释，坏处是强耦合——特征名一变，词表文件名跟着变，任何按名字硬编码的脚本都会断。官方给出的频率文件是让人做取舍用的：低频 token 是否合并进 <unk>、过长的文本词表是否截断，都由使用者决定，库本身不做裁剪。

2.6 四个任务之间的差异矩阵

维度	24 小时死亡	出院死亡	出院 ICD-9	主要诊断 CCS
预测时点	入院后 24 小时	出院时	出院时	出院时
标签数量	1 个二值	1 个二值	多个诊断码	1 个分组码
标签所在位置	context	context	context	context
剔除规则	无额外剔除	无额外剔除	无额外剔除	剔除 1.3% 不可计费主要诊断
序列长度	短，止于第 24 小时	长，覆盖全程	长，覆盖全程	长，覆盖全程
典型任务	早期预警	结局预测	多标签分类	单标签分类
类别不平衡	严重	严重	不适用	中等

矩阵里最容易看错的是第一列与第二列的差别。两个包都预测住院死亡，但一个在 24 小时处下判断、一个在出院时下判断。前者要求模型在信息极少时给出结论，后者几乎等于「事后归因」。把它们当成同一个任务的两个副本，是最常见的误用。

§3 它是谁的数据

3.1 三个人与一个部门

制作者三人全部隶属 Google Health：Jonas Kemp、Kun Zhang、Andrew Dai。这份数据的由来不是一次独立的数据收集，而是一篇论文的副产物——官方背景段写明，这个版本的数据被用于产生 Kemp 等人发表的结果。换言之，它先是一份研究用的中间产物，后来才被整理成公开资源。

三个人的位置可以从参考文献里读出来：Kun Zhang 与 Andrew Dai 都在 Rajkomar 等 2018 年那篇方法学论文的作者名单中，Andrew Dai 同时是 2019 年那篇应用论文的合著者；Jonas Kemp 是 2019 年论文的第一作者，也是本库在 PhysioNet 上的第一署名。致谢中出现的工程与临床人员，则对应流水线落地时必不可少的那些角色：数据接入、临床语义核对、基础设施。

致谢名单列了十五位贡献者或支持者，包括 Greg S. Corrado、Claire Cui、Michael D. Howell、Alvin Rajkomar、Mimi Sun 等人。这份名单与谷歌健康当时做 EHR 序列模型的那条线高度重合，也解释了为什么这套流水线的形态与 Rajkomar 等 2018 年那篇 npj Digital Medicine 论文几乎一致——官方方法段承认，这套方法论最早就是在那篇论文里描述的。

利益冲突一栏只有一句话：谷歌支持了这份资源的创建。这句话应当被认真对待：它说明这套数据的加工与工程投入由一家商业机构承担，而原始采集、去标识化与托管责任仍在 PhysioNet 与上游 MIMIC 项目一侧。

3.2 时间线

时间	事件	意义
2001–2012	上游数据采集期	覆盖 MIMIC-III 的全部住院年份
2016-09-02	MIMIC-III v1.4 发布	本库的唯一上游
2018	Rajkomar 等发表 FHIR 序列化方法	本库的方法学出处
2019	Kemp 等人的预印本	本库数据的首次使用场景
2020-09-29	本库 1.0.0 发布	至今唯一版本
2020 至今	无更新	上游已迭代到 MIMIC-IV，本库仍停在 v1.4

3.3 上游 MIMIC-III v1.4 的形态

要判断这个库能不能用，得先知道它的原料长什么样。上游官方页给出的关键事实如下：

项目	内容
数据来源机构	波士顿贝斯以色列女执事医疗中心
覆盖年份	2001–2012
患者规模	超过四万名重症患者
表数量	26 张关系型表
主键层级	`SUBJECT_ID`（患者）、`HADM_ID`（住院）、`ICUSTAY_ID`（ICU 停留）
临床信息系统	CareVue 与 MetaVision 两套，采集期内先后使用
事件表组织	按 `ITEMID` 存放，含义需回字典表查询
访问方式	完成培训并签署数据使用协议后，从受限站点下载

二十六张表、三级主键、ITEMID 间接寻址——这三点合起来，就是「预处理为什么难」的全部答案。任何一条化验值都要三次连接才能追到它的名字与单位，而每一次连接都可能因为缺失键丢行。

3.4 数据来源的三个层次

第一层是原始临床记录：护士在床旁核对的生理测量、医生的病程记录、药房的医嘱与给药、检验科的回报。这一层不由本库负责。

第二层是关系型整理：MIMIC 项目把这些记录装进二十六张表，做去标识化、时间平移、日期偏移。这一层决定了本库能看到什么。

第三层是序列化封装：本库把表映射到 FHIR，再把 FHIR 展开成 SequenceExample。这一层决定了本库以什么形状交付。

三层之间的信息损耗是单向累积的。第一层里有的东西，第二层可能已经丢了（例如原始时间被平移）；第二层里有的东西，第三层可能不再保留（例如未被映射进 FHIR 的字段）。判断一个任务能不能用这个库，本质上是在问：我需要的信息，能不能撑过这两次转换。

§4 它最独特的东西

4.1 唯一一条公开的 MIMIC 到序列流水线产物

PhysioNet 上做 MIMIC 派生的项目很多：有抽特征的、有做子集的、有转 FHIR 的。但把「关系表 → FHIR → 序列样本」这条完整链路走完、并把结果公开的，只有这一个。这一点在方法段写得很清楚：先映射到 HL7 FHIR，再从 FHIR 转成 SequenceExample，用的是一条开源流水线；同时补了一句关键的限定——目前把 MIMIC-III 映射到 FHIR 的工具并未公开。

这句限定必须被记住。它意味着你拿到的是一张「成品照片」，不是「相机与胶卷」。照片可以看、可以量、可以用来训练，但想换一个角度重拍，得自己造相机。

4.2 两个预测时点乘三种标签

四个文件夹不是随意凑的，它们是一个二维设计的四个格子：预测时点有两档（24 小时、出院），标签有三种（住院死亡用两个时点覆盖、ICD-9 全部诊断、CCS 主要诊断）。这个设计让「同一批住院在不同信息量下的可预测性」变成一个可以直接对照的实验。

信息量	对应包	模型能看到的	临床上对应的场景
极少	24 小时死亡	入院后第一天	早期预警、分诊分流
完整	出院死亡	全程	结局归因、质量评价
完整	出院 ICD-9	全程	编码辅助、病案质控
完整	主要诊断 CCS	全程	粗粒度分组、医保分组预演

这个二维设计还有一个副作用值得记住：四个包共用同一批住院，但每个包内部的样本集合并不完全相同。CCS 包因为剔除了 1.3% 的住院，样本集比另外三个小一圈；24 小时包因为截断，样本内容比另外三个短一截。做跨任务对照时，正确的做法是先取交集，再在交集的住院上比较，否则差异里会混进样本集不同带来的噪声。

四格里最有意思的是左上角。24 小时意味着模型必须在信息最少的时候下判断，而这恰恰是临床上最需要预测能力的时刻——入住 ICU 的第一天决定后续资源投入。这个包的存在，让「早预测有多难」有了一个固定的测量刻度。

4.3 一条样本里装着多次住院

官方对这个设计的表述是：每条样本包含本次住院截至预测时点的数据，以及同一患者既往住院的全部数据。这一点与大多数 EHR 基准不同——多数基准是「一次住院一条样本」，本例是「一条样本 = 一个人的一段历史 + 一次住院的前半段」。

设计选择	常见做法	本库做法	后果
历史范围	只看本次住院	拼接全部既往住院	样本长度方差极大
时间基准	相对入院时间	Unix 绝对秒	需自行派生相对量
缺失处理	插值或前向填充	不填充，保留稀疏	解析代码必须容忍空时间步
事件粒度	按小时聚合	按事件原始时刻	时间轴长度随病情波动

第三行是最容易低估的。稀疏不是缺陷，是设计：它把「这个时间步没有测量」这一事实保留下来了。真正做聚合时，缺测本身往往是信号——一个六小时没有任何记录的时间段，与一个每小时都有记录的时间段，临床含义完全不同。

4.4 标签的粒度与口径

标签	粒度	体系	口径说明
住院死亡	住院级二值	院内死亡	24 小时包在入院第 24 小时下判断，出院包在出院时下判断
出院诊断	住院级多标签	ICD-9-CM	全部诊断码，数量随病例而异
主要诊断	住院级单标签	CCS 分组	由主要诊断映射而来，不可计费码被剔除

官方没有在页面上给出「24 小时死亡」标签的精确定义——是「入院 24 小时内死亡」还是「入院 24 小时后仍存活者的院内死亡」，从文件夹名无法判定。这是一个必须自己确认的口径，见 §10 的未核验清单。做早期预警研究时，这两种定义的临床含义差别很大：前者包含极早期死亡，后者把它们排除在队列之外。

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

住院时长门槛。 只收满 24 小时的住院。这条门槛会系统性地排除病情极轻（当天出院）与极重（24 小时内死亡）的两端。任何讨论「ICU 全人群」的结论，都要先扣掉这部分。

编码体系的时间边界。 ICD-9 在美国已于 2015 年停用。用这个库训练的编码模型，迁移到 ICD-10 环境需要重新建立映射与词表。

文本的可逆性边界。 文本已被分词，且只保留 token 与次数。需要原文的任务必须回上游。

地理与机构边界。 单一医学中心、单一国家、2001–2012 年的诊疗常规。跨机构泛化必须另找数据验证。

§5 怎么拿到：从 DUA 到张量

5.1 获取路径

步骤	做什么	大概耗时	产出
1	在 PhysioNet 注册账号	即时	账号
2	完成 CITI「Data or Specimens Only Research」培训	数小时	结业证明
3	签署 PhysioNet Credentialed Health Data Use Agreement 1.5.0	即时提交，审核需时	访问授权
4	通过审核后进入项目页下载	视带宽	四个文件夹
5	核对文件完整性	数分钟	可解析的 TFRecord 集合

上游 MIMIC-III 的申请流程在官方页上写明「批准至少需要一周」，本库沿用同一套访问要求。这一步没有捷径：数据里含受保护健康信息，凭证访问是硬门槛。

5.2 目录结构与文件命名

拿到之后，顶层只有四个文件夹，与 §2.1 的表一致。每个文件夹内是一组 TFRecord 与一份词表 ZIP。官方没有公布具体文件名与切分文件清单，也没有给出各包的体积；这些信息需登录后在文件列表里查看。本文不对未见过的文件名做任何推测。

5.3 用 tf.data 读 TFRecord

TFRecord 是按记录顺序拼接的二进制容器，读取时逐条解析即可。典型写法：

import tensorflow as tf

#-- TFRecord 是记录流，不必一次读入内存
files = tf.data.Dataset.list_files("in_hospital_death_at_24hrs/*.tfrecord")
ds = (tf.data.TFRecordDataset(files, num_parallel_reads=4)
        .map(tf.train.SequenceExample.FromString, num_parallel_calls=4)
        .padded_batch(32, padded_shapes=({}, {})))

这里还有一个常被忽略的细节：TFRecordDataset 的读取顺序与文件内的写入顺序一致，但文件之间的顺序不保证稳定。如果训练依赖样本顺序（例如在线难例挖掘），需要自己加一层固定种子的 shuffle；如果只做常规的随机批训练，shuffle 的缓冲区应不小于单个文件的样本量，否则同一个文件内的样本会成块出现。

padded_batch 是这段的关键。序列长度不一致，直接 batch 会在最后一步报错；填充到批内最长即可，但要注意填充值不能与真实 token 的索引冲突，通常把 0 留给填充、词表从 1 开始编号。

5.4 把序列摊平成张量

解析出 feature_lists 之后，真正的工程量才开始。官方给出的建议是：建模前先遍历数据集，把感兴趣的解析张量取出来看。这一步不能省——不同特征的时间轴对齐方式，决定了后续是用循环网络、Transformer，还是先做时间分桶再喂给树模型。

做法	优点	代价	适用
按 `eventId` 对齐后逐时间步嵌入	保留原始时序	实现复杂，需处理稀疏	序列模型
按小时分桶聚合	长度可控，便于批处理	丢掉桶内顺序	常规基线
只取统计量（计数、均值、末值）	最快，可接任意模型	丢掉时序	传统模型对照
取最近 N 个事件	长度固定，聚焦近期	长病史被截断	早预警任务

四种做法没有优劣，只有代价落在哪里。第一种最忠实，但对显存的要求随最长样本走：一批里只要有一条几百个时间步的样本，整批都要填充到那个长度。第二种把长度压到住院小时数，代价是把同一小时内的先后顺序抹平，而用药的先后有时正是关键。第三种最省，但把「什么时候发生」彻底丢掉了，之后无论怎么解释模型都无从谈起。第四种在早预警任务里最常见，因为它天然对齐了「只看今天之前」的临床逻辑。

5.5 词表对齐

词表是按文件夹给的，不是全库共用。原因很直接：不同任务的包可能包含不同的特征集合，词表必须与包内实际出现的键一致。硬编码一份词表跨包使用，会在遇到未见 token 时静默出错——多数实现会把未知 token 映射到索引 0，而 0 往往同时是填充位，错误就此被吞掉。

正确做法是把词表当作包的一部分来管理：加载哪个包，就加载同目录的 ZIP；建立映射时保留一份反查表，遇到未知 token 显式记录并计数。

5.6 六个最容易出错的地方

坑	现象	原因	处理
按样本随机切分	测试集指标虚高	同一患者的多条样本被分到两侧	按 `patientId` 分组切分
把四个包合并	同一次住院被计四次	四个包是同一批住院的四种视图	一次只用一个包
直接拿整数当数值	数值尺度错乱	部分字段是索引，部分是浮点	按字段类型分别处理
忽略时间截断	用到了预测时点之后的信息	只看了标签没看时间轴	用 `timestamp` 过滤事件
把 context 当序列	张量维度对不上	官方明确列了哪些属 context	按官方清单分组
词表跨包复用	静默产生未知 token	各包词表不通用	词表与包绑定加载

§6 与库内词条的关系

6.1 关系图谱

词条	关系	差异要点
MIMIC-III 重症监护临床数据库	直接上游	二十六张关系表，本库是它的序列化派生
MIMIC-IV 重症监护医疗数据库	同族更新版	覆盖年份更晚、结构重排，本库未跟进
MIMIC-IV on FHIR	同族、同方法、不同终点	那个停在 FHIR 资源层，本库继续压成序列样本
FIDDLE 重症 EHR 特征矩阵	同类目的、不同形态	那个产出特征矩阵，本库产出序列样本
MIMIC-IV-Ext-22MCTS	同类目的事件时间序列	那个是事件计数级长表，本库是协议缓冲
MIMIC-III-Ext-MIMIC-Patient	同类目的、逐患者组织	那个面向问答语料，本库面向预测任务
MIMIC-Ext-SynNotes	文本侧派生	那个生成合成笔记，本库只保留分词结果
CliniQ	检索基准	那个做实体检索评测，本库做结局预测

6.2 检索路径

如果目标是「拿一份能直接训练的 MIMIC 数据」，路径是：先确认任务是不是住院级预测；是，则本库、FIDDLE 特征矩阵、事件时间序列三者择一，按「要不要时序」决定；否，则回到 MIMIC-III 本体。

如果目标是「研究 EHR 预处理口径的影响」，路径是：以本库为固定口径，另建一套自己的口径，在同一批住院上对比。这时本库的价值不在数据，而在「一组已知的、不再变动的选择」。

如果目标是「教学」，路径是：用一个包的少量文件讲完「二进制容器到张量」的全流程，再用第二个包说明「同一批住院换标签会怎样」。这条路径不需要完整下载，也不需要训练出好结果，只需要解析成功，因此对本库的版本陈旧问题最不敏感。

如果目标是「FHIR 互操作」，路径是：MIMIC-IV on FHIR 给资源层，本库给「资源层之后」，两者恰好构成一条完整链路的两端。

6.3 分工判据

你的判据	选它	不选它
要马上训练，不想写 ETL	是	不适用
要自定义特征	不适用	回上游 MIMIC-III
要做波形或影像	不适用	换 MIMIC-IV-Waveform、MIMIC-CXR
要最新年份	不适用	换 MIMIC-IV 系
要可复现的基线数字	是	不适用
要研究预处理敏感性	是，作为对照组	不适用

§7 质量评估与局限性

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

本节不打「好用/不好用」的总分，只拆开五个可分别评价的维度：原料质量、转换保真度、标签可信度、文档完备度、可维护性。四者的证据强度差别很大——原料质量可以追到 MIMIC-III 的公开文档，转换保真度只能追到方法段的两句话，标签可信度取决于上游编码质量，文档完备度则是这个库最弱的一环。

7.1 五维评分

维度	评价	依据	强度
原料质量	高	上游 MIMIC-III 是经过长期检验的公开库	强
转换保真度	无法独立验证	映射工具未公开，只知先 FHIR 后序列	弱
标签可信度	中高	死亡与诊断均取自结构化字段	中
文档完备度	中	结构与语义写得清楚，规模与文件清单缺失	中
可维护性	低	单版本、六年未更新、上游已换代	强

第三行与第五行值得展开。标签的中高评价来自标签来源：住院死亡与出院诊断都是病案与 HIS 里的结构化字段，不是人工标注，也不依赖文本抽取。它们的误差主要继承编码质量，而不是本库引入的误差。可维护性的低评价则没有争议：一个 2020 年发布、此后没有任何版本记录的库，在上游已经迭代两代之后，只能作为历史基线使用。

7.2 标签的两层可信度

第一层是事件层：死亡这件事本身。医院内死亡在 HIS 里有明确记录，可信度高。但「出院后死亡」不在本库范围内——官方只承诺住院死亡，不做出院后随访。

第二层是编码层：诊断码由病案编码员在出院时填写，受编码规范、报销规则、个体习惯影响。ICD-9 的多标签尤其如此：同一次住院，不同编码员给出的码数可能相差数倍。CCS 分组是在此之上的再一次映射，把一个可能的编码噪声转成一个更粗的类别，噪声被压缩但也被固化。

7.3 已知的、可枚举的偏差

偏差	机制	影响方向
住院时长筛选	只收 ≥24 小时	排除极轻与极重两端
单中心	一家医学中心的诊疗常规	外推性受限
年代偏差	2001–2012 年的用药与监测习惯	与当代实践有差距
编码体系	ICD-9 已停用	迁移需重建映射
CCS 剔除	1.3% 不可计费主要诊断被去掉	主要诊断任务的类别边界被收窄
历史拼接	既往住院全部纳入	长病史患者样本更长，模型可能偏向他们
文本不可逆	只保留 token	依赖原文的任务无法做

前三行的偏差是这类单中心回顾数据的共性，无法通过换划分方式消除。第四行与第六行是本库特有的：编码体系决定了它与当代数据的接口必须经过一次映射，历史拼接决定了长病史患者在样本长度上的话语权更大。做长度归一化时，如果不区分「本次住院的事件数」与「历史事件数」，模型很可能学到「住院次数多的人死亡率高」这种相关性，而它在临床上并不构成可干预的因果路径。

这张表里唯一有官方数字的是第五行，其余都是结构性描述。结构性描述不需要统计支撑，只需要读文档；这也是本文只写这三类数字的原因。

7.4 外部验证矩阵

验证方式	是否可行	说明
同一库内换划分	可行	但必须按患者重切，否则与官方划分不可比
与 MIMIC-IV 对照	部分可行	需自行在 MIMIC-IV 上重建同口径流水线
与 MIMIC-IV on FHIR 对照	不可直接比	终点不同，一个是资源层一个是序列层
跨机构外部验证	不可行	本库只含单中心数据
时间外推	部分可行	上游只到 2012 年，无更晚数据

这张矩阵的读法是：五行里有三行只能打「部分」或「不可」。也就是说，任何想用它证明「模型能泛化到新医院」的研究，都缺一个关键环节。可行的替代是把本库当作预训练或超参数搜索的场所，把真正的泛化声明留给另一份多中心数据——这个分工比硬把单中心结果说成通用结论要诚实，也更容易被审稿人接受。

7.5 它为何仍需被引用

一个六年没更新、上游已换代的派生库，为什么还值得写进方法段？因为它提供了一个别处拿不到的东西：一组不再变动的预处理决定。在可复现性讨论里，「别人怎么切的」往往比「切得对不对」更重要。引用它，等于声明「我的输入口径与此一致」或「我以此为基线」。这两种声明都比「我们参照 MIMIC-III 自行处理」要精确得多。

§8 生态位与历史

8.1 沿革

这条线的起点是 2018 年那篇把 EHR 表示成 FHIR 再喂给深度模型的论文。它提出的关键主张不是某个网络结构，而是一个工程主张：把不同医院的异构数据先统一到 FHIR，再让模型只面对一种语法。这个主张在工业界很快被接受，因为它解决的是「每接一家医院就要重写一次 ETL」的成本问题。

2019 年，Kemp 等人把这条流水线用在临床文本上，做了分层患者分类与语言模型预训练。2020 年，作为那项工作的数据副产物，这个库被整理发布。所以它的血统很清楚：它不是为公开而生的数据集，而是一条产业流水线在公开数据上跑过一遍之后留下的痕迹。

8.2 与 Rajkomar 2018 的关系

维度	Rajkomar 等 2018	本库
目标	证明 FHIR 序列化 + 深度模型可行	把该流水线的产物公开
数据	两家医院的私有数据	公开的 MIMIC-III
输出	论文与结果	可下载的 TFRecord
代码	未公开	未公开

第四行是理解这个库的关键：方法公开在论文里，实现没有公开，只有产物公开。这决定了使用者只能在产物上做文章，不能改流水线。

8.3 生态位

需求层次	对应资源	本库位置
原始数据	MIMIC-III v1.4	上游
互操作层	MIMIC-IV on FHIR	平行分支
序列样本	本库	唯一公开成品
特征矩阵	FIDDLE 等	同类替代
事件长表	22MCTS 等	同类替代

8.4 谁在用

从引用结构推断（不是从使用统计推断），它的使用者集中在三类：一是做 EHR 序列模型、需要快速搭基线的研究组；二是讨论预处理可复现性的方法学论文，把它当作「已固定口径」的对照；三是医学信息学课程，用它演示「从表到张量」的完整链路。第三类的用法最不需要担心版本问题，因为教学目标不是最新数据，而是理解转换过程。

这三类用法背后有一个共同点：它的「可替代性」并不对称。作为序列样本，它很容易被自建流水线替代——只要愿意投入工程，任何人都能在 MIMIC-III 上重造一份同样形态的数据。作为「一组公开的、不再变动的预处理决定」，它几乎没有替代品：自建的口径再合理，也只是另一组选择，不能充当别人论文里的参照点。这种不对称解释了为什么它的下载量未必高，却在方法段里反复出现。

§9 使用指引

9.1 三种角色的路径

角色	第一步	第二步	注意
建模者	办访问、下一个包	用 24 小时死亡包跑通基线	不要一上来就合并四个包
方法学研究者	读方法段与词表结构	自建一套口径做对照	对照必须在同一批住院上做
教学者	挑一个包的少量文件	演示解析与词表加载	强调稀疏与时间轴

9.2 一条最短的可用流程

完成 CITI 培训，签署 DUA 1.5.0，取得凭证访问权限。
下载 in_hospital_death_at_24hrs 一个文件夹，先跑通解析。
用 SequenceExample.FromString 逐条读出 context，确认 patientId、timestamp、label 三类键存在。
列出词表 ZIP 内的文件名，确认特征键与 feature_lists 的键一致。
按 patientId 重做一次分组划分，与官方 80/10/10 对照，确认自己的实现没有泄漏。
用 §5.3 的 padded_batch 组批，先跑一个最简单的循环网络，拿到基线数字。
再换第二个包，比较同一模型在两个预测时点上的差距。

9.3 引用方式

项	内容
数据集引用	Kemp, J., Zhang, K., & Dai, A. (2020). MIMIC-III - SequenceExamples for TensorFlow modeling (version 1.0.0). PhysioNet. https://doi.org/10.13026/n2v5-5b32
上游引用	使用本库必须同时引用 MIMIC-III v1.4，官方在父项目一栏明确要求
平台引用	PhysioNet 平台综述论文，按官方 Cite 按钮生成
版本号	写 1.0.0，不要写 latest
划分说明	若自行重切，须写明与原划分的差异

§10 AI 使用声明

项目	声明
文本生成	本文由 AI 辅助撰写，编辑把关结构与事实
数字来源	规模、结构、边界三类数字取自 PhysioNet 官方页与上游 MIMIC-III 页面
文件核验	官方页与版本子页可直接访问；文件清单因地区限制与凭证要求不可见
不一致说明	上游患者规模的精确计数（Johnson 等 2016 给出的四万六千余人与五万八千余次住院）未在本次核验中从官方页复现，正文只采用「超过四万名」这一官方表述
论文信息	方法学出处与使用场景依据官方参考文献列表，未逐篇读全文
未核验内容	各包样本数量、文件体积、词表规模、24 小时死亡标签的精确定义
图像	无配图；封面为生成式提示词，不含真实病历内容
免责	本文不构成临床建议；数据使用须遵守 DUA 1.5.0 与上游许可

常见误读（避坑清单）

说法	实际	证据
「它是 MIMIC-III 的完整副本」	只含住院时长满 24 小时的部分，且每条样本在预测时点被截断	官方数据描述段
「它是波形时序数据」	是事件序列，不含任何波形	官方把所有特征描述为 FHIR 资源路径
「下载就能用」	仅凭证用户可访问，须 CITI 培训加 DUA 1.5.0	官方 Access 栏
「它和 MIMIC-IV on FHIR 是一回事」	上游不同、终点不同：那个停在 FHIR 资源层	两个项目的官方页
「四个包可以合并训练」	同一批住院的四种视图，合并即重复计数	官方说明四个文件夹仅标签与时点不同
「80/10/10 可以随便切」	官方按患者 ID 切	官方数据描述段
「标签是 ICD-10」	ICD-9，且 CCS 任务剔除 1.3% 不可计费码	官方数据描述段
「文件是 CSV 或 Parquet」	TFRecord，逐条为 SequenceExample	官方数据描述段
「它一直在更新」	只有一个版本，2020 年至今未变	版本历史仅 1.0.0
「里面附带 FHIR 原始资源」	只给转换后的序列样本，映射工具未公开	官方方法段
「词表全库通用」	每个任务文件夹各一份	官方数据描述段
「时间戳是相对入院的小时数」	全部是 Unix 秒	官方使用说明段

FAQ

Q1：它到底有多少条样本？
官方页没有给出数字，只说明了样本池是 MIMIC-III 中住院时长满 24 小时的全部住院，并给出了患者级 80/10/10 的划分比例。精确条数需要在取得凭证访问后清点文件或逐条计数。任何声称「约五万八千条」的说法都来自对上游住院数的直接套用，忽略了 24 小时筛选与截断规则，不应采信。

Q2：为什么它比 MIMIC-III 小这么多？
三个原因叠加：只保留住院级记录（丢掉 ICU 停留级的独立记录与未映射字段）、只保留满 24 小时的住院、只保留被映射进 FHIR 的字段。三次裁剪之后，剩下的是一份面向预测任务的窄表，而不是完整病案。

Q3：四个文件夹该用哪一个？
先问你的任务在临床上对应哪个时点。要早期预警，用 24 小时死亡包；要做结局归因，用出院死亡包；要做编码辅助，用 ICD-9 包；要做粗粒度分组，用 CCS 包。不要为了「数据多」而合并。

Q4：官方划分能直接用吗？
能，但要注意两点：一是官方只给了比例，没给划分清单，你得自己按 patientId 复现；二是如果你改了样本池（比如剔除某些住院），划分必须整体重做，不能沿用。

Q5：文本特征能还原成原句吗？
不能。库里只有分词后的 token 与它在词表中的位置，没有原始字符串，也没有标点与大小写信息。需要原文时必须回到 MIMIC-III 的 NOTEEVENTS 表。

Q6：能不能只用它的标签，输入自己造？
可以，这是它被低估的用法之一。四个包的标签口径清晰、时点明确，把标签取出来与本地的输入流水线对齐，等于借用了一份经过整理的监督信号。

Q7：为什么它不做 ICD-10？
因为它冻结在 MIMIC-III v1.4，而该库覆盖 2001–2012 年，那个时期美国用的是 ICD-9。后续的 MIMIC-IV 才提供 ICD-9 与 ICD-10 双版本。

Q8：它的许可能商用吗？
许可为 PhysioNet Credentialed Health Data License 1.5.0，附带数据使用协议。协议的核心约束是不得尝试重新识别个体、不得再分发原始数据。具体条款以官方许可全文为准，商业使用前应逐条核对，不要只看许可名称。

术语表

术语	解释
SequenceExample	TensorFlow 的序列样本协议缓冲，由 context 与 feature_lists 两部分组成
context	整条样本只有一个值的特征集合
feature_lists	随时间变化、每个时间步可有零到多个值的特征集合
feature_list	feature_lists 中的一条，对应一个特征随时间的变化
TFRecord	TensorFlow 的二进制记录容器，逐条顺序存储
FHIR	快速医疗互操作性资源，医疗数据交换的现代标准
资源	FHIR 中的基本数据单元，如 Patient、Observation
词表	离散特征取值到整数索引的映射
token	文本或编码经切分后的最小单位
CCS	Clinical Classifications Software，把 ICD 码归入粗类别的分组方案
ICD-9-CM	第九版国际疾病分类临床修改版，美国 2015 年前使用
主键	关系表中唯一标识一行的字段
HADM_ID	MIMIC 中标识一次住院的主键
预测时点	样本序列的截止时刻，此后信息不可见
截断	丢弃预测时点之后的数据
历史拼接	把同一患者既往住院的数据并入当前样本
患者级划分	同一患者的所有样本只进训练侧或只进测试侧
稀疏	特征在每个时间步上不一定有值
填充	组批时把短序列补到统一长度
凭证访问	需完成培训与协议后才能下载的受限访问方式
DUA	数据使用协议，规定允许与禁止的用途
CITI	研究伦理与受试者保护的培训课程体系

附录 A：核心数字核对表

项	值	来源
全名	MIMIC-III - SequenceExamples for TensorFlow modeling	官方页面标题
版本	1.0.0，唯一版本	版本历史栏
发布日期	2020 年 9 月 29 日	官方页面
DOI（本版）	10.13026/n2v5-5b32	官方页面
DOI（latest）	10.13026/6jx9-cy34	官方页面
预测任务数	4	数据描述段
划分比例	约 80% / 10% / 10%，按患者 ID	数据描述段
纳入下限	住院时长 ≥ 24 小时	数据描述段
CCS 任务剔除比例	1.3%	数据描述段
context 特征数	7 项	使用说明段
输入特征条目	4 组	使用说明段
元数据字段数	6 项	使用说明段
上游表数量	26 张	MIMIC-III 官方页
上游患者规模	超过四万名	MIMIC-III 官方页
上游年份跨度	2001–2012	MIMIC-III 官方页
参考文献数	5 篇	参考文献栏
致谢人数	15 人	致谢栏
许可	PhysioNet Credentialed Health Data License 1.5.0	访问栏

附录 B：数字的来源分层

第一层：官方页面明写。 四个任务文件夹、80/10/10 划分、24 小时门槛、1.3% 剔除、七项 context 特征、Unix 秒时间戳、许可与 DUA 版本、两个 DOI、发布日期、单版本事实。这些数字在正文中出现时都可回溯到官方页对应段落。

第二层：上游官方页。 二十六张表、超过四万名患者、2001–2012、CareVue 与 MetaVision 两套系统。这些来自 MIMIC-III v1.4 的项目页，不在本库页面上，引用时须写清是上游统计。

第三层：未核验。 各包样本数量、文件体积、词表规模、24 小时死亡标签的精确定义、官方划分的具体清单。这些信息要么因凭证限制不可见，要么官方本就没有公布。正文中凡涉及处均只做定性描述，并在 §10 列明。

附录 C：完整参考文献

编号	文献	链接	用途
1	本库官方页 v1.0.0	https://physionet.org/content/mimic-seqex/1.0.0/	全部结构、边界与许可信息
2	MIMIC-III v1.4 官方页	https://physionet.org/content/mimiciii/1.4/	上游规模与表结构
3	Johnson 等，MIMIC-III 论文（Scientific Data, 2016）	官方参考文献第 1 条	上游方法学背景
4	Rajkomar 等，npj Digital Medicine, 2018	https://doi.org/10.1038/s41746-018-0029-1	FHIR 序列化方法出处
5	Kemp 等，arXiv:1909.03039	官方参考文献第 4 条	本库数据的使用场景
6	MIMIC-Extract（官方参考文献第 2 条）	arXiv:1907.08322	同类预处理流水线对照
7	Sjoding 等通用化流程（官方参考文献第 3 条）	MLHC 2019	同类预处理流水线对照
8	PhysioNet 平台综述（2026，Nature Health）	https://doi.org/10.1038/s44360-026-00096-z	托管与引用规范

附录 D：任务代码

任务一：按患者重做分组划分

import tensorflow as tf
from collections import defaultdict

#-- 先扫一遍所有样本，只取 patientId，用于自己复现分组划分
def scan_patients(pattern):
    pids = []
    for raw in tf.data.TFRecordDataset(tf.io.gfile.glob(pattern)):
        ex = tf.train.SequenceExample.FromString(raw.numpy())
        f = ex.context.feature["patientId"]
        pids.append(f.bytes_list.value[0].decode("utf-8"))
    return pids

pids = scan_patients("in_hospital_death_at_24hrs/*.tfrecord")
uniq = sorted(set(pids))

#-- 以患者为最小单位切分，绝不按样本切
n = len(uniq)
train = set(uniq[: int(n * 0.8)])
val   = set(uniq[int(n * 0.8): int(n * 0.9)])
test  = set(uniq[int(n * 0.9):])

assert not (train & val) and not (train & test) and not (val & test)
print(len(uniq), len(train), len(val), len(test))

任务二：确认时间截断是否生效

import tensorflow as tf

#-- 序列里最后一个事件不应晚于 context 的 timestamp
def check_cut(path, k=200):
    bad = 0
    for i, raw in enumerate(tf.data.TFRecordDataset([path]).take(k)):
        ex = tf.train.SequenceExample.FromString(raw.numpy())
        ts = ex.context.feature["timestamp"].int64_list.value[0]
        ev = ex.feature_lists.feature_list["eventId"].feature
        if ev and ev[-1].int64_list.value[0] > ts:
            bad += 1
    return bad

print(check_cut("in_hospital_death_at_24hrs/part-00000.tfrecord"))

两段代码的用途不同：第一段防泄漏，第二段防越界。它们都不依赖任何私有工具，只用到 TensorFlow 自带的解析原语，可以在拿到数据的第一天就跑起来。文件名请以实际目录为准，本文不对未见过的文件名做推测。

附录 E：如果只记五件事

序号	记住什么	为什么
1	四个包，同一批住院，标签与时点不同	合并即重复计数，选包先选任务
2	按患者 ID 做 80/10/10	按样本切会让指标虚高
3	只收满 24 小时的住院，ICD-9 时代	决定了它能回答与不能回答的问题
4	TFRecord 里的 SequenceExample，context 加 feature_lists	解析思路由此确定
5	口径已冻结，改不动	当基线用最合适，当实验台不合适

编辑说明

本文的核验时间为 2026 年 10 月 28 日。核对方式为直接访问 PhysioNet 项目主页与 1.0.0 版本子页，逐段比对摘要、背景、方法、数据描述、使用说明、致谢、利益冲突与参考文献；文件清单一栏因地区限制与凭证要求返回不可用，故全文不对具体文件名、文件体积、样本数量做任何推测。上游数字另经 MIMIC-III v1.4 官方页核对。未覆盖的内容包括各包样本数量、词表规模、标签精确定义与官方划分清单，这些已在 §10 与附录 B 列明。