信息速览
重症医学的公开数据供给，二十多年里几乎由同一个名字撑着：波士顿贝斯以色列女执事医疗中心的真实住院与急诊记录，去标识之后交给全世界。它的组织方式也几乎一直是同一种——关系型数据库，几十张表，星形模式，主外键相连，研究者的第一道门槛是一句 SQL。而在医院与厂商那一侧，过去十年真正跑在生产系统里的交换语法却不是 SQL，而是 FHIR（Fast Healthcare Interoperability Resources，快速健康互操作性资源）：一套以 HTTP 为传输、以 JSON 或 XML 为序列化格式、把临床世界拆成「患者」「就诊」「观察」「医嘱」等资源的标准。两套语法之间长期存在一条无人填平的空缺：产业缺少一份足够大、足够真实、并且可以公开反复压测工具链的 FHIR 语料。合成数据做不了术语绑定的压力测试，几十例的演示数据压不出服务器端的批量导出瓶颈。
MIMIC-IV on FHIR 就是冲着这条空缺来的。它把一个十年的关系型病历库整体搬进 FHIR：24 个画像覆盖 MIMIC-IV 本体，另有 6 个画像覆盖急诊模块 MIMIC-IV-ED，术语取自 MIMIC 自己的码表，最终以 gzip 压缩的 NDJSON 分发。它的定位必须一开始就摆正：这不是一份新数据，而是同一份数据的另一种语法。患者还是那些患者，时间跨度还是 MIMIC-IV 与 MIMIC-IV-ED 所覆盖的那些年份，变化的只是每个字段的存放位置与名字。也正因为如此，它的价值不在「多了一大份训练样本」，而在「终于有一个真实规模的对象可以用来练习 FHIR」。
先看清全貌，再决定是否去排队办手续——一屏速览见下表。
| 维度 | 内容 |
|---|---|
| 全名 | MIMIC-IV on FHIR（官方页同时写作 MIMIC-IV-on-FHIR） |
| 发布方 | PhysioNet；制作方为七人跨国团队，来自多伦多病童医院、吕贝克大学、基尔大学、阿姆斯特丹 UMC、澳大利亚 CSIRO 与 MIT |
| 首次发布 | 2024 年 2 月 20 日，版本 1.0 |
| 当前版本 | 2.1，2024 年 11 月 12 日发布，官方定性为错误修正版 |
| 数据来源 | MIMIC-IV v2.2（住院与 ICU 模块）与 MIMIC-IV-ED v2.2（急诊模块） |
| 上游规模 | MIMIC-IV v2.2 含 299,712 名患者、431,231 次住院、73,181 次 ICU 入住；MIMIC-IV-ED v2.2 约 425,000 次急诊停留 |
| 画像数 | MIMIC-IV 侧 24 个、MIMIC-IV-ED 侧 6 个，合计 30 个 |
| 基础资源类型 | Condition、Encounter、Medication、MedicationAdministration、MedicationDispense、MedicationRequest、Observation、Organization、Patient、Procedure 等 |
| 术语资源 | 官方称实现指南含 64 个术语资源与 2 个扩展 |
| 对齐目标 | 尽量对齐 US Core v4.0.0，但画像并不显式继承自 US Core |
| 术语处理 | 刻意不做标准本体映射；实验室项目沿用原始 itemid，未使用 LOINC |
| 文件格式 | .ndjson.gz，每行一个 FHIR 资源的 JSON 序列化结果 |
| 关联代码 | kind-lab/mimic-fhir 仓库，静态版本归档于 Zenodo（DOI 10.5281/zenodo.14003175） |
| 许可与获取 | PhysioNet Credentialed Health Data License 1.5.0；须完成 CITI 培训并签署 DUA 1.5.0，仅凭证用户可下载 |
| DOI | 版本 2.1 为 10.13026/rrj1-ny66，latest 为 10.13026/9hhp-ps57 |
| 典型用途 | FHIR 服务器与 ETL 链路的真规模压测、跨机构数据协调方法研究、互操作工具的教学演示、本地画像与 US Core 的差异评价 |
§1 它要解决的具体麻烦
1.1 两种语法之间的十年空缺
FHIR 的设计前提是「现实世界的医院一定会偏离全球标准」。它用资源加画像的机制容纳这种偏离：基础资源给出人人一致的多数字段，画像负责在本院语境下裁剪与增补。这套机制在文档层面已经相当成熟——HL7 的规范、US Core 实施指南（由美国国家卫生信息技术协调办公室推动的 USCDI 标准落在 FHIR 上的实现约束），以及庞大的工具生态，共同构成了完整的说明书。
缺的是练习对象。一份能被反复使用的 FHIR 语料至少要在四个维度上足够真实：规模（行数量级足以触发批量导出与分页问题）、脏度（存在空值、不合规范的显示名、多余空格之类的小毛病）、密度（资源之间存在真实引用网络，而不是一堆孤岛文档）、术语（存在院内本地码表，而不是只有标准编码）。合成数据只能满足其中一部分；各家医院的演示服务器通常只有几十例；而真正跑在生产系统里的医院数据，绝大多数研究者一辈子也拿不到。
FHIR 工具链的很多失败模式只有在第四维上才会暴露：本地码值如何变成 CodeSystem（代码系统，术语的来源清单）与 ValueSet（值集，面向具体用例挑选出来的编码组合），绑定之后服务器如何校验，会不会因为一个多余空格或一条错误的显示名而拒绝整个资源。MIMIC-IV on FHIR 的价值恰恰在于它保留了这些难看的部分——制作方明确说，为了让 FHIR 中的内容尽可能完整，他们刻意不做标准本体映射：实验室项目保留原始 itemid，未使用 LOINC；只有在没有别的选择时才借用标准本体，例如用 SNOMED-CT 编码来标记急诊分诊事件的存在。这种把本地脏度原样搬进来的处理方式，让它比任何清洗过的演示数据都更接近工程师日后真正要面对的东西。
1.2 三条常见的错误期待
第一条，期待它是 MIMIC-IV 的完整替身。它的资源集合来自映射时的取舍，不是原始数据库的逐表复制；有些 MIMIC-IV 的内容必须塞进扩展（extension，FHIR 用于在标准元素之外承载信息的机制）才能存在。习惯了 SQL 的人会默认「凡是表里的列都能在资源里找到」，这个默认在这里不成立。
第二条，期待它的术语是标准术语。恰恰相反：因为刻意不映射，所以实验室项目是 MIMIC 的 itemid、药物是本院的配方码与 GSN（Generic Sequence Number，通用序列号）、诊断是 ICD-9 或 ICD-10 原码。想把它与另一家医院按 LOINC 或 SNOMED-CT 合并，映射这一跳必须由使用者自己补。
第三条，期待新版本带来新年份的数据。2.1 是错误修正版，官方发布说明把它的内容写成了一整张修正清单，涉及代码系统与值集的生成方式、显示名对齐、空值与单位合规处理等；底层源数据仍是 MIMIC-IV v2.2 与 MIMIC-IV-ED v2.2，没有新年份、也没有新患者。
1.3 它能给到的与给不到的
| 你的需求 | 它给的 | 够不够 |
|---|---|---|
| 真规模的 FHIR 服务器压测语料 | 每种资源一个 NDJSON 文件，资源间有真实引用网络 | 够，这是它最直接的用途 |
| 本地码表转 CodeSystem / ValueSet 的范例 | 术语从 MIMIC 表直接生成，并经服务器校验 | 够，且比演示数据更接近生产状态 |
| 本地画像与 US Core 差异的评价 | 画像尽量对齐 US Core v4.0.0 但不显式继承 | 够做差异清单，不够做合规认证 |
| 跨机构术语合并（如转到 OMOP） | 原始码保留在本地码空间 | 不够，标准本体映射这一跳要自己补 |
| ICU 波形、影像或自由文本 | 本项目不含这三类 | 不够，需回到对应的 MIMIC 子资源 |
| 新的建模样本 | 患者集合与上游一致，无新增人群 | 不够，它的增量是语法而不是样本 |
| NDJSON 读写与批量导出的教学 | 解压即可按行处理，不依赖服务器 | 够，是成本最低的入门路径 |
| 微生物检验链路的结构练习 | 一次检验拆成 Test→Org→Susc 三级父子资源 | 够练结构，但相当多的测试没有关联菌种 |
1.4 你的处境与它能帮到的事
| 你的处境 | 它能帮你什么 | 下一步该做什么 |
|---|---|---|
| 你在搭 FHIR 服务器，需要在真实体量上跑批量导出 | 提供真实的资源体量与引用网络，可直接灌入后做 Bulk Export 演习 | 先灌 Patient 与 Encounter 验证连通性，再逐资源灌入并记录校验报错 |
| 你在写本地码表到 CodeSystem 的转换脚本 | 它的码系统是直接从库生成、又经过服务器校验的成品 | 照代码仓库里 sql/codesystem/ 的思路改，先处理空值与前后空格再绑定 |
| 你在做跨库数据协调的方法学研究 | 同一份数据同时有 SQL 版与 FHIR 版，可做同题两套语法的一致性对照 | 先在两个版本上各跑一个最小队列定义，比较抽出的患者是否一致 |
| 你要教一门医疗互操作课程 | NDJSON 无需后端即可讲，概念可用真数据演示 | 用 §5.4 的按行读取方式做课堂练习，不必先起服务器 |
| 你在评估 US Core 的落地难度 | 画像对齐但不继承，差异逐条可见 | 以 ED 模块是否满足 FAIR 原则的既有评议为参照，列出你自己业务域的缺口 |
| 你只想用半小时判断它值不值得申请 | 官方页的背景与方法两段已给出全部关键信息 | 先读完 1.6 的边界与 §7 的局限，再决定是否排队申请 |
1.5 一句话判断
它不是给模型准备的新语料，而是给工具链准备的真考场：同一批被全世界研究透的患者，换了一套只有工业界在用的语法重新排版，并且把本地码表的脏活原样留了下来。
1.6 不适合谁：四条边界
不适合把它当作更多标签的来源。 上游患者本身就是公开数据，这张 FHIR 快照没有增加任何一位新患者。想用它改善模型表现的人会一无所获。
不适合需要标准术语的场景。 实验室码停留在本院 itemid，检验不用 LOINC，给药记录因空值较多而未用 NDC。任何以标准语义为前提的分析，都要先自建映射表。
不适合想要波形、影像或自由文本的团队。 这里只搬运结构化表格部分；波形在 MIMIC-IV Waveform，影像在 MIMIC-CXR，文本在 MIMIC-IV-Note，都是不同的资源。
不适合没有凭证的短期项目。 它需要 CITI 的 Data or Specimens Only Research 培训与 DUA 1.5.0 签署，流程以周计。用一个下午做原型验证的人用它不划算——先用演示版或合成数据把流程跑通，再回来申请。
§2 数据构成与规格
2.1 一次映射的五个步骤
制作方把整套工作拆成五步，这个拆分本身就是理解数据形态的钥匙。
第一步是术语生成（Terminology Generation）。MIMIC 的码值先从原始表里抽出，落成 CodeSystem 与 ValueSet 两类资源，再绑定到资源元素上。绑定关系不是装饰，而是 FHIR 服务器据以校验「这个元素上的编码是否合法」的依据——2.1 版的修正清单里，绝大多数条目都是绑定环节的错误修复。
第二步是实施指南创建（Implementation Guide Creation）。实施指南（IG）是把一批画像与术语打包、并发布成可浏览站点的容器。官方称 MIMIC 的 IG 含 22 个画像、64 个术语资源和 2 个扩展，并提供在线站点供逐一览阅。这里有一处数字上的不一致值得留意：摘要段说为 MIMIC-IV 造了 24 个画像、为 MIMIC-IV-ED 再造 6 个，而方法段说 IG 含 22 个画像（§7.4 专门核对这一处）。
第三步是映射（Mapping）。逐列检查 MIMIC-IV 的每一列，判断它能落到哪个 FHIR 元素上；写 SQL 把映射结果导出成 JSON；没有落脚处的列，就新建扩展承载。官方明确提醒，SQL 工具本身不保证导出结果符合 IG，所以映射之后仍要单独校验。
第四步是校验（Validation）。用真实 FHIR 服务器跑校验，用来发现术语绑定、资源互引、元素映射上的问题——它相当于给这套映射写的单元测试。
第五步是导出（Export）。先用 FHIR 服务器的批量导出功能把资源整体拉出，再按 NDJSON 格式落地，最后 gzip 压缩。官方还补了一句重要的技术注记：第四步与第五步是为了保证产物符合公开发布的实施指南，理论上完成第三步映射之后，也可以直接从源库导出 NDJSON。
| 步骤 | 输入 | 产出 | 使用者最该关心的点 |
|---|---|---|---|
| 术语生成 | MIMIC 各表的本地码值 | CodeSystem 与 ValueSet 资源 | 码表是本院的，不是 LOINC 或 SNOMED-CT |
| 实施指南创建 | 画像与术语 | 一份可浏览的 IG | 画像与 US Core 对齐但不继承 |
| 映射 | MIMIC 表的列 | SQL 脚本与 FHIR 元素的 JSON | 无处安放的列进了扩展 |
| 校验 | 生成好的 FHIR 资源 | 一份报错清单 | 2.1 版修的就是上一版的报错 |
| 导出 | 通过校验的资源 | .ndjson.gz 文件 |
每行一个资源，压缩后体积才可用 |
2.2 三十份画像的名册
官方用表 1 给出了 MIMIC 表到 FHIR 画像的近似映射，下面按模块重排，并保留每段 Notes 里的说明要点。
| 模块 | 来源 MIMIC 表 | 新 FHIR 画像 | 官方说明的要点 |
|---|---|---|---|
| hosp 患者追踪 | patients |
MimicPatient | 出生日期由 anchor_age 与 transfers.intime 推算 |
| hosp | admissions |
MimicEncounter | 住院就诊的主干资源 |
| hosp | transfers |
MimicEncounter、MimicLocation | 护理单元转成 Location 资源，被 Encounter 引用 |
| hosp | diagnoses_icd、d_icd_diagnoses |
MimicCondition | 结算诊断 |
| hosp | procedures_icd、d_icd_procedures |
MimicProcedure | 结算操作 |
| hosp | labevents、d_labitems |
MimicObservationLabevents、MimicSpecimen | 未使用 LOINC，术语就是原始 itemid |
| hosp | microbiologyevents |
MimicObservationMicroTest / MicroOrg / MicroSusc、MimicSpecimen | 一次微生物检验拆成三个 Observation，Test→Org→Susc 是父子关系 |
| hosp | prescriptions、poe |
MimicMedicationRequest | 处方表为主；有医嘱但没有可关联的 pharmacy_id 时退到 poe，如大量输液 |
| hosp | pharmacy |
MimicMedicationDispense | 药房发药 |
| hosp | emar、emar_detail |
MimicMedicationAdministration | 引用的药物主要是药名与配方码；因空值较多未使用 NDC |
| icu | icustays |
MimicEncounterICU | 所有 ICU 画像都指向它，它再回指住院 Encounter |
| icu | procedureevents |
MimicProcedureICU | ICU 床旁操作 |
| icu | inputevents |
MimicMedicationAdministrationICU | 输液类给药 |
| icu | chartevents |
MimicObservationChartevents | ICU 中记录量最大的来源 |
| icu | datetimeevents |
MimicObservationDatetimeevents | 时间型的观测，取的是日期时间值与项目码 |
| icu | outputevents |
MimicObservationOutputevents | 出量记录 |
| ed | edstays |
MimicEncounterED | 所有 ED 画像都指向它；若随后住院则引用那次住院 Encounter |
| ed | diagnosis |
MimicConditionED | 急诊停留结束时的结算 ICD 诊断 |
| ed | medrecon |
MimicMedicationStatementED | 用药重整，即来院前的服药史 |
| ed | pyxis |
MimicMedicationDispenseED | Pyxis 自动药柜的发药记录 |
| ed | triage |
MimicProcedureED | 官方把「接受分诊」这件事当作一次操作 |
| ed | vitalsign、triage |
MimicObservationED | 疼痛与心律的记录 |
| ed | vitalsign、triage |
MimicObservationVitalSignsED | 生命体征记录 |
| 全局 | 无对应表 | MimicOrganization | 全库只做一个，对应贝斯以色列女执事医疗中心 |
| 全局 | transfers 中的护理单元 |
MimicLocation | 每个唯一护理单元一个，共 41 个 |
名册之外还有两条容易被忽略的结构事实。其一，所有 ICU 画像都指向 MimicEncounterICU，而它反过来引用原始住院就诊的 Encounter；急诊同理，MimicEncounterED 若存在后续住院，会引用那次住院的 Encounter。于是「同一个人—同一次住院—同一次 ICU 入住—前一晚的急诊」这条链条，在 FHIR 里变成三次引用跳转，而不是 SQL 里的两次表连接。
其二，药物信息在 MIMIC-IV 里没有单一主表。官方从七个来源拼出 MimicMedication：处方表的配方码、GSN 与通用药名，emar 的 medication 列，emar_detail 的配方码，ICU 的 d_items，poe 中 order_type 为 IV therapy 或全胃肠外营养的静脉事件，以及由处方表来的药物混合物（Medication mixes，药房通常一起配发的药品组合）。之所以要单独处理混合物，是因为 FHIR 的 MedicationRequest 只允许引用一个 Medication，而 MIMIC-IV 里一次可以同时开多种药，于是这些成分被放进 ingredients 属性。
2.3 一个资源的解剖
NDJSON 中的每一行都是一个独立的 FHIR 资源。以 ICU 就诊为例，一个精简后的结构大致如下（为便于阅读做了换行与省略，实际文件里它被压成一行）：
{"resourceType":"Encounter","id":"<uuid>","meta":{"profile":["http://mimic.mit.edu/fhir/mimic/StructureDefinition/MimicEncounterICU"]},
"status":"finished","class":{"code":"..."},"subject":{"reference":"Patient/<uuid>"},
"partOf":{"reference":"Encounter/<uuid>"},"period":{"start":"...","end":"..."},
"location":[{"location":{"reference":"Location/<uuid>"}}]}
把它拆开理解：
| 元素 | 在这里的含义 | 读的时候要留心什么 |
|---|---|---|
resourceType |
资源的种类，如 Patient、Encounter、Observation | 分文件存放时它就是文件命名依据 |
id |
资源自身的 UUID | MIMIC 的整数主键不在这里，而被换成了 UUID（见 2.4） |
meta.profile |
声明它遵循哪个本地画像 | URL 以 mimic.mit.edu/fhir/mimic 开头，是按此定位 IG 的关键 |
subject |
指向 Patient 的引用 | 相当于 SQL 里的 subject_id 连接条件 |
partOf |
指向父级 Encounter | ICU 就诊的此项回指住院 Encounter，急诊同理指向住院或留空 |
period |
起止时间 | 日期已被上游去标识流程平移，不代表真实日历 |
location |
患者停留过的护理单元 | 每次跨病房转运产生一个 Location 引用，取值来自那 41 个 Location |
class / status |
就诊类别与状态 | 绑定到 MIMIC 自建 CodeSystem，不是标准全集 |
值得留意的是 Observation 家族在体量上的特殊位置：实验室检验来自 labevents，ICU 图表来自 chartevents，出量来自 outputevents，急诊体征来自 vitalsign。这是关系型明细表进入 FHIR 后的必然结果——一行明细就是一个资源对象，没有压缩，也没有分块。
2.4 主键与引用：subject_id 去了哪里
习惯了 SQL 的人最容易卡在这一步。MIMIC 的整数主键在 FHIR 版里被 UUID 取代，连接条件从「同一列名」变成「引用字符串」。
| 连接诉求 | SQL 里的写法 | FHIR 版里怎么做 |
|---|---|---|
| 找某个人的全部住院 | 按 patients.subject_id 过滤 |
先定位 Patient 资源，再按 Encounter.subject 反查该 UUID |
| 找某次住院的 ICU 入住 | 用 hadm_id 连接 icustays | 找 partOf 指向该住院 Encounter 的 ICU Encounter |
| 找某次急诊之后有没有住院 | 连接 edstays.hadm_id |
看 ED Encounter 的 partOf 是否指向住院 Encounter |
| 找某次就诊的全部检验 | 用 hadm_id 连接 labevents | 按 Observation.subject 过滤，再取 period 落在就诊时间窗内的行 |
| 找某个微生物检验的药敏结果 | 同一张表的多列 | 沿 Test→Org→Susc 三级引用逐级下钻 |
| 找某个病区的在院患者 | 连接 transfers |
用 Location 引用反查 Encounter |
这套转换的代价要在动手前想清楚：维度表消失之后，「按某个值等于常数」的查询变成了两次查找。想在 FHIR 侧抽出某个具体项目等于某个值的观测，得先查 CodeSystem 拿到对应编码，再按编码筛资源。批量分析更省事的做法是先把它灌进支持 FHIR 的分析引擎，或反扁平化回宽表，而不是逐行扫 NDJSON。
患者身份的另一处工程细节也值得一提。FHIR 的 Patient 资源要求出生日期，而 MIMIC 只给 anchor_age；官方的做法是用 transfers.intime 作基准推算出生日期，理由是 admittime 只对住院患者存在，会把只在急诊停留的人排除在外。性别通过 birthsex 扩展承载源库的 gender 列，因为源库没有专门记载出生性别。至于姓名，官方直接把 subject_id 拼成 Patient_<id> 形式的字符串——这不是漏做去标识，而是原本就不存在姓名字段。
2.5 术语来自哪里
FHIR 用两种资源装术语：CodeSystem 是编码的来源清单，ValueSet 是面向具体用例挑出来的一组编码。绑定（binding）之后，服务器就能校验元素上的编码是否合规。
| 术语去向 | 使用的编码体系 | 官方的态度 |
|---|---|---|
| 实验室检验项目 | MIMIC 原始 itemid | 明确未使用 LOINC，以免改动 MIMIC 的术语 |
| 微生物检验 | 本院的检验码、菌种码、抗生素码 | 同样保留院内码 |
| 诊断与操作 | ICD-9 与 ICD-10 原码 | 由结算数据得来，未做转换 |
| 处方药物 | 配方码、GSN、NDC（在 NDC 可用的场合） | 来源随表而异 |
| 给药记录中的药物 | 主要是药名与配方码 | 官方因空值较多而未采用 NDC |
| 急诊分诊的存在 | SNOMED-CT 码 | 这是少数不得不借用标准本体的例子 |
| 入院类别、入院类型、入院来源、出院去向 | MIMIC 自建 CodeSystem | 由 MimicEncounter 自定义绑定 |
| 单位 | 自建单位 CodeSystem | 2.1 版补进了 emar_detail 的两个单位列作为来源 |
这里最深的一层含义是：术语在 FHIR 里不是注释，而是可执行的约束。2.1 版的修正清单几乎全与术语绑定有关——单位来源缺失导致某个单位被判为未知编码；显示名与 CodeSystem 不一致导致整个资源报错；pharmacy.frequency 里多余的空格违反编码空白规则。这些错误单个看都很小，加在一起却能让一次全量导入失败。它存在的意义正在于此：让研究者在本地就能复现生产环境里才会出现的失败。
2.6 文件长什么样
按官方的说明，数据文件是带 .ndjson.gz 扩展名的压缩 NDJSON，每个文件中的每一行都是一个合法 FHIR 资源序列化后的 JSON。制作方选择 JSON 而非 XML 作为序列化格式，这一点在讨论 FHIR 时必须明示，因为两者的工具链并不通用。
资源按类型分文件，这一点可以从公开代码仓库的生成脚本名册看出来（sql/ 下的 fhir_patient.sql、fhir_encounter_icu.sql、fhir_observation_labevents.sql、fhir_medication_request.sql 等）。因此目录形态大致可以理解为「一个资源类型一个压缩包」，外加配套的代码系统与值集资源。
| 文件族 | 大致内容 | 备注 |
|---|---|---|
| MimicPatient / MimicOrganization / MimicLocation | 患者、机构与护理单元 | Organization 全局仅一个；Location 共 41 个 |
| MimicEncounter 系列 | 住院、ICU 与急诊的就诊资源 | 用 partOf 串起的主干 |
| MimicObservation 系列 | 实验室、微生物三级、图表、日期型、出量、急诊体征 | 明细行数最多的一族 |
| MimicCondition / MimicProcedure 系列 | 诊断与操作 | 含结算 ICD 与急诊分诊 |
| MimicMedication 系列 | Medication、Request、Dispense、Administration 及其 ED 与 ICU 变体 | 来源最杂的一族 |
| MimicSpecimen | 检验与微生物的标本 | 官方另为实验室侧做了独立生成脚本 |
| CodeSystem / ValueSet | 术语资源 | 自 2.1 版起由数据库的术语 schema 生成 |
需要坦白的一点：受访问政策限制，在某些网络环境下官方页的文件区会显示「Data is not available in your region due to legal or policy restrictions」，无法列出每个文件的行数与字节数。因此本节不写任何单文件规模数字——这类数字请在你自己取得凭证之后核对，相关的不确定性也列进了 §10 的未核验清单。
2.7 一张字段迁移对照表
关系型思维最常问的一句话是「那一列去哪了」。官方没有给出逐列的对照表，而是把答案放进实施指南；下面用几条最常见的列说明迁移的一般规律，具体哪一列落到哪个元素，请以官方在线站点为准。
| 关系型侧的写法 | FHIR 侧的落点 | 迁移时发生的变化 |
|---|---|---|
patients.anchor_age |
Patient.birthDate 经由推算 | 从整数年龄变成由入室时刻倒推的近似日期 |
patients.gender |
Patient 的 birthsex 扩展 | 从普通列变成扩展，FHIR 区分性别与出生性别 |
patients.subject_id |
Patient.id 与 identifier | 整数主键变成 UUID，另留一条可读标识 |
admissions.admittime / dischtime |
Encounter.period | 两列合并成一个含起止的结构 |
admissions.admission_type 等 |
Encounter 的本地绑定元素 | 取值被绑定到 MIMIC 自建 CodeSystem |
transfers.careunit |
独立的 Location 资源 | 字符串列被提升为一个可复用的资源 |
icustays.* |
Encounter（ICU 画像） | 又一次就诊，靠 partOf 挂在住院之上 |
chartevents.itemid / valuenum |
Observation.code 与 valueQuantity | 项目码保留了本地语义，值与单位合成一个结构 |
labevents.flag |
Observation 的解释（interpretation）元素 | 取值进入本地 CodeSystem 的绑定 |
microbiologyevents 的单行 |
三个 Observation 加有可能的 Specimen | 一行拆成父子三层的资源簇 |
prescriptions.drug 等一列多位 |
Medication 与 MedicationRequest 的组合 | 因为 MedicationRequest 只接受一个药物引用，混合物另做处理 |
emar_detail.product_code |
MedicationAdministration 的药物引用 | 缺失时由上一层表补齐，仍缺失则为 NULL |
poe 中的静脉事件 |
MedicationRequest | 无处方但有医嘱的场景从备用来源摄入 |
edstays.acuity 到 vitalsign.pain |
Observation 或 Procedure | 按语义被分到不同资源类型 |
这张表透出一条规律：列到元素的迁移不是一对一改写，而是语义重组。时间列会被合并成区间，分类列会被提升为术语绑定，字符串枚举则可能被提升为独立资源。理解了这一点，就不会再用「缺了哪一列」的思路去找数据，而是问「这类信息在 FHIR 里通常用哪种结构表达」。
§3 它是谁的数据
3.1 贡献者名单与国际分工
这是一份由七人团队完成的跨国协作，名单本身就说明了它的气质：它不是某家医院的信息科产物，而是一群既懂医疗信息学又蹲过 FHIR 社区的人的自发作业。
| 作者 | 所属机构 | 所在国家 |
|---|---|---|
| Alex Bennett | The Hospital for Sick Children, Toronto | 加拿大 |
| Joshua Wiedekopf | IT Center for Clinical Research, University of Lübeck | 德国 |
| Hannes Ulrich | Institute for Medical Informatics and Statistics, Kiel University / UKSH | 德国 |
| Philip van Damme | Amsterdam University Medical Centers | 荷兰 |
| Piotr Szul | Australian e-Health Research Centre, CSIRO Health and Biosecurity | 澳大利亚 |
| John Grimes | Australian e-Health Research Centre, CSIRO Health and Biosecurity | 澳大利亚 |
| Alistair Johnson | Massachusetts Institute of Technology | 美国 |
官方致谢部分把资金来源写在明处：加拿大卫生研究院（Canadian Institutes of Health Research）资助号 470397；同时致谢 MIMIC-IV 的制作者使数据可得，以及 FHIR 社区在答疑上的支持。利益冲突一栏写的是「None to declare」。对使用者而言，这份名单有两个实用含义：一是维护方分散在 FHIR 工具链活跃的地区（德国与美国医疗信息学主导，澳大利亚提供 Pathling 分析服务器），二是它没有来自源医院信息科的维护承诺，属于研究型产物的典型形态——更新节奏取决于这群人的时间。
3.2 时间线
| 时间 | 事件 | 对使用者的含义 |
|---|---|---|
| 2018 年 | Ververs 等人把 MIMIC-III 转成 FHIR 的工作发表 | 这条技术路线的最早尝试，规模限于 MIMIC-III |
| 2021 年 | Ulrich 等人发表把 MIMIC-IV 转成核心数据集的经验总结 | 德国语境下的第二次尝试，奠定了后续方法的雏形 |
| 2023 年 1 月 5 日 | MIMIC-IV-ED v2.2 在 PhysioNet 发布 | 急诊侧上游就位 |
| 2023 年 1 月 | MIMIC-IV v2.2 在 PhysioNet 发布 | 住院与 ICU 侧上游就位 |
| 2023 年 4 月 | Bennett 等人在 JAMIA 发表方法论文 | 方法有了同行评议版本，可正式引用 |
| 2024 年 2 月 20 日 | MIMIC-IV on FHIR v1.0 发布 | 首个可用版本，数据源为上游 v2.2 |
| 2024 年 | van Damme 等人在 JAMIA Open 发表急诊模块的 FAIR 评价 | 互操作性的外部评价出现 |
| 2024 年 11 月 12 日 | v2.1 发布，官方定性为错误修正版 | 当前版本，修的是 FHIR 校验中发现的一批问题 |
这条时间线透露出一个关键信息：上游已经停在 v2.2，后续 MIMIC-IV 的新版本不会自动同步进来。如果源数据将来升到更高版本，这一支 FHIR 产物是否跟进，取决于维护者是否重跑管线。
3.3 采集场景
数据的原始采集环境是美国波士顿的贝斯以色列女执事医疗中心（Beth Israel Deaconess Medical Center，BIDMC），一家三级教学医院。住院与 ICU 模块覆盖的时间跨度是 MIMIC-IV v2.2 的口径；急诊模块按上游官方摘要的说法，对应 2011 至 2019 年的急诊就诊。
去标识化依据 HIPAA 安全港条款执行，日期被整体平移，因此 FHIR 资源里的 period 与 effectiveDateTime 都处在平移后的时间轴上。派生出来的字段也带着这层痕迹：前文提到的出生日期是由 anchor_age 推算的近似值，而不是真实生日；名字直接由 subject_id 拼串而成。这两点决定了它不能用在任何需要真实日期语义的任务上——例如按季节分析发病、与公共卫生日历做对齐。
采集的第三个特征是单一中心。所有共享同一个 Organization 资源的做法，既简化了模型，也诚实地标出了边界：跨机构合并研究在这里做不了，除非引入第二个来源。
3.4 它在数据血缘里的位置
| 层级 | 内容 | 谁负责 |
|---|---|---|
| 源头 | BIDMC 的真实临床信息系统 | 医院 |
| 去标识层 | HIPAA 安全港去标识、日期平移 | MIMIC-IV 团队 |
| 关系型层 | MIMIC-IV v2.2（hosp / icu）、MIMIC-IV-ED v2.2 | MIT LCP 团队 |
| 语法层 | MIMIC-IV on FHIR v2.1 | 本文的七人团队 |
| 工具层 | 实现指南、代码仓库、Zenodo 静态归档、Pathling 教程 | 同一批作者及周边社区 |
理解这张层次表可以避免一类常见误会：它处在「语法层」，因此它的任何内容与上一层不一致时，改解释的主人永远是上游，而不是它自己。比如说某位患者的出生日期看起来奇怪，去查 MIMIC-IV 的 anchor_age 机制；说某个实验室项目码对不上 LOINC，那是设计如此。
§4 它最独特的东西
4.1 稀缺性：真实规模的公开 FHIR 数据极少
公开可得的 FHIR 数据大致有三类：厂商或标准组织的合成示例、搭载示例代码的几十例演示包、以及少数做过 FHIR 化的公开数据集。第一类永远不会有本地脏码，第二类撑不起批量导出压测，第三类数量稀少并且在近十年里几乎被反复引用同一批名字。
在这样一个稀缺格局里，它的独特之处集中在三个叠加条件上：体量足够大到能暴露工程问题（上游是近三十万患者的住院库与约四十二万五千次急诊停留），脏度没有被清洗掉（本地码表、空值、显示名不一致全在），以及它是可以合法下载、可以反复重跑、可以贴在论文里给出 DOI 的。三者叠加之后，它几乎是唯一能同时满足「真实」「大规模」「公开」的 FHIR 语料。
4.2 差异化：不映射是一条被写进设计的选择
绝大多数把数据搬进标准的工作，第一步是把本地码映射到标准本体。这一步一旦做了，数据会变得干净、可合并，但同时也失去了「本地码值在现实中常常与多个标准码之间存在一对多、多对一的错配关系」这一层真实。
它反其道而行：官方在摘要与方法两段两次强调不把 MIMIC 的概念映射到标准本体，除非不得已。于是：
| 常见做法 | 这里的做法 | 结果 |
|---|---|---|
| 实验室项目用 LOINC | 保留原始 itemid | 失去跨院可比性，换来院内的完整保真 |
| 药物编码用 RxNorm 或 NDC | 用本院配方码、GSN、通用名 | 同上 |
| 缺失就丢行 | 空值保留为 NULL 或进入扩展 | 让下游工具必须真正处理空值 |
| 与本地实践冲突时改数据 | 新建扩展承载本院字段 | 信息不丢，代价是非标准元素要多学一层 |
这个选择使它成为研究「从本地迁移到标准到底成本多大」的理想对象：所有难映射的点都被原样保留，做标准映射时的工作量因此可以被量化，而不是被事先抹掉。
4.3 具体案例：三处能看出作者用力的设计
微生物检验拆成三级。 一次 microbiologyevents 的记录在关系型库里是一行，在 FHIR 里则变成 Test、Org、Susc 三个资源，且构成 Test→Org→Susc 的父子引用链。之所以必须拆，是因为 FHIR 的 Observation 资源装不下「检验 + 菌种 + 药敏」这三层语义。官方还特别说明：相当数量的检验没有关联菌种，这些检验的结果只能从 comments 里取；而没有菌种生长的检验，自然不会拥有下级 Org 资源。
分诊被当作一次操作。 FHIR 的 Procedure 资源描述「对患者执行的动作」，于是 ED 里唯一目前存在的 ED 操作就是「提供了分诊」这件事，并用 SNOMED-CT 编码标记其存在。这是把流程事件塞进资源模型的一个教科书式妥协。
位置只有 41 个。 全院护理单元被提出来做成 41 个 MimicLocation 资源，患者的每次跨病房转运在 Encounter 的 location 元素里追加一个引用。这意味着「转科」这个关系型图层的时间序列属性，在 FHIR 版里变成了引用加分时段的复合结构。
4.4 标注与粒度
FHIR 版并没有额外的人工标注：它搬运的是上游已有的结构化内容，作者没有新增任何判读标签。因此标注粒度这个概念在这里等价于「资源的粒度」——一行关系型明细变成一个资源对象，粒度的粗细由源表决定，而不是由本项目的标注决定。这对使用者是个好消息：不会有隐藏的注释者间差异；也是个限制：任何想做 Clinical Judgment 研究的人，都得回到那些做了人工判读的衍生资源上去。
4.5 边界条件
| 边界 | 具体情况 | 触发的后果 |
|---|---|---|
| 上游版本冻结 | 只对齐 MIMIC-IV v2.2 与 MIMIC-IV-ED v2.2 | 上游后续版本的内容不会出现在这里 |
| 单一机构 | 全库一个 Organization | 做不了跨院泛化研究 |
| 只有住院就诊 | 官方明确指出 MIMIC-IV v2.2 内只有住院类就诊 | 门诊、随访、家庭病床的场景无法练习 |
| 不含波形、影像与自由文本 | 本项目只搬运结构化表格部分 | 多模态研究需另行组合其他资源 |
| 凭证墙 | 需培训、签署协议、区域限制 | 文件区在特定地区可能不可列 |
| 术语停在院内 | 未映射 LOINC / SNOMED-CT | 与标准语义研究的接口要自己造 |
§5 怎么拿到
5.1 获取流程
它不是开放下载资源。完整的流程是三段：注册并通过 PhysioNet 的凭证审核；完成 CITI 的「Data or Specimens Only Research」培训并提交证明；签署 PhysioNet Credentialed Health Data Use Agreement 1.5.0。三者齐备之后才能获得文件区的访问权限。许可条款为 PhysioNet Credentialed Health Data License 1.5.0，禁止再识别、禁止再分发是这类许可的通行约束。
| 步骤 | 你要做的事 | 常见卡点 |
|---|---|---|
| 凭证审核 | 注册账号、完成身份验证并说明所在单位 | 机构邮箱与身份证明材料不一致 |
| 伦理培训 | 完成 CITI Data or Specimens Only Research 课程 | 证书有效期与人 outro 信息要对应一致 |
| 签署协议 | 签署 DUA 1.5.0 | 部分机构要求内部伦理流程先行 |
| 下载 | 登录后访问带版本号的文件区 | 部分地区会返回区域不可用的提示 |
5.2 目录结构与批量下载
文件按版本号组织，https://physionet.org/content/mimic-iv-fhir/2.1/ 既是版生机根，也是你要递归抓取的目录。带凭证批量下载的标准做法：
#-- 递归抓取整个版本目录；--ask-password 避免密码进历史
wget -r -N -c -np --user <你的PhysioNet用户名> --ask-password \
https://physionet.org/content/mimic-iv-fhir/2.1/
#-- 只看某一类资源时，先列目录再定向抓取，别一次性拉全部
分段下载的价值在这里很实在：Observation 家族是大头，先把 Patient、Encounter、Location 三个骨架灌完，服务器就能跑起引用完整性检查，再补明细资源。
5.3 流式读取 NDJSON
NDJSON 的最大好处是不需要任何专用库：按打开 gzip、按行 json.loads 即可。
import gzip, json
from pathlib import Path
def iter_ndjson_gz(path, limit=None):
#-- 逐行产出，不把整个文件读进内存；Observation 类文件尤其重要
n = 0
with gzip.open(path, "rt", encoding="utf-8") as fh:
for line in fh:
line = line.strip()
if not line:
continue
yield json.loads(line)
n += 1
if limit is not None and n >= limit:
break
真正要小心的是三件事。其一，文件的每一行是一个完整资源，不要试图用 json.load 一次读整个文件——它不是 JSON 数组。其二，同一个患者的资源分散在不同文件里，跨文件串需要以 UUID 为键做一次索引。其三，日期字段全是字符串，解析后记得把它当作平移时间轴上的值，不要与外部日历对齐。
5.4 转成宽表：反扁平化的最小做法
多数分析还是要回到二维表。下面这段按「患者 + 就诊 + 观测」三层最小骨架抽取，可按需扩展字段：
rows = []
with gzip.open("MimicObservationLabevents.ndjson.gz", "rt", encoding="utf-8") as fh:
for line in fh:
res = json.loads(line)
#-- 只抽三种要素：谁、什么时候、测的什么码
rows.append({
"patient_uuid": (res.get("subject") or {}).get("reference"),
"encounter_uuid": (res.get("encounter") or {}).get("reference"),
"effective": res.get("effectiveDateTime"),
"code": (res.get("code", {}).get("coding") or [{}])[0].get("code"),
"value": res.get("valueQuantity", {}).get("value"),
"unit": res.get("valueQuantity", {}).get("unit"),
})
这段单层抽取会在 Observation 家族上产生很宽很长的表，如果内存吃紧，用 pandas 的 read_json(lines=True) 配 chunksize 分批处理，或直接落进列式存储。
5.5 灌进服务器：以分析服务器为例
官方教程选择 Pathling（一款面向分析的 FHIR 服务器）作为示范，理由是它支持直接加载 NDJSON 并且分析算子经过优化。教程仓库里同时提供了 docker-compose 编排，可在本地一键起服务。
#-- 示意：把若干 NDJSON 行合并成 FHIR Bundle 后 POST 到一个 FHIR 服务器端点
import json, requests
bundle = {"resourceType": "Bundle", "type": "transaction", "entry": []}
for res in iter_ndjson_gz("MimicPatient.ndjson.gz"):
bundle["entry"].append({
"resource": res,
"request": {"method": "PUT", "url": f"{res['resourceType']}/{res['id']}"},
})
if len(bundle["entry"]) >= 500:
requests.post("http://localhost:8080/fhir", json=bundle,
headers={"Content-Type": "application/fhir+json"})
bundle["entry"].clear()
跑这条链路时要把服务器的资源上限、超时与批量大小逐个试出来——这本身就是官方使用说明想让人练习的东西。此外还有一条值得注意的路线：把它接到 Google Cloud Healthcare API 之类托管服务上，代码仓库 gcp/ 目录给出了按包加载、按患者加载的示例脚本；教程仓库也提供了对应的笔记本。
5.6 五个坑
坑一：把 # 当成注释写到代码块之外。 在 Markdown 里顶格写井号会被渲染成标题，写 Hey––like 脚本注释请一律用 #--：既不会和标题语法打架，也方便后期全文替换检查。
坑二：以为 IG 里的画像数是 30。 摘要与方法的口径不一致（见 §7.4），引用时最好写明你采用的是哪个数字、来自哪一段。
坑三：按 NDJSON 的行序做连接。 NDJSON 里相邻两行之间没有任何顺序保证，患者与就诊的关系只能靠引用解析；试图用「上一行」「下一行」推断上下文会得到错的结果。
坑四：把 itemid 当成通用码。 它是 BIDMC 的内部项目码，只在 MIMIC 内部可解释。任何跨库对齐都要先落到标准本体。
坑五：忽略扩展里的字段。 没有标准落脚点的 MIMIC 列被放进了扩展；只读标准元素会造成系统性的信息丢失，尤其是检验优先级、稀释值、以及急诊侧的疼痛与心律记录这类细节。
5.7 版本差异：从 1.0 到 2.1 修了些什么
2.1 版官方定性为错误修正版，修正项几乎全部来自 FHIR 校验。把它们按类型归纳，可以直接当作「自己写 FHIR 转换管道时的检查清单」来用。
| 修正类型 | 官方列出的典型例子 | 给管道设计的提醒 |
|---|---|---|
| 术语来源补齐 | 补 emar_detail 的两个单位列作为单位 CodeSystem 的来源 | 术语系统的来源表要与数据同步发布，临时拼一半最容易漏 |
| 显示名对齐 | 修正多个代码系统的 display，消除「显示名不一致」报错 | 显示名与编码必须同源生成，不能手改一半 |
| 空值处理 | 空药品名按 NULL 处理；空 lab_VALUE 产出 NULL；空单位不再生成空对象 | 空值要在导出层明确翻译成 NULL，而不是空串或空字典 |
| 数值与单位抽取 | 改进从 fill_quantity 抽取数值与单位的逻辑 | 值与单位写在同一个字符串里的字段要专门解析 |
| 编码空白规范 | 去掉 pharmacy.frequency 里不符合空白规则的空格 |
编码类字段不能带前后空格 |
| 结构合法性 | 修正 dosageInstruction.timing 缺少 code 或 repeat 的问题 | 校验器会要求某些结构必须二选一存在 |
| 资源形状 | 去掉不必要的外层数组包裹；不再生成多余的代码系统与值集 | 单值元素不要包成数组 |
| 标准内建结构 | 血压类观测对空值的处理要符合血压多态结构的要求 | 复合观测（如血压）有专门的结构约束 |
| 序列化细节 | 把导出格式改为 csv，修复反斜杠转义问题 | 转义问题在 JSON 序列化边界最容易翻车 |
对使用者来说，这一节的价值在于：如果你的实验在某个环节撞到类似的报错，先确认自己拿的是 2.1 而不是 1.0——官方已经花了一个版本把这些坑填过一遍。
§6 与库内其他数据集的关系
6.1 关系图谱
它在谱系上属于 MIMIC 家族的「语法转换层」，既不新增人群，也不新增变量，因此与其他资源的关系主要是四种：上游、同层兄弟、互补模态、可替代 benchmark。
| 关系 | 资源 | 性质 | 判据 |
|---|---|---|---|
| 上游 | MIMIC-IV 临床数据库 | 同一批患者的 SQL 版本 | 想要任何一个原始列，都从这里找：MIMIC-IV 全球规模最大的重症监护公开数据集 |
| 上游 | MIMIC-IV-ED 急诊模块 | 急诊侧来源 | 急诊 2011–2019 年的停留：MIMIC-IV-ED 急诊科临床数据库 |
| 同层 | MIMIC-IV-Note | 同一家医院的另一个模态 | 自由文本病程，不在本资源内：MIMIC-IV-Note 去标识化临床自由文本语料库 |
| 同层 | MIMIC-CXR | 同一批患者的影像 | 影像及其报告另有一套标识体系：MIMIC-CXR 大规模胸片加放射报告多模态数据集 |
| 同层 | MIMIC-IV-ECG | 同一批患者的心电 | 十二导联波形，与FHIR 版无关：MIMIC-IV-ECG 院内十二导联心电图波形库 |
| 家族近邻 | MIMIC-IV 全量页面 | 上游的另一份库内说明 | 想核对 299,712 名患者等上游数字：MIMIC-IV 重症监护医疗数据库 |
| 替代 benchmark | 多中心 ICU 库 | 想要多机构泛化时才是替代 | 单中心是硬边界：eICU-CRD 多中心远程重症监护数据库 |
| 替代 benchmark | 荷兰 ICU 库 | 想要非美国人群 | 同上：amsterdamumcdb 阿姆斯特丹 UMC 数据库 |
| 方法学对照 | 标准 OMOP 化的 MIMIC | 想对比「另一种标准化路径」 | OMOP 与 FHIR 是不同的目标模型：MIMIC-BR 巴西 ICU 匿名化 OMOP 临床数据库 |
6.2 什么时候该换资源
| 你的目标 | 要不要用它 | 该换去哪 |
|---|---|---|
| 想学 FHIR、练批量导出、压术语绑定 | 要，这是库里最合适的选择 | 无需替换 |
| 想建 ICU 预测模型 | 不要，直接要 SQL 版 | MIMIC-IV 临床数据库或 eICU-CRD |
| 想做跨院泛化验证 | 不要，单中心 | eICU-CRD、HiRID、阿姆斯特丹 UMC 数据库 |
| 想做 NLP | 不要，没有文本 | MIMIC-IV-Note |
| 想做影像 | 不要，没有像素 | MIMIC-CXR |
| 想比较标准化路线的成本 | 要，正好是研究对象 | 与 OMOP 化的 MIMIC 家族资源对照 |
6.3 分工判据：一句话区分
SQL 版负责「把问题算对」，FHIR 版负责「把数据搬到另一个语法里还能活」。两者要回答的问题不同，不存在谁替代谁。
这条判据在写研究方案时很有用：如果你的创新点在模型或队列定义，用 SQL 版；如果创新点在数据的搬运、协调、互操作，才轮到它出场。
相关数据集导航
下表给出库内可直接跳转的相关资源，按「先上游、后同层、再替代」排列。
| 类别 | 资源 | 与它的分工 |
|---|---|---|
| 上游 · 住院与 ICU | MIMIC-IV 临床数据库 | 同一批患者的关系型版本 |
| 上游 · 全量说明 | MIMIC-IV 重症监护医疗数据库 | 上游总览与上下游关系 |
| 上游 · 急诊 | MIMIC-IV-ED 急诊科临床数据库 | ED 侧来源，约四十二万五千次停留 |
| 同层 · 文本 | MIMIC-IV-Note 临床自由文本语料库 | 自由文本，FHIR 版不含 |
| 同层 · 影像 | MIMIC-CXR 胸片与报告 | 影像模态 |
| 同层 · 心电 | MIMIC-IV-ECG 十二导联心电波形库 | 波形模态 |
| 替代 · 多中心 | eICU-CRD 多中心远程重症数据库 | 跨院泛化时用它 |
| 替代 · 欧洲队列 | HiRID 伯尔尼重症监护数据库 | 非美国人群 |
| 替代 · 荷兰队列 | amsterdamumcdb 阿姆斯特丹 UMC 数据库 | 非美国的 ICU 起点 |
| 方法学 · 另一种标准化 | MIMIC-BR 巴西 ICU 匿名化 OMOP 库 | OMOP 路线的对照 |
| 方法学 · 纵向基准 | EHRSHOT 纵向 EHR 少样本评估基准 | 另一种结构化 EHR 组织方式 |
| 近邻 · 单院区 covid 时代 ICU | NWICU 芝加哥多院区 ICU EHR | 时间更新的单中心 EHR |
§7 质量评估与局限性
7.0 前置校正：读之前必须先做的两件事
第一，明确它是派生产物而非独立观测。任何关于患者、住院、急诊的数字都应回溯到 MIMIC-IV v2.2 与 MIMIC-IV-ED v2.2 的官方说明，而不是从这里反推。
第二，明确「这里没有问题」不等于「FHIR 侧没有问题」。它的全部质量开销花在「忠实地翻译」上，翻译得再好也不会修正上游本身的偏差——上游写入不足（例如许多重大操作没有清晰记录）会原样保留。
| 前置校正 | 具体内容 | 不做会怎样 |
|---|---|---|
| 溯源 | 关键数字回到上游官方页核对 | 把上游限制误归给它 |
| 译惯 | 接受「同一个字段在新语法里换了名字」 | 误判字段缺失 |
| 时间语义 | 日期被整体平移 | 与外部日历对齐时结论作废 |
| 单中心认知 | 一个 Organization 资源 | 跨院结论不成立 |
7.1 五维评分
| 维度 | 评价 | 依据 |
|---|---|---|
| 数据真实性 | 高 | 源数据来自真实临床信息系统，去标识后平移发布 |
| 结构规范度 | 高 | 有实施指南、服务器校验、并且出过一个纯修错误的版本 |
| 术语可用度 | 中偏低（取决于要不要标准本体） | 刻意保留院内码，不做标准映射 |
| 获取便利度 | 低 | 需培训、协议与凭证，部分地区提示不可下载 |
| 分析便利度 | 中 | NDJSON 便于流式读，引用网络需自己解析 |
7.2 两层「正确性」
FHIR 版存在两层必须分别检查的正确性问题：
| 层 | 谁负责 | 怎么检查 |
|---|---|---|
| 翻译层 | 本项目 | 资源能否通过针对 MIMIC 实现指南的校验；2.1 版修的就是这一层 |
| 源数据层 | MIMIC-IV 团队 | 上游是否记录了这个事实、记录是否完整 |
把这两层混为一谈是最常见的阅读错误。举例来说，某个实验室结果看起来离谱，可能是 FHIR 映射把单位处理错了，也可能上游源头就是这个值；判断方法是拿同一 itemid 回 SQL 版对照。
7.3 可枚举的偏差
| 偏差来源 | 表现 | 应对 |
|---|---|---|
| 单一机构 | 一个 Organization，波士顿一家三级医院 | 不做跨院外推 |
| 只有住院场景 | 官方明确上游只有住院类就诊 | 门诊、随访、居家场景练不了 |
| 术语停在院内 | 未用 LOINC / 未用 NDC | 自己补标准映射 |
| 上游写入不足 | 一些重大操作没有清晰记录 | 以操作为基础的研究要谨慎 |
| 去重与清洗在上游完成 | 上游按主键去重 | 不要指望在 FHIR 侧再做一次 |
| 版本冻结 | 停在 v2.2 | 上游后续更新不会自动进来 |
| 区域可用性 | 部分地区返回不可下载 | 提前确认网络与政策环境 |
7.4 官方自己的数字打架
官方文本里有两处数字不能直接对齐，写证明材料或复现说明时务必标明你取哪一个：
| 位置 | 说法 | 差在哪 |
|---|---|---|
| Abstract | 为 MIMIC-IV 造 24 个画像，为 MIMIC-IV-ED 再造 6 个，合计 30 | 按目的分组的画像计数 |
| Methods（实施指南创建） | MIMIC 实施指南含 22 个画像、64 个术语资源、2 个扩展 | IG 内登记的画像计数 |
两者的差别可以理解为「做了 30 个，其中 22 个进了那份实施指南」。官方没有在页面对这一处做脚注，因此引用时请连同出处段落一起写。
类似的还有基础资源类型的清单：Data Description 段列出的基础资源不含 MedicationStatement，但后文确实描述了服务于急诊用药重整的 MimicMedicationStatementED。可以认为那份清单不是全集，按后文的资源说明为准。
7.5 外部评估与它为什么还在用
急诊侧的资源已经在 2024 年被第三方拿去做过 FAIR（Findable, Accessible, Interoperable, Reusable，可发现、可访问、可互操作、可复用）原则的评价，结论是这一转换提高了数据集在 FAIR 维度上的质量。这是它目前最有分量的一份外部背书，也解释了它为什么在资源发布后仍然值得使用：它提供的是一套经过外部审视的、可复用的转换方法，而不只是一堆文件。
至于它持续被使用的另一个原因更朴素——学术界需要一个真规模的 FHIR 语料，而这个位置长期空缺。在同等体量、同等真实度的替代方案出现之前，它是成本最低的选择：自带的实施指南、开源的生成脚本、可归档的版本，以及一个已经跑通的分析服务器教程，共同构成了完整的工作流，而不只是一堆下载链接。
§8 生态位与历史
8.1 一条不长的沿革
把 MIMIC 家族搬进 FHIR 的努力不是从 2024 年才开始的。2018 年德国团队发表了把 MIMIC-III 转成 FHIR 的工作；2021 年同一批作者中的几位发表了把 MIMIC-IV 转成德国医疗信息学倡议核心数据集的经验总结。这些前期工作在Background 段被官方列为背景文献，本项目是这条线的第三代：目标不再是服务于某一个国家的核心数据集，而是做一个可以直接对齐美国 US Core 的通用 FHIR 资源集。
| 阶段 | 目标语法 | 规模 | 服务对象 |
|---|---|---|---|
| 2018 年前后 | FHIR（德国语境） | MIMIC-III | 德国的核心数据集实践 |
| 2021 年前后 | FHIR（核心数据集） | MIMIC-IV 早期版本 | 同上，方法层面的经验沉淀 |
| 2024 年至今 | FHIR（对齐 US Core v4.0.0） | MIMIC-IV v2.2 + MIMIC-IV-ED v2.2 | 通用的互操作研究与工具测试 |
8.2 与挑战赛、榜单的关系
它不属于任何共享任务或挑战赛的产物，也没有官方榜单。这个缺席并不意外：FHIR 化的目的是让数据能流动，而不是让模型在同一份数据上比分高低。因此评价它的方式不是「某某任务上的分数」，而是「把同样的分析搬到新语法上要做多少额外工作」。
8.3 它占据的生态位
| 竞争者 | 强在哪 | 弱在哪 | 相比之下 |
|---|---|---|---|
| 厂商的合成示例数据 | 干净、随时可得 | 没有本地脏码、体量小 | 教学可以，压测不行 |
| 演示服务器上的少量实例 | 与服务器配套 | 只有几十例 | 跑不出批量导出瓶颈 |
| 云上的免费 FHIR 沙箱 | 免维护 | 数据不可下载、代码不可复现 | 做不了可重复实验 |
| 院内的真实 FHIR 出口 | 最真实 | 绝大多数人拿不到 | 可望不可即 |
| 它 | 真规模、可下载、有 DOI、有生成代码 | 单中心、术语停在院内 | 前三者的交集只有它能提供 |
8.4 谁在用
三类人是它的主要受众。第一类是互操作工程师：他们需要一份能让服务器、管道、术语服务都出错的真数据，以便把错误处理写成产品的一部分。第二类是方法研究者：数据协调、本地到标准的迁移成本、FHIR 分析引擎的评测，都需要把同一份数据用两种语法表示。第三类是教学者：一门讲 FHIR 的课程如果只有 PDF，学生不会真正理解什么是资源引用网络；用它可以在一节课里让学生亲手解开一条患者到 ICU 入住的引用链。
§9 使用指引
9.1 三种角色的最短路径
| 角色 | 第一步 | 第二步 | 第三步 |
|---|---|---|---|
| 互操作工程师 | 只灌 Patient 与 Encounter 两个文件进服务器 | 逐步加入 Observation 家族，记录校验报错 | 用 2.1 版的修正清单反推自己管道该加哪些检查 |
| 数据科学研究者 | 先取 SQL 版定义好队列 | 把队列的主键映射到 FHIR 的 UUID | 在两种语法上比对抽出人群是否一致 |
| 教学者 | 用少量 NDJSON 行讲资源结构 | 演示 Patient、Encounter、Location 的引用 | 再演示观测如何按 subject 与 period 汇聚到同一次就诊 |
9.2 最小的可复现流程
#-- 1) 取得凭证后递归抓取 2.1 版本目录
wget -r -N -c -np --user <用户名> --ask-password \
https://physionet.org/content/mimic-iv-fhir/2.1/
#-- 2) 先看骨架文件的首行，确认 meta.profile 里的画像地址
zcat MimicPatient.ndjson.gz | head -n 1
#-- 3) 建立 subject_uuid 到 subject_id 的映射，再串观测
import gzip, json
subj = {}
with gzip.open("MimicPatient.ndjson.gz", "rt", encoding="utf-8") as fh:
for line in fh:
r = json.loads(line)
ident = next((i["value"] for i in r.get("identifier", [])), None)
subj[r["id"]] = ident
9.3 引用方式
官方要求同时给三份致谢：本资源的版本引用、它的原始方法论文、以及 PhysioNet 平台的通行引用。此外别忘了官方明确要求引用上游——使用时应一并致谢 MIMIC-IV v2.2 与 MIMIC-IV-ED v2.2。
| 该引用什么 | 内容 |
|---|---|
| 资源本身 | Bennett, A., Wiedekopf, J., Ulrich, H., van Damme, P., Szul, P., Grimes, J., & Johnson, A. (2024). MIMIC-IV on FHIR (version 2.1). PhysioNet. RRID:SCR_007345. DOI 10.13026/rrj1-ny66 |
| 方法论文 | Bennett AM, Ulrich H, van Damme P, Wiedekopf J, Johnson AE. MIMIC-IV on FHIR: converting a decade of in-patient data into an exchangeable, interoperable format. JAMIA, 2023, 30(4):718-725 |
| 平台 | Pollard 等人关于 PhysioNet 的通行引用（Nature Health, 2026） |
| 上游 | MIMIC-IV v2.2（DOI 10.13026/6mm1-ek67）与 MIMIC-IV-ED v2.2（DOI 10.13026/5ntk-km72） |
§10 AI 使用声明
| 项目 | 说明 |
|---|---|
| 文本生成 | 全文由 AI 依据官方页面与示例代码仓库撰写，未经人工逐句复核 |
| 数字来源 | 全部规模、结构与边界数字来自 PhysioNet 官方页的 Abstract / Background / Methods / Data Description / Usage Notes / Release Notes 段，或来自官方引用的上游页面 |
| 文件核验 | 由于访问政策与区域限制，文件清单的具体行数与字节数未能核验 |
| 不一致说明 | 官方文本内部存在画像计数差异（30 与 22）与基础资源清单不完整，已在 §7.4 单独列出 |
| 论文信息 | 方法论文为 JAMIA 2023 年 30 卷 4 期 718-725 页；FAIR 评价为 JAMIA Open 2024 年 7 卷 1 期 ooae002 |
| 未核验内容 | 各 NDJSON 文件的行数、字节数、以及 Resource 级的时间跨度边界 |
| 图像 | 封面仅为生成提示词，未实际生成或核对视觉结果 |
| 免责 | 医疗数据的使用须遵守许可条款，不得用于身份再识别，也不构成任何临床决策依据 |
常见误读（避坑清单）
| 说法 | 实际 | 证据 |
|---|---|---|
| 它是 MIMIC-IV 的新版本 | 它是另一次语法重写，版本独立于上游 | 官方称其数据源为 MIMIC-IV v2.2 与 MIMIC-IV-ED v2.2 |
| 患者群体变大了 | 与上游完全一致，没有新增患者 | 上游 MIMIC-IV v2.2 的患者规模便是它的上限 |
| 检验项目用了 LOINC | 未使用 LOINC，保留原始 itemid | Data Description 明确写出 |
| 药物采用了 NDC | 给药记录因空值较多未采用 NDC | Data Description 明确写出 |
| 画像是 US Core 的子孙 | 尽可能对齐，但不显式继承 | Methods 段的实施指南创建部分 |
| 实施指南含 30 个画像 | 方法段写的是 22 个画像 | Methods 与 Abstract 的口径差异，见 §7.4 |
| 有波形和影像 | 三者都不在资源内 | Data Description 只列举了结构化表 |
| 下载是开放的 | 需培训、签署协议并凭证下载 | 官方 Access 段写明访问政策 |
| v2.1 增加了新年份 | 2.1 是错误修正版，修的是 FHIR 校验发现的一批问题 | Release Notes 的 Version 2.1 段 |
| 住院数据是真实日期 | 去标识流程已把日期整体平移 | 上游 HIPAA 安全港去标识的说明 |
| 它有几十家医院 | 全库只有一个机构资源 | Data Description 的 MimicOrganization 段 |
FAQ
它是 MIMIC-IV 的替代品吗？
不是。它承载的人群、变量、时间跨度都与关系型版本一致，差别只在语法。想要做统计分析或建模的人，直接用 SQL 更快；练 FHIR 工具链、或者研究本地到标准的迁移成本时才用它。
为什么连一个标准本体都不映射？这样不是更难用吗？
难用是代价，保真是目的。映射到 LOINC 或 SNOMED-CT 之后数据会变干净，但映射过程中的损失与歧义也随之一并被藏起来，使用者再也看不到本地实践与标准模型之间的落差。而这份落差正是它能提供的研究价值。
一份 NDJSON 到底有多大？
受访问政策限制，在某些网络环境下官方文件区会提示区域不可用，因此每个文件的行数与字节数无法在这里给出，请以你取得凭证之后的实际目录为准。这也是文中刻意不引用任何单文件体积数字的原因。
可以把它的供养服务器直接用于临床系统吗？
绝对不行。它是凭证墙之后的去标识研究数据，仅用于教育与科研用途。许可条款明确禁止再识别与再分发，也不会有任何临床可用性保证。
研究引用时最少要给几个文献？
四个：资源本身的版本 DOI、方法论文、PhysioNet 平台的通行引用，以及上游 MIMIC-IV 与 MIMIC-IV-ED 的版本引用。官方页面把这三份要求分别写在了不同位置，引用清单里不要漏掉上游。
术语表
| 术语 | 释义 |
|---|---|
| FHIR | Fast Healthcare Interoperability Resources，快速健康互操作性资源，面向交换的健康数据标准 |
| 资源（Resource） | FHIR 中临床实体的最小表示单位，如 Patient、Encounter、Observation |
| 画像（Profile） | 对基础资源的本地化约束，用于表达某个机构的实际用法 |
| 扩展（Extension） | 在标准元素之外承载信息的数据结构 |
| CodeSystem | 代码系统，某一编码体系的完整清单 |
| ValueSet | 值集，从若干 CodeSystem 中挑选出的、面向具体用例的一组编码 |
| 绑定（Binding） | 把 ValueSet 关联到资源元素上，使服务器可校验取值 |
| NDJSON | newline-delimited JSON，每行一个独立 JSON 对象的文本格式 |
| US Core | 美国 USCDI 标准在 FHIR 上的实现指南 |
| USCDI | United States Core Data for Interoperability，美国互操作核心数据集 |
| 实施指南（IG） | 把一批画像与术语打包发布的容器，通常带可浏览站点 |
| LOINC | 实验室观测标识符的逻辑命名与编码体系 |
| SNOMED-CT | 系统化临床医学术语集 |
| itemid | MIMIC 内部用于标识检验与图表项目的本地代码 |
| Bulk Export | FHIR 服务器按批量方式导出全部资源的标准操作 |
| BIDMC | Beth Israel Deaconess Medical Center，贝斯以色列女执事医疗中心 |
附录 A：核心数字核对表
| 数字 | 出处 |
|---|---|
| 版本 2.1，2024 年 11 月 12 日发布 | 官方页版本区与 Release Notes |
| 首个版本 1.0，2024 年 2 月 20 日发布 | 官方页版本区 |
| DOI 10.13026/rrj1-ny66（v2.1）与 10.13026/9hhp-ps57（latest） | 官方页 Discovery 区 |
| MIMIC-IV 侧 24 个画像、ED 侧 6 个画像 | 官方页 Abstract |
| 实施指南含 22 个画像、64 个术语资源、2 个扩展 | 官方页 Methods |
| Location 资源 41 个 | Data Description 的 MimicLocation 段 |
| Organization 资源 1 个 | Data Description 的 MimicOrganization 段 |
| 七位作者、六国机构 | 官方页作者列表 |
| 资助号 CIHR 470397 | 官方页 Acknowledgements |
| 上游 MIMIC-IV v2.2：299,712 名患者、431,231 次住院、73,181 次 ICU 入住 | MIMIC-IV v2.2 官方页 Release Notes |
| 上游 MIMIC-IV-ED v2.2：约 425,000 次急诊停留，2011–2019 年 | MIMIC-IV-ED v2.2 官方页 Abstract |
| 许可 PhysioNet Credentialed Health Data License 1.5.0 | 官方页 Access 区 |
| Zenodo 静态代码归档 DOI 10.5281/zenodo.14003175 | 官方页 References |
| 方法论文 JAMIA 2023;30(4):718-725 | 官方页原始论文引用行 |
导航说明：本篇面向医疗互操作与数据工程的从业者。若你的目标是单纯的临床建模，请从上游的关系型 MIMIC-IV 入手；若你的目标是练字典与工具链，顺着 §6 的关系图谱与相关数据集导航逐层走即可，注意所有 MIMIC 家族资源都要先通过凭证墙。
