ArchEHR-QA — 患者-电子病历证据落地的问答共享任务数据集

INFOBOX — ArchEHR-QA 一屏速览

维度	内容
本质	患者提问-EHR 证据落地问答共享任务数据集（BioNLP 2025 @ ACL；2026 迭代为 CL4Health @ LREC）
官方读音	“Archer”
团队	美国国立医学图书馆（NLM/NIH）院内研究部；Sarvesh Soni、Dina Demner-Fushman
发布平台	PhysioNet（认证访问）；DOI v1.4 = 10.13026/sneb-dn55
规模	167 例病例（PhysioNet v1.4：dev 20 + test 100 + test-2026 47）；2025 共享任务用 120 例
数据源	公共健康论坛真实患者提问 + MIMIC-III / MIMIC-IV-Note 衍生临床笔记
场景	重症监护（ICU）与急诊科（ED）
任务	生成带句级引用的自然语言答案，证据落地于笔记句
标注	句级 relevance 三标签：essential / supplementary / not-relevant
评估	双轴：Factuality（引用 P/R/F1，strict/lenient）+ Relevance（BLEU/ROUGE/SARI/BERTScore/AlignScore/MEDCON）
2025 结果	29 队 / 75 系统；冠军 DMISLab：Overall 53.7%、strict micro F1 58.6%、平均 relevance 48.8%
获取	PhysioNet 认证访问（CITI 培训 + DUA）；无公开训练集
许可	PhysioNet Credentialed Health Data License 1.5.0 + DUA 1.5.0
库内互链	MIMIC-IV-Note(47)、MIMIC-III(590)、MIMIC-IV(592)、emrQA(139)、EHRXQA(646)、MedQuAD(160)

ArchEHR-QA 是一个把"患者提问"与"电子健康记录"接在一起的数据集：它不是让模型背诵医学知识，而是让它回答一位真实患者关于自己住院经过的追问——“为什么给我做这个手术？”“药物不能代替吗？”——并且每一个论断都必须用病历里的具体句子作证。它的名字读作 “Archer”，是 2025 年 ACL 生物医学自然语言处理工作坊（BioNLP 2025）的官方共享任务数据集；2026 年它拆成四个子任务继续办（CL4Health @ LREC 2026）。对医疗机构而言，这类系统直面的是"患者门户消息正在压垮临床医生"这一现实问题：自动生成有据可查的答复，是缓解临床负担的候选路径。

导语读法三则：

1. 只想下数据：直奔 §6 获取与许可——注意这是认证访问（CITI 培训 + DUA），无公开直链，且无训练集。
2. 关心任务与标注：直奔 §2 与 §3——句级 relevance 三标签与"带引用答案"是本数据集的定义性设计。
3. 关注 2025 战果：直奔 §5 评估与基准——29 队 75 系统、冠军 DMISLab 53.7% 是理解任务难度的最快入口。

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

美国医院的患者门户（patient portal）每天涌进大量患者消息，其中相当一部分是索取医疗信息——“我的检查结果是什么意思”“这个治疗有没有必要”。回复这些消息是临床医生负担攀升的主要来源之一。理想的解法是：系统读取该患者本人的电子健康记录（EHR），自动起草一份既有临床依据、又贴合患者关切的答复草稿，供医生审阅发送。

问题在于，"有依据"这件事此前几乎无人认真评测。已有的 EHR 问答工作大多面向临床医生的信息需求（例如让系统从病历里抽取某个检验值），鲜有面向患者的、并且显式检查系统是否引用了正确的证据。更缺的是数据：要把"答案是否正确"与"答案是否落在证据上"分开衡量，就需要一份逐句标注了相关性、并配有人类参考答案的数据集——而这样的公开资源此前并不存在。

ArchEHR-QA 的回答分三层。第一层是数据：收集公共论坛里真实的患者提问，把它们对齐到公开可获取的真实 EHR（MIMIC-III / MIMIC-IV 的临床笔记），由临床医生改写为规范问题、并撰写带句级引用的参考答案。第二层是标注：把笔记节选逐句标为 essential（必须引用）/ supplementary（可作支撑）/ not-relevant（不应引用），使"引用质量"可被精确计分。第三层是评测框架：把"证据识别"与"答案生成"拆成两个可分别度量的轴——Factuality（引用是否命中）与 Relevance（答案文本是否切题），并把二者合成总榜分数。作者称这是首个公开的、同时封装患者提问与其 EHR 相关临床证据的数据集。

§0 读法三则：

1. 这个条目要同时讲清两件事：作为数据集（PhysioNet 上的 XML/JSON 发布物，v1.4 共 167 例）与作为共享任务（BioNLP 2025 用 120 例办了比赛）——两者的规模口径不同，切勿混用（§2、坑 1）。
2. 全文的规模数字严格分层：120 = 2025 共享任务子集；134 = Scientific Data 论文口径；167 = PhysioNet v1.4 最新。每处引用都标明版本（§7、坑 2）。
3. "认证访问 + 无训练集"是它 AI-Ready 属性的两块短板，也是它与 MedQuAD、MedQA 等即开即用数据集最本质的区别（§6、§8）。

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

Q1：ArchEHR-QA 是挑战赛还是数据集？
两者都是。它是 BioNLP 2025 共享任务的官方数据集——任务由 ACL 生物医学 NLP 工作坊主办，参赛队提交系统在榜单上比；同时它作为独立基准数据集长期托管在 PhysioNet 上（2025 任务已结束，页面明确"M maintained as a benchmark dataset… and as an archival record of the 2025 shared task"）。名字读作 “Archer”。

Q2：它让模型做什么？
给定三样输入——患者自然语言问题、临床医生改写的规范问题、患者临床笔记节选（已逐句编号）——生成一段自然语言答案，并对答案里每个论断标注它依据的是哪几句笔记（形如 [5,10,18]）。任务核心是 grounding（证据落地）：答案不仅要相关，还要指得准。

Q3：数据从哪来？
患者问题来自公共领域的真实健康论坛消息（真实患者对自己或家人的病情追问）；笔记节选则对齐到公开可获取的真实 EHR——具体是 MIMIC-III（v1.4）与 MIMIC-IV-Note（v2.2）。场景覆盖重症监护（ICU）与急诊科（ED）。

Q4：有多少例？
PhysioNet v1.4（2026-10-05）共 167 例，分三份：dev 20 例（ID 1–20）、test 100 例（ID 21–120）、test-2026 47 例（ID 121–167）。其中 ID 1–134 对应数据论文所述，135–167 是后按同一协议新增的。

Q5：有没有训练集？
没有公开训练集。 2025 共享任务只给了 dev 20 例（带 relevance keys，供开发与验证）+ test 100 例（keys 隐藏，用于评测）。2026 的 test-2026 47 例仅向注册参与者分阶段发放。这意味着想拿它做监督训练，实际可用标注只有 20 例级别的规模（外加论文口径的 134/167 例 relevance 标注作为弱标签来源）。

Q6：标注长什么样？
最关键是句级 relevance 三标签：每句笔记标为 essential（回答该问题必须引用）、supplementary（可引用作补充支撑）、not-relevant（不应引用）。此外每例还有临床医生撰写的带引用参考答案（clinician_answer）及其逐句拆分（id/text/citations）。

Q7：怎么评分？
双轴。① Factuality（事实性）：把系统答案里引用的句号与人工标注的 essential 句比对，算 Precision/Recall/F1——分 strict（只算 essential）与 lenient（essential+supplementary）两变体。② Relevance（相关性）：把生成答案文本与参考答案/essential 句 + 问题比对，用 BLEU、ROUGE-LSum、SARI、BERTScore、AlignScore、MEDCON 六族指标。总榜分 = Factuality（strict F1）与 Relevance 组合分的平均。

Q8：2025 年谁赢了？
29 支团队参赛，共提交 75 个系统，24 支队伍提交了系统描述论文。冠军 DMISLab（Hwang et al., 2025）拿到总榜 53.7%、strict micro F1 58.6%、平均 relevance 48.8%；其后是 Neural（Bogireddy et al.）与 LAILab（Le et al.）。总分五成出头，说明任务远未解决。

Q9：基线是什么？
一个"简单但强"的零样本基线：提示 LLaMa 3.3 70B，输入患者问题 + 医生问题 + 笔记节选，并把笔记句标识符一并给出，让它自由生成带引用的答案。参赛系统在此之上用了各种架构（含"先检索最相关证据再生成"的两阶段）、专有与开放权重 LLM、微调与少样本策略。

Q10：为什么它对 AI-Ready 重要？
它是库内少见的**"共享任务型"高风险高价值样本**：一方面封装了前沿的"证据落地问答"评测框架（双轴 + 六族指标），是目前患者视角 EHR QA 的标杆设计；另一方面它的认证访问 + 无公开训练集 + 区域限制三重要求，使它成为"方法可借鉴、数据难即取"的典型——恰是 AI-Ready 光谱上偏保守的一端（§6、§9）。

§1.5 数据集设计的三条主线

回看 ArchEHR-QA 的整体设计，可以提炼出贯穿始终的三条主线，理解它们有助于在具体使用时做出正确判断。

主线一：真实优先（realism first）。 患者问题取自真实论坛，病历取自真实 MIMIC 记录，参考答案由真实临床医生撰写——数据集刻意拒绝"合成问题 + 虚构病历"的省事路线。代价是获取门槛（敏感病历须认证）与规模受限（每例都要医生工时）；回报是结果的生态效度高，能反映真实部署中的噪声与复杂度。

主线二：证据可计分（evidence as a first-class object）。 把笔记句预先编号、逐句打 relevance 标签、要求答案带句号引用——一切都是为了让"证据使用"从模糊判断变成可计算的指标。这是本数据集在方法论上最核心的贡献，也是它区别于普通问答数据集的分水岭。

主线三：评测先行（evaluation-first design）。 数据集与评测框架是同时设计的：strict/lenient 双口径、双真值来源、六族 relevance 指标，反映出作者对"单一指标会被钻空子"的清醒认识。数据集因此更像一个成熟的benchmark，而非一堆待挖掘的原始语料。

§2 数据构成与规格

2.1 规模与三划分

ArchEHR-QA 在 PhysioNet 上的 v1.4 版本共 167 例患者病例，组织为三份：

划分目录	病例数	病例 ID	用途
dev/	20	1–20	开发与验证（带 relevance keys）
test/	100	21–120	2025 共享任务测试（keys 隐藏）
test-2026/	47	121–167	2026 迭代测试（仅注册参与者）
合计	167	1–167	PhysioNet v1.4

两点必须说清：

1. 2025 共享任务实际只用了 120 例（20 dev + 100 test）——这是综述论文与 PhysioNet Task Description 双证的口径。
2. Scientific Data 数据论文口径为 134 例——v1.3（2026-01-01）发布时累计 134 例，PhysioNet Release Notes 明确"cases with IDs 1–134 correspond to those described in the accompanying Scientific Data paper"；v1.4 的 135–167 是后续新增。因此引用"134"应指数据论文，"167"应指 PhysioNet 最新。

规模口径速记：120（2025 赛）= dev 20 + test 100；134（数据论文 / v1.3）= 120 + 14；167（v1.4 最新）= 134 + 33。

2.2 每例（case）的字段结构

主数据文件 archehr-qa.xml 以 <case id="N"> 组织，每例含以下元素（据 PhysioNet 实抓格式说明）：

元素	含义	备注
clinical_specialty	该例的临床专科	多专科用竖线 `\
patient_narrative	患者叙述式完整问题	真实论坛消息风格，口语化、含个人细节
patient_question	患者问题中的关键短语 span	内含 <phrase>，带 id 与 start_char_index
clinician_question	临床医生改写的规范问题	由医生据患者叙述提炼，用于消歧
note_excerpt	作为证据的临床笔记节选	文本本体
note_excerpt_sentences	笔记节选的逐句切分	内含 <sentence>，带 id/paragraph_id/start_char_index

其中 <sentence> 的 id 是引用计分的基本单位——系统答案里的 [5,10,18] 指的就是这些句子编号；paragraph_id 标记句子所属段落，start_char_index 给出其在段落内的字符偏移。

2.3 答案键（archehr-qa_key.json）结构

答案键是一个 JSON 数组，每个对象对应一例：

字段	含义
case_id	对应 XML 中的病例 ID
clinician_answer	临床医生撰写的答案，含方括号句号引用（如 [5,10,18]）
clinician_answer_without_citations	同上但去掉引用括号（v1.4 新增）
clinician_answer_sentences	答案的逐句分解，每项含 id/text/citations（citations 为笔记句号数组）
answers	对笔记句的逐句 relevance 标注，每项含 sentence_id/relevance

answers 的 relevance 三值是评测的锚点：

• essential：回答该问题必须引用（strict 口径下计入答案集）
• supplementary：可以引用以作补充支撑（lenient 口径下计入）
• not-relevant：不应引用

2.4 数据文件与映射文件

文件	内容
archehr-qa.xml	主病例数据（患者问题、医生问题、笔记节选、句级切分、专科）
archehr-qa_key.json	答案键（医生参考答案 + 句级 relevance 标注）
archehr-qa_mapping.json	病例 ID → 源文档 ID 的映射

archehr-qa_mapping.json 的存在说明病例是可追溯回 MIMIC 源文档的——这对做血缘核对、或想结合 MIMIC 全量上下文的研究者有用，但也意味着再分发边界天然受 MIMIC 的 DUA 约束（§6）。

2.5 数据源与血缘（MIMIC 系）

ArchEHR-QA 的笔记证据并非原创采集，而是派生自两份公开可获取的真实 EHR：

父项目	版本	作用
MIMIC-III Clinical Database	v1.4	临床笔记来源之一
MIMIC-IV-Note: Deidentified free-text clinical notes	v2.2	临床笔记来源之一

PhysioNet 项目页的 Parent Projects 区明确列出这两者，并注明"Please cite them when using this project"——即使用 ArchEHR-QA 时须同时引用两个父项目。这一血缘决定了 ArchEHR-QA 的许可不可能是宽松的 CC 协议，而必然继承 MIMIC 的认证访问体系（§6）。

患者问题则来自公共领域的真实健康论坛——作者强调这是"真实患者健康信息需求"（true patient health information needs expressed in real-world health forum messages），再对齐（align）到公开 EHR。这种"论坛真实提问 + 真实病历"的组合，正是它区别于合成题或考试题数据集的关键。

§2.6 一个完整病例的解剖（以 PhysioNet 示例为蓝本）

要把 ArchEHR-QA 的设计看透，最好的办法是走一遍它的一个完整病例。以下取材自 PhysioNet 页面给出的心脏科示例（本例 ID 5）。

患者叙述（patient_narrative）：一位 48 岁的患者自述"2 月 20 日晕倒被送医，又有两次发作；有慢性肾病（肌酐约 1.5）；贫血（血红蛋白 10.3）；在 ICU 住了 8 天，出院时稳定；医生给他做了心导管检查；心肌酶没有升高，住院期间超声心动图显示左室射血分数 25%。这个有创、有风险的操作是必要的吗？"

患者问题短语 span（patient_question）：系统从中标出两个关键短语——My doctor performed a cardiac catherization.（id 0，start_char_index 254）与 Was this invasive, risky procedure necessary.（id 1，start_char_index 381）。后者即患者真正想知道的焦点问题。

临床医生改写问题（clinician_question）：Why was cardiac catheterization recommended to the patient?（为什么建议给该患者做心导管检查？）——一句话把口语化的追问钉成可回答的规范问题。

笔记节选与逐句切分：note_excerpt 给出该患者住院经过的叙述性笔记；note_excerpt_sentences 把笔记切成句，逐句配 id/paragraph_id/start_char_index。

参考答案（clinician_answer，带引用）：医生的答案是——“患者因经超声心动图确认的射血分数 25% 的加重性心衰而被建议做心导管检查 [5,18,10]。他有低输出量心衰，导致腹腔内压升高，进而引起淤血性肝病、腹痛与右上腹压痛 [11]。心导管检查显示该患者需要用米力农治疗 [19]。米力农输注通过显著改善心输出量与楔压，改善了患者的心脏泵功能 [20,13]。”

逐句 relevance 标注（answers）：在同一份笔记中，部分句子被标为 essential（如第 10 句）、部分 supplementary（如第 7 句）、部分 not-relevant（如第 1 句）。

这个病例把数据集的全部设计要素浓缩其中：

1. 真实、杂乱、带情绪的输入（“Was this invasive, risky procedure necessary.” 双问号与口语）——迫使任务必须借助医生改写问题。
2. 短语 span 标注（patient_question）——保留患者"原始焦点"的位置信息，可用于研究"焦点抽取"。
3. 句级引用的答案（[5,18,10] 等）——把每个论断都钉到证据，是多句引用（一句答案引三句证据）的典型。
4. 反向的 relevance 标注（answers 中同句即"究竟哪句该引"——既标 essential 也标 not-relevant，形成完整的正负例）。

对开发者而言，一个病例提供的数据粒度足以训练/评测四类模型：问题解释（患者问→医生问）、焦点抽取（定位 patient_question 短语）、证据识别（预测句子 relevance）、答案生成（生成带引用文本）。这正是 2026 迭代把它拆成四个子任务的现实基础。

§2.7 规模数字的工程含义

面对"120 / 134 / 167"三个数字，工程实践中最关心的问题是：我到底能拿到多少可用的标注？ 答案分层如下：

可用资源	规模	是否带 relevance 标注	获取门槛
dev 集	20 例	是（keys 公开）	认证访问
test 集（2025）	100 例	否（keys 隐藏）	认证访问
test-2026	47 例	仅参与者	注册 + 分阶段发放
数据论文口径	134 例	部分（论文分析用）	随论文/发布物

实务结论：真正"可当场用于开发"的带标注数据只有 dev 20 例；若想借用论文报告的分析，可参考 134 例口径，但那不是可直接下载的独立文件集。至于 167 例的完整 relevance keys，PhysioNet 的答案键文件（archehr-qa_key.json）是否覆盖全部 167 例需以实际文件为准——公开页面未明示 key 文件的覆盖范围，这是又一处应当在获取后核对的细节（遗留疑点）。

这一"标注量稀缺"的现实，直接决定了它的使用方式：它适合做评测基准（benchmark）与少样本/提示实验，不适合做监督训练语料。任何计划"拿它微调一个模型"的团队，都应先评估 20 例 dev 能否支撑目标——通常不能。

§2.8 为什么用 XML 而不是纯 JSON

一个工程细节值得注意：主数据用 XML（archehr-qa.xml）而非 JSON。原因推测有三：① 病例数据天然是嵌套结构（case → patient_question → phrase；note_excerpt_sentences → sentence），XML 的元素嵌套比 JSON 更直观地表达层级与属性（id/start_char_index 作为属性）；② XML 便于携带字符偏移（start_char_index）与段落归属（paragraph_id）等位置信息；③ 与临床文本处理领域既有的标注交换格式（如 brat 等基于 XML 的工具链）兼容。而答案键（key.json）是扁平数组结构，用 JSON 更自然——这就是"主数据 XML + 答案键 JSON"的由来。

对使用者的现实影响：解析 XML 需要额外一个解析器（如 Python 的 xml.etree / lxml），而 JSON 键可直接 json.load。数据集提供了 mapping 文件作为两者之间的桥梁（case_id ↔ 源文档）。

§3 任务定义与标注协议

3.1 任务形式化

ArchEHR-QA 的任务可以精确地写成一句话：给定一份临床笔记节选（逐句编号）和一个问题，生成一段自然语言答案，并在答案中引用支撑它的笔记句号。

输入三元组：

1. 患者问题（patient-posed question）——真实论坛风格的自然语言，常含大量个人细节与情绪化追问。
2. 临床医生改写问题（clinician-interpreted question）——由医生提炼的规范问题，用于消歧。例如患者写"为什么他们要做这个手术？？？“，医生版改写为"为什么给他做急诊抢救性修复？”。
3. 临床笔记节选（note excerpt）——已逐句编号、作为证据池的临床文档片段。

输出：一段自然语言答案 + 句级引用。

关键设计：笔记句预先编号，答案的引用直接指向这些编号。这样评测就能把"答案对不对"与"引用准不准"彻底解耦——前者用文本相似度度量，后者用引用命中率度量。

3.2 为什么需要"医生改写问题"

患者原话充满歧义、口语、以及与本例无关的旁枝（有时甚至夹带对家人的描述、时间线错乱）。若直接把原话喂给系统，评测会把"理解问题的失败"和"生成答案的失败"混在一起。加入医生改写问题后，任务被钉在"我知道你在问什么，请给出有据可查的答案"这一等价形式上，让证据落地成为真正的考点。2026 迭代进一步把这一环节独立为 Subtask 1（Question Interpretation），让"把患者问题解释成规范问题"本身成为可单独评测的能力。

3.3 句级 relevance 标注细则

标注的核心产物是对笔记节选逐句打上的 relevance 标签：

标签	定义	评测含义
essential	回答该问题必须引用	strict 口径下计入答案集
supplementary	可以引用以提供补充支撑	lenient 口径下计入答案集
not-relevant	不应引用	引用它会被计为误报

这三个标签直接决定了两套 Citation F1 的计分：

• strict：把 essential 句视为标准答案 → 引用 supplementary 或 not-relevant 都算错，考验精确性。
• lenient：把 essential + supplementary 视为标准答案 → 允许适度扩展引用，考验召回。

"答案文本"侧的参考真值则有两种来源（综述论文明确）：① 临床医生撰写的参考答案本人；② essential 笔记句与患者/医生问题的拼接。两种真值分别用于不同的 relevance 计算。

3.4 参考答案与引用

每例都有一份临床医生撰写的参考答案，其格式形如（示例取自 PhysioNet 页面）：

The patient was recommended a cardiac catheterization for worsening heart failure confirmed by left ventricle ejection fraction of 25% on his echocardiogram [5,18,10]. He had low output heart failure which caused increasing intra-abdominal pressure resulting in congestive hepatopathy… [11]. …

可见每个论断（句子）尾部挂着一组句号引用（citations），指向笔记中被它用到的句子。v1.4 起，答案被进一步分解为 clinician_answer_sentences（逐句 + citations 数组），使"答案句 → 证据句"的映射机器可读。这一"答案句级引用"结构是本数据集对"可解释问答"最直接的贡献。

3.5 标注者与质量保证（公开可考部分）

• 数据由专家手工标注（“expert-annotated dataset”，Abstract 原文）。
• 组织团队成员全部完成所需培训且是 MIMIC-III/IV 认证用户（Ethics 段），确保接触真实病历合规。
• 测试集存在双标注与对账机制：综述论文提到 Codabench 自动分数"not final… after reconciliation of double annotations"——即榜上初分会在双标注对账后被重算（Table 5 即为修订后的分数，且显示个别系统排名有实质变化）。
• 未公开的标注细节：标注者数量、标注者专业背景、句级 relevance 的标注者间一致性（IAA/kappa）等在公开页面未给出——这是本条目的遗留疑点（§7）。

§3.6 从数据到模型：四类可训练任务

虽然本数据集没有公开训练集，但它的标注结构天然支持四类任务（也是 2026 四子任务的现实映射）：

任务	输入	输出	数据依据
问题解释	patient_narrative	clinician_question	患者问→医生问的对照
焦点抽取	patient_narrative	patient_question 短语 span	<phrase> 的 start_char_index
证据识别	问题 + note_excerpt_sentences	逐句 relevance 标签	answers 字段
答案生成	问题 + 笔记	带引用答案文本	clinician_answer + citations

这四层是递进的：先把患者的话解释清楚，再从证据池里挑出该用的句子，最后组织成连贯答案并标注引用。2025 的端到端任务要求系统一次性完成全部四层，这正是它难度高（冠军 53.7%）的原因之一；2026 把它们拆开，让研究能定位"到底是哪一层拖了后腿"。

§3.7 标注工作流的推测性还原

虽然公开页面未披露完整标注 SOP，但从数据结构可反推其工作流大致如下（此为基于产出物的合理推断，非官方声明）：

1. 选例：从 MIMIC-III/IV 中挑选适合展示"患者信息需求"的 ICU/急诊病例，截取相关临床笔记节选。
2. 对齐患者问题：把论坛真实患者问题与所选病例对齐，确保该病例的笔记确实能回答这个问题。
3. 医生改写：临床医生把患者原话改写为规范问题（clinician_question）。
4. 句级切分：把笔记节选切成句，逐句编号（id/paragraph_id/start_char_index）。
5. relevance 标注：逐句判定 essential/supplementary/not-relevant。
6. 参考答案撰写：医生撰写带句级引用的答案。
7. 双标注与对账：对测试集做双标注，对账后确定最终 keys（综述论文提及此机制）。
8. 专项标专科：为每例标注 clinical_specialty（v1.3 起）。

这条流水线的关键角色是临床医生：改写问题、判定 relevance、撰写参考答案三步都需要医学判断，无法外包给非专业人员。这也是本数据集规模难以快速膨胀的根本原因——每例的成本都含医生工时。

§4 共享任务的演进：2025 → 2026

4.1 2025 首办（BioNLP @ ACL 2025）

• 定位：单任务——生成证据落地的患者问题答案。
• 组织：随第 24 届 BioNLP 工作坊（第 63 届 ACL 年会）举办，工作坊日期 2025-08-01。
• 数据：用 ArchEHR-QA 的 120 例子集（dev 20 + test 100）。
• 提交平台：Codabench（竞赛 5302）。
• 结果综述：2025 综述论文（pages 396–405）。
• 参赛：29 队、75 系统、24 篇系统描述。

4.2 2026 迭代（CL4Health @ LREC 2026）

2026 迭代（“ArchEHR-QA 2026”）把任务拆为四个互补子任务，并采用分阶段数据发布：

子任务	名称	考的什么
Subtask 1	Question Interpretation	把患者问题解释为规范问题
Subtask 2	Evidence Identification	从笔记中识别相关证据句
Subtask 3	Answer Generation	生成答案
Subtask 4	Evidence Alignment	答案与证据的对齐

时间线（官网实抓）：首次征集与开发集 2026-01-02；Subtask 1 测试集 2026-01-20、提交截止 2026-01-27；Subtasks 2–3 测试集 2026-01-30、提交截止 2026-02-16；Subtask 4 测试集 2026-02-16、提交截止 2026-03-02（延至 03-04）；系统论文 2026-03-13；录用通知 2026-03-24；CL4Health 工作坊 2026-05-12。各子任务有独立 Codabench 竞赛页（13526/13527/13528 等）。

演进的含义：2025 把"证据识别+答案生成"合成一个端到端任务；2026 把它流水线化，让每个环节可独立评测。这与"可解释医疗 AI 应当把推理链显式化"的趋势同向——拆开子任务，等于承认"哪一步出错"比"总分多少"更重要。

4.3 从"比赛"到"档案"

值得注意的是 PhysioNet 页面本身的定位说明：2025 迭代已结束、不再接收参赛或提交，“本 PhysioNet 仓库作为患者-EHR 证据落地问答的基准数据集、以及 2025 共享任务的存档记录维护”。也就是说，挑战赛的生命周期是短的（约半年），但数据集的使命是长期的——这正是一个合格"竞赛型数据集"应有的双重身份。

§4.4 任务的学术定位：它填的是哪个空

综述论文对齐了几条相邻研究线，用于定位 ArchEHR-QA 的空白：

研究线	面向谁	是否用患者本人病历	是否评测证据使用
通用健康问答	消费者/患者	否	否
临床医生 EHR 问答	医生	是	否
自动回复患者消息（不含 EHR）	患者	否	否
用 EHR 回复患者消息（少数）	患者	是	否
ArchEHR-QA	患者	是	是

综述论文的核心论点：即便在少数"使用患者记录"的研究里，也没有一项评估了生成答复究竟如何有效地利用这些证据。ArchEHR-QA 的价值，正是在"患者 + 病历 + 证据使用评测"三者的交叉点上，从 0 到 1 地补上了缺口。作者原文称其为"据我们所知，首个封装了患者提问与来自 EHR 的相关临床证据的公开数据集"。

这一"填空"定位可以解释任务的若干设计选择：为什么要医生改写问题（把消费者侧的噪声隔离）、为什么要句级 relevance（把"证据使用"变成可计分对象）、为什么要 strict/lenient 两口径（承认"该引多少"本身有争议）。

§4.5 数据治理与伦理

ArchEHR-QA 在伦理上有两处设计值得记录：

1. 患者问题来自公共领域：使用的是公开发布在健康论坛的患者消息（“posted to public health forums”），而非抓取私人通信——这降低了直接采集患者私人数据的伦理负担。
2. 病历侧走正规认证：笔记证据派生自已被广泛接受为去标识化标准的 MIMIC-III/IV，且组织团队自身须为"完成培训 + 认证用户"，确保接触真实病历合规。

两者的组合——“公开问题 + 认证病历”——是数据合规上一种务实的设计：它承认患者问题可以是公开的，但病历证据必须受控。这一拆分也为其他研究者提供模板：若你的数据涉及敏感内容，能否把"敏感部分"与"公开部分"分开治理？

不过，它并未消除所有伦理问题：即便患者问题原本公开，将其与具体病历对齐后重新发布，是否构成对原始发帖人的再识别风险，公共页面未展开讨论——这是一个值得使用者自行评估的开放议题。

§4.6 2026 四子任务的再解读

2026 迭代把任务拆成四步，每一拆都有明确的问题指向：

• Subtask 1 问题解释：把"患者问了什么"变成可评测对象。拆它的理由：2025 端到端任务里，"没听懂问题"和"答不好"混在一起，无法定位失败源头。
• Subtask 2 证据识别：把"该引哪几句"独立出来。这是与 strict/lenient 口径最直接对应的子任务——本质是句级 relevance 分类/排序。
• Subtask 3 答案生成：在（可能给定的）证据基础上生成连贯文本。拆它的理由：把"写作质量"从"证据选择"中解耦。
• Subtask 4 证据对齐：检验生成答案的引用是否与证据一致。这是 factuality 的显式化，也是四步中最贴近"可追溯性"目标的一环。

四子任务的组合，等于把 2025 的一个黑箱拆成一条可诊断的流水线：哪一步错了，就能单独拿出来改进。这对系统开发者比对总分更有价值——你可以只参赛自己擅长的环节，也可用子任务诊断端到端系统的瓶颈所在。

§5 评估框架与基准结果

5.1 双轴评价体系

ArchEHR-QA 的评估设计可概括为"引用了对证据没有 + 答案切不切题"两问：

① Factuality（事实性）——用生成答案引用的句号与人工标注证据集比对，计算 micro 级 Precision/Recall/F1：

• strict 变体：标准答案 = 仅 essential 句。
• lenient 变体：标准答案 = essential + supplementary 句。

② Relevance（相关性）——把生成答案文本与参考真值比对，用六族文本/语义指标：

类别	指标
n-gram 重叠	BLEU、ROUGE-LSum
可读性/简化	SARI
语义相似	BERTScore、AlignScore
医学内容保真	MEDCON

③ Overall（总分） = Factuality（strict Citation F1）与 Relevance（各归一化分的组合）的平均。

这套"引用命中 + 文本相关"的双轴结构，是本数据集方法论上最值得迁移的部分：它把"幻觉"（引用了不存在的证据）与"平淡"（答案没错但不切题）分开惩罚。

5.2 2025 基准结果（Table 4 / Table 5）

综述论文报告29 队、75 系统的结果。榜首表现（preliminary 答案键口径，Table 4）：

名次	团队	Overall	strict micro F1	平均 relevance
1	DMISLab（Hwang et al., 2025）	53.7%	58.6%	48.8%
2	Neural（Bogireddy et al., 2025）	紧随其后	—	—
3	LAILab（Le et al., 2025）	紧随其后	—	—

读法警示：冠军总分仅 53.7%、strict F1 58.6%——意味着一半以上的引用在严格口径下不正确或缺失。这直观说明"证据落地问答"远未解决。

排名会变：Table 5 用修订后的 relevance keys + 临床医生参考答案重算后，总分范围"相对稳定"，但个别系统的排名发生实质变化。这提示：在双标注对账完成前，榜上名次不宜当定论（也是本库记录竞赛结果时的通用谨慎）。

5.3 基线系统

官方基线是一个零样本方案：提示 LLaMa 3.3 70B（Grattafiori et al., 2024），输入患者问题 + 医生问题 + 笔记节选，并把笔记句标识符一并提供，让其直接生成带引用的答案。作者称其"simple yet strong"——即在不做任何证据检索预处理的情况下，大模型已能提供一个不弱的起点。

5.4 参赛系统的技术图景

综述论文归纳的参赛方法谱系：

• 架构：含"先选最相关证据、再生成答案"的两阶段（检索-生成）方案，以及端到端直接生成方案。
• 模型：专有 LLM（闭源 API 类）与开放权重 LLM 并用。
• 调优：**微调（fine-tuning）与少样本（few-shot）**等各种策略。

这套图景本身有参考价值：面对"要引用证据"的任务，一个自然的工程直觉（先检索后生成）确实被相当多队伍采用——这与开放域 RAG（检索增强生成）的思路同源，但目标从"检索到相关文档"升级为"引用到正确句子"。

§5.5 从"能作答"到"有据可查"：为什么双轴评估重要

医疗场景对 AI 有一条不同于其他领域的硬要求：可追溯性（traceability）。当受众缺乏医学知识（患者正是如此）时，给出一个正确答案但无法说明依据，和给错答案的后果可能同样严重——因为患者无从判断该不该相信。综述论文明确把"grounding 在医学中尤其关键"归因于此。

ArchEHR-QA 的双轴评估正是为了惩罚两类不同的失败：

• 幻觉型失败（Factuality 低）：答案语气笃定，却引用了不支撑它的证据句，或引用了不存在的句号。strict 口径下，这类失败会被 Citation F1 直接抓住。
• 平庸型失败（Relevance 低）：答案引用可能不算错，但文本空洞、答非所问，没真正回应患者关切。六族 relevance 指标会惩罚这类输出。

把两者分开计分、再取平均，传递的政策信号是清晰的：光有据不行，光切题也不行。这正是"证据落地问答"比"开放域问答"更难的地方——模型要同时在两个轴上达标，而 2025 年的最好系统也只有 53.7% 的总分。

§5.6 结果解读的三个提醒

引用 2025 结果时，有三点容易被忽略：

1. 53.7% 是"总分"，不是"正确率"。它是 Factuality（strict F1）与 Relevance 组合分的平均，本身混合了"引用命中"与"文本相关"两个不同性质的分量，不宜直接读成"答对了一半"。
2. strict F1 58.6% 是"引用层面"的分数。它衡量的是系统引用的句号与标注 essential 句的重合度，而非答案的医学正确性。一个引用命中率高的答案，其医学内容仍可能不妥（评测不校验医学事实的正确性，只校验"是否引用了标注为相关的句子"）。
3. preliminary vs 修订。Table 4 用初步答案键，Table 5 用修订答案键，后者导致个别系统排名变化。转引名次时务必注明口径。

§5.7 为什么冠军只有 53.7%：任务难点的三层拆解

一个自然的疑问是：LLM 已经能写流畅答案，为何冠军总分才 53.7%？答案藏在任务的三个叠加难点里。

难点一：证据句的标注本身有主观性。 "该不该引某句"并非总有唯一答案——essential 与 supplementary 的边界依赖临床判断。strict 口径下只有 essential 算对，等于要求系统与标注者对"必引句"达成高度一致，而人本身未必一致（双标注对账的存在即为此）。

难点二：引用需要跨句推理。 患者问"这个手术有没有必要"，答案证据可能散落在笔记的多处（如本例 [5,18,10] 三句），系统必须同时找全并正确组合，漏一句就掉 Recall，多引一句就掉 Precision。

难点三：答案既要引用对又要写得像。 Relevance 轴用六族指标衡量文本质量，意味着答案不仅要"引对句"，还要组织成与临床医生风格相近的连贯文本——两个目标有时互相拉扯（过度堆砌引用会损害流畅度）。

三层叠加的结果，就是 58.6% 的 strict F1 与 53.7% 的总分——这既是一个难以逾越的基线，也是后续研究（含 2026 四子任务）要攻的方向。

§6 获取与许可：认证访问的门怎么进

6.1 三层获取路径

资产	获取方式	门槛
数据本体（XML/JSON）	PhysioNet 项目页下载	认证访问：注册 + CITI 培训 + 签 DUA
评测脚本	GitHub（soni-sarvesh/archehr-qa 的 /evaluation）	开源，直接取用
2026 测试数据	仅向注册参与者分阶段发放	报名 + 分阶段授权

6.2 许可与 DUA 全貌

• 数据许可：PhysioNet Credentialed Health Data License 1.5.0
• 数据使用协议：PhysioNet Credentialed Health Data Use Agreement 1.5.0
• 必需培训：CITI “Data or Specimens Only Research” 课程
• 访问级别：Credentialed Access（认证访问）——PhysioNet 原文：“Only credentialed users who sign the DUA can access the files.”

这套体系继承自 MIMIC（ArchEHR-QA 的父项目），意味着没有公开直链、没有宽松再分发条款。想用的团队必须先走完 PhysioNet 的认证流程。

6.3 血缘引用的连带义务

由于数据派生自 MIMIC-III v1.4 与 MIMIC-IV-Note v2.2，使用时须同时引用两个父项目（PhysioNet Parent Projects 区原文）。这意味着学术使用该数据集时的引用清单至少是三条：综述论文（任务）+ Scientific Data 论文（数据）+ MIMIC 父项目。

6.4 DOI 与版本

标识	值
Discovery DOI（v1.4）	10.13026/sneb-dn55
DOI（latest）	10.13026/zzax-sy62
RRID	SCR_007345（PhysioNet 平台）
数据论文 DOI	10.1038/s41597-026-06639-z
综述论文 DOI	10.18653/v1/2025.bionlp-1.34

6.5 区域限制（重要存照）

抓取时点 PhysioNet 页面 Files 区提示：“Data is not available in your region due to legal or policy restrictions.” 即数据文件的可下载性受区域法律/政策限制——这不是数据集下架，而是 PhysioNet 针对 MIMIC 系数据的地理合规机制。对 AI-Ready 评估的含义：即便完成认证，实际可获取性仍可能受所在地域影响。

6.6 版本链（获取的历史快照）

版本	日期	变化
v1.0	2025-02-26	发布开发集 20 例
v1.1	2025-02-28	移除多余问题
v1.2	2025-04-11	发布测试集 100 例；dev 索引改为从 1 起
v1.3	2026-01-01	累计 134 例；加 clinical_specialty + 带引用答案
v1.4	2026-10-05	累计 167 例；加去引用答案文本 + 答案句级分解

这张版本链本身就是"共享任务型数据集如何演进"的活教材：开发集先发（v1.0）→ 补测（v1.2）→ 赛后扩充与结构化（v1.3/v1.4）。

§6.7 认证访问的实际影响（数据工程视角）

对数据工程团队而言，ArchEHR-QA 的"认证访问"不是一个可以忽略的细节，而会改变项目的工序安排：

1. 前置合规工作：需要为团队成员完成 CITI 培训（每人数小时）、签署机构级 DUA。这在传统"下载即可用"的数据集上是不存在的步骤。
2. 交付延迟：培训与签署需要数天到数周，项目排期须预留。
3. 再分发禁止：DUA 意味着完成认证的机构不能把数据转给未认证的合作方——多机构协作时每方都要独立走流程。
4. 区域不确定性：即便完成认证，PhysioNet 仍可能因区域法律/政策拦截下载（抓取时点即被拦）。
5. 血缘引用义务：使用后须同时引用 MIMIC 父项目，学术产出时引用清单更长。

这些成本换来的是数据合规性：患者病历是敏感数据，认证访问确保每一份下载都能追溯到责任主体。对研究者而言，这是一份"合法但麻烦"的数据——理解这一点，才能正确评估它在自己项目中的可用性。

§6.8 许可合规操作清单

若决定使用 ArchEHR-QA，以下合规步骤应按序完成（据 PhysioNet 要求整理）：

步骤	动作	责任方
1	注册 PhysioNet 账号	每位用户
2	完成 CITI “Data or Specimens Only Research” 培训	每位用户
3	签署 PhysioNet Credentialed Health Data Use Agreement 1.5.0	用户/机构
4	确认所在区域可下载（区域限制核查）	用户
5	下载 XML + JSON 文件	认证用户
6	使用后核对引用：综述论文 + 数据论文 + MIMIC-III/IV	用户
7	再分发前确认 DUA 边界（通常禁止转给未认证方）	用户/机构

任何一步缺失，都可能导致合规风险。特别是第 3 步（DUA）与第 7 步（再分发），是研究者最容易忽略的两处——DUA 是机构级承诺，再分发限制则直接影响多机构协作的可行性。

§7 避坑清单：八个已踩过的坑

坑 1：规模数字有三个，"120/134/167"别混用。 2025 共享任务用 120 例（dev 20 + test 100）；Scientific Data 数据论文口径 134 例；PhysioNet v1.4 最新 167 例。它们不是矛盾而是版本差。引用时必须先声明口径——写"该数据集有 167 例"时不要忘了 2025 比赛只用了一半多。

坑 2：这不是"有训练集"的常规数据集。 它没有公开训练集；dev 只有 20 例（带 keys），test 100 例 keys 隐藏，test-2026 仅限参与者。把它当监督训练集的团队会发现标注量仅 20 例级别。想做监督学习，得自寻增强或弱标签路径。

坑 3：认证访问 ≠ 免费下载。 数据受 PhysioNet Credentialed Health Data License 1.5.0 约束，须注册 + CITI 培训 + 签 DUA，且部分区域因法律/政策无法下载。别把它和 MedQuAD、MedQA 那类即开即用的数据集并列描述为"公开可下"。

坑 4：许可靠血缘继承，非独立宽松协议。 ArchEHR-QA 派生自 MIMIC-III/IV，因此不可能给出 CC BY 之类的宽松许可；使用时须同时引用 MIMIC 父项目。只引 ArchEHR-QA 会违反父项目的引用要求。

坑 5：“患者数"不等于"病例数”。 167 是病例（case）数，PhysioNet 未披露唯一患者总数——多例可能来自同一患者。任何"该数据集覆盖 167 位患者"的表述都是错的。

坑 6：榜上分数会因双标注对账而变。 Codabench 自动分"not final"，Table 5 重算后个别系统排名有实质变化。引用 2025 名次时须注明是哪个口径（preliminary vs 修订后），别把初榜当定论。

坑 7：会议地点拼写。 ACL Anthology 综述论文页写 “Viena, Austria”（疑为 Vienna 的笔误）；工作坊实际随 ACL 2025 在奥地利维也纳举办。转引时按标准拼写 Vienna，并知悉原文的拼写出入。

坑 8：把它当"通用医学问答"会错。 ArchEHR-QA 考的是基于给定笔记的证据落地，不是开放域知识问答。它的输入里已经给了证据池，模型的任务是选中并引用正确句子，而非检索外部知识。与 MedQA（考试选择）、MedQuAD（消费者知识问答）是不同赛道。

§7.5 术语陷阱补充

除正文 §7 的八个坑外，还有几处术语容易误用：

• “grounded”≠“factual”。Grounding 指"答案锚定在给定证据"，factual 指"内容与事实相符"。一个答案可以 grounded（正确引用了笔记句）却不 factual（该笔记句本身对患者病情描述有误）——评测只测前者。
• "relevance"是句子级、非答案级。数据集里的 relevance 标签是给笔记句打的（这句该不该引），不是给答案打的。
• “dev”≠“训练集”。dev 20 例虽带 keys，但设计目的是开发验证，规模远不足以训练；把它当训练集会导致严重过拟合。
• “test-2026”≠新任务。它是同一任务下后续新增的测试例（ID 121–167），不是另一套任务。

§7.6 关于"共享任务数据集"这一类型的说明

ArchEHR-QA 属于一类特殊的发布物：共享任务数据集（shared task dataset）。这类数据集有几个共性，值得单列以帮助读者跨条目套用：

1. 生命周期分层：赛期（活跃，配榜单与排行榜）→ 赛后（归档，转为长期基准）。ArchEHR-QA 正是如此。
2. 数据发布分期：dev 先发、test 后发、可能追加（本项目 v1.0→v1.4 的版本链即典型）。
3. keys 隐藏：测试集标注不公开，防止系统直接读取答案。
4. 配套论文双份：任务综述论文（结果分析）+ 数据论文（数据描述）。
5. 多子任务演进：首办往往单任务，后续迭代拆分子任务以细化评测。
6. 平台中介：依赖 Codabench 等平台提交与计分。

理解这六条共性，就能在面对任何"某某 Challenge 202X"数据集时，快速判断它的规模口径（赛用 vs 发布）、获取方式（认证 vs 公开）、以及该引哪篇论文。

§8 与库内条目的关系

8.1 家族图谱

• MIMIC-IV-Note（rid 47）：直接父项目——ArchEHR-QA 的临床笔记证据来源之一（v2.2）。两篇同读才能理解笔记文本的原始形态与去标识化约束。
• MIMIC-III（rid 590）/ MIMIC-IV（rid 592）/ mimic-iv-clinical-database（rid 4）：另外的父项目与同族资源。ArchEHR-QA 的 archehr-qa_mapping.json 可追溯回这些源文档。
• emrQA（rid 139）：最直接的方法论近亲。emrQA 是抽取式（给定问题从病历中抽取答案 span），ArchEHR-QA 是生成式 + 必须引用——两者合看正好覆盖 EHR 问答的两代范式。
• EHRXQA（rid 646）/ EHRSQL（rid 713）：EHR 问答与 Text-to-SQL 基准。EHRXQA 面向表格+文本混合的临床问答，与 ArchEHR-QA 的自由文本笔记问答形成互补。
• EHRSHOT（rid 11）：纵向 EHR 基础模型少样本评估——与本条目同属"NLM/学术机构主导的临床 NLP 基准"谱系。
• MedQuAD（rid 160）/ MedicationQA（rid 170）/ HealthSearchQA（rid 492）：患者视角问答的同族。三者均面向消费者/患者，但数据多为知识库或搜索问题，不以患者本人病历为证据——这正是 ArchEHR-QA 的独特性所在。
• MedQA（rid 50）/ MedMCQA（rid 111）/ HeadQA（rid 120）：医学考试问答，与 ArchEHR-QA 的"真实患者+真实病历"形成鲜明对照。
• MIMIC-Ext-CXR-QBA（rid 926）：胸片视觉问答的"问题-框-答案"数据集——同为"医学问答+引用/定位"结构，可作多模态对照。
• MEDIQA（rid 220）/ PriMock57（rid 811）：医患对话/问诊语料——相关的临床沟通 NLP 资源。
• MTSamples（rid 350）：医学转录文本——临床文本语料的通用参照。

8.2 检索路径建议

• 检索词组合：“ArchEHR-QA” + “grounded question answering” + “EHR”；或用读音 “Archer” 配合 “BioNLP 2025”。
• 若目标是直接可用数据：先确认能否通过 PhysioNet 认证（CITI + DUA）；否则退而研究其方法（评测脚本 GitHub 开源）。
• 若目标是引用患者 EHR 问答标杆：引综述论文 Table 4（DMISLab 53.7%）说明任务难度，并注明双标注对账会改排名（坑 6）。

§8.3 与"开放即用"数据集的结构性差异

把 ArchEHR-QA 与本库内的开放问答数据集逐维对照，可以清晰看出"共享任务型敏感数据"的独特性：

维度	ArchEHR-QA	MedQuAD(160)	MedQA(50)	emrQA(139)
面向对象	患者（真实病历）	消费者	考试	医生（病历抽取）
证据要求	必须句级引用	无	无	抽取 span
访问	认证访问	公开	公开	认证访问
训练集	无（20 例 dev）	有	有	有
病历依赖	是（MIMIC）	否	否	是
评测框架	双轴（Factuality+Relevance）	答案匹配	准确率	span F1

这张表最值得注意的一行是"训练集"：ArchEHR-QA 与 MedQuAD/MedQA 的分野不在于数据质量，而在于它的定位是评测基准而非训练语料。20 例带标注的 dev 集只够做开发验证，不足以支撑监督训练——这是选择它时最容易踩的预期落差。

§8.4 检索与使用实操建议

给打算实际使用 ArchEHR-QA 的团队几条落地建议：

1. 先确认资质：项目启动前就发起 PhysioNet 认证（CITI 培训 + DUA），避免因合规流程阻塞进度。
2. 优先用 dev 例做原型：20 例带标注足以上手评测框架、跑通评测脚本。
3. 直接复用评测脚本：GitHub 上的 /evaluation 开源，无需自造 Citation F1 与 relevance 指标实现。
4. 对齐 MIMIC 上下文：若需笔记全文，用 archehr-qa_mapping.json 追溯源文档，在 MIMIC 中取用。
5. 引用齐三条：综述论文 + 数据论文 + MIMIC 父项目。
6. 注意区域限制：若所在区域被拦，需提前准备替代方案（如通过合作机构获取）。

§9 AI-Ready 定位与可迁移价值

9.1 在 AI-Ready 光谱上的位置

把 ArchEHR-QA 放到本库的 AI-Ready 坐标系里，它是一份**“方法高度就绪、数据获取受限”**的样本：

• 就绪的一面：任务定义清晰、评测框架完整（双轴 + 六族指标）、评测脚本开源、参考答案与句级标注结构化（XML/JSON）、数据论文与综述论文齐备——研究价值与可复现性设计属上乘。
• 受限的一面：认证访问 + 无公开训练集 + 区域限制三重门槛，使它无法被"即下即用"；再分发边界受 MIMIC DUA 约束。

这使它成为与 MedQuAD、MedQA 等"开放即用"数据集的镜像案例：能拿来做方法对标与评测设计参考，难以拿来做大规模训练。

9.2 可迁移的三条经验

1. 双轴评测范式：把"引用准确"（Factuality）与"文本相关"（Relevance）分开计分，是对抗幻觉的通用设计——任何"生成 + 引用"系统都可借鉴。
2. 患者视角的评测设计："医生改写问题"的引入，把"理解问题"与"生成答案"解耦，是处理真实用户噪声输入的可复制手法。
3. 竞赛型数据集的双生命周期：挑战赛（短周期）+ 长期基准档案（PhysioNet 托管），是学术数据集影响最大化的成熟路径。

9.3 适合谁 / 不适合谁

适合：证据落地/引用生成研究者、临床问答系统开发者、想对标患者视角 EHR QA 的团队、共享任务参赛者、评测框架设计者。

不适合：需要大规模公开训练集的监督学习项目、需要宽松许可再分发的商业场景、把"公开可下"当硬需求的数据工程团队。

§9.4 对评测框架设计的启示

ArchEHR-QA 最可能被长期引用的是它的评测框架，而非数据本身。三条可迁移的设计原则：

1. 把"引用"与"内容"分轴。任何依赖证据的生成系统（RAG、摘要、报告生成）都应至少报告两类分数：证据命中（factuality）与输出质量（relevance）。只报告后者，会漏掉幻觉这一最大风险。
2. 同一真值给两套口径。strict/lenient 承认"该引多少证据"存在合理的宽严尺度，让排行榜既奖励精确也可能奖励覆盖——比单一阈值更公平。
3. 真值文本双源。用"人工参考答案"与"证据句拼接"两种真值分别计算 relevance，降低对单一真值写法的敏感度。

这三条对任何"生成 + 引用"任务都具有普适参考价值，也是 ArchEHR-QA 即便数据难以获取、仍值得收录的理由。

§10 总结

10.1 三句话总结

1. ArchEHR-QA 是首个公开的"患者提问 + 其 EHR 相关临床证据"数据集，以句级 relevance 标注与带引用参考答案，把"证据落地"变成可精确评测的目标。
2. 它是 BioNLP 2025 共享任务（29 队 / 75 系统）的官方数据，冠军 DMISLab 总分仅 53.7%，说明患者视角的证据落地问答远未解决；2026 迭代拆为四个子任务继续推进。
3. 其 AI-Ready 属性呈"方法就绪、数据受限"：评测框架与脚本可自由复用，但数据本体受认证访问 + 无公开训练集 + 区域限制约束。

10.2 30 秒决策卡

你的情况	行动
想研究证据落地评测框架	直接读 §5 + GitHub 评测脚本（开源）
想要可用训练数据	先确认能过 PhysioNet 认证；否则改用 dev 20 例做小样本/提示实验
要引用患者 EHR QA 标杆	引综述论文 Table 4（DMISLab 53.7%）+ 注明口径与版本（坑 1/6）
要做监督微调	注意无公开训练集（坑 2），需自建弱标签或增强方案
要写数据集综述	§2 结构表 + §8 家族图谱 + §5 评测体系可直接引用
要引用本条目	三条引用齐备：综述论文 + 数据论文 + MIMIC 父项目（坑 4）

§10.3 一页纸速记

对时间紧迫的读者，ArchEHR-QA 的全部要点可压缩为一页：

• 是什么：患者提问-EHR 证据落地问答数据集 + BioNLP 2025 共享任务（“Archer”）。
• 谁做的：NLM/NIH，Sarvesh Soni、Dina Demner-Fushman。
• 多大规模：v1.4 共 167 例（dev 20 + test 100 + test-2026 47）；2025 赛用 120 例。
• 数据源：公共论坛患者提问 + MIMIC-III/IV 笔记。
• 任务：生成带句级引用的答案，句标 essential/supplementary/not-relevant。
• 评测：Factuality（引用 F1，strict/lenient）+ Relevance（六族指标），取平均。
• 2025 战果：29 队 75 系统，冠军 DMISLab 53.7%。
• 怎么拿：PhysioNet 认证访问（无公开训练集）。
• 许可：PhysioNet Credentialed License 1.5.0 + DUA。
• 坑：规模三口径、无训练集、认证访问、血缘引用、区域限制。

DAIMS 评估（数据资产在 AI 就绪度上的多维打分）

维度	评分	说明
D — Discoverability 可发现性	高	PhysioNet 项目页 + 官网 + ACL Anthology + 双 DOI + RRID，检索入口齐全
A — Accessibility 可获取性	低	认证访问（CITI + DUA）+ 区域限制；无公开直接下载
I — Interoperability 互操作性	中高	XML/JSON 结构化发布，含 mapping 文件可追溯源文档；但格式为自定义 schema，非 FHIR 等标准
M — Metadata 元数据完备度	高	数据论文 + 综述论文 + PhysioNet 详尽格式说明 + 逐版本 Release Notes
S — Sustainability 可持续性	高	PhysioNet 长期托管（RRID）+ NLM/NIH 机构背书 + 版本链清晰（v1.0→v1.4）
综合	中	元数据与方法维度就绪度高，数据可获取性维度显著拉低总分——典型"方法>数据"就绪型资产

FAQ（高频问答 30 问）

A. 基础认知

Q1：ArchEHR-QA 是什么？
一个患者提问-电子健康记录证据落地的问答数据集，也是 BioNLP 2025（ACL）共享任务的官方数据。名字读作 “Archer”。

Q2：它是挑战赛吗？
既是挑战赛数据也是长期基准。2025 共享任务已结束（约半年赛程），PhysioNet 仓库作为基准数据集与赛事存档长期维护。

Q3：全称是什么？
ArchEHR-QA: A Dataset for Addressing Patient’s Information Needs related to Clinical Course of Hospitalization（面向患者住院经过信息需求的数据集）。

Q4：谁做的？
美国国立医学图书馆（NLM，隶属 NIH）院内研究部。主要作者 Sarvesh Soni、Dina Demner-Fushman（综述论文另有 Soumya Gayen）。

Q5：发表在哪里？
数据论文在 Scientific Data（2026, 13:523）；共享任务综述论文在 BioNLP 2025 会议论文集（pages 396–405，ACL Anthology 2025.bionlp-1.34）。

Q6：什么时候办的？
2025 迭代随 ACL 2025 的 BioNLP 工作坊，工作坊日期 2025-08-01。2026 迭代随 CL4Health @ LREC 2026，工作坊 2026-05-12。

B. 数据

Q7：有多少例？
三个口径：2025 共享任务用 120 例；数据论文口径 134 例；PhysioNet v1.4 最新 167 例。

Q8：167 例怎么分？
dev 20 例（ID 1–20，带 keys）+ test 100 例（ID 21–120）+ test-2026 47 例（ID 121–167）。

Q9：有训练集吗？
没有公开训练集。 dev 仅 20 例带标注，test 100 例 keys 隐藏。

Q10：数据从哪来？
患者问题来自公共健康论坛真实消息；笔记证据派生自 MIMIC-III v1.4 与 MIMIC-IV-Note v2.2。

Q11：什么临床场景？
ICU（重症监护）与急诊科（ED）。

Q12：文件格式？
XML（archehr-qa.xml 主数据）+ JSON（archehr-qa_key.json 答案键、archehr-qa_mapping.json 映射）。

Q13：覆盖多少患者？
未披露唯一患者数——167 是病例数，不是患者数（坑 5）。

C. 任务与标注

Q14：任务要模型做什么？
生成带句级引用的自然语言答案，证据落地于给定笔记的句子。

Q15：输入有哪几样？
患者问题 + 临床医生改写问题 + 笔记节选（逐句编号）。

Q16：为什么要医生改写问题？
患者原话歧义多，改写问题消除歧义，让评测聚焦"证据落地"而非"理解噪声"。

Q17：句级 relevance 有几个标签？
三个：essential（必须引用）/ supplementary（可补充引用）/ not-relevant（不应引用）。

Q18：参考答案长什么样？
临床医生撰写的答案，每句尾部挂一组笔记句号引用（如 [5,10,18]）。v1.4 起还有答案句级分解（id/text/citations）。

Q19：标注细节公开吗？
标注者数量、背景、句级 IAA/kappa 未公开——遗留疑点（坑 2 相关）。

Q20：测试集是单标注还是双标注？
综述论文提到双标注与对账机制（初分 not final），但具体协议未详述。

D. 评估

Q21：怎么评分？
双轴：Factuality（引用 P/R/F1，strict/lenient）+ Relevance（BLEU/ROUGE-LSum/SARI/BERTScore/AlignScore/MEDCON）。总榜分 = 二者平均。

Q22：strict 和 lenient 差别？
strict 只把 essential 当答案集；lenient 把 essential + supplementary 都算。

Q23：基线是什么？
零样本提示 LLaMa 3.3 70B（输入问题 + 笔记 + 句号标识符）。

Q24：2025 谁赢了？
DMISLab：Overall 53.7%、strict micro F1 58.6%、平均 relevance 48.8%。

Q25：多少队参加？
29 队，共 75 系统，24 队提交系统描述。

Q26：分数会变吗？
会——Table 5 用修订 keys 重算后，个别系统排名有实质变化（坑 6）。

E. 获取与许可

Q27：怎么获取数据？
PhysioNet 认证访问：注册 + CITI “Data or Specimens Only Research” 培训 + 签署 DUA。

Q28：许可是什么？
PhysioNet Credentialed Health Data License 1.5.0 + DUA 1.5.0。

Q29：有区域限制吗？
有——PhysioNet 提示部分区域因法律/政策无法下载（坑 3）。

Q30：引用要引几条？
至少三条：综述论文（任务）+ Scientific Data 论文（数据）+ MIMIC 父项目（血缘，坑 4）。

事实清单（硬事实 34 条）

1. 官方全称：ArchEHR-QA: A Dataset for Addressing Patient’s Information Needs related to Clinical Course of Hospitalization
2. 官方读音：“Archer”（官方页面明确）
3. 发布机构：NLM 院内研究部（Division of Intramural Research, NLM, NIH）
4. 作者：Sarvesh Soni、Dina Demner-Fushman（PhysioNet 页面 2 人）
5. 综述论文作者：Sarvesh Soni、Soumya Gayen、Dina Demner-Fushman（3 人）
6. PhysioNet v1.4 发布日：2026-10-05
7. PhysioNet v1.4 规模：167 例
8. 三划分：dev 20（1–20）+ test 100（21–120）+ test-2026 47（121–167）
9. 2025 共享任务用 120 例（20 dev + 100 test）
10. 数据论文口径 134 例（ID 1–134）
11. 数据源：MIMIC-III v1.4 + MIMIC-IV-Note v2.2
12. 临床场景：ICU + 急诊科
13. 患者问题来源：公共健康论坛真实消息
14. 文件格式：XML + 两份 JSON（key + mapping）
15. 句级 relevance 三标签：essential / supplementary / not-relevant
16. 引用格式：[句号,句号]（如 [5,10,18]）
17. 综述论文 Anthology ID：2025.bionlp-1.34
18. 综述论文页码：396–405
19. 综述论文 DOI：10.18653/v1/2025.bionlp-1.34
20. 数据论文：Scientific Data 13, 523（doi 10.1038/s41597-026-06639-z）
21. PhysioNet DOI（v1.4）：10.13026/sneb-dn55
22. PhysioNet DOI（latest）：10.13026/zzax-sy62
23. RRID：SCR_007345
24. 参赛规模：29 队 / 75 系统 / 24 篇系统描述
25. 冠军：DMISLab（Hwang et al., 2025）Overall 53.7%
26. 冠军 strict micro F1：58.6%
27. 冠军平均 relevance：48.8%
28. 亚军/季军：Neural（Bogireddy et al.）、LAILab（Le et al.）
29. 基线：LLaMa 3.3 70B 零样本
30. 许可：PhysioNet Credentialed Health Data License 1.5.0 + DUA 1.5.0
31. 必需培训：CITI Data or Specimens Only Research
32. 访问级别：Credentialed Access（认证访问）
33. 版本链：v1.0(2025-02-26) → v1.1(2025-02-28) → v1.2(2025-04-11) → v1.3(2026-01-01) → v1.4(2026-10-05)
34. 2026 迭代：CL4Health @ LREC 2026，拆四子任务

FAQ 续（Q31–Q42：进阶）

Q31：grounding 和 factuality 是一回事吗？
不是。grounding 指答案是否锚定在给定证据；factuality 在 ArchEHR-QA 里特指引用命中证据的程度。二者相关但不等价（见 §7.5）。

Q32：评测会检查答案的医学正确性吗？
不会直接检查。它检查引用是否命中标注句 + 文本是否与参考相似；医学事实的正确性不由榜单校验。

Q33：为什么 dev 只有 20 例？
设计如此。dev 的目的是开发验证而非训练，规模小是共享任务的常态（也正因此，官方不提供"训练集"）。

Q34：可以把它当训练集用吗？
不建议。20 例 dev 带标注，规模不足以训练；test 100 例 keys 隐藏。硬训会过拟合。

Q35：2026 新增的 47 例（121–167）怎么获取？
仅向 2026 共享任务注册参与者分阶段发放；PhysioNet v1.4 已收录但受认证访问约束。

Q36：为什么笔记证据来自 MIMIC 而不是自采？
因为需要"公开可获取的真实 EHR"。MIMIC 是公认的去标识化重症/急诊数据，复用它既合规又可追溯（mapping 文件）。

Q37：患者是 ICU/急诊病人，那门诊问答适用吗？
数据场景限于 ICU 与急诊科，门诊场景的适用性未验证——迁移时须重新评估。

Q38：句号引用 [5,10,18] 是升序还是乱序？
示例中既有升序（[5,18,10] 实为乱序呈现），说明计分不依赖顺序，只做集合匹配。

Q39：strict 与 lenient 哪个更常用作总榜？
总分用 strict Citation F1（综述论文明确 Overall = Factuality(strict) 与 Relevance 的均值）。

Q40：评测脚本能单独用吗？
能。GitHub（soni-sarvesh/archehr-qa 的 /evaluation）开源源码，可对自建系统打分。

Q41：该数据集和 MIMIC-CXR 那类影像数据集什么关系？
同族不同模态。MIMIC-CXR 是影像+报告，ArchEHR-QA 是纯文本笔记问答；共同上游是 MIMIC 血统与认证访问体系。

Q42：我要引用它做综述，最少引哪几篇？
综述论文（任务）+ Scientific Data 论文（数据）+ MIMIC-III/IV 父项目（血缘），三条齐备。

FAQ 续二（Q43–Q52：实操）

Q43：评测脚本怎么跑？
从 GitHub soni-sarvesh/archehr-qa 的 /evaluation 取源码，按 README 准备预测文件（带引用的答案），运行即可得 Citation F1 与 relevance 指标。

Q44：我的系统只输出答案不输出引用，能参赛吗？
2025 任务要求答案带句级引用，无引用则 Factuality 轴无法计分；建议至少输出引用。

Q45：essential 句一定只有几句？
不一定，视病例而定；本例参考答案引了三句（[5,18,10]），也有引一句的。

Q46：可以只用 patient_narrative 不用 clinician_question 吗？
技术上可以，但官方任务与基线都同时提供两者；去掉改写问题会显著增加难度（等价于 2026 的 Subtask 1 要自己解决）。

Q47：笔记节选有多长？
公开页面未给统一长度；示例显示可达十余句。总字符数受 MIMIC 笔记片段截取影响（遗留疑点）。

Q48：clinical_specialty 有多少种取值？
公开页面未给出专科枚举与分布（遗留疑点）。

Q49：能用于商业产品吗？
须严格依 DUA 审查；认证访问 + MIMIC 血缘使其商业使用受限，务必先确认条款。

Q50：和 2026 的 Subtask 数据是同一批吗？
test-2026（ID 121–167）是 2026 迭代的新增测试例，与 2025 的 1–120 不同批次。

Q51：如何复现 2025 榜首？
参考 DMISLab 的系统描述论文（Hwang et al., 2025），按综述论文方法谱系检索。

Q52：如果我拿不到数据怎么办？
可用评测脚本对自建系统自测，并借鉴双轴框架；数据本体需走认证；极端情况下以综述论文报告的对标结果作为参照。

术语表（28 条）

术语	中文	释义
ArchEHR-QA	患者EHR问答数据集	本条目主体，“Archer”
grounded QA	证据落地问答	答案须引用支撑证据的问答形式
grounding	证据落地	把生成内容锚定到具体证据句
EHR	电子健康记录	Electronic Health Record
patient portal	患者门户	患者在线与医疗机构通信的入口
patient narrative	患者叙述	患者自述的完整问题文本
patient question	患者问题	患者问题中的关键短语 span
clinician question	临床医生改写问题	医生据患者叙述提炼的规范问题
note excerpt	笔记节选	作为证据的临床文档片段
clinical notes	临床笔记	临床自由文本记录
relevance	相关性	笔记句对回答问题的重要性
essential	必须引用	relevance 标签：回答必须引用
supplementary	可补充引用	relevance 标签：可作补充支撑
not-relevant	不相关	relevance 标签：不应引用
citation	引用	答案指向笔记句号的标注
factuality	事实性	引用命中证据的度量
BLEU	—	n-gram 重叠机器翻译指标
ROUGE-LSum	—	摘要召回重叠指标
SARI	—	文本简化指标
BERTScore	—	基于 BERT 的语义相似指标
AlignScore	—	事实一致性对齐指标
MEDCON	—	医学内容保真指标
MIMIC-III	—	经典重症监护公开数据库
MIMIC-IV-Note	—	MIMIC-IV 去标识化临床笔记
PhysioNet	—	生物医学数据共享平台 (MIT)
Credentialed Access	认证访问	需培训+DUA 的访问级别
DUA	数据使用协议	Data Use Agreement
shared task	共享任务	学术会议附设的竞赛式任务

附录

附录 A：文件清单

文件	格式	内容
archehr-qa.xml	XML	主病例数据
archehr-qa_key.json	JSON	答案键（参考答案 + relevance 标注）
archehr-qa_mapping.json	JSON	病例 ID → 源文档 ID 映射

附录 B：XML 病例结构骨架

<annotations>
  <case id="5">
    <clinical_specialty>cardiology</clinical_specialty>
    <patient_narrative> ... 患者叙述 ... </patient_narrative>
    <patient_question>
      <phrase id="0" start_char_index="254"> ... </phrase>
      <phrase id="1" start_char_index="381"> ... </phrase>
    </patient_question>
    <clinician_question> ... 医生改写问题 ... </clinician_question>
    <note_excerpt> ... 笔记节选 ... </note_excerpt>
    <note_excerpt_sentences>
      <sentence id="1" paragraph_id="1" start_char_index="0"> ... </sentence>
      <sentence id="2" paragraph_id="2" start_char_index="0"> ... </sentence>
    </note_excerpt_sentences>
  </case>
</annotations>

附录 C：答案键 JSON 结构骨架

[
  {
    "case_id": "4",
    "clinician_answer": "... [5,18,10] ...",
    "clinician_answer_without_citations": "...",
    "clinician_answer_sentences": [
      {"id":"1","text":"...","citations":["5","10","18"]}
    ],
    "answers": [
      {"sentence_id":"1","relevance":"not-relevant"},
      {"sentence_id":"7","relevance":"supplementary"},
      {"sentence_id":"10","relevance":"essential"}
    ]
  }
]

附录 D：评估指标速查

轴	指标	说明
Factuality	Citation Precision/Recall/F1	strict（仅 essential）/ lenient（+supplementary）
Relevance	BLEU / ROUGE-LSum / SARI	n-gram 与简化
Relevance	BERTScore / AlignScore	语义与事实一致性
Relevance	MEDCON	医学内容保真
Overall	均值	Factuality(strict F1) 与 Relevance 组合的平均

附录 E：2025 时间线

事件	日期
首发征集	2025-01-24
开发集发布	2025-02-26
测试集发布	2025-04-11
系统提交截止	2025-04-28（原 04-25）
系统论文截止	2025-05-09（原 05-02）
工作坊	2025-08-01

附录 F：2026 时间线

事件	日期
首发征集 / 开发集	2026-01-02
Subtask 1 测试集	2026-01-20
Subtasks 2–3 测试集	2026-01-30
Subtask 4 测试集	2026-02-16
工作坊	2026-05-12

附录 G：2025 冠亚季军

名次	团队	Overall
1	DMISLab（Hwang et al., 2025）	53.7%
2	Neural（Bogireddy et al., 2025）	—
3	LAILab（Le et al., 2025）	—

附录 H：溯源来源清单

1. PhysioNet 项目页：https://physionet.org/content/archehr-qa-bionlp-task-2025/
2. 共享任务官网（2026）：https://archehr-qa.github.io
3. 2025 任务页：https://archehr-qa.github.io/2025/
4. 综述论文：https://aclanthology.org/2025.bionlp-1.34/
5. Codabench 2025 竞赛：https://www.codabench.org/competitions/5302/

附录 I：指标定义速览

指标	计算对象	直观含义
Citation Precision（strict）	系统引用的句中命中的essential比例	引用"准不准"
Citation Recall（strict）	应引essential句中被引到的比例	引用"全不全"
Citation F1（strict）	P/R 调和均值	引用综合质量
Citation F1（lenient）	用 essential+supplementary 重算	宽口径引用质量
BLEU	生成文本 vs 参考	n-gram 精确度
ROUGE-LSum	生成文本 vs 参考	最长公共子序列召回
SARI	生成 vs 参考	增删改的合理性
BERTScore	生成 vs 参考	语义相似度
AlignScore	生成 vs 参考	事实一致性
MEDCON	生成 vs 参考	医学内容保真
Overall	Factuality(strict F1) 与 Relevance 组合	总榜分

附录 J：双口径对照总表

项目	口径 A	口径 B	采信
规模	120（2025 共享任务）	167（PhysioNet v1.4）	两者并存，按语境注明
规模	134（数据论文/v1.3）	167（v1.4）	引用数据论文用 134
作者数	2（PhysioNet 数据页）	3（综述论文，+Gayen）	按对象区分
会议地点	“Viena, Austria”（Anthology 原文）	Vienna（标准拼写）	用 Vienna，注原文笔误
用例数（赛）	120（赛事）	167（发布物）	按"比赛/数据集"区分

附录 K：扩展阅读线索

• 想复现榜单：Codabench 2025 竞赛页 5302 存档。
• 想做方法比对：综述论文 Table 4/5 的 29 队方法谱系。
• 想接入系统：GitHub soni-sarvesh/archehr-qa 评测脚本。
• 想追踪 2026：CL4Health @ LREC 2026 工作坊 + 四子任务 Codabench 页。
• 想理解上游：MIMIC-III v1.4 + MIMIC-IV-Note v2.2 两个父项目。

附录 L：常见误区速查表

误区	事实
“它是个有训练集的问答数据集”	无公开训练集，dev 仅 20 例带标注
“公开可免费下载”	认证访问（CITI + DUA），部分区域受限
“167 例就是 167 位患者”	167 是病例数，患者总数未披露
“评测会检查医学正确性”	只检查引用命中 + 文本相关
“grounding 就是 factual”	grounding 指锚定证据，与事实正确性不同
“2025 比赛用了全部 167 例”	2025 只用 120 例
“只引 ArchEHR-QA 一篇即可”	须加引 MIMIC 父项目
“榜上名次是终局”	双标注对账后排名会变
“它和 MedQuAD/MedQA 同类”	它面向患者真实病历+强制引用，赛道不同

附录 M：结构化字段速查

字段	所属文件	类型	说明
case id	XML	属性	病例 ID（1–167）
clinical_specialty	XML	元素	临床专科，`\
patient_narrative	XML	元素	患者叙述式问题
patient_question/phrase	XML	元素	患者问题短语 span
clinician_question	XML	元素	医生改写问题
note_excerpt	XML	元素	笔记节选
note_excerpt_sentences/sentence	XML	元素	逐句切分
case_id	key.json	字段	对应 XML 病例
clinician_answer	key.json	字段	带引用答案
clinician_answer_without_citations	key.json	字段	去引用答案（v1.4）
clinician_answer_sentences	key.json	字段	答案句级分解（v1.4）
answers	key.json	字段	逐句 relevance 标注

附录 N：与相邻任务的选型对照

你的需求	推荐
评测"生成+引用"系统	ArchEHR-QA（双轴框架）
训练 EHR 抽取式问答	emrQA(139)
训练消费者知识问答	MedQuAD(160)
医学知识考试评测	MedQA(50)/MedMCQA(111)
医患对话摘要	MEDIQA(220)
患者视角药物问答	MedicationQA(170)
纵向 EHR 基础模型少样本评测	EHRSHOT(11)
胸片视觉问答	MIMIC-Ext-CXR-QBA(926)

附录 O：版本-规模-内容对照表

版本	日期	累计例数	新增内容
v1.0	2025-02-26	20	开发集首发
v1.1	2025-02-28	20	移除多余问题
v1.2	2025-04-11	120	测试集 100 例；索引从 1 起
v1.3	2026-01-01	134	clinical_specialty + 带引用答案
v1.4	2026-10-05	167	去引用答案 + 答案句级分解

附录 P：2025 参赛方法谱系速览

维度	选项
架构	两阶段（先检索证据再生成）/ 端到端直接生成
模型	专有 LLM / 开放权重 LLM
调优	微调 / 少样本提示
基线	LLaMa 3.3 70B 零样本
提交	Codabench，每队最多 3 次

附录 Q：入门三步

1. 读框架：综述论文（2025.bionlp-1.34）——理解任务与双轴评估。
2. 读数据：PhysioNet 项目页——理解 XML/JSON 结构（本文 §3、附录 B/C）。
3. 跑脚本：GitHub /evaluation——用 dev 20 例跑通计分流程。

附录 R：给不同角色的行动建议

如果你是研究生（找题目）：ArchEHR-QA 的四个子任务各自都能撑起一篇小论文；双轴评估框架的低分现状（冠军 53.7%）说明大量改进空间，重点可放在"证据识别"（Subtask 2）与"答案-证据对齐"（Subtask 4）这两个显式可评测的环节。

如果你是临床信息学团队（想落地）：先想清楚"患者门户消息自动起草"的实际工作流——ArchEHR-QA 提供的是评测参照，不是可直接部署的模型。用法是：用它的双轴框架衡量你自建系统的引用命中率与文本质量，再按医疗机构的合规要求（认证访问 + 审计）设计数据管线。

如果你是 NLP 工程师（找 baseline）：LLaMa 3.3 70B 零样本是官方基线，可作为起点；在此之上加"先检索证据再生成"的两阶段结构是 2025 参赛队的主流选择，值得优先尝试。

如果你是数据治理岗（做评估）：ArchEHR-QA 是研究"敏感医疗数据如何在合规前提下开放评测"的良好案例——患者问题公开、病历受控、评测脚本开源的三分治理结构可作模板。

附录 S：一句话结论集

• 一句话定位：ArchEHR-QA 是首个患者视角、强制证据引用的 EHR 问答共享任务数据集。
• 一句话难度：2025 年 29 队竞逐，最好系统总分 53.7%，证据落地问答远未解决。
• 一句话价值：它的双轴评估框架（Factuality + Relevance）比数据本身更具可迁移性。
• 一句话限制：认证访问 + 无公开训练集 + 区域限制，使它"方法可借、数据难取"。
• 一句话引用：引用它要引三条——综述论文、数据论文、MIMIC 父项目。

附录 T：全文数据来源一览（可核验链接）

事实类别	来源
数据集名称、规模、版本链、许可	PhysioNet 项目页
任务定义、评估指标、子任务	共享任务官网（2025 / 2026）
参赛队数、系统数、冠军分数、方法谱系	BioNLP 2025 综述论文
数据论文出处（Scientific Data 13:523）	PhysioNet 引用说明
MIMIC 血缘（v1.4 / v2.2）	PhysioNet Parent Projects
提交平台与竞赛号	Codabench

所有链接均以抓取时点 2026-10-09 可访问为准；若链接失效，以 FACTS.md §10 的 URL 清单为回溯依据。

尾注

• 本条目所有硬数字均以 PhysioNet 项目页、BioNLP 2025 综述论文、官方任务网站三源互证为准，抓取时点 2026-10-09。
• 规模、作者数、会议地点的双口径差异已在 §2、§7 与 FACTS.md §9 逐条存照。
• 未取得的关键信息（患者总数、标注者一致性统计、专科分布、文件字节数、2026 迭代最终结果）列为遗留疑点，不作推测。
• 数据论文（Scientific Data）全文因网络预算限制未直抓，其内部标注细节待后续核对；本条目以可直接验证的三源证据为准。

---

相关数据集导航

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

• ehr-notes-qa-llms — 共享标签：医学问答与基准 / 电子健康记录 / 医疗NLP / 临床电子病历 / 医学问答
• emrqa — 共享标签：电子健康记录 / 医疗NLP / 临床电子病历 / 医学问答
• cliniq — 共享标签：医学问答与基准 / 电子健康记录 / 医疗NLP / 临床电子病历
• medagentbench — 共享标签：医学问答与基准 / 电子健康记录 / 医疗NLP / 临床电子病历
• medsynth — 共享标签：医学问答与基准 / 电子健康记录 / 医疗NLP / 医学问答
• bioasq — 共享标签：医学问答与基准 / 医疗NLP / 医学问答
• medquad — 共享标签：医学问答与基准 / 医疗NLP / 医学问答
• ehrsql — 共享标签：电子健康记录 / 医疗NLP / 临床电子病历 / 医学问答
• ehr-reasoncon — 共享标签：医学问答与基准 / 电子健康记录 / 医疗NLP / 临床电子病历
• bedside-bench — 共享标签：医学问答与基准 / 电子健康记录 / 医疗NLP / 医学问答

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