笔记与表对不上账 — EHRCon 病历一致性核验集

一份出院小结里写着"心率 167，2 月 2 日"，同一家医院的结构化表里，这条心率记在 2 月 6 日。另一份小结写着"已开始阿托伐他汀"，用药表里确实有这条医嘱，药名、剂量、单位逐项对得上。第三份小结提到高血压诊断，诊断表里却查不到任何记录。这三种情况在真实的电子健康记录（EHR, Electronic Health Record）里并行存在，而且是常态——结构化表为检索、结算与统计而建，临床笔记为叙述、交接与判断而写，两套语言并不自动同步。医生录错值、复制过期清单、把事件记在错误的时间点，都会让两者分叉；分叉之后的病历既误导下一次临床决策，也误导任何基于它做的二次分析。

已有的表格事实核查基准回答不了这个问题。TabFact、INFOTABS、SEM-TAB-FACTS、FEVEROUS 都是在维基百科表格或论文表格上验证单条声明，表小、领域单一、且默认证据方无错；电子病历里的问题恰好相反——表可能错，笔记也可能错，没有一方是天然基准，而且待查的不是一条声明，是整篇笔记里散落的几十个实体。

EHRCon 是专门为这个 gap 造的第一份公开基准。韩国科学技术院（KAIST）团队联合临床医生，从 MIMIC-III 里随机抽出 105 篇超过 800 token 的临床笔记，让标注者逐实体写下 SQL、跑在真实的 MIMIC-III 库上，把 4,101 个实体判为 CONSISTENT 或 INCONSISTENT，并记下不一致具体落在哪张表哪一列。它同时给出原始 MIMIC-III schema 与 OMOP CDM schema 两个版本，配套一个八阶段的大语言模型流水线 CheckEHR。它的规模不大，粒度却极细——不是"这篇笔记有没有问题"，而是"这句里的这个体温值，与 labevents 表第几列对不上"。一屏速览见下表。

维度	内容
全名	EHRCon: Dataset for Checking Consistency between Unstructured Notes and Structured Tables in Electronic Health Records
发布方	PhysioNet；数据由 KAIST 主导，联合 Samsung Medical Center 与 MIT 构建
首次发布	2024 年 8 月 19 日，版本 1.0.0
最近版本	2025 年 3 月 19 日，版本 1.0.1（新增 Check_DB 与 Almost_Consistent 两个字段）
上游数据	MIMIC-III Clinical Database v1.4（Parent Project），贝斯以色列女执事医疗中心 2001–2012 年约四万名 ICU 患者
笔记数	105 篇，随机抽取且长度超过 800 token
标注实体数	4,101 个（官方页 Data Description 段与代码仓库摘要写作 3,943，见 §10）
对照结构化表	13 张 MIMIC-III 表（9 张事件表 + 4 张字典表）
笔记类型	出院小结 38 篇、医生记录 33 篇、护理记录 34 篇
标签	每个实体 CONSISTENT 或 INCONSISTENT，附带不一致的表名与列名
标注粒度	实体级；实体分 Type 1（数值）/ Type 2（存在性）/ Type 3（字符串值）三类
schema 版本	原始 MIMIC-III schema 与 OMOP CDM 两套并存
文件格式	标注为 Python pickle（.pkl，按住院号命名），笔记为 CSV；配套逐患者 SQLite 库由脚本构建
数据划分	test 83 篇 / valid 22 篇；无 train 划分
许可	PhysioNet Credentialed Health Data License 1.5.0，需 CITI 培训与 DUA
典型用途	病历内部矛盾自动发现、表格事实核查跨域迁移、Text-to-SQL 真实场景评测、大语言模型临床推理基准

§1 它要解决的具体麻烦

1.1 两套语言为什么会分叉

电子病历里住着两套数据。结构化表是按字段设计的：检验值在 labevents，生命体征在 chartevents，医嘱在 prescriptions，诊断编码在 diagnoses_icd。它们的价值是可检索、可聚合、可跨患者比较，代价是表达力有限——一个数值进得去，"血压呈下降趋势"这种判断进不去。临床笔记刚好相反：它写得下判断、推理、时序与不确定性，代价是不可检索、不可聚合，且写法因人而异。

两者理论上应该互相印证。实践中的衔接却是人工的：医生看完检验结果，写出诊断与处置，再由某个人（常常不是同一个人）把结论录入结构化字段。这个链条上每一环都可能断。官方页 Background 段给出的成因清单很直接——EHR 界面往往按行政与财务任务而非临床文书流程设计，负担过重的医护可能导入错误的用药清单、复制粘贴过期记录、或录入不准确的检验结果。

断链的后果不是学术问题。诊断与用药信息出错会直接落到患者身上，也会带来法律层面的风险；而对研究者来说，用一份内部自相矛盾的病历做二次分析，得到的结论同样站不住。人工逐条核对海量关系库既慢又贵，于是"自动查账"成为刚需——这正是 EHRCon 要支撑的能力。

值得把"自动查账"和相邻任务区分开。它不等于信息抽取：抽取只管从笔记里把值提出来，不问库里有没有；也不等于 Text-to-SQL：问句转 SQL 只管生成可执行的查询，不问查询结果的临床含义。一致性核验要求三件事连做——先判断笔记里哪些话是可核的，再把它翻译成对库的查询，最后比对查询结果并说清差在哪一列。任何一环缺席，任务就退化成前两者之一，也就失去了它特有的难度。

1.2 三条常见的错误期待

第一条，期待它是一份"标注好了错误病历"的语料，可以直接监督训练。它不是。4,101 个实体、105 篇笔记、且官方明确只给了 test 与 valid 两级划分、没有 train 划分。它天生是评测集，不是训练集。

第二条，期待标签能指出"笔记错了还是表错了"。它不能。官方在论文里把这一点讲得很清楚：传统事实核查判定 Supported 或 Refuted，前提是证据方无错；而在 EHR 里表与笔记都可能错，无法把任一方定义为基准证据，因此只能用 CONSISTENT / INCONSISTENT 这种对称表述。拿到一个 INCONSISTENT，你只知道两边对不上，不知道哪边是对的。

第三条，期待它是通用领域的事实核查集。它不是。它绑定 MIMIC-III 的 schema，实体范围被限定在 13 张表能覆盖的临床事件内；脱离这个 schema，标注就失去意义。想做跨领域迁移，它提供的是 “MIMIC-III vs OMOP CDM” 这一组同数据不同 schema 的对照，而不是跨领域的对照。

1.3 它能给到的与给不到的

你的需求	它给的	够不够
实体级一致性判定的评测集	4,101 个实体，逐实体 CONSISTENT / INCONSISTENT	够，且附带不一致的表与列，可做可解释性分析
端到端"自动查账"系统的打分板	官方给出 CheckEHR 基线的召回、精确率与交集分数	够，且基线成绩本身说明任务难度
Text-to-SQL 的真实场景评测	标注过程留下 all_queries 与 27 个经校验的 SQL 模板	可做，但模板是人写的核对查询，不是自然语言问答对
跨 schema 泛化研究	同一批标注同时适配 MIMIC-III 与 OMOP CDM	够，这是它最独特的设计
训练一个矛盾检测模型	105 篇笔记、无 train 划分	不够，量级与划分都不支持监督训练
判断"笔记错还是表错"	标签是对称的 CONSISTENT / INCONSISTENT	不够，官方明确无此区分
患者级或住院级结论	实体分布在 105 篇笔记上，未公布患者数	不够，需自行按住院号归并并说明口径
药物不良事件、结局预测	无任何结局变量	不够，标签只描述笔记与表是否一致

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

你的处境	它能帮你什么	下一步该做什么
你在做表格事实核查，想找个真实、大规模关系库的场景	从维基百科表格跳到真实 EHR：13 张表、四万名患者规模的底层库	先用 OMOP 版跑一遍，再跑 MIMIC-III 版，比较 schema 差异造成的落差
你在做病历质控，想量化"笔记与表对不上"到底有多常见	官方给出了不一致的落点分析（哪类笔记、哪些表、哪些列）	直接引用论文 §3.4 的官方数字，别自己从文件里重算
你在评测大语言模型的长文本推理	整篇笔记、上下文长、需分段、需多跳——正是难点所在	参考 CheckEHR 的八阶段拆分，先把分段与实体识别分开计分
你在做 Text-to-SQL，苦于基准都是单表短问句	真实 schema、真实外键、真实时间条件的查询	用 all_queries 里的查询做参照，注意它们是核对查询而非分析查询
你想复现或改进 EHR-ReasonCon 那条线	它是上游初版，源笔记同一组 105 篇	先读 §6.2 的判别表，确认你要的是表层匹配还是推理密集型核验
你在教临床信息学，需要一个"病历也会自相矛盾"的实例	官方图 1 给了三个可直接搬进课件的最小案例	用时间与数值两个维度各举一例，重点讲"无法确定谁错"

1.5 一句话判断

它不是一份更大的训练语料，而是一把更细的尺子：把"笔记与表对不上"这件事从一篇笔记的模糊印象，量到了具体实体、具体表、具体列。

1.6 不适合谁：四条边界

不适合拿来做监督训练。 105 篇笔记、无 train 划分、标签只有两个值。任何想用数据量换性能的路线都会在这里碰壁，官方自己的用法也是"评测 CheckEHR"而不是"训练 CheckEHR"。

不适合拿来判断责任归属。 INCONSISTENT 不代表笔记错。MIMIC-III 本身经过去标识与预处理，官方在 Limitations 段明确说这些预处理可能引入了真实 EHR 里并不存在的不一致。把标签当成"医生写错了"的证据，是误用。

不适合拿来做跨机构泛化结论。 底层是单一医疗中心、单一国家、单一时间段（2001–2012）的 ICU 数据。它刻画的是这一套系统与这一批书写者，不是一个普适的不一致发生率。

不适合在没拿到 MIMIC-III 授权的情况下使用。 标注文件本身不含患者数据，但复现一致性判定必须跑 SQL，就必须有 MIMIC-III。EHRCon 是派生资源，门槛继承上游（§5.1）。

§2 数据构成与规格

2.1 两棵目录：original 与 processed

官方页 File Structure 段给出的结构是一棵两层分叉的树。根目录下有 dataset（官方页写作 base）与 database 两个子目录，前者放标注与笔记，后者放逐患者的 SQLite 库文件。

EHRCon
├── dataset
    ├── original
        ├── test
            ├── discharge
                ├── discharge_label
                    └── EHRCon_{hadm_id}_data.pkl
                └── discharge_test.csv
            ├── nursing
            └── physician
        └── valid
    └── processed
└── database
    └── _.db

两个分支的差别在笔记文本本身：original 用 MIMIC-III 的原始笔记做一致性检查，processed 则已过滤掉笔记里在 EHR 表中不可能出现的部分——主要是入院前病史与未来治疗计划。作者的判断很实际：这两类内容天然无从核对，留着只会制造噪声。

original 与 processed 之下结构完全相同，各有 test 与 valid 两级，每级再分 discharge、nursing、physician 三个目录。标注文件是 pickle，命名带住院号（hadm_id）；CSV 文件装笔记文本。

2.2 标注文件的字段字典

每个 .pkl 是一个嵌套字典，顶层键是笔记的 ROW_ID，值是一串实体记录。字段如下：

字段	取值形态	含义	使用注意
Row_id	整数，字典顶层键	该篇临床笔记在 MIMIC-III NOTEEVENTS 中的 ROW_ID	是定位笔记的主键，与 hadm_id 不是一回事
entity	字典，键为实体名	本次一致性检查的主体，如某个检验项、某种药	键名是标注者写下的实体字符串，未做标准化
data	列表，元素为 {表名: {列名: 值}}	从笔记中抽出、并映射到表列上的值	这是"笔记说了什么"的结构化表示
label	字符串	一致性判定；若不一致，写明哪几列不一致，如 "charttime" and "valuenum" are inconsistency	不是枚举值，是可读文本，需自行解析
errors	整数	出现不一致的列数	0 对应 CONSISTENT；大于 0 对应 INCONSISTENT
position	整数或字符串	实体在笔记中的行号	用于把判定回溯到笔记原文位置
source	字符串 mimic	数据来源标记	用于区分 MIMIC-III 与 OMOP 版本时的溯源
entity type	1 / 2 / 3	1 数值实体；2 无值但存在性可核；3 字符串值实体	Type 3 收录但未进入主实验
all_queries	列表	判定该实体时实际执行过的全部取值对	复现判定过程的关键证据
Check_DB	yes / no	v1.0.1 新增；标记需要查库或查指南才能确定的情形	例如 “1 tab” 到底是剂量还是单位
Almost_Consistent	yes / no	v1.0.1 新增；标记差异小于 0.01% 的"几乎一致"	阈值来自官方定义，不可自行放宽

errors 与 label 是一对互补设计：errors 给机器用的计数，label 给人读的说明。这也是它在可解释性上比一般二分类基准强的地方——你不仅能知道这个实体不一致，还能知道不一致落在哪一列，以及判定过程中跑过哪些查询。

2.3 十三张表：九张事件表加四张字典表

表的入选不是拍脑袋定的。论文附录 B.1.2 记录了选表过程：先随机抽 300 篇笔记（出院小结、护理记录、医生记录各 100 篇）分析其中出现的实体，再反推需要哪些表才能覆盖，最终定为 13 张，其中 4 张是字典表。

表名	角色	装的是什么
chartevents	事件表	床旁生命体征与观察值
labevents	事件表	实验室检验结果
prescriptions	事件表	医嘱用药
inputevents_cv	事件表	输入量记录（CareVue 系统）
inputevents_mv	事件表	输入量记录（MetaVision 系统）
outputevents	事件表	输出量记录
microbiologyevents	事件表	微生物学培养与药敏
diagnoses_icd	事件表	ICD 诊断编码
procedures_icd	事件表	ICD 操作编码
d_items	字典表	chartevents 等表的项目名称字典
d_labitems	字典表	检验项目名称字典
d_icd_diagnoses	字典表	ICD 诊断编码的短标题与长标题
d_icd_procedures	字典表	ICD 操作编码的短标题与长标题

四张字典表的作用是消解"缩写—全称—商品名—通用名"之间的鸿沟。笔记里写 Temp、体温、Tylenol、对乙酰氨基酚，指的是同一件事，但在库里落在不同的 itemid 上。官方为此专门做了一个 Item Search Tool：用 C4-WSRS 医学缩略语数据集收集缩写—全称对，用 GPT-4（0613）从笔记里抽出商品名并转成通用名，合成候选集后再与库内 itemid 做二元组余弦相似度匹配，超过阈值即召回。

2.4 一个实体的完整解剖

官方给出的 JSON 样例是最直接的说明书：

#-- 官方页给出的 EHRCon 单条记录结构（示意）
{
  "Row_id": [
    {
      "entity": {
        "data": [{"table_name1": {"column_name1": "value"}}],
        "label": '"charttime" and "valuenum" are inconsistency',
        "errors": 2
      }
    }
  ],
  "position": "4",
  "source": "mimic",
  "entity_type": "1",
  "Check_DB": "yes",
  "Almost_Consistent": "yes",
  "all_queries": []
}

把它翻译成一句人话：这篇笔记（ROW_ID 已知）的第 4 行出现了一个实体；它是 Type 1 实体，也就是带数值的实体；标注者把笔记里的值映射到 table_name1 的 column_name1 上，生成并执行了查询；结果有两列对不上，charttime 与 valuenum，所以 errors 是 2，标签是 INCONSISTENT；判定过程跑过的取值对全部收进 all_queries；Check_DB 为 yes 说明这个实体需要查库或查指南才能确定含义；Almost_Consistent 为 yes 说明实际差异在 0.01% 以内，属"几乎一致"。

这条记录浓缩了整个任务的定义：给一篇笔记和一个数据库，找出笔记里可核对的实体，把它们映射到表列，写 SQL 去查，看是否对得上，对不上就说清哪几列对不上。

2.5 标注 schema：三类实体、两个标签、三种时间

实体类型决定了"核对到什么程度算完事"。

类型	定义	例子	是否进入主实验
Type 1	带数值的实体	temp - 99.9，WBC - 9.6	是
Type 2	无数值，但存在性可在库中核实	Lasix was started，WBC was tested	是
Type 3	带字符串值的实体	Lasix increased，BP was stable，WBC changed from 1 to 5	否，仅收录

Type 3 被排除的理由很有说服力：字符串值在库里的表示方式太多，"BP was stable"在值列里可能是 Stable、可能是 Normal，也可能根本没有对应值而只有一组数值表示。这种可变性会直接转化为标注错误，所以作者把它收进数据集但不用于主实验——对后来的使用者来说，这是一个明确的"这块地有坑"的标记。

时间表达式被单独拎出来处理，因为它是这类任务最容易出错的维度。官方把它分成三类：

时间表达式类别	判定口径
标准格式（YYYY-MM-DD 或 YYYY-MM-DD HH:MM:SS）	校验该时间戳上是否确有此事件
叙述式（“入院前后”“出院后不久”）	取指定日期前后一天内的记录
未写明时间	按笔记类型定：出院小结看整段住院期，医生与护理记录看记录日期前后一天

这个口径差异有实际后果。同样是"患者用了万古霉素"，写在出院小结里要拿整个住院期去查，写在护理记录里只查前后各一天，查不到就判不一致——同一个事实在不同笔记类型下可能得到不同标签。

2.6 两个 schema 版本：MIMIC-III 与 OMOP CDM

EHRCon 的另一半价值在 schema 对照。OMOP CDM（Observational Medical Outcomes Partnership Common Data Model）是观察性健康数据的公开标准，用来把不同来源的数据统一成同一套表结构。作者使用了 MIT-LCP 发布的 MIMIC-OMOP 实现，把 MIMIC-III 的表与列映射到 OMOP 的表与列。

MIMIC-III 表	关键列	对应 OMOP 表	对应 OMOP 列
chartevents	charttime / valuenum / valueuom	Measurement	measurement_datetime / value_as_number / unit_source_value
labevents	charttime / valuenum / valueuom	Measurement	measurement_datetime / value_as_number / unit_source_value
outputevents	charttime / valuenum / valueuom	Measurement	measurement_datetime / value_as_number / unit_source_value
microbiologyevents	charttime / org_name / spec_type_desc	Measurement、Specimen、Concept	measurement_datetime、specimen_datetime、concept_name
inputevents_mv	starttime / endtime / amount / rate	Drug_exposure	drug_exposure_startdate / drug_exposure_enddate
inputevents_cv	charttime / amount / rate	Drug_exposure	drug_exposure_startdate / drug_exposure_enddate
prescriptions	startdate / enddate / drug	Drug_exposure、Concept	drug_exposure_startdate / drug_exposure_enddate / concept_name
d_items、d_labitems	label	Concept 等	概念名
d_icd_diagnoses、d_icd_procedures	short_title / long_title	Concept 等	概念名

因为 OMOP 版是从 MIMIC-III 派生的、承载同一批患者信息，MIMIC-III 上标注好的实体标签可以直接套用到 OMOP 上，不需要重标。作者在核对时发现 MIMIC-OMOP 里存在用药开始时间晚于结束时间的记录，做了对调修正——这个细节提示了一件事：连标准化实现本身也可能有数据质量问题。

值得注意的是实验结论。按常理 OMOP 结构更规整、表更少，应该更好查；官方报告的结果是 OMOP 版表现与 MIMIC-III 版相当甚至更差，原因是 OMOP 把值、单位、规格压进同一个字段（例如一整串 “Cipralex 10mg tablets (Sigma Pharmaceuticals Plc) 28 tablets”），实体反而更难拆。

§3 它是谁的数据

3.1 贡献者与机构

作者	机构（PhysioNet 页面标注）	角色线索
Yeonsu Kwon	KAIST	共同第一作者，代码仓库所有者
Jiho Kim	KAIST	共同第一作者
Gyubok Lee	KAIST	作者
Seongsu Bae	KAIST	作者
Daeun Kyung	KAIST	作者
Wonchul Cha	Samsung Medical Center	临床侧
Tom Pollard	MIT	作者
Alistair Johnson	MIT（项目官网列为 University of Toronto）	作者
Edward Choi	KAIST	通讯作者

机构构成决定了这份数据的性格：KAIST 提供机器学习与自然语言处理的方法，Samsung Medical Center 提供临床视角，MIT 侧的两位作者长期参与 MIMIC 系列与 PhysioNet 的建设。论文引言里提到，标注指令由一位具有十五年以上经验的临床医生与 AI 研究者共同设计，这不是客套——整份数据的判定口径（哪些实体该抽、时间怎么算、差异到什么程度算一致）都是临床口径而非算法口径。

官方页面把 Tom Pollard 与 Alistair Johnson 均标注为 MIT，项目官网则把 Johnson 标注为 University of Toronto。这一处差异不影响数据本身，引用作者机构时以你引用的那一版为准。

3.2 时间线

时间	事件
2023 年 4 月	标注工作开始（论文 Datasheet 的采集时间跨度）
2024 年 4 月	标注工作结束
2024 年 6 月 24 日	arXiv 预印本 v1 发布（arXiv:2406.16341）
2024 年 8 月 19 日	PhysioNet v1.0.0 首次发布
2024 年 12 月 30 日	arXiv v2 修订
2024 年	论文收录于 NeurIPS 2024 Datasets and Benchmarks Track
2025 年 3 月 19 日	PhysioNet v1.0.1 发布，新增 Check_DB 与 Almost_Consistent 字段

v1.0.1 的两个新增字段值得单独说。它们都不是"补漏"，而是标注者在实践中撞到的两类边界：一类是需要查库或查指南才能确定含义的实体（“1 tab” 究竟是剂量还是单位），另一类是数值差异极小、实质上可以认为一致的实体（差异小于 0.01%）。把它们显式标记出来，等于把"标注者当时犹豫过"这件事也交给了使用者。

3.3 标注现场：从一句笔记到一条 SQL

标注流程分六步，官方在图 2 与 Methods 段给了完整描述：

1. 通读笔记，配合网络检索与 GPT-4（0613）讨论，识别实体与相关信息；
2. 用 Item Search Tool 找库内相关 item，找不到就人工匹配；
3. 选定实体关联的表；
4. 从笔记中抽出日期、数值、单位等信息，生成 SQL 并执行；
5. 若查询无结果，逐条屏蔽 SQL 条件再执行，定位不一致究竟出在哪一列；
6. 遇到指令未覆盖的边界情形，讨论后更新指令；全部标完再做一轮后处理，按最终指令补标，并删除对不齐的实体。

第 5 步是这套流程的核心技巧。一次查询无结果只说明"没查到"，不能说明"哪里不对"；只有把条件逐条摘掉再查，才能分辨是时间对不上、值对不上，还是实体本身就不在库里。这正是 label 字段能写出 “charttime and valuenum are inconsistency” 的原因。

为了保证查询质量，作者先设计了 27 个 SQL 模板，由两位作者逐一校验——模拟可能生成的查询并与底层库交叉核对结果。标注者基于这些模板生成具体查询，这既降低了 SQL 出错率，也让不同标注者的查询风格保持可比。

3.4 数据来源的四个层次

层次	内容	谁负责
第一层	贝斯以色列女执事医疗中心 2001–2012 年 ICU 原始诊疗记录	原医疗机构
第二层	MIMIC-III v1.4：去标识、日期平移、结构化表 + NOTEEVENTS 笔记	MIT LCP
第三层	EHRCon：105 篇笔记的实体级一致性标注	KAIST 等
第四层	派生物：OMOP CDM 版本、以及后续的推理密集型增强版本	见 §6.2

每一层都引入了前一层没有的东西。第二层的去标识与日期平移让数据可用，官方也在 Limitations 里承认它可能引入真实系统里不存在的不一致；第三层把"一致性"变成可标注的对象；第四层则把同一批标注向不同 schema 与不同难度延展。用这份数据做结论时，必须说清结论落在哪一层。

§4 它最独特的东西

EHRCon 病历一致性核验集真正稀缺的地方有三处：它挂在真实的全量关系库上而不是小表格上；它拒绝预设证据方无错，因此标签是对称的；它把判定过程也一并公开，让每一个标签都能追溯到具体的查询与具体的列。下面逐条展开。

4.1 与已有表格事实核查基准的差别

基准	证据源	核验对象	默认前提	规模量级
TabFact	维基百科表格	单条声明	表正确，判断声明真伪	大规模声明
INFOTABS	维基百科信息栏	单条假设	表正确	中等
SEM-TAB-FACTS	科学论文表格	单条声明	表正确	中等
FEVEROUS	维基百科文本与表格	单条声明	证据正确	大规模
EHRCon	真实 EHR 关系库（13 张表）	整篇笔记中的全部可核实体	双方都可能错	105 篇 / 4,101 实体

差别有三处是实质性的。其一，证据规模：前四者的表通常只有几十行，MIMIC-III 是四万名 ICU 患者的全量关系库。其二，前提：前四者默认证据方无错，EHRCon 明确否认这一点，因此标签是对称的 CONSISTENT / INCONSISTENT 而非 SUPPORTED / REFUTED。其三，核验对象的生成方式：前者给定声明要你判，后者要先从整篇长文本里把该核的实体抽出来再判——实体识别本身就吃掉了一大截性能。

4.2 官方给出的不一致落点

论文 §3.4 给了三组可以直接引用的数字，全部出自官方：

落点	官方数字	含义
笔记类型	出院小结贡献 727 / 1,168 例不一致	出院小结在全部不一致中占主要部分
表	labevents 占 36.55%	检验表是最容易与笔记对不上的表
表	用药相关表合计 17.58%	包括 prescriptions 等
列	与时间相关的差异占 56.16%	不一致更多发生在时间而非数值
时间差异	其中 58.23% 是一小时之差	提示可能来自系统而非人为

作者的解释也值得一读。出院小结之所以不一致多，是因为它写在出院时刻、要汇总整段住院的主要事件与处置，时间跨度长、信息密度高；而护理记录与医生记录是事件发生时即时写的。时间差异集中在一小时这个量级，则更像系统问题——时区、班次切换、录入时间戳的口径不一，而不是人写错了数。

这几组数字是论文正式发表的统计，可以引用；但请注意它们的口径是论文表 1 的 4,101 实体全集，不是 processed 目录下的 3,943 实体。

4.3 案例：三类不一致各有各的难法

官方图 1 给了三个最小案例，恰好覆盖三种难法：

案例	笔记写的	表里记的	判定	难在哪
时间不一致	2 月 2 日心率 167	同一心率记在 2 月 6 日	INCONSISTENT	值对得上，时间对不上；要按时间表达式规则定窗口
完全一致	使用阿托伐他汀	药名、剂量、单位均一致	CONSISTENT	需要跨商品名/通用名匹配，并逐列核对
存在性缺失	提到高血压诊断	诊断表中查不到	INCONSISTENT	实体存在但库中无记录；属于 Type 2 场景

第三个案例最容易被误读。表里查不到，可能是笔记写错了，也可能是录入漏了，还可能是编码口径不同（临床诊断与 ICD 编码之间本就有映射损失）。EHRCon 的标签只负责记录"对不上"，不负责归因。

4.4 标注质量的证据：两个系数

官方在附录 E 里给了质量控制的具体做法与结果：不用众包，用发表过医疗 AI 论文、熟悉 MIMIC-III schema 与 SQL 的研究者做标注；标完之后，四位标注者对每种笔记类型各抽查 20 篇做交叉核对，其余笔记按交叉核对中解决的关键问题统一修正。结果是实体识别的 F1 为 0.880，双方都识别出的实体中标签一致的比例为 0.938。

这两个数字要分开读。0.880 说的是"哪些东西该被标出来"这一层有分歧——实体边界、粒度、是否属于 13 张表的覆盖范围，主观性较强。0.938 说的是"标出来之后判它对不对"这一层分歧较小——因为判定最终落到 SQL 执行结果上，相对客观。对使用者来说这意味着：如果你的系统在这份数据上表现不好，先分清楚是死在实体识别还是死在判定，这两段的改进路径完全不同。

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

口径一：实体范围。 标注指令明确把实体限定在 9 张事件表能覆盖的范围内，且必须是"发生在入院与笔记记录时间之间"的事件。笔记里写的院前史、家族史、未来计划都不在范围内——processed 目录已经把它们过滤掉，original 目录保留但对应部分无从核对。

口径二：时间窗口。 同一个事实在不同笔记类型下的查询窗口不同（§2.5）。跨笔记类型比较不一致率时，必须先确认窗口口径一致。

口径三：极小的数值差异。 Almost_Consistent 把小于 0.01% 的差异标记为"几乎一致"。这个阈值是官方定的，如果你的应用场景对精度更敏感，应当把这部分单列出来而不是直接并入 CONSISTENT。

口径四：Type 3 实体。 字符串值实体已收录但官方未用于主实验。把它并入评测会让结果不可比。

§5 怎么拿到

5.1 获取门槛与目录面

EHRCon 是派生资源，门槛继承 MIMIC-III。官方页 Access 段写明三件事：只有完成凭证认证的登录用户可以访问文件；许可为 PhysioNet Credentialed Health Data License 1.5.0；需完成 CITI “Data or Specimens Only Research” 培训并签署 PhysioNet Credentialed Health Data Use Agreement 1.5.0。

步骤	做什么	在哪做
1	注册 PhysioNet 账号	physionet.org/register/
2	申请并完成凭证认证（credentialing）	physionet.org 凭证申请流程
3	完成 CITI Data or Specimens Only Research 培训	physionet.org/about/citi-course/
4	签署 MIMIC-III 的 DUA	https://physionet.org/content/mimiciii/1.4/
5	签署 EHRCon 的 DUA 并下载	https://physionet.org/content/ehrcon-consistency-of-notes/1.0.1/
6	构建逐患者 SQLite 库	仓库自带 make_database.py

第 6 步不能省。标注文件只记录"抽出了什么值、判成了什么"，复现判定必须真的执行 SQL，因此需要本地库。仓库的 README 给出的做法是把下载内容放进 dataset/，再建 dataset/database/ 目录并运行 make_database.py。

需要提醒的是：PhysioNet 的文件目录（/files/...）对部分地区直接返回 403，核验过程中未能逐文件列出官方目录，目录结构依据官方页 File Structure 段与代码仓库 README 两处相互印证（§10）。

5.2 批量下载

#-- 凭据访问资源必须带账号下载；-r 递归，-np 不回溯父目录
wget -r -N -c -np --user YOUR_USER --ask-password \
  https://physionet.org/files/ehrcon-consistency-of-notes/1.0.1/

#-- 只取标注文件与笔记 CSV，可限定后缀
wget -r -N -c -np -A "*.pkl,*.csv" --user YOUR_USER --ask-password \
  https://physionet.org/files/ehrcon-consistency-of-notes/1.0.1/

5.3 加载标注与笔记

import pickle
import pandas as pd

#-- 一个住院号对应一个标注文件
with open("EHRCon_123456_data.pkl", "rb") as f:
    data = pickle.load(f)

notes = pd.read_csv("discharge_test.csv")

print(type(data), len(data))          #-- 顶层键是 ROW_ID
print(notes.columns.tolist())

pickle 是 Python 版本敏感的二进制格式，跨版本加载可能失败；官方推荐环境为 Python 3.8。若只需做统计分析，建议先把 pickle 摊平成 DataFrame 再另存为 parquet 或 CSV（§5.4），后续流程就不再依赖原始 Python 版本。

5.4 摊平成实体级表

import pickle
import pandas as pd


def flatten(pkl_path):
    #-- 原始结构是三层嵌套：ROW_ID -> 实体记录 -> 实体名
    with open(pkl_path, "rb") as f:
        raw = pickle.load(f)
    rows = []
    for row_id, items in raw.items():
        for item in items:
            for ent, payload in item.get("entity", {}).items():
                rows.append({
                    "row_id": row_id,
                    "entity": ent,
                    "label": payload.get("label"),
                    "errors": payload.get("errors"),
                    "data": payload.get("data"),
                    "position": item.get("position"),
                    "entity_type": item.get("entity_type"),
                    "check_db": item.get("Check_DB"),
                    "almost": item.get("Almost_Consistent"),
                    "n_queries": len(item.get("all_queries") or []),
                })
    return pd.DataFrame(rows)


df = flatten("EHRCon_123456_data.pkl")
print(df.head(5).to_string())

摊平之后有一个必须立刻做的判断：label 是自由文本而非枚举值。建议以 errors 为准派生 CONSISTENT（errors 为 0）与 INCONSISTENT（errors 大于 0），把 label 只当作解释文本；反过来从 label 里做字符串匹配去推标签，会踩到官方自己举的反例——label 里出现 “inconsistency” 这个词的形态并不唯一。

5.5 复现判定：SQL 模板长什么样

SELECT *
FROM Chartevents
JOIN d_items ON Chartevents.itemid = d_items.itemid
WHERE strftime('%Y-%m-%d', Chartevents.charttime) = '{date_value}'
  AND {condition_values};

这是官方 27 个模板中的一个。它的形状说明了三件事：核对总是按 hadm_id 限定在同一住院内；时间条件套在 strftime 上做日期级比较；值条件由 {condition_values} 留出填入位置，由标注者从笔记里抽出的值与单位填充。prescriptions 与 inputevents_mv 这类同时有起止时间的表，模板会展开成区间条件，这也是它们的时间判定窗口与 chartevents 不同的原因。

5.6 五个最容易出错的地方

一、把 label 当枚举字段。 它是可读文本，errors 才是计数。用 errors 派生标签。

二、忘记限定住院范围。 所有核对都发生在同一次住院内；跨住院匹配会造出大量假的不一致。

三、混用 original 与 processed 的笔记文本。 position 是行号，两个版本的笔记文本不同，行号不通用。用哪个版本的标注就必须用哪个版本的 CSV。

四、把 Type 3 实体计入评测。 官方明确未用于主实验，纳入会让你的数字与任何公开结果不可比。

五、拿它训练而不评测。 无 train 划分、105 篇笔记。官方自己的用法是评测 CheckEHR，不是训练。

六、忽略逐患者库的版本。 复现判定依赖本地 SQLite 库，库是用脚本从 MIMIC-III 现场构建的；脚本或上游版本一变，查询结果就可能变，all_queries 里的历史结果也要跟着重新解释。

七、只报一个总分。 实体识别与一致性判定是两层，难度不同、改进路径也不同（§7.2）。只报总分会把第一层的失败掩盖成第二层的失败。

5.7 一个最小评测骨架

import pandas as pd

#-- 以 errors 派生标签，避免解析 label 文本
def to_binary(df):
    df = df.copy()
    df["gold"] = df["errors"].apply(lambda e: "INCONSISTENT" if e and int(e) > 0 else "CONSISTENT")
    return df

#-- 主实验口径：排除 Type 3，单列 Almost_Consistent
def main_split(df):
    core = df[df["entity_type"].astype(str) != "3"].copy()
    core["flag_almost"] = core["almost"].astype(str).str.lower().eq("yes")
    return core

gold = to_binary(flatten("EHRCon_123456_data.pkl"))
gold = main_split(gold)
pred = gold[["row_id", "entity", "gold"]].copy()
pred["pred"] = "CONSISTENT"   #-- 全判一致的底线基线，替换成你的系统输出

tp = ((pred["gold"] == "INCONSISTENT") & (pred["pred"] == "INCONSISTENT")).sum()
print("召回分子", tp, "总实体", len(pred))

这段代码只演示口径，不给任何系统成绩。它要强调的仍然是那两件事：标签必须从 errors 派生，Type 3 必须在主实验里排除。

§6 与库内条目的关系

6.1 关系图谱

关系	站内条目	说明
上游母库	mimic-iii	全部笔记与结构化表的来源，EHRCon 的 Parent Project
下游增强版	ehr-reasoncon	沿用同一组 105 篇笔记，重做成推理密集型版本，见 §6.2
同主题·SQL 侧	ehrsql	同为 KAIST EdLab 线的 EHR Text-to-SQL 基准，问句—SQL 形态不同
同主题·合成对照	synsum	用结构化表生成临床笔记，方向相反
同主题·笔记问答	ehr-notes-qa-llms	基于出院小结的大模型评测基准
同主题·笔记结构	medsecid	MIMIC-III 笔记的章节识别标注
同主题·语料规模	mimic-ext-synnotes	十亿词级合成笔记语料，规模路线与它相反
同主题·多表问答	ehrxqa	MIMIC-IV 多表问答，任务形态不同
同主题·证据落地	archehr-qa-bionlp-task-2025	患者提问—笔记证据，另一类证据对齐任务

6.2 与 EHR-ReasonCon（rid 1007）的判别：初版与推理密集型增强版

这是最容易被混淆的一组。二者同团队、同主题、甚至共用同一组源笔记，但它们是两份独立发布的数据集：不同的 PhysioNet 资源页、不同的版本号、不同的 DOI、不同的论文、不同的规模与标注 schema。

维度	EHRCon（本页）	EHR-ReasonCon（站内 rid 1007）
官方全名	EHRCon: Dataset for Checking Consistency between Unstructured Notes and Structured Tables in Electronic Health Records	EHR-ReasonCon: Reasoning-Intensive Consistency Verification Between Clinical Notes and Structured Tables in Electronic Health Records
PhysioNet 版本	v1.0.1（首版 v1.0.0）	v1.0.0
DOI	10.13026/m4vd-y789	10.13026/7m91-3010
发布时间	2025-03-19（首版 2024-08-19）	2026-09-15
源笔记	MIMIC-III v1.4 随机抽 105 篇	沿用 EHRCon 的同一组 105 篇
标注实体数	4,101	8,042
对照表数	13（9 事件表 + 4 字典表）	14
标注字段	Row_id / entity / data / label / errors / position / entity_type / all_queries / Check_DB / Almost_Consistent	锚实体 + 推理密集型重标注
主打难点	实体识别 + 值与时间的精确匹配	医学解读、事件关系推理、时序变化分析
配套系统	CheckEHR（八阶段 LLM 流水线）	EHR-INSPECTOR（分段→抽锚实体与时序引用→工具查表验证）
评估建议	以召回、精确率、交集分数报告	建议语义级实体级评估，不推荐精确字符串匹配
团队	KAIST + Samsung Medical Center + MIT	KAIST + Ghent University + Samsung Medical Center + Samsung Changwon Hospital + Asan Medical Center
关系	初版	派生增强版（Parent Projects 明确列出 EHRCon v1.0.1 与 MIMIC-III v1.4）

一句话区分：EHRCon 问"表里有没有这个值"，EHR-ReasonCon 问"笔记里这个临床判断，能不能被表里的证据推理地支持"。 前者的典型难题是心率 167 记在了错误的日期；后者的典型难题是"贫血"需要解读血红蛋白值才能确认，"抗生素敏感性"需要连接多个微生物学字段，"血压下降趋势"需要检视多个时间点的测量。

实体数从 4,101 涨到 8,042，不构成"同一份数据扩量"的关系：后者是在同一组笔记上按五阶段、专家引导的流水线重新标注，锚实体的定义、粒度与判定口径都变了。因此二者不可拼接、不可互相替代，也不适合拿一方的结果去反驳另一方。选题时的判据只有一条：你要测的是表层数值/存在性匹配，还是需要医学解读与时间推理的一致性判断。

6.3 检索路径与分工判据

你想做的事	该用哪个	判据
评测"值/时间对不对得上"的自动查账	EHRCon	标签落在具体表与列，可解释性强
评测"临床判断是否被证据支持"	EHR-ReasonCon（rid 1007）	需推理的案例只有后者系统覆盖
做中文/多语言的病历矛盾检测	二者都不合适	均为英文、单一医疗中心
需要大规模训练语料	mimic-ext-synnotes	规模路线，无一致性标注
需要问句—SQL 的监督信号	ehrsql	它给的是核对查询，不是问答对

§7 质量评估与局限性

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

本节讨论的是"这份标注能不能用来打分"，不是"MIMIC-III 的质量如何"。EHRCon 的标签描述的是笔记与表的关系，不描述任何一方与真实世界的关系。带着"标签 = 事实错误"的预设去读任何一个数字，都会得出错误结论。

7.1 五维评分

维度	评分	理由
标注深度	高	实体级，附表名列名、行号、执行过的查询、两个边界标记字段
任务清晰度	高	标签定义、实体类型、时间口径都有成文指令，且论文附录完整公开
规模	低	105 篇笔记、4,101 实体、无 train 划分，只能评测不能训练
获取门槛	低	需凭证认证、CITI 培训、两份 DUA，且必须自行构建本地库才能复现
泛化面	中	单一中心单一国家；但提供 MIMIC-III 与 OMOP CDM 两套 schema，跨 schema 泛化有支撑

7.2 标注质量的两层

第一层是实体识别，F1 为 0.880。分歧主要来自边界与粒度：一个"化学七项"里到底算几个实体、一条"血压稳定"算不算可核实体，不同标注者会有不同判断。

第二层是一致性判定，双方一致的实体中标签一致比例为 0.938。这一层更稳，因为判定最终落到 SQL 执行结果，是可验证的客观事实而非主观印象。

两层之间的落差提示了使用方式：把系统输出拆成"抽了哪些实体"与"判成了什么"两段分别计分，比只看一个总分有用得多。官方自己的实验也印证了这一点——CheckEHR 的召回与交集分数之间存在明显差距，作者明确把这归因于实体识别阶段的困难。

7.3 已知的、可枚举的偏差

来源偏差。 底层是单一医疗中心 2001–2012 年的 ICU 数据，书写习惯、系统版本、编码规范都是特定的。

预处理偏差。 官方在 Limitations 段明说：MIMIC-III 为保护隐私与便于复用做过预处理，这些预处理可能引入真实 EHR 数据中并不存在的不一致。这是这份数据最根本的一条限制——它测出的不一致里，有一部分可能根本不是临床现实中会发生的。

覆盖偏差。 放射报告与心电图报告被排除，因为依赖影像与心电监测，超出核对范围；"Nursing/other"类别中大量内容（如家属会谈细节）无法与表核对，也被排除。留下的三类笔记是"能被表核对的"那一子集。

长度偏差。 笔记按超过 800 token 随机抽取，短笔记不在其中。

schema 偏差。 实体范围被限定在 13 张表内，笔记里超出这些表的信息不进入标注。

把这些偏差叠起来看，会得到一条对使用者很重要的判断：这份数据刻画的是"在 MIMIC-III 这一特定去标识快照里，三类可核笔记与 13 张表之间的不一致形态"。它可以用来说明这类不一致确实存在、形态如何、自动核验有多难；它不适合被用来给出任何一个"发生率"意义上的外部结论，因为分母本身是被筛选过的。

7.4 外部验证矩阵

说法	是否成立	依据
任务比维基表格事实核查难	成立	官方报告 CheckEHR 召回落在 40–60% 区间
直接用大模型查不如分阶段	成立	官方对比：直接给 GPT-3.5 全部信息做核对，召回 10.12%、精确率 8.75%
分阶段流水线有效	成立	GPT-3.5 few-shot 下召回 61.06%、精确率 48.63%、交集 86.25%
OMOP schema 一定更好查	不成立	官方报告 OMOP 版表现相当或更差，few-shot 召回 54.36%
长文本不分段更好	不成立	官方在 25% 测试集上验证，不分段的召回明显下降
实体识别是主要瓶颈	成立	召回与交集、精确率与交集之间的差距由作者归因于 NER

7.5 它为何能持续

稀缺的不是数据量，是那个组合：真实的、大规模的关系型 EHR 库，配上实体级的人工标注，再把判定过程（SQL、映射、行号）一并公开。造一份更大的笔记语料不难，难的是让每一个标签都能追溯到"跑了哪条查询、查了哪张表哪一列"。这个"可追溯"的属性让它既是评测集，也是方法研究的解剖样本。

§8 生态位与历史

8.1 历史沿革

表格事实核查这条线从维基百科起步，TabFact、INFOTABS、SEM-TAB-FACTS、FEVEROUS 依次把证据从单一表格扩展到文本加表格。EHRCon 把它们推进到真实临床库，同时把前提从"证据无错"改成"双方都可能错"。2024 年 6 月挂 arXiv，2024 年 8 月落到 PhysioNet，同年在 NeurIPS 2024 Datasets and Benchmarks Track 发表；2025 年 3 月修订为 v1.0.1，补上两个边界标记字段。2026 年，同一团队在它的基础上做出推理密集型版本 EHR-ReasonCon（§6.2），把任务从表层匹配推向需要医学解读与时序推理的场景。

8.2 与 CheckEHR 的关系

CheckEHR 是随数据一起发布的配套框架，八阶段：笔记分段、命名实体识别、时间过滤、表识别、伪表构建、自我校正、值重格式化、查询生成。全部阶段用上下文学习驱动，仓库里为 discharge、nursing、physician 三类笔记各配了一套 few-shot 配置，另有 zero-shot 配置。

它与数据的关系是"基线"而非"答案"。官方报告的最好成绩是 GPT-3.5（0613）在 few-shot 下的召回 61.06%，而整体召回区间在 40–60%——这个成绩本身就是任务难度的度量，也是留给后续研究的空间。值重格式化与自我校正两个阶段的存在，提示了这一类系统的真实痛点：笔记写 “admission”，表里存 “2022-02-02”；大模型在构建伪表时会幻觉出笔记里没有的单位。

8.3 生态位

它处在三个圈的交集里：EHR 自然语言处理、表格事实核查、大语言模型长文本推理。前一个圈给它临床语义，中间那个给它任务形式，后一个给它当下的关注度。它在每个圈里都不是规模最大的那个——论语料规模比不上合成笔记语料，论声明数量比不上 TabFact，论推理深度比不上 EHR-ReasonCon——但只有它同时具备"真实数据库 + 实体级人工标注 + 判定过程可追溯"这三条。

这三条里最容易被低估的是第三条。一份只给标签的数据集，只能用来回答"系统做对了多少"；一份连判定过程都给的数据集，还能回答"系统错在哪一步"。CheckEHR 的八个阶段之所以能被逐个拆解做消融，正是因为标注侧留下了值映射、时间口径与执行过的查询。对方法研究者来说，这个可拆解性比多几千个实体更有价值。

从时间上看，它的位置也清楚：在维基表格基准之后、在推理密集型增强版之前，承接了"把事实核查搬进真实临床系统"这一步。想要表层匹配的起点，它是当前最合适的一站；想要推理深度，顺着 §6.2 往下游走。

8.4 谁在用

从官方 Datasheet 的自述看，数据集发布时"尚未被用于其他任务"，作者预期它除 EHR 一致性检查外，也可用于表格事实核查任务。实际使用者主要是三类：做病历质控与患者安全的研究者、做表格事实核查想换真实场景的自然语言处理团队、以及需要长文本多跳推理基准的大语言模型评测团队。配套代码仓库给出了完整的配置与运行方式，降低了复现门槛。

§9 使用指引

9.1 三种角色的路径

角色	最短路径	要避开的坑
临床信息学研究者	直接引用论文 §3.4 的落点分析，用它说明自动查账的必要性	别把不一致率当成"医生错误率"
自然语言处理算法工程师	用 CheckEHR 的八阶段拆分做基线，逐阶段计分	别把 Type 3 实体计入，别用 label 字符串推标签
数据治理从业者	借它的实体类型与时间口径设计院内的核对规则	别照搬 13 张表的范围，院内 schema 不同

9.2 一条最短的可用流程

1. 完成 PhysioNet 凭证认证、CITI 培训，签署 MIMIC-III 与 EHRCon 两份 DUA；
2. 下载 processed 分支（笔记已过滤，实体与表对齐度更高）；
3. 运行仓库的 make_database.py 构建逐患者 SQLite 库；
4. 用 §5.4 的 flatten 把 pickle 摊平成实体级表，以 errors 派生二分类标签；
5. 按官方口径排除 Type 3 实体，单独列出 Almost_Consistent 为 yes 的实体；
6. 选定 test（83 篇）做评测，valid（22 篇）留给调参；
7. 计分时分两段：实体识别与一致性判定，分别报召回、精确率与交集分数。

9.3 引用方式

引用对象	写法
数据集	Kwon, Y., Kim, J., Lee, G., Bae, S., Kyung, D., Cha, W., Pollard, T., Johnson, A., & Choi, E. (2025). EHRCon: Dataset for Checking Consistency between Unstructured Notes and Structured Tables in Electronic Health Records (version 1.0.1). PhysioNet. RRID:SCR_007345. https://doi.org/10.13026/m4vd-y789
论文	Kwon Y, et al. EHRCon: Dataset for checking consistency between unstructured notes and structured tables in electronic health records. NeurIPS 2024 Datasets and Benchmarks Track；预印本 arXiv:2406.16341
平台	PhysioNet 平台综述（2026 年发表于 Nature Health），按官方页 Cite 按钮生成
上游	MIMIC-III Clinical Database v1.4（Parent Project，须一并引用）
代码	https://github.com/dustn1259/EHRCon
项目页	https://ehrcon.github.io

引用时务必写清版本号（1.0.1 与 1.0.0 的字段集合不同）、用的是 original 还是 processed 分支、以及是否排除了 Type 3 实体——这三项直接决定你的数字能否被复现。

§10 AI 使用声明

项目	声明
文本生成	本文由 AI 辅助撰写，编辑把关结构与事实
数字来源	规模、结构、边界三类数字来自 PhysioNet 官方页、项目官网、代码仓库 README 与论文（arXiv:2406.16341v2）
文件核验	官方页 Abstract / Background / Methods / Data Description / Usage Notes / Limitations / Release Notes / Ethics / Acknowledgements 各段经直接访问确认；代码仓库目录树与 README 经直接访问确认
不一致说明	实体总数存在两个官方口径：论文摘要与表 1 为 4,101，官方页 Data Description 段与仓库 README 为 3,943；官方未逐字说明二者分别对应 original 与 processed 哪一套，正文按此并存处理。另：作者机构在 PhysioNet 页与项目官网有一处不一致（Alistair Johnson：MIT / University of Toronto）。许可方面，论文 Datasheet 自述为 MIT License，而 PhysioNet 实际施加的是 Credentialed Health Data License 1.5.0；以 PhysioNet 页面为准
论文信息	论文正文（含附录 B、C、D、E 与表 1、表 2）经 HTML 版全文核对
未核验内容	PhysioNet 文件目录因区域限制返回 403，未能逐文件列出；各类实体的逐类条数、每篇笔记的患者归属、逐患者库的文件数与体积均未逐一核实
图像	无配图；封面为生成式提示词，不含真实病历内容
免责	本文不构成临床建议；数据使用须遵守 PhysioNet 凭证访问要求与 DUA，不得再分发

常见误读（避坑清单）

说法	实际	证据
「它有四千多份病历」	105 篇笔记，4,101 个标注实体	官方页 Abstract 与论文表 1
「标签能指出笔记错了还是表错了」	标签是对称的 CONSISTENT / INCONSISTENT	论文 §3.1：表里与笔记都可能错，无法定义基准证据
「可以直接拿来训练模型」	只有 test 83 与 valid 22，无 train 划分	论文 Datasheet：105 篇随机分为测试集 83 与验证集 22
「它是通用的表格事实核查集」	绑定 MIMIC-III 的 13 张表与 OMOP 映射	论文附录 B.1.2
「百分之多少的不一致是医生的错」	官方不做归因，且 MIMIC-III 预处理本身可能引入不一致	官方页 Limitations 段
「OMOP 版更好查」	官方报告 OMOP 版表现相当或更差	论文 §5.3 与官网 Analysis 段
「label 是个枚举字段」	是自由文本，errors 才是计数	官方页字段说明
「Type 3 实体可以正常计入」	已收录但未进入主实验	论文 §3.1
「下载标注文件就够用了」	复现判定必须执行 SQL，需本地库与 MIMIC-III 授权	仓库 README 的 Setup 与 make_database.py
「它和 EHR-ReasonCon 是同一份数据」	两份独立资源：不同 DOI、不同版本、4,101 对 8,042 实体、13 对 14 张表	见 §6.2；二者 Parent Projects 关系为派生

FAQ

Q1：EHRCon 到底是 4,101 个实体还是 3,943 个？
两个数字都是官方口径，出现在不同位置。论文摘要与表 1 的合计是 4,101，PhysioNet 官方页 Data Description 段与代码仓库 README 写的是 3,943。数据集有 original 与 processed 两套目录，前者用未过滤的原始笔记、后者过滤掉了表里不可能出现的信息，合理推测两个数字分别对应这两套，但官方没有逐字说明对应关系。引用时请写明你用的数字出自哪一版、用的是哪个分支。

Q2：拿到一个 INCONSISTENT 标签，能不能判断是医生写错了？
不能。标签只说明笔记里的信息与结构化表对不上，不说明哪一方是错的。这不是标注偷懒，而是任务定义：在电子病历里，表和笔记都可能出错，任何一方都不能被预先定义为基准证据。官方还额外提醒，MIMIC-III 为保护隐私所做的预处理本身就可能引入真实系统里不存在的不一致。

Q3：为什么官方要同时做 MIMIC-III 和 OMOP CDM 两个版本？
为了测 schema 泛化。两者装的是同一批患者信息，但组织方式不同：MIMIC-III 用多张专用表，OMOP CDM 用标准化表。如果一套核验方法只在某种 schema 上有效，就很难说它真的理解了临床语义。官方的实验结论恰好是个反直觉的结果——结构更规整的 OMOP 版表现反而相当或更差，因为 OMOP 把值、单位、规格压进了同一个字段，实体更难拆。

Q4：没有 train 划分，那 baseline 是怎么训的？
不需要训。CheckEHR 是纯上下文学习的流水线，八个阶段都用少量示例驱动，仓库里为 discharge、nursing、physician 三类笔记各配了 few-shot 配置，另有 zero-shot 配置。数据集的角色是打分板而不是教材；如果你要做监督训练，需要自己构造训练信号，并且必须说明训练数据的来源，避免与 test 重叠。

Q5：它和站内 rid 1007 的 EHR-ReasonCon 是什么关系？
派生关系，但不是同一份数据。EHR-ReasonCon 沿用 EHRCon 的同一组 105 篇源笔记，按五阶段、专家引导的流水线重新标注，产出 8,042 个锚实体，对照 14 张表，主打需要医学解读、事件关系推理与时序变化分析的案例；EHRCon 是 4,101 个实体、13 张表，主打值与时间的表层匹配。二者 DOI、版本号、论文、配套系统都不同（EHR-INSPECTOR 对 CheckEHR）。选题判据是：测表层匹配用 EHRCon，测推理密集型核验用 EHR-ReasonCon。

术语表

术语	解释
EHR	电子健康记录，医院内患者诊疗信息的数字化汇总
结构化表	按字段组织、可 SQL 检索的数据，如检验、用药、诊断编码
临床笔记	医护用自然语言书写的病程、小结与护理记录
CONSISTENT / INCONSISTENT	一致性判定的两个标签；只描述两者是否相符，不归因
实体级标注	标注对象是笔记中的一个个实体，而非整篇笔记
Type 1 / 2 / 3	数值实体 / 可核存在性的无值实体 / 字符串值实体
MIMIC-III	贝斯以色列女执事医疗中心 2001–2012 年 ICU 去标识数据库
OMOP CDM	观察性健康数据的通用数据模型标准
hadm_id	住院号，一次住院的唯一标识
ROW_ID	MIMIC-III NOTEEVENTS 表中笔记的行标识
Item Search Tool	官方为缩写、商品名与库内 itemid 做匹配的工具
CheckEHR	随数据发布的八阶段大语言模型核验流水线
伪表	从笔记中抽出的、模拟数据库表结构的信息集合
值重格式化	把笔记里的表述转换成与库字段一致的数据类型
交集分数	官方使用的评测指标，衡量系统判定与人工标注的交叠程度
CITI 培训	PhysioNet 要求的 “Data or Specimens Only Research” 课程
DUA	数据使用协议，凭据访问资源必须签署
凭据访问	需账号、培训与协议三重核验后才能下载
时间表达式	笔记中描述事件时刻的方式：标准格式、叙述式、缺失

附录 A：核心数字核对表

项	值	来源
笔记数	105	官方页 Abstract；论文表 1
标注实体数	4,101（另一官方口径 3,943）	论文表 1；官方页 Data Description 段
对照结构化表	13（9 事件表 + 4 字典表）	论文附录 B.1.2
出院小结 / 医生记录 / 护理记录	38 / 33 / 34 篇	论文表 1
各类实体数	1,908 / 1,530 / 663	论文表 1
Type 1 / Type 2 实体	3,011 / 1,090	论文表 1
CONSISTENT / INCONSISTENT 实体	2,933 / 1,168	论文表 1
出院小结中的不一致	727 / 1,168	论文 §3.4
labevents 占不一致比例	36.55%	论文 §3.4
用药相关表占不一致比例	17.58%	论文 §3.4
时间相关差异占比	56.16%	论文 §3.4
时间差异中一小时之差占比	58.23%	论文 §3.4
数据划分	test 83 / valid 22	论文 Datasheet
笔记长度下限	800 token	论文附录 B.1.1
交叉核对规模	4 位标注者 × 每类 20 篇	论文附录 E
实体识别 F1	0.880	论文附录 E
标签一致比例	0.938	论文附录 E
SQL 模板数	27（经两位作者校验）	论文 §3.3
选表分析样本	300 篇（三类各 100 篇）	论文附录 B.1.2
CheckEHR 最佳召回	61.06%（GPT-3.5 few-shot）	论文 §5.2
直接用 GPT-3.5 的召回	10.12%	论文 §5.2
OMOP 版 few-shot 召回	54.36%	论文摘要
标注周期	2023 年 4 月至 2024 年 4 月	论文 Datasheet
版本与日期	v1.0.0（2024-08-19）、v1.0.1（2025-03-19）	官方页版本历史
DOI	10.13026/m4vd-y789	官方页 Discovery 段
许可	PhysioNet Credentialed Health Data License 1.5.0	官方页 Access 段

附录 B：数字的来源分层

第一层：官方页面与官方结构说明。 105 篇笔记、4,101 与 3,943 两个实体口径、13 张表、test 与 valid 两级划分、版本号与发布日期、DOI、许可与访问门槛、字段字典、目录结构。这些来自 PhysioNet 项目页的摘要、数据描述、使用说明、局限、发布说明与访问段，并由代码仓库 README 的目录树与字段列表交叉印证。

第二层：论文全文。 表 1 的逐类实体与标签、表 2 的基线成绩、§3.4 的不一致落点、附录 B 的选表与 OMOP 映射、附录 E 的质量控制系数、Datasheet 的采集周期与划分口径。论文为 arXiv:2406.16341v2，以 HTML 全文核对。

第三层：项目官网。 三个最小案例（时间不一致、完全一致、存在性缺失）与 OMOP 版表现的分析结论，来自 ehrcon.github.io 的图注与 Analysis 段；官网同时把 13 张表这一数字写在正文里。

第四层：未核实。 PhysioNet 文件目录因区域限制无法列出，因此各类实体的逐类条数、每篇笔记的患者与住院归属、逐患者库的文件数与体积、以及 all_queries 的完整形态均未逐一核实。正文凡涉及这些地方只做定性表述，不给出数字。