EHR-ReasonCon — 临床笔记与结构化表推理密集型一致性核验数据集

INFOBOX — EHR-ReasonCon 一屏速览

维度	内容
本质	临床笔记↔结构化 EHR 表的推理密集型一致性核验数据集（在 EHRCon 基础上深挖高推理案例）
官方全名	EHR-ReasonCon: Reasoning-Intensive Consistency Verification Between Clinical Notes and Structured Tables in Electronic Health Records
团队	KAIST 主导，联合 Ghent University / Samsung Medical Center / Samsung Changwon Hospital / Asan Medical Center；通讯 Edward Choi
交付	PhysioNet v1.0.0（Published 2026-09-15；DOI 10.13026/7m91-3010）
上游	MIMIC-III v1.4（源笔记）+ EHRCon v1.0.1（同 105 篇笔记）
规模	8,042 锚实体 × 105 篇笔记 × 14 张结构表；CONSISTENT 5,847 / INCONSISTENT 2,195
笔记类型	Discharge 38 / Physician 33 / Nursing 34
划分	test : valid = 4 : 1
标注可靠性	实体识别一致性 0.897；一致性标注一致性 0.888
核心主张	现实病历核验需医学解读、事件关系推理、时序变化分析——非表层数值匹配所能覆盖
配套系统	EHR-INSPECTOR（LLM 框架：分段→抽锚实体与时序引用→工具查表验证）
获取	凭据访问：PhysioNet 账号 + CITI 培训 + DUA（继承 MIMIC-III 门槛）
许可	PhysioNet Credentialed Health Data License 1.5.0

§0 导读：这个数据集解决什么问题

电子健康记录（EHR, Electronic Health Record）里同时住着两套语言：一套是结构化表——检验值、用药、诊断编码、生命体征，字段清晰、可 SQL 检索；另一套是非结构化临床笔记——医生和护士用自然语言记录病情、处置与病程。理想情况下两者应彼此印证：笔记里写"血红蛋白 7.2"就应能在检验表里找到对应的值，笔记里写"已停用万古霉素"就应能在用药表里看到停用记录。

现实并非如此。EHR 系统往往按行政管理需求而非临床文书工作流设计[1]，医护人员可能录错值、复制过期信息、漏记、把事件记在错误时间点[2,3]。这些不一致会削弱 EHR 数据的可靠性，对患者护理和二次数据分析构成风险[4]。人工逐条比对海量关系型数据库既耗时又昂贵。

EHRCon（Kwon et al., NeurIPS 2024 Datasets and Benchmarks Track）[5] 先迈出一步：为"自动核查笔记与结构化表一致性"提供了基准。但 EHRCon 主要停留在表层信息——某个数值、某个简单临床事件是否在库中出现。问题在于，临床笔记里大量信息无法靠直接匹配确认：

• 确认"贫血"需要解读血红蛋白值（医学解读）；
• 确认"抗生素敏感性"需要连接多个微生物学字段（事件关系推理）；
• 验证"血压下降趋势"需要检视多个时间点的测量（时序推理）。

**EHR-ReasonCon 正是为捕获这类"推理密集型一致性核验"案例而设计。**它沿用 EHRCon 的 105 篇笔记作为源笔记，在 MIMIC-III[6] 之上通过五阶段、专家引导的标注流水线重新构建，产出 8,042 个锚实体的一致性标签。

一句话定位：EHRCon 回答"表里有没有这个值"，EHR-ReasonCon 回答"笔记里的这个临床判断，能不能被表里的证据推理地支持"。 它是配套论文所提系统 EHR-INSPECTOR 的评估基准。

§1 数据集速览：十问十答

Q1：EHR-ReasonCon 是什么？
一个临床笔记与结构化 EHR 表之间的推理密集型一致性核验数据集，含 8,042 个锚实体的人工一致性标注，v1.0.0 托管于 PhysioNet。

Q2：谁做的？
KAIST（韩国科学技术院）主导，联合比利时 Ghent University、韩国 Samsung Medical Center、Samsung Changwon Hospital、Asan Medical Center；通讯作者 Edward Choi（KAIST）。共 13 位作者。

Q3：数据从哪来？
构建在 MIMIC-III 之上，使用 EHRCon 的 105 篇临床笔记作为源笔记。Parent Projects 明确为 EHRCon v1.0.1 与 MIMIC-III Clinical Database v1.4。

Q4：有多大？
8,042 个标注锚实体，来自 105 篇笔记，覆盖 3 类笔记（Discharge 38 / Physician 33 / Nursing 34），对照 14 张 MIMIC-III 结构化表。

Q5：标签是什么？
每个锚实体标为 CONSISTENT 或 INCONSISTENT。全集 CONSISTENT 5,847、INCONSISTENT 2,195。

Q6：和 EHRCon 什么关系？
派生关系：EHR-ReasonCon = EHRCon 笔记 × 更深的推理密集型重标注。EHRCon 偏表层匹配，EHR-ReasonCon 专攻需医学解读/事件关系/时序推理的案例。

Q7：怎么获取？
凭据访问（Credentialed Access）：需 PhysioNet 账号、完成 CITI「Data or Specimens Only Research」培训、签署 PhysioNet Credentialed Health Data Use Agreement 1.5.0。门槛沿 MIMIC-III 口径。

Q8：许可是什么？
PhysioNet Credentialed Health Data License 1.5.0。因派生自 MIMIC-III，不能无条件再分发。

Q9：怎么评估？
作者明确建议语义级、实体级评估（如 LLM-as-a-judge，harsh 与 lenient 两档），不推荐精确字符串匹配——因为系统与人工标注者的 span 边界、粒度天然不同。

Q10：配套系统是什么？
EHR-INSPECTOR：一个 LLM 框架，先分段笔记、抽取锚实体与时序引用，再用表探索工具核验一致性；EHR-ReasonCon 是其评估基准。

§2 数据构成与规格

2.1 规模、来源与机构构成

EHR-ReasonCon 的规模可以用三个数字锚定：8,042 × 105 × 14——8,042 个标注锚实体、105 篇临床笔记、14 张被核验的结构化表。

数据以 MIMIC-III v1.4[6] 为上游，采用 EHRCon[5] 的 105 篇笔记作为源笔记。这意味着 EHR-ReasonCon 与 EHRCon 共享同一组笔记，但标注深度不同（详见 §4）。机构构成上，主建方为 KAIST，另有 Ghent University 提供方法学协作、三家韩国临床机构（Samsung Medical Center、Samsung Changwon Hospital、Asan Medical Center）提供临床专家支持。

逐类笔记分布表（官方页 Data Description）：

Note Type	Notes	Entities	Consistent	Inconsistent
Discharge（出院小结）	38	3,497	2,041	1,456
Physician（医生记录）	33	2,841	2,388	453
Nursing（护理记录）	34	1,704	1,418	286
Total	105	8,042	5,847	2,195

这张表本身颇值玩味：

• 出院小结的不一致率最高：1,456 / 3,497 ≈ 41.6%，而医生记录仅 453 / 2,841 ≈ 15.9%、护理记录 286 / 1,704 ≈ 16.8%。出院小结是全文汇总，信息量大、时间跨度长，最易出现与结构化表脱节之处。
• 笔记数分布相对均衡（38/33/34），但实体数分布极不均衡（3,497/2,841/1,704）——出院小结单篇携带约 92 个实体，护理记录单篇约 50 个。

2.2 十四张结构化表

每个锚实体在 14 张 MIMIC-III 表中寻找证据。官方页列出的是：

患者事件表（10 张）：Chartevents（图表事件/生命体征）、Labevents（检验）、Prescriptions（处方）、Inputevents_cv（输入事件/ICU 记录系统）、Inputevents_mv（输入事件/元数据系统）、Outputevents（输出事件/出入量）、Procedureevents_mv（操作事件）、Microbiologyevents（微生物学）、Diagnoses_icd（ICD 诊断）、Procedures_icd（ICD 操作）。

字典表（4 张）：D_items（Chartevents 项目字典）、D_icd_diagnoses（ICD 诊断字典）、D_icd_procedures（ICD 操作字典）、D_labitems（Labevents 项目字典）。

注意口径：14 张表中含 4 张字典表（D_*）。字典表不直接承载患者事件记录，而是提供项目 ID→名称/单位的映射。检验/核验时，值来自事件表、含义来自字典表，两相结合才构成完整证据。检索者引用"14 张表"时应理解这一含字典表的口径。

2.3 目录结构与文件格式

官方页给出的 folder hierarchy：

EHR_ReasonCon/
├── README.md                    # 文件指南（格式、文件间关系）
├── annotations.csv              # 全部 8,042 条标注，单一扁平表
├── discharge/
│   ├── test/
│   │   ├── discharge_test.csv   # 该 split 的源笔记
│   │   └── EHRReasonCon_{hadm_id}_data.json   # 每篇笔记一个注释文件
│   └── valid/
│       ├── discharge_val.csv
│       └── EHRReasonCon_{hadm_id}_data.json
├── physician/  ...
├── nursing/    ...
├── patient_data/
│   └── {hadm_id}/               # 逐次入院的结构化表
│       ├── chartevents.csv
│       ├── labevents.csv
│       ├── prescriptions.csv
│       ├── inputevents_cv.csv
│       ├── inputevents_mv.csv
│       ├── outputevents.csv
│       ├── procedureevents_mv.csv
│       ├── microbiologyevents.csv
│       ├── diagnosis_icd.csv
│       ├── procedure_icd.csv
│       ├── patient_records.csv  # 该患者记录到的项目目录
│       └── catalog_items.csv    # 候选项目及其画像（TOP_VALUES）
└── resources/
    ├── preprocessed_d_items.csv # 工具使用的归一化 D_ITEMS 字典
    ├── d_labitems.csv           # Labevents.ITEMID 的 D_LABITEMS 字典
    └── top_values.json          # 逐项目的全语料值画像

关键设计：patient_data/{hadm_id}/ 把结构化表按入院（admission）切片——每篇笔记只需加载其对应 hadm_id 的表，无需载入完整 MIMIC-III 数据库。这让研究者能在不部署全量 MIMIC-III 的前提下复现核验流程，大幅降低工程门槛。

双格式约定：

• 逐笔记 JSON（EHRReasonCon_{hadm_id}_data.json）为权威：以笔记的 ROW_ID 为键，值为锚实体列表，每个实体是单键对象（实体名→标注元数据）。
• annotations.csv 是同一批 8,042 条标注的扁平化版本（键为 hadm_id, row_id, entity_index），供偏好单表的用户使用。
• 源笔记 CSV 使用标准 MIMIC-III NOTEEVENTS 列（ROW_ID, SUBJECT_ID, HADM_ID, CHARTDATE, CHARTTIME, CATEGORY, TEXT, ADMITTIME 等）。

2.4 锚实体标注的字段体系

每个锚实体是一个单键对象，其标注元数据字段如下（官方页逐条列出）：

字段	含义
data	从笔记抽取的值，映射到对应表项与列，如 {'labevents': {'valuenum': '1.4'}, 'd_labitems': {'label': 'creatinine'}}
label	一致性标签：consistent / inconsistent
entity_type	核验类型：1=数值型、2=存在可核事件型、3=字符串/类别型
position	实体在笔记中的行号
table	作为证据的主结构化表（如 chartevents）
evidence_row_ids	支撑证据的表的 ROW_ID 列表
consistency_check_path	标注者到达该标签的工具探索/推理路径编码轨迹
inconsistent_columns	对不一致实体，指明差异发生的具体列（如 charttime、valuenum）
almost_consistent	笔记与表值是否近乎相同（差异可忽略），Yes / No
commonsense_medical_none	标记所需知识类型：常识（c）/ 医学（m）/ 无需（n）
medical_knowledge_source	所查权威医学参考的 URL（如适用）
check_db	是否需要查数据库或临床指南才能定标签
abnormal_case	标注中标记的非典型/边缘案例

官方页特别说明：并非每个字段对每个实体都存在，可选字段仅在该实体的核验相关时填充。

这套字段体系是 EHR-ReasonCon 区别于普通二分类数据集的关键——它不仅给出结论（consistent/inconsistent），还给出推理过程的可审计痕迹（consistency_check_path）、知识依赖类型（commonsense_medical_none）、证据定位（evidence_row_ids）与差异定位（inconsistent_columns）。

2.5 加载示例

官方页提供的加载代码：

import json
import pandas as pd

notes = pd.read_csv("discharge/test/discharge_test.csv")
note = notes.iloc[0]  # HADM_ID = 115468.0, ROW_ID = 1087
with open(f"discharge/test/EHRReasonCon_{note.HADM_ID}_data.json", encoding="utf-8") as f:
    annotations = json.load(f)   # {"1087": [ {entity: {...}}, ... ]}
entities = annotations[str(note.ROW_ID)]
records = pd.read_csv(f"patient_data/{int(note.HADM_ID)}/{table}.csv")

# 或直接用扁平表：
flat = pd.read_csv("annotations.csv")

（JSON 用标准 json 库即可加载；patient_data 目录让实体能对照真实记录核验而无需载入整库。）

§3 标注流水线：五阶段如何把"临床判断"变成可复核标签

3.1 人员结构

EHR-ReasonCon 的标注由专家引导、多人独立、交叉复核构成：

• 4 位临床专家（制定标注协议）：一位 board-certified 放射肿瘤学家、一位 board-certified 普外科医生、一位麻醉科住院医师、一位 EHR 技师。
• 8 位受训标注员（trained annotators，熟悉 EHR 系统）：执行实体识别与一致性标注，必要时查阅权威医学参考（UpToDate、MedlinePlus、Cleveland Clinic、Mayo Clinic）并咨询医生。
• 1 位独立复核者：初始标注完成后，复查全部 105 篇笔记以保证数据集级一致性。

3.2 五阶段流程

官方页 Methods 给出五阶段（Stage 0–4）：

Stage 0 — Pre-Annotation Setup（预标注设置）。与 4 位临床专家协作，制定标注协议，规定：笔记中的叙述性表述如何映射到结构化表字段、如何解读时序趋势、如何处理模糊的临床判断。协议经**试点标注（pilot annotation）**迭代精炼。试点期间，团队分析标注员如何检索证据，并将反复出现的检索模式形式化为 8 个模块化表探索工具，归入三类功能：

1. entity-to-table-item alignment（实体→表项对齐）：对笔记实体做词汇与语义检索，找出对应表项，如把 “WBC” 对齐到 “White Blood Cells”；
2. database exploration and value profiling（数据库探索与值画像）：探索表结构、汇总每个项目的典型值，如识别出 Stool Amount 是类别型而非数值型；
3. temporal and conditional record retrieval（时序与条件记录检索）：按时窗与值约束检索记录，检视趋势与事件。

Stage 1 — Anchor Entity Identification（锚实体识别）。标注员识别每篇笔记中对应结构化表项的锚实体（用药、诊断、生命体征、检验等）。这些锚实体是证据检索的入口点。

Stage 2 — Tool-Assisted Table Exploration（工具辅助表探索）。对每个锚实体，标注员检视其属性（如剂量、给药途径）与时序语境，用预定义工具查询结构化表，取回作为一致性评估证据的记录。

Stage 3 — Consistency Verification（一致性核验）。每个锚实体：若笔记信息被结构化记录支持则标 CONSISTENT，否则标 INCONSISTENT。此阶段涉及推理密集型分析——时序推理、常识推理、医学解读——必要时查阅权威医学参考或咨询医生。

Stage 4 — Annotation Reliability（标注可靠性）。每篇笔记由两名标注员独立完成 Stage 1–3，再通过互相协商解决分歧，复杂临床判断上报医学专业人员。初始标注完成后，独立复核者复查全部 105 篇以保证全数据集一致性。

3.3 标注质量硬数字

Stage 4 的结果给出两个关键一致性系数（官方页原文）：

• 实体识别一致性（entity identification）：0.897
• 一致性标注一致性（consistency labeling）：0.888

口径说明（存照）：官方页仅给出 0.897 / 0.888 两个数值，未明确标注是何种统计量（可能是 Cohen’s κ，也可能是一致率百分比）。检索者引用时应注明"官方页未细化系数口径"，不要擅自臆断为 κ。

两个数值都接近 0.9，说明在"哪是锚实体"和"它一致与否"两个环节，人工标注的可重复性较高——这对一个涉及医学解读与推理的数据集而言是相当稳健的信号。

3.4 从"表层匹配"到"推理核验"的三类案例

EHR-ReasonCon 的核心价值在于专攻 EHRCon 覆盖不足的高推理案例。官方页 Background 给出三个典型：

核验类型	例子	为何需推理
医学解读	确认"贫血"	需解读血红蛋白（hemoglobin）值，而非直接匹配一个字符串 “anemia”
事件关系推理	确认"抗生素敏感性"	需连接多个微生物学字段才能得出
时序变化分析	验证"血压下降趋势"	需检视多个时间点的测量记录

这三类构成数据集"reasoning-intensive（推理密集型）"称谓的实质：答案不在表里的某一格，而藏在跨格、跨表、跨时间的临床逻辑中。

§4 与 EHRCon、er-reason、ArchEHR-QA 的辨析

本批条目中有三个名字相近、极易混淆的条目，务必分清。它们主题不同、来源不同、非别名关系：

条目	rid	本质	主题	来源/机构
ehr-reasoncon（本条）	待入库	笔记↔结构化表一致性核验数据集	一致性核验（note-table consistency）	KAIST，PhysioNet，基于 MIMIC-III
er-reason	985	急诊科临床推理数据集	急诊场景临床推理	UCSF
archehr-qa-bionlp-task-2025	1000	患者-EHR 证据落地的问答共享任务	问答（QA）	BioNLP 2025 共享任务

辨析要点：

1. EHR-ReasonCon vs EHRCon（前作，非库内同名冲突）：EHRCon[5] 是 Kwon et al. 在 NeurIPS 2024 Datasets and Benchmarks Track 发布的前作，侧重表层匹配（数值或简单事件是否在库中）。EHR-ReasonCon 复用其 105 篇笔记，但重新做了推理密集型标注。两者是派生/升级关系，PhysioNet 页明确把 EHRCon v1.0.1 列为 Parent Project。不是撞库别名——EHRCon 与 EHR-ReasonCon 是两个独立数据集。

2. EHR-ReasonCon vs er-reason（rid 985）：er-reason 的 “er” 指 Emergency Room（急诊科），主题是急诊临床推理；EHR-ReasonCon 的 “ehr” 指 Electronic Health Record，主题是笔记与表的一致性。名字像、内核完全不同：前者是"在急诊场景推理"，后者是"核验病历内部自洽"。读者切勿因 “reason” 一词误以为同一家族。

3. EHR-ReasonCon vs ArchEHR-QA（rid 1000）：ArchEHR-QA 是 BioNLP 2025 共享任务，任务是"给定患者问题，从 EHR 笔记中落地证据并作答"（QA 范式）；EHR-ReasonCon 是"给定笔记实体，判断其与结构化表是否一致"（核验范式）。一个是问答，一个是核验。二者都以 EHR 文本为对象，但任务定义正交。ArchEHR-QA 的 “Arch” 源自其架构式证据扎根（architecture for evidence grounding），与 ReasonCon 的 “Con”（consistency）无关联。

一句话记忆：ReasonCon = 一致性（Consistency）核验；er-reason = 急诊（ER）推理；ArchEHR-QA = EHR 问答（QA）。

§5 EHR-INSPECTOR：配套的核验系统

EHR-ReasonCon 不是孤立数据集，而是配套论文所提系统 EHR-INSPECTOR 的评估基准。官方页 Usage Notes 明确：

“The accompanying paper introduces EHR-INSPECTOR, an LLM-based framework that segments notes, extracts anchor entities and temporal references, and verifies consistency using table-exploration tools; EHR-ReasonCon serves as its evaluation benchmark.”

EHR-INSPECTOR 的四步工作流：

1. segments notes（分段笔记）——把整篇临床笔记切分为可处理单元；
2. extracts anchor entities and temporal references（抽取锚实体与时序引用）——找出待核验实体及其时间锚点；
3. verifies consistency using table-exploration tools（用表探索工具核验一致性）——复用的正是 Stage 0 形式化的那套工具思路（实体对齐 / 值画像 / 时序检索）；
4. 输出一致性判断——对照结构化表给出一致/不一致结论。

这套设计逻辑：把标注协议里"人类标注员如何查表推理"的操作，抽象成 LLM agent 可调用的工具集，从而把人工核验流程可计算化。EHR-ReasonCon 则提供"标准答案"来度量这套 agent 的准确性。

5.1 评估口径：为何不用精确匹配

官方页 Usage Notes 给出关键评估建议：

“Because span boundaries and granularity naturally differ between systems and human annotators, we recommend semantic, entity-level evaluation (e.g., LLM-as-a-judge under harsh and lenient criteria, as used in the accompanying paper) rather than exact string matching.”

翻译与解读：

• 不建议：精确字符串匹配（exact string matching）——因为系统抽取的 span 边界与人类标注者的粒度天然不同（人类可能标 “blood pressure 90/60”，系统可能只标 “90/60” 或整句）。
• 建议：语义级、实体级评估，例如 LLM-as-a-judge，并用 harsh（严格）与 lenient（宽松）两档 判据。

这是一个成熟的方法学选择：承认标注边界的主观性，转而评估语义等价性。对数据集使用者而言，这意味着评测脚本不能简单 == 比较，而应实现语义评判器或直接采用论文的评判协议。

5.2 数据集定位与用途

官方页 Usage Notes 界定用途：

“EHR-ReasonCon is intended for developing and evaluating systems that verify consistency between clinical notes and structured EHR tables, with an emphasis on reasoning-intensive cases involving clinical interpretation, event relations, and temporal change.”

即：面向"开发与评估笔记–表一致性核验系统"，重点在临床解读、事件关系、时序变化三类推理密集型案例。

§6 获取与许可：凭据访问的门怎么进

6.1 三层门槛

EHR-ReasonCon 是 Credentialed Access（凭据访问） 数据集，不能公开下载。要拿到文件，需同时满足：

1. PhysioNet 账号——在 physionet.org 注册并登录；
2. 完成 CITI 培训——“Data or Specimens Only Research” 课程（人类受试者数据研究伦理培训）；
3. 签署 DUA——PhysioNet Credentialed Health Data Use Agreement 1.5.0。

Access Policy（官方页原文）：“Only credentialed users who sign the DUA can access the files.”

6.2 许可（License）

• License：PhysioNet Credentialed Health Data License 1.5.0
• Data Use Agreement：PhysioNet Credentialed Health Data Use Agreement 1.5.0
• Required training：CITI Data or Specimens Only Research

6.3 地域限制提示

官方页 Files 区块当前显示：“Data is not available in your region due to legal or policy restrictions.”——即部分地域因法律或政策限制无法下载。这是一个务实的提醒：即便拿到凭据，仍可能受地域约束；跨国团队需预留合规窗口。

6.4 版本链与血缘

• 当前版本：v1.0.0（Initial Release，2026-09-15）
• 版本历史：Releases 仅一条 1.0.0 - Initial Release
• DOI（v1.0.0）：10.13026/7m91-3010
• DOI（latest）：10.13026/t7hc-k382
• Parent Projects（父项目）：
  • EHRCon: Dataset for Checking Consistency between Unstructured Notes and Structured Tables in Electronic Health Records v1.0.1
  • MIMIC-III Clinical Database v1.4

引用规范：官方页明确要求"when using this resource, please cite"本数据集（Kwon, Y., Kim, J., Choi, J., Rabaey, P., Kim, M., Im, S., Yang, J., JUNMIN, L., Lee, S., Kim, J., Yoon, H., Kwon, H., & Choi, E. (2026)），并同时引用父项目 EHRCon 与 PhysioNet 平台的通用引用（Pollard et al., Nature Health 2026）。

6.5 伦理与利益冲突声明

官方页 Ethics 区块：“This project builds upon previous datasets (MIMIC-III) that have been approved for credentialed distribution.”——本项目构建于已获批凭据分发的 MIMIC-III 之上。Conflicts of Interest：“The authors have no conflicts of interest to declare.”（作者声明无利益冲突。）

6.6 AI-Ready 评估：凭据访问对二次利用的影响

维度	评价
可获取性	⚠️ 中——凭据访问，门槛高于公开数据集，低于申请制私有数据
复现性	✅ 高——DDL/CITI/DUA 流程标准化，全球研究者均可申请
再分发	❌ 受限——因继承 MIMIC-III 的 DUA，不可无条件再分发
工程友好度	✅ 高——patient_data/{hadm_id}/ 切片设计免去全量 MIMIC-III 部署
训练友好度	⚠️ 中——8,042 实体规模适中，适合评估而非大规模预训练

§7 生态与谱系：一条"MIMIC → EHRCon → EHR-ReasonCon"的演进链

7.1 家族图谱

EHR-ReasonCon 不是凭空出现，而是 EHR 一致性核验研究脉络上的一环：

MIMIC-III v1.4 (2016, PhysioNet)
      │  （上游临床数据库）
      ▼
EHRCon v1.0.1 (2024, NeurIPS D&B Track, Kwon et al.)
      │  （首次系统化"笔记–表一致性"基准，105 篇笔记）
      ▼
EHR-ReasonCon v1.0.0 (2026, PhysioNet)
      │  （复用同 105 篇笔记，深挖推理密集型案例）
      ▼
EHR-INSPECTOR (2026, 配套论文 arXiv:2605.26463)
         （LLM 核验系统，以 EHR-ReasonCon 为评估基准）

演进逻辑：EHRCon 解决"有没有基准"的问题；EHR-ReasonCon 解决"基准够不够难"的问题——把难度从表层数值匹配抬升到医学解读 + 事件关系 + 时序变化。这条链条体现了 EHR-NLP 领域从"抽取"到"推理"的范式迁移。

7.2 与前作 EHRCon 的差异边界

维度	EHRCon (2024)	EHR-ReasonCon (2026)
关注层次	表层信息（数值/简单事件是否存在）	推理密集型（解读/关系/时序）
源笔记	MIMIC-III 笔记	同一批 105 篇（复用）
核心贡献	建立一致性核验基准	提升核验难度、暴露表层匹配盲区
关系	前作/父项目 v1.0.1	派生/升级 v1.0.0

关键理解：EHR-ReasonCon 不是"更大的 EHRCon"，而是"更难的 EHRCon"——笔记数量相同（105），但标注针对的是 EHRCon 覆盖不足的高推理案例。因此两者互补而非替代：想测基础匹配能力用 EHRCon，想测推理能力用 EHR-ReasonCon。

7.3 在 EHR-NLP 数据集景观中的位置

EHR-ReasonCon 处于"临床文本 × 结构化数据对齐"这一交叉口，与下列方向相邻：

• 笔记–表一致性（EHRCon、EHR-ReasonCon）：判断两套数据是否自洽；
• EHR 问答（ArchEHR-QA 等）：给定问题从 EHR 取证作答；
• 临床推理基准（er-reason 等）：在特定临床场景做诊断/处置推理；
• 医疗编码/信息抽取：从文本抽结构化字段。

EHR-ReasonCon 的独特价值在于：它把核验（verification）与推理（reasoning）结合，既不是纯抽取，也不是纯问答，而是证据驱动的自洽性判定。

7.4 潜在应用场景

• 病历质控（documentation quality assurance）：自动标记笔记与结构化表不一致处，辅助病案室与质控团队；
• 患者安全：不一致可能危及决策，自动化核验可作预警；
• EHR 数据治理：评估二次分析前的数据可信度；
• LLM 临床能力评测：作为需要"查表+推理"的 agentic 任务基准；
• 自动化病历书写辅助：在录入阶段实时比对。

§8 方法学启示：四条可迁移的经验

8.1 "专家定协议 + 受训标注员劳动"是可复制的流水线

EHR-ReasonCon 的人员结构（4 专家定协议 → 8 标注员执行 → 独立复核者终审）与"专家海量标注"不同——专家只参与协议制定与疑难裁决，把重复劳动交给受训标注员。这种分层能显著降低专家时间成本，同时通过 Stage 4 的双人独立 + 复核保住质量，是一种可迁移到其他临床标注项目的组织范式。

8.2 把"人类如何查表推理"形式化成工具，是走向可计算化的关键

Stage 0 把标注员的检索模式提炼为 8 个模块化表探索工具（对齐 / 值画像 / 时序检索），这套工具随后被 EHR-INSPECTOR 直接复用为 LLM agent 的 action space。这揭示了一个通用方法论：标注协议不只是"标注指南"，还可以直接升格为系统设计的规格说明。人工标注流程与自动化系统共享同一套操作语义，是"人机协同标注"的优雅形态。

8.3 承认 span 主观性、改用语义评估，是对标注现实的诚实回应

作者明确拒绝精确字符串匹配、主张 LLM-as-a-judge 双档评估（harsh/lenient）。这体现了一种成熟态度：当任务本质是语义判断时，评估指标必须与任务本质匹配。对所有构建"有主观边界"数据集的项目，这是重要提醒——不要用一把刻度不符的尺子去量。

8.4 二分类标签之外，保留推理痕迹字段

consistency_check_path、commonsense_medical_none、medical_knowledge_source、abnormal_case 等字段，让数据集不止于标签，还保留了"为什么这么标"“依赖了什么知识”"是否边缘案例"的元信息。这让数据集可用于：分析模型在何种知识依赖类型上失手、定位异常案例、审计推理路径。标注即数据，元信息即研究资产。

8.5 临床专家跨机构参与，提升判断的临床可信度

三家韩国临床机构（Samsung Medical Center、Samsung Changwon Hospital、Asan Medical Center）的临床专家参与协议制定，使"什么算不一致"的判断贴近真实临床语境，而非纯技术人员的想当然。

§9 与库内条目的关系

9.1 可互链条目

库内条目	rid	关系类型	互链理由
er-reason	985	主题相邻（临床推理）	同为"临床推理"主题，但 er-reason 聚焦急诊场景推理，本条聚焦笔记-表一致性核验——可作"临床推理基准"族群互链，需辨析主题差异
archehr-qa-bionlp-task-2025	1000	任务相邻（EHR 文本任务）	同为 EHR 文本处理任务，但 ArchEHR-QA 为问答范式，本条为核验范式——可作"EHR-NLP 任务"族群互链
chexstruct-cxreasonbench	待查	主题相邻（结构化推理）	名字含 reason/struct，可能涉及结构化推理，可作对照互链（需核实主题）
3dreasonknee	待查	弱相邻	含 reason，但为影像三维推理，主题相远，谨慎互链
medreason	待查	弱相邻	含 reason，可能为医学推理数据集，可作"推理"族群弱互链

9.2 上游与谱系互链

• MIMIC-III（若库内有条目）：本条的上游临床数据库，Parent Project；
• EHRCon（前作）：若库内无独立条目，则在正文以谱系形式说明。

9.3 检索路径建议

• 从"电子健康记录 / 临床电子病历 / 医疗NLP / 临床文本"标签进入；
• 从"一致性核验 / note-table / ReasonCon / EHRCon"关键词进入；
• 从"EHR-INSPECTOR / LLM-as-a-judge / 临床推理"进入配套方法学。

9.4 建议互链点（供主会话参考）

正文 §4 已就 er-reason（rid 985）与 ArchEHR-QA（rid 1000）做了逐一辨析，建议：

• 本条 → er-reason（rid 985）：标注"主题相邻、需辨析"；
• 本条 → archehr-qa-bionlp-task-2025（rid 1000）：标注"任务相邻、需辨析"。

§10 DAIMS 元数据符合性

下表对照 DAIMS（Data Archive and Information Management System / 数据管理元数据框架）的核心维度，给出 EHR-ReasonCon 的元数据画像：

DAIMS 维度	EHR-ReasonCon 对应内容
Dataset Identity（数据集标识）	EHR-ReasonCon v1.0.0；DOI 10.13026/7m91-3010；PhysioNet 托管；RRID:SCR_007345
Provenance（来源）	MIMIC-III v1.4（源笔记）+ EHRCon v1.0.1（笔记来源）；五阶段专家引导标注
Content Description（内容描述）	8,042 锚实体、105 篇笔记、14 张结构化表；CONSISTENT/INCONSISTENT 标签
Structure & Format（结构与格式）	逐笔记 JSON（权威）+ annotations.csv（扁平表）+ 源笔记 CSV + patient_data 分表 CSV + resources 字典
Access & Rights（获取与权利）	Credentialed Access；PhysioNet Credentialed Health Data License 1.5.0；DUA 1.5.0；CITI 培训
Quality & Reliability（质量与可靠性）	实体识别一致性 0.897；一致性标注一致性 0.888；独立复核者复查全部 105 篇
Temporal Coverage（时间覆盖）	上游 MIMIC-III 2016；数据集发布 2026-09-15
Relationships（关联）	Parent Projects：EHRCon v1.0.1、MIMIC-III v1.4；配套系统 EHR-INSPECTOR
Citation & Attribution（引用与归属）	Kwon et al. (2026)；需同时引用 EHRCon 与 PhysioNet 平台
Domain-specific（领域特有）	entity_type 三分类；knowledge dependence (c/m/n)；evidence_row_ids；inconsistent_columns

§11 避坑清单：六个已踩过的坑

坑 1：把 EHR-ReasonCon 当作 EHRCon 的别名。
二者是派生关系但独立数据集——EHRCon 是 NeurIPS 2024 前作，EHR-ReasonCon 是 2026 PhysioNet 版本，笔记数虽同为 105，标注层次与贡献不同。检索时不要用 EHRCon 的编号/DOI 去指代 EHR-ReasonCon。

坑 2：把 er-reason（rid 985）误认作本条目。
er-reason 的 “er” = Emergency Room（急诊），主题为急诊临床推理；EHR-ReasonCon 的 “ehr” = Electronic Health Record。名字含相同词根 “reason” 但内核不同，切勿当作别名。

坑 3：把 ArchEHR-QA（rid 1000）误认作本条目。
ArchEHR-QA 是 BioNLP 2025 共享任务的问答数据集，任务是"从 EHR 笔记取证作答"；EHR-ReasonCon 是一致性核验数据集。一个是 QA，一个是 verification。

坑 4：假设数据可公开下载。
EHR-ReasonCon 是 Credentialed Access，需 PhysioNet 账号 + CITI 培训 + DUA。且部分地域受法律/政策限制不可下载。不要期待一个公开直链。

坑 5：用精确字符串匹配评估。
官方明确不建议 exact string matching。因系统与人工标注者 span 边界/粒度不同，必须用语义级实体评估（LLM-as-a-judge，harsh/lenient 双档）。

坑 6：把 "14 张表"全当作患者事件表。
14 张表中含 4 张字典表（D_items、D_icd_diagnoses、D_icd_procedures、D_labitems）。事件值来自事件表、含义来自字典表，理解时要分开这两类。

§12 总结

12.1 三句话总结

1. EHR-ReasonCon 是 KAIST 主导、托管于 PhysioNet 的临床笔记↔结构化表一致性核验数据集，8,042 个锚实体、105 篇笔记、对照 14 张 MIMIC-III 表，v1.0.0 发布于 2026-09-15。
2. 它的独特定位是把核验难度从"表层匹配"提升到"推理密集型"——专攻需医学解读、事件关系推理、时序变化分析的案例，是 EHRCon 的升级版与 EHR-INSPECTOR 的评估基准。
3. 它是凭据访问数据集（PhysioNet Credentialed Health Data License 1.5.0），且作者主张用语义级 LLM-as-a-judge 双档评估而非精确匹配。

12.2 适合谁

• 开发/评估笔记–表一致性核验系统的研究者；
• 做 EHR-NLP / 临床推理 的模型团队；
• 研究病历质控与患者安全的临床信息学人员；
• 需要agentic 工具调用评测集的 LLM 研究者（EHR-INSPECTOR 式任务）；
• 关注标注方法学（专家协议 + 受训标注员 + 推理痕迹字段）的数据集构建者。

12.3 不适合谁

• 需要公开免申请数据的人（本数据集是凭据访问）；
• 需要大规模预训练语料的人（8,042 实体为评估级规模）；
• 研究对象儿科/门诊/非 ICU 的人（继承 MIMIC-III 成人 ICU 偏差）；
• 只想做纯文本抽取、不需跨表推理的人（应看抽取类数据集）。

12.4 30 秒决策卡

要一个"需要 LLM 查表 + 医学推理才能判断病历自洽性"的评测集？ → EHR-ReasonCon。
能接受凭据访问门槛（账号+CITI+DUA）？ → 是，就申请。
想测的是纯抽取或问答？ → 换数据集（抽取类 / ArchEHR-QA）。
担心和 er-reason 混？ → 记住：ReasonCon = Consistency，er-reason = 急诊。

FAQ（高频问答）

A. 基础认知

Q：EHR-ReasonCon 和 EHRCon 到底什么关系？
A：EHRCon（NeurIPS 2024）是本条的前作/父项目 v1.0.1；EHR-ReasonCon 复用其 105 篇笔记，重新做推理密集型标注，是独立数据集。

Q：为什么叫 “ReasonCon”？
A：“Reason” 指 reasoning-intensive（推理密集型），“Con” 指 consistency（一致性）——合起来即"推理密集型一致性核验"。

Q：和 er-reason（rid 985）是一回事吗？
A：不是。er-reason 的 er = Emergency Room（急诊），主题是急诊推理；EHR-ReasonCon 的 ehr = Electronic Health Record，主题是笔记-表一致性。

Q：和 ArchEHR-QA（rid 1000）是一回事吗？
A：不是。ArchEHR-QA 是 BioNLP 2025 的 EHR 问答共享任务；本条是一致性核验数据集。

Q：谁来维护？
A：KAIST 主导构建；PhysioNet（MIT Laboratory for Computational Physiology）托管。

B. 数据与获取

Q：怎么下载？
A：需 PhysioNet 凭据访问——注册账号 + 完成 CITI “Data or Specimens Only Research” 培训 + 签署 DUA 1.5.0。

Q：许可是什么？
A：PhysioNet Credentialed Health Data License 1.5.0。

Q：为什么有地域限制？
A：因派生自受 DUA 约束的 MIMIC-III，部分地域因法律/政策不可下载，官方页有明确提示。

Q：能再分发吗？
A：不能无条件再分发，须遵守上游 MIMIC-III/EHRCon 的 DUA 链。

Q：文件格式？
A：逐笔记 JSON（权威）+ annotations.csv（扁平）+ 源笔记 CSV + patient_data 分表 CSV + resources 字典。

C. 数据与规模

Q：多大？
A：8,042 锚实体、105 篇笔记、14 张结构化表。

Q：标签分布？
A：CONSISTENT 5,847、INCONSISTENT 2,195。

Q：笔记类型分布？
A：Discharge 38、Physician 33、Nursing 34。

Q：怎么划分？
A：test : valid = 4 : 1。

Q：标注可靠性如何？
A：实体识别一致性 0.897、一致性标注一致性 0.888（系数口径官方未细化）。

D. 任务与方法

Q：核心任务是什么？
A：判定笔记中锚实体是否被结构化表记录支持（CONSISTENT/INCONSISTENT）。

Q：entity_type 有哪几类？
A：1=数值型、2=存在可核事件型、3=字符串/类别型。

Q：为什么要推理？
A：如确认"贫血"需解读血红蛋白，"抗生素敏感性"需连接多个微生物字段，"血压下降趋势"需跨时间点。

Q：配套系统是什么？
A：EHR-INSPECTOR，一个 LLM 框架（分段→抽锚实体与时序引用→工具查表→核验）。

Q：怎么评估？
A：语义级实体评估（LLM-as-a-judge，harsh/lenient 双档），不用精确匹配。

E. 生产与库内

Q：库内会与谁关联？
A：er-reason（rid 985）、archehr-qa-bionlp-task-2025（rid 1000）——均需辨析主题差异。

Q：上游是谁？
A：MIMIC-III v1.4 与 EHRCon v1.0.1。

Q：DOI 是什么？
A：v1.0.0 为 10.13026/7m91-3010；latest 指针 10.13026/t7hc-k382。

Q：有几个版本？
A：目前仅 v1.0.0（Initial Release，2026-09-15）。

F. 复现与工程细节

Q：要部署全量 MIMIC-III 吗？
A：不需要。patient_data/{hadm_id}/ 已按入院切片，加载对应 admission 的表即可。

Q：JSON 怎么读？
A：标准 json 库即可；键为笔记 ROW_ID，值为锚实体列表。

Q：README 有什么？
A：说明笔记、标注、结构化表三者如何互相引用。

Q：evidence_row_ids 是什么？
A：支撑该实体判断的表记录 ROW_ID 列表，可定位原始证据。

Q：inconsistent_columns 是什么？
A：对不一致实体，指明差异发生的具体列（如 charttime、valuenum）。

Q：consistency_check_path 是什么？
A：标注者到达标签所走的工具探索/推理路径编码轨迹，用于审计。

Q：commonsense_medical_none 是什么？
A：标记该实体核验所需知识类型：常识©/医学(m)/无需(n)。

Q：abnormal_case 是什么？
A：标记标注中发现的非典型/边缘案例。

事实清单（硬事实 30 条）

1. 官方全名：EHR-ReasonCon: Reasoning-Intensive Consistency Verification Between Clinical Notes and Structured Tables in Electronic Health Records。
2. 版本：v1.0.0（Initial Release）。
3. 发布日期：Sept. 15, 2026。
4. 托管平台：PhysioNet（RRID:SCR_007345）。
5. 维护方：MIT Laboratory for Computational Physiology。
6. DOI（v1.0.0）：10.13026/7m91-3010。
7. DOI（latest）：10.13026/t7hc-k382。
8. 作者数：13 人。
9. 通讯/资深作者：Edward Choi（KAIST）。
10. 主建机构：KAIST（韩国科学技术院）。
11. 合作机构：Ghent University、Samsung Medical Center、Samsung Changwon Hospital、Asan Medical Center。
12. 标注锚实体总数：8,042。
13. 临床笔记数：105。
14. 笔记类型数：3（Discharge/Physician/Nursing）。
15. Discharge：38 篇 / 3,497 实体 / 2,041 一致 / 1,456 不一致。
16. Physician：33 篇 / 2,841 实体 / 2,388 一致 / 453 不一致。
17. Nursing：34 篇 / 1,704 实体 / 1,418 一致 / 286 不一致。
18. 全集 CONSISTENT：5,847。
19. 全集 INCONSISTENT：2,195。
20. 关联结构化表数：14。
21. 14 表中含字典表 4 张（D_items/D_icd_diagnoses/D_icd_procedures/D_labitems）。
22. 划分比例：test : valid = 4 : 1。
23. 实体识别一致性：0.897。
24. 一致性标注一致性：0.888。
25. 标注员数：8 位受训标注员。
26. 临床专家数：4 位（放射肿瘤/普外/麻醉住院医/EHR 技师）。
27. 表探索工具数：8 个（3 类功能）。
28. 标注阶段数：5（Stage 0–4）。
29. 上游源：MIMIC-III v1.4 + EHRCon v1.0.1。
30. 许可：PhysioNet Credentialed Health Data License 1.5.0（凭据访问）。
31. 获取要求：PhysioNet 账号 + CITI 培训 + DUA 1.5.0。
32. 配套系统：EHR-INSPECTOR（LLM 框架）。
33. 配套论文：arXiv:2605.26463（Towards error-free EHRs）。
34. 推荐评估：语义级实体评估（LLM-as-a-judge，harsh/lenient 双档）。
35. 官方加载示例用 HADM_ID=115468.0、ROW_ID=1087。

---

深度扩写篇（续写区）

本节起为接管续写代理 agent-e2-ehrreasonc 在原 723 行成稿之后追加的定向扩写内容，遵循"保留原文、只增不改"的铁律。以下章节编号紧接原文 §12 总结，从 §13 续起；原文 FAQ（A–F 组）与事实清单（30 条）之后新增的编号坑点、FAQ 续编、对照表、参考文献与存照附录亦在本续写区。

§13 数据规模与构成（深度扩写）

§2 已给出 EHR-ReasonCon 的骨架数字，本节把"8,042 锚实体 / 105 篇笔记 / 14 张结构表"这组标签背后的构造逻辑拆开讲清楚，帮助使用者在没有拿到数据之前就能对它的形状、稀疏性、类别倾斜有一个准确预期。

13.1 三层嵌套的容器结构

EHR-ReasonCon 的数据在逻辑上是三层嵌套：

数据集 (Dataset)
 └── 临床笔记 (Note)  × 105
      └── 锚实体 (Anchor Entity)  × 合计 8,042
           └── 证据行 (Evidence Row, ROW_ID)  × 变长

• 第一层：105 篇临床笔记，来自 MIMIC-III v1.4 的成人 ICU 入院记录，且刻意复用前作 EHRCon v1.0.1 的同一批 105 篇（详见 §4 与 §19 谱系说明）。这样设计的目的是让 EHR-ReasonCon 与 EHRCon 形成可对照的姊妹数据集：同一批笔记、同一批结构化表，差别只在标注的"难度取向"。
• 第二层：8,042 个锚实体（anchor entity）。锚实体是"笔记里出现的、应当能被结构化表中某条记录支持或否证的具体断言单元"——一个数值、一次事件、一个类别值。它不是任意短语，而是经过标注协议筛选、必须可落到表项/列上的最小可核验单位。
• 第三层：证据行。每个锚实体都挂着 evidence_row_ids，即支撑该判断的结构化表记录 ROW_ID 列表。它是变长的：一个实体可能对应 0 行（完全无记录）、1 行、或跨表多行。

理解这三层的关键在于：笔记是"主张"，结构化表是"证据"，锚实体是把二者对接起来的"抓手"，而标签则是"主张是否被证据支持"的裁决。

13.2 类别倾斜：为什么 Discharge 笔记贡献了近半实体

逐笔记类型看实体分布，有一个显著不均衡（数据来自官方页与 FACTS.md §4）：

Note Type	Notes（笔记数）	Entities（实体数）	Consistent（一致）	Inconsistent（不一致）	每篇平均实体
Discharge	38	3,497	2,041	1,456	≈92.0
Physician	33	2,841	2,388	453	≈86.1
Nursing	34	1,704	1,418	286	≈50.1
Total	105	8,042	5,847	2,195	≈76.6

三点观察：

1. Discharge（出院小结）单篇实体最密（≈92 篇均），因为它是对整段住院过程的汇总性文本，会复述大量数值（检验、生命体征、用药）与事件（手术、培养结果），可核验点天然多。
2. Nursing（护理记录）单篇实体最少（≈50 篇均），护理记录偏流程性与观察性描述，许多内容是"做了什么"而非"测得什么"，可落到结构化表的具体断言相对少。
3. 不一致率差异极大：Discharge 不一致率 ≈41.6%（1,456/3,497），Physician 仅 ≈15.9%（453/2,841），Nursing ≈16.8%（286/1,704）。出院小结是错误/矛盾最集中的区域——这既符合临床直觉（汇总文本转写、拼接时更易出错），也意味着评测集里的"难题"主要来自 Discharge 类。

工程含义：如果你的核验系统在 Discharge 笔记上表现明显差于其他两类，不要先怀疑代码 bug，这大概率是难度分布的真实反映；应分笔记类型分层报告指标。

13.3 全集标签比例与"推理密集型"的代价

全集 CONSISTENT 5,847 / INCONSISTENT 2,195，整体不一致率 ≈27.3%。相较于"表层匹配"型的一致性任务，EHR-ReasonCon 的不一致比例偏高，原因正是它的选题取向——它主动保留并加权那些需要医学解读、事件关系或时序推理才能判定的案例，而不是简单的大数值比对。

值得强调：INCONSISTENT 不等于"临床错误"。在标注语义里，INCONSISTENT 只表示"笔记中的锚实体与其对应结构化表记录不一致"，其成因可能包括：

• 笔记转写/概括时的数字化误差（如血压 120 误写 102）；
• 时间点归属错位（把 A 时点值写到 B 时点）；
• 单位不一致（mg vs µg 未换算）；
• 语义等价但表述不同被误判（这类应经 Stage 3 复核剔除，但边缘案例仍在）；
• 记录缺失导致"无法支持"（严格口径下计入不一致）。

因此把 INCONSISTENT 直接当"医疗差错率"用是口径误用，详见后续 §16 坑点与 §17 FAQ。

13.4 14 张结构表的角色分工

EHR-ReasonCon 对照 14 张 MIMIC-III 表。按角色可分为三类：

（A）患者事件表（承载"发生了什么"）

• Chartevents：床旁监护与护理记录（生命体征、GCS、呼吸机参数等），是锚实体命中率最高的表之一。
• Labevents：化验结果（血常规、生化、血气、微生物相关检验等）。
• Microbiologyevents：微生物培养与药敏，是"抗生素敏感性"类事件关系推理的关键表。
• Inputevents_cv / Inputevents_mv：液体与药物输入（cv=CareVue、mv=MetaVision 两套源系统），同一概念分表是常见踩坑点。
• Outputevents：出量（尿量、引流量等）。
• Procedureevents_mv：床旁操作事件（MetaVision 口径）。
• Prescriptions：处方/用药，时间与剂量信息。

（B）编码表（承载"诊断/操作编码"）

• Diagnoses_icd：ICD 诊断编码。
• Procedures_icd：ICD 操作编码。

（C）字典表（承载"编码到名称的映射"，共 4 张）

• D_items：Chartevents/Inputevents/Outputevents/Procedureevents 的 itemid 字典。
• D_labitems：Labevents 的 itemid 字典。
• D_icd_diagnoses：ICD 诊断码字典。
• D_icd_procedures：ICD 操作码字典。

关键提示：官方"14 张表"的口径包含 4 张字典表，因此严格意义上的"患者事件表"是 10 张。字典表本身不含患者事件，但核验时几乎绕不开——要把 itemid=220045 翻译成"心率"，必须查 D_items。这直接影响"是否算命中"的判断，是 §16 中的重点坑。

13.5 逐表锚实体分布的量级直觉

官方未逐表公开锚实体计数，但从任务定义与标注协议可推断命中分布的量级：

• 最高频：Chartevents、Labevents（数值型锚实体主战场，entity_type=1 的主体）。
• 中频：Prescriptions、Microbiologyevents、Inputevents_cv/mv、Outputevents。
• 低频但高价值：Diagnoses_icd/Procedures_icd（编码断言，entity_type 多为 3），以及各字典表（作为核对工具而非直接证据）。

工程含义：做数据加载与自检时，不要假设每篇笔记都触及全部 14 张表。按 patient_data/{hadm_id}/ 切片加载时，缺失某张表对应文件属正常现象，而非数据损坏。

13.6 变长证据与"多点支撑"现象

evidence_row_ids 的变长特性带来一个重要现象：多点支撑。一个锚实体（例如"住院期间最高收缩压 180"）可能由多条 Chartevents 记录共同支撑，标注会记录相关行的 ROW_ID 集合。评价一个核验系统时，它能否定位到正确的一组证据行，与"能否给出正确标签"是两个不同维度的问题：

• 标签正确 + 证据正确：真正判对；
• 标签正确 + 证据错误/缺失：可能"蒙对"（尤其在不一致率偏低的类上）；
• 标签错误 + 证据正确：推理/裁决环节出错。

因此建议在自建评测里分开报告"标签准确率"和"证据定位质量（如证据行召回/精确）"，不要只看二分类标签。

13.7 数据规模速查（本节压缩版）

指标	数值	出处
临床笔记	105	官方页
笔记类型	3（Discharge/Physician/Nursing）	官方页
锚实体总数	8,042	官方页
结构表	14（含 4 张字典表）	官方页
CONSISTENT	5,847	官方页
INCONSISTENT	2,195	官方页
整体不一致率	≈27.3%	5,847/2,195 推导
Discharge 不一致率	≈41.6%	1,456/3,497 推导
划分	test : valid = 4 : 1	官方页
实体识别一致性	0.897	官方页
一致性标注一致性	0.888	官方页
唯一患者数	未披露	FACTS.md 待核 2

说明：不一致率为派生量（由官方披露的分子分母推导），官方未直接给出百分比表述；引用时宜注明"据 …/… 推导"。

§14 任务定义与标注体系（深度扩写）

§3 已概括了五阶段流水线与标字段。本节把任务的形式化定义、标注字段的语义、推理难度的三种来源以及标注可靠性的口径逐一展开，作为使用者实现核验系统与评估脚本时的规格参考。

14.1 任务的正式表述

给定：

• 一篇临床笔记 N（Discharge / Physician / Nursing 之一）；
• 该笔记对应的患者入院切片 A = {T_1, T_2, …, T_14}，其中每张 T_i 是 14 张结构化表中若干行记录；
• 笔记中抽取出的一个锚实体 e（由标注协议界定，携带 entity_type、position、data 等元信息）。

任务：输出一个二分类标签

label(e) ∈ { CONSISTENT, INCONSISTENT }

其判定语义为：笔记中由锚实体 e 所表达的主张，是否被结构化表切片 A 中的记录所支持。

这是一个逐实体的、证据驱动的蕴含判定（evidence-grounded entailment）：不是判断笔记整体真假，也不是检索式问答，而是对单一断言单元在给定证据库下给出"支持/不支持"的裁决，并需要指出证据（evidence_row_ids）与指出分歧点（inconsistent_columns）。

14.2 与相邻任务的边界

为避免误把 EHR-ReasonCon 当别的任务用，明确几条边界：

相邻任务	与本任务的区别
信息抽取（NER/RE）	本任务不只要抽实体，还要判定其与表的一致性；抽取是前置步骤。
事实核查（fact verification）	相似，但本任务的"证据库"是结构化表而非自由文本；且锚实体是临床数值/事件/类别，不是通用陈述。
表格问答（TableQA）	本任务不是"问一个问题再答"，而是"给定断言判定支持否"，且证据可跨表。
笔记-表对齐（alignment）	对齐只解决"哪条记录对应哪个实体"，本任务还要在对齐之后做一致性裁决，含推理。
语义等价判定	本任务判定的是笔记 vs 表（跨模态），且不一致可能来自时序/单位/缺失，而非纯改写。

14.3 entity_type 三分类的判定细则

EHR-ReasonCon 用 entity_type 区分锚实体的可核验形态，这决定了核验时该用什么工具、比什么字段：

• type 1 = numerical value（数值型）：锚实体是一个数值断言，如"肌酐 2.1 mg/dL"“体温 38.5℃”。核验路径通常是：定位对应表项（如 Labevents 的 creatinine itemid）→ 比对 valuenum/valueuom/charttime。难点：单位换算、时点选择、同一项目多次测量取哪一次。
• type 2 = existence-verifiable event（存在可核事件型）：锚实体断言"某事发生过/未发生"，如"行气管插管"“血培养阳性”。核验路径是：在相关表中检索是否存在对应事件记录。难点：事件可能跨表（培养+药敏）、可能由多行共同定义、可能被编码/字典间接表达。
• type 3 = string/categorical value（字符串/类别型）：锚实体是一个类别或字符串值，如"诊断：2 型糖尿病"“药物：万古霉素”“手术：腹腔镜胆囊切除”。核验路径是：匹配编码/名称，常需经字典表翻译。难点：同义词、编码粒度、缩写。

实践中，type 1 与 type 3 的核验更"可自动化"，type 2 与跨表的复合断言最"吃推理"，也最接近数据集"reasoning-intensive"的立意。

14.4 标注字段逐项语义

下表把标注元数据字段的语义与用途讲透（字段名依据 FACTS.md §5）：

字段	类型	语义	用途
data	字符串/数值	将笔记中的锚实体值映射到表项/列的规范化表示	建立"笔记值 ↔ 表字段"的对应
label	枚举	consistent / inconsistent	任务监督信号
entity_type	1/2/3	数值型 / 存在可核事件型 / 字符串类别型	决定核验路径与工具
position	偏移/区间	锚实体在笔记原文中的位置	溯源、span 级评测
table	表名	该实体核验所对照的结构化表	定位证据表
evidence_row_ids	列表	支撑判断的表记录 ROW_ID 集合	证据定位评测、审计
consistency_check_path	轨迹编码	标注者到达标签所走的工具探索/推理路径	可解释性、过程审计
inconsistent_columns	列表	对不一致实体，差异发生的具体列（如 charttime、valuenum）	解释"错在哪一维"
almost_consistent	布尔	近一致（边缘）标志	隔离模糊案例，避免污染主指标
commonsense_medical_none	c/m/n	所需知识类型：常识 / 医学 / 无需知识	分析"知识依赖"对难度的影响
medical_knowledge_source	URL/引用	医学知识来源（当需要外部医学知识时）	可复现、可审计
check_db	布尔	是否需查数据库或指南	区分"查表可得"与"需外部知识"
abnormal_case	布尔	标注中发现的非典型/边缘案例	质量控制与边界分析

14.5 三类推理强度的来源

EHR-ReasonCon 之所以"reasoning-intensive"，在于锚实体的判定往往不能靠字面比对，而需下列三类推理（FACTS.md §7）：

1. clinical interpretation（临床解读）：需要把参数放回医学语境。例：笔记写"贫血"，表里没有"贫血"这一 string，但有血红蛋白 Hb=9.2 g/dL；判定 CONSISTENT 需要知道"Hb 偏低 ⇒ 贫血"的临床阈值知识。
2. event relations（事件关系）：需要连接跨字段/跨表的信息来确认一个事件。例：笔记写"对万古霉素敏感"，需连接 Microbiologyevents 中"菌种 + 抗生素 + 敏感性（S/I/R）"多个字段甚至多行记录，才能确认该断言成立。
3. temporal change（时序变化）：需要跨时间点比较。例：笔记写"血压较前下降"，需取 A 时点与 B 时点的血压记录并做趋势比较，单点记录不足以支持。

这三种推理，恰是 commonsense_medical_none（c/m/n）与 check_db 字段想刻画的东西。做误差分析时，按这三类切分比按表名切分更能揭示系统短板。

14.6 五阶段流水线的角色与产物

结合 §3，把每个阶段的输入→产物→把关点列清（依据 FACTS.md §5）：

• Stage 0 预标注设置：4 位临床专家制定标注协议；设计并固化 8 个模块化表探索工具（3 类功能：entity-to-table-item alignment、database exploration & value profiling、temporal & conditional record retrieval）。产物是协议 + 工具集。把关点是"工具能否覆盖三类推理"。
• Stage 1 Anchor Entity Identification：标注员识别人工笔记中"应对应结构化表项"的锚实体。把关点是"实体是否可落到表项/列"。
• Stage 2 Tool-Assisted Table Exploration：标注员用 8 个工具查表、取证据记录（产出 evidence_row_ids、table、consistency_check_path）。把关点是"证据是否可复现"。
• Stage 3 Consistency Verification：在证据基础上做一致性裁决（含时序/常识/医学推理），标注 label 与 inconsistent_columns。把关点是"推理链是否成立"。
• Stage 4 Annotation Reliability：每篇笔记由 2 名标注员独立完成 → 互商 → 存疑升级至医学专家裁决；另设独立复核者复查全部 105 篇。把关点是"标注者间一致性"。

14.7 标注可靠性的口径与局限

官方披露两项标注者间一致性：实体识别 0.897、一致性标注 0.888（FACTS.md §4）。使用这两数字时注意三点：

1. 系数类型未细化：官方页未标明是 Cohen’s κ、Krippendorff’s α 还是原始一致率（agreement rate），FACTS.md 存照为"待核 4"。不同系数含义不同（κ/α 已扣除随机一致，原始一致率未扣除），跨论文比较时不可直接等同。
2. 两个数字对应两个子任务：0.897 针对"实体边界/实体识别"（span 级），0.888 针对"一致性标签"（分类级）。它们不能互换引用。
3. 一致性高不等于任务简单：0.888 的分类一致性在二分类里看似一般（随机基线约 0.5–0.7 视分布而定），考虑到任务含大量需要推理的边缘案例（almost_consistent、abnormal_case），这已属不易；但也提示边缘案例仍是噪声来源。

14.8 标注体系的设计取舍（解读）

从字段设计能读出三条设计取舍：

• 保留过程而非只留结论（consistency_check_path）：作者显然把"可审计性"放在重要位置，这对受监管的医疗场景尤为必要。
• 显式标记边缘（almost_consistent、abnormal_case）：不追求把所有案例都硬塞进二分类，而是把模糊案例标出来，供下游按需过滤——这让数据集能同时服务"严格评测"和"鲁棒性分析"两种用途。
• 显式标注知识依赖（commonsense_medical_none、check_db、medical_knowledge_source）：把"需要什么知识才能判对"变成一等公民，便于研究者按知识依赖分层评估模型，也正是"reasoning-intensive"命题的操作化。

这三点合起来，使 EHR-ReasonCon 不只是一个标签文件，而是一份带推理过程与知识标注的诊断工具。

§15 使用指南：数据加载与核验脚手架（代码示例）

前提：EHR-ReasonCon 为凭据访问（Credentialed Access）数据集，须经 PhysioNet 账号 + CITI 培训 + 签署 DUA 后方可下载（详见 §6）。以下代码示例假设你已合法获得数据，仅演示工程实践，不含任何规避许可的做法。字段名依据官方页与 FACTS.md §5；若拿到数据后字段名有出入，以官方 README 为准。

15.1 目录结构假设

据 FACTS.md §6 与 §12 FAQ（源笔记 CSV + 逐笔记 JSON + patient_data 分表 + resources 字典），典型解包后结构如下（以官方 README 为准）：

ehr-reasoncon/
├── notes/                       # 105 篇源笔记
│   ├── discharge/*.csv          # 或合并为 notes.csv，含 note_type/text/row_id/hadm_id
│   ├── physician/
│   └── nursing/
├── annotations.csv              # 扁平版：一行一锚实体
├── annotations/                 # 逐笔记 JSON（权威版）
│   └── <ROW_ID>.json            # 键为笔记 ROW_ID，值为锚实体列表
├── patient_data/
│   └── <HADM_ID>/               # 按入院切片
│       ├── chartevents.csv
│       ├── labevents.csv
│       ├── prescriptions.csv
│       ├── inputevents_cv.csv
│       ├── inputevents_mv.csv
│       ├── outputevents.csv
│       ├── procedureevents_mv.csv
│       ├── microbiologyevents.csv
│       ├── diagnoses_icd.csv
│       ├── procedures_icd.csv
│       └── ...
├── resources/                   # 字典
│   ├── d_items.csv
│   ├── d_labitems.csv
│   ├── d_icd_diagnoses.csv
│   └── d_icd_procedures.csv
└── README.md

15.2 加载扁平标注表

import pandas as pd

ROOT = "ehr-reasoncon"

# 扁平版标注：一行一锚实体。若你的列名不同，用 rename 对齐。
ann = pd.read_csv(f"{ROOT}/annotations.csv")
print(ann.shape)
print(ann.columns.tolist())
# 期望包含（视官方 README）：
# note_row_id, hadm_id, note_type, entity_index,
# data, label, entity_type, position, table,
# evidence_row_ids, consistency_check_path,
# inconsistent_columns, almost_consistent,
# commonsense_medical_none, medical_knowledge_source,
# check_db, abnormal_case

# 标签分布复核（应得 5847 / 2195，见 §2）
print(ann["label"].value_counts())

若 evidence_row_ids 等列表字段以字符串形式（如 "1087;1090" 或 "[1087, 1090]"）存储，需解析：

import json
from typing import List

def parse_row_ids(cell) -> List[int]:
    if pd.isna(cell):
        return []
    s = str(cell).strip()
    if s.startswith("["):
        return [int(x) for x in json.loads(s)]
    if ";" in s:
        return [int(x) for x in s.split(";") if x]
    if "," in s:
        return [int(x) for x in s.split(",") if x]
    return [int(s)] if s else []

ann["evidence_row_ids_parsed"] = ann["evidence_row_ids"].apply(parse_row_ids)

15.3 加载逐笔记 JSON（权威版）

import json, os, glob

def load_note_annotations(annot_dir: str) -> dict:
    """返回 {note_row_id: [entity_dict, ...]}"""
    out = {}
    for fp in glob.glob(os.path.join(annot_dir, "*.json")):
        with open(fp, "r", encoding="utf-8") as f:
            obj = json.load(f)
        # 官方 JSON 键为笔记 ROW_ID，值为锚实体列表
        for k, v in obj.items():
            out[int(k)] = v
    return out

notes_ann = load_note_annotations(f"{ROOT}/annotations")
print(f"载入 {len(notes_ann)} 篇笔记的标注")

# 抽查一个实体的字段
first_note = next(iter(notes_ann))
sample = notes_ann[first_note][0]
for k, v in sample.items():
    print(f"  {k}: {v!r}")

15.4 按 hadm_id 切片加载结构化表

import os
import pandas as pd

TABLES = [
    "chartevents", "labevents", "prescriptions",
    "inputevents_cv", "inputevents_mv", "outputevents",
    "procedureevents_mv", "microbiologyevents",
    "diagnoses_icd", "procedures_icd",
]

def load_admission(hadm_id: int) -> dict:
    """载入某次入院的全部结构化表；缺失的表返回空 DataFrame。"""
    base = f"{ROOT}/patient_data/{hadm_id}"
    tables = {}
    for t in TABLES:
        fp = os.path.join(base, f"{t}.csv")
        if os.path.exists(fp):
            tables[t] = pd.read_csv(fp)
        else:
            tables[t] = pd.DataFrame()  # 该笔记未触及此表属正常（见 §13.5）
    return tables

def load_dictionaries() -> dict:
    return {
        "d_items": pd.read_csv(f"{ROOT}/resources/d_items.csv"),
        "d_labitems": pd.read_csv(f"{ROOT}/resources/d_labitems.csv"),
        "d_icd_diagnoses": pd.read_csv(f"{ROOT}/resources/d_icd_diagnoses.csv"),
        "d_icd_procedures": pd.read_csv(f"{ROOT}/resources/d_icd_procedures.csv"),
    }

15.5 用字典表翻译 itemid（关键步骤）

Chartevents/Labevents 里的 itemid 只是数字，必须经字典表翻译为可读概念（见 §13.4、§16 坑 7）：

dicts = load_dictionaries()

def resolve_item_label(itemid: int) -> str:
    """先查 d_items，再查 d_labitems。"""
    di = dicts["d_items"]
    if {"itemid", "label"}.issubset(di.columns):
        hit = di.loc[di["itemid"] == itemid, "label"]
        if len(hit):
            return str(hit.iloc[0])
    dl = dicts["d_labitems"]
    if {"itemid", "label"}.issubset(dl.columns):
        hit = dl.loc[dl["itemid"] == itemid, "label"]
        if len(hit):
            return str(hit.iloc[0])
    return f"[unknown itemid {itemid}]"

# 示例：把某次入院的 chartevents itemid 加上可读标签
tables = load_admission(hadm_id=115468)  # 示例 hadm_id
ce = tables["chartevents"]
if not ce.empty and "itemid" in ce.columns:
    ce["item_label"] = ce["itemid"].apply(resolve_item_label)
    print(ce[["itemid", "item_label", "charttime", "valuenum", "valueuom"]].head())

15.6 构造逐实体的核验输入

要把一个锚实体喂给核验器，通常需要三样东西：笔记上下文 + 实体位置 + 候选证据行。

def build_entity_context(note_row_id: int, entity_idx: int, notes_df: pd.DataFrame):
    # 1) 笔记文本
    row = notes_df.loc[notes_df["row_id"] == note_row_id]
    assert len(row) == 1
    note_text = str(row.iloc[0]["text"])
    hadm_id = int(row.iloc[0]["hadm_id"])

    # 2) 实体元信息
    ent = notes_ann[note_row_id][entity_idx]

    # 3) 证据候选：优先用 evidence_row_ids 定位到具体表
    tables = load_admission(hadm_id)
    evidence = {}
    for rid in parse_row_ids(ent.get("evidence_row_ids", [])):
        for tname, tdf in tables.items():
            if "row_id" in tdf.columns:
                hit = tdf.loc[tdf["row_id"] == rid]
                if len(hit):
                    evidence.setdefault(tname, []).append(hit)
                    break
    return {
        "note_text": note_text,
        "hadm_id": hadm_id,
        "entity": ent,
        "evidence": evidence,
    }

ctx = build_entity_context(note_row_id=1087, entity_idx=0, notes_df=notes_df)
print(ctx["entity"])

15.7 最小评测脚手架（实体级二分类）

官方推荐语义级/实体级评估（LLM-as-a-judge，harsh/lenient 双口径），而非精确字符串匹配（见 §4、§8）。下面给出一个不含 LLM 依赖的二分类指标骨架，作为下限基线对照：

from sklearn.metrics import precision_recall_fscore_support, confusion_matrix

def evaluate_classification(golds, preds, labels=("consistent", "inconsistent")):
    p, r, f1, sup = precision_recall_fscore_support(
        golds, preds, labels=list(labels), zero_division=0
    )
    for lab, pi, ri, fi, si in zip(labels, p, r, f1, sup):
        print(f"{lab:14s}  P={pi:.3f}  R={ri:.3f}  F1={fi:.3f}  n={si}")
    print("confusion matrix (rows=gold, cols=pred):")
    print(confusion_matrix(golds, preds, labels=list(labels)))

# 假设你有一个 predict(entity_ctx) -> "consistent"/"inconsistent" 的实现
golds, preds = [], []
for row_id, ents in notes_ann.items():
    for idx in range(len(ents)):
        ctx = build_entity_context(row_id, idx, notes_df)
        golds.append(str(ctx["entity"]["label"]).lower())
        preds.append(predict(ctx))  # 占位：替换为你自己的模型调用
evaluate_classification(golds, preds)

代码中如出现 predict(ctx)，需替换为你自己的实现（规则法 / 微调模型 / LLM 管线）。不要用精确字符串匹配笔记 span 与表值来当主指标——这正是作者明确不建议的评测口径。

15.8 语义级评估（LLM-as-a-judge）要点

若采用作者推荐的语义级评估，实践建议：

• 双口径：同时跑 harsh（严格） 与 lenient（宽松） 两档判官提示词，报告两套分数。harsh 下把"语义接近但粒度/边界不同"判为不匹配，lenient 下判为匹配；二者差值反映边界敏感度。
• 判官输入：应包含 note_text 的相关窗口、锚实体、golds 标签，以及证据行（否则判官无法核对事实）。
• 固定判官与提示词：跨系统比较时保持判官模型、版本、提示词、温度一致，否则分数不可比。
• 报告方差：LLM 判官有随机性，至少跑多次取均值/方差，或设 temperature=0。

# 伪代码：双口径判官调用
def judge(note_window, entity, gold_label, evidence, mode):
    """mode ∈ {'harsh','lenient'}；返回 True 表示判对。"""
    prompt = render_judge_prompt(mode=mode, note=note_window,
                                 entity=entity, gold=gold_label,
                                 evidence=evidence)
    verdict = call_llm(prompt, temperature=0.0)   # 你的 LLM 接口
    return parse_verdict(verdict)

acc_harsh   = run_judge_all(mode="harsh")
acc_lenient = run_judge_all(mode="lenient")
print(f"harsh={acc_harsh:.3f}  lenient={acc_lenient:.3f}  Δ={acc_lenient-acc_harsh:+.3f}")

15.9 测试集与验证集的使用（test:valid = 4:1）

数据划分为 test : valid = 4 : 1（FACTS.md §4）。工程建议：

• 只在 valid 上做模型选择/超参调优，把 test 留作最终一次报告，避免泄漏。
• 分层抽样检查：确认 valid 里 Discharge/Physician/Nursing 三类及 consistent/inconsistent 两类的比例是否与全集一致；若不均，最终报告需分类型给出，不要只报总体。
• 由于 almost_consistent / abnormal_case 存在（见 §14.4），建议主表报"全体"，附表报"剔除边缘案例后"，两种口径都给，方便复现与对比。

15.10 复现检查清单（打钩自检）

• [ ] 已合法获得数据（PhysioNet 凭据 + DUA 签署）。
• [ ] 扁平标注表实体总数 = 8,042；CONSISTENT = 5,847；INCONSISTENT = 2,195（对不上说明版本或解析有误）。
• [ ] 笔记数 = 105；三类笔记数 = 38 / 33 / 34。
• [ ] 逐笔记 JSON 与扁平 CSV 的记录能对齐（键 = 笔记 ROW_ID）。
• [ ] evidence_row_ids 能在对应表里定位到行；缺失属正常但要有统计。
• [ ] 字典表翻译 itemid 生效（Chartevents/Labevents 都能出可读标签）。
• [ ] 评测报告分笔记类型、分推理类型（c/m/n、check_db）、双口径至少三类切分。
• [ ] 固定随机种子与判官配置，记录版本号以便复现。

§16 避坑清单（续编：坑 7 – 坑 14）

原文 §11 已列坑 1 – 坑 6，本节编号续接，补齐至 14 则，覆盖数据工程、评价口径、语义理解三类高频踩坑。所有条目均针对 EHR-ReasonCon 的口径，凡与上游 MIMIC-III 相关的坑点会特别标注。

坑 7：把 itemid 当概念用（不查字典表）

现象：直接对 Chartevents/Labevents 的 itemid 做数值比对，或把它当"指标名"随手聚类。
后果：itemid=220045 是心率、220050 是收缩压、50912 是肌酐——纯数字无语义。不做字典翻译，你的规则/模型根本无法把"笔记里的心率"对到"表里哪一列"。更隐蔽的是，同一概念在不同表里 itemid 不同，D_items 与 D_labitems 是两套字典。
正解：核验前先经 resources/d_items.csv 与 d_labitems.csv 把 itemid 翻成 label，再做对齐（见 §15.5）。注意 D_items 覆盖 Chartevents/Inputevents/Outputevents/Procedureevents，D_labitems 覆盖 Labevents，不要只查一张。

坑 8：把 INCONSISTENT 直接当"医疗差错率"

现象：报告里写"本数据集显示 27.3% 的病历存在医疗错误"。
后果：口径误用。INCONSISTENT 只表示"笔记锚实体与结构化表记录不一致"，其成因大量来自转写、时序归属、单位、缺失，而非临床决策错误（见 §13.3）。把它当差错率会严重误导。
正解：始终用"note–table inconsistency"表述；如需谈差错，须经临床复核并明确区分"记录不一致"与"医疗差错"，二者非同一概念。

坑 9：忽视 Inputevents_cv 与 Inputevents_mv 的分表陷阱

现象：只加载 inputevents_mv，或把两表简单 concat 后去重。
后果：MIMIC-III 的 Inputevents 有 CareVue（cv）与 MetaVision（mv）两套源系统，同一患者数据只落在其中之一（原系统决定）。只加载一张会漏掉另一半患者。此外两表列名/口径可能有别，直接 concat 易混。
正解：两表都加载；核验某患者时按 hadm_id 取，该患者通常只出现在其中一表；若两表都空却笔记断言了输入事件，需记为提高"证据缺失"嫌疑，但不必然是数据错误。

坑 10：用精确字符串匹配当主评测口径

现象：把系统输出的 span 与人工标注 span 做 == 比对，或对表值做字符串完全相等判定，然后报告"准确率 12%"。
后果：分数虚低且不可比。作者明确不建议精确匹配——span 边界与粒度在系统与人工标注者间天然不同（“120/80 mmHg” vs “BP 120/80”；“2.1” vs “2.10 mg/dL”），人工标注者之间也只有 0.897 的实体识别一致性（见 §14.7）。
正解：采用实体级语义评估（LLM-as-a-judge，harsh/lenient 双口径），把"语义等价、边界不同"在 lenient 下判对（见 §15.8）。报告时说明判官模型与提示词版本。

坑 11：忽略 almost_consistent / abnormal_case，让边缘案例污染主指标

现象：把全部 8,042 实体一锅端进主指标，不区分边缘案例。
后果：边缘案例（近一致、非典型）本身带主观性，会稀释或放大系统差异，使结论不稳；与其他论文比较时因口径不同而不可比。
正解：主表给"全体"，附表给"剔除 almost_consistent/abnormal_case 后"的分数（见 §15.9）；分析差异时优先看剔除后的一致性，再单独讨论边缘案例的行为。

坑 12：把时序断言当单点比对（丢 charttime）

现象：判定"血压较前下降"时只取一条血压记录，或取全住院范围内的极值。
后果：**时序推理（temporal change）**是数据集三类推理之一（§14.5）。单点比对会系统性地把"趋势类"断言判错；取全范围极值则可能与笔记所指的具体时点不符。
正解：凡断言含"较前/上升/下降/持续/趋势"等词，必须取至少两个时点并核对 charttime；必要时用工具类"temporal & conditional record retrieval"的思路定位窗口。inconsistent_columns 若指向 charttime，往往正是时点归属问题（见 §14.4）。

坑 13：跨表复合断言只查一张表

现象：判定"对某抗生素敏感"时只查 Microbiologyevents 的菌种行，或只查 Prescriptions。
后果：事件关系（event relations）类断言常常跨字段、跨行、跨表：药敏信息在 Microbiologyevents（菌种 + 抗生素 + S/I/R），而"是否真的用了该药"在 Prescriptions/Inputevents。只查一张表会漏证据或误判。
正解：对 entity_type=2 或明显复合的断言，多表联查；把 evidence_row_ids 理解为"证据集合"而非"单行"（§13.6），并在评测里单独报告跨表案例的表现。

坑 14：无视凭据访问与再分发约束

现象：把数据（或其子集）上传到公共仓库、贴进论文附录、或作为模型权重训练语料的公开镜像。
后果：违反 PhysioNet Credentialed Health Data License / DUA 1.5.0，且因派生自受 DUA 约束的 MIMIC-III（§6），再分发条件更严。部分地域还因法律/政策限制不可下载——绕过限制同样违规。
正解：仅在 DUA 授权范围内使用；不无条件再分发；发布模型/代码时不附带受约束的原始数据；在论文中引用官方 DOI 而非附带数据副本；遵守上游 MIMIC-III/EHRCon 的许可链。

坑点速查（7–14）：7 必查字典表 · 8 不一致≠差错 · 9 cv/mv 两表 · 10 禁精确匹配 · 11 隔离边缘案例 · 12 时序要双点 · 13 复合要跨表 · 14 守 DUA。

§16.1 与前六坑的合看

原文坑 1–6 更偏"数据身份与获取"层面（来历、笔记来源、版本等），本节坑 7–14 则偏"用起来的工程与口径"层面。两者合起来构成一份从"拿到数据"到"报出可信指标"的完整清单。建议把它固化成团队 checklist，尤其坑 10（评测口径）与坑 14（许可），前者决定结论可信度，后者决定合规底线。

§17 常见问题 FAQ（续编，12+ 组）

原文 FAQ 已覆盖 A–F 六组基础问答。本节为续编，聚焦使用者在"上手、评测、合规、辨析"阶段最常追问的 15 组问题，编号 G–U，便于检索。凡与原文重复的知识点，此处只做更深一层追问，不重复基础定义。

G. 上手与数据加载

Q：我按 hadm_id 加载某患者，发现很多表文件不存在，是数据坏了吗？
A：不是。105 篇笔记不会触及全部 14 张表（见 §13.5），某次入院缺失某表文件属正常。按 patient_data/{hadm_id}/ 加载时，对缺失表返回空表即可，别当异常处理。

Q：itemid 到底是什么？为什么不能直接当指标名？
A：itemid 是 MIMIC-III 内部数字编码，无语义；同一概念在不同表里编码不同（D_items 与 D_labitems 是两套字典）。核验前必须翻译为 label（见 §15.5、坑 7）。

Q：扁平 annotations.csv 和逐笔记 JSON 哪个优先用？
A：JSON 是权威版（键为笔记 ROW_ID），CSV 是扁平投影。以 JSON 为准，CSV 便于 pandas 分析；二者记录数应一致（8,042），对不上就是解析或版本问题。

Q：evidence_row_ids 是空的正常吗？
A：正常。部分锚实体对应 0 行（表里无记录，严格口径下计入不一致）。空证据本身是有信息量的信号，不要丢弃。

H. 标签语义

Q：INCONSISTENT 是不是就代表"医生写错了"？
A：不是。它只表示"笔记锚实体与表记录不一致"，成因可能是转写、时序、单位、缺失等（见 §13.3、坑 8）。把它等号于"医疗差错"是口径误用。

Q：CONSISTENT 是不是代表"完全字面相同"？
A：不是。CONSISTENT 是语义支持：笔记主张被表记录支持即可，表述可不同（如"贫血"由"Hb=9.2"支持）。这也正是不能用精确匹配评测的根本原因。

Q：为什么 INCONSISTENT 比例（≈27%）比一般一致性任务高？
A：因为数据集刻意保留高推理门槛的不一致案例（临床解读、事件关系、时序），是有意为之的难度取向，不是数据缺陷（见 §13.3）。

I. 评测口径

Q：到底该用什么指标评？作者推荐什么？
A：作者推荐实体级语义评估（LLM-as-a-judge，harsh/lenient 双口径），明确不建议精确字符串匹配（见 §14.7、坑 10）。基础二分类 P/R/F1 可作下限对照，但主指标应是语义级。

Q：harsh 和 lenient 差很多说明什么？
A：差值反映系统对span 边界与粒度的敏感度。差值大，说明系统分数高度依赖评审严格度，跨系统比较时要特别小心（见 §15.8）。

Q：要不要单独测证据定位？
A：建议要。标签正确 ≠ 证据正确（见 §13.6）。只报标签准确率，会掩盖"蒙对"（尤其在不一致率低的 Physician/Nursing 类）。可另报证据行的召回/精确。

Q：分类型报告有必要吗？
A：非常有必要。Discharge 不一致率 ≈41.6%，Physician/Nursing 仅 ≈16%，难度分布差异极大（见 §13.2）。只报总体会误导。

J. 与 EHRCon / MIMIC-III 的关系

Q：EHR-ReasonCon 和 EHRCon 什么关系？会不会撞车？
A：它是 EHRCon 的姊妹/延续：共用同 105 篇笔记，但取向不同——EHRCon 偏表层匹配，EHR-ReasonCon 强调 reasoning-intensive（临床解读/事件关系/时序）。二者不是别名，是同一谱系的两代（见 §4、§19）。

Q：需要部署 MIMIC-III 全库才能用吗？
A：不需要。数据已按 hadm_id 切片（见 §15.4）。加载对应入院的表即可，无需全库。

Q：它跟 MIMIC-III 的许可是一样的吗？
A：门槛沿 MIMIC-III 口径（都属 Credentialed Access），但它是独立数据集，有自己的 DOI 与 DUA；再分发须遵守上游许可链（见 §6、坑 14）。

K. 机构、版本与引用

Q：谁做的？通讯作者是谁？
A：KAIST 主导，联合 Ghent University、Samsung Medical Center、Samsung Changwon Hospital、Asan Medical Center；通讯/资深作者 Edward Choi（见 FACTS.md §3）。

Q：有几个版本？DOI 用哪个？
A：目前仅 v1.0.0（Initial Release，2026-09-15）。版本 DOI 10.13026/7m91-3010，latest 指针 10.13026/t7hc-k382（见 FACTS.md §1）。

Q：配套论文是什么？
A：arXiv:2605.26463，“Towards error-free EHRs: Reasoning-intensive consistency verification between clinical notes and structured tables in electronic health records”；配套系统 EHR-INSPECTOR（见 §5）。

L. 库内辨析（易混条目）

Q：库里的 er-reason（rid 985）是本条目吗？
A：不是。er-reason 是 UCSF 急诊场景的临床推理基准，主题是"急诊推理"，与本条目的"笔记–表一致性核验"不同。名字像、主题异，非别名（见 §18）。

Q：那 archehr-qa-bionlp-task-2025（rid 1000）呢？
A：也不是。它是 BioNLP 2025 的患者-EHR 证据落地问答（QA）共享任务，任务是问答而非一致性核验（见 §18）。

Q：遇到名字相近的条目，怎么快速判断是不是同一个？
A：看三件事：DOI / 托管平台 / 任务形态。同一数据集 DOI 一致；本条目的唯一标识是 PhysioNet ehr-reasoncon + DOI 10.13026/7m91-3010。名字相似但 DOI/任务不同，即不同条目。

M. 实操与陷阱

Q：加载时最常踩的坑是什么？
A：三点：不查字典表（坑 7）、cv/mv 只加载一张（坑 9）、时序断言当单点比对（坑 12）。这三条能解释绝大多数"明明数据在库里却判不对"的情况。

Q：能不能把数据副本传到公共平台方便复现？
A：不能。违反 DUA 与上游 MIMIC-III 许可链（见 §6、坑 14）。合规做法是公开代码与处理脚本，让使用者各自凭据获取数据后复现。

§18 相关数据集对照表（含库内条目辨析）

EHR-ReasonCon 处在一个"临床文本 + 结构化 EHR + 推理"的密集生态中。本节用对照表把它与上游、姊妹、以及库内两个名字相近但主题不同的条目区分清楚，避免引用时张冠李戴。库内条目的 rid 依据 FACTS.md §1 与 §8 的查重结论。

18.1 首要辨析：EHR-ReasonCon vs 库内 er-reason vs archehr-qa-bionlp-task-2025

这三者名字里都带 “ehr/reason”，最易混淆，必须逐一划清：

维度	EHR-ReasonCon（本条目）	er-reason（库内 rid 985）	archehr-qa-bionlp-task-2025（库内 rid 1000）
主题	临床笔记 ↔ 结构化表的推理密集型一致性核验	UCSF 急诊场景的临床推理数据集/基准	BioNLP 2025 患者-EHR **证据落地问答（QA）**共享任务
任务形态	逐锚实体二分类（CONSISTENT/INCONSISTENT）+ 证据定位	临床推理（急诊场景）	问答（QA，生成/答案落地到证据）
输入/输出	笔记断言 + 表记录 → 支持/不支持 + 证据行	急诊情境 → 推理结论	临床问题 + EHR → 答案（附证据）
数据来源	MIMIC-III v1.4（复用 EHRCon 的 105 篇笔记）	UCSF 急诊（非 MIMIC 笔记）	患者-EHR 文本
与本条目关系	就是本条目	同属"临床推理"大主题，不同数据集、不同场景，可作互链	同属"EHR-NLP 任务"大主题，QA 而非一致性核验，可作互链
是否别名/撞车	—	否（不同主题、不同来源）	否（不同任务形态）
引用时注意	DOI 10.13026/7m91-3010	勿与本条目混引	勿把 QA 指标套到本条目

一句话记法：er-reason = 急诊"推理"；archehr-qa-… = EHR"问答"；EHR-ReasonCon = 笔记–表"一致性核验"。三者只共享"临床 + 推理/EHR"的宽泛语境，任务与数据均不同。

18.2 谱系对照：上游与前作

数据集	角色	与 EHR-ReasonCon 的关系
MIMIC-III v1.4	上游临床数据库（PhysioNet，2016）	提供源笔记与 14 张结构化表；本数据集派生自它（Johnson, Pollard, Mark 等）
EHRCon v1.0.1	前作（NeurIPS 2024 D&B Track，Kwon et al.）	共用同 105 篇笔记；EHRCon 偏表层一致性，EHR-ReasonCon 向高推理场景深化
EHR-ReasonCon v1.0.0	本条目的版本	2026-09-15 于 PhysioNet 发布

时间线：MIMIC-III（2016-09）→ EHRCon（2024，NeurIPS D&B）→ 姊妹论文 arXiv:2605.26463（2026）→ EHR-ReasonCon v1.0.0（2026-09-15）。

18.3 任务邻域对照：相似但不相同

对照对象	相似点	关键差异（防误用）
事实核查（fact verification，如 FEVER 范式）	都是"给定主张判支持/反驳"	本任务证据库是结构化表、主张是临床数值/事件/类别
表格问答 / 表格蕴含（TableQA / Table NLI）	都涉及表	本任务不做自然语言提问，且证据跨表、含时序与临床解读
笔记-表对齐（note-table alignment）	都要把笔记对到表	对齐只是前置；本任务要在对齐后做推理裁决
临床信息抽取（如 i2b2/n2c2 系列 NER）	都处理临床文本	抽取不判一致性；本任务以核验为核心
语义等价 / 释义识别	都涉及"不同表述同一含义"	本任务是跨模态（文本↔表）且含时序/单位/缺失维度的不一致

18.4 生态定位图（文字版）

            MIMIC-III v1.4 (上游临床数据库)
                    │
        ┌───────────┴────────────┐
        │                        │
   EHRCon v1.0.1            (其他 MIMIC 派生任务)
   (NeurIPS 2024 D&B)           │
        │                        │
        │  共用 105 篇笔记        │
        ▼                        ▼
   EHR-ReasonCon v1.0.0   ← 本条目的数据核心
   (PhysioNet 2026-09-15)
        │
        │  评测基准
        ▼
   EHR-INSPECTOR (LLM 核验框架，配套论文 arXiv:2605.26463)

   库内宽语境互链（主题相近、任务不同）：
     ├─ er-reason (rid 985)               · 急诊临床推理
     └─ archehr-qa-bionlp-task-2025 (rid 1000) · EHR 问答共享任务

18.5 与库内互链的建议

按 FACTS.md §8 的口径，本条目在库内可作宽语境互链：

• er-reason（rid 985）：挂"临床推理基准"互链，注明"同为推理主题，但对象为急诊场景，非笔记–表一致性"。
• archehr-qa-bionlp-task-2025（rid 1000）：挂"EHR-NLP 任务"互链，注明"为 QA 任务，非一致性核验"。
• 若库内已有 MIMIC-III 类条目，可作为上游互链；EHRCon 若在库内，则作前作互链。

辨析要点复用：无论何时，判断"是否同一条目"只看 DOI + 托管平台 + 任务形态 三要素；名字相近绝不构成别名。本条目的锁定标识：PhysioNet ehr-reasoncon + DOI 10.13026/7m91-3010 + 任务"note–table consistency verification"。

18.6 一表速览：易混三者的"身份证"

条目	唯一标识	一句话身份
EHR-ReasonCon	PhysioNet ehr-reasoncon / DOI 10.13026/7m91-3010	笔记–表推理密集型一致性核验
er-reason (rid 985)	库内记录 985	急诊临床推理数据集
archehr-qa-bionlp-task-2025 (rid 1000)	库内记录 1000	BioNLP 2025 EHR 问答共享任务

§19 参考文献与来源附录

本节汇总本篇条目的信息出处，标注可靠等级。凡官方一手来源标【一手】，由一手推导的派生量标【派生】，官方未细化的疑点标【待核】。所有网络事实以 FACTS.md 记录为准，本篇未新增网络请求。

19.1 一手来源（官方）

1. 【一手】PhysioNet 内容页 — EHR-ReasonCon v1.0.0：https://physionet.org/content/ehr-reasoncon/。提供官方全名、发布日（Sept. 15, 2026）、笔记数（105）、笔记类型分布（Discharge 38 / Physician 33 / Nursing 34）、锚实体数（8,042）、CONSISTENT（5,847）/ INCONSISTENT（2,195）、结构表数（14，含字典表）、划分（test:valid = 4:1）、标注者间一致性（0.897 / 0.888）、许可与获取要求。
2. 【一手】PhysioNet DOI（v1.0.0）：10.13026/7m91-3010。
3. 【一手】PhysioNet DOI（latest 指针）：10.13026/t7hc-k382。
4. 【一手】PhysioNet 平台：MIT Laboratory for Computational Physiology 维护，RRID:SCR_007345。
5. 【一手】配套论文（预印本）：Y. Kwon, J. Kim, J. Choi, P. Rabaey, M. Kim, S. Im, J. Yang, J.-M. Lee, S. Lee, J. Kim, H. Yoon, H. Kwon, E. Choi, “Towards error-free EHRs: Reasoning-intensive consistency verification between clinical notes and structured tables in electronic health records,” arXiv:2605.26463, 2026。
6. 【一手】上游前作：EHRCon（NeurIPS 2024 Datasets and Benchmarks Track，Kwon et al.），版本 v1.0.1。
7. 【一手】上游数据库：MIMIC-III Clinical Database v1.4（PhysioNet，2016；A. Johnson, T. Pollard, R. Mark 等）。

19.2 派生量（由一手推导）

8. 【派生】整体不一致率 ≈27.3%：由 2,195 / 8,042 推导（分子分母均官方披露）。
9. 【派生】Discharge 不一致率 ≈41.6%：由 1,456 / 3,497 推导。
10. 【派生】Physician 不一致率 ≈15.9%：由 453 / 2,841 推导。
11. 【派生】Nursing 不一致率 ≈16.8%：由 286 / 1,704 推导。
12. 【派生】各笔记类型篇均实体（Discharge ≈92.0 / Physician ≈86.1 / Nursing ≈50.1 / 全体 ≈76.6）：由实体数除以笔记数推导。

引用派生量时，建议一并注明"据官方披露的分子与分母推导"，以免被误认为官方直接表述。

19.3 待核事项（官方未细化，存照）

13. 【待核】唯一患者数未披露：官方页仅披露 105 篇笔记与 8,042 锚实体，患者级规模为遗留疑点。
14. 【待核】标注者间一致性系数类型未指明：0.897 / 0.888 未标明是 Cohen’s κ、Krippendorff’s α 还是原始一致率；跨论文比较须谨慎。
15. 【待核】"14 张表"含字典表口径：D_items / D_icd_diagnoses / D_icd_procedures / D_labitems 为字典表（非患者事件表）；"14 张表"以官方口径为准，严格意义的患者事件表为 10 张。
16. 【待核】arXiv 编号格式：arXiv:2605.26463 的 YYMM 段（2605 = 2026-05）暗示预印于 2026-05 前后，本篇未二次抓取 arXiv 页核对标题/作者序；数据以 FACTS.md 记录为准。
17. 【待核】逐表锚实体计数未逐表公开：本篇 §13.5 的分布为量级推断，非官方逐表数字。

19.4 引用与规范说明

• 本条目的唯一标识三要素：PhysioNet slug ehr-reasoncon + DOI 10.13026/7m91-3010 + 任务形态 “note–table consistency verification”。
• 辨析提醒：er-reason（rid 985）与 archehr-qa-bionlp-task-2025（rid 1000）非本条目别名，详见 §18。
• 许可提醒：本数据集为 Credentialed Access，再分发受限（详见 §6、坑 14）。
• 数据与代码分离原则：复现时应公开代码/脚本，数据由使用者各自凭据获取，不得附带受约束数据的副本。

§20 存照附录（双口径与待核记录）

本附录承接 FACTS.md §9，把本篇涉及的双口径冲突与待核疑点集中存照，供后续核证与勘误。存照原则：只记录、不臆断；遇冲突时并列两种口径并标注推导，不擅自择一为"正确"。

20.1 双口径逐条

双口径 1 — 日期

• 口径 A（官方页）：Published Sept. 15, 2026。
• 口径 B（论文）：arXiv:2605.26463 编号暗示 2026 年（YYMM=2605 ⇒ 约 2026-05）。
• 存照：二者不矛盾——论文预印早于数据集正式发布属常态。发布日以官方页 2026-09-15 为准。

双口径 2 — DOI

• 口径 A（版本 DOI）：10.13026/7m91-3010（v1.0.0）。
• 口径 B（latest 指针）：10.13026/t7hc-k382。
• 存照：当前仅 v1.0.0 一个版本，两个 DOI 当前指向同一版本；引用具体版本时用前者，引用"最新"时可用后者。

20.2 待核逐条

待核 1 — arXiv 编号

• 疑点：arXiv:2605.26463 编号格式（YYMM=2605）虽合理，但本篇未二次抓取 arXiv 页确认标题与作者序。
• 处置：标题/作者以 FACTS.md 记录为准；如需强引用，建议主会话二次核实。

待核 2 — 唯一患者数

• 疑点：官方未披露唯一患者数，仅披露笔记数（105）与锚实体数（8,042）。
• 处置：任何"患者级"规模表述均不应写入，除非另行核证。

待核 3 — 字典表计数口径

• 疑点：14 表中 4 张为字典表，"14 张表"的口径含字典表。
• 处置：引用时注明口径；严格意义的患者事件表为 10 张。

待核 4 — 标注者间一致性系数类型

• 疑点：0.897 / 0.888 未标明系数类型（κ / α / 原始一致率）。
• 处置：原样存照数值，不擅自加系数名；跨论文比较时须留意口径差异。

待核 5 — 逐表锚实体分布

• 疑点：官方未逐表公开锚实体计数。
• 处置：§13.5 的分布为量级推断；如需精确数字，须自行统计（前提是已获授权数据）。

20.3 勘误与版本记录

• 本篇（续写区 §13–§20）由接管续写代理 agent-e2-ehrreasonc在原 723 行成稿之后追加，遵循"保留原文、只增不改"铁律；原文 §§0–12、FAQ（A–F）、事实清单（30 条）保持不变。
• 续写区数据一律与 FACTS.md 对齐；凡新增的派生量（不一致率、篇均实体）均在 §19.2 标注为【派生】。
• 如后续官方更新（如新版本发布、患者数披露、系数类型明确），应在追加而非改写既有文字的前提下补记，保持可追溯。

20.4 存照一句话总括

两个双口径（日期、DOI）均已调和并说明；五个待核（arXiv 编号、患者数、字典表口径、一致性系数类型、逐表分布）均已登记。凡本篇未确证者，一律标【待核】或【派生】，绝不冒充官方数字。

---

续写区结束。以上 §13–§20 由 agent-e2-ehrreasonc 追加，正文主体见前文 §§0–12。

---

相关数据集导航

以下为站内 AI-Ready 数据集百科中与本词条共享多个主题标签的相关数据集，按相关度降序排列：

• mimic-ext-synnotes — 共享标签：电子健康记录 / 医疗NLP / 临床文本 / 医学问答与基准 / 重症监护
• echo-note2num — 共享标签：电子健康记录 / 临床电子病历 / 医疗NLP / 临床文本 / 重症监护
• cliniq — 共享标签：电子健康记录 / 临床电子病历 / 医疗NLP / 医学问答与基准
• brateca — 共享标签：电子健康记录 / 临床电子病历 / 医疗NLP / 临床文本
• synsum — 共享标签：电子健康记录 / 临床电子病历 / 医疗NLP / 临床文本 / 医学问答与基准
• anzics-apd — 共享标签：电子健康记录 / 临床电子病历 / 医学问答与基准 / 重症监护
• archehr-qa-bionlp-task-2025 — 共享标签：电子健康记录 / 临床电子病历 / 医疗NLP / 医学问答与基准
• annotation-opioid-use-notes — 共享标签：电子健康记录 / 医疗NLP / 临床文本 / 重症监护
• mednli — 共享标签：电子健康记录 / 医疗NLP / 临床文本 / 医学问答与基准
• aci-bench — 共享标签：电子健康记录 / 医疗NLP / 临床文本 / 医学问答与基准

导航说明：本章节由全站统一标签体系自动计算生成（标签重合度算法），双向可达；点击链接可跳转至对应数据集词条。