MIMIC-IV 演示库 OMOP 版 — 一百人铺成标准表

重症监护数据这条路上长期并行着两套互不通话的坐标系。MIMIC 那一套是"家门口坐标"：表名叫 admissions、chartevents、labevents，主键是 subject_id、hadm_id、stay_id，化验项目靠 d_labitems 里的 itemid 认人，全球数万篇论文都写在这套坐标上，写熟了效率极高，换个库全部作废。OMOP CDM（Observational Medical Outcomes Partnership Common Data Model，观察性医疗结果合作组织通用数据模型）那一套是"通用坐标"：同样一句"某患者在某天被诊断了某事"，落到 condition_occurrence 表里，用什么编码由标准概念编号 concept_id 决定，不关心源头是哪家医院、哪套信息系统。通用坐标最大的好处是分析代码可以跨机构原样复用，最大的尴尬是它长期缺一份够分量的、能公开下载的 ICU 级实例来演示与教学——绝大多数 OMOP 实例都在各家机构防火墙后面，外人连表结构长什么样都看不到。

MIMIC-IV demo data in the OMOP Common Data Model 就是架在这两套坐标系之间的一座桥，而 MIMIC-IV 演示库 OMOP 版是它在中文语境里最直白的叫法。它把 MIMIC-IV 演示子集中的 100 名患者搬进 OMOP 的表结构，交付物分成三块：OMOP 表的 CSV、Achilles 数据刻画的 JSON、OHDSI 数据质量看板（Data Quality Dashboard，DQD）的 JSON。它由九位作者署名，2021 年 6 月 21 日发布在 PhysioNet 上，唯一的版本号是 0.9，按 ODbL 1.0 免申请开放——既不用修 CITI 课程，也不用签数据使用协议。

它的定位极其克制，克制到把短板直接印在页面上：自由文本病历未填充，inputevents 与 outputevents 两张重症输入输出表尚未纳入转换，部分 MIMIC 概念没有充分映射到标准概念，emar 与 emar_detail 两张电子给药记录表未用于细节抽取。官方在发布公告里写得很清楚，这份数据"正在接受用户测试，且有已知局限"。五年过去，版本表上仍然只有 0.9 一条记录。它不是一份拿来做实验的数据，是一份拿来看清"MIMIC 进 OMOP 这条路到底怎么走"的样本。一屏速览见下表。

一屏速览

维度	内容
全名	MIMIC-IV demo data in the OMOP Common Data Model
发布平台	PhysioNet，由 MIT 计算生理实验室（MIT LCP）托管
转换执行方	OHDSI 社区，SQL 由 Odysseus Data Services 的 Kallfelz 与 Tsvetkova 主导
首次发布	2021 年 6 月 21 日，版本 0.9
版本现状	版本表仅 0.9 一条，截至核实日无后续版本
患者数	100 名，取自 MIMIC-IV 的演示子集
上游模块	3 个：core（住院与转科）、hosp（检验、微生物、电子给药）、icu（重症事件表）
目标模型	OMOP Common Data Model，ETL 仓库 DDL 文件名锁定为 5.3.1
交付目录	3 个：1_omop_data_csv、2_achilles_json_data、3_data_quality_dashboard_files
落数目标表	etl/etl 目录下 20 个 cdm_ 脚本对应 20 张 OMOP 表
表定义规模	CDM DDL 建 29 张表，标准词表 DDL 另建 10 张
概念策略	标准概念取 RxNorm、LOINC、ICD-10 等标准词表；源端概念自建于 20 亿以上区间
自定义映射	custom_mapping_csv 目录 23 个文件，其中 22 个为 gcpt_ 前缀映射表
质量工具	Achilles（数据刻画）+ Data Quality Dashboard（数据质量），均为 R 实现
文件格式	CSV（每张 OMOP 表一个文件，首行为列名）+ JSON
许可	Open Data Commons Open Database License v1.0（ODbL 1.0），免申请
DOI	10.13026/p1f5-7x35（v0.9）；最新 10.13026/2d25-8g07
代码仓库	github.com/OHDSI/MIMIC，SQL 以 Python 封装，面向 Google BigQuery 优化
典型用途	OMOP CDM 教学与演示、OHDSI 工具链联调、概念映射与 ETL 的社区协作基线

§1 它要解决的具体麻烦

1.1 两套坐标，两种成本

一个研究组想做多中心真实世界证据研究，会遇到一道绕不过去的工程题：十家医院的信息系统由十家厂商提供，诊断编码有的用 ICD-9、有的用 ICD-10，检验项目各有各的本地编号，用药记录分散在医嘱、摆药、执行三张表上。把十套结构统一成一套，工作量几乎等于重做十遍数据工程。OMOP CDM 的存在就是为了把这个"十遍"压缩成"一遍"：每家机构各自做一次 ETL（Extract-Transform-Load，抽取-转换-加载），之后所有分析都写在同一套表结构上。

但 OMOP 这一侧有个先有鸡还是先有蛋的问题。想学会做 ETL，需要看别人做好的 ETL；想验证自己的 ETL 做得对不对，需要一份已知答案的标准实例。市面上能公开下载的 OMOP 实例极少，且大多是门诊或理赔数据—— Synthea 那样的合成数据没有真实世界的脏乱，理赔数据没有检验值与生命体征。真正需要 OMOP 的那一类 richest 数据（重症监护的分钟级事件），恰好是最不容易公开的那一部分。

这份数据集补的就是这个缺口：它把全球使用最广的 ICU 数据库的演示子集，以最通用的数据模型交付，且完全免申请。它不是为了让谁用 100 个人做研究，而是为了让"OMOP 那套表在真实 ICU 数据上长什么样"这件事第一次可以被任何人打开看。

1.2 三条常见的错误期待

第一条，期待它是"小一号的 MIMIC-IV"。它不是缩小版，是换坐标系。MIMIC 的三十来张表被拆散重组进二十来张 OMOP 表，表名、列名、主键全部改变，itemid 字典表消失、取而代之的是 concept_id。想在上面照着 MIMIC 教程练 SQL，会一步都走不通；反过来，想用它反推 MIMIC 原生结构，也会因为中间隔了一层映射而处处碰壁。

第二条，期待它的数据内容与 MIMIC-IV 演示库等值。转换是有损的。官方已知限制里明确写着自由文本病历未填充、inputevents 与 outputevents 尚未纳入、emar 与 emar_detail 未用于细节抽取——这四项占了重症监护数据相当大的一块信息量。拿它和 MIMIC-IV 演示库做"内容对账"，会对出一片窟窿。

第三条，期待它跟着 MIMIC-IV 一起升级。它锁在 MIMIC-IV v1.0 那一代的上游上，版本停在 0.9。MIMIC-IV 后来推进到 2.x、3.x，OMOP CDM 后来推进到 5.4，GitHub 仓库里的 ETL 代码也确实跟着跑过 MIMIC 2.0 与 2.2，但 PhysioNet 上的交付物没有同步发新版。以为"仓库在更新所以数据在更新"，是最容易踩的一坑。

1.3 它能给到的与给不到的

你的需求	它给的	够不够
看清 OMOP CDM 在真实 ICU 数据上的表结构与填充情况	29 张表的 DDL、20 张表的落数 CSV、逐表列名	够，这是它最核心的价值
学习 OHDSI 工具链怎么用	随包 Achilles 与 DQD 的 JSON，可直接喂给对应应用	够，省掉自己跑一遍刻画
练习概念映射与 ETL 写法	完整公开 SQL、22 张自定义映射表、五步转换逻辑	够，且是社区公认的参考实现
做多中心方法的可移植性演示	标准概念编号与标准表结构	够做演示，不够做结论
用 100 名患者训练模型	100 人的结构化记录	不够，量级上不成立
做文本抽取、病历生成、命名实体识别	无，自由文本病历未填充	完全不够，需另走文本路径
做液体平衡、出入量相关研究	无，inputevents 与 outputevents 未纳入	完全不够
做真实世界证据的流行病学结论	100 人、单中心、时间被偏移	不够，官方定位就是演示
复现某篇 MIMIC 论文的原始结果	需经一层映射回源，且部分表缺	不够，应直接用 MIMIC 原生库

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

你的处境	它能帮你什么	下一步该做什么
你在给自家医院做 OMOP ETL，不知道从哪张表下手	提供一份 ICU 级源数据的完整落表范例，逐表可查	先照着 20 个 cdm_ 脚本的顺序读，再对照自己的源表做缺口清单
你要教 OMOP CDM 这门课，缺一份能让学生随便乱跑的数据	免申请、体积小、可直接进内存	用 CSV 直接开课，第二节课再让学生装 PostgreSQL 走 OHDSI 包
你在评估要不要把团队的分析栈迁到 ATLAS	提供真实的转换代价样本：多少概念要自建、多少映射要人工	重点读 custom_mapping_csv 的 22 张表，估算自己的映射工作量
你想知道 ICU 的波形数据能不能进 OMOP	仓库里有波形概念验证：wf_header、wf_details 两张源表，落到 measurement 与 condition_occurrence	读 lk_meas_waveform.sql 与 st_waveform_poc_2.sql
你在做概念映射的质量研究	提供三阶段人工复核流程的产出与残留问题	结合 DQD 的 JSON 看哪些检查项未通过
你只是想看看 OMOP 表到底长什么样再决定学不学	几分钟下载，CSV 用任何工具都能打开	直接看 1_omop_data_csv 里的 person 与 visit_occurrence

1.5 一句话判断

它不是一份用来出结果的数据，而是一份用来校准预期的样本：先看清 MIMIC 进 OMOP 这一步要付多少代价、会丢哪些东西、哪些概念必须自己映射，再决定这条路要不要走。

1.6 不适合谁：四条边界

不适合拿来做任何统计推断。 100 人、单中心、时间经过偏移，任何一个流行病学数字在它上面算出来都不该被写进论文。官方对它的定位写的是演示与教育。

不适合拿来替代 MIMIC-IV 原生库。 只要你的问题能在 MIMIC 原生表上直接回答，就该直接用原生表。每多一层映射，就多一层的语义损失与版本错位风险。

不适合拿来做文本任务。 自由文本病历未填充，note 与 note_nlp 两张表在转换里没有内容。要做文本，走 MIMIC-IV-Note 那条独立路径。

不适合拿来当生产环境的 OMOP 参考实现照抄。 版本号 0.9 本身就是"初始版本"的意思，官方明确列出已知局限并邀请社区提 PR。把一份自认不完整的实现抄进生产管线，等于把别人的未决问题接成自己的技术债。

§2 数据构成与规格

2.1 三个目录，三种用途

数据按用途分成三个顶层目录，这个划分本身就是一份使用说明。

第一个目录 1_omop_data_csv 是主体。它为每一张 OMOP 表准备一个 CSV 文件，第一行是列名，列遵循 OMOP 模型规范。官方给了一句非常关键的判读规则：如果某个文件只有列头、没有数据行，说明没有任何 MIMIC 数据被转换进那张表。这条规则让人不必猜"这张表为什么是空的"——空就是真的没转。

第二个目录 2_achilles_json_data 放 Achilles 工具生成的 JSON。Achilles 是 OHDSI 的数据刻画工具，跑在数据库之上，产出的是聚合层面的数据刻画结果，可以配合 Achilles Web 应用浏览。它的作用不是提供新数据，而是提供"这份数据长什么样"的现成答案。

第三个目录 3_data_quality_dashboard_files 放 DQD 生成的 JSON。DQD 是 OHDSI 的数据质量看板，按一套预设的检查项对 CDM 实例逐项打分，并把未通过的检查记录下来。官方特别说明：这些 JSON 是最近一次 Achilles 与 DQD 运行的产物，仓库里还留了"哪些数据质量错误依然存在"的文档。

目录	内容	为什么值得单独留一份
1_omop_data_csv	每张 OMOP 表一个 CSV，首行列名	数据本体；空文件即代表该表无数据转入
2_achilles_json_data	Achilles 刻画结果 JSON	省去自己装 R 环境跑刻画的工夫，可直接浏览
3_data_quality_dashboard_files	DQD 质量检查 JSON	让"这份转换质量如何"有可查证的依据，而非口头声明

2.2 表清单：定义 29 张，落数约 20 张

OMOP 的模型定义在 ETL 仓库的 DDL 文件里。CDM 侧的 DDL 建了 29 张表，标准词表侧的 DDL 另建 10 张。而真正由 ETL 脚本往里写数的，是 etl/etl 目录下 20 个以 cdm_ 开头的脚本所对应的表。两者之间的差额，正是"定义了但没填"的部分。

分组	表	在本项目中的状态
人口与观察期	person	由 cdm_person.sql 落数
人口与观察期	observation_period	由 cdm_observation_period.sql 落数
就诊	visit_occurrence	由 cdm_visit_occurrence.sql 落数
就诊	visit_detail	由 cdm_visit_detail.sql 落数
临床事件	condition_occurrence	由 cdm_condition_occurrence.sql 落数
临床事件	procedure_occurrence	由 cdm_procedure_occurrence.sql 落数
临床事件	drug_exposure	由 cdm_drug_exposure.sql 落数
临床事件	device_exposure	由 cdm_device_exposure.sql 落数
临床事件	measurement	由 cdm_measurement.sql 落数
临床事件	observation	由 cdm_observation.sql 落数
临床事件	specimen	由 cdm_specimen.sql 落数
临床事件	death	由 cdm_death.sql 落数
派生 eras	condition_era	由 cdm_condition_era.sql 落数
派生 eras	drug_era	由 cdm_drug_era.sql 落数
派生 eras	dose_era	由 cdm_dose_era.sql 落数
机构与人	care_site	由 cdm_care_site.sql 落数
机构与人	provider	由 cdm_provider.sql 落数
机构与人	location	由 cdm_location.sql 落数
关系与元数据	fact_relationship	由 cdm_fact_relationship.sql 落数
关系与元数据	cdm_source	由 cdm_cdm_source.sql 落数
定义了未落数	note、note_nlp	自由文本病历未填充
定义了未落数	cost、payer_plan_period	无对应 ETL 脚本
定义了未落数	cohort、cohort_definition 等结果表	属结果模式，由分析环节生成而非转换环节
词表	concept、vocabulary、domain、concept_class、concept_relationship、relationship、concept_synonym、concept_ancestor、source_to_concept_map、drug_strength	10 张；本包仅提供本地概念部分

需要强调一个容易混淆的点：上表把"有 ETL 脚本"当作"有数据"的代理指标，而实际是否有数据行，仍以 CSV 文件里有没有行为准。ETL 脚本存在只说明逻辑写好了，不说明这次运行一定产出了行。

2.3 一条患者的完整解剖

以最典型的就诊链条为例，一个 MIMIC 患者在 OMOP 里被拆成四层。最外层是 person，一行一个人，带性别概念、出生年、种族与族裔概念。往里一层是 observation_period，记录这个人在数据覆盖范围内的可观察时间窗。再往里是 visit_occurrence，对应一次住院。最内层是 visit_detail，对应这次住院里的一次 ICU 停留。临床事件——诊断、操作、用药、器械、测量、观察——各自挂在 visit_occurrence 或 visit_detail 上。

这四层的意义在于回答"这个事件发生在哪一次医疗接触里"。MIMIC 用三级主键回答同一个问题，OMOP 用四层表结构回答，两种结构在语义上大体对应，但在时间粒度与空值处理上并不等价。例如 MIMIC 的 ICU 停留有明确的 intime 与 outtime，OMOP 的 visit_detail 也有起止时间，但两者对"一次转科算不算新的一段"的处理口径未必一致。这种不一致不会报错，只会在你按 visit_detail 做分段统计时悄悄改变分母。

person 表里还有一处值得单独指出的设计：year_of_birth 不是直接取自患者的真实出生年，而是由 anchor_year 减去 anchor_age 推算得到。这是 MIMIC 去标识化的直接后果——MIMIC 只给锚定年份与锚定年龄，不给真实日期。OMOP 侧继承了这个约束，因此任何依赖精确出生日期的分析都要先接受这个精度损失。

2.4 主键映射：不要假设编号相等

这是本数据集最容易被误用的一处。ETL 脚本里有一行注释直接把问题摆了出来：为什么不用 subject_id 当 person_id、不用 hadm_id 当 visit_occurrence_id？注释后面跟着"ask analysts"，说明这个决定在团队内部也还留着尾巴。

实际的写法是：person_id 由 FARM_FINGERPRINT(GENERATE_UUID()) 生成，visit_occurrence_id、visit_detail_id 同样由脚本重新生成，MIMIC 侧的原始编号被保留在 *_source_value 列里。

MIMIC 侧编号	OMOP 侧主键	MIMIC 编号保存在哪
subject_id	person_id（重新生成）	person.person_source_value
hadm_id	visit_occurrence_id（重新生成）	visit_occurrence.visit_source_value
stay_id	visit_detail_id（重新生成）	visit_detail.visit_detail_source_value
chartevents itemid	无独立主键，映射为 concept_id	measurement.measurement_source_value
labevents itemid	无独立主键，映射为 concept_id	measurement.measurement_source_value

后果很直接：如果你想把 OMOP 侧的某一行对回 MIMIC 原生表，必须走 *_source_value 这一列，绝不能假设 person_id 等于 subject_id。同样地，每次重跑 ETL 生成的 person_id 都可能不同，因此任何把 person_id 硬编码进脚本或结果文件的做法，在重跑之后就会失效。

2.5 概念归宿：标准、本地、未映射

OMOP 的核心机制是"概念"。一条源端记录进入 CDM 时，它的编码要么被映射到一个标准概念（standard concept），要么被保留为一个本地概念。本项目的本地概念按 OMOP 惯例分配在 20 亿（2B）以上的编号区间，然后再建立到标准概念的映射关系。

归宿	编号区间	含义	使用注意
标准概念	常规区间，来自 LOINC、RxNorm、ICD-10 等标准词表	可直接参与跨库分析	这才是 OMOP 分析真正依赖的部分
本地概念	大于 20 亿	MIMIC 特有编码，先落地保留再做映射	跨库比对前必须先"映射到底"
未映射	记为 0	尚未找到合适的标准概念	官方承认部分 MIMIC 概念未充分映射

映射缺失关系的处理分了三步，这一步是本项目最值得学习的地方。第一步，对缺失的映射关系先用程序批量生成"建议"；没有建议的，人工补一条。第二步，由具备医学背景的专家逐条人工复核全部映射的准确性。第三步，在数据质量检查跑完之后，再由更大的团队复核一遍。三步走完才进入交付。这个流程说明了一件事：概念映射不是一次性的技术活，而是一条需要医学判断的质量链。

2.6 自定义映射表清单

custom_mapping_csv 目录里共 23 个文件，除一份清单文件 custom_mapping_list.tsv 外，22 个是 gcpt_ 前缀的映射表。按覆盖的源端域分组如下。

分组	文件	覆盖的源端内容
用药	gcpt_drug_ndc.csv、gcpt_drug_route.csv	药品国家药品编码、给药途径
检验	gcpt_meas_lab_loinc_mod.csv、gcpt_meas_unit.csv	实验室项目到 LOINC、计量单位
体征	gcpt_meas_chartevents_main_mod.csv、gcpt_meas_chartevents_value.csv	重症监护体征项主项与取值
波形	gcpt_meas_waveforms.csv	波形派生测量项
微生物	gcpt_micro_organism.csv、gcpt_micro_antibiotic.csv、gcpt_micro_microtest.csv、gcpt_micro_resistance.csv、gcpt_micro_specimen.csv	病原体、抗生素、药敏试验、耐药性、标本
操作	gcpt_proc_itemid.csv、gcpt_proc_datetimeevents.csv	操作字典项与时间型事件
观察	gcpt_obs_drgcodes.csv、gcpt_obs_insurance.csv、gcpt_obs_marital.csv	DRG 编码、保险、婚姻状况
就诊与人口	gcpt_vis_admission.csv、gcpt_per_ethnicity.csv、gcpt_cs_place_of_service.csv	入院类型、族裔、服务场所
出入量与生成项	gcpt_outputevents.csv、gcpt_mimic_generated.csv	出量事件、MIMIC 生成概念

观察这张表会发现一个耐人寻味的细节：gcpt_outputevents.csv 存在于仓库里，但官方页的已知限制又写明 outputevents 尚未纳入转换。这两句并不矛盾——仓库的 main 分支是持续维护的开发线，早已超越了 0.9 这次交付；PhysioNet 上的 0.9 是某个时间点上的快照。读仓库时看到的，和下载到的，不是同一份东西。

2.7 CSV 的读取与类型陷阱

OMOP 的 CSV 看起来没有任何门槛，用任何表格软件都能打开。但有三处类型问题会在打开之后才暴露出来。

第一处是概念编号的宽度。concept_id 在 OMOP 里是整数，本地概念被分配在 20 亿以上的区间，已经接近 32 位有符号整数的上界。用默认设置把它读成有符号 32 位整数在某些环境里不会出错，但在另一些环境里会溢出成负数或被截断。稳妥的做法是显式指定为 64 位整数或字符串再比较。

第二处是前导零与字符串化。像 person_source_value 这类列，源端是整数编号，落到 CSV 里被写成字符串。用自动类型推断去读，有的文件会被认成数字、有的被认成字符串，跨文件做连接时就会静默失败。凡是以 _source_value 结尾的列，一律按字符串处理最省心。

第三处是日期与时间的精度。OMOP 的事件表里有日期列与日期时间列之分，而 MIMIC 的时间经过整体偏移，某些派生字段被显式置空——例如 person 表里的 month_of_birth、day_of_birth、birth_datetime 在 ETL 里直接写入空值，只保留 year_of_birth。这不是数据缺失，是上游精度就不存在，硬要去填只会造出假信息。

import pandas as pd

#-- 统一按字符串读 source_value 列，避免自动类型推断造成的连接失败
person = pd.read_csv(
    "mimic-iv-demo-omop/0.9/1_omop_data_csv/person.csv",
    dtype={"person_source_value": "string"},
    low_memory=False,
)

#-- concept_id 显式用 64 位整数，兼容 20 亿以上的本地概念区间
meas = pd.read_csv(
    "mimic-iv-demo-omop/0.9/1_omop_data_csv/measurement.csv",
    dtype={"measurement_concept_id": "Int64",
           "measurement_source_value": "string"},
    low_memory=False,
)

#-- 回源：靠 source_value 而不是主键对齐 MIMIC 原生编号
key = person[["person_id", "person_source_value"]]
print(key.head())

§3 它是谁的数据

3.1 九位署名者与四种机构背景

署名作者共九位，机构背景分成四类，这个构成恰好说明了这类工作为什么难做。

作者	机构	角色含义
Michael Kallfelz	Odysseus Data Services Inc.	ETL 工程主力
Anna Tsvetkova	Odysseus Data Services Inc.	ETL 工程主力
Tom Pollard	Massachusetts Institute of Technology	MIMIC 侧代表
Sicheng Hao	MIT	MIMIC 侧
Manlik Kwong	Tufts 临床研究与健康政策研究所	方法学
Andrew Williams	Tufts 临床与转化科学研究所、Tufts 医学中心	方法学
Gigi Lipori	University of Florida Health	实施方视角
Vojtech Huser	NIH 国家医学图书馆	标准与可持续性
Jeffrey Osborn	Endpoint Health, Inc.	产业界视角

四类背景缺一不可：没有懂 MIMIC 的人，源端语义会被读错；没有懂 OMOP 的人，目标模型会被填歪；没有做过真实机构实施的人，ETL 写得出但跑不动；没有标准组织与资助方，映射维护撑不过第一年。官方在致谢里写明了资助来源：比尔及梅琳达·盖茨基金会提供了部分支持，Huser 的贡献由 NIH 国家医学图书馆支持，Pollard 受 NIBIB 的 R01EB030362 资助。

3.2 时间线

时间	事件
2020 年秋	OHDSI 兴趣小组启动本项目，以 MIMIC-III 的 OMOP ETL 为基础改造
2021 年春	ETL 逻辑与概念映射继续推进，社区成员通过 PR 补充
2021 年 6 月 21 日	版本 0.9 在 PhysioNet 发布
2021 年 6 月 28 日	PhysioNet 发布公告，明确"正在用户测试中、有已知局限"
2021 年及之后	仓库继续维护，跑过 MIMIC 2.0 与 2.2，但 PhysioNet 交付物未升级

这条时间线最重要的一点在最后一行：仓库在动，交付物没动。判断一份数据的新鲜度时，看的是 PhysioNet 的版本表，不是 GitHub 的提交记录。

3.3 上游：三个模块，一百个人

上游是 MIMIC-IV 的演示子集，100 名患者，覆盖三个模块。core 提供患者与住院、转科信息；hosp 提供医院层面的检验、微生物与电子给药；icu 提供重症监护的事件表。官方页的 Parent Projects 里列了两条：MIMIC-IV v1.0 与 MIMIC-III Clinical Database Demo v1.4。

这里有一个必须自己核对、而官方页并没有交代清楚的点。PhysioNet 上独立的 MIMIC-IV 演示库项目（url_name 为 mimic-iv-demo）的版本表是 1.0（2022 年 6 月 22 日）与 2.2（2023 年 1 月 31 日），都晚于本数据集 2021 年 6 月的发布日。也就是说，本数据集所依据的那"100 名患者"与后来演示库 v2.2 所取的"100 名患者"，是否为同一批人，官方页没有声明。凡是要把两侧数据并排比较的工作，都必须先把这个问题查清楚，否则等于在两张不同的样本上做对照。

3.4 来源层次

层次	实体	说明
原始临床数据	贝斯以色列女执事医疗中心的重症监护病历	去标识化后由 MIT LCP 维护
第一层公共产品	MIMIC-IV v1.0	需凭据访问，模块化：core / hosp / icu / note
第二层公共产品	MIMIC-IV 演示子集（100 名患者）	免申请，剔除自由文本
第三层公共产品	本数据集（OMOP CDM 版）	在演示子集之上再换一次坐标系
旁支	MIMIC-III Clinical Database Demo v1.4	官方列为父项目之一，主要贡献了可复用的映射经验

层次越往上，越容易拿到，也越远离原始细节。理解这一点，就知道为什么在这个数据集上做的每一件事都要先问一句：我要的那个东西，是不是在某一层被弄丢了。

§4 它最独特的东西

4.1 免申请，且是 ICU 级

OMOP 生态里公开可得的实例不多，能免申请下载的更少，兼具 ICU 粒度的最少。这个组合是它真正的稀缺性所在：不需要任何资质流程，任何人都能拿到一份真实的、带着分钟级体征与诊断操作用药的 OMOP CDM 实例。对于想进入这个生态的人来说，这是一份没有门槛的入门实物。

4.2 波形进 OMOP 的概念验证

官方在背景里点明了第四项动机：探索把 ICU 波形与数值型数据转换成 OMOP 标准概念的可行性。这件事在此之前几乎没人做过——OMOP CDM 是为离散的临床事件设计的，波形是连续信号，两者在模型层面根本不是一类东西。

仓库里的做法是把它当概念验证（proof of concept）来做。scripts/wf_read.py 遍历存储桶路径下的子目录，把目录结构信息填进 wf_header 表、把找到的 CSV 数据填进 wf_details 表，这两张表随后作为 measurement 与 condition_occurrence 的源表使用。在 lk_meas_waveform.sql 里能看到具体的落法：measurement_source_value 写成"<波形库参考编号>.<算法编号>"的形式，例如 “3700002_0011.WFDB”，注释里还说明 ECG 测量被映射到导联级别。

这个设计的意义在于保留溯源：一个波形派生出来的测量值，能从 source_value 一路追回它来自哪个波形文件、由哪个算法算出。这在 OMOP 里并不常见，而它恰好是波形数据能不能进通用模型的关键——如果溯源断了，派生值就和凭空冒出来的数字没有区别。仓库里标记为 poc_2 与 poc_3 的两批数据，前者由脚本自动加载，后者按注释所述是手工加载准备的。

4.3 ETL 与映射是按全量设计的

官方在 Usage Notes 里写了一句容易被忽略但很关键的话：ETL 代码是同时为演示集与全量集设计的，ETL 里的映射不限于演示数据里出现过的概念，而是覆盖全量数据的完整谱系。

这句话把它的价值抬高了一档。它意味着你手里这份 100 人的小包，附带的是一份面向几万人大库的映射资产。想评估"把 MIMIC-IV 全量搬进 OMOP 要多少工作量"的人，可以直接数这 22 张映射表的规模与缺口，而不必自己从零起步。反过来说，也因此不能因为"演示数据里这个概念没出现"就认为映射不存在。

4.4 五步转换逻辑与八条工作流

ETL 的逻辑被明确拆成五步，每一步的产物用前缀标识，这套命名让整条管线可以被逐段审查。

步骤	产物前缀	做什么
1	src_	对源数据做快照，落到暂存表
2	lk_*_clean	清洗：过滤无用行、格式化取值、应用业务规则
3	lk_*_concept	把源端编码映射到词表概念
4	lk_*_mapped	把清洗后的数据与映射好的编码连接起来
5	cdm_*	按 target_domain_id 把数据分发到各张目标 CDM 表

包在外层的八条工作流则是：vocabulary refresh（装载词表与自定义映射）、waveform collecting（装载波形解析结果）、ddl（建空表）、staging（建快照）、etl（执行转换）、ut（跑内部单元测试）、metrics（生成内部质控指标）、unload（把 CDM 与词表复制到最终的 OMOP 数据集）。最后一步 unload 会把中间过程的技术字段（unit_id、load_table_id、load_row_id、trace_id）从成品表里剥掉。

4.5 边界条件：空表、缺表与偏差

边界类型	具体表现	出处
表级缺失	note、note_nlp 无内容	官方 Known limitations
表级缺失	inputevents、outputevents 未纳入转换	官方 Known limitations 与发布公告
表级缺失	emar、emar_detail 未用于细节抽取	官方 Known limitations
映射不足	部分 MIMIC 概念未充分映射到标准概念	官方 Known limitations
口径差异	drug_exposure 由 prescriptions 与 pharmacy 两表填充	官方 Known limitations
系统性偏差	多数数据质量问题与 MIMIC 去标识时间偏移有关	官方 Methods 段
版本停滞	版本表仅 0.9，无后续版本	PhysioNet 版本表
可及性	部分区域访问文件页会收到区域限制提示	官方 files 页面提示

§5 怎么拿到

5.1 目录结构与下载路径

官方页的 Access 段写明：任何人在遵守许可条款的前提下都可以访问文件，许可为 ODbL 1.0。下载有三条常规路径。

#-- 递归下载整个 0.9 版本目录（需接受 PhysioNet 的下载条款）
wget -r -N -c -np --user-agent="Mozilla/5.0" \
     https://physionet.org/files/mimic-iv-demo-omop/0.9/

#-- 只取主体 CSV 目录，跳过刻画与质量报告
wget -r -N -c -np --user-agent="Mozilla/5.0" \
     -A "*.csv" https://physionet.org/files/mimic-iv-demo-omop/0.9/1_omop_data_csv/

#-- 校验：列出下载到的 CSV 与字节数，零字节文件即"未转换"的表
find mimic-iv-demo-omop -name "*.csv" -printf "%s\t%p\n" | sort -n | head -40

第三条命令是本数据集最有用的一条自查：按字节数排序后，只有列头的那些文件会排在最前面。官方页明确写了"如果某个文件只有列头、没有数据行，说明没有 MIMIC 数据被转换进那张表"，这条命令把这句话直接落到可执行的检查上。

5.2 装进数据库：OHDSI 生态的前提

官方在 Usage Notes 里给了明确建议：CSV 可以直接下载、直接在内存里读，但绝大多数 OHDSI 分析包要求数据必须在数据库里。也就是说，"用 pandas 读 CSV"只够看，不够用。要用 ATLAS、要跑 DQD、要跑 Achilles，得先落库。

import pandas as pd
import glob, os

#-- 把 1_omop_data_csv 下全部 CSV 读成 DataFrame 字典
base = "mimic-iv-demo-omop/0.9/1_omop_data_csv"
tables = {}
for path in sorted(glob.glob(os.path.join(base, "*.csv"))):
    name = os.path.splitext(os.path.basename(path))[0]
    tables[name] = pd.read_csv(path, low_memory=False)

#-- 先看哪些表是空的：只有列头、没有数据行
empty = [k for k, v in tables.items() if len(v) == 0]
print("空表:", empty)
print("表名数:", len(tables), "非空表数:", len(tables) - len(empty))

#-- 看 person 表的列，确认 source_value 列的存在
print(list(tables["person"].columns))

落库时有个顺序要求：先建 CDM 表结构，再导入 CSV，最后导入词表。CDM 表结构可以直接用仓库里的 DDL，但要注意 DDL 里的表名前缀是参数化替换标记（@etl_project.@etl_dataset.cdm_person 这种形式），需要先替换成自己库里的实际 schema 名。

5.3 补齐标准词表：最容易卡住的一步

官方在 Data Description 里给了一条很容易被漏掉的说明：随包提供的词表部分只包含本地概念（20 亿以上区间），其余的词表内容需要按标准机制自行获取，并指向 OHDSI 文档的"访问标准化词表"一节。

这一步不做完，数据是残的。因为 OMOP 的分析逻辑依赖 concept_id 之间的层级与"Maps to"关系，本地概念只有先通过关系表映射到底，才能参与标准分析。官方指定的获取入口是 OHDSI 的 Athena 词表服务。换句话说，下载到的 CSV 里那些大于 20 亿的编号，在没有完整词表的情况下只是一串无意义的整数。

步骤	做什么	不做会怎样
1	从 Athena 下载最新版标准词表	本地概念无法映射到底
2	把随包的本地概念合并进词表的 concept 表	源端编码失去承载
3	确认 concept_relationship 里的 “Maps to” 关系完整	标准分析查不到目标概念
4	用 Achilles 跑一遍，与随包 JSON 对照	无法确认自己的装配是否等价于官方

5.4 用随包的 JSON 做对照

Achilles 与 DQD 的两个 JSON 目录不是装饰。正确的用法是：先在本地把装配好的库跑一遍 Achilles，再把结果与随包 JSON 对照。对得上，说明你的装配与官方一致；对不上，先查词表版本是不是下错了。官方在仓库里还留了文档说明"哪些数据质量错误依然存在"，那份文档应当与 DQD 的 JSON 一起读——它告诉你哪些红灯是已知的、可以接受的。

5.5 五个坑

第一个坑，把 person_id 当成 subject_id。ETL 用 FARM_FINGERPRINT(GENERATE_UUID()) 重新生成主键，MIMIC 编号只保留在 person_source_value。跨库对齐必须走 source_value 列。

第二个坑，以为下载完 CSV 就能用 OHDSI 工具。绝大多数 OHDSI 分析包要求数据在数据库里，CSV 只适合直接看。

第三个坑，只下 CSV 不下词表。本地概念在 20 亿以上区间，没有完整标准词表就映射不到标准概念，分析链条在第一环就断了。

第四个坑，用 GitHub 仓库的状态推断交付物的状态。仓库跑过 MIMIC 2.0 与 2.2，交付物停在 0.9。两者不是一回事。

第五个坑，把它当 MIMIC-IV 演示库的等价物。转换是有损的：文本没有、出入量没有、电子给药细节没有。任何"两边应该对得上"的预期都会落空。

5.6 回源对齐与版本固定

很多实际工作并不满足于在 OMOP 侧做完分析，还需要回到 MIMIC 原生表去核对某条记录、补某个字段，或者把 OMOP 侧定义的队列映射回原生表取原始明细。这件事有一条唯一可靠通道：*_source_value 列。

做法上要注意三点。第一，person_id、visit_occurrence_id、visit_detail_id 都是 ETL 运行时生成的，重跑一次就可能变，所以任何跨会话的中间结果都不能只存这些编号，必须连 source_value 一起存。第二，回源时要把 source_value 从字符串转回 MIMIC 侧的整型编号再连接，否则一边是字符串一边是整数，连接结果会静默为空。第三，回源之前要先确认两侧的"代"是否一致——这份数据锁在 MIMIC-IV v1.0 那一代，如果拿它的 source_value 去查现行 v3.x 的原生表，编号体系可能已经改过，对不上是常态而不是故障。

要做的事	用哪一列	不能用什么
OMOP 行对回 MIMIC 患者	person.person_source_value	person_id
OMOP 行对回 MIMIC 住院	visit_occurrence.visit_source_value	visit_occurrence_id
OMOP 行对回 MIMIC 重症停留	visit_detail.visit_detail_source_value	visit_detail_id
查某个测量项来自哪个源端编码	measurement.measurement_source_value	measurement_concept_id
确认某个概念是标准还是本地	concept_id 是否大于 20 亿	概念名称字符串

版本固定同样重要。引用这份数据时，除了写清 PhysioNet 的版本号 0.9 与 DOI，若你还用到了 GitHub 仓库里的 ETL 代码，应当同时记录仓库的提交号。因为两者不同步，只写其中一个，后来的人就无法复现你跑的那一份。

§6 与库内其他资源的关系

6.1 关系图谱

相关资源	关系	判据
MIMIC-IV（rid 592）	上游母库，需凭据	官方 Parent Projects 列 MIMIC-IV v1.0
MIMIC-IV 演示库（rid 1629）	同源不同代，同为 100 人演示子集	本数据集 2021 年发布，演示库独立项目 2022 年起才有版本
MIMIC-IV 演示库 MEDS 版（rid 1633）	同一上游的另一套标准改写	一个走 OMOP CDM，一个走 MEDS 事件流
MIMIC-IV on FHIR（rid 1529）	同一上游的第三套标准改写	OMOP 面向观察性研究，FHIR 面向交换
MIMIC-III（rid 106）	前一代母库	本项目的映射基础来自 MIMIC-III 的 OMOP 工作
MIMIC-III Demo（rid 591）	官方列为父项目之一	官方 Parent Projects 明确列出 v1.4
MIMIC-BR（rid 156）	同为 OMOP 化的 MIMIC 系数据库	巴西多中心、独立数据，非这份数据上游
MIMIC-III Waveform（rid 586）	波形概念验证的源头之一	官方背景段引用 MIMIC-III 波形库
MIMIC-IV 波形库（rid 65）	波形派生的另一条取数路径	这份数据只含派生测量值，不含原始波形
MIMIC-IV-Note（rid 47）	补上这份数据缺失的文本层	官方已知限制：自由文本未填充

6.2 检索路径

想按"我要干什么"找路，可以从三条线索入手。做通用数据模型与跨机构分析，从这份数据与 MIMIC-BR 进。做事件流建模与特征抽取，从 MEDS 版进。做系统间交换与接口对接，从 FHIR 版进。三条线索的共同上游都是 MIMIC-IV 演示子集，这决定了它们在患者层面理论上同源，但在具体内容上并不可互换。

6.3 分工判据

你的问题	该用哪一份	理由
OMOP 表在 ICU 数据上长什么样	这份数据	唯一公开的 ICU 级 OMOP 实例
我要练 MIMIC 原生 SQL	MIMIC-IV 演示库（rid 1629）	保留原生表结构与主键
我要跑 OHDSI 的 ATLAS	这份数据	只有 OMOP 实例能直接接 OHDSI 工具
我要训练序列模型	MEDS 版（rid 1633）	已是事件流形态，划分已固定
我要做接口与互联互通演示	FHIR 版（rid 1529）	FHIR 是交换标准而非分析标准
我要文本	MIMIC-IV-Note（rid 47）	这份数据文本层为空
我要原始波形	MIMIC-IV 波形库（rid 65）	这份数据只含波形派生测量值

§7 质量评估与局限性

7.0 前置校正：它是视图，不是副本

评估它之前必须先摆正一件事：它不是 MIMIC-IV 的副本，是 MIMIC-IV 在另一套坐标系里的一个视图。视图的正确性有两层含义——结构对不对（表、列、主键是否符合 CDM 规范），以及语义对不对（映射出来的概念是不是源端那个意思）。前者可由 DQD 与单元测试检查，后者只能靠人工医学复核，而官方承认后者仍有残留问题。

7.1 五维评分

维度	评价	依据
结构规范性	高	表与列遵循 OMOP 模型规范，DDL 与落数脚本一一对应
语义保真度	中等偏低	官方承认部分 MIMIC 概念未充分映射
内容完整性	中等偏低	文本、出入量、电子给药细节三块明确缺失
可复现性	高	ETL 全公开、五步命名清晰、八条工作流可顺序执行
时效性	低	版本停在 0.9，上游母库与 CDM 规范都已推进

7.2 两层标注，两种错误

第一层是源数据本身的错误。MIMIC 的去标识化把日期整体偏移，官方明确说"数据质量工具识别出的问题多数与 MIMIC 去标识化的时间偏移有关"。这一层的错误不由转换引入，也无法由转换修复。

第二层是转换引入的错误。概念映射错了、源端筛选条件写窄了、domain 分错了表，都会在这一层发生。官方用三阶段人工复核来对付它，但已知限制里仍留着"部分概念未充分映射"这一条。

两层错误的关键区别是可修性不同：第一层要回到母库，第二层改 ETL 与映射表即可，而且第二层正是社区 PR 机制要解决的那一类。

7.3 可枚举的偏差

偏差来源	表现	影响
时间偏移	日期整体平移，年份与年龄以 anchor_year、anchor_age 表达	任何跨年趋势分析失效；出生年只能推算
人群偏移	单中心、ICU 与住院患者	不能代表门诊或普通人群
规模偏移	100 名患者	任何比例类结论都不成立
表级偏移	文本、出入量、电子给药细节缺失	依赖这几块的研究方向直接不可做
映射偏移	部分概念未映射到标准概念	相关分析会漏掉这些行
版本偏移	锁在 MIMIC-IV v1.0 与 CDM 旧版	与现行规范存在代差

7.4 外部验证：官方自己给了检查工具

本项目没有依赖外部机构的独立验证，而是把 OHDSI 自己的两把尺子用上了：Achilles 看数据刻画是否合理、是否全面，DQD 逐项跑预设的数据质量检查。两份 JSON 随包分发，等于把"质量如何"这个问题的答案连同数据一起交付，而不是留给用户自己去猜。

这种做法的价值在于可对照。任何人重新装配一遍，都可以拿自己的 Achilles 结果与随包结果比。对得上，说明装配正确；对不上，说明某个环节不一致。这在 OMOP 生态里其实是一种少见的诚实做法——多数 CDM 实例的质量报告是不公开的。

还需要补一句边界：这两把尺子量的是"结构性合规"，不是"语义性正确"。DQD 能查出某列的取值是否落在允许范围、某张表的行数是否为零、某个日期是否早于出生日期，但查不出"这个诊断代码映射出来的概念是否真的是医生写下的那个意思"。后者只能靠那三阶段人工复核，而人工复核的覆盖率与一致性本身就难以量化。所以正确的读法是：质量报告绿灯多，说明这份转换在模型规范上是站得住的；但它不能反过来证明语义无损。官方把"部分概念未充分映射"留在已知限制里，正是对这一边界的诚实交代。

7.5 为什么 0.9 一直没升级

官方在 Release Notes 里写得很坦白：0.9 是转换的初始版本，希望在未来版本中解决社区指出的局限，并请用户关注项目仓库的更新。维护模式被明确交给了社区——映射与 ETL 的持续维护预期由 OHDSI 研究者通过向 GitHub 仓库提 PR 完成，仓库的 readme 里留了负责审阅 PR 的联系人。

结果是代码在演进、交付物没演进。仓库的变更记录显示 ETL 后来跑过 MIMIC 2.0 与 2.2，词表也更新过版本。这算失败吗？未必。对一个本来就是"转换范例"的项目来说，仓库活着比版本号好看更重要。代价则是：任何想用它的人都必须自己接受"代码与数据不同步"这个现实，并在引用时写清版本号 0.9。

§8 生态位与历史

8.1 沿革：从 MIMIC-III 的探索到 MIMIC-IV 的实施

阶段	工作	意义
早期探索	Nicolas Paris、Adrien Parrot 等把 MIMIC-III 转成 OMOP，成果发在 medRxiv	证明了这条路走得通，也留下了可复用的映射
本项目	以 MIMIC-III 的模板脚本与概念映射为基础，调整逻辑、扩充映射以适配 MIMIC-IV	从"能转"走向"转得全、转得准"
后续维护	OHDSI 研究者通过 PR 持续改进 ETL 与映射	把一次性项目变成社区资产

官方在发布公告里直接向 Paris 与 Parrot 的工作致谢，并在方法段说明映射基础来自他们公开的仓库，本项目在此之上"增加了许多映射以达到更高的覆盖率"。这个沿革说明了一件事：通用数据模型的落地从来不是一次性工程，而是靠一批人接力积累映射资产。

8.2 与挑战赛、社区治理的关系

它不像影像或心电数据集那样绑在某个挑战赛上，社区治理走的是另一条路：OHDSI 兴趣小组在 2020 年的会议纪要公开在仓库 Wiki 上，问题在 GitHub 提，使用问题在 OHDSI 论坛发帖，代码改进与概念映射通过 PR 贡献。想获得仓库更高权限，按官方说法是提一个 issue 申请。

这套治理方式对"映射"这种资产是合适的。映射表天生需要持续补充与纠错，靠一次发布解决不了，靠一个团队也解决不了，只有把入口开放给所有用过它的人才能滚起来。

8.3 生态位

它的位置可以用一句话概括：OMOP 生态的公开入口，MIMIC 生态的标准出口。对 OMOP 一侧，它提供了一份不设门槛的 ICU 级实例；对 MIMIC 一侧，它提供了一条把研究成果搬进通用模型的现成路径。两边都不缺别的资源，缺的恰是这个接口。

把这个位置再拆开看，能看清它为什么难以被替代。替代它需要同时满足三个条件：数据来自真实重症监护场景、以 OMOP CDM 交付、完全免申请。合成数据能满足后两条但缺第一条，理赔与门诊类 OMOP 实例能满足后两条但缺第一条的粒度，机构自有的 ICU 级 OMOP 实例能满足前两条但缺第三条。三选二的方案遍地都是，三条全占的很少。这正是它即便停在 0.9、即便明确列着一堆局限，依然值得单独存在的原因——它回答的不是"这份数据够不够好"，而是"这条路走不走得通"。

也正因为如此，对它的评价不该沿用评价训练语料的那套标准。训练语料看规模、看标注质量、看划分是否合理；它看的是另外三件事：转换逻辑是否清楚到可以照抄，概念映射是否覆盖到可以复用，质量报告是否公开到可以对照。这三件事上它的表现是过硬的。

8.4 谁在用

官方给的四项动机已经圈定了使用人群：想让 MIMIC-IV 以 OMOP 格式被更广泛使用的人、想在 MIMIC 数据上启用 OHDSI 工具的人、需要一份可用于演示与教育的数据集的 OHDSI 与 PhysioNet 社区、以及研究 ICU 波形与数值数据能否标准化的人。第四类人最值得单独提——他们要的不是数据，是一个可行性证明。

§9 使用指引

9.1 三种角色路径

角色	最短路径	该重点看什么
想学 OMOP CDM 的学生	下 CSV → 用表格软件打开 person 与 visit_occurrence → 对照官方模型文档读列名	表与表之间怎么靠主键串起来
要做自家 ETL 的工程师	克隆仓库 → 按五步命名读 etl/etl 下的脚本 → 对照 22 张映射表估工作量	src_ 到 cdm_ 这条链每一段的产物
想用 OHDSI 工具的研究者	下 CSV → 落库 → 补词表 → 跑 Achilles 与随包 JSON 对照 → 接 ATLAS	词表装配是否与官方一致

9.2 最短流程

第一步，从 PhysioNet 下载 0.9 目录，先看 CSV 的字节数分布，把空表挑出来。第二步，用仓库的 DDL 建表，替换其中的参数化前缀。第三步，从 Athena 取标准词表，与随包本地概念合并。第四步，导入 CSV。第五步，跑 Achilles，与随包 JSON 对照。五步走完，才算拿到了一份可用的 OMOP 实例。省略任何一步，后面都会以"查不到概念"或"结果对不上"的形式还回来。

9.3 引用方式

官方指定的引用格式如下，版本号与 DOI 都指向 0.9 这一次交付：

Kallfelz, M., Tsvetkova, A., Pollard, T., Kwong, M., Lipori, G., Huser, V.,
Osborn, J., Hao, S., & Williams, A. (2021). MIMIC-IV demo data in the OMOP
Common Data Model (version 0.9). PhysioNet. RRID:SCR_007345.
https://doi.org/10.13026/p1f5-7x35

官方同时要求包含 PhysioNet 的标准引用，并在 Parent Projects 里要求一并引用其派生来源 MIMIC-IV v1.0 与 MIMIC-III Clinical Database Demo v1.4。若你的工作依赖 GitHub 仓库中的 ETL 代码而非 PhysioNet 上的交付物，应同时标注仓库地址与所依据的提交，因为两者并不同步。

§10 AI 使用声明

项	说明
文本生成	全文由 AI 起草，结构、判断与表述均为生成结果，未经临床专家复核
数字来源	规模、结构、边界三类数字均取自 PhysioNet 官方页面与 ETL 仓库文件，未自行计算任何分布性统计
文件核验	官方页正文、版本表、许可段、DOI 段均已逐段读取；ETL 仓库的 DDL 与 etl 脚本目录已逐项列出
不一致说明	官方页未标注 CDM 版本号，文中 5.3.1 系由 ETL 仓库 DDL 文件名推出；仓库中存在 gcpt_outputevents.csv 而官方页称 outputevents 未纳入，属开发线快照差异
论文信息	引用格式取自官方页 Cite 段，DOI 10.13026/p1f5-7x35；上游 MIMIC-IV v1.0 的 DOI 为 10.13026/s6n6-xd98
未核验内容	CSV 文件清单与逐表行数未能逐文件核验（核实环境访问文件页时收到区域限制提示）；100 名患者与 MIMIC-IV 演示库 v2.2 所取患者是否为同一批，官方页未声明
图像	封面图为提示词生成，不含真实数据内容，不构成任何医学示意
免责	本文不构成医疗建议；数据使用须遵守 ODbL 1.0 与 PhysioNet 的使用条款

常见误读（避坑清单）

说法	实际	证据
它是 MIMIC-IV 的缩小版	是换坐标系，表名列名主键全变，itemid 消失	落表脚本对应 20 张 OMOP 表，与 MIMIC 原生表无对应名
person_id 就是 subject_id	person_id 由 FARM_FINGERPRINT(GENERATE_UUID()) 生成	cdm_person.sql 的 INSERT 段；subject_id 存在 person_source_value
下载 CSV 就能用 OHDSI 工具	绝大多数 OHDSI 分析包要求数据在数据库中	官方 Usage Notes 明确说明
它含出院小结等文本	note 与 note_nlp 无内容	官方 Known limitations 首句
它能做液体平衡研究	inputevents 与 outputevents 未纳入转换	官方 Known limitations 与发布公告
仓库在更新所以数据在更新	仓库跑过 MIMIC 2.0 与 2.2，交付物停在 0.9	PhysioNet 版本表仅 0.9 一条
空表是下载坏了	只有列头的文件表示没有数据被转换进该表	官方 Data Description 明确说明
不需要另下词表	随包只含 20 亿以上本地概念，其余需按标准机制获取	官方 Data Description 指向 OHDSI 文档 5.1.2 节
它和 MIMIC-IV 演示库是同一批患者	官方页未声明，且两者发布时间相差一年	演示库独立项目版本表为 1.0（2022）与 2.2（2023）
用它算出的比例可以外推	100 人、单中心、时间偏移，官方定位为演示与教育	官方 Background 与 Usage Notes

FAQ

Q1：它和 MIMIC-IV 演示库是什么关系，是不是同一份数据的两种格式？

不是。两者共享"MIMIC-IV 的 100 名患者演示子集"这个上游概念，但交付时间、表结构、内容范围都不同。本数据集发布于 2021 年 6 月 21 日，彼时 PhysioNet 上独立的 MIMIC-IV 演示库项目还没有版本记录（它的 1.0 发布于 2022 年 6 月 22 日，2.2 发布于 2023 年 1 月 31 日）。官方页的 Parent Projects 列的是 MIMIC-IV v1.0 与 MIMIC-III Clinical Database Demo v1.4，而不是后来那个演示库项目。因此"两边患者是不是同一批"这个问题，官方页没有给出答案。此外内容范围也不同：本数据集明确缺失自由文本、重症输入输出与电子给药细节，而原生演示库保留的是 MIMIC 原生表。把它当作原生演示库的等价格式替换，会在多个方向上落空。

Q2：为什么只有 0.9 一个版本，是不是项目停了？

项目没停，停的是 PhysioNet 上的交付版本。官方 Release Notes 把 0.9 定义为"转换的初始版本"，并说明未来的局限修复要看项目仓库。仓库的变更记录显示 ETL 之后确实跑过 MIMIC 2.0 与 2.2，自定义词表也更新过。维护模式被明确设计成社区驱动：映射与 ETL 的持续维护预期由 OHDSI 研究者通过 PR 完成，仓库 readme 里留了审阅联系人。所以正确的理解是"代码在演进、快照没更新"，而不是"项目死亡"。引用时务必写清版本 0.9 与对应 DOI，避免读者误以为你用的是最新的开发线成果。

Q3：我想做药物相关研究，它的用药数据可靠吗？

要分两头说。一是覆盖范围：官方明确说 drug_exposure 由 prescriptions 与 pharmacy 两张表填充，而 emar 与 emar_detail 这两张电子给药记录表没有用于额外的细节抽取。这意味着用药记录覆盖的是"开了什么药、发了什么药"，而"实际什么时候给到患者、给了多少、有没有漏给"这一层细节不在里面。二是概念映射：用药在 OMOP 里按惯例落到 RxNorm 标准概念，本地编码走 20 亿以上区间再映射，官方承认部分概念未充分映射。做用药研究前，建议先查 DQD 的报告看用药相关检查项的通过情况。

Q4：波形数据在哪里，我能拿到原始波形吗？

拿不到原始波形。本数据集里的波形是以"概念验证"的形式存在的：仓库脚本遍历波形存储桶下的目录，把目录结构填进 wf_header、把 CSV 数据填进 wf_details，再由这两个源表把派生出来的测量值落到 measurement，相关发现落到 condition_occurrence。measurement_source_value 被写成"波形库参考编号.算法编号"的形式，用来保留溯源。也就是说，你得到的是"从波形算出来的数"以及"这个数来自哪个波形文件、由哪个算法算出"，而不是波形信号本身。要原始波形，走 MIMIC-IV 波形库或 MIMIC-III 波形库。

Q5：我要不要为了用它去学 OMOP CDM？

取决于你要解决的到底是什么。如果你的分析只会在 MIMIC 上跑一次、不涉及跨库复用，那直接学 MIMIC 原生结构更划算，多一层映射只多一层损失。如果你的目标是让分析代码能搬到别的机构、或者要接入 ATLAS 这类 OHDSI 工具链，那 OMOP 是必经之路，而这份数据集正是成本最低的入门实物——免申请、体积小、随包带质量报告。折中的判断标准是：看你的代码里有没有"换一家医院就要重写一遍"的部分。有，就值得学；没有，就不必为了它多绕一层。

术语表

术语	含义
OMOP CDM	Observational Medical Outcomes Partnership Common Data Model，观察性医疗结果合作组织通用数据模型，一套把不同来源医疗数据统一表示的表结构规范
OHDSI	Observational Health Data Sciences and Informatics，观察性健康数据科学与信息学，维护 OMOP CDM 与相关工具链的國際协作社区
ETL	Extract-Transform-Load，抽取-转换-加载，把源数据搬进目标模型的工程流程
concept_id	概念编号，OMOP 中一切临床语义的承载单位，标准概念来自标准词表，本地概念自分配
本地概念	源端特有编码在 OMOP 中的落地形式，按惯例分配在 20 亿以上编号区间，再映射到标准概念
标准概念	standard concept，来自 LOINC、RxNorm、ICD-10 等标准词表、可跨库直接比对的概念
ATLAS	OHDSI 的网页分析应用，用于在 OMOP 实例上做队列定义与刻画
Achilles	OHDSI 的数据刻画工具，产出聚合层面的数据画像报告
DQD	Data Quality Dashboard，OHDSI 的数据质量看板，按预设检查项对 CDM 实例逐项评分
Athena	OHDSI 的标准词表下载服务
person / visit_occurrence / visit_detail	OMOP 的三层就诊结构，分别对应患者、一次就诊、就诊内的一段
source_value	OMOP 表中保留源端原始值的列，是回源对齐的唯一可靠通道
target_domain_id	决定一条映射后的记录分发到哪张 CDM 表的域标识
ODbL 1.0	Open Data Commons Open Database License v1.0，开放数据库许可，本数据集的发布许可
波形 POC	proof of concept，把 ICU 连续波形信号转成 OMOP 离散概念的验证性工作
anchor_year / anchor_age	MIMIC 去标识化后给出的锚定年份与锚定年龄，用于推算出生年

附录 A：核心数字核对表

数字	出处
100 名患者	PhysioNet 官方页 Background 段与发布公告
版本 0.9	PhysioNet 官方页版本表，仅此一条
2021 年 6 月 21 日发布	PhysioNet 官方页 Published 行
3 个上游模块（core / hosp / icu）	官方页 Background 段
3 个交付目录	官方页 Data Description 段
29 张 CDM 表定义	ETL 仓库 etl/ddl/ddl_cdm_5_3_1.sql 的建表语句计数
10 张标准词表定义	ETL 仓库 etl/ddl/ddl_voc_5_3_1.sql 的建表语句计数
20 个 cdm_ 落数脚本	ETL 仓库 etl/etl 目录文件名清单
9 位署名作者	PhysioNet 官方页作者行
20 亿（2B）以上为本地概念区间	官方页 Methods 段
23 个自定义映射文件（22 个 gcpt_）	ETL 仓库 custom_mapping_csv 目录清单
5 步转换逻辑、8 条工作流	ETL 仓库 README 的 ETL 逻辑与工作流段
ODbL 1.0	PhysioNet 官方页 License 段
DOI 10.13026/p1f5-7x35（v0.9）	PhysioNet 官方页 Discovery 段
DOI 10.13026/2d25-8g07（latest）	PhysioNet 官方页 Discovery 段
上游 DOI 10.13026/s6n6-xd98（MIMIC-IV v1.0）	官方页 References 第 4 条
项目浏览 2260 次（当前版本）	PhysioNet 官方页 Project Views 段