MIMIC-III-Ext-MIMIC-Patient — 500 例逐患者 JSON 临床问答语料

INFOBOX — MIMIC-Patient（mimic-patient-json）一屏速览

一句话定性：这不是"更大的 MIMIC"，而是"更像医生的 MIMIC"——它把关系表折叠成病人的一段人生，再用关键词路由把这段人生切成可以被逐句提问的碎片。读这个条目时，请始终同时记住两个数字：500（规模）与 4.40%（它占母库的比例），前者决定它能做什么，后者决定它不能做什么。

维度	内容
本质	MIMIC-III 的逐住院 JSON 派生集（ext 扩展包，非新采集），配一个病人模拟脚本
官方名	MIMIC-III-Ext-MIMIC-Patient: Structured Per-Patient JSON Records for Clinical Question Answering
团队	宾夕法尼亚大学（Penn），Shang Tianqi 等 6 人；配套论文为 DynamiCare 多智能体框架
平台	PhysioNet，v1.0.0 发布于 2026-09-11；RRID SCR_007345
母库	MIMIC-III v1.4：58,976 次住院 / 4 万+ 患者 / 2001-2012 / BIDMC
漏斗	58,976 → 四条件筛出 2,597 → 无放回随机抽 500 → 500 个 JSON 文件
单文件粒度	一次住院 = 一个 JSON（含人口学、诊断、处方、生命体征、化验、报告、出院小结）
附带工具	answer_agent.py：关键词路由 + LLM 合成的两段式患者模拟器
获取	Credentialed Access：PhysioNet 账号 + CITI 培训 + 签署 DUA，与 MIMIC 本体同一套门
许可	PhysioNet Credentialed Health Data License 1.5.0
DOI	v1.0.0 = 10.13026/bzzd-w075；最新版 = 10.13026/n19w-aw59（brief 给的 rees-1092 有误，见坑 1）
体量	页面未披露总字节数（Files 区因地区限制显示不可用）
库内互链	MIMIC-III Legacy（590）、MIMIC-III（106）、AIPatient（550）、MedAgentBench（1064）、emrQA（139）

上表"库内互链"一栏只列最直接的五个，完整互链网见 §11.2 与附录 I；这两处对同一批条目给出了不同的角度（前者按关系远近、后者按家族归属），读者按需取用，不必两处都记。

MIMIC-Patient 是把一座重症监护数据仓库"折叠成一个个病人"的产物：MIMIC-III 原本是 26 张互相用外键勾连的关系表，研究者要花几天写 SQL 才能拼出一个病人的完整病程；这份扩展包把 58,976 次住院筛到 2,597 次，再随机取 500 次，每一次住院压成一个 JSON 文件，字段名直接用人能读懂、LLM 也能读懂的层级（Patient.Admission_info、Diagnoses、Prescription、Physical Exam），并附带一个 answer_agent.py，让医生智能体可以像问病人一样问它。它的价值不在于"更多数据"，而在于把数据结构这件事一次性做完，把研究者的注意力从 JOIN 挪到问诊逻辑上。

导语读法三则：

1. 只想知道这是什么：读 §1 十问十答与 INFOBOX 即可，其余章节是给复现者和评审者的。
2. 准备真的去用：直奔 §5 字段结构、§6 获取许可，再做 §9 的十条上手检查——认证门、字段漂移、外部 API 合规三件事最容易翻车。
3. 评估 LLM 智能体：读 §8 的任务与指标，再对照 §13 的局限清单，别把 500 例子集当成 MIMIC-III 的代表样本。

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

0.1 三个层次的问题

第一层是工程问题。MIMIC-III 的原始形态对 LLM 极不友好：一次住院的信息散落在 PATIENTS、ADMISSIONS、ICUSTAYS、DIAGNOSES_ICD、PRESCRIPTIONS、CHARTEVENTS、LABEVENTS、NOTEEVENTS 等表里，CHARTEVENTS 单表就有数亿行，任何"把这个病人的情况讲给我听"的需求都要先过一遍查询优化。把一次住院序列化成一个 JSON，等于把查询成本从"运行时"前移到"发布时"，使用者只付传输和解析的成本。

第二层是任务问题。临床诊断的真实形态是信息不对称下的多轮问询：医生不知道病人有什么病，只能一问一答地收集病史、查体、化验，逐步收敛假设。而当时主流 LLM 医疗基准（MedQA、PubMedQA 之类）是"题目-选项"式单轮问答，病例信息一次性给全——这恰好抹掉了诊断中最难的部分。要让模型学会"问"，就得有一个会回答、但只回答被问到的内容的病人模拟器。这就是 answer_agent.py 的定位。

第三层是评测问题。有了模拟病人，就可以把"多轮问诊 → 提出鉴别诊断清单"变成一个可量化的任务：以住院时的真实诊断为目标，看模型在第几轮、以多高的命中率把正确诊断排进候选。DynamiCare 论文正是用这份数据搭起了这套评测，并宣称是"首个面向 LLM 智能体的动态临床决策基准"。

0.2 它不是什么

这份数据集不是新的患者群体。所有人都是 MIMIC-III 里已经存在的人，patient_id 就是 MIMIC-III 的 SUBJECT_ID，admission_id 就是 HADM_ID。它不是完整 MIMIC-III 的替代品——500 例只占 58,976 次住院的 0.85%，而且是刻意挑过的"简单病例"。它也不是影像数据集：心电图、超声、影像只以文字报告形式出现，原始波形与 DICOM 均不在包内（需要波形请走 MIMIC-III Waveform 系列，见 §11 互链）。

0.3 与前作的关系

MIMIC 生态里此前已有若干"派生视图"：MIMIC-III Clinical Database Demo（100 例完全公开）、MIMIC-III Clinical Database（需认证的完整版）、MIMIC-IV（2008-2022 的新一代结构）。MIMIC-Patient 的位置很特殊——它比 Demo 大 5 倍且同样是真实病历，但获取门槛与完整版相同（认证访问），因此它既不能当 Demo 用，也不能当完整库用，它是一个"中等规模、结构最友好、门槛不降"的中间态。理解这一点，才能避免在选型阶段误判。

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

Q1：这份数据集到底发布在哪、什么时候？
PhysioNet，条目路径 physionet.org/content/mimic-iii-ext-mimic-patient/1.0.0，v1.0.0 初始版发布于 2026-09-11。平台登记的 RRID 是 SCR_007345（PhysioNet 通用资源标识），DOI 为 10.13026/bzzd-w075。

Q2：500 这个数字是怎么来的？
MIMIC-III v1.4 共有 58,976 次住院。作者按下述四个条件过滤后剩下 2,597 次住院，再无放回随机抽取 500 次，每次住院序列化为一个 JSON。注意筛选与抽样是两步：2,597 是"合格池"，500 是"抽样结果"，两者都以住院（admission）为单位，不是以患者为单位。

Q3：四个筛选条件是什么？
其一，该次住院的诊断记录少于 5 条——降低共病复杂度，让诊断推理的评判目标不至于发散；其二，非新生儿住院——新生儿病房的临床路径与成人心肺监护差别太大；其三，患者在住院期间存活——死亡病例的病程常被中断，记录完整性差；其四，结构化数据完整且至少含一份出院小结——保证问答时有东西可查。

Q4：一个 JSON 里有什么？
按 PhysioNet 页面披露，聚合了：入院信息（patient_id、admission_id、admission_diagnosis）、人口学、ICD-9 诊断、处方、操作、床旁生命体征（Chart Data）、化验（Lab Data），以及半结构的 ECG/超声/影像报告与出院小结抽取出的 Chief Complaint、Major Surgical or Invasive Procedure、Physical Exam（含 VS、General、HEENT、Neck、Cardiac、Lungs、Abdomen、Extremities、Skin、Pulses）、Allergies、Introduction 等字段。

Q5：answer_agent.py 是干什么的？
病人模拟器。给定一个问题，它先用正则分词提取关键词，查预置的"关键词 → JSON 章节"映射表，把相关章节的内容取出来交给 LLM，以病人第一人称语气回答；若关键词命中失败或检索内容为空，则回退为把整份 JSON 交给 LLM 直接推理。

Q6：为什么不用 RAG 向量检索？
论文没有给出解释，但从设计看，作者的诉求是可控与低成本：关键词路由是确定性的，能明确告诉你"这句回答来自哪个章节"，便于人工评估真伪；而向量检索在多字段的小型结构化 JSON 上容易召回无关段落。这是工程取舍，不是技术优越性（局限见 §10）。补一句更实用的判断：这类"章节边界清晰、字段语义固定"的数据，检索的目标其实是定位字段而不是理解语义，字典路由的精确率通常不低于嵌入检索，代价主要在召回；当问题口语化程度高、或需要跨章节拼接时，向量检索才有明显优势。

Q6b：为什么路由机制决定了评测的上限？
因为医生智能体能拿到的信息完全由路由决定，而路由的词典是人工维护的、覆盖面有限，一旦问题措辞偏离词典，系统就退回全量上下文，等于把"信息受控"的前提作废。换言之，Hit@K 的高低同时受三个因素影响：模型的推理能力、问题措辞与词典的匹配度、兜底路径是否被触发。只报告最终分数而不报告这三者的分解，读者无法判断性能瓶颈在哪一层，这也是后续复现研究最值得补的一块内容。Q7：获取门槛和 MIMIC-III 一样吗？
一样。Database Credentialed Access：PhysioNet 账号、CITI「Data or Specimens Only Research」培训证书、签署 PhysioNet Credentialed Health Data Use Agreement 1.5.0。门槛不会因为只有 500 例而降低。

Q8：能直接拿来做训练集吗？
可以，但要注意：500 例对训练来说偏小，更适合做评测集或提示工程/智能体架构的验证集；作者本人的用法也是评测（DynamiCare 用它跑 Hit@K 与人工评估）。若要训练，需自行考虑与 MIMIC-III 其他划分的去重。

Q9：和 MIMIC-IV 的关系？
无直接关系。MIMIC-Patient 明确基于 MIMIC-III v1.4（2001-2012，BIDMC），不含 MIMIC-IV 的 2008-2022 扩展期与新版 hosp/icu 模块结构。

Q10：有没有公开样例可以不等审批就看？
PhysioNet 页面的 Files 区在未登录/受限地区显示 “Data Not Available”，因此没有公开直链样例。若只想"看看长什么样"，可参考 GitHub 仓库 THEGREATICE/DynamiCare 的 README 与代码（代码公开，但数据不在仓库内），或使用 MIMIC-III Demo 的 100 例自行按相同 schema 拼接，作为开发期替身。

§2 命名、身份与来源链条

2.1 三个名字，一个东西

这份数据集在三个地方有三个名字，检索时极易走散：

出现位置	名称	用途
PhysioNet 条目	MIMIC-III-Ext-MIMIC-Patient: Structured Per-Patient JSON Records for Clinical Question Answering	正式引用名，ext 表示"扩展包"
DynamiCare 论文正文	MIMIC-Patient	论文内简称，指同一份数据
本库 slug	mimic-patient-json	检索与互链标识，强调"逐患者 JSON"这一形态

ext 前缀是 PhysioNet 上 MIMIC 衍生系列的通用约定：mimic-iii-ext-* 与 mimic-iv-ext-* 均表示"基于 MIMIC 原始库加工出来的派生数据集"，与 mimic-iii-clinical-database-*（本体）区分。库内同名家族还有 ppg（928）、synnotes（1002）、cxr 系列（616/617/926/927）等。

2.2 来源链条：从 BIDMC 到 Penn 到 PhysioNet

链路可以拆成四段。采集段：Beth Israel Deaconess Medical Center 在 2001-2012 年间的 ICU 电子病历，经 MIMIC-III 团队去标识化后形成 v1.4 版本，托管于 PhysioNet，凭 DUA 获取。筛选段：Penn 团队在获得 DUA 授权的前提下，从 ADMISSIONS、DIAGNOSES_ICD、NOTEEVENTS 等表出发执行四条件筛选，得到 2,597 例。加工段：对 500 例抽样逐例解析原始表、正则切分报告、调用 GPT-4 抽取出院小结，落成 JSON。发布段：作者把 500 个 JSON 与脚本作为"扩展包"回传 PhysioNet，独立条目、独立 DOI，但沿用母库的访问控制。

这条链有一个值得注意的治理含义：派生数据集没有降低原始数据的敏感等级。即便字段已经重新组织，内容仍然是受 DUA 约束的患者数据，因此不能因为"只有 500 例"或"已经结构化"就放松合规要求。这也是 why 该条目在 PhysioNet 上仍标 Credentialed Access 而非 Open Access 的根本原因。

另外，这一段的"来源链条"本身就是一个可复用的模板：任何基于受限母库的派生集，都可以用同样的四段式描述（谁采集、谁筛选、谁加工、谁发布），并在每一段标注访问控制是否继承。读者若在其他条目上看到结构相似的段落，不必怀疑是套模板——这正是互链体系的价值：同族数据的结构描述保持一致，才能让检索者横向比较。

另一个容易被忽略的治理细节是"派生者"的责任边界。作者在加工阶段接触的是完整 MIMIC-III（凭 DUA 授权），而使用者接触的是其派生子集；两者签署的 DUA 条款相同，但风险面不同：作者需要保证抽取过程不外泄（例如调用外部 LLM 时的零留存），使用者需要保证自己的使用场景不外泄。链条上任何一环违规，都会追溯到这个条目本身，这也是 PhysioNet 对派生集同样坚持认证访问的现实理由。

2.3 与"Demo 版"的关键差异

MIMIC-III Clinical Database Demo 是 100 例完全公开的样本，任何人下载即用，无需 DUA。MIMIC-Patient 常被误认为"大号 Demo"，实际上两者在治理层面完全不同，而且这种误认会直接导致合规事故——把 MIMIC-Patient 的数据当作公开数据贴进博客或 GitHub，是最常见的违规形式之一：

维度	MIMIC-III Demo	MIMIC-Patient
规模	100 例	500 例
访问	Open Access，直链下载	Credentialed Access，需 CITI + DUA
形态	26 张 CSV 关系表	逐住院 JSON
抽样	随机 100 例患者	四条件筛选后随机 500 次住院
用途	教学、代码联调	评测、智能体研究

因此"先用 Demo 把管线跑通，再申请正式版"是标准动线，而 MIMIC-Patient 只能放在正式版那一侧。

还要提醒一个细节：Demo 与正式版的 SUBJECT_ID 可能在部分病例上重叠（Demo 就是从正式库抽出的），但不要用 Demo 里的病例去推测正式版的结构——两者表结构相同、内容范围不同，JSON 派生版又在此基础上再组织了一层，三者结构互不相同。若团队同时使用三份数据，建议在数据字典里明确标注每份数据的来源与粒度，避免在代码里混用。

§3 数据规模：一串必须记牢的数字

3.1 主链条

58,976 → 2,597 → 500 → 1（每次住院一个文件）。

• 58,976：MIMIC-III v1.4 的住院（hospital admission）总数，对应 ADMISSIONS 表行数口径。
• 40,000+：MIMIC-III 的患者数口径，同一次住院可能属于同一患者的不同入院，因此患者数小于住院数。
• 2,597：四条件过滤后的合格住院数，约占全库 4.4%。
• 500：随机抽取结果，约占全库 0.85%，占合格池 19.3%。
• 1：每次住院对应一个 JSON 文件，文件名如 100173.json。

3.2 这些数字的解读陷阱

第一个陷阱是把 500 当患者数。PhysioNet 与论文都写"500 次入院（admission）"，若同一患者有多次合格入院且都被抽中，患者数会略小于 500。做患者级统计时应先去重 patient_id。

第二个陷阱是把 2,597 当"清洗后全集"。2,597 只是四条件筛选的结果，不含任何"人工复核"环节；是否存在患者级去重、是否剔除了某些异常科室，页面未说明。把它当作"可用样本池"没问题，当作"质量已审"则过头。

第三个陷阱是用 500 例反推 MIMIC-III 分布。抽样前先按"诊断少于 5 条 + 存活 + 数据完整"筛过，这是典型的选择偏倚：轻症、单一主诊断、病程完整的病例被系统性保留，重症多器官衰竭、院内死亡病例被系统性排除。任何"ICU 死亡率""共病负担"类统计在 500 例上都不可信。

数字读法上还有一个细节：2,597 这个数在 PhysioNet 页面与论文中被表述为"符合筛选条件的住院数"，而 500 是"随机抽取的住院数"，两者都不等于"患者数"。如果研究单位是患者而不是住院，需要在使用前按 patient_id 去重，去重后的实际患者数一定小于 500，且无法从公开页面直接查到——这是一个需要在获批数据上自行统计的指标，也应在论文中如实报告。

还有一处容易被忽略的读法：“随机抽取"不等于"等概率抽取每一类疾病”。抽取是简单随机，但前提池本身已被截断，等概率只作用于剩下的病例，对被截断的病种而言概率为零。若你的研究目标是"评估模型在多病共存场景的表现"，那么无论抽多少例，这份数据都提供不了样本——这不是样本量能解决的问题。

补充一个更具体的情形：由于"住院期间存活"是硬条件，这份数据集里 HOSPITAL_EXPIRE_FLAG 恒为 0，任何以死亡为结局的建模任务（院内死亡预测、临终决策分析）在这份数据上都是结构性不可做的，不是样本量问题而是标签全为负类的问题。同理，"非新生儿"意味着儿科 ICU 的部分特殊路径缺失，若研究目标包含极低出生体重儿，这份数据同样不适用。使用前把筛选条件逐条对照自己的研究问题，比事后发现标签不可用要省事得多。

3.3 体量与实际存储

PhysioNet 页面未给出总字节数（Files 区在抓取时因地区限制显示不可用），这是本条目的一处信息缺口。可按经验估算量级：单次住院的 CHARTEVENTS 片段与化验数据通常几百 KB 到数 MB 文本，加上出院小结数 KB，500 例整体大概率在百 MB 量级，而不是 GB 量级。实际值以获批后下载的目录清单为准，勿引用估算值作引用数据。

3.4 时间跨度与中心

时间覆盖 2001-2012，全部来自 BIDMC 单一中心（波士顿，哈佛医学院附属教学医院）。这意味着：ICD-9 而非 ICD-10 编码体系（美国 2015 年才切到 ICD-10）、纸质与早期电子病历混合期的书写习惯、当时的用药与监护标准。任何跨年代或跨国的迁移研究都应显式讨论这三重时点偏差。此外，2001-2012 年间的临床指南本身也在变（如脓毒症定义从 Sepsis-1 演到 Sepsis-3 的前夜），同一诊断标签在不同年份对应的临床含义并不完全一致，做时间切片分析时要留意这种"标签漂移"。

§4 构建流水线：从关系表到 JSON

4.1 四条件筛选的工程含义

四个条件在原始库上对应四类查询。"诊断少于 5 条"要 join DIAGNOSES_ICD 按 HADM_ID 分组计数；"非新生儿"一般通过 ADMISSIONS.ADMISSION_TYPE 或科室字段与年龄阈值判断；"住院期间存活"对应 ADMISSIONS.HOSPITAL_EXPIRE_FLAG = 0；"结构化数据完整且至少一份出院小结"对应 NOTEEVENTS 中存在 CATEGORY = 'Discharge summary' 的记录，且关键表在该 HADM_ID 下非空。这四条都不是 MIMIC 官方提供的视图，需要使用者自己写 SQL——作者的 data_process.ipynb 实现了这一步，但 notebook 是否随数据集发布、是否在 GitHub 仓库中公开，页面未明确。

4.2 三类数据的三种处理手法

数据类型	内容	手法	风险点
结构化	入院信息、人口学、诊断、处方、操作、Chart/Lab	按 HADM_ID 直接合并	高频事件（如逐小时生命体征）如何压缩成 JSON，页面未说明
半结构化	ECG、超声、影像报告	正则识别 Findings、Impression 等小标题后分段	报告模板不统一时切分失败，字段可能错位
非结构化	出院小结	GPT-4 抽取为结构化字段	抽取错误的传播、LLM 版本漂移影响可复现性

这是全文件最重要的方法论差异：确定性规则处理半结构化，生成式模型处理非结构化。前者失败方式是"切不出来"，后者失败方式是"切出来但内容不对"，且后者不可复现——GPT-4 的某一版本在某一时点的输出，换时间换版本可能不同，而数据集里只有最终结果，没有中间日志。这对做"数据质检"研究的人反而是个有趣切入点。

4.3 为什么以住院为单位而非患者为单位

以住院为单位有两个好处：一是诊断目标更明确（每次住院有明确的 admission_diagnosis 与 ICD-9 清单），二是临床推理的边界更清晰（入院到出院是一个闭环）。代价是丢失纵向信息——同一患者多次入院之间的病程演进不在同一文件里，做"再入院预测"或"疾病进展"研究需要自行跨文件按 patient_id 关联。

4.4 与原始表的对照关系

JSON 字段并非一对一映射原始表，而是再设计的层级：

• Patient.Admission_info ← ADMISSIONS（SUBJECT_ID → patient_id，HADM_ID → admission_id）+ ADMISSIONS.DIAGNOSIS（→ admission_diagnosis）
• Demographics ← PATIENTS（GENDER、DOB、DOD 等）
• Diagnoses ← DIAGNOSES_ICD join D_ICD_DIAGNOSES（ICD-9 码 + 描述）
• Prescription ← PRESCRIPTIONS（药名、剂量、途径、起止时间）
• 生命体征 ← CHARTEVENTS 中的 VS 类 ITEMID
• 化验 ← LABEVENTS join D_LABITEMS
• ECG/Radiology ← NOTEEVENTS 中对应 CATEGORY 的报告文本，经正则切分
• Introduction/Chief Complaint/Physical Exam/Allergies 等 ← 出院小结经 GPT-4 抽取

理解这张对照表，是在 JSON 出现字段缺失时能回溯到原始表定位原因的前提。

§5 一次住院的 JSON 解剖：字段级说明

本节按 PhysioNet 页面披露的字段层级逐段拆解。需注意：官方页面只给出字段名与部分示例，未公布完整的 JSON Schema（类型、必填性、嵌套深度、取值域），因此下文对类型的描述属于"按字段名与常规临床数据形态推断"，凡推断处均标注；真正写代码前必须用获批后的实际文件核对一次。

5.1 顶层骨架

从页面给出的路径写法可以看出，JSON 采用了"病人对象 → 临床板块"的两层结构：

{
  "Patient": {
    "Admission_info": { "patient_id": ..., "admission_id": ...,
                        "admission_diagnosis": ... },
    "Demographics":  { ... },
    "Diagnoses":     [ ... ],
    "Prescription":  [ ... ],
    "Physical Exam": { ... },
    ...
  },
  "ECG":      { ... },
  "Radiology":{ ... },
  "Introduction": "...",
  "Chief Complaint": "...",
  "Allergies": ...,
  "Major Surgical or Invasive Procedure": ...
}

这里有两个容易踩的点。其一是板块并非全在 Patient 之下：ECG、Radiology、Introduction、Allergies 等键在页面示例中是与 Patient 平级的顶层键，取数时如果只遍历 data["Patient"] 会漏掉所有报告与主诉。其二是字段名含空格（Physical Exam、Chief Complaint、Major Surgical or Invasive Procedure），Python 侧必须用 data["Physical Exam"] 而不是属性访问，JSONPath 写法也要注意引号转义。

5.2 Admission_info

三个子字段承载身份锚点：patient_id 对应 MIMIC-III 的 SUBJECT_ID，admission_id 对应 HADM_ID，admission_diagnosis 是入院诊断的自由文本（对应 ADMISSIONS.DIAGNOSIS，该字段在 MIMIC-III 中长期质量参差，常见拼写错误与缩写）。文件名 100173.json 的命名规则页面只说"以唯一标识符命名"，未明确是 HADM_ID 还是 SUBJECT_ID；由于 100173 落在 MIMIC-III 的 SUBJECT_ID 常见区间内，更可能是患者号，但必须实测确认——这会直接影响你能否用文件名做 join。

5.3 Demographics

人口学板块给出性别、年龄（MIMIC-III 通常以 anchor_age + 入院年份推算，89 岁以上患者统一记为 300 岁左右的去标识化处理）、种族与婚姻状态等。这里有一个陷阱：MIMIC 的年龄是去标识化后的偏移量，不是真实年龄，且 89 岁以上被压缩到同一区间。做年龄分层统计时必须遵循官方说明，不能当连续变量直接用。

5.4 Diagnoses

页面明确写了 Diagnoses 以 ICD-9 编码组织。原始 DIAGNOSES_ICD 每行一个码，带 SEQ_NUM 表示主次顺序；JSON 中是否为数组、是否保留顺序、是否附描述文本，页面只给了"ICD-9"这一句，未展示样例。由于筛选条件限定"诊断少于 5 条"，每个文件的诊断列表都很短，这也意味着诊断推理的目标集合很小——平均每个病例只有几条候选，模型即使瞎猜也有一定命中率，这一点在解读 Hit@K 指标时必须计入（见 §8.4）。

5.5 Prescription

处方板块应有的字段是药名、剂量、剂量单位、给药途径、频次、起止时间。MIMIC-III PRESCRIPTIONS 的一个专业坑是 DRUG 字段为自由文本药名，同一成分可能因商品名、剂型、拼写差异出现多种写法（如 metoprolol 与 metoprolol tartrate），直接按字符串统计会显著低估实际用药。JSON 化过程中是否做了归一化，页面未说明。

5.6 生命体征与化验

Chart Data（生命体征）与 Lab Data（化验）是单次住院中数据量最大的两块。MIMIC-III 的 CHARTEVENTS 与 LABEVENTS 都带 ITEMID 数字编码，需要 join 字典表才能翻译成"心率"“收缩压”“血肌酐”。JSON 中若已把 ITEMID 翻译成可读名，使用者就不必再带字典表；但这也意味着单位可能与字典表定义不同（例如血压是 mmHg 还是 cmH₂O——MIMIC 中确有按呼吸机管路压力记录的条目混入血压项的历史问题），做数值分析前必须逐项核对单位。

5.7 ECG / 超声 / 影像报告

三类报告都以 MIMIC-III NOTEEVENTS 的文本形态存在，作者用正则识别 Findings、Impression 等小标题后切分成分段字段。这套做法的可靠性完全取决于报告模板的一致性：BIDMC 的影像报告模板相对规范，切分成功率较高；而 ECG 自动报告（MUSE 系统输出）格式固定但术语缩写多，超声报告则因操作者差异较大。使用这些字段做"报告结构化"研究时，建议先抽样 20 例人工核对切分边界。

5.8 出院小结抽取字段

Introduction、Chief Complaint、Major Surgical or Invasive Procedure、Allergies、Physical Exam（下含 VS、General、HEENT、Neck、Cardiac、Lungs、Abdomen、Extremities、Skin、Pulses 十个亚项）这些字段，来自 GPT-4 对出院小结的抽取。这组字段的名字本身就是出院小结的章节标题，说明抽取策略是按章节标题定位后整体搬移，而非细粒度实体抽取。这种策略的优点是实现简单、字段可读性高，缺点是它对标题格式高度敏感：如果某份小结把"体格检查"写成"体查"或直接省略标题，抽取就会整体落空。

值得专门说的是 Physical Exam 的十个亚项：HEENT（头眼耳鼻喉）、Neck（颈，含颈静脉怒张与甲状腺）、Cardiac（心音、杂音）、Lungs（呼吸音）、Abdomen（腹软、压痛、反跳痛）、Extremities（水肿）、Skin（皮疹）、Pulses（周围脉搏）——这套检查顺序是内科病历的标准模板。对病人模拟器而言，这些字段是"查体"环节的答案来源；对研究而言，它是一个天然的"结构化查体语料"，可用于训练查体描述到异常体征的映射。

5.9 缺失与空值

由于筛选条件要求"包含所有主要类别的结构化数据"，理论上每个文件都有内容。但实际使用中会出现三类"软缺失"：字段存在但值为空字符串、值为 “N/A”/“None”、以及章节标题存在而正文为空（出院小结中常见"见上"引用）。建库时应把这三类统一映射为 null，否则问答系统会把空字符串当作"有信息"而给出空洞回答。

这三类软缺失还有一个"连锁效应"值得警惕：当 Physical Exam.Lungs 为空时，路由仍可能命中该章节（因为章节键存在），于是模型拿到一个空对象，它会倾向于用"听起来像"的内容填补空白——这正是幻觉的高发场景。一个简单的工程对策是在路由后加一道"空值检查"，命中但内容为空时直接返回固定的拒答句，而不是交给模型自由发挥。这条规则不需要模型理解，只需要代码判断，可靠性远高于提示词约束。

§6 获取与许可：和 MIMIC 本体同一道门

6.1 三步认证流程

第一次接触 PhysioNet 认证资源的人常卡在这一步，这里给完整路径：

1. 注册 PhysioNet 账号（physionet.org，免费），在账户设置中补全姓名、机构、职位、ORCID 等信息。
2. 完成 CITI 培训：在 citiprogram.org 注册，选修 “Data or Specimens Only Research” 课程，通过后下载完成证书（PDF），在 PhysioNet 账户的 “Training” 页上传，等待人工审核（通常数个工作日）。
3. 签署 DUA：在该数据集页面点击 “Request access”，填写研究用途说明，在线签署 PhysioNet Credentialed Health Data Use Agreement 1.5.0；由数据托管方审批，通过后该账号即可下载。

三步缺一不可，且CITI 证书有效期与再认证需要自己盯：证书过期后新的下载请求会被拒。

6.2 许可条款的实际约束

Credentialed Health Data License 1.5.0 的核心条款可以概括为四条禁令加一条义务：不得再识别或尝试再识别个体；不得把数据分享给未签署 DUA 的第三方（包括把数据喂给未确认数据留存政策的外部 LLM API）；不得用于商业用途（需另行洽谈）；不得公开任何数据子集（包括"示例文件"）；义务是发表时引用数据集 DOI 与 PhysioNet 标准引文。

对本文读者最相关的是第二条。answer_agent.py 默认调用 OpenAI API，把患者 JSON 片段作为提示词发送出去——这在 DUA 框架下是否合规，取决于服务商是否提供零数据留存（zero data retention）配置。PhysioNet 页面专门用一段说明提示了这一点：未确认留存与隐私政策兼容前，不得把认证 MIMIC 数据传输给第三方。作者自述在处理中采用了零留存配置，但使用者自己的调用不在作者的合规范围内，必须自行评估。需要补充的是：即使服务商承诺零留存，“提示词是否进入日志、日志保存多久、内部审计人员能否访问"这些细则仍要逐条看条款，而不是只看宣传页上的一个勾选项。实践中的判断顺序建议是：先确认服务商接口是否在条款中承诺"不用于训练"与"有限留存”，再看能否申请到企业级零留存，最后才是考虑是否接受"放弃外部 API、改本地推理"这一退路——顺序反了容易出现"先跑通再补合规"的风险。

6.3 地区限制

抓取时 PhysioNet 页面显示 “Data Not Available”，原因写明为"数据在你的地区因法律或政策限制不可用"。这不是条目下架，而是平台侧的出口管制/地区策略。中国大陆访问者可能需要通过合规的机构渠道或海外合作者获取，具体以 PhysioNet 的 Access 页面说明与机构法务意见为准，本文不作操作建议。

6.4 版本与 DOI

v1.0.0 的 DOI 是 10.13026/bzzd-w075；PhysioNet 同时给出"latest version" DOI 10.13026/n19w-aw59，后者是版本无关的持续标识，指向最新版本。引用时：若你的分析绑定 1.0.0 的具体文件，引 v1.0.0 的 DOI；若只提"这个数据集"，引 latest DOI 更稳。brief 中出现的 10.13026/rees-1092 与官方任一 DOI 均不符，疑为同名不同物或其他派生集的标识，已在坑 1 存照。

6.5 获取后的第一件事

拿到压缩包后建议立刻做三件事：ls patient_json | wc -l 核对文件数是否为 500；md5sum 全部文件留指纹（便于日后判断上游是否静默更新）；对 3-5 个文件跑一次 json.load 确认无编码问题（出院小结含特殊符号，历史上有文件使用非 UTF-8 编码的案例）。

§7 answer_agent.py：两段式病人模拟器

7.1 设计动机

病人模拟器的难点不在"回答得像病人"，而在回答得克制。如果直接把整份 JSON 丢给 LLM，模型会倾向于把知道的一切都说出来——问"你哪里不舒服"，它回答"我因急性心衰入院，既往高血压、糖尿病，目前用呋塞米 40mg 静推"——这等于作弊，多轮问诊的"信息获取"难度被抹平了。所以必须有一个机制，把"模型知道什么"限制在"病人被问到什么"。

answer_agent.py 用最朴素的方式实现这个限制：关键词路由 + 章节级检索。

7.2 第一段：关键词路由

流程是：问题文本 → 正则分词 → 关键词提取 → 查预置映射字典 → 定位 JSON 章节 → 取出该章节内容 → 连同问题一起交给 LLM → 以病人第一人称作答。

与论文描述一致，路由表是"预定义的关键词 → 章节"字典。例如含"medication/drug/prescription/药"的问题路由到 Prescription，含"pain/hurt/疼"的问题路由到 Chief Complaint 与 Physical Exam。章节内容是整块送进提示词的，而不是先做段落级相似度检索——这也解释了为什么它不需要向量库。

这一步的三个优点：确定性（同一问题路由结果可复现）、可解释（能回答"这个答案来自哪一节"）、低成本（送进模型的 token 少）。三个缺点同样明显：词典覆盖有限，口语化表达（“我这两天心里发慌”）难命中"cardiac"；一词多义（“pressure” 可能是血压也可能是压力性疼痛）；跨章节问题（"你以前有过类似情况吗"需要同时看 Introduction 与历史入院，而单文件只有本次住院）无法处理。

7.3 第二段：LLM 合成与兜底

当路由未命中，或检索到的章节内容为空/模糊时，系统回退到整份 JSON 作为上下文直接推理。这是兜底，也是漏洞：兜底路径一旦触发，"克制原则"就失效了，模型可能把全部信息倒出来。论文对此没有给出兜底触发率的统计，使用者若要做严格的多轮问诊评测，应当自行记录兜底触发次数（可达性指标），并在结果里报告。

系统提示词中还有一条安全约束：对病例中无信息的提问，必须回答 “I don’t know”。这条约束的重要性在于，它把"幻觉"变成可测量的指标——病人说"不知道"是正确的，编造一个不存在的手术史才是错误。人工评估中的 Truthfulness 维度正是测这个。值得注意的是，这条约束与路由机制之间存在张力：路由把上下文收窄到某几个章节，模型看不到的字段会被判为"无信息"，即便原始 JSON 里其实有；因此病人说"不知道"有两种来源，一种是数据确实没有，另一种是路由没把数据送进来。区分这两者，需要把每次问答的命中章节一并留痕，否则评测者会把路由漏召回误判为模型能力不足。这也是本文建议在做任何 Hit@K 报告时同时公布兜底率与章节命中分布的原因：单看最终回答，无法判断失误发生在检索层还是推理层。

7.4 命令行与运行

README 给出的用法：

python answer_agent.py --path <patient_json_file> --question "What medications are you taking?" --model gpt-4.1

三个参数：--path 单文件路径；--question 问题文本，省略时输出开场自我介绍（对应 Introduction 字段）；--model 指定 OpenAI 模型，默认 gpt-4o（多智能体脚本）或 gpt-4.1（患者脚本，以 README 示例为准）。依赖仅 pandas openai requests，API Key 放在根目录 config.json 的 OPENAI_API_KEY 字段。

需要注意：脚本是无状态单轮的——每次调用独立读文件、独立回答问题，不维护对话历史。多轮问诊的对话状态由上层 doctor_agent.py 维护，它把历史问答拼进下一次请求。这意味着如果你单独调用 answer_agent.py 做多轮测试，模型看不到前文，可能出现前后矛盾的回答——这是使用方式问题，不是数据问题。

7.5 与其他病人模拟方案的对照

方案	检索机制	信息边界控制	实现成本	代表
关键词路由 + 章节块	字典映射	强（只给命中章节）	低	MIMIC-Patient
向量检索 RAG	语义相似度	中（Top-K 段落可能跨章节）	中	通用 RAG 栈
结构化查询（Text-to-SQL）	问题转 SQL	强（精确字段）	高	EHRSQL 类
全量上下文	无	弱（全部可见）	最低	直接塞 JSON

四者没有绝对优劣。关键词路由的优势是边界清晰、可审计；劣势是覆盖率低。做智能体研究时，一个自然的改进方向是"路由优先、RAG 兜底、全量上下文作为最后手段"，并把每一级的触发率作为系统指标报告出来。

7.6 一个被忽略的工程细节

分词用的是正则而非临床 NLP 工具（如 scispaCy、MetaMap），因此对缩写与同义词的处理依赖字典本身的手工维护。想要提升覆盖率，最直接的办法是扩充字典并加入同义词表（“SOB”→“shortness of breath”→Chief Complaint/Lungs），而不是换更重的检索模型——因为瓶颈在召回入口，不在排序。还有一个更细的问题：正则分词对否定句几乎无感，问"你有没有得过大病"时，如果 JSON 里某字段写着"否认重大疾病史"，路由命中后把这句原样交给模型，模型可能读成"得过大病"。这类否定范围错误在抽取阶段和回答阶段都会发生，抽检时必须专门测。

§8 任务、指标与在 DynamiCare 中的位置

8.1 两个任务共用一份数据

MIMIC-Patient 支撑两个层面的任务。患者问答：单轮，问一句答一句，评估回答的真实性与相关性。动态诊断：多轮，医生智能体团队轮流提问，逐步形成鉴别诊断清单，评估命中率与提问效率。前者是数据本身的能力，后者是数据被用作环境（environment）的方式。

8.2 诊断任务的流程

一次 episode 的流程大致是：系统读取一个患者 JSON，但只把"主诉"或极简信息给医生智能体；医生团队（多个专科 agent）轮流生成问题，问题经 answer_agent.py 转为病人回答；团队根据回答动态调整成员构成（例如出现神经系统症状时加入神经科 agent）与下一步检查；达到轮数上限（--max_rounds，默认 10）或团队认为可以下结论时输出诊断清单。整个过程记录在 data/log/log_{patient_id}_{model}.json，结果写入 data/result/result_{patient_id}_{model}.json，包含最终诊断与 ground truth。

8.3 指标定义

• Hit@5 / Hit@10：正确诊断是否出现在预测清单的前 5 / 前 10 位。衡量"能不能想到"。
• Rec@5 / Rec@10：前 5 / 前 10 位覆盖了多少条真实诊断。衡量"想得全不全"。
• Ave-Q：平均提问轮数。衡量交互深度，也是成本指标。
• 匹配规则：预测诊断文本经 BioPortal API 映射为 ICD-9 编码，取前三位匹配即算正确。这意味着 “428.0 充血性心力衰竭” 与 “428.9 心力衰竭未特指” 在三位码层面算同一类（428），预测空间是 1000+ 个三位码组，而非 1.4 万个完整 ICD-9 码。这条规则显著放宽了匹配，解读结果时必须记住。

8.4 关键结果

论文报告的多智能体（DynamiCare）对单智能体（GPT-4.1）对比：Hit@5 63.4 vs 58.0，Hit@10 71.6 vs 63.2，Rec@5 43.2 vs 31.0，Rec@10 58.8 vs 41.7，Ave-Q 7.55 vs 3.83。与 MEDIQ 基准对比（同为 GPT-4.1）：iMedQA 92.0 vs 67.0，iCraftMD 96.4 vs 72.1（这两项是对话质量类指标，口径与 Hit@K 不同，不可混算）。患者系统人工评估：100 例、3 名医学生独立打分、3 分制（0-2），Truthfulness 均值 1.95，Relevance 均值 1.79。

读这组数字有三条注意事项。一是 Hit@10 71.6 的天花板并不高：考虑到每个病例的诊断数少于 5 条、预测空间只有三位码组，71.6 说明模型在"想到正确诊断"上仍有明显缺口。二是 Ave-Q 翻倍不等于效率下降：多智能体问得更多（7.55 轮 vs 3.83 轮），但命中率也更高，单位轮次的信息增益是否更高，论文未给出计算。三是人工评估样本 100 例、评分者 3 人，未报告评分者间一致性（如 Cohen’s κ），Truthfulness 1.95 的"接近满分"需要谨慎解读——评分者可能都倾向宽松。

8.5 与既有基准的差异

MEDIQ、iMedQA、iCraftMD 这些名字看起来像同一族，实际口径不同：MEDIQ 是交互式医疗决策模拟环境，iMedQA/iCraftMD 是其内部的两个具体场景。DynamiCare 在它们之上的增量是"患者端信息受控"与"专科团队可动态重组"。若要把本数据集的成绩与其他临床 QA 基准（如 MedQA 的多选题准确率）横向比较，是不同任务不可比的典型错误——前者测多轮问诊后的清单排序，后者测单轮选择题正确率。

8.6 复现所需的最小环境

Python 3.10+、pandas/openai/requests、OpenAI API Key、BioPortal API Key（仅 data_convert.py 需要）。由于模型版本会变，论文的绝对数字不可严格复现，能做的是在同一天、同一模型快照下跑对照组（单智能体 vs 多智能体），比较相对差异。所有涉及 API 的评测都应记录调用日期与模型快照名，这是当前 LLM 评测的通行做法。

§9 上手实践：十条检查清单

第 1 条：确认访问状态。在 PhysioNet 登录后检查数据集页是否出现 “Download” 按钮；若仍是 “Request access”，说明 DUA 未批或 CITI 未过。地区限制提示与权限不足提示的区别要分清。

第 2 条：核对文件数。find patient_json -name '*.json' | wc -l 应为 500。若不符，先查是否解压不完整，再联系托管方。

第 3 条：验 JSON 可解析。批量 json.load 一遍，记录失败文件。编码问题在含特殊符号（µ、°、±）的病历文本中并不罕见。

第 4 条：确认文件名语义。随机挑 3 个文件，比对文件名词与内部 patient_id/admission_id，确定命名用的是哪一个，再决定后续 join 策略。

第 5 条：摸清顶层键。set(data.keys()) 打印一遍，别假设只有 Patient。把顶层键清单写进你的数据字典。

第 6 条：单位核对。抽 5 例的生命体征与化验，与 MIMIC-III 官方 D_ITEMS/D_LABITEMS 的单位定义比对，特别是血压、体温（华氏/摄氏）、血糖（mg/dL vs mmol/L）。

第 7 条：诊断码验证。抽 10 例，把 JSON 里的 ICD-9 与 MIMIC-III DIAGNOSES_ICD 中同 HADM_ID 的记录对一遍，确认是否保留了主次顺序、是否丢了描述文本。

第 8 条：抽取字段抽检。抽 10 例，把 Physical Exam 各亚项与原始出院小结对照，估算 GPT-4 抽取的准确率，作为后续使用这些字段的置信度基线。

第 9 条：API 合规确认。查所用 LLM 服务商是否提供零留存/不训练承诺，必要时改用本地部署模型；企业版与个人版的留存政策可能不同。

第 10 条：记录版本与日期。把数据集 v1.0.0、模型快照名、运行日期写进实验日志。三个月后回头复现时，这三项是唯一能解释差异的线索。

这十条清单的顺序不是随意的：前四条验的是"数据拿到手没有、拿到的是不是完整的"，中四条验的是"字段能不能直接用"，后两条验的是"合规与可追溯"。多数团队出问题的环节在第六、七、九条——单位、诊断码、API 合规三件事看起来是细节，实际上决定了整份分析结论是否成立。建议把清单做成 checklist 文件随项目走，每次新成员加入都跑一遍，避免经验只留在个别人脑子里。

§15 深度解析：筛选漏斗、抽样与"500 例"的统计学含义

15.1 漏斗的三次收缩

把 58,976 到 500 的过程拆成比例来看，能更清楚地理解每一步在删什么：

阶段	数量	相对上一步	删掉了什么
MIMIC-III v1.4 全部住院	58,976	100%	—
诊断记录少于 5 条	未单独披露	—	多病共存、复杂共病、恶性肿瘤多发转移等
再排除新生儿	未单独披露	—	新生儿 ICU 住宿、先天性疾病、产科相关（部分）
再排除院内死亡	未单独披露	—	重症终末期、抢救失败、临终关怀病例
再要求数据完整 + 至少一份出院小结	2,597	4.40%（对全库）	转院离院、文书缺失、结构化数据稀疏的病例
随机抽 500	500	19.26%（合格池）	随机，无系统性偏好

页面没有给出中间步骤的逐条件剩余量，这是一个真实的信息缺口。对使用者而言，这意味着无法判断哪一条筛选贡献最大——如果"诊断少于 5 条"删掉了 80% 的病例，那么这份数据集的"轻症"属性就极强；如果主要是"出院小结缺失"在删，那么病例复杂度可能并没有那么低。两种情形的科学含义完全不同。这一项建议在作者后续版本或论文附录中补充，本文只能标注为未披露。

15.2 500 例的统计属性

从抽样理论看，500 是个"中等"样本量：对总体比例估计，95% 置信区间半宽约为 1.96 × √(0.25/500) ≈ 4.4 个百分点。但这一公式的前提是简单随机抽样且无选择偏倚，而这里前一步有四条件硬筛选，等于做了分层截断，置信区间公式不再适用。换句话说，样本内的统计量可以算，但不能把它当作 MIMIC-III 总体参数的无偏估计。

另一个常被忽略的点是聚类效应：500 次住院来自约数百位患者，同一位患者的多次入院之间存在强相关（同一基础疾病、同一体质）。若按住院为单位统计，标准误会被低估。做严谨分析时应使用患者层面的聚类稳健标准误，或按患者做 bootstrap。

15.3 为什么是 500 而不是 1000

页面未说明样本量选择理由。从论文的评测设计反推：多智能体诊断每个 episode 要消耗 10 轮以上问答、每轮一次 LLM 调用，单例成本显著高于静态问答；500 例 × 2 个系统（多智能体/单智能体）× 10 轮，已经是数万次 API 调用量级。500 是在"统计上够用"与"算力上可承受"之间的折中，也是小规模临床智能体评测的常见量级（同类工作多在 200-1000 之间）。

15.4 一个反直觉的推论

由于筛选条件是"诊断少于 5 条"，而抽样的目标是"诊断推理"，这份数据集实际上把任务难度压低了。真实的鉴别诊断之所以难，往往是因为患者同时有多种慢性病、症状互相掩盖、用药互相干扰。删掉这些病例之后，剩下的多是"单一主诊断 + 若干稳定慢病"的干净病例。因此在这份数据上训练的智能体，到了真实 ICU 环境很可能表现下降——不是模型变差，而是分布变了。做部署前评估时，必须额外准备一份未经筛选的测试集。

§16 工作流实例：一次真实会话的推演

16.1 场景设定

假设取一个 60 岁男性病例，入院诊断为"急性失代偿性心力衰竭"，诊断为 3 条（心衰、高血压、2 型糖尿病，均少于 5 条，符合入池条件），住院 6 天，出院存活，出院小结齐全。JSON 中可见 Chief Complaint 为"气促 3 天加重"，Physical Exam.Lungs 记"双肺底湿啰音"，Physical Exam.Extremities 记"双下肢凹陷性水肿 2+"，Prescription 含呋塞米、美托洛尔、二甲双胍。

16.2 医生智能体的提问序列

第一轮，全科医生 agent 提问"你这次为什么来医院"。路由命中 Chief Complaint，病人答"这三天越来越喘不上气，晚上躺不平"。此时医生团队只有全科一人。第二轮，医生问"有没有胸痛或发烧"。问题含"pain"与"fever"关键词，若字典有对应项则路由到 Chief Complaint 与 Physical Exam.General，病人答"没有胸痛，没量过体温，好像不烧"。第三轮，医生要求"描述一下你的腿"。关键词"leg/swelling"路由到 Physical Exam.Extremities，病人答"两条腿肿，按下去有个坑"。此时医生团队动态加入心内科 agent。第四轮，心内科问"平时吃什么药"。路由到 Prescription，病人答"有一种利尿的，还有降压的，名字记不清"。第五轮，医生开化验（这一步在 DynamiCare 中通过额外工具或直接提问实现），问"最近有没有查过血"。若 JSON 的 Lab 板块有关键词映射，则返回肌酐、BNP 等值；若无，则触发兜底，模型可能把全部化验倒出——这正是需要监控的兜底触发点。

16.3 诊断收敛

第 7-8 轮，团队提出鉴别清单：急性失代偿性心衰（首要）、COPD 急性加重、肺栓塞、肺炎、肾病综合征。以三位码匹配，心衰 428 命中 ground truth，Hit@5 成功。整个 episode 用了 8 轮，接近论文报告的 Ave-Q 7.55 均值。

16.4 这个例子里暴露的三个设计问题

问题一：关键词字典的中文/英文覆盖。上例全用英文，若测试者用中文提问，正则分词与英文关键词字典完全对不上，全部走兜底。这说明 answer_agent.py 是英文专用的，中文场景需重写路由层。

问题二：检查类问题的处理。真实问诊中"我给你开个血常规"是动作而非提问，模拟器需要区分"提问"与"下医嘱"。当前脚本只有问答接口，没有检查下单接口，化验结果的获取方式取决于上层设计。

问题三：时间维度缺失。“这三天越来越喘"中的"三天”，JSON 里只有入院与出院日期，没有症状起始时间线，模型只能从主诉文本里读到"3 天"这个字符串。做病程推理时这是硬约束。

§17 与同类数据集的横向对照

17.1 对照维度选择

横向比较容易失焦，这里选四个有区分度的维度：记录粒度（一次住院/一位患者/一条问答）、信息受控方式（静态全文/检索/模拟器）、获取门槛、主要用途。

数据集	粒度	受控方式	门槛	主要用途
MIMIC-Patient	一次住院	关键词路由模拟器	认证 + DUA	多轮诊断评测
MIMIC-III Demo	一位患者多表	无（静态）	公开	教学、联调
emrQA	一条问答	无（静态）	公开	抽取式问答训练
EHRXQA	一条问答 + 图像	无（静态）	公开	多模态 EHR 问答
EHRSQL	一条 SQL 问答	无（静态）	公开	Text-to-SQL
MedAgentBench	一个任务	虚拟 EHR 环境	公开	智能体工具调用
AIPatient	一位虚拟患者	知识图谱驱动	公开	病人模拟
MEDIQ	一次交互	模拟环境	公开	交互式决策

17.2 关键差异解读

与 AIPatient 的差异最有意思：AIPatient 用知识图谱 + 合成病历构造虚拟病人，可以任意生成罕见病例；MIMIC-Patient 用真实病历，覆盖面受制于真实分布。前者可控性强、可无限扩展，后者真实性强、但受选择偏倚影响。两条路线在"病人模拟"这个目标上互补。

与 MedAgentBench 的差异在评测对象：MedAgentBench 测的是"能不能正确调用工具、写对查询"，MIMIC-Patient 测的是"能不能通过问诊获得信息并做出诊断"。前者是操作能力，后者是临床推理能力。

与 emrQA/EHRXQA 的差异在任务形态：那两个是"给定病历片段，回答问题"，属于阅读理解；MIMIC-Patient 是"不给你病历，你自己问"，属于主动信息获取。难度层级不同。

17.3 为什么这份数据在 2026 年出现

时间点不是偶然。2024-2025 年间，医学 LLM 评测从"考试分数"转向"智能体能力"，静态题库的天花板已经显现（顶级模型在 MedQA 上接近饱和）。要区分模型，必须换更接近真实工作流的任务，而真实工作流的核心是"信息不完整下的多轮交互"。MIMIC-Patient 正是这一转向的产物：它不追求更大规模，而是追求"更真实的交互形态"。同一时期出现的 MedAgentBench、EHR-ReasonCon 等（库内 rid 1064、1007）都处在这条演进线上。

§18 数据治理视角：派生数据集的合规再思考

18.1 派生不等于脱敏

MIMIC-III 的去标识化遵循 HIPAA Safe Harbor 的 18 项标识符移除规则，并做了日期偏移（每位患者随机平移，保持间隔）。派生数据集在此基础上重新组织字段，但没有引入新的脱敏层。这意味着：JSON 中的每一条信息，其敏感性与原始表完全相同。把分散在 26 张表里的信息聚合成"一个人的完整画像"，在某些攻击模型下反而更容易做属性推断（例如通过罕见手术 + 罕见年龄 + 特定邮编区域组合定位个体）。

18.2 谁对合规负责

链条上有三方：PhysioNet（托管与访问控制）、作者（数据处理与发布）、使用者（使用场景）。DUA 约束的是使用者，但作者在页面上的说明（“LLM 处理采用零数据保留配置”）只覆盖了作者自己的处理阶段，不覆盖使用者后续的每一次 API 调用。实践中常见误区是"作者说零留存，所以我也可以直接调 API"——这两件事没有因果关系。

18.3 机构使用的现实路径

对医院或高校团队，合规路径通常是三条：一是走机构与 PhysioNet 的集体 DUA；二是使用机构自建的 LLM 网关（数据不出内网）；三是选择明确承诺不训练、不留存的企业 API 并留存合同证据。三条都需要 IRB 或伦理委员会的备案，尤其是当研究涉及"用 LLM 处理患者数据"这一新型处理活动时。

18.4 派生数据集的版本治理

v1.0.0 是初始版，后续若更新（修字段、补病例、换抽取模型），DOI 的 latest 版本会指向新版，而 v1.0.0 的 DOI 保持冻结。这对复现研究很关键：论文里写的 1.0.0，两年后可能已经不是默认下载的版本。建议在方法学部分同时写明版本号与 DOI，不要只写"latest"。

§19 复现与验证：一份可执行的核对脚本思路

19.1 目录级核对

拿到数据后第一件事是做目录级核对：确认 patient_json 目录存在、文件数为 500、扩展名统一为 .json、根目录下有 answer_agent.py。这一步能挡掉 80% 的解压失败与路径错误。

19.2 记录级核对

第二步是记录级核对：逐个 json.load，统计顶层键的并集与交集。如果某些文件的顶层键缺失（例如没有 ECG），说明该病例确实没有心电图报告，而不是解析出错。把"键缺失率"统计出来，可以作为数据质量的一个侧面指标。

19.3 字段级核对

第三步是字段级核对：抽样 20 例，把 Diagnoses 与 MIMIC-III 原始 DIAGNOSES_ICD 对比，把 Prescription 与 PRESCRIPTIONS 对比，把 Physical Exam 与出院小结原文对比。三张表分别给出"一致/缺失/多余/错位"四类计数，形成一份内部质检报告。这份报告不必公开（DUA 限制），但应在团队内部留存，作为后续使用这些字段的置信度依据。

19.4 评测级核对

第四步是评测级核对：用固定的 10 例、固定的问题集、固定的模型快照，跑一遍 answer_agent.py，记录路由命中率与兜底触发率。若路由命中率低于 50%，说明你的问题措辞与作者词典不匹配，需要扩充字典或改写问题。这一步是保证后续评测结果可比较的前提。

19.5 存档建议

建议把上述四步的结果（计数、哈希、日志）打包存档，并在论文附录中简要报告。这既是学术规范，也是应对"数据静默更新"的唯一手段——当上游发布 v1.1 时，你能证明自己的分析基于 v1.0.0。

§20 维护计划与条目状态

20.1 触发更新的条件

本条目在以下情形需要修订：PhysioNet 发布 v1.1 及以上版本并改变字段结构；作者公开 answer_agent.py 的路由字典或补充文档；出现第三方在 MIMIC-Patient 上的复现报告或排行榜；MIMIC-III 母库条目（rid 590）发生重大修订导致互链信息过期。

20.2 当前条目状态

截至 2026-10-17，条目为"首发状态"：核心事实（规模、筛选、门槛、DOI）已三源互证；字段级描述部分依赖页面披露与推断，标注为"待实测"；体量、文件名语义、路由字典细节为遗留疑点。这些缺口不影响条目的使用价值，但在做严格复现时应以实际文件为准。

20.3 对读者的最后提醒

这份数据集最容易犯的错，不是技术错误，而是定位错误：把它当成 MIMIC-III 的"轻量版"来用（会导致统计结论失真），或者把它当成"公开数据集"来传播（会违反 DUA）。正确的心态是：它是一份结构友好的评测夹具，价值在于形态而非规模，使用时必须带上它的筛选条件和合规约束一起去理解。

定位错误往往不是一次性发生的，而是在项目推进中逐步滑移：开始时你清楚它只适合做方法评测，写到第三个月，为了让结果更好看，开始用它估算"某病在 ICU 的占比"，滑坡就此开始。防滑坡的办法不是自律，而是在项目启动时就把"可回答的问题清单"和"禁止回答的问题清单"写进文档，并在每次新增分析时对照一次。这份清单不必长，七八条即可，但它能把最常见的误用挡在门外。

20.4 条目自评

若用一句话概括本条目想传达的核心判断：MIMIC-Patient 用一个精巧的结构设计，把"多轮问诊"从不可评测变成了可评测，代价是牺牲了样本代表性；使用者只要守住"只做方法评测、不做分布推断"这条线，就能安全地获得它的全部价值。

这条判断可以反向使用：当你在文献里看到有人用 MIMIC-Patient 声称某种临床结论（例如"心衰患者中某指标升高与再入院相关"），先看它是否守住了这条线；如果没有，结论的可信度要用本文 §13、§15 的框架重新审一遍，而不是直接引用。

§21 深入 answer_agent.py：从设计意图到可移植实现

21.1 两段式架构的因果链

要理解 answer_agent.py 为什么长这样，得先看它要解决的约束。约束有四条：第一，患者数据体积不小，单份 JSON 含大量化验与生命体征，整份塞进上下文既贵又容易稀释注意力；第二，DUA 要求最小必要披露，理论上只应把被问到的信息交给模型；第三，评测需要可解释性——评审者会问"这句回答从哪来"；第四，实现成本要低，作者的主线是多智能体框架，不能在患者端耗太多工程量。四条约束叠加，答案就是"关键词 → 章节"的字典路由：它最便宜、最可解释、披露面最小，唯一代价是覆盖率。

21.2 路由表的可能结构

虽然源码细节未公开，但从论文与 README 可以推断路由表大致是"关键词列表 → 章节路径"的映射，可能的形式是：

{
  "medication": ["Patient.Prescription"],
  "drug":       ["Patient.Prescription"],
  "allerg":     ["Allergies"],
  "pain":       ["Chief Complaint", "Physical Exam.General"],
  "fever":      ["Chief Complaint", "Physical Exam.VS"],
  "surgery":    ["Major Surgical or Invasive Procedure"],
  "ecg":        ["ECG"],
  "ct":         ["Radiology"],
  "x-ray":      ["Radiology"],
  "lab":        ["Patient.Lab"],
  "vital":      ["Patient.VS"]
}

一个关键词可以映射到多个章节（"pain"同时查主诉与一般情况），一个章节也可以被多个关键词命中（“drug”"medication"都指向处方）。这种"多对多"设计是必要的，因为患者描述症状时往往同时涉及主观感受与客观体征。值得注意的是，论文提到用的是正则分词而非词干化或嵌入相似度，这意味着 “medications”（复数）能否命中 “medication” 取决于正则是否做了词形容错——这是一个实现细节，也是复现时最容易出偏差的地方。

21.3 提示词层面的三个角色约束

从论文描述看，患者系统的提示词至少包含三条角色约束：一是第一人称、口语化（不能像病历一样念术语）；二是只答所问（不主动扩展）；三是不知道就说不知道。这三条在评测中的意义不同：第一条影响 Relevance 评分（回答是否像人），第二条影响任务的"信息获取难度"（是否被作弊），第三条影响 Truthfulness（是否幻觉）。作者用 3 分制人工评估同时测 Truthfulness 与 Relevance，恰好对应这三条约束中的两条半。

21.4 可移植实现的最小骨架

若要在自己的数据上复刻这套逻辑，最小骨架需要四个组件：加载器（读 JSON、扁平化）、路由器（关键词 → 路径列表）、取数器（按路径取内容、处理缺失）、合成器（拼提示词调 LLM）。下面给出参考结构：

ROUTES = {
    "medication": ["Patient.Prescription"],
    "allerg":     ["Allergies"],
    "pain":       ["Chief Complaint", "Physical Exam.General"],
    "surgery":    ["Major Surgical or Invasive Procedure"],
}

def resolve(case, path):
    cur = case
    for part in path.split("."):
        if not isinstance(cur, dict) or part not in cur:
            return None
        cur = cur[part]
    return cur

def build_context(case, question):
    q = question.lower()
    sections = []
    for kw, paths in ROUTES.items():
        if kw in q:
            for p in paths:
                v = resolve(case, p)
                if v:
                    sections.append((p, v))
    if not sections:
        return "FALLBACK", case          # 兜底：全量上下文
    return "ROUTED", sections

def prompt(case, question):
    mode, ctx = build_context(case, question)
    if mode == "FALLBACK":
        body = f"Patient record:\n{json.dumps(ctx, ensure_ascii=False)}"
    else:
        body = "\n".join(f"[{p}]\n{v}" for p, v in ctx)
    return (
        "You are the patient. Answer in first person, only with facts "
        "in the record. If the record has no answer, say 'I don't know'.\n\n"
        f"{body}\n\nQuestion: {question}\nAnswer:"
    )

骨架的重点不在代码本身，而在三个可观测点：mode 记录走了路由还是兜底；sections 记录命中了哪些章节；提示词长度记录 token 成本。把这三点写进日志，就能在评测报告里给出"路由覆盖率"“兜底率”"平均上下文 token"三个系统级指标——这比只报 Hit@K 更能说明一个智能体架构的优劣。

21.5 提升覆盖率的四条路径

第一条是同义词扩展：把 “SOB/shortness of breath/dyspnea/breathless” 全部映射到呼吸系统相关章节。第二条是否定与时间词处理：问"最近有没有做过手术"时，"没有"这个答案本身也是信息，不能因为关键词未命中就兜底。第三条是章节级索引：把每个章节的字段名本身也做成关键词（问"血压"直接命中 VS），比手工维护关键词表更省力。第四条是轻量向量兜底：路由失败时先用小模型做章节级相似度排序，取 Top-2 章节，仍为空才走全量。四条路径的工程成本递增，收益也递增，建议按需叠加。

§22 数据字典的再细化：字段命名与语义边界

22.1 命名风格的混杂

从页面披露看，字段命名风格并不统一：有蛇形小写下划线（patient_id、admission_id、admission_diagnosis），有帕斯卡式（Patient、Admission_info、Demographics、Diagnoses、Prescription、Introduction、ECG、Radiology、Allergies），还有带空格的自然语言式（Chief Complaint、Physical Exam、Major Surgical or Invasive Procedure）。这种混杂通常是多人协作或分阶段开发的产物：结构化字段由脚本生成（蛇形），板块名由代码类定义（帕斯卡），出院小结抽取字段直接沿用了原文标题（自然语言）。

对使用者而言，混杂命名带来三个具体麻烦：一是自动扁平化时会产生不一致的键（Patient.Admission_info vs Patient.Physical Exam）；二是跨文件比较时需要写归一化函数；三是若要把数据导入 DataFrame 或 SQL 表，列名需要统一改写（数据库列名对空格不友好）。建议在入自己的分析管线时，先做一次"命名归一化映射表"，把空格换下划线、统一大小写风格，并保留原始键名以便回溯。

22.2 Introduction 字段的语义

Introduction 在病人模拟器中是"开场白"的来源，对应的是出院小结里的"病史摘要"段落。这个字段的命名容易让人误解为"介绍信"或"前言"。从使用上看，它应该包含患者的基本人口学、主诉、现病史概要，足以让医生智能体在零轮提问时形成初步印象（DynamiCare 的初始输入很可能就是这一段）。使用时要警惕：如果 Introduction 里已经写了明确诊断（出院小结经常在第一段就写"患者因急性心衰入院"），那么医生智能体的任务就被提前剧透了。在严格的评测协议中，Introduction 必须先做诊断信息剥离，否则 Hit@K 会被高估。

22.3 Allergies 与用药安全的关联

Allergies 字段看似次要，但在评测中有独特价值：一个称职的医生智能体在开药前应当询问过敏史，而一个只会查诊断的智能体会跳过这一步。若把"是否询问过敏史"作为一个过程指标纳入评测，就能区分"结果对但过程不对"的模型。这也是多轮评测相比静态题库的优势——它可以评估过程质量而不只是结果正确率。

22.4 Major Surgical or Invasive Procedure 的边界

该字段记录住院期间的主要手术或侵入性操作（如冠脉造影、气管插管、中心静脉置管、透析）。出院小结里这一段常以列表形式出现，GPT-4 抽取时可能按行拆成数组，也可能拼成一个字符串——页面未说明类型。使用时若按字符串处理，需要自己按分隔符拆分；若按数组处理，需要处理"单条时退化为字符串"的情况。

22.5 Physical Exam.VS 与 Chart Data 的重叠

Physical Exam.VS（生命体征）与结构化板块中的 Chart Data（生命体征）存在潜在重叠：前者取自出院小结的查体段落（通常只记入院时的一组数据），后者来自 CHARTEVENTS（逐小时记录）。两者数值可能不一致（不同时间点），也可能单位不同。做分析时要明确以哪一份为准，不能把两份混在一起算均值。

22.6 缺失值的三种语义

同一"空"在不同字段下含义不同：Allergies 为空可能表示"无已知过敏"，也可能表示"未记录"；ECG 为空几乎肯定表示"该次住院未做心电图"；Physical Exam.Lungs 为空则可能是抽取失败。把三者都映射为 null 是工程上省事的做法，但会丢失语义。更严谨的做法是在建库时增加一个 _missing_reason 旁注字段，由人工或规则判断缺失类型。这对做"数据质量研究"的项目尤其重要。

§23 评测方法论：怎样才算公平地使用这份数据集

23.1 三类对照实验设计

架构对照：固定模型、固定提示词、固定轮数上限，只改变智能体架构（单智能体 / 多智能体 / 多智能体 + 动态组队），比较 Hit@K 与 Ave-Q。这是论文采用的设计，也是最能说明"架构本身是否有用"的设计。

模型对照：固定架构，换不同 LLM（GPT-4.1、GPT-4o、开源模型），比较同一病例集上的表现。这类对照的噪声最大，因为不同模型的提示词敏感度不同，必须做提示词调优的"公平预算"（例如每个模型都允许调 3 轮提示词）。

数据消融：固定架构与模型，改变输入的完整性——例如去掉 Physical Exam、去掉 Introduction 中的诊断线索、把诊断列表从 ground truth 中移除。这类实验能回答"哪些字段真正有用"，对数据集设计者也有反馈价值。

23.2 必须报告的指标

除了 Hit@5/10、Rec@5/10、Ave-Q，建议补充：路由覆盖率（问题被关键词命中的比例）、兜底率（走全量上下文的比例）、平均上下文 token（成本指标）、问答一致性（同一问题在不同轮次是否给出矛盾回答）、拒答率（回答 “I don’t know” 的比例）。后三项在论文中没有，但它们直接反映病人模拟器的质量，缺了它们，Hit@K 的提升可能只是"作弊更多"的结果。这些指标的计算方式都很简单，但需要在调用层埋点：路由覆盖率 = 命中数 / 总提问数，兜底率 = 走 fallback 的 episode 数 / 总 episode 数，token 成本可按提示词与回答的字符数近似折算。埋点成本很低，缺的往往只是"想到要测"。

23.3 评分者一致性问题

人工评估用 3 名医学生、3 分制，测 Truthfulness 与 Relevance。方法学上必须报告评分者间一致性（Cohen’s κ 或 Krippendorff’s α），否则 1.95 与 1.79 这两个均值无法判断是"真实高"还是"评分宽松"。论文暂未报告，这是一个可改进点。若要复现，建议至少 5 名评分者、双盲（评分者不知道回答来自哪个系统）、并计算一致性系数。

23.4 统计显著性

500 例的 Hit@5 从 58.0 到 63.4，提升 5.4 个百分点。配对样本的 McNemar 检验可以判断这一提升是否显著——粗略估算，若约 20% 的病例出现"单智能体错、多智能体对"、约 15% 出现反向，则差异在 p<0.05 附近。论文是否报告了显著性检验，页面未提；做二次分析时应自行补上。没有显著性检验的 KPI 对比，只能作为趋势参考。

23.5 病例级失败分析的价值

比整体指标更有信息量的是失败案例的分类。建议把失败分成四类：信息未获取（该问的没问）、信息误读（问了但理解错）、推理错误（信息齐了但诊断错）、表达错误（诊断对但排序靠后或表述不在码表内）。四类的占比能直接指出改进方向：若"信息未获取"占主导，应优化问诊策略；若"信息误读"占主导，应优化患者模拟器的回答质量；若"表达错误"占主导，应优化 BioPortal 映射。分类工作建议由两名标注者独立完成并计算一致性，否则"失败原因"本身就成了另一个不可靠的标签——这与评测数据里的抽取字段是同一类方法论问题。

§24 与真实临床教学的映射

24.1 模拟病人（SP）的历史角色

标准化病人（Standardized Patient, SP）是医学教育的成熟工具：由演员按剧本扮演患者，训练医学生的问诊技巧，并由 SP 按评分表反馈。MIMIC-Patient 可以看作 SP 的数字化版本，差别在于：演员可以即兴发挥、能主动补充信息、能表达情绪；而当前的患者模拟器是被动的、只答所问、缺乏情绪表达（论文自己在局限中也提到"患者系统不会主动提供信息"）。这个差异决定了它目前只能用于"信息获取能力"的评测，不能替代沟通技巧训练。

24.2 可能的医学教育用法

第一，作为鉴别诊断训练的自测平台：学生向模拟器提问，系统记录提问序列，教师可以回看"问了什么、漏了什么"。第二，作为问诊完整性检查表的验证工具：把"是否询问过敏史、用药史、家族史、travel history"等条目做成自动化检测，评估学生在每个条目上的覆盖。第三，作为考试题目的自动生成器：从 500 例中抽取病例，随机化症状呈现顺序，生成不同版本的考题。

24.3 与 OSCE 的差距

客观结构化临床考试（OSCE）考的是全流程：接诊、问诊、查体、辅助检查、诊断、沟通、人文关怀。MIMIC-Patient 只覆盖"问诊 + 辅助检查结果获取 + 诊断"三个环节，查体是文本化的（读 Physical Exam 字段），沟通与人文完全缺失。因此它适合做 OSCE 的部分替代或形成性评估，不适合做终结性认证。

24.4 隐私与教学的交叉约束

把真实患者数据用于教学，即便已去标识化，仍需在教学场景下遵守 DUA——例如不得在公开课堂上投屏展示完整 JSON、不得让学生把数据带出受控环境。这一点在医学院的教学部署中常被忽略，因为教学者往往把"内部使用"等同于"无需管控"。更稳妥的做法是把教学数据放在受控虚拟机或校内沙箱中，学生只能通过接口提问、不能下载原始文件；这既满足 DUA，也顺便让学生体验"临床数据不可随意复制"的真实约束。

§25 常见误读辨析

25.1 “500 例就是 MIMIC-III 的 1% 抽样”

不是。先筛后抽，筛选删掉了 95.6% 的住院。正确的说法是"从合格池中抽了 19.3%“，而不是"从全库抽了 0.85% 的代表性样本”。

25.2 “有了 answer_agent 就等于有了病人模拟”

不等于。answer_agent.py 是一个问答接口，不是完整的模拟环境：它没有对话状态、没有主动追问、没有情绪、没有检查下单接口。完整的病人模拟需要在其之上叠加状态管理、检查工具与评测协议。

25.3 “关键词路由是落后的技术”

不一定。在结构化 JSON 上，字典路由的精确率往往高于向量检索（因为字段语义明确、噪声少），且可解释性强。它的问题在召回而非精确。判断技术是否合适要看任务：如果是"从一份结构化病历里找被问到的章节"，字典路由是合理选择；如果是"从海量自由文本里找相关段落"，才需要向量检索。

25.4 “派生字段是 GPT-4 抽的，所以不可信”

过度否定。GPT-4 在结构化抽取任务上的表现通常不差，尤其是模板化的出院小结。问题不在"平均质量"，而在"错误分布"——它会系统性地在某些类型上出错（否定词、否定范围的判定，长句中的主语归属，缩写歧义）。正确做法是抽检估计错误率与错误类型，而不是一刀切不用。另一个常被忽略的点是抽取结果的稳定性：同一份小结换一个温度参数或换一次调用，结果可能不同；若抽取是在固定温度 0 下完成，可复现性较好，否则连"同一份数据的两次加工"都难以对齐，这一点在数据集文档中往往没有交代。

25.5 “PhysioNet 上标了 Credentialed，就说明数据很敏感”

准确说，是说明平台遵循统一治理标准，而不是对这份数据做了单独的敏感性评估。MIMIC 生态下所有派生集都沿用同一门槛，无论其内容是 100 例还是 500 例。敏感性的真实判断应基于内容（是否含自由文本、是否含罕见病组合），而不是访问标签。

25.6 “500 例太少，没有研究价值”

样本量要匹配研究问题。若研究问题是"多智能体架构是否比单智能体更善于收集信息"，500 例足够做出有统计意义的比较（配对设计下效应量 5 个百分点、α=0.05、power=0.8 只需约 200 例）。样本量小影响的是分布推断，不是方法比较。混淆这两者是最常见的误判。

§10 避坑清单：十二个已踩过或已识别的坑

坑 1：DOI 张冠李戴

任务 brief 给出的 DOI 是 10.13026/rees-1092，而 PhysioNet 页面明确登记 v1.0.0 为 10.13026/bzzd-w075，最新版为 10.13026/n19w-aw59。两者完全不是同一字符串，不存在"注册号 vs 展示号"的解释空间。rees-1092 的末尾形似 PhysioNet 近年来为部分条目分配的短随机后缀（如 mimic-iv 的 10.13026/a3wn-hq05 形态），但本文未能定位它对应的具体条目——最可能是其他 MIMIC 衍生数据集或同名项目的 DOI。处置：引用一律用官方 DOI；本文按纪律以官方为准，并将冲突存照于附录 S。

坑 2：把 “ext” 家族当成本体

PhysioNet 上 mimic-iii-ext-* 与 mimic-iii-clinical-database-* 是两类东西：前者是第三方加工出的派生集，后者是 MIT-LCP 维护的原始库。搜索 “MIMIC-III dataset” 时两者会混排出现，若误把 ext 条目当成本体下载，会得不到 26 张关系表，也无法做基于 ITEMID 的深度分析。辨识方法很简单：看 URL 里是否有 -ext-。

坑 3：500 例被当成 MIMIC-III 的代表样本

“从 MIMIC-III 抽样 500 例"这句话容易被读成"500 例代表性样本”，但抽样前已经过四条件过滤，排除了诊断复杂、院内死亡、记录不全的病例。用它算死亡率、平均住院日、共病指数都会系统性偏离全库。任何分布性结论都必须回到 MIMIC-III 全库验证，MIMIC-Patient 只适合做方法验证与评测。

坑 4：会议名双口径

PhysioNet 引文段写作 “AMIA Summits on Translational Science Proceedings, 2026, 408”，而 GitHub README 的 BibTeX 写 journal={AMIA Summits on Translational Science Proceedings}——这一处一致；但 README 页眉的另一处写的是 “Published in AMIA Annual Symposium Proceedings”。AMSUS（Summits）与 AMIA Annual Symposium 是两个不同的会议，论文实际归属应以 PMC 页面与正式卷期为准。本文按 PhysioNet 引文采用 Summits on Translational Science Proceedings，并把 README 的歧义存照。

坑 5：把文件名当 HADM_ID

100173.json 这类数字命名，既可能是 SUBJECT_ID 也可能是 HADM_ID。MIMIC-III 的 SUBJECT_ID 常见于 1-4 万区间，HADM_ID 常见于 10 万-19 万区间，从数值量级看更像 SUBJECT_ID；但页面只说"以唯一标识符命名"，没有给规则。若按 HADM_ID join 而实际是 SUBJECT_ID，会大范围匹配失败或错配。务必实测。

坑 6：字段名含空格导致取数失败

Physical Exam、Chief Complaint、Major Surgical or Invasive Procedure 三个键都带空格。用 data.Physical Exam 会语法错误，用 pandas json_normalize 也会把空格转成奇怪的形式。稳妥写法是统一用字典下标，并在扁平化时显式重命名为下划线形式。

坑 7：只遍历 Patient 子对象

ECG、Radiology、Allergies 等键在页面示例里是顶层键，不在 Patient 之下。写遍历逻辑时若只走 data["Patient"]，报告与主诉会整块丢失，而程序不会报错——这是最隐蔽的一类数据丢失。

坑 8：把三位码匹配当成严格诊断评估

BioPortal 映射后"前三位匹配即算正确"，等于把 428.0 与 428.9 视为同类。这放宽了评测，也让不同论文的数字无法直接比较（有的用完整码、有的用三位码、有的用 CCS 分组）。引用 Hit@K 时必须同时写明匹配粒度。

坑 9：把出院小结字段当成金标准

Physical Exam 等字段由 GPT-4 从出院小结抽取，可能漏项、错位、主语归错（把"否认胸痛"抽成"胸痛"）。拿这些字段做训练标签或评测答案，会引入生成式模型的系统性误差。建议做法：做一次 50 例人工抽检，估计准确率后再决定是否使用；否定词处理是重点抽检对象。

坑 10：忽视 DUA 对第三方 API 的约束

answer_agent.py 的默认路径是把患者数据发给 OpenAI。这在 DUA 视角下是"向第三方披露认证数据"，只有在服务商提供不训练、不留存承诺时才成立。个人开发者用普通 API Key 直接跑，合规风险由自己承担；机构使用者应走企业版或本地模型。

坑 11：把单轮脚本误当多轮对话

answer_agent.py 每次调用独立读文件、独立作答，不保留对话历史。单独用它做多轮测试，会出现"上一轮说没有高血压、这一轮说有"的矛盾。多轮状态由上层医生脚本管理，理解这一点才能正确归因。

坑 12：忽略单位与去标识化年龄

MIMIC 的年龄是偏移量，89 岁以上统一处理；生命体征与化验的单位可能与直觉不同。直接做"年龄-死亡率"回归或"血糖阈值"规则，会得到看似合理实则错误的结论。所有数值字段用前都要过一遍单位的核对清单。

§11 生态定位与库内互链

11.1 在 MIMIC 家族中的位置

MIMIC 已经长成一个生态：MIMIC-III（2001-2012，ICU+院内）、MIMIC-III Clinical Database Demo（100 例公开）、MIMIC-III Waveform（波形）、MIMIC-IV（2008-2022，模块化重构）、MIMIC-IV-ED（急诊）、MIMIC-CXR（胸片）、MIMIC-IV-Note（自由文本）。这一生态的共同底座是 BIDMC 的单中心数据与 PhysioNet 的认证访问体系。

MIMIC-Patient 的独特性在于它是面向 LLM 智能体的视图：其他派生集多在"更细的模态"（波形、影像、笔记）上做文章，而它把已有模态重新组织成一次对话所需的形状。这也决定了它与本体条目的关系不是"上游/下游数据"，而是"同一批病人的两种面向"——面向 SQL 的分析者用本体，面向 prompt 的智能体用这份 JSON。

11.2 库内可互链条目

库内条目	rid	与本条目的关系
mimiciii-legacy	590	MIMIC-III 本体档案，认证流程、26 张表结构以其为准
mimic-iii	106	同源本体条目（另一版本档案）
mimiciv / mimic-iv-clinical-database	592 / 4	新一代 MIMIC，时间跨度与模块结构对比参照
synthetic-mimic-iii-health-gym	597	合成版 MIMIC 智能体环境，与本条目构成"真实 vs 合成"对照
aipatient	550	模拟病人知识图谱，病人模拟器的另一条技术路线
medagentbench	1064	虚拟 EHR 智能体基准，评测范式可对标
emrqa / ehrxqa	139 / 646	EHR 问答数据集，抽取式 vs 生成式对照
ehrsql	713	Text-to-SQL 路线，与本条目的关键词路由形成方法对照
mediqa	220	医患对话摘要，患者侧语言数据参照
archehr-qa / ehr-reasoncon	1000 / 1007	2025-2026 新出的 EHR 推理评测

11.3 与同业智能体基准的方法对比

若把"用 LLM 做诊断"的评测路线排一排，会看到三种范式：静态题库（MedQA 类，一次性给全信息）、数据库查询（EHRSQL、MedAgentBench，测的是工具调用与 SQL 生成）、交互模拟（本条目与 MEDIQ，测的是问询策略）。三者难度递增，评测噪声也递增——静态题库可完全复现，交互模拟的结果随模型、轮数上限、路由词典而变。选择哪一条，取决于你要证明的是"模型知不知道"还是"模型会不会问"。

11.4 对下游工作的意义

这份数据最可能被用在三个方向：一是作为病人模拟器的参考实现，研究者可以照着关键词路由的结构做自己的版本；二是作为多轮诊断评测的固定病例集，500 例规模适中，比 MIMIC-III 全库便宜得多；三是作为EHR 结构化的样本工程案例，研究"哪些字段该规则抽取、哪些该交给 LLM"。三个方向都需要在论文里显式声明选择偏倚与派生字段的不确定性。

§12 质量评估：DAIMS 打分与解读

DAIMS（Data and AI Maturity/Quality Scoring）在本库中用于横向比较数据集的 AI 就绪度。以下六维按 1-5 分评分，依据均来自 PhysioNet 页面与论文，未获取的信息按保守口径扣分。

维度	评分	依据
文档完备度	3	页面有字段级说明与获取指引，但缺完整 Schema、体量、文件清单、answer_agent.py 的实现细节
机器可读性	4	原生 JSON、字段命名语义化，无需额外解析器；扣分项为字段名含空格、板块层级不统一
溯源可追	4	每条记录可回溯到 MIMIC-III 的 SUBJECT_ID/HADM_ID，DOI 与版本明确
合规与治理	4	沿用母库的 DUA/CITI 体系，治理成熟；扣分项为派生数据无独立再识别风险评估说明
代表性	2	四条件筛选 + 单中心 + 仅 500 例，分布严重偏离母库
可复现性	3	数据固定但派生字段依赖 GPT-4 抽取，抽取日志未公开；评测结果依赖模型快照
加权合计	3.3 / 5	结构工程做得好，样本代表性是硬伤

解读要点：3.3 不是"中等偏差"的评价，而是"用途受限"的信号。它在"做智能体评测环境"这个用途上可以打 4 分以上，但在"做临床流行病学研究"上接近 1 分。DAIMS 的分维度设计正是为了避免单一总分掩盖用途差异——读者应看分项，而不是只看合计。

§13 局限性与批判性评估

13.1 方法层面

选择偏倚是首要问题。四条件中的"诊断少于 5 条"直接删掉了复杂共病病例，而复杂共病恰恰是临床诊断中最考验医生的场景。这意味着在这份数据上评测出的"诊断能力"，更接近"单病种识别能力"。作者在 PhysioNet 页面也明确承认这是"选择性子集，非代表性样本"。

派生字段的不确定性是第二问题。GPT-4 抽取没有公开 prompt、版本、温度、抽检报告。对一份以"评测"为用途的数据集而言，标签本身的不确定性会直接传导到评测结论。理想做法是发布抽取日志与抽检一致率，目前没有。

评测指标的口径宽松是第三问题。三位码匹配、每例诊断数少于 5、预测空间 1000+ 组，三者叠加使得 Hit@K 的绝对值偏高，跨论文比较须谨慎。

13.2 工程层面

answer_agent.py 的词典路由是原型级实现，覆盖率与鲁棒性都未量化。它更像一个"参考设计"而非"生产组件"。真正做病人模拟器时，需要补上对话状态管理、路由失败的可观测性、以及多轮一致性约束（例如已答过的内容不能反口）。

13.3 治理层面

派生数据集往往给人"已经脱敏过一遍"的错觉。实际上 JSON 化并不改变数据的敏感等级，反而因为把分散字段聚合成"一个人的完整画像"，在某些维度上提高了再识别风险（例如罕见病 + 特定年龄 + 特定手术组合）。这一点在页面上没有专门的再识别风险评估说明，使用者在做二次发布或分享截图时应当格外小心。

13.4 应该在什么场景下用它

适合：验证多轮问诊框架、比较不同智能体架构的信息获取效率、教学演示"受控病人模拟"的设计。不适合：估计疾病流行率、训练通用临床模型、做跨机构外推研究、做影像-文本多模态研究（无原始影像）。

再补一条常被忽略的适用场景：检索增强生成（RAG）系统的回归测试。这类系统的失败往往出现在"检索漏召回"与"生成幻觉"两类，而 MIMIC-Patient 的章节化结构恰好可以把两类错误分开统计（路由命中与否对应检索层，回答与字段是否一致对应生成层）。把它当作一个小型的、可人工核对的回归集，比用公开的通用问答集更贴近临床语境；但前提是团队已经持有 DUA 授权，并且测试结果不对外公开原始样本。若要做成可重复的回归套件，还需要固定三样东西：问题集（建议 50-100 条，覆盖主诉、用药、过敏、化验、报告五类）、期望章节（每条问题对应应命中的 JSON 章节）、容差规则（哪些表述算等价）。三样固定之后，每次改动路由词典或换模型，都能在同一把尺子上量出变化。

§14 总结

14.1 三句话

1. MIMIC-Patient 是把 MIMIC-III 的一次住院压成一份 JSON 的结构化视图，500 例，来自 2,597 例合格池。
2. 它的核心贡献不是数据量，而是结构 + 一个受控的病人模拟器，让"多轮问诊"成为可评测的任务。
3. 它的限制同样明确：选择偏倚、单中心、派生字段由 LLM 生成、获取门槛不降。

14.2 适合谁

做医学 LLM 智能体、临床问答系统、EHR 结构化管线的研究者；需要一份"小而完整"的评测集，又已有 MIMIC 认证的团队。

14.3 不适合谁

没有 PhysioNet 认证、希望零门槛快速试用的开发者（请改用 MIMIC-III Demo 或合成数据）；需要大样本统计的流行病学研究者；需要原始影像/波形的多模态团队。

14.4 30 秒决策卡

你的需求	建议
想看 JSON 长什么样	读 GitHub README + 本条目 §5，或用 Demo 数据自拼
想做多轮诊断评测	直接申请，500 例足够跑通
想训练临床 LLM	样本太小，考虑 MIMIC-IV 全库
想做流行病统计	不合适，回 MIMIC-III 全库
想对比 EHRSQL/MedAgentBench	任务范式不同，只能做定性对比

§26 与原始 MIMIC-III 表的字段映射全解

26.1 为什么需要映射表

JSON 是"再设计"的视图，字段名与原始表不对应。当 JSON 里某个值看起来可疑时，唯一能查证的方法就是回到原始表。下表是本文据 MIMIC-III 公开文档整理的映射参考（左列为 JSON 板块，右列为原始表与字段），供定位使用。注意：MIMIC-III 的表结构以库内 mimiciii-legacy（rid 590）条目与官方文档为准，本文不重复其完整字段说明。

JSON 板块	原始表	关键字段	映射要点
Admission_info	ADMISSIONS	SUBJECT_ID, HADM_ID, ADMISSION_TYPE, DIAGNOSIS, ADMITTIME, DISCHTIME, HOSPITAL_EXPIRE_FLAG	类型与时间戳一般不进 JSON，只留标识与入院诊断
Demographics	PATIENTS	GENDER, DOB, DOD, DOD_HOSP, EXPIRE_FLAG	年龄需由 ADMITTIME 与 DOB 推算，89 岁以上特殊处理
Diagnoses	DIAGNOSES_ICD + D_ICD_DIAGNOSES	SUBJECT_ID, HADM_ID, SEQ_NUM, ICD9_CODE, LONG_TITLE	SEQ_NUM 表示主次，JSON 是否保留需实测
Prescription	PRESCRIPTIONS	DRUG, DOSE_VAL_RX, DOSE_UNIT_RX, ROUTE, STARTDATE, ENDDATE	药名为自由文本，未归一时同一药有多种写法
Chart Data（生命体征）	CHARTEVENTS + D_ITEMS	ITEMID, CHARTTIME, VALUENUM, VALUEUOM	高频，JSON 里大概率被筛选或聚合
Lab Data（化验）	LABEVENTS + D_LABITEMS	ITEMID, CHARTTIME, VALUENUM, VALUEUOM, FLAG	FLAG 标记异常，是否保留需实测
操作	PROCEDURES_ICD + D_ICD_PROCEDURES	SEQ_NUM, ICD9_CODE	与 Major Surgical 字段不同源，后者来自小结
ECG / Radiology	NOTEEVENTS	CATEGORY, TEXT, CHARTTIME	类别名依 MIMIC 版本的 CATEGORY 取值而定
Introduction 等	NOTEEVENTS（Discharge summary）	TEXT	经 GPT-4 抽取，原文不在 JSON 中

26.2 三个映射陷阱

第一，ITEMID 到名称的翻译不可逆。JSON 若已把 ITEMID=211 译成"心率"，你无法反推出原始条目，也就无法判断这个"心率"是监护仪自动采集还是护士手工录入——两者在 CHARTEVENTS 中是不同的 ITEMID，质量也不同（自动采集更密集但有伪影，手工录入更稀疏但经过确认）。类似的还有体温的测量部位（腋下/口腔/直肠）、血压的测量方式（有创/无创），这些信息一旦丢失，数值本身的可比性就打了折扣，做趋势分析时尤其要注意。

第二，诊断表的 SEQ_NUM 语义。MIMIC-III 中 SEQ_NUM=1 通常表示主诊断，其后为次诊断，但这个约定并非绝对（部分病例的主诊断排序不规范）。若 JSON 未保留顺序，做"主诊断预测"研究就失去了标签来源，只能退化为"诊断集合预测"。

第三，时间戳的丢失。JSON 中是否保留 CHARTTIME/STARTDATE 决定了能否做时序分析。若只保留值不保留时间，这份数据就只能做"静态快照"问答，无法支持"血压在过去 6 小时如何变化"这类问题——这对多轮问诊是一个实质限制，因为医生问诊时常需要"动态趋势"。

26.3 与 MIMIC-IV 的字段形态差异

若读者同时使用 MIMIC-IV，要注意字段命名体系不同：MIMIC-IV 用 subject_id/hadm_id（全小写）与 hosp/icu 模块划分，检验项概念表为 d_labitems，且新增 omr（门诊生命体征）等模块。MIMIC-Patient 用的是 MIMIC-III 体系（驼峰 SUBJECT_ID），两者不能直接 join，需通过 subject_id 做映射（同一个体在两库中的编号可能不同，需借助官方提供的交叉表或按人口学特征对齐，后者不可靠）。

§27 数据质量的经验性判断

27.1 五类可见缺陷

在没有原始文件的情况下，仅凭公开文档就能预判五类缺陷。字符编码：病历文本含 µ、°、±、→ 等符号，若抽取管线未统一 UTF-8，可能出现乱码。否定词：出院小结的查体段落大量使用"未见"“否认”“阴性”，GPT-4 抽取时容易把"否认胸痛"抽成"胸痛"，这是否定范围判定的经典难题。章节错位：正则识别 Findings/Impression 时，若报告使用 FINDINGS:（大写冒号）或 Findings:（小写），匹配规则需覆盖变体，否则切分失败导致整个报告塞进一个字段。单位混用：同一化验项在不同年代可能用不同单位（如血糖 mg/dL 与 mmol/L 在 BIDMC 系统中是否统一，需核对）。重复记录：PRESCRIPTIONS 中同一药物的多次调整会逐行记录，JSON 若未去重，处方列表会显得冗长。

27.2 质量抽检的最小方案

不必做全量人工审，抽 30 例即可估计主要缺陷率：每例检查（a）JSON 能否完整解析；（b）Physical Exam 十个亚项是否齐全；（c）Diagnoses 条数是否与原始表一致；（d）Prescription 是否有明显重复；（e）ECG/Radiology 是否有明显错位。五项各记"通过/不通过"，统计不通过率。若某一项不通过率超过 20%，说明该类字段不宜直接使用，需要人工修正或退回原始表。

27.3 质量与用途的匹配

需要强调，"质量差"是相对用途而言的。同样一个 Physical Exam.Lungs 字段，若用于"检索式问答"（只需判断有无湿啰音），抽取错误的代价小；若用于"训练查体描述生成模型"，错误会被放大。因此在任何使用前，先明确用途对字段精度的容忍度，再决定是否抽检、抽检多少。这是数据工程的基本功，也是对派生数据集最负责任的使用方式。

27.4 缺陷的可报告性

DUA 允许在论文中报告数据质量统计（计数、比例），但不允许公开原始样本。因此团队可以把抽检结果写进方法学部分，例如"在 30 例抽检中，处方字段重复率 18%，查体亚项缺失率 7%"，这既满足学术透明，也不违反协议。建议把抽检脚本与结果一并存档，供审稿人质询时提供（在受控环境下）。

§28 版本演进预测与风险

28.1 可能的下一个版本

从同类派生集的历史看，v1.x 更新通常包含三类改动：修正字段命名（把带空格的键改成下划线）、补充缺失病例或替换抽取失败的样本、更新 answer_agent.py 的模型默认值与字典。其中字段重命名是破坏性改动，会让依赖旧键名的代码失效。因此使用前应把键名访问集中在一个适配层，而不是散落在各处。

28.2 模型依赖的风险

answer_agent.py 默认调用 GPT-4.1/GPT-4o，若 OpenAI 下线旧模型（历史上多次发生），脚本会直接报错。稳健做法是把模型名做成配置项，并在日志中记录实际使用的模型快照。此外，不同模型的提示词遵循度差异很大，"只答所问"这条约束在弱模型上可能失效，导致评测结果不可比。

28.3 上游母库的变化风险

MIMIC-III 本身已进入维护期（MIMIC-IV 是主力），v1.4 之后是否还会发布新版本存疑。若母库停止更新，MIMIC-Patient 的溯源锚点保持稳定，这对长期引用是好事。但若 PhysioNet 调整访问政策（例如统一改为单一 DUA），获取流程可能变化，需关注平台公告。

28.4 生态位被替代的风险

2026 年之后，若出现规模更大、同样面向智能体评测的派生集（例如基于 MIMIC-IV 的同类工作），MIMIC-Patient 的相对价值会下降。但它作为"首个明确以多轮问诊为目标的 MIMIC 派生集"，在方法学引用上仍有先发优势。判断一个数据集是否会过时，看的不是规模，而是它定义的任务是否成为标准——从这个角度看，它已经完成了自己的历史使命。

§29 读者问题集：二十个进阶问答

1. 为什么不用 MIMIC-IV 而用 MIMIC-III？
论文写作时 MIMIC-IV 已存在，但 MIMIC-III 的表结构更紧凑（26 张表 vs 模块化的数十张），做"压成一份 JSON"的工程量更小。此外 MIMIC-III 的文献积累更厚，诊断标签（ICD-9）在 NLP 研究中更常见。

2. 500 例里有没有儿科病例？
筛选条件只排除"新生儿"，儿童病例可能保留。使用时应按年龄字段筛查，若研究限定成人，需自行过滤。

3. 为什么诊断要限制少于 5 条？
为了让"诊断目标"可界定。若一个病例有 15 条诊断，评测"是否想到正确诊断"就没有明确答案——哪个才是"正确"的？限制条数等于人为定义了评测边界。

4. JSON 里有护理记录吗？
页面未列出护理记录字段。MIMIC-III 的护理记录主要在 CHARTEVENTS 与 NOTEEVENTS 的 Nursing 类别中，是否被纳入未知。

5. 能否用它做再入院预测？
技术上可以按 patient_id 关联多次入院，但 500 例中同一患者多次入院的比例很低，正样本不足，不适合做预测建模。

6. Introduction 里会不会泄露诊断？
很可能。出院小结首段常直接写诊断，使用前建议做诊断词剥离，或用规则检测并遮罩。

7. 为什么人工评估只用 100 例？
成本。每例要 3 名评分者独立打分，100 例已是 300 次评分，人工成本可观。100 例的均值标准误约 0.1（3 分制），对"接近满分"的结论够用，对细粒度比较不够。

8. 报告里的 DUA 约束具体卡在哪一步？
卡在"向第三方传输"。本地推理、机构内网部署都不涉及传输；调用外部 API 才涉及，需确认服务商的留存与训练政策。

9. 可以用合成数据替代吗？
可以用 synthetic-mimic-iii-health-gym（rid 597）类合成数据做开发调试，但评测结论必须回到真实数据，因为合成数据的分布是人为设定的，无法反映真实临床的不确定性。

10. 数据里有没有影像的原始 DICOM？
没有。只有报告文本。需要影像请用 MIMIC-CXR 系列（rid 16/617 等）。

11. 时间戳保留到什么粒度？
页面未说明。MIMIC 原始数据有精确到分钟的时间戳，但去标识化会做日期偏移。JSON 是否保留时间需实测。

12. 为什么叫"Structured Per-Patient"而不是"Per-Admission"？
官方标题用 patient，但正文明确说是"每次住院"。这是命名与实现的轻微不一致，引用时应以"per admission"的实际粒度描述。

13. 能用于商业产品吗？
不能直接用于。DUA 限定研究用途，商业使用需与数据托管方另行协议，且受 HIPAA 相关约束。

14. 能否公开发布基于它的微调模型？
模型权重若可能记忆训练数据，存在再识别风险，发布前需做成员推断测试与伦理审查。多数机构会要求不公开权重或仅在受控环境分发。

15. 为什么论文说"首个动态临床决策基准"，而 MEDIQ 更早？
作者的主张是"首个以多智能体动态组队 + 患者端信息受控为特征的基准"，与 MEDIQ（更早的交互式模拟环境）在"动态"的定义上不同。这类"首个"声明通常带限定词，引用时应完整转述限定范围。

16. 数据里有没有 ICU 与普通病房的区分？
MIMIC-III 含 ICU 与院内数据，JSON 是否标记科室未知。若研究限定 ICU，需按 ICUSTAYS 关联判断，而 JSON 可能未保留该关联。

17. 正则分词对中文提问有效吗？
基本无效。英文关键词字典与中文问题没有交集，会全部走兜底。中文场景必须重写路由层。

18. 能否把这个 JSON 转成 FHIR？
可以，但要做大量映射（诊断→Condition、处方→MedicationRequest、化验→Observation），且 FHIR 的资源引用模型与单文件 JSON 不同，属于一次性工程，不是开箱可用。

19. 数据集有没有数据卡（datasheet）？
PhysioNet 页面本身相当于一份简版数据卡（含动机、构成、筛选、局限），但没有采用 Gebru 等人的标准 datasheet 模板，也未提供 Croissant 元数据。

20. 引用时最容易漏什么？
最容易漏母库引用。数据集 cite 只覆盖派生层，方法论根基是 MIMIC-III 原始论文，两者都要引。

§30 结语与方法论沉淀

30.1 这份数据集教给我们的事

第一件事是结构即产品。同一批病人，换一种组织结构，就从"需要写 SQL 的分析素材"变成"可以直接对话的评测环境"。数据的价值不完全由内容决定，也由形态决定。第二件事是克制即能力。病人模拟器的核心不是"知道多少"，而是"知道什么时候不说"。第三件事是筛选即定义。四条件筛选不只是清洗，它在定义这个数据集能回答什么问题、不能回答什么问题。第四件事是门槛不随规模降。500 例的派生集仍要走完整认证，这说明数据治理的严格程度取决于内容而非体量，后来的派生者也很难绕开这道门。

30.2 对 AI-Ready 数据集建设的三条启示

其一，派生集要有明确的"用途声明"。MIMIC-Patient 在页面上写清了适合做问答评测、不适合做分布推断，这种自限式声明值得学习。其二，派生集要带"可运行的最小示例"。answer_agent.py 虽小，但它把"数据怎么用"变成了可执行代码，比一千字文档有效。其三，派生集要暴露"派生过程的不确定性"。当前版本没有公开 GPT-4 抽取的日志与抽检结果，这是一个遗憾；下一代派生集若能把抽取置信度一并输出，价值会更高。

30.3 一句话定位

MIMIC-Patient 不是更大的 MIMIC，而是更像医生的 MIMIC：它把"病历"变成"病人"，把"检索"变成"问诊"，把"准确率"变成"问诊质量"。理解了这一点，也就理解了这个条目为什么值得单独写。

如果把这句话再展开一层：它把"数据工程"问题（如何把 26 张表拼成一份可读的病例）与"提示工程"问题（如何让模型只回答被问到的内容）合并成一个数据集产品，这种合并本身就是一种方法论主张——数据不应只是模型训练时的燃料，也可以是模型评测时的环境。这个主张在 2026 年的医疗 AI 语境里正当其时，因为静态基准已接近饱和，能力差异越来越体现在交互过程中而非单点判断上。

但也正因为它是"环境"，它的质量评价标准与传统数据集不同：传统数据集看标注准确率，环境则看"交互的真实性"与"回答的受控性"。前者由数据决定，后者由代码决定，两者混在一起时，使用者很难分清某次评测失败到底是数据的问题还是实现的问题。本文在 §5、§7、§23 反复强调分解指标，正是为了把这团混乱拆开——这是阅读和使用这类"数据集 + 脚本"复合产品的核心习惯。

§31 对 MIMIC-III 母库的技术回顾（仅为理解派生集服务）

31.1 二十六张表的三层结构

MIMIC-III v1.4 的表可以分成三层理解，这个分层对读 JSON 很关键。患者层：PATIENTS（一人一行，性别、出生日期、死亡日期）。住院层：ADMISSIONS（一次住院一行，入院与出院时间、入院类型、入院诊断、是否院内死亡），这一次住院是 MIMIC-Patient 的抽样单位，也是 JSON 的主键来源。事件层：CHARTEVENTS（床旁记录）、LABEVENTS（化验）、INPUTEVENTS/OUTPUTEVENTS（出入量）、PRESCRIPTIONS（处方）、PROCEDURES_ICD（操作）、DIAGNOSES_ICD（诊断）、NOTEEVENTS（文本），以 SUBJECT_ID + HADM_ID 为外键挂到住院层。

JSON 化本质上就是"把一次住院的所有事件层行，按语义折叠进一个对象"。折叠过程中一定会做取舍：全量的 CHARTEVENTS 动辄数万行，不可能原样放进 JSON，因此必然做筛选（如只保留入院首日或每日极值）或聚合（如取均值/最值）。哪些事件被保留、如何聚合，直接决定 JSON 能回答什么问题，而这部分细节恰恰是公开文档最薄弱的地方。使用者在做时序相关研究时，必须先摸清这一点。

31.2 字典表的作用

MIMIC-III 的 D_ITEMS（约 1,600 个条目）、D_LABITEMS（约 750 个检验项）、D_ICD_DIAGNOSES（约 1.4 万个 ICD-9 码）、D_ICD_PROCEDURES 是全部翻译层。JSON 若已完成翻译，使用者可以跳过字典；但翻译是不可逆的有损操作，一旦 ITEMID 被丢弃，就无法再做条目级的精细筛选（例如只取"有创动脉血压"而非"无创袖带血压"）。这是使用派生集时最应该权衡的一个点：便利性与可分析粒度之间，天然存在取舍。一个折中方案是在 JSON 中保留 ITEMID 作为旁注字段（value 与 itemid 并存），既方便人读，也支持机器精筛；若数据集未这样做，使用者在做精细分析时就只能回到原始表，用 HADM_ID 做一次反查——这一步虽麻烦，但完全可行，前提是保留了住院号。

31.3 为什么 MIMIC-III 的"再发布"是个大工程

同一批数据被反复派生的原因在于：每次派生都针对一个特定用途做优化。MIMIC-CXR 优化了影像-报告配对，MIMIC-IV-Note 优化了文本，MIMIC-Patient 优化了对话形态。没有一个派生集能同时满足所有用途，因为不同用途对"保留什么、丢掉什么"的要求互相冲突。理解了这一点，就不会再问"为什么不直接用官方的一个通用版本"——因为那样的版本无法同时做到轻量与完整。

§32 统计口径的细节讨论

32.1 住院数与患者数

MIMIC-III 常被引用为"58,976 次住院、40,000+ 患者"。这两个数字的口径是：住院数对应 ADMISSIONS 行数，患者数对应 PATIENTS 行数（约 4.6 万）。因为部分患者多次入院，住院数大于患者数。写文章时若混用（如"4 万次住院"），会被审稿人抓住，这是引用 MIMIC 时的高频错误。

32.2 2,597 的占比

2,597 / 58,976 = 4.403%。这个占比说明筛选很严格：近 96% 的住院被排除。若读者想估计"这份数据覆盖了 MIMIC 的多少临床多样性"，4.4% 是一个直观的量级参照。但要注意，这个占比不能反推"每类疾病的覆盖率"——筛选与疾病种类并非均匀分布，某些病种（如单一诊断的择期手术）覆盖率远高于 4.4%，某些病种（如多器官衰竭）覆盖率接近 0。

32.3 500/2,597 的抽样误差

500 例对 2,597 例的抽样，比例 19.26%，属于较大抽样比（接近 1/5），因此有限总体校正因子 √((N-n)/(N-1)) = √((2597-500)/2596) ≈ 0.898，标准误比无限总体假设小约 10%。做精细统计时应使用校正公式，而不是直接用 √(p(1-p)/n)。

32.4 与"99 例"类小样本的区别

MIMIC-III Demo 是 100 例，常用于教学；MIMIC-Patient 是 500 次住院。两者量级差 5 倍，但性质差异更大：Demo 是随机抽患者，保留全部表；MIMIC-Patient 是筛选后抽住院，且重组织成 JSON。因此 Demo 适合"学习 MIMIC 结构"，MIMIC-Patient 适合"直接做问答评测"，二者不能互换。

32.5 体量的间接估算

若按单次住院的平均文本量估算：生命体征按每 4 小时记录一次、住院 5 天约 30 组 × 10 项 = 300 个数值；化验按每天 2 次、每次 20 项、5 天 = 200 个数值；处方 10-30 条；报告 2-5 份；出院小结 2-5 KB。合计单份 JSON 文本大概 20-80 KB，500 份约 10-40 MB，加格式化与冗余可能到 100 MB 量级。这只是量级估算，不可作为引用数据，页面未披露真实值。

§33 与 DynamiCare 论文的细读

33.1 论文的贡献切分

论文的贡献可拆成三块：数据集（MIMIC-Patient）、框架（多智能体动态组队）、评测（Hit@K 与人工评估）。三块的成熟度不同：数据集的工程量大但方法简单；框架是主要创新点；评测设计完整但统计严谨性不足。读这篇论文时，应把注意力放在"框架如何决定谁提问、何时换人"上，而不是只看 Hit@5 的数字。

33.2 动态组队机制

“动态"体现在两点：一是专科医生的加入与退出由当前假设驱动（例如怀疑神经系统疾病时加入神经科），二是提问策略随信息积累调整。这一机制的意义在于模拟真实的多学科会诊（MDT）——真实临床中也不是一位医生问到底，而是随病情判断引入不同专科。把它形式化为"可计算的组队策略”，是论文最有价值的部分。

33.3 与单智能体对照的意义

单智能体对照组的意义不仅是"证明多智能体更好"，更是"证明提升来自架构而非模型"。因为两者用同一个 GPT-4.1，唯一差别是架构，所以 5.4 个百分点的 Hit@5 提升（58.0→63.4）可以归因于组队与提问策略。这是标准消融思路，值得借鉴。

33.4 论文未回答的问题

至少四个问题没有明确答案：兜底触发率是多少？多轮对话的一致性如何保证？人工评估的评分者一致性系数是多少？Hit@K 的差异是否统计显著？这四个问题恰好是后续研究可以填补的空白，也是审稿人会追问的点。

33.5 与 MEDIQ 的关系

MEDIQ 是更早的交互式医疗决策环境，DynamiCare 在它之上做对比实验（iMedQA 92.0 vs 67.0，iCraftMD 96.4 vs 72.1）。这些数字的意义是"在 MEDIQ 的既有场景里，动态组队也带来提升"，属于外部效度验证。但两者数据源不同（MEDIQ 自有场景 vs MIMIC-Patient），不能直接合并解读。

§34 数据集卡（Datasheet 风格）

34.1 动机

为 LLM 智能体提供"病人端"的可交互环境，支持多轮问诊与诊断推理评测；同时把 MIMIC-III 的关系型数据压缩为便于提示工程使用的结构化 JSON。

34.2 构成

500 个 JSON，每次住院一个；来源为 MIMIC-III v1.4；四条件筛选（诊断 <5 条、非新生儿、院内存活、数据完整含出院小结）；从 2,597 例合格池随机无放回抽 500。

34.3 采集与处理

原始数据由 BIDMC 在常规诊疗中产生，MIMIC 团队去标识化；派生处理由 Penn 团队完成：结构化表按住院合并、半结构化报告正则切分、出院小结用 GPT-4 抽取。

34.4 用途与禁止用途

适：多轮诊断评测、病人模拟器研究、EHR 结构化管线验证。
禁：临床决策支持部署、流行病学分布推断、任何形式的再识别或数据转售。

34.5 分发与维护

PhysioNet 托管，Credentialed Access，版本 1.0.0（2026-09-11），版本无关 DOI 追踪最新版；维护者为作者团队，更新节奏未公开。

34.6 伦理审查

页面对外声明：全部数据已完全去标识化，未引入额外可识别信息，未采集新患者数据，LLM 处理采用零留存配置。未披露独立伦理委员会审查编号。

§35 术语补充与易混淆概念

35.1 三组容易混的"数据集"

原始库 vs 派生集：MIMIC-III 是原始库，MIMIC-Patient 是派生集。公开版 vs 认证版：Demo 是公开版，正式版需认证。单一模态 vs 多模态扩展：MIMIC-CXR 是影像扩展，MIMIC-Patient 是结构重组。三组区分交叉使用，检索时最容易出错的就是"以为 demo 就是小号正式版"。

35.2 "结构化"的两层含义

本条目中的"结构化"指两层：一是数据格式结构化（JSON 而非 CSV 长表），二是内容结构化（自由文本经抽取变成字段）。前者是格式问题，后者是语义问题。MIMIC-Patient 同时做了这两层，因此在讨论"结构化程度"时要指明是哪一层。

35.3 病人模拟器的三种实现

规则驱动（关键词路由 + 模板）、检索驱动（RAG）、生成驱动（全量上下文）。三者的差别在"信息边界控制"与"回答自然度"的权衡：规则驱动最克制但最生硬，生成驱动最自然但最容易泄底，检索驱动居中。MIMIC-Patient 选的是规则驱动 + 生成驱动混合，这是当前工程条件下较务实的选择。

35.4 "AI-Ready"在本条目中的具体所指

本库的"AI-Ready"不是指"可以直接训练模型"，而是指"数据形态对 AI 工作流友好"。具体到本条目：JSON 免解析、字段语义化、配套可运行脚本、有明确的使用边界说明。反例是那些只有 PDF 说明、数据散落在数十个 CSV 中、无示例代码的数据集。

§36 读者决策树

若你不确定要不要用这份数据，可以按以下顺序自问：

第一步，你有 PhysioNet 认证吗？没有的话，先评估获取周期（CITI 培训 + DUA 审批），通常以周计；若只需要短期验证，改用 Demo 或合成数据。

第二步，你要解决的是一道题还是一段对话？如果是一道题（给定病例，问诊断），用静态题库更省事；如果是"模型如何逐步获取信息"，才需要这份数据。

第三步，你关心的是分布还是方法？关心分布，回 MIMIC-III 全库；关心方法（架构、提示、组队策略），这份数据合适。

第四步，你能接受派生字段的不确定性吗？能，就用全部字段；不能，就只用结构化板块，避开 GPT-4 抽取的字段。

第五步，你的评测要公开复现吗？要，就必须固定模型快照并记录调用日志；不要，也要记录，因为你自己三个月后也会忘。

§37 结语补充：这份数据最容易被用错的地方

最容易的误用，是把"病人回答得流畅"当成"数据质量高"。流畅度来自 LLM 的语言能力，不来自数据的准确性。第二容易的误用，是把"Hit@5 63.4"当成"模型诊断准确率 63.4%"——前者是清单排序指标，后者是单一诊断判断，两者不可互换。第三容易的误用，是把 500 例的抽检结论推广到 MIMIC 全库。这三条误用都不涉及技术门槛，只涉及概念清晰度，但恰恰是论文评审与项目验收时最常被追问的点。

§38 条目使用说明

本条目面向三类读者：想快速了解数据集的研究者（读 §1、INFOBOX）、准备使用的工程师（读 §5-§9、附录 B）、做方法学综述的学者（读 §10-§25）。所有"未披露""待实测"的标注都是诚实的缺口标记，不是写作疏漏；凡有推断，均已在段落内声明。若读者手上有获批数据并发现了本文推断有误之处，应以实际文件为准，并建议向作者反馈，以便下一版页面补充 Schema 说明。

§39 案例库：五类典型病例在 JSON 中的样子

本节用五个"典型形态"说明不同病例在 JSON 里长什么样。这些例子是基于筛选条件的合成描述，不是从数据中抄录的真实记录，用于帮助读者建立字段预期。

39.1 单病种择期手术型

这类病例最简单：入院诊断一句话（如"胆囊结石伴慢性胆囊炎"），诊断列表 2-3 条，手术字段有明确记录，术后恢复顺利，出院小结结构完整。在 JSON 中，Major Surgical or Invasive Procedure 只有一条，Prescription 以围手术期用药为主（抗生素、镇痛），Physical Exam 各亚项齐全且多为阴性。审核判读：这类病例对智能体几乎没有挑战，医生问两三个问题就能猜到答案，容易把 Hit@K 抬高。

39.2 内科急性加重型

如"慢性阻塞性肺疾病急性加重"：主诉是气促加重，查体有哮鸣音，化验有血气异常，处方含支气管扩张剂与激素。这类病例的难点在"鉴别"——COPD 急性加重、心衰、肺炎三者的主诉高度相似，需要靠查体细节（哮鸣音 vs 湿啰音）与化验（BNP vs 白细胞）区分。JSON 中 Physical Exam.Lungs 与 Radiology 是关键字段，若这些字段抽取质量差，评测结果会显著下滑。

39.3 症状不典型型

如老年患者的"乏力、食欲下降"，实际诊断是隐匿性感染。这类病例在数据集中占比不高（因为筛选偏向"记录完整"），但对评测最有价值：它要求智能体追问细节（发热史、travel history、用药史），而不是从主诉直接跳到结论。若 500 例中此类病例极少，评测就测不出"追问能力"的差异。

39.4 多慢病稳定型

如"2 型糖尿病 + 高血压 + 高脂血症"的常规复诊入院，诊断为 3 条，无急性事件。这类病例的 JSON 中 Prescription 最长（多种长期用药），而 Physical Exam 多为"未见异常"。它们对问诊的信息获取挑战不大，但适合测试"用药核对"类问题（是否询问依从性、是否发现药物相互作用）。

39.5 术后并发症型

如"阑尾切除术后腹腔感染"：主诉为术后腹痛发热，查体有腹膜刺激征，化验白细胞升高，影像提示积液。这类病例的 JSON 中手术字段与再入院记录并存，时间线较复杂（第一次手术在本次住院内还是上次住院，需要看 admission_id）。它暴露出一个结构性问题：单文件无法表达跨住院的因果链。

39.6 五类病例的分布预期

由于筛选条件排除诊断数 ≥5 的病例，多慢病型与术后并发症型（常伴随多条诊断）占比会偏低，单病种型占比偏高。这意味着数据集的病例构成天然偏向"简单明了"，读者在看到高 Hit@K 时应先想到这一点。

§40 数据工程的十项规范建议

40.1 读取层

规范 1：编码显式声明。读文件时显式指定 encoding="utf-8"，并对解码失败的文件做记录而非静默跳过。规范 2：结构校验先行。在业务逻辑前先做一次 schema 校验（顶层键是否存在、类型是否符合预期），失败即中止，不要带着脏数据往下跑。

40.2 表示层

规范 3：统一键名。把带空格的键在读取时统一改写成下划线形式，并保留一份 原始键 → 规范键 的映射，供回溯。规范 4：缺失显式化。把空字符串、"N/A"、"None"、"见上" 统一映射为 null，并另设标志位区分"未做"与"未记"。

40.3 业务层

规范 5：单例隔离。每个病例的解析在一个独立的上下文里完成，避免跨病例的状态污染（尤其是缓存键要用住院号）。规范 6：审计日志。任何 LLM 调用都记录输入哈希、模型名、时间戳、输出长度，便于事后追溯与复现。

40.4 交付层

规范 7：样例脱敏。内部文档若需展示样例，只用字段名与结构，不贴真实值。规范 8：版本锚定。所有报告标注数据集版本号与 DOI，不写"latest"。规范 9：可执行校验。把核对脚本纳入仓库，任何人 clone 后能一键复跑。规范 10：结论分层。把"数据内结论"与"外推结论"分开写，后者必须标明假设与验证方式。

这十条不针对某一个数据集，而是面向所有"结构化临床文本"项目的通用规范。MIMIC-Patient 只是恰好让这些规范变得具体可感。

§41 与本库其他条目共用的方法论

41.1 派生集条目的写作范式

本库中凡是"基于某母库派生"的条目，都遵循同一套写作骨架：先写母库规模与派生漏斗，再写派生处理（哪些字段、什么手法），然后写访问门槛（是否继承母库）、最后写局限（筛选偏倚、抽取不确定）。本条目是该范式的实例之一，其他同类条目（如 MIMIC-CXR 的各扩展包、synnotes 等）可参照阅读。

41.2 与"合成数据"条目的对照

合成数据条目（如 synthetic-mimic-iii-health-gym，rid 597）的写作重点在"生成机制与保真度"；派生集条目的重点在"抽取保真度与选择偏倚"。两者都会涉及"数据是否像真实病人"这一命题，但一个问的是"生成得像不像"，一个问的是"抽取对不对"。读者若同时读两条，会看到两种完全不同的质量评估框架。

41.3 与"问答基准"条目的对照

问答基准条目（emrQA、EHRXQA、MedAgentBench）的重点在任务定义与指标；派生集条目的重点在数据形态与合规。MIMIC-Patient 横跨两者，因此本条目既讲了任务（§8），也讲了数据（§5），篇幅上数据部分更长——这是由它的"数据集"身份决定的，而非其"基准"身份。

41.4 互链的价值

读者从 MIMIC 本体条目进来，往往是想做临床数据分析；从问答基准条目进来，往往是想做模型评测。两条动线在 MIMIC-Patient 处交汇，这正是它作为"中间态"数据集的价值：它既需要 MIMIC 的基础设施，也服务于智能体评测的新需求。条目末尾的互链表（§11.2）就是为这两条动线设计的导航。

§42 时间线：从数据采集到条目定型

42.1 四个时间节点

2001-2012：BIDMC 临床数据产生；2010 年前后 MIMIC-III 前身 MIMIC-II 已在运行。2016：MIMIC-III 论文发表于 Scientific Data（3:160035），确立 58,976 次住院的公开口径。2025-2026：Penn 团队构建 MIMIC-Patient，DynamiCare 论文投稿并被 AMIA Summits 接收。2026-09-11：PhysioNet v1.0.0 发布。2026-10-17：本条目抓取与成稿。

42.2 时间差带来的解读含义

数据采集结束（2012）到数据集发布（2026）之间隔了 14 年。这意味着 JSON 里的临床实践反映的是 2001-2012 年的标准：ICD-9 编码、早期的脓毒症定义（Sepsis-2）、尚未普及的某些药物。用当代模型评测这些病例，等于让模型回到"十多年前的医院"工作，这在方法学上是可接受的（因为任务是诊断推理而非遵循最新指南），但在讨论"临床适用性"时必须说明。

42.3 版本时间线

v1.0.0（2026-09-11）为初始版；截至目前无 v1.1。若未来出现更新，本条目需按 §20.1 的触发条件修订。读者应留意 PhysioNet 页面上的 “Version” 与 “Latest version” 标识，二者可能不同。

§43 回答"这份数据到底有多重要"

43.1 从引用潜力看

一份数据集的重要性，部分体现在"它被谁用于回答什么问题"。MIMIC-Patient 的引用潜力集中在三类工作：多智能体医疗框架（用它做评测环境）、病人模拟器研究（用它做对照数据）、EHR 结构化研究（用它做方法案例）。这三类工作都是 2025-2026 年的热点，因此其短期引用潜力不低。

43.2 从不可替代性看

在"真实病历 + 多轮问诊 + 结构化 JSON"这个交叉点上，目前没有明显的同类竞品：MIMIC-III Demo 太粗糙，emrQA 是静态问答，MedAgentBench 是虚拟环境。这种稀缺性会维持一段时间，直到有人做出基于 MIMIC-IV 的同类版本。

43.3 从方法学贡献看

它把"患者端信息受控"这件事工程化了。这个思路会影响后来者：做病人模拟器时，如何限制模型"知道太多"，成为一个必须回答的设计问题。这种"提出问题"的价值，往往比"提供数据"更持久。更具体地说，后来者若想做得更好，至少要在三个方向上推进：把"知道什么"的边界从章节级细化到字段级；把边界控制从提示词约束升级为代码层的强制过滤（模型根本看不到被屏蔽字段）；把边界的每一次放行都写进审计日志，供评测者复核。这三步做完，"信息受控"才从一种写作技巧变成一种可验证的系统属性。

43.4 从局限看

它的局限同样是教科书级的：选择偏倚、派生不确定性、门槛不降、样本偏小。这四条几乎是所有"派生数据集"的通病，因此它也可以作为反面教材——提醒数据生产者在做派生时，要同时输出"抽取日志"与"抽检报告"，否则数据的使用者永远处于"不知道字段有多准"的状态。更进一步：一个成熟的派生集应当附带一份"已知缺陷清单"，逐条写明缺陷类型、影响字段、估计比例与缓解建议，让下游不必从零开始踩坑。这份清单的成本远低于它节省的重复劳动，可惜目前多数派生集都没有。

§44 最后的操作建议

如果你明天就要开始用这份数据，建议的顺序是：先花半天把认证流程走完（CITI 培训可在线完成，DUA 审批等待时间不可控，越早提交越好）；等待期间用 MIMIC-III Demo 把解析与路由代码写好并跑通；数据到手后第一天只做核对（§9 十条清单），不做任何分析；第二天开始跑 10 例小规模评测，确认路由覆盖率与兜底率；确认无误后再扩到 500 例全量。这个顺序能把"数据问题"与"方法问题"分开，避免把数据缺陷误判为方法失败。

§45 复现 DynamiCare 评测的最小工程方案

45.1 你需要准备的四样东西

第一样是数据（500 个 JSON）。第二样是一个能稳定回答的 LLM 接口（建议同时准备一个开源模型的本地部署作为备选，用于处理 DUA 敏感场景）。第三样是一个"医生智能体"的循环控制器，负责维护对话历史、决定下一问问什么、在何时收敛。第四样是一份评测协议文档，写清轮数上限、问题来源、评分规则、匹配粒度。

45.2 医生智能体的状态设计

一次 episode 的状态至少包含：病例 ID、已问问题列表、已获回答列表、当前鉴别假设集合、当前参与的专科 agent 列表、剩余可提问轮数。这个状态不放在患者端，而放在医生端，是为了让患者端保持"无状态"——这也是 answer_agent.py 被打包成独立脚本的设计基础。状态设计得越清晰，复现时越容易与论文对上。

45.3 问题生成的三种策略

模板式：预设一组问题模板（“有没有发热”“平时吃哪些药”），按固定顺序问。特点是可复现、覆盖面稳定，但缺乏针对性。LLM 生成式：让模型根据当前假设生成下一个问题。特点是有针对性，但问题质量随模型波动。混合式：先用模板覆盖基本项（主诉、病程、用药、过敏、既往史），再用 LLM 生成针对性追问。论文的多智能体框架偏向第二、三种，这也是 Ave-Q 达到 7.55 的原因之一。

45.4 收敛判定的两种方式

轮数上限：到 --max_rounds 强制输出，简单但会让部分 episode 在信息不足时结束。自评收敛：让医生 agent 自行判断"证据是否充分"，充分则提前结束。后者更接近真实临床，但会引入模型的过度自信问题（信息不足时也认为充分）。建议两者结合：自评收敛为主，轮数上限为兜底。

45.5 一个可运行的对照脚本结构

for case in cases:
    patient = PatientSession(case, model=MODEL_B)
    doctor  = DoctorAgent(mode="multi", model=MODEL_A, max_rounds=10)
    state = doctor.init(case)
    while not doctor.should_stop(state):
        q = doctor.next_question(state)
        a = patient.ask(q)
        state.update(q, a)
    pred = doctor.final_diagnosis(state)
    score(pred, case["gold"])

这个结构的关键点在于两个角色用不同的 model 变量：患者端与医生端可以是不同模型（论文中患者端用 GPT-4.1），这样既能避免"自己问自己"的泄漏，也能分别调优。实践中还有一个常被忽视的细节：患者端的温度应设得低一些（追求回答稳定），医生端的温度可以略高（鼓励探索不同假设），两者混用同一套采样参数会让实验结论难以解释。

45.6 结果记录的字段设计

每条 episode 记录：case_id、模型快照、轮数、每轮问题与回答、路由模式（routed/fallback）、命中章节、最终诊断列表、gold 诊断、Hit@5/10 与 Rec@5/10、耗时、token 用量。这些字段足以支撑事后做失败归因（见 §23.5），也足以支撑作者回应当审稿人对可复现性的质疑。若预算允许，再加两个字段会让日志更有价值：一是每轮回答引用到的原始字段路径（用于核对"回答是否有据"），二是医生 agent 每次变更假设时的理由文本（用于分析"推理链是否合理"）；前者服务于真实性核查，后者服务于过程评价。

45.7 常见工程坑

坑 A：患者端与医生端共用同一个 API Key 与同一温度，导致回答风格趋同；建议两端差异化配置。坑 B：对话历史无限增长，后期轮次 token 超限；建议只保留最近 N 轮或做摘要压缩。坑 C：诊断匹配时直接字符串比较，忽略同义词；应按论文用 BioPortal 映射到码。坑 D：没记录模型快照，三个月后无法解释结果漂移。

§46 数据集的社会技术属性

46.1 谁在生产，谁在消费

生产者是学术团队（Penn），消费者是另一批学术团队（做智能体的研究者）。中间没有商业化环节，这决定了它的演进节奏跟随论文而非产品。这一点对使用者有利（不用担心付费墙变更），也有不利（更新慢、文档不全）。

46.2 谁承担风险

风险主要是合规风险与再识别风险，由使用者承担。数据集发布方通过 DUA 把责任转移给下游，这是认证数据集的通行做法。使用者需要理解：签署 DUA 不是形式，而是法律责任的分界点。

46.3 谁获益

短期是论文作者（引用与影响力），中期是做智能体评测的研究者（有了标准病例集），长期是整个 MIMIC 生态（证明了派生集可以有多样形态）。这种"多层获益"结构是开放科学数据集的典型特征。

46.4 谁来维护

页面未指定维护团队与联系方式（作者联系方式需登录查看）。这意味着问题反馈的路径不透明，使用者若发现数据问题，只能通过 PhysioNet 的反馈渠道或 GitHub issue 提出。这是一个治理层面的小缺陷，但对长期质量有影响。

§47 字段级 FAQ：二十个工程问题

1. Admission_info 只有三个字段，够吗？
不够做时间分析，够做身份锚定。入院时间、出院时间、入院类型（急诊/择期）若不在 JSON 中，就无法计算住院日，也无法区分急慢诊。这是使用前必须确认的。

2. Diagnoses 是数组还是对象？
页面只说"ICD-9"，未给样例。三种可能：字符串数组（只有码）、对象数组（码 + 描述 + 主次）、以码为键的对象。三种形态的解析代码完全不同，必须先 type() 确认。

3. Prescription 的起止时间在不在？
若在，可以做用药时序分析；若不在，只能做"用了哪些药"的静态统计。MIMIC-III 的 PRESCRIPTIONS 有 STARTDATE/ENDDATE，JSON 是否保留未知。

4. 生命体征是原始序列还是汇总值？
这是最关键的一个未知项。若是序列，可以做趋势分析；若是汇总（如入院首日均值），只能做单点判断。从"LLM 上下文预算"的角度推测，作者大概率做了压缩，但这只是推测。

5. 化验单位是否保留？
Lab Data 若不保留 VALUEUOM，数值就失去意义（肌酐 1.2 是 mg/dL 还是 µmol/L 差 88 倍）。这是必须核对的第一件事。

6. Physical Exam 十项是否可能缺失？
可能。出院小结未记载的查体项，抽取后为空。空值率需要使用者在本地统计。

7. ECG 字段是文本报告还是结构化参数？
据页面描述，ECG 属"半结构化文本"，即报告文本经规则切分，不是数值化的心率/PR 间期等参数。做心电图信号分析请改用 MIMIC-III Waveform。

8. Radiology 是否区分检查类型？
未知。若结构为 { "CT": {...}, "X-Ray": {...} } 则区分；若为数组则需从文本判断。做影像报告研究时需先摸清。

9. Allergies 为空意味着什么？
三种可能：无过敏、未记录、抽取失败。无法从数据本身区分，需结合出院小结判断。这是典型的三义空值问题。

10. 能否从 JSON 还原出完整的原始病历？
不能。JSON 是选择性投影，原始表的高频事件、字典编码、部分时间戳被丢弃。还原请回 MIMIC-III 原始库（凭 patient_id/admission_id 关联）。

11. patient_id 与 admission_id 是否会混淆？
在部分 MIMIC 数据中两者数值范围不重叠，但 Admission_info 同时给出两者，所以只要显式取键就不会混。文件名的语义才是真正的坑（见坑 5）。

12. 中文病历能直接套用这套 schema 吗？
schema 层面可以（住院→JSON 的抽象是通用的），但字段名、报告切分规则、路由字典都要重做。本数据集的经验可迁移，代码不可直接复用。

13. JSON 里有没有患者姓名、住址？
不会有。MIMIC 已去标识化，直接标识符在原始库中已移除。但自由文本中可能残留间接标识（如罕见职业、具体日期），使用与引用时仍需谨慎。

14. 日期是真实日期吗？
不是。MIMIC 对每位患者做了随机日期偏移，同一患者内的间隔保持真实，跨患者日期不可比。做季节性分析会失效。

15. 能否用 JSON 直接训练一个"病历摘要"模型？
可以，但标签质量取决于 GPT-4 抽取质量；更稳妥的做法是用原始出院小结做监督，JSON 只做输入。

16. 500 个文件能否一次全部载入内存？
可以。按百 MB 量级估算，普通笔记本足够。但仍建议流式处理，避免峰值内存问题。

17. 有没有官方的数据校验工具？
页面未提供。没有 checksum 清单，也没有 schema 文件。这是本数据集在工程规范化上的一处欠缺。

18. 能否用 HuggingFace datasets 直接加载？
不能。数据不在 HF 上，且受 DUA 限制不可公开镜像。任何"HF 上的 MIMIC-Patient"镜像都应视为侵权复制。

19. 使用后需要向作者反馈吗？
非强制，但建议。发现问题（字段错位、抽取错误）反馈给作者，有助于下一版改进，也是学术共同体的一种义务。

20. 条目里写的"待实测"是什么意思？
意思是本文在公开信息范围内无法确认，需要拿到数据后实测。这类标注是诚实的缺口标记，不是模糊表述。

§48 一份完整的数据卡模板（供使用者自填）

项	填写内容
数据集名与版本	MIMIC-III-Ext-MIMIC-Patient v1.0.0
DOI	10.13026/bzzd-w075
获取日期	待填
获取方式	PhysioNet Credentialed Access（DUA 编号待填）
文件数	待核对（应为 500）
总字节	待测
校验哈希	待生成
使用字段范围	例：仅 Diagnoses + Physical Exam，排除 GPT-4 抽取字段
已知缺陷	待抽检填写
抽检比例	例：30/500
主要用途	例：多轮诊断评测
模型快照	例：gpt-4.1-2025-xx-xx
运行日期	待填
结论外推边界	仅限本数据集内，不外推 MIMIC-III 总体
合规审查	机构 IRB / 伦理备案号待填

把这张表填完，你的使用就有了完整的可追溯性。这张表也适合作为团队内部的数据交接文档。

FAQ：高频问答 30 问

A. 基础认知

1. MIMIC-Patient 和 MIMIC-III 是同一个东西吗？
不是。MIMIC-III 是 26 张关系表的完整库，MIMIC-Patient 是从中抽 500 次住院压成的 JSON 派生集。前者的条目在库内是 rid 590/106，后者是本条目。

2. 名字里的 “Ext” 是什么意思？
Extension，指 PhysioNet 上的扩展包（derived dataset）。同一命名体系下还有 mimic-iii-ext-ppg、mimic-iv-ext-ecg-glucose 等，都由第三方基于 MIMIC 加工。

3. 它和 DynamiCare 是什么关系？
DynamiCare 是论文提出的多智能体诊断框架，MIMIC-Patient 是该论文构建并使用的评测数据。数据独立在 PhysioNet 发布，代码在 GitHub。

4. 谁是作者？
Tianqi Shang、Weiqing He、Charles Zheng、Lingyao Li、Li Shen、Bingxin Zhao，单位为 University of Pennsylvania。

5. 什么时候发布的？
PhysioNet 页面标注 v1.0.0 初始版发布于 2026-09-11。论文发表于 2026 年 AMIA 会议。

6. 数据是真实的病人吗？
是。全部来自 BIDMC 2001-2012 年的真实 ICU 住院记录，已按 MIMIC-III 的标准流程去标识化，不是合成数据。

6b. 那为什么 500 例看着比 MIMIC-III 全库"干净"？
因为抽样前做了四条件筛选，把诊断条数多、住院期间死亡、文书不全的病例挡在门外，剩下的自然显得"干净"。这不是去标识化带来的效果，而是筛选带来的效果，两者容易被混为一谈，读表时要分清。

B. 数据与获取

7. 我能直接下载吗？
不能。需要 PhysioNet 账号 + CITI 培训证书 + 签署 DUA，与 MIMIC-III 本体完全一致。

8. CITI 要上哪门课？
“Data or Specimens Only Research”。证书上传 PhysioNet 账户后待审。

9. 为什么页面显示 Data Not Available？
抓取时平台提示"数据在你的地区因法律或政策限制不可用"，属地区访问策略，不是条目下架。

10. 一共多少文件？
patient_json/ 下 500 个 JSON + 1 个 answer_agent.py。

11. 有多大？
页面未披露总字节数。按单次住院数据量估算在百 MB 量级，实际以目录清单为准。

12. 有样例可看吗？
没有公开样例。可参考 GitHub 仓库 README 与代码结构，或用 MIMIC-III Demo 自拼同构数据做开发替身。

13. 用哪个 DOI 引用？
绑定 1.0.0 文件时引 10.13026/bzzd-w075；泛引最新版用 10.13026/n19w-aw59。

C. 数据结构

14. 一个 JSON 有哪几个顶层板块？
Patient（含 Admission_info、Demographics、Diagnoses、Prescription、Physical Exam 等）、ECG、Radiology、Introduction、Chief Complaint、Allergies、Major Surgical or Invasive Procedure。

15. 诊断是什么编码？
ICD-9。每例少于 5 条（筛选条件）。

16. 有原始影像吗？
没有。影像、ECG、超声只以文字报告形式出现。

17. 有波形数据吗？
没有。需要波形请用 MIMIC-III Waveform 系列（库内 rid 586/587/588）。

18. Physical Exam 下面有什么？
VS、General、HEENT、Neck、Cardiac、Lungs、Abdomen、Extremities、Skin、Pulses 十个亚项，来自出院小结抽取。

19. 文件名是 HADM_ID 还是 SUBJECT_ID？
页面未明确。从数值量级看更像 SUBJECT_ID，但必须实测确认（坑 5）。

D. answer_agent.py

20. 它用什么检索？
关键词路由：正则分词 → 预定义"关键词-章节"字典 → 取章节整块内容 → 交 LLM 合成。

21. 路由失败怎么办？
回退到整份 JSON 作为上下文交 LLM 直接推理。这条兜底路径会削弱信息边界控制。

22. 支持多轮对话吗？
单轮无状态。多轮状态由上层 doctor_agent.py 维护。

23. 必须用 OpenAI 吗？
脚本默认调 OpenAI，但把调用层换成任意兼容接口即可；注意 DUA 对第三方服务的约束。

24. 会编造病史吗？
系统提示要求对无信息问题回答 “I don’t know”，人工评估 Truthfulness 均值 1.95（2 分制满分），说明幻觉较少但非零。

25. 怎么跑通第一条？
python answer_agent.py --path xxx.json --question "..." --model gpt-4.1，API Key 写进 config.json。

E. 评测与结果

26. Hit@5 是多少？
多智能体 63.4，单智能体（GPT-4.1）58.0。

27. 匹配规则是什么？
预测诊断经 BioPortal 映射 ICD-9，前三位相同即算正确。

28. Ave-Q 是什么意思？
平均提问轮数。多智能体 7.55，单智能体 3.83。

29. 有第三方复现吗？
截至 2026-10 抓取时点未见公开的第三方排行榜或复现报告。

30. 能拿来训练模型吗？
可以但不推荐作训练主力：500 例偏小，且选择偏倚明显。更适合做评测与架构验证。

事实清单：硬事实 30 条

1. 官方名：MIMIC-III-Ext-MIMIC-Patient: Structured Per-Patient JSON Records for Clinical Question Answering。
2. PhysioNet 路径：/content/mimic-iii-ext-mimic-patient/1.0.0。
3. 初始版发布日：2026-09-11。
4. RRID：SCR_007345。
5. DOI（v1.0.0）：10.13026/bzzd-w075。
6. DOI（latest）：10.13026/n19w-aw59。
7. 母库：MIMIC-III Clinical Database v1.4。
8. 母库住院数：58,976。
9. 母库患者数：40,000+。
10. 母库时间跨度：2001-2012。
11. 母库中心：BIDMC（波士顿）。
12. 合格池：2,597 次住院。
13. 抽样结果：500 次住院。
14. 抽样方式：无放回随机。
15. 筛选条件 1：诊断记录少于 5 条。
16. 筛选条件 2：非新生儿。
17. 筛选条件 3：住院期间存活。
18. 筛选条件 4：结构化数据完整且至少一份出院小结。
19. 文件构成：500 个 JSON + answer_agent.py。
20. 访问级别：Database Credentialed Access。
21. 许可：PhysioNet Credentialed Health Data License 1.5.0。
22. DUA：Credentialed Health Data Use Agreement 1.5.0。
23. 培训：CITI Data or Specimens Only Research。
24. 诊断编码：ICD-9。
25. 半结构化报告处理：正则识别 Findings/Impression 等小标题分段。
26. 出院小结处理：GPT-4 抽取为结构化字段。
27. 答案生成模型：GPT-4.1（患者系统）。
28. 多智能体 vs 单智能体 Hit@5：63.4 vs 58.0。
29. 多智能体 vs 单智能体 Hit@10：71.6 vs 63.2。
30. 人工评估：100 例 × 3 名医学生，Truthfulness 1.95 / Relevance 1.79。

术语表：26 条

术语（英）	中文	在本文中的含义
admission	住院/入院	MIMIC 的统计单位，对应 HADM_ID
HADM_ID	住院标识	MIMIC-III 每次住院的唯一编号
SUBJECT_ID	患者标识	MIMIC-III 每位患者的唯一编号
patient_json	逐患者 JSON 目录	本数据集的数据目录名
answer_agent.py	回答智能体脚本	病人模拟器实现
doctor_agent.py	医生智能体脚本	多智能体问诊主程序
keyword routing	关键词路由	用字典把问题映射到 JSON 章节
fallback	兜底回退	路由失败时改为全量上下文推理
personified answer	人格化作答	以病人第一人称生成回答
discharge summary	出院小结	非结构化文本的主要来源
NOTEEVENTS	笔记事件表	MIMIC-III 存放各类自由文本的表
CHARTEVENTS	图表事件表	床旁生命体征等高频记录表
LABEVENTS	化验事件表	实验室检验结果表
ITEMID	条目编号	生命体征与化验的字典编码
ICD-9	国际疾病分类第九版	诊断编码体系
BioPortal	生物医学本体门户	用于诊断文本到 ICD-9 的映射
Hit@K	前 K 命中	正确诊断是否进入前 K
Rec@K	前 K 召回	前 K 覆盖真实诊断的比例
Ave-Q	平均提问数	交互轮数指标
Truthfulness	真实性	回答与病历一致程度
Relevance	相关性	回答是否切题
selection bias	选择偏倚	筛选导致样本不代表总体
credentialed access	认证访问	需签 DUA 的受限下载
DUA	数据使用协议	使用认证数据的法律文件
zero retention	零留存	LLM 服务不保存请求数据
de-identification	去标识化	移除直接标识符的处理

附录

附录 A：条目信息速查卡

字段	值
条目 slug	mimic-patient-json
正式名	MIMIC-III-Ext-MIMIC-Patient
论文简称	MIMIC-Patient
平台	PhysioNet
版本	1.0.0
发布日期	2026-09-11
DOI (v1.0.0)	10.13026/bzzd-w075
DOI (latest)	10.13026/n19w-aw59
RRID	SCR_007345
记录数	500
记录粒度	每次住院
格式	JSON + Python
访问级别	Credentialed
许可	PhysioNet Credentialed Health Data License 1.5.0
配套论文	DynamiCare（AMIA Summits 2026:408，PMC13274293）
代码仓库	github.com/THEGREATICE/DynamiCare
本条目抓取日	2026-10-17

附录 B：数据字段字典（页面披露口径）

板块	字段	类型（推断）	来源表	说明
Patient	Admission_info.patient_id	整数	ADMISSIONS.SUBJECT_ID	患者号
Patient	Admission_info.admission_id	整数	ADMISSIONS.HADM_ID	住院号
Patient	Admission_info.admission_diagnosis	字符串	ADMISSIONS.DIAGNOSIS	入院诊断自由文本
Patient	Demographics	对象	PATIENTS	性别、年龄、种族等
Patient	Diagnoses	数组	DIAGNOSES_ICD + D_ICD_DIAGNOSES	ICD-9 码与描述
Patient	Prescription	数组	PRESCRIPTIONS	药名、剂量、途径、起止
Patient	Physical Exam.*	对象	出院小结（GPT-4）	十个查体亚项
顶层	ECG	对象	NOTEEVENTS（ECG 类）	规则切分
顶层	Radiology	对象	NOTEEVENTS（影像类）	含 Findings/Impression
顶层	Introduction	字符串	出院小结（GPT-4）	病例简介
顶层	Chief Complaint	字符串	出院小结（GPT-4）	主诉
顶层	Allergies	字符串/数组	出院小结（GPT-4）	过敏史
顶层	Major Surgical or Invasive Procedure	字符串	出院小结（GPT-4）	主要手术或侵入性操作

类型列均为推断值，实测请以获批文件的 type() 输出为准。

附录 C：坑点索引（与 §10 对照）

编号	坑名	影响面	严重度
坑 1	DOI 张冠李戴	引用、检索	高
坑 2	ext 家族当本体	选型	中
坑 3	500 例当代表样本	统计结论	高
坑 4	会议名双口径	引用	低
坑 5	文件名语义不明	join	中
坑 6	字段名含空格	取数	中
坑 7	只遍历 Patient	数据丢失	高
坑 8	三位码当严格评估	结果解读	中
坑 9	抽取字段当金标准	训练/评测	高
坑 10	忽视 DUA 约束	合规	高
坑 11	单轮脚本误当多轮	归因	中
坑 12	单位与年龄去标识	数值分析	中

附录 D：双口径存照表

事项	口径 A	口径 B	本文采用
DOI	brief: 10.13026/rees-1092	官方: 10.13026/bzzd-w075 / n19w-aw59	官方
会议名	PhysioNet: AMIA Summits on Translational Science Proceedings	README 页眉: AMIA Annual Symposium Proceedings	Summits
筛选条件条数	PhysioNet: 4 条	PMC 正文: 3 条（合并新生儿与存活）	4 条
体量	页面: 未披露	估算: 百 MB 量级	记为未披露
文件名语义	页面: 唯一标识符	数值量级: 更像 SUBJECT_ID	待实测

附录 E：DAIMS 评估全表

维度	评分	权重	加权分	说明
文档完备度	3	15%	0.45	字段有说明，缺 Schema 与体量
机器可读性	4	20%	0.80	JSON 原生，扣分于空格键名
溯源可追	4	15%	0.60	可回溯 HADM_ID/SUBJECT_ID
合规与治理	4	20%	0.80	沿用成熟 DUA 体系
代表性	2	15%	0.30	四条件筛选 + 单中心
可复现性	3	15%	0.45	依赖 GPT-4 抽取与模型快照
合计	—	100%	3.40	用途受限型数据集

附录 F：检索路径示范

目标	推荐查询式	预期命中
官方页面	site:physionet.org MIMIC-Patient JSON	PhysioNet 1.0.0 条目
配套论文	“DynamiCare” medical multi-agent	PMC13274293
代码	THEGREATICE DynamiCare	GitHub 仓库
母库	“MIMIC-III, a freely accessible critical care database”	Scientific Data 2016;3:160035
派生家族	site:physionet.org mimic-iii-ext	ext 系列条目
反例	MIMIC-Patient（不带 ext）	容易命中 MIMIC-IV 的 note 或 demo

检索卫生两条：一、MIMIC-Patient 是论文内简称，PhysioNet 与部分搜索引擎可能只索引正式名；二、带 ext 的条目均为派生集，不要与本体条目混淆。

附录 G：复现骨架（伪代码）

import json, os

def load_case(path):
    with open(path, encoding="utf-8") as f:
        return json.load(f)

def flatten(case):
    # 注意：ECG/Radiology 等在顶层，不在 Patient 之下
    out = {}
    for k, v in case.items():
        if isinstance(v, dict):
            for k2, v2 in v.items():
                out[f"{k}.{k2}".replace(" ", "_")] = v2
        else:
            out[k.replace(" ", "_")] = v
    return out

def route(question, mapping):
    q = question.lower()
    hits = [sec for kw, sec in mapping.items() if kw in q]
    return hits or ["__fallback__"]

mapping = {
    "medication": "Patient.Prescription",
    "allerg": "Allergies",
    "pain": "Chief Complaint",
    "surgery": "Major_Surgical_or_Invasive_Procedure",
}

case = load_case("patient_json/100173.json")
print(route("What medications do you take?", mapping))

骨架只演示结构与路由逻辑，实际提示词与调用层需按合规要求自行实现。

附录 H：使用前检查清单（12 项）

1. 访问权限已获批，下载按钮可见。
2. 文件数 = 500。
3. 全部 JSON 可解析。
4. 文件名语义已确认。
5. 顶层键清单已记录。
6. 生命体征单位已核对。
7. 化验单位已核对。
8. ICD-9 与原始表抽样比对通过。
9. 抽取字段抽检 10 例以上。
10. LLM 服务商留存政策已确认。
11. 版本号与模型快照写入日志。
12. 引用格式已按 DOI 与 PhysioNet 标准引文准备。

附录 I：与库内条目的关系声明

本条目为 mimic-patient-json（PhysioNet 派生集），与库内 mimiciii-legacy（rid 590）、mimic-iii（rid 106） 为"派生 vs 本体"关系，本体条目的表结构、住院数据量、认证流程细节以那两条为准，本条目不重复。与 mimiciv（592）、mimic-iv-clinical-database（4） 为"上一代 vs 新一代"关系。与 synthetic-mimic-iii-health-gym（597） 为"真实 vs 合成"对照。与 aipatient（550）、medagentbench（1064） 为同赛道（病人模拟/智能体评测）不同技术路线。

附录 J：引文规范

数据集引用（APA）：

Shang, T., He, W., Zheng, C., Li, L., Shen, L., & Zhao, B. (2026). MIMIC-III-Ext-MIMIC-Patient: Structured Per-Patient JSON Records for Clinical Question Answering (version 1.0.0). PhysioNet. RRID:SCR_007345. https://doi.org/10.13026/bzzd-w075

方法引用（BibTeX）：

@article{shang2026dynamicare,
  title={DynamiCare: A dynamic multi-agent framework for interactive and open-ended medical decision-making},
  author={Shang, Tianqi and He, Weiqing and Zheng, Charles and Li, Lingyao and Shen, Li and Zhao, Bingxin},
  journal={AMIA Summits on Translational Science Proceedings},
  volume={2026},
  pages={408},
  year={2026}
}

母库引用：

Johnson, A. E., Pollard, T. J., Shen, L., et al. (2016). MIMIC-III, a freely accessible critical care database. Scientific Data, 3, 160035.

三处引用缺一不可：数据、方法、母库。

附录 K：本条目生产档案

项	内容
代理名	agent-b-mimicpatie
开工时间	2026-10-17T20:41+08:00
抓取源	PhysioNet 条目页、PMC13274293、GitHub README
网络请求	WebFetch 3 次，WebSearch 0 次
查重	DB mimic* 33 条无同名；writing/ 无同名目录
存照	FACTS.md §9，附录 D
遗留疑点	体量未披露、文件名语义待实测、字段 Schema 未公开、answer_agent 源码未直读

附录 L：术语补充（缩写速查）

缩写	全称	中文
BIDMC	Beth Israel Deaconess Medical Center	贝斯以色列女执事医疗中心
MIMIC	Medical Information Mart for Intensive Care	重症监护医学信息库
LLM	Large Language Model	大语言模型
RAG	Retrieval-Augmented Generation	检索增强生成
EHR	Electronic Health Record	电子健康记录
CITI	Collaborative Institutional Training Initiative	科研伦理培训项目
IRB	Institutional Review Board	机构审查委员会
GNU	—	本文未涉及

缩写表里混入 GNU 这一条是刻意保留的提醒：文档里出现的每一个缩写都应当能在这里查到，如果查不到，说明正文引入了未定义的术语，需要补一行而不是跳过。做条目互查时，可以把正文中所有全大写词抽出来与这张表比对，差集就是待补术语，这是最省力的术语一致性检查法之一。

尾注

本条目为 AI-Ready Wikipedia 数据集条目，生产于 2026-10-17。事实陈述以 PhysioNet 官方条目页（v1.0.0）、PMC13274293 论文正文、GitHub THEGREATICE/DynamiCare README 三源互证为据；brief 与官方不一致处（DOI、会议名、筛选条件条数）已在坑 1、坑 4 与附录 D 存照。字段级描述凡标注"推断"者，均需以获批后实际文件核对。条目与库内 mimiciii-legacy（590）、mimic-iii（106）、aipatient（550）、medagentbench（1064）等条目互链，构成 MIMIC 派生集与临床智能体评测两个检索面的交汇点。补充一句：上述三源互证的"时点"本身也是事实的一部分。PhysioNet 页面会随版本静默更新，PMC 论文可能有勘误，GitHub README 可能随代码演进改口径；因此凡引用具体数字，都应连同抓取日期一并记录，否则两年后回看，读者无法判断数字是"当时如此"还是"一直都如此"。

---

相关数据集导航

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

• ehrsql — 共享标签：电子健康记录 / 临床电子病历 / 医学问答 / 临床文本 / 评测基准
• medsecid — 共享标签：电子健康记录 / 临床电子病历 / 临床文本 / 评测基准
• labelled-notes-hospital-course — 共享标签：电子健康记录 / 临床电子病历 / 临床文本 / 评测基准
• medisumqa — 共享标签：电子健康记录 / 医学问答 / 临床文本 / 评测基准
• mediqa — 共享标签：电子健康记录 / 临床电子病历 / 临床文本 / 评测基准
• deidentified-medical-text — 共享标签：电子健康记录 / 临床电子病历 / 临床文本 / 评测基准
• synsum — 共享标签：电子健康记录 / 临床电子病历 / 临床文本 / 评测基准
• ehr-notes-qa-llms — 共享标签：电子健康记录 / 临床电子病历 / 医学问答 / 评测基准
• emrqa — 共享标签：电子健康记录 / 临床电子病历 / 医学问答
• cmedqa2 — 共享标签：医学问答 / 临床文本 / 评测基准

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