MIMIC-Eye 眼动多模态整合数据集

把 MIMIC-IV 病历、MIMIC-CXR 胸片与 REFLACX 放射科医师眼动按患者重排成一棵目录树——千级患者、千级住院、数千张胸片,仅四成半拿得到临床链接

来源 MIMIC-IV(Hosp 与 ICU 模块)+ MIMIC-IV-ED + MIMIC-CXR + MIMIC-CXR-JPG + REFLACX + Eye Gaze Data for Chest X-rays 的按患者重组发布时间: 2026-10-18最后更新: 2026-10-18 阅读 11
MIMIC-Eye 眼动多模态整合数据集

信息速览

数据集名称MIMIC-Eye 眼动多模态整合数据集
数据类型真实世界数据,影像数据,临床文本,人工标注,眼动追踪
规模3,192 名患者 / 1,644 次住院 / 3,689 张胸片
接入方式MIMIC-IV(Hosp 与 ICU 模块)+ MIMIC-IV-ED + MIMIC-CXR + MIMIC-CXR-JPG + REFLACX + Eye Gaze Data for Chest X-rays 的按患者重组
AI 就绪度

MIMIC-Eye 是昆士兰科技大学(Queensland University of Technology,QUT)团队 2023 年 3 月 23 日发布在 PhysioNet 上的整合型派生数据集。它不采集任何新数据,而是把 MIMIC-IV 的结构化病历、MIMIC-CXR 的胸片与放射学报告、MIMIC-IV-ED 的急诊记录,和 REFLACX、Eye Gaze 两个眼动库里的放射科医师注视轨迹,按患者编号重新装进同一棵目录树:3,192 名患者,每人一个文件夹,最多七个子文件夹,旁边另有一个跨患者的 spreadsheets 汇总区。

医学影像的深度学习长期只吃图像,报告、化验、分诊记录散落在互不相通的库表里,而「医生看片时眼睛往哪走」这类过程数据几乎从不与病历同时出现。MIMIC-Eye 补的正是这条断链:它让一张胸片第一次能同时挂上病人的急诊分诊指标、住院轨迹、放射报告,以及某位医师读这张片时的注视序列与口述原话。对研究视觉搜索、可解释影像诊断、人机注意力对齐的人来说,这是一条此前需要自己拼装数月的数据通路。

用它的第一件事不是解压,而是读 spreadsheets 目录下的 cxr_meta.csv:先看 in_reflacx 与 in_eye_gaze 两列,确定哪些胸片真的带眼动,再看 stay_id 是否为空,确认哪些胸片接得上病历。三千余张胸片里,同时具备眼动与临床链接的只是少数,不先做这层筛选就全量遍历,会在大量只有结构化病历的空壳文件夹上浪费算力,且很容易把「链接失败」误当成「数据缺失」。

§1 它是什么

1.1 一句话定义与三个否定

MIMIC-Eye 是 PhysioNet 上的一份 credentialed access 数据集,官方全称 MIMIC-Eye: Integrating MIMIC Datasets with REFLACX and Eye Gaze for Multimodal Deep Learning Applications(短名在官方摘要中写作 MIMIC-EYE,PhysioNet 项目路径为 mimic-eye-multimodal-datasets)。它的定义可以压缩成一句:把六个已经各自发布的 PhysioNet 项目,按患者编号重排成一棵目录树,并额外造一张能把胸片、眼动与住院记录串起来的枢纽表。

这个定义里最要紧的是「重排」而非「新增」。要准确理解它,先要排除三种常见误解:

  • 它不是新采集的数据。没有新的患者招募,没有新的读片实验,没有新的标注员。所有影像、病历、眼动轨迹都曾以独立项目的形式发布过,MIMIC-Eye 做的是搬运与索引。
  • 它不是 MIMIC-IV 的一个视图或子集。虽然它把 MIMIC-IV 的表搬了进来,但纳入的患者不是从三十余万名 MIMIC-IV 患者里随机或按病种筛出来的,而是从两个眼动实验库的受试者名单倒推出来的。
  • 它不是一个机器学习基准。没有官方划分之外的评测协议,没有排行榜,没有基线分数,也没有声明某项任务的标准指标。作者只建议了用法方向。

1.2 六个父项目与各自的贡献

PhysioNet 页面在「Parent Projects」一栏明确列出六个必须引用的上游项目,并逐一标注版本。理解这六者各自负责什么,是理解整棵目录树的前提。

父项目 版本(页面对应) 在本数据集里贡献什么 在目录树中的位置
MIMIC-IV(Hosp 模块) v1.0 人口学、住院与病房转科轨迹、住院期间的检验与用药 Hosp/
MIMIC-IV(ICU 模块) v1.0 ICU 级事件:出入量、点滴、操作 ICU/
MIMIC-IV-ED v1.0 急诊就诊、分诊评估、生命体征、用药核对 ED/
MIMIC-CXR v1.0.0 放射学报告的文本内容、DICOM 元数据 CXR-DICOM/
MIMIC-CXR-JPG v2.0.0 可直接被模型读取的 JPG 胸片、CheXpert/NegBio 标签、官方划分 CXR-JPG/
REFLACX v1.0.0 五位放射科医师的注视点、凝视、瞳孔面积、带时间戳口述转录、异常定位椭圆 REFLACX/
Eye Gaze Data for Chest X-rays v1.0.0 另一位放射科医师的眼动与音频,外加解剖结构分割与边界框 EyeGaze/

表中七行对应目录树里的七个模块文件夹,而那六个父项目里有两项(MIMIC-IV 与 MIMIC-CXR)各贡献了两个模块,所以是「六库七模块」。这个错位是项目页自身叙述不统一的一个来源,§6 会专门处理。

值得单独说明的是 MIMIC-CXR 与 MIMIC-CXR-JPG 的分工。前者是原始数据库,胸片以 DICOM 格式存放,附带放射学报告文本;后者的存在理由是同一个:DICOM 这种格式对训练管线极不友好,需要专用库解析、需要处理窗宽窗位、需要额外做像素归一化,于是社区另做了一份 JPG 版本并配上结构化标签。MIMIC-Eye 两个都收:CXR-DICOM/ 下只有一份份以 study_id 命名的元数据文本(s{study_id}.txt),CXR-JPG/ 下才是真正能喂给模型的图像文件,放在 s{study_id}/{dicom_id}.jpg 这样的两级路径里。实际含义是:训练只用 CXR-JPG,要原始 DICOM 头信息才看 CXR-DICOM,两边不要重复读。

1.3 发布方、版本与身份

作者共六人:Chihcheng Hsieh、Chun Ouyang、Jacinto C. Nascimento、Joao Pereira、Joaquim Jorge、Catarina Moreira。PhysioNet 页面本身没有逐人标注机构,只给出资助信息:UNESCO Chair on AI&XR 教席,以及葡萄牙科学技术基金会(Fundação para a Ciência e a Tecnologia,FCT)的两个编号——2022.09212.PTDC(项目代号 XAVIER)与 UIDB/50021/2020。昆士兰科技大学的机构知识库 ePrints 把该条目登记在案(记录号 239699),通讯作者列为 Catarina Pinto Moreira,ORCID 为 0000-0002-8826-5163。两相印证,主体团队来自 QUT,合作署名覆盖葡萄牙方面。资助编号指向的机构归属属于推定,正文不把它写成定论。

版本方面只有一站:v1.0.0,2023 年 3 月 23 日发布,DOI 为 10.13026/pc72-as03。页面另给一个「latest」DOI 10.13026/kr1c-v245,但版本列表里仍然只有一个 1.0.0,这是 PhysioNet 用 ConCEPT DOI 管理版本的常规做法——每个版本一个固定 DOI,另有一个永远指向最新版的滚动 DOI。本项目发布至今未更新,三个年头过去仍是 1.0.0。

页面上标注的 RRID 是 SCR_007345。这个编号在 MIMIC-CXR、REFLACX、MIMIC-IV 等多个父项目的页面上同样出现,它是 PhysioNet 平台层的通用资源标识,不是 MIMIC-Eye 的独有身份。引用时若把它当作唯一标识写进论文,会指向整个 PhysioNet 而不是这个数据集。

1.4 它到底改变了什么:从「六个下载入口」到「一棵树」

如果只看数据类型,MIMIC-Eye 里没有任何一种数据是在别处拿不到的。这六个父项目全部公开(在签署协议的前提下),一个有耐心的团队完全可以用几个月时间自己拼出等价的表。那么 MIMIC-Eye 的增量落在哪里?落在一个常被低估的环节上:跨库主键对齐的工程实现,以及由此产生的一列新字段。

先说对齐。六个父项目各自的主键体系互不相同:MIMIC-IV 用 subject_id(患者)、hadm_id(住院)、stay_id(ICU 住院段);MIMIC-IV-ED 用 subject_id 加 stay_id(急诊的 stay_id 与 ICU 的 stay_id 同名列、不同语义,是 MIMIC 家族最经典的踩坑点);MIMIC-CXR 用 subject_id、study_id(一次影像检查)、dicom_id(单张图像);REFLACX 用自己的 reflacx_id;Eye Gaze 用 dicom_id。要把它们串起来,至少需要做三件事:把胸片的拍摄时刻换算到某个住院段的时间窗内、把两套同名不同义的 stay_id 区分开、把眼动记录的回溯标识(REFLACX 的 reflacx_id、Eye Gaze 的 dicom_id)与影像主键对上。

再说新字段。MIMIC-Eye 在 spreadsheets 目录下放了一张 cxr_meta.csv,说明它是在 MIMIC-CXR-JPG 原有 metadata.csv 的基础上扩列的,新增三列:

  • stay_id:把这张胸片接到某一次住院记录,作者原话是「有了这个 stay_id,图像就能连到 MIMIC-IV-ED 中对应的临床数据」;
  • in_reflacx:布尔值,这张片有没有被 REFLACX 使用;
  • in_eye_gaze:布尔值,这张片有没有被 Eye Gaze 使用。

这三列就是整个数据集「三方对齐」的全部元数据证据。缺了它们,目录树只是一堆平行文件夹;有了它们,使用者才能在 O(1) 的时间里回答「这张片有没有眼动、接不接得上病历」这两个筛选问题,而不必自己写跨库关联脚本。对任何想复现跨模态实验的团队来说,省下的正是最容易出错的那一段。

1.5 与母库的分工边界

与 REFLACX(库内 rid=623)的分工:REFLACX 是「眼动数据长什么样」这件事的权威来源——它定义了采集协议(EyeLink 1000 Plus、1000 赫兹、十三点校准)、定义了五类产出文件(注视点、凝视、椭圆、转录、胸廓框)、也定义了它自己与 MIMIC-CXR 的血缘关系。想知道眼动信号的信噪比、想了解医师之间标注差异有多大、想评估某个眼动模型在原始读片任务上的表现,都应该直接读 REFLACX。MIMIC-Eye 不重复定义这些,它把 REFLACX 整包搬进来,加的是 REFLACX 本身没有的东西:同一批眼动记录旁边的病历。换句话讲,REFLACX 回答「眼睛怎么动」,MIMIC-Eye 回答「这个人的急诊分诊指标是多少、住了几天院、出院诊断是什么」。

与 MIMIC-IV(库内 rid=4)的分工:MIMIC-IV 是全院级的完整临床数据库,适合做队列研究、做表型定义、做再入院预测。MIMIC-Eye 只取了其中被眼动实验覆盖的那一小撮人,临床表的字段没有增补,只是按患者切开重装。要做大规模流行病学,用 MIMIC-IV;要做小样本、多模态、带过程数据的建模,用 MIMIC-Eye。两者覆盖的人数差两个数量级,这不是缺陷,是用途分化的必然结果。

与 MIMIC-CXR(rid=16)和 MIMIC-CXR-JPG(rid=617)的分工:这两条覆盖的是全院胸片的图像侧与标签侧,量级是十万级的十倍有余。MIMIC-Eye 只取了其中极小一部分,且限于那批患者的胸片。若目的是训练一个通用胸片分类器,MIMIC-CXR-JPG 是正解;若目的是研究「某张特定胸片的特定读片过程」,MIMIC-Eye 才有意义。

增量的一句话总结:MIMIC-Eye 的唯一增量是「把眼动 × 影像 × 病历三方按人对齐,并把对齐结果固化成三列布尔与一个外键」。这句话既是它的全部价值,也是它的全部局限——它不生产数据,只生产关系。

§2 数据构成

2.1 目录树的形状

根目录下只有两类条目:一个是 spreadsheets/,其余全部是 patient_{subject_id}/。患者的文件夹数量等于患者数,每个文件夹内部最多有七个子文件夹,对应七个模块;某个患者如果从没进过 ICU,ICU/ 就不存在,如果从没去过急诊,ED/ 就不存在。所以「最多七个」这个限定不是排版上的措辞,而是实际结构的描述。

patient_{subject_id}/
    Hosp/           MIMIC-IV Hosp 模块的表
    ICU/            MIMIC-IV ICU 模块的表
    ED/             MIMIC-IV-ED 的表
    CXR-JPG/        s{study_id}/{dicom_id}.jpg + 三张标签表
    CXR-DICOM/      s{study_id}.txt
    REFLACX/        gaze_data/ + main_data/ + metadata.csv
    EyeGaze/        audio_segmentation_transcripts/ + 四张表
spreadsheets/       跨患者的字典表与汇总表

这种「一人一文件夹、模块一子文件夹」的组织方式,与 MIMIC 家族原本的「一表一文件、全库一文件」正相反。MIMIC-IV 是关系型组织:hosp/admissions.csv 里存全部患者的住院记录,要取某人的数据得做 WHERE subject_id = ? 过滤。MIMIC-Eye 是面向对象式组织:直接进他的文件夹就全在。两种组织各有代价——前者便于全库统计与联表,后者便于单例审阅与按需下载;MIMIC-Eye 选后者,把「一个人」当作检索与加载的自然单位。

这个选择对深度学习管线的实际影响是:按患者划分训练/验证/测试集变得非常自然。同一个患者的胸片分散在他自己的文件夹里,只要按患者切分,就不会出现同一患者的片被同时塞进训练与测试的泄漏。而在 MIMIC-CXR-JPG 的平铺结构里,这点需要额外写一段按 subject_id 分组的代码才能保证。

2.2 模块与文件清单

七个模块各自装了什么,是使用者最先要弄清的事。下表按模块列出主要文件与内容,字段可靠性一列标注了每行信息的确认程度。

模块 主要文件 内容 字段可靠性
Hosp admissions.csv、diagnoses_icd.csv、labevents.csv、prescriptions.csv、pharmacy.csv、microbiologyevents.csv、procedures_icd.csv、drgcodes.csv、omr.csv、poe.csv、poe_detail.csv、services.csv、transfers.csv 住院、出院诊断、检验、处方、药房、微生物、操作、DRG、门诊测量、医嘱及其明细、住院科室、转科 依惯例推定(字段定义沿用 MIMIC-IV v1.0 官方文档)
ICU chartevents.csv、inputevents.csv、outputevents.csv、procedureevents.csv、ingredientevents.csv、datetimeevents.csv、icustays.csv ICU 护理记录、入量、出量、操作、输入成分、日期型事件、ICU 住院段 依惯例推定
ED edstays.csv、triage.csv、vitalsign.csv、diagnosis.csv、medrecon.csv、pyxis.csv 急诊就诊、分诊评估、生命体征、急诊诊断、用药核对、发药记录 依惯例推定
CXR-JPG s{study_id}/{dicom_id}.jpg、cxr_chexpert.csv、cxr_negbio.csv、cxr_split.csv、cxr_meta.csv 胸片 JPG、两套 14 类结构化标签、官方划分、元数据 依惯例推定(标签由 CheXpert/NegBio 规则器生成,非人工逐条标注)
CXR-DICOM s{study_id}.txt DICOM 元数据文本导出 语义存疑(项目页只说「DICOM 元数据也被转成 CSV」,与目录里的 .txt 不完全一致)
REFLACX gaze_data/{reflacx_id}/gaze.csv、main_data/{reflacx_id}/{anomaly_location_ellipses,chest_bounding_box,fixations,timestamps_transcription}.csv、main_data/{reflacx_id}/transcription.txt、metadata.csv 原始注视点、异常椭圆、胸廓框、凝视、逐词时间戳转录、转录全文、ID 对照 依目录树确认(见 §2.3)
EyeGaze audio_segmentation_transcripts/{dicom_id}/{aortic_knob,left_lung,mediastanum,right_lung}.png、audio.mp3、audio.wav、transcript.json、bounding_boxes.csv、eye_gaze.csv、fixations.csv、master_sheet.csv 解剖结构分割图、音频、转录 JSON、边界框、原始注视、凝视、主索引表 依惯例推定(四张 png 的解剖命名取自目录树原文)

表中 CXR-DICOM 一行的「语义存疑」值得展开。项目页正文说「他们的 DICOM 元数据也被转换成了 CSV 文件并存放在这里」,但目录树显示 CXR-DICOM/ 下放的是 s{study_id}.txt,而 CSV 形式的元数据(cxr_meta.csv)出现在 CXR-JPG/ 和 spreadsheets/。两种描述不能同时成立,按文件名应以 .txt 为准。

2.3 REFLACX 模块的四个产出

眼动是本数据集的核心差异化模块,值得单独拆开。REFLACX 母库定义的五类产出,在 MIMIC-Eye 里被切成两层存放:

第一层 gaze_data/,每个 reflacx_id 一个子目录,里面只有 gaze.csv。这是原始采样流,母库口径为 1000 赫兹,即每毫秒一个点,一场读片持续数十秒就是数万个点。这一层数据量大、含噪多,适合做信号处理或画热图,不适合直接当作模型输入。

第二层 main_data/,同样按 reflacx_id 分目录,但装的是已经处理过的派生量:

  • fixations.csv:把连续采样流切成「凝视」单位,每个凝视有起止时间与位置,还附带归一化瞳孔面积、当时的窗宽窗位、缩放与平移状态。最后这几项容易被忽略——它们记录了医师在读数过程中调整显示参数的动作,对研究「人怎么改变观察条件」有独立价值。
  • anomaly_location_ellipses.csv:人工画出的异常定位椭圆,坐标为 xmin/ymin/xmax/ymax,另有一列 certainty,取值 0 到 5。这是 REFLACX 用来验证「眼动能否定位病灶」的对照标签。
  • chest_bounding_box.csv:围绕肺与心影的胸部边界框,用来把眼动坐标从屏幕坐标系换算到解剖坐标系。
  • timestamps_transcription.csv 与 transcription.txt:前者是逐词带时间戳的口述文本(母库说明是语音识别生成后人工校正),后者是可读全文。

四者合起来构成一条完整链条:原始注视 → 凝聚成凝视 → 用口述词的时间戳给凝视打上语义 → 用椭圆和胸廓框把凝视落到解剖位置上。这条链条本身比任何单一文件都重要,因为研究「医师看到什么、说了什么、眼睛停在哪」需要三者对齐,缺一环就只能做较弱的分析。

2.4 EyeGaze 模块的解剖分割

EyeGaze 模块与 REFLACX 模块最大的结构差异在于它带了解剖结构的分割图与边界框。audio_segmentation_transcripts/{dicom_id}/ 下的四张 png 分别是主动脉结(aortic_knob)、左肺、纵隔、右肺:

文件名 解剖区域 对眼动分析的用途
aortic_knob.png 主动脉结 判断凝视是否落在纵隔轮廓的关键点上
left_lung.png 左肺野 肺内异常搜索的主要区域
right_lung.png 右肺野 同上,注意影像左右与解剖左右相反
mediastanum.png 纵隔 心影、气管、肺门所在区域

这四张图是「以图对图」的掩码,尺寸与对应胸片一致,可以直接与眼动坐标做逐像素叠加,得到「这名医师在这张片的这个解剖区停留了多少毫秒」这样的量。REFLACX 模块没有这层掩码,只有胸廓框(肺+心的整体外接矩形),粒度粗一档。这是两个眼动库之间最实质的差别,也是研究解剖区域级注意力分配时优先用 EyeGaze 模块的原因。

需要提醒的是文件名里的 mediastanum 是原目录树的拼写(纵隔的规范英文为 mediastinum),引用路径时必须照抄,不能「顺手改正」,否则脚本找不到文件。

2.5 spreadsheets 目录:唯一跨患者的地方

与患者文件夹同级,spreadsheets/ 存放「与具体患者无关」的表。按目录树,它分成五个子目录加两个散落文件:

位置 内容 为什么要放在这里
spreadsheets/CXR-JPG/ cxr_chexpert.csv、cxr_negbio.csv、cxr_split.csv 全量标签与官方划分,按患者切开会导致巨量重复
spreadsheets/Hosp/ d_hcpcs.csv、d_icd_diagnoses.csv、d_icd_procedures.csv、d_labitems.csv 编码字典表,患者无关
spreadsheets/ICU/ d_items.csv ICU 项目字典表(chartevents 等表的取值含义全在这里)
spreadsheets/REFLACX/ metadata.csv REFLACX 全量 ID 对照
spreadsheets/EyeGaze/ bounding_boxes.csv、eye_gaze.csv、fixations.csv、master_sheet_with_updated_stayId.csv 全量眼动与更新了 stay_id 的主索引
根 cxr_meta.csv、cxr_meta_with_stay_id_only.csv 枢纽表与其只含 stay_id 的裁剪版

这里有两个必须注意的点。第一,字典表不能省。ICU/d_items.csv 定义了 itemid 到项目名与单位的映射,没有它,chartevents.csv 里的 itemid=220045 只是一串数字,你根本不知道那是心率。同理 Hosp/d_labitems.csv 之于 labevents。MIMIC 家族的老手会条件反射地先下字典表,新使用者最容易在这上面卡住。

第二,两个 cxr_meta 不能混用。cxr_meta.csv 是完整版(在原 metadata 上加了 stay_id、in_reflacx、in_eye_gaze 三列),cxr_meta_with_stay_id_only.csv 从名字看是只保留 stay_id 相关列的裁剪版。做三方对齐用完整版,只做影像-病历链接用裁剪版可以省内存,但不要以为裁剪版里也有眼动的布尔列。

2.6 规模数字与其筛选逻辑

这是最容易出错的地方,因为 MIMIC 家族的母库规模与派生集规模相差一到两个数量级。下表把两者并列,避免混淆。

对象 规模 这是「本数据集」还是「源库」
MIMIC-Eye 住院 1,644 本数据集
MIMIC-Eye 胸片 3,689 本数据集
MIMIC-IV 患者 315,460 源库
MIMIC-IV-ED 就诊 447,712 源库
MIMIC-CXR 图像 377,110(其中 PA 位 96,161) 源库
两个眼动父项目各自的患者数 见 §9.1 速查表 父项目(也是本数据集的筛选池)

筛选逻辑只有一句话,出自项目页:「我们只取那些来自 EyeGaze 或 REFLACX 数据集的患者,因为它们提供了以人为中心(human-centered)的数据。」换句话说,纳入标准不是病种、不是年龄、不是住院次数,而是「这个患者曾经被请进读片实验室、坐在眼动仪前看过胸片」。这是一个极其特殊的纳入标准,它对使用者意味着三件事。

第一,这三千余人是曾被招募参与眼动实验的人。母库的招募对象是「在该院做过胸片检查的患者」,所以样本仍属真实临床人群,但参与实验本身需要知情同意与配合,不能排除轻度选择偏倚。

第二,规模上限由眼动库决定。两个眼动库加起来只覆盖这一量级的患者,无论 MIMIC-IV 有多大,本数据集都不可能超过它们。

第三,两库的交集极小。项目页明确写「只有 10 名患者同时存在于两个数据集中」。这意味着 REFLACX 侧与 Eye Gaze 侧的患者几乎完全不相交,两边的数据在统计上基本独立:想比较「五位医师轮读」与「一位医师读」的差异,只能在这 10 人身上做,样本量不足以支撑任何组间检验。

2.7 从三万到三千:纳入与胸片匹配的两级漏斗

整个数据集的构造是两个串联的漏斗,第一个按人筛,第二个按片筛。

第一级漏斗(按人):MIMIC-IV 的全部患者 → 只保留出现在 REFLACX 或 Eye Gaze 中的那些。两个眼动库各自的患者数、它们的交集人数与最终并集人数,见 §9.1 速查表。这里有一处需要核对的算术:两侧人数相加再减去项目页声明的交集,得到的数比官方公布的患者总数多出 35 人。官方没有解释这个差额,§6 把它列为待核项。正文一律采用官方值。

第二级漏斗(按片):上一步那批人的全部胸片 → 只保留能确定所属住院段的那部分。这里的筛选规则出自项目页的 Phase 1 描述,共四步:

  1. 对每一张胸片,先在该患者的住院记录里搜索可能对应的住院段;
  2. 在 MIMIC-IV-ED 的 edstays 表里查每个住院段的入出时间(intime 与 outtime);
  3. 在 MIMIC-CXR-JPG 的元数据表里查这张片的检查日期与时间(StudyDate、StudyTime),得到拍摄时刻;
  4. 若拍摄时刻落在某个住院段的入出时间之间,就确定它的 stay_id;否则继续找下一个。

用作者自己的记号写就是:当 T_start(p, j) < T_CXR(p, i) < T_end(p, j) 成立时,第 i 张片归属第 j 次住院。

项目页承认首轮效果并不好:55.99% 的胸片无法确定 stay_id,原因是很多片是在患者离开急诊之后拍的。作者随后把匹配窗口从「急诊住院区间」放宽到「七天」,多识别出 23.26% 的胸片。两个数字语义不同:前者是首轮失败率,后者是放宽后的相对增益,不能直接相减得最终成功率。作者最终只保留拍摄时刻落在住院区间内的胸片,理由是希望临床信息在时间上贴近影像。

最终落地的数字是 1,683 张有临床链接的胸片,占全部胸片的 45.6%。用 55.99% 的首轮失败率反推会得到约 1,624 张,与 1,683 相差 59 张,说明最终采用的规则与首轮那一版并不完全相同。官方没有交代最终规则的细节,这一处也在 §6 的误读表中列为待核项。

漏斗的实用解读:如果你要做「影像 + 病历」的联合建模,可用样本就是上面那个数;如果你只做眼动与影像,可用样本是全部收录胸片中带眼动的那部分;如果你要三模态齐备,样本量还要再乘上「带眼动」与「有临床链接」两个条件的重叠比例,项目页没有给出这个数字,需要自己在 cxr_meta.csv 上算。

§3 怎么拿到

3.1 三层门槛:账号、培训、协议

MIMIC-Eye 是受限访问(restricted access),不是公开下载,也不是「注册即可」的 credentialed 层级。PhysioNet 的受限访问要走完三步,缺一步都拿不到文件:

  1. 注册 PhysioNet 账号并完成身份核验。PhysioNet 要求填写真实姓名、所属机构、邮箱,并对机构邮箱做验证。个人邮箱注册会被人工审核,周期不定。
  2. 完成 CITI 培训。必须通过协作机构培训计划(Collaborative Institutional Training Initiative,CITI)的「Data or Specimens Only Research」课程,把结业证书上传到 PhysioNet 账号。这一步是所有人类受试者数据访问的通用前置,没有替代路径。
  3. 签署数据使用协议。对 MIMIC-Eye 这类受限数据,要签 PhysioNet Restricted Health Data Use Agreement 1.5.0,并指定一名「responsible researcher」。协议的核心条款是不得再识别、不得转发给未签约者、不得用于商业用途(除非另行获批)。

三步走完之后,项目页会出现下载入口;但即使签了字,若所在地域被平台判定为受法律或政策限制,页面的 Files 区仍会显示「Data Not Available」。这一状态在检索时点实际出现过,也是本项目文件体积无法取得的原因。

3.2 许可证与「一签六引」的叠加约束

许可名称是 PhysioNet Restricted Health Data License 1.5.0。但真正约束使用者行为的不是这一份,而是它叠加在六个父项目各自的协议之上。

PhysioNet 页面在 Parent Projects 一栏写明:「使用本项目时请引用它们。」这六个父项目全部是同一档受限访问,协议文本相同、条款相同,但引用义务是分立的——论文的方法节必须同时列出六条引用,缺任何一条都构成不完整引用。这在实操上意味着参考文献列表会比其他数据集长出五条,投稿时容易超页或被编辑要求精简,需要提前和期刊沟通。

更隐蔽的约束来自版本。页面列出的父项目版本是 MIMIC-IV v1.0 与 MIMIC-CXR-JPG v2.0.0,而这两个项目后来都升过代(MIMIC-IV 已到 v2.2 乃至 v3.1,MIMIC-CXR-JPG 已到 v2.1.0)。PhysioNet 的版本 DOI 是逐版本固定的,签 v1.0 的协议只能拿 v1.0 的文件。如果使用者手上是新版父库,就无法保证与本数据集的行级一致——同一个 subject_id 在新版里可能多了一条 diagnoses 记录,在本数据集里没有。做严格复现时,应该按本数据集声明的版本下载,而不是按「最新版」下载。

3.3 文件体积:一个拿不到的数字

项目页没有披露文件总量与体积。Files 区因区域策略不可见,连文件名清单都看不到,只能从目录树反推格式构成:CSV(绝大多数表)、JPG(胸片)、TXT(DICOM 元数据与转录全文)、PNG(解剖分割)、MP3 与 WAV(读片录音,双格式并存)、JSON(转录结构化)。

从格式构成可以做量级判断,但只能是判断,不能当成事实写:全部胸片若按 MIMIC-CXR-JPG 的常规压缩率,单张数百 KB 量级;REFLACX 的原始注视点按 1000 赫兹计,3,032 个读片子目录每个数万行,是体积的主要贡献者之一;音频双格式并存(MP3 + WAV)意味着同一段录音存了两遍,WAV 是未压缩的,体积约为 MP3 的十倍。规划存储时应预留余量,并准备在下载后按需删掉 WAV 或原始 gaze.csv。

3.4 下载后的第一步:不是解压,是读索引

拿到全量文件后,最省时的起点是三个文件,顺序不能乱:

第一步读 spreadsheets/cxr_meta.csv。这是枢纽表,逐行是一张胸片,列里含 dicom_id、study_id、subject_id、stay_id、in_reflacx、in_eye_gaze。用它先回答「哪些片带眼动」与「哪些片接得上病历」两个问题,把可用的片子筛出来。不要跳过这一步直接遍历患者文件夹——三千多个文件夹里,绝大多数只有结构化病历,没有影像也没有眼动。

第二步读 spreadsheets/ICU/d_items.csv 与 spreadsheets/Hosp/d_labitems.csv。前者把 ICU 表里的 itemid 翻译成项目名与单位,后者把检验表里的 itemid 翻译成检验项目名。没有这两张字典,任何数值列都只是裸数字。这是 MIMIC 家族的传统陷阱,稍后会专门讲。

第三步读 spreadsheets/REFLACX/metadata.csv 与 spreadsheets/EyeGaze/master_sheet_with_updated_stayId.csv。前者是 REFLACX 侧的 ID 对照,把 reflacx_id 与 dicom_id、study_id 连起来;后者是 Eye Gaze 侧的主索引,文件名里的 updated_stayId 表明它已经把 stay_id 补进去了。两张表是进入两个眼动子目录的唯一钥匙——眼动文件按 reflacx_id 或 dicom_id 命名,不直接标注患者编号。

三步做完,使用者手里就有一张「这张片属于谁、有没有眼动、接不接得上病历、去哪个路径找文件」的完整清单,之后所有批量处理都可以围绕这张清单展开。

3.5 一份最小的加载脚本思路

不写具体代码,但描述清楚加载顺序,能省掉大量试错:

先读枢纽表并加两个布尔过滤条件,得到目标胸片列表;再按列表里的 subject_id 到对应患者文件夹取临床表(只取需要的几个 CSV,不要整目录读入);然后按 dicom_id 到 CXR-JPG/s{study_id}/ 取图像;最后若该片 in_reflacx 为真,按 reflacx_id 到 REFLACX/main_data/ 取凝视与转录,若 in_eye_gaze 为真,按 dicom_id 到 EyeGaze/ 取分割掩码与眼动。

这个顺序的关键在于先索引后取数。反过来做(先遍历文件夹、边读边判断)在小规模上无感,在三千患者、数万文件上会反复做磁盘寻道,且极易在某个缺子文件夹的患者身上抛异常中断。用索引驱动的写法,缺什么就跳过什么,容错天然存在。

3.6 合规边界:三类不能再识别风险

协议条文是通用的,但这份数据有几个具体的再识别面,使用前应当明确知道自己不会碰:

第一类是时间戳。MIMIC 家族的日期是移位后的(每位患者有一个固定的随机偏移),但同一患者内部的相对时间关系保留。眼动数据的逐毫秒时间戳与住院时间叠加后,理论上能精确定位「某人在某次住院的哪一天做了读片实验」。若再叠加公开的医院排班或设备日志,存在小概率再识别路径。

第二类是音频。Eye Gaze 与 REFLACX 模块都带读片录音(audio.mp3、audio.wav),口述内容里可能出现患者姓名、床号、日期等识别信息。母库称做了转录校正,但音频本身是否做过彻底脱敏,项目页没有说明。任何对外发布的演示都不应播放原始音频。

第三类是机构与医师身份。REFLACX 只有五位医师,Eye Gaze 只有一位。在单中心、单医师的小样本里,若同时公布其读片风格指标(注视时长分布、扫视幅度),与公开的放射科医师履历做交叉,存在推断身份的可能。论文报告个体层面指标时应做聚合。

这三条不是协议原文,而是从数据形态推出的风险面,属使用者在协议之上应自行加设的边界。

§4 质量与已知问题

4.1 预处理政策:只修「严重问题」,其余全部继承

判断一个派生数据集的质量,第一件事是看它动了什么、没动什么。MIMIC-Eye 的政策写得非常直白,在 Usage Notes 里原样声明:

本数据集只对 REFLACX 与 EyeGaze 的数据做了最小限度的预处理,用于修复 Method 部分 Phase 2 所描述的严重问题。对其他父数据集没有做任何预处理。MIMIC-Eye 中呈现的缺失数据与数据质量问题继承自父数据集。

这段话把责任边界划得很清楚,也把难度转移给了使用者。它对使用者的实际含义有三点:其一,不能假定某张表已经清洗过,MIMIC-IV 里那些著名的脏数据(labevents 的单位混用、chartevents 的重复记录、prescriptions 的自由文本剂量)在这里一模一样存在;其二,不同父库之间的编码体系没有统一,比如性别编码、诊断编码的版本差异,需要自己对齐;其三,任何跨研究的结果比较都必须先确认双方用的是同一套预处理,否则差异可能全来自清洗策略。

这种「最小干预」的立场有其合理性——作者的理由是「既提供灵活性,又保证与父数据集的一致性」。灵活性给到了,代价是每个使用者都要付一次重复建设。

4.2 作者实际修的两处

Phase 2 描述的预处理只有两处,都针对「会直接毁掉数据可用性」的问题。

第一处是 REFLACX 的标签版本合并。 REFLACX 的病例编号分属两版标签(v1 与 v2,具体条数见 §9.1),两版对同一病灶的圈定规则不同,直接混用会导致标签语义漂移。作者的做法是「访谈放射科医师,用他们的意见融合两版标签,解决冲突」,融合之后剩下 21 类病变。这一步是 MIMIC-Eye 唯一称得上「新增标注」的动作——不是重新标注,而是在两套已有的圈法之间做仲裁。它的质量取决于受访医师的人数与仲裁规则,项目页没有交代这两点,所以这 21 类的可靠性只能算「依惯例推定」。

第二处是 Eye Gaze 的 DICOM ID 截断修复。 Eye Gaze 的 eye_gaze.csv 里有一部分 DICOM_ID 被截掉了末五位,导致无法对应到任何胸片。修复规则是:若同一记录同时存在错误 ID 与有效 ID,删掉错误那条;若只有错误 ID,就用有效 ID 替换。这是机械修复,风险不大,但说明母库的 ID 字段存在系统性写入缺陷——用 Eye Gaze 侧数据时应自行复核 ID 唯一性与长度。

除此之外,MIMIC-IV、MIMIC-IV-ED、MIMIC-CXR、MIMIC-CXR-JPG 四个父库「一个字段都没动」。这一句要按字面理解。

4.3 假设—支持—反对:五个关键判断的置信度

派生数据集的很多关键性质没有官方表述,只能推断。下表把五条最常被问到、也最容易拍脑袋的推断摊开,逐条给出支持证据与反对证据。

假设 支持证据 反对证据 结论强度
患者总数就是两库并集 项目页逐字给出总数,并说明其中分别来自 REFLACX 与 EyeGaze 的人数 2,199 + 1,038 − 10 = 3,227,比官方总数多 35;官方未解释 B(数字为官方值,加和关系存疑)
有临床链接的那批胸片是按「拍摄时刻落在住院区间」筛出的 项目页给出四步匹配流程与不等式 按 55.99% 失败率反推得约 1,624 张,与官方口径差 59;最终规则未公布 B
两库交集只有 10 人 项目页逐字写「only 10 patients exist in both datasets」 与上一条的加和差额矛盾;若交集为 45 人则加和恰好自洽 C(单一来源,且与自身算术冲突)
眼动记录与胸片采集不同期,只与读片时刻同期 母库为独立读片实验,医师在实验室内看已采集的胸片;数据带实验内的逐词时间戳 项目页未明说两者的时间关系 A(由采集设计可确证)
目录树七个模块与 Data Description 的七段描述一一对应 目录树逐行列出七个文件夹 方法段称「七个 MIMIC-IV 模块」,把 REFLACX 与 EyeGaze 也算作 MIMIC-IV 模块;且 Core 子文件夹实际名为 Hosp/、CXR 实际拆成 CXR-JPG/ 与 CXR-DICOM/ B(结构对,命名对不上)

这张表里最需留意的是第三行。交集人数直接决定能不能做跨库比较——按官方口径的 10 人算,任何「五位医师对一位医师」的对比都只是轶事;若真实交集是 45 人,仍属小样本,但性质不同。项目页自相矛盾,只能按最保守的 10 人规划。

4.4 缺失数据的三层结构

MIMIC-Eye 的缺失不是随机的,而是分层结构化的,不同层的缺失原因与处理方式完全不同。

第一层:患者层缺失。 三千余名患者里,不是每人都进过 ICU,也不是每人都走过急诊。ICU/ 与 ED/ 子文件夹的缺席是正常的、有意义的缺失——它表示该患者没有这段就医经历,不是数据丢失。用 os.path.exists 判断存在性即可,不要当成 NaN 处理。

第二层:片层缺失。 全部胸片里有约 54.4% 没有 stay_id。这批片子的影像与眼动都在,只是接不上临床记录。做纯影像或纯眼动任务时它们是有效样本;做影像 + 临床时必须排除,排除之后样本近乎腰斩。

第三层:字段层缺失。 即使在拿到 stay_id 的那批片子里,临床字段仍有各自的缺失模式。项目页提到的十个临床特征——Core 模块的年龄与性别,ED 分诊表的体温、心率、呼吸频率、血氧饱和度、收缩压、舒张压、疼痛评分、分级(acuity)——其中疼痛评分在急诊实践中缺失率很高(患者无法表达或未评估),分级在不同年份的录入规范也不一致。这层缺失继承自 MIMIC-IV-ED,本数据集不做任何填补。

三层缺失叠加的实际后果是:想做「三模态齐备」的实验,可用样本量会远小于「有临床链接」的那一部分。项目页没有给出这个交集的数字,必须在 cxr_meta.csv 上自己算,这是开始任何建模之前的第一道可行性与样本量评估。

4.5 眼动数据自身的质量问题

眼动信号的信噪比问题在母库层就已存在,本数据集原样继承。四类典型问题:

校准漂移。 EyeLink 1000 Plus 采用十三点序列校准,母库说明校准在会话开始、休息后、每 25 例未校准后、或数据质量问题可修复时进行。这意味着两校准点之间的记录存在缓慢漂移,越往后越偏。远程模式(医师额头贴贴纸、头部可小幅移动)比头戴式更容易漂。使用者若做跨被试比较,应检查每段记录的起始注视点是否落在中心十字附近。

凝视时长分布的被试间差异。 五位医师的扫视策略可能差异巨大:有人习惯快速全局扫视后定点,有人习惯逐区细读。在小样本上,模型很容易学到「这是医师 A 的风格」而不是「这是病灶的特征」。这也是为什么眼动预测模型的评测必须在留出被试的划分下做,而不是随机划分样本。

瞳孔数据的解释歧义。 REFLACX 的 fixations.csv 带归一化瞳孔面积。瞳孔面积受光照、认知负荷、疲劳三重因素影响,在长时间读片中,疲劳导致的瞳孔变化可能与认知负荷混在一起。把它当作「认知负荷的代理指标」需要额外的实验设计控制,单靠这份数据无法分离。

数据丢弃。 母库报告有一小批编号因质量被丢弃了眼动数据、但保留了标注。MIMIC-Eye 沿用这批数据,意味着「有标注无眼动」的样本是可能存在的——做多模态训练时需按 gaze_data/ 是否存在做运行时判断。

4.6 与「同一批数据、另一条接入路线」对照

库内另有一条把胸片接到 MIMIC-IV 的路线:MIMIC-CXR-Ext-MIMIC-CXR-DB(rid=927),它按住院窗口(hadm_id)把 MIMIC-CXR-JPG 的全量胸片关联到 MIMIC-IV,最终得 14.6 万张院内胸片。两条路线的目标相似、方法不同,值得并排看:

维度 MIMIC-Eye MIMIC-CXR-Ext-MIMIC-CXR-DB
关联主键 stay_id(住院段,偏急诊) hadm_id(住院)
关联窗口 急诊住院入出时间,首轮 55.99% 失败 住院时间窗
覆盖患者 千级(受眼动库限制) MIMIC-IV v3.1 全库
覆盖胸片 数千张,其中约四成半可链接 14.6 万张院内胸片
额外维度 眼动、报告、急诊分诊 ICD-10 诊断、检验面板、12 本体三元组

两者的分工是:要「大规模影像 + 病历」,用 rid=927;要「小规模影像 + 病历 + 眼动」,用本数据集。没有哪条更优,只有覆盖维度与样本量的取舍。

4.7 一句话的质量结论

MIMIC-Eye 的数据质量等于它的六个父库的平均水平减去一层对齐损失。它没有引入新的噪声源(除了一次标签仲裁与一次 ID 修复),但也没有消除任何旧噪声。使用者拿到的是一个忠于上游、组织良好、但完全不干净的素材包。

§5 能做什么

5.1 作者给出的唯一方向:融合,而不是替换

项目页的 Usage Notes 把用途说得很克制:「本数据集包含多种输入与标签,建议使用者用不同的输入与标签组合去做多模态学习、多任务学习与对比学习。」没有指定任务,没有定义指标,只给了一个例子——MDF-Net。

MDF-Net 的全称是 Multimodal Dual-Fusion Network for abnormality detection using CXR images and clinical data,意为「用胸片与临床数据做异常检测的多模态双融合网络」。从名字可以看出它的结构:两条支路分别吃图像与临床特征,在中段做融合,用于判断胸片是否存在异常。作者在项目页引用了这篇方法论文(参考文献编号 22)并给出代码仓库,但页面没有给出 MDF-Net 在本数据集上的任何分数。

这一点必须讲清楚:MIMIC-Eye 没有官方基线。 想引用「MDF-Net 在 MIMIC-Eye 上的 AUC 是多少」是查不到的,只能自己复现。这对论文写作是实质障碍——没有公认基线,任何新方法的提升幅度都无法与已有工作报告对比。

5.2 五类可做的任务

从数据形态出发,能做的任务远多于作者点名的这三类。下表按「输入 → 输出」列出五类,标出样本量与主要障碍。

任务 输入 输出 / 监督 可用样本 主要障碍
眼动显著性预测 胸片图像 凝视热图或注视序列 全部胸片中带眼动的部分 仅五到六位医师,留出被试后训练信号稀薄
弱监督病灶定位 胸片 + 凝视热图 异常椭圆 同上,且需有椭圆标注 眼动定位与真实病灶的相关性本身是待验证命题
影像 + 临床异常分类 胸片 + 十项临床特征 CheXpert/NegBio 标签或报告推断标签 有临床链接的片子 标签由规则器生成,非人工金标准
跨模态检索 胸片 ↔ 转录 ↔ 临床特征 配对关系 带转录的读片子集 转录是口述而非正式报告,词汇与报告体裁不同
临床特征补全 / 表征学习 结构化临床表 自监督或掩码重建 全部患者的结构化表 与影像无关,实为 MIMIC-IV 子集任务

第一类与第二类最独特,因绝大多数胸片数据集没有过程数据。第三类与第五类用其他 MIMIC 派生集同样能做,此处不提供额外优势。第四类的价值在于配对关系——同一张胸片既有正式放射报告(来自 MIMIC-CXR),又有医师读片时的口述原话(来自 REFLACX 转录),两种文本描述同一张图,构成天然的对比学习正样本对。

5.3 一个最小可执行示例:从一张片到一个数据样本

下面用一个具体的例子走完整条链路,帮助理解各文件如何咬合。设想研究者想构建一个「胸片 + 分诊生命体征 + 凝视热图」的三输入样本。

第一跳,定位候选片。 打开 spreadsheets/cxr_meta.csv,筛 in_reflacx 为真且 stay_id 非空的行。这一步同时保证了三件事:这张片在 REFLACX 里有眼动、这张片接得上某次急诊住院、这张片的元数据齐全。

第二跳,取影像。 用该行的 study_id 与 dicom_id 拼出路径 patient_{subject_id}/CXR-JPG/s{study_id}/{dicom_id}.jpg。JPG 已经是可读格式,不需要 DICOM 解码;若需要原始窗宽窗位信息,去 CXR-DICOM/s{study_id}.txt。

第三跳,取临床特征。 用该行的 stay_id 到 patient_{subject_id}/ED/triage.csv 查分诊评估,得到体温、心率、呼吸频率、血氧、收缩压、舒张压、疼痛、分级八项;到 patient_{subject_id}/Hosp/ 下的 admissions.csv 取性别与年龄相关的入院信息。这一步能成立,正是因为 cxr_meta.csv 把影像 ID 与 stay_id 绑在了一起。

第四跳,取眼动。 用 spreadsheets/REFLACX/metadata.csv 把 dicom_id 翻成 reflacx_id,再到 patient_{subject_id}/REFLACX/main_data/{reflacx_id}/fixations.csv 取凝视坐标,并读同目录的 chest_bounding_box.csv 做坐标归一化。若需要原始采样流,改读 gaze_data/{reflacx_id}/gaze.csv。

第五跳,取标签。 用 dicom_id 到 spreadsheets/CXR-JPG/cxr_chexpert.csv 查 14 类标签,或到 main_data/{reflacx_id}/anomaly_location_ellipses.csv 取人工椭圆做定位监督。

五跳走完,一个样本就齐了。整个过程中,cxr_meta.csv 的 stay_id 是第一跳与第三跳之间的唯一桥梁;没有它,第二跳之后的影像与第三跳之后的临床数据永远碰不到一起。这是整份数据集设计的核心关节,也是它区别于「六个压缩包」的地方。

5.4 时间语义:别把三段时间当成一段

新手最容易犯的错,是把眼动时间戳、影像拍摄时间与住院时间当作同一个时间轴。事实上这里有三个完全不同的时间段:

时间段 时长量级 由谁记录 用途
胸片拍摄 毫秒到秒 MIMIC-CXR 的 StudyDate/StudyTime 决定这张片归属哪次住院
医师读片 数十秒 REFLACX 逐毫秒注视点与逐词时间戳 决定凝视序列的先后
住院 小时到天 MIMIC-IV-ED 的 intime/outtime 决定临床特征的时间窗

三者叠起来才构成一个样本的完整时间坐标:患者在某个住院日的某个时刻拍了这张片,数年后某位医师在实验室里用几十秒读了它。 眼动数据与读片严格对齐(毫秒级),但与胸片采集之间隔着数年;临床特征与胸片的时间关系由 stay_id 的窗口保证(小时级)。研究「医师看到这个病灶时瞳孔是否放大」是在读片时间轴上提问;研究「这个病人的血氧是否预测了胸片异常」是在住院时间轴上提问。两条轴不能混用。

5.5 不适合用它做的事

以下四类任务不适合用这份数据集,列出来是为了省掉试错:

训练通用胸片分类器。 样本量太小(数千张,且分布不均衡),且筛选标准是「此人参加过眼动实验」,不代表临床人群。通用分类应该用 MIMIC-CXR-JPG 的全量或 CheXpert。

大规模队列研究。 患者数与住院次数都只到千级,做任何需要亚组分析的流行病学研究都会被样本量卡死。

验证「眼动优于图像」这类强命题。 只有五到六位医师的眼动,无法代表放射科群体的视觉策略;跨被试泛化能力无法在这份数据上被严肃评估。

需要放射学报告全文的生成任务。 MIMIC-Eye 的 CXR-DICOM 目录只存元数据,正式的放射报告文本并未作为独立表随目录树展开;能拿到的是 REFLACX 的口述转录,口述与报告在体裁、句法、信息密度上都不同,不能替代报告生成任务的监督文本。

§6 常见误读与引用陷阱

6.1 误读表

下表列出检索与引用这份数据集时最常见的说法,逐条给出实际口径与证据位置。

常见说法 实际口径 证据位置
「MIMIC-Eye 有三十余万名患者」 三十余万是 MIMIC-IV 源库,本数据集纳入的是其中的千级子集,纳入标准为「出现在两个眼动库之一」 项目页 Data Description「The original MIMIC-IV dataset includes 315,460 patients. For MIMIC-Eye, we only retrieve patients that are either from the EyeGaze or REFLACX datasets」
「MIMIC-Eye 有三十七万张胸片」 三十七万是 MIMIC-CXR 源库,本数据集收录的胸片是千级 同上;本数据集规模段逐字给出患者、住院、胸片三个数
「它是 MIMIC-IV 的一个版本或分支」 不是分支,是独立项目;发布团队不是 MIT 的 MIMIC 团队,而是 QUT 团队,与 MIMIC-IV 无版本继承关系 作者列表与 PhysioNet Parent Projects 关系(父项目,非分支)
「它有同行评审的数据论文」 没有。PhysioNet 页面 Published paper 字段为空;Google Scholar 把 PhysioNet 版本本身当著录条目;QUT ePrints 登记为 Other Contribution、Refereed: No PhysioNet 页面;QUT ePrints 记录 239699
「REFLACX 的全称是「放射科眼动」之类」 REFLACX 的全称是 Reports and eye-tracking data for localization of abnormalities in chest x-rays,即「胸片异常定位的报告与眼动追踪数据」,不是缩写自某个机构名 REFLACX 母库 PhysioNet 页面标题
「Eye Gaze 就是 REFLACX」 是两个独立母库。REFLACX 五位医师、带椭圆与转录;Eye Gaze 一位医师、带解剖分割与音频。两者交集患者极少 项目页 REFLACX 与 EyeGaze 两段说明;母库页面
「三千多张胸片都能接上病历」 只有约 45.6% 能接上,其余胸片只有影像与眼动 项目页 Phase 1 描述的匹配失败率与最终可链接数
「RRID SCR_007345 是本数据集的唯一标识」 这是 PhysioNet 平台级通用 RRID,多个父项目共用;唯一标识应用 DOI 父项目页面的 RRID 字段与本数据集一致
「用它可以复现 MDF-Net 的论文结果」 MDF-Net 是方法论文,项目页未给出它在本数据集上的任何分数,无法复现原文数字 项目页参考文献 22 仅列题名,Usage Notes 只说「示例」
「它是开放的,注册就能下」 受限访问,需注册 + CITI 培训 + 签署 Restricted Health Data Use Agreement,且所在地区可能因政策不可见 项目页 Access 与 License 字段;Files 区状态
「下载时只需要签 MIMIC-IV 的协议」 需要同时满足六个父项目各自的协议与引用义务 项目页 Parent Projects「Please cite them when using this project」
「这份数据已经清洗过了」 只对 REFLACX 与 EyeGaze 做了最小修复,其余四个父库零预处理,缺失与质量问题全部继承 项目页 Usage Notes 原文

表中前两行是本项目历史上反复出错的类型——把源库规模当成派生集规模。二者相差两个数量级,一旦写进论文的方法节,审稿人第一轮就会拦下。

6.2 技术陷阱

坑点 1:两套 stay_id 同名不同义。 MIMIC-IV-ED 有自己的 stay_id(急诊就诊段),MIMIC-IV ICU 也有自己的 stay_id(ICU 住院段),两者取值空间不重叠。cxr_meta.csv 里的 stay_id 按作者表述是接到 ED 侧的那一套。若拿它去 ICU/icustays.csv 里做关联,会得到一个「关联成功但语义全错」的结果集——行数看起来正常,内容却指向无关的患者。防范办法:先确认目标表的 stay_id 来自哪个模块,再做关联。

坑点 2:字典表的位置。 d_items.csv 在 spreadsheets/ICU/ 下,d_labitems.csv 在 spreadsheets/Hosp/ 下,不在各自的模块目录里。若按「进 patient 文件夹找」的思路,会觉得 ICU 表里的 itemid 无解。字典表是跨患者共享的,只能到 spreadsheets/ 找。

坑点 3:mediastanum 的拼写。 EyeGaze 模块的纵隔分割图文件名是 mediastanum.png,规范英文应为 mediastinum。按规范拼写写路径会找不到文件,且报错信息只显示「文件不存在」,很容易误判为数据缺失。

坑点 4:胸片左右与解剖左右相反。 影像学惯例是面对患者,图像的左侧对应患者右肺。EyeGaze 的 left_lung.png 与 right_lung.png 是按解剖命名还是按图像方位命名,项目页未说明。做左右侧别的分析(如「左侧胸腔积液是否更容易吸引注视」)之前必须先验证一次:挑一张已知有单侧病变的片,看注视点落在哪张掩码上。

坑点 5:眼动坐标的参考系。 凝视坐标是屏幕坐标,胸片在屏幕上的位置、缩放、平移都会被医师在读数过程中调整(fixations.csv 里记录了缩放平移状态)。直接拿屏幕坐标去对应图像像素会系统性偏移。正确做法是先按 fixations.csv 的缩放平移参数把坐标变回图像坐标,再用 chest_bounding_box.csv 做归一化。

坑点 6:转录不是报告。 transcription.txt 是医师口述的逐字转录,含犹豫、自我更正、语气词,与 findings/impression 结构的正式报告完全不同。把它当报告训练文本生成模型会学到口述腔调;把它当报告的「同义表述」做对比学习则是合理的用法,但要接受正样本对在长度与信息密度上的不对称。

坑点 7:中央 cxr_meta.csv 与患者级 CXR-JPG/cxr_meta.csv 的关系。 两个位置都有同名文件,中央那份是扩列后的全量版,患者级那份是切分后的子集。若两处都读并拼接,会出现重复行。以中央那份为准。

坑点 8:in_reflacx 与 in_eye_gaze 是「被该库使用」而非「有眼动数据」。 母库 REFLACX 有 20 个编号因质量丢弃了眼动、保留了标注,所以布尔为真的片子里可能出现没有 gaze_data/ 的情况。做训练时仍需做文件存在性检查。

坑点 9:cxr_meta_with_stay_id_only.csv 不是完整版的轻量替代。 它只保留 stay_id 相关列,不含两个眼动布尔。用裁剪版筛眼动会全部落空。

坑点 10:患者文件夹不等于七个都在。 最常见的是只有 Hosp/ 与 CXR-JPG/ 两个子文件夹的患者。批量脚本必须对每个子文件夹做存在性判断,否则会在第一个缺 ICU 的患者处中断。

坑点 11:编号总数不等于有效读片数。 项目页在描述标签时用编号总数,在描述眼动时用扣除质量不合格后的有效配对数,两处数字不同属正常,不是笔误。详见 §9.1 速查表。

6.3 引用格式

规范的引用应包含三项:数据集本体、PhysioNet 平台、六个父项目。本体引用按页面给定格式为:

Hsieh, C., Ouyang, C., Nascimento, J. C., Pereira, J., Jorge, J., & Moreira, C. (2023). MIMIC-Eye: Integrating MIMIC Datasets with REFLACX and Eye Gaze for Multimodal Deep Learning Applications (version 1.0.0). PhysioNet. https://doi.org/10.13026/pc72-as03

六个父项目中,REFLACX 需要额外引用其期刊论文(Scientific Data 2022 年的那篇),其余五个引用 PhysioNet 条目即可。若在正文中讨论眼动采集协议,还应引用 REFLACX 的原始方法描述;若讨论急诊分诊字段,引用 MIMIC-IV-ED;若讨论胸片标签,引用 MIMIC-CXR-JPG。

§7 在生态中的位置

7.1 MIMIC 派生家族的五种派生态

MIMIC-IV 自 2020 年发布以来,围绕它长出了一个庞大的派生生态。把这些派生集按「改变了什么」分类,能看清 MIMIC-Eye 站在哪一格。

派生态 改变的对象 代表 与 MIMIC-Eye 的关系
标签派生 给已有影像加结构化标签 MIMIC-CXR-JPG(CheXpert/NegBio) MIMIC-Eye 直接继承了这一层
像素派生 给已有影像加分割、检测框、病灶掩码 MIMIC-CXR-Ext-ILS(指令引导病灶分割) 同类目的像素级扩展,但不含眼动
文本派生 把报告改写成问答、指令、合成语料 MIMIC-Ext-CXR-QBA(VQA 三元组) 文本侧扩展,与 MIMIC-Eye 的转录侧互补
嵌入派生 把影像压成向量 image-embeddings-mimic-cxr(4,096 维嵌入) 计算侧的轻量化路径,与 MIMIC-Eye 无关
关联派生 把不同来源按人/次/时间对齐 MIMIC-Eye、MIMIC-CXR-Ext-MIMIC-CXR-DB MIMIC-Eye 属于这一类,且是唯一引入眼动的

五种派生态里,前四种都是在单一模态内部「加密」——加更多标签、更细的掩码、更多的文本、更省算力的表示。第五种不加密,而是「接线」:把原本平行的两条数据流按主键钉在一起。MIMIC-Eye 的全部价值就在这条接线上,而它接的这条线(眼动)在整个家族里是独一份。

7.2 眼动数据在医学影像研究中的位置

眼动追踪进入医学影像研究不是一个新方向。放射科医师的视觉搜索行为在认知科学里被研究了三十余年,早期工作关注「专家与新手的扫视模式差异」,中期关注「视觉搜索的隧道效应与满意度搜索」,近十年随着深度学习兴起,焦点转向「能否用眼动数据改善模型」。

这条研究线索上的关键命题是:医师的凝视是否携带了图像标签之外的定位信息。 如果一张胸片被标为「有气胸」,标签只告诉你「有」,不告诉你「在哪」;而医师找到气胸时的凝视序列,隐含了「他先看了肺尖、然后移向膈肌上缘、最后定在某个位置」这一过程。若能从凝视里反推出病灶位置,就相当于用极低成本获得了弱监督定位标签,绕开了昂贵的人工勾画。

REFLACX 的设计正是为了验证这个命题:它同时提供凝视序列与人工画的异常椭圆,让研究者能直接检验「凝视热图与人工椭圆的吻合度」。MIMIC-Eye 在这个方向上不新增证据,但它把一个此前缺失的变量加了进来——同一个病灶,不同临床背景下的医师会不会看得不一样。 例如一个血氧 88% 的急诊患者,其胸片上的异常是否比一个血氧正常者的同位置异常更容易被医师扫到?这个问题需要凝视与临床特征同时在场,而此前没有公开数据集能满足。

7.3 库内互链:各条边各自解决什么

下面列出库内与本数据集有实质关联的条目,每条说明「为什么该互链」而不是泛泛的「同域」。

上游母库(六条中的五条在库内已有条目)

  • MIMIC-IV(rid=4):本数据集 Hosp 与 ICU 两个模块的直接来源。它的条目覆盖三十余万患者的完整字段字典,本数据集未重复这些内容,使用者查字段定义应回到该条。
  • MIMIC-CXR(rid=16):CXR-DICOM 模块与放射报告文本的来源。想看报告文本样本、想了解 DICOM 结构,去该条。
  • MIMIC-CXR-JPG(rid=617):CXR-JPG 模块、CheXpert/NegBio 标签表与官方划分的直接来源,也是 cxr_meta.csv 扩列前的基底。这是与本数据集血缘最近的一条,因为枢纽表就长在它的 metadata 上。
  • MIMIC-IV-ED(rid=567):ED 模块与急诊分诊八项生命体征的来源,也是 stay_id 匹配规则里 edstays 表所在。
  • REFLACX(rid=623):眼动采集协议、五位医师、椭圆与转录的权威来源。REFLACX 回答「眼动长什么样」,MIMIC-Eye 回答「眼动接在谁身上」。

平行关联路线

  • MIMIC-CXR-Ext-MIMIC-CXR-DB(rid=927):同样把胸片接到 MIMIC-IV,但走 hadm_id 路线、覆盖十四万余张院内胸片。与 MIMIC-Eye 构成「大规模宽覆盖」与「小规模带眼动」的对照,已在 §4.6 并排比较。

同族派生(按派生态分布)

  • MIMIC-CXR-Ext-ILS(rid=616):像素派生的代表,提供指令引导的病灶分割对。与 MIMIC-Eye 的关系是「若要用凝视作弱监督,ILS 的人工掩码是现成的对照真值」。
  • MIMIC-Ext-CXR-QBA(rid=926):文本派生的代表。MIMIC-Eye 提供口述转录,QBA 提供结构化问答,两者可组成「口述 → 问答」的文本增广管线。
  • image-embeddings-mimic-cxr(rid=611):嵌入派生,提供免 GPU 的轻量基线。做眼动预测任务时,可用它的嵌入替代原始图像,降低训练成本。
  • lung-segment-mimic-cxr(rid=613):肺分割派生。它的掩码可用于把凝视坐标投影到肺野,与 EyeGaze 模块的解剖 png 功能重叠但覆盖面更广。
  • MIMIC-IV-ECHO(rid=1094):另一条「影像 + 结构化测量」的匹配子集路线,但模态是超声、无过程数据。与 MIMIC-Eye 同属「匹配子集」类别。
  • MIMIC-IV-Note(rid=47):本数据集不含临床自由文本笔记(只有放射报告与口述转录)。若研究要接出院小结,需另行获取。

7.4 与「眼动 + 胸片 + 病历」之外的可能性

还有一类潜在用途尚未被作者提及:用眼动作为临床推理过程的可解释性证据,反过来审计影像模型。

主流影像模型的可解释性方法(类激活图、显著性图、注意力权重)产出的都是「模型看了哪里」的热图,但这些热图与「医生看哪里」的热图是否是同一回事,长期缺乏对照。有了 MIMIC-Eye,可以直接把模型注意力热图与 REFLACX 凝视热图做空间相关分析:相关高说明模型学到的策略接近人类,相关低则说明模型走了捷径。这类审计在影像模型进入临床前的评估里越来越被重视,而它需要的数据正是「同一张片上的两套热图」——一套来自模型,一套来自人。这一用途不需要任何新标注,只需要把已有的两部分接起来,而这恰好是本数据集完成的事。

7.5 生态位的一句话

MIMIC-Eye 不属于任何一条主流派生方向的「更优版本」,它是 MIMIC 派生家族里唯一的「过程数据接入点」。它的生态位不是替代谁,而是让「医师怎么读」这件事第一次能以结构化形式与「病人是谁」并存于同一条主键上。

§8 总结

8.1 适用与不适用

适合用它的场景:研究对象是「医师读片过程」而非「影像本身」;需要同一张胸片上的凝视序列与临床背景同时在场;能接受千级样本与受限访问的合规成本;团队里有做眼动信号处理的经验。

不适合的场景:目标是训练通用影像模型;需要大规模队列;需要官方基线做方法对比;需要现成的干净数据;需要放射报告全文生成。

8.2 三句话

第一,MIMIC-Eye 不生产数据,它生产关系——把六个已经公开的 PhysioNet 项目按患者钉成一棵树,并用三列元数据完成眼动、影像与病历的三方对齐。

第二,它的价值与它的局限是同一件事:因为完全忠于上游,所以拿到手的数据干净程度与母库一致;也因为没有做任何清洗,使用者必须自己承担全部预处理。

第三,它是目前公开数据里少数几个能回答「同一个病灶,在不同临床背景下会不会被看得不一样」的素材,但答案取决于使用者能否在样本很小、医师很少的条件下构造出稳健的评测设计。

§9 附录

9.1 关键数字速查

指标 数值
版本 1.0.0(2023-03-23)
DOI 10.13026/pc72-as03
患者 3,192
住院 1,644
胸片 3,689
有临床链接的胸片 见正文 §2.7(约 45.6%)
REFLACX 侧患者 2,199
Eye Gaze 侧患者 1,038
两库交集患者 10(官方口径,与加和差额 35 冲突)
REFLACX 编号总数 / 有效配对 3,052 / 3,032
标签融合后病变类别 21
临床特征数 10(Core 2 + ED 分诊 8)
首轮 stay_id 匹配失败率 55.99%
放宽至 7 天窗口的增益 23.26%
目录层级 根 / patient_{subject_id} / 模块 / 文件
模块数 7
眼动设备 EyeLink 1000 Plus,25 mm 镜头,远程模式
眼动采样率 1000 Hz
父项目数 6

9.2 缩写表

缩写 全称 中文
MIMIC Medical Information Mart for Intensive Care 重症监护医学信息数据库
CXR Chest X-Ray 胸片
ED Emergency Department 急诊科
ICU Intensive Care Unit 重症监护病房
Hosp Hospital 住院(MIMIC-IV 的非 ICU 住院模块)
REFLACX Reports and eye-tracking data for localization of abnormalities in chest x-rays 胸片异常定位的报告与眼动追踪数据
DUA Data Use Agreement 数据使用协议
CITI Collaborative Institutional Training Initiative 协作机构培训计划
DICOM Digital Imaging and Communications in Medicine 医学数字成像与通信标准
JPG JPEG 图像格式 有损压缩图像格式
CheXpert 一套胸片 14 类标签的标注规则集 —
NegBio 一套基于否定检测的胸片标签规则器 —
PA Posterior-Anterior 后前位(胸片投照体位)
AP Anterior-Posterior 前后位
gaze 注视点原始采样 眼动原始信号
fixation 凝视(眼睛在一点上的稳定停留) 注视
saccade 扫视(两次凝视之间的快速移动) 扫视
pupil dilation 瞳孔扩张 —
attention map 注意力热图 —
saliency 显著性 —
VQA Visual Question Answering 视觉问答
QUT Queensland University of Technology 昆士兰科技大学
FCT Fundação para a Ciência e a Tecnologia 葡萄牙科学技术基金会
IRB Institutional Review Board 机构审查委员会
RRID Research Resource Identifier 研究资源标识
DOI Digital Object Identifier 数字对象标识

9.3 使用前检查清单

  1. 是否已完成 CITI 培训并上传证书?
  2. 是否已签署 PhysioNet Restricted Health Data Use Agreement 1.5.0?
  3. 是否已确认所在地区可访问(页面 Files 区是否有内容)?
  4. 是否已把六个父项目的引用全部写进参考文献?
  5. 是否已下载 spreadsheets/cxr_meta.csv 并统计 in_reflacx、in_eye_gaze、stay_id 三个字段的联合分布?
  6. 是否已下载 d_items.csv 与 d_labitems.csv 两张字典表?
  7. 是否已确认目标 stay_id 来自 ED 侧而非 ICU 侧?
  8. 是否已验证 EyeGaze 的左右肺掩码与图像方位的对应关系?
  9. 是否已确认眼动坐标的缩放平移还原方式?
  10. 是否已按患者而非按图像划分训练/验证/测试集?

9.4 未覆盖内容

以下内容未纳入,原因一并说明。项目页未提供文件体积与文件清单,故无下载规划的数值。项目页未提供任何实验结果,故无基线分数可列。MIMIC-IV v1.0 与现行版本的字段差异需下载两版做结构 diff,超出资料范围。REFLACX 五位医师的个人特征母库亦未披露。

9.5 检索模板

检索该数据集时,建议使用以下组合,能避开大量同名干扰:

  • 官方名全称加引号,用于精确检索;
  • PhysioNet 项目路径 mimic-eye-multimodal-datasets,用于直达项目页;
  • DOI 10.13026/pc72-as03,用于引文追踪;
  • 「MIMIC-Eye」与「eye tracking」「gaze」联用,用于找到引用它的下游论文;
  • 避免单用「MIMIC eye」,会大量命中眼科影像数据集(如眼底病变相关项目),与眼动无关。

9.6 DAIMS 质量评估

DAIMS(Data and AI Maturity Score,数据与人工智能成熟度评分)从五个维度评估数据集面向 AI 使用的成熟度。下表按该框架逐维打分。

维度 评分 依据
数据可发现性 中 有 PhysioNet 条目与 DOI,可检索;但无独立论文,搜索引擎中的曝光低于有论文的同类数据集
数据可访问性 低 受限访问三重门槛(账号 + CITI + DUA),且地区限制可能直接阻断;无公开样本或演示子集
数据可理解性 中高 目录树结构清晰、有完整文件清单;但无数据字典随附,字段含义需回父库查
数据可互操作性 高 主键沿用 MIMIC 家族标准(subject_id / hadm_id / stay_id / dicom_id),能与父库直接对齐;这是它最强的一维
数据可复用性 中 六父项目协议叠加使引用负担重;无官方划分之外的任务协议,复用者各自为政,结果难横向比较

综合判断:这是一份互操作性突出、可访问性受限、缺少配套文档层的数据集。它在「把东西接起来」这件事上做得比多数派生集好,在「让人用得顺」这件事上做得比多数派生集少。使用者如果把预期设为「拿到一个已对齐的原始素材包」,会满意;如果预期是「拿到一个可跑基准」,会失望。

§10 常见问答

Q1:MIMIC-Eye 和 REFLACX 是什么关系?
REFLACX 是上游母库,MIMIC-Eye 是下游整合集。REFLACX 提供五位放射科医师读胸片时的注视点、凝视、瞳孔面积与带时间戳的口述转录;MIMIC-Eye 把这批眼动数据整包放进自己的目录树,并用 cxr_meta.csv 的 in_reflacx 列与 stay_id 列把它接到 MIMIC-IV 的病历上。两者只是包含关系,不是替代关系。

Q2:为什么三万多患者最后只剩三千多名?
因为纳入标准只有一条:患者必须出现在 REFLACX 或 Eye Gaze 任一数据集中。这两个库本身是围绕眼动采集设计的,参与者是做过读片实验的那批患者,规模远小于 MIMIC-IV 的三十一万余名住院患者。所以三千余名不是抽样偏差造成的结果,而是眼动数据的供给上限。

Q3:3,689 张胸片里为什么只有 1,683 张有临床数据?
胸片要接到临床数据,必须落在某个住院时间段之内。作者给出的匹配规则是拍摄时刻落在急诊住院的入出时间之间,首轮超过半数匹配不上,把窗口放宽到七天之后又多识别了一批。最终能接上的不到一半,其余胸片仍然保留影像与眼动,只是没有对应的临床侧记录。具体比例见 §2.7。

Q4:这个数据集能直接用来训练模型吗?
能,但不能指望开箱即用。作者明确只对 REFLACX 与 EyeGaze 做了最小预处理,其余父库一个字段都没动,缺失值与质量问题全部继承。要训练就得自己决定预处理方案,包括图像尺寸、临床特征标准化、缺失值填补和眼动坐标系对齐。这也意味着不同团队的结果很难直接比较。

Q5:眼动数据是什么设备采的,精度够吗?
REFLACX 母库用的是 EyeLink 1000 Plus,配 25 毫米镜头,远程模式,采样率 1000 赫兹,用十三点序列做校准。MIMIC-Eye 没有重新采集,沿用的是这批原始记录,所以精度上限由母库决定。远程模式允许头部小幅移动,长时间读片后段的数据质量通常低于前段。

Q6:想研究医生看片时的注意力,先从哪张表入手?
先读 spreadsheets/cxr_meta.csv,用 in_reflacx 列筛出被眼动覆盖的胸片,拿到 dicom_id 与 stay_id;再去 patient 文件夹下的 REFLACX/gaze_data 找原始注视点,去 main_data 找凝视与转录。不要一上来就遍历全树,三千多个患者文件夹里绝大多数只有结构化病历,没有眼动。

Q7:眼动数据和胸片的时间是对齐的吗?
眼动数据自身与读片过程严格对齐:注视点带毫秒级时间戳,口述转录逐词带时间戳,凝视表还记录了窗宽窗位与缩放平移状态。但眼动记录与胸片的采集之间隔了数年,不是同时发生。研究注意力模式时同步的是「医师看这张片的那几十秒」,不是「病人拍这张片的那几秒」。

Q8:MIMIC-Eye 有数据论文吗?该引用什么?
截至检索时点没有独立的同行评审数据论文。PhysioNet 页面的 Published paper 字段为空,Google Scholar 把 PhysioNet 版本本身当作著录条目。规范引用应写 Hsieh 等六人、2023 年、PhysioNet、版本 1.0.0、DOI 10.13026/pc72-as03,并按页面要求同时引用六个父项目。

Q9:两个眼动库能不能合起来用?
技术上可以,统计上要谨慎。两库只有极少数患者重叠,采集设备、读片人数、标注体系都不同——REFLACX 是五位医师轮读并画椭圆,Eye Gaze 是一位医师并有解剖分割。合起来做训练集等于把两种不同的观测协议混在一个标签空间里。更稳妥的做法是把两库当作两个子域,做域适应或分别报告。

Q10:为什么文件体积查不到?
项目页的 Files 区按地区做了法律与政策限制,检索时点显示「Data Not Available」,因此文件数、字节数、目录内容都不可见。这不是页面没写,而是平台对非授权访问者隐藏。只有完成授权流程的用户才能看到真实的文件清单。

Q11:能不能只用其中一部分患者,比如只取有 ICU 记录的?
可以,而且很常见。取交集时用三个条件串联:in_reflacx 或 in_eye_gaze 为真、stay_id 非空、对应患者文件夹下存在 ICU/ 子目录。三个条件一叠,样本量会进一步压缩,但换来的是更完整的临床轨迹与更贴近真实场景的多模态样本。做之前先算清楚剩下多少,再决定是否值得。

Q12:如果我要做可解释性研究,这份数据能提供什么别人给不了的?
提供同一张胸片上的两套注意力证据:一套是医师的真实凝视热图,一套是模型的可解释性热图。多数影像数据集只能提供后者加人工勾画,无法提供「人在这张图上的注意力时间序列」。有了这个对照,就能回答「模型是不是在看医生会看的地方」这类审计问题,而不是只看指标高低。

事实清单

  1. 官方全称为 MIMIC-Eye: Integrating MIMIC Datasets with REFLACX and Eye Gaze for Multimodal Deep Learning Applications。
  2. 短名在官方摘要中写作 MIMIC-EYE。
  3. PhysioNet 项目路径为 mimic-eye-multimodal-datasets。
  4. 版本 1.0.0,2023 年 3 月 23 日发布。
  5. DOI 为 10.13026/pc72-as03,另有「latest」DOI 10.13026/kr1c-v245。
  6. 页面标注 RRID SCR_007345,该编号为 PhysioNet 平台级通用标识。
  7. 作者六人:Hsieh、Ouyang、Nascimento、Pereira、Jorge、Moreira。
  8. 主体团队归属昆士兰科技大学,据 QUT ePrints 记录 239699。
  9. 资助来源:UNESCO Chair on AI&XR 与葡萄牙 FCT(2022.09212.PTDC、UIDB/50021/2020)。
  10. 页面 Published paper 字段为空,无独立数据论文。
  11. QUT ePrints 将该数据集登记为 Other Contribution、Refereed: No。
  12. 数据集的患者、住院、胸片三项规模以项目页 Data Description 为准。
  13. 住院次数的限定语是「与胸片关联的」,不是患者全部住院。
  14. 胸片规模含所有可用影像,其中仅约四成半能链接临床记录。
  15. 可链接胸片的具体数目见 §2.6 规模表。
  16. 纳入标准为患者出现在 REFLACX 或 Eye Gaze 之一。
  17. REFLACX 侧与 Eye Gaze 侧的患者数见 §2.6 规模表。
  18. 项目页称两库交集仅 10 名患者。
  19. 两个眼动库的患者数相加再减去声明的交集,结果比官方总数多 35,官方未解释。
  20. 首轮 stay_id 匹配失败率为 55.99%。
  21. 匹配窗口放宽至七天可多识别 23.26% 的胸片。
  22. 每个患者文件夹最多含七个子文件夹。
  23. 根目录另有 spreadsheets/ 存放跨患者表。
  24. 六个父项目为 MIMIC-IV、MIMIC-IV-ED、MIMIC-CXR、MIMIC-CXR-JPG、REFLACX、Eye Gaze Data for Chest X-rays。
  25. 父项目引用版本为 MIMIC-IV v1.0 与 MIMIC-CXR-JPG v2.0.0。
  26. cxr_meta.csv 在原 metadata 上新增 stay_id、in_reflacx、in_eye_gaze 三列。
  27. REFLACX 编号总数 3,052,有效眼动-转录配对 3,032。
  28. REFLACX 标签 v1 覆盖 2,757 例,v2 覆盖 295 例。
  29. 两版标签融合后剩 21 类病变。
  30. 临床特征共十项:Core 两项(年龄、性别)加 ED 分诊八项。
  31. 八项分诊特征为体温、心率、呼吸频率、血氧饱和度、收缩压、舒张压、疼痛评分、分级。
  32. REFLACX 眼动设备为 EyeLink 1000 Plus,25 毫米镜头,远程模式。
  33. REFLACX 采样率 1000 赫兹,十三点序列校准。
  34. REFLACX 由五位放射科医师采集,Eye Gaze 由一位采集。
  35. EyeGaze 模块提供四张解剖分割掩码,命名含 mediastanum(拼写与规范英文不同)。
  36. 许可为 PhysioNet Restricted Health Data License 1.5.0。
  37. 访问需注册、CITI 培训与签署 Restricted Health Data Use Agreement 1.5.0。
  38. Files 区在检索时点因地区限制显示不可用。
  39. 项目页浏览量为 883 次(当前版本等于全部版本)。
  40. 作者建议的配套方法为 MDF-Net,但其在本数据集上的分数未公开。

编辑说明

核验时间 2026-10-18。核验方式:PhysioNet 项目页 1.0.0 与 latest 两次 WebFetch 抓取(含 Abstract、Data Description、目录树、Parent Projects、Usage Notes 逐段提取);REFLACX 母库页面一次抓取(用于设备、采样率、病例计数与期刊信息);一次 WebSearch 确认无独立数据论文(命中 Google Scholar 著录与 QUT ePrints 记录);一次 curl 直接取项目页 HTML 核对 citation 元数据(作者、日期、DOI、Restricted Access 字样)。库内查重经 dedup_gate.py 与 ai_ready_dataset 表两次检索。

双口径与内部冲突登记如下。其一,患者数按「两侧相加减交集」得 3,227,与官方 3,192 差 35,正文采用官方值并以 B 级结论标注存疑。其二,1,683 张可链接胸片无法由 55.99% 失败率直接反推(反推得约 1,624,差 59),说明最终匹配规则与首轮不同,官方未交代。其三,「七个 MIMIC-IV 模块」的措辞与实际目录(含 REFLACX、EyeGaze 两个非 MIMIC-IV 模块,且 Hosp 与 CXR 各拆两处)不一致。其四,项目页称 DICOM 元数据被转成 CSV,但目录树中 CXR-DICOM/ 存放的是 .txt。其五,REFLACX 的 3,052 与 3,032 是编号总数与有效配对数之别,非笔误。

未覆盖内容:文件体积与文件清单(地区限制);MIMIC-IV v1.0 与现行版本的逐字段差异;REFLACX 五位医师的年资与专长(母库未披露);除 PhysioNet 页面外是否存在其他版本著录(网络预算限制未做第四轮检索)。下次复核建议在 PhysioNet 出现新版本或正式数据论文时进行。


相关数据集导航

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

  • ehrxqa — 共享标签:多模态 / 电子健康记录 / X光影像
  • symile-mimic — 共享标签:多模态 / 电子健康记录 / X光影像
  • medical-cxr-vqa-dataset — 共享标签:多模态 / X光影像 / 视觉问答
  • rexvqa — 共享标签:多模态 / X光影像 / 视觉问答
  • mimic-ext-cxr-qba — 共享标签:多模态 / X光影像 / 视觉问答
  • mimic-cxr-ext-mimic-cxr-db — 共享标签:多模态 / 电子健康记录 / X光影像
  • mimic-cxr — 共享标签:多模态 / X光影像
  • health-data-nexus — 共享标签:多模态 / 电子健康记录
  • vqa-med — 共享标签:多模态 / 视觉问答
  • latte-cxr — 共享标签:多模态 / X光影像

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

返回 AI-Ready 数据集