影像的日期可以直接与临床日期相减吗？

不行。DICOM 头里的日期被整体平移了三到十年，平移量按站点固定；GDC 的临床日期则统一换算成距病理诊断日的天数。两套口径各自自洽，相减得到的既不是真实日期差，也不是有意义的间隔。

肝细胞癌 TCGA-LIHC — 九十七例三模态影像与组学配对

Q: 它和 HCC-TACE-Seg 能互相替代吗？

不能。HCC-TACE-Seg 有术前术后配对的增强 CT 与疗效标签，但没有配对组学；TCGA-LIHC 有完整的组学与病理配对，却没有疗效标签，主要以术前基线影像为主。两者的用途不重叠。

信息速览

数据集名称肝细胞癌 TCGA-LIHC — 九十七例三模态影像与组学配对

数据类型影像组学,病理全切片,多组学,元数据,临床配对

规模九十七例（TCIA 集合口径）；GDC 同项目口径为三百七十七例

接入方式https://www.cancerimagingarchive.net/collection/tcga-lihc/

AI 就绪度

TCGA-LIHC 是癌症影像档案馆（TCIA）托管的肝细胞癌影像集合，名称末尾的 LIHC 是 TCGA 的项目编号，对应 Liver Hepatocellular Carcinoma。集合页给出的规模是四级数字：九十七例患者、二百三十七次影像检查、一千六百八十八个序列、十二万五千三百九十七幅图像，合计 56.38 GB，模态为 CT、MR 与 PT。该集合本身不含分割掩膜，也不含临床与基因组数据；后两者在基因组数据共享平台（GDC）上，两侧由同一串 TCGA 患者编号贯通。

它在肝脏方向的资源里位置独特，原因不在规模，而在身份。肝细胞癌的影像诊断依赖一组可以逐条描述的征象——动脉期强化、门脉期廓清、包膜显影、门静脉癌栓——这些征象本身就是 LI-RADS 这套影像诊断体系所评的对象。TCGA-LIHC 把「按这套体系读出来的影像」与「同一个人的分子亚型」和「同一个人的 H&E 切片」绑在了同一串 barcode 上，于是「某种强化方式对应哪类转录组亚型」这类问题第一次有了公开、可复核、可复现的入口。

需要提前说明两条边界。第一，九十七例是很小的样本，而且集合不含任何掩膜，任何需要像素级标注的分割工作都不应从这里出发，该去 LiTS 那类专门的肝脏分割数据。第二，它与库内已有的介入疗效资源 HCC-TACE-Seg 是互补而非替代关系：后者有 TACE 术前术后配对与疗效标签但没有组学，此条有组学却没有疗效标签。一屏速览见下表。

项	值
正式名称	The Cancer Genome Atlas Liver Hepatocellular Carcinoma Collection
简称	TCGA-LIHC
托管方	The Cancer Imaging Archive (TCIA)，美国 NCI
患者数	九十七（TCIA 口径）
检查数	二百三十七次
序列数	一千六百八十八
图像数	十二万五千余幅
体积	56.38 GB
模态	CT、MR、PT
格式	DICOM
分割掩膜	无（集合本体不含）
组学与临床	GDC 同项目，三百七十七例
对齐键	TCGA 患者 barcode（十二位）
当前版本	v5，2020-05-29
许可	CC BY 3.0
DOI	10.7937/K9/TCIA.2016.IMMQW8UQ

§1 它要解决的具体麻烦

1.1 一句话结论：它解决的是「同一个人的片子、切片和基因能不能对上号」

单看影像，可以回答「肝癌长什么样」；单看组学，可以回答「肝癌分几型、谁预后差」。两件事各自都成立，中间那道最贵的问题——「影像上呈现这类强化方式与包膜状态的肿瘤，分子上是否属于某个特定亚类」——任一侧单独都答不了。这个集合的全部价值落在这道题上：它没有追求覆盖尽可能多的腹部扫描，它做的是把已经完成整套分子测量的那批人的术前片子收回来，挂上与分子数据相同的主键。

这个定位同时决定了它的优点与它的短板。优点是配对是结构性的，不是事后拼的：官方页面明确写着影像的 Patient ID 与 TCGA 同一病例的 Patient ID 完全相同，且每位 TCGA 病例在 TCIA 上的基线检查均为术前。短板是影像采集完全服务于「补一份片子」，不服务于影像学自身的研究设计——没有统一协议、没有重建规范、没有病灶标注，也没有按 LI-RADS 重新评过一遍。

把这句话再收紧一次：它不生产影像，它把散落在四家北美机构的常规诊疗影像收拢回来，挂上与分子数据相同的那把钥匙。

1.2 三条常见的错误期待

第一条是把它当成「肝癌影像数据集」。它是「肝癌影像加了分子注释的那一小批人」，九十七例，且不是为了影像任务采的。要更大样本、更多病种的腹部影像，去看通用腹部库；要像素级肿瘤轮廓，去看分割挑战赛数据；要组学配对，才轮到它。

第二条是把它和 GDC 上的同名项目当成同一份东西。GDC 上的 TCGA-LIHC 是三百七十七例的分子队列，涵盖三百七十七例的临床与拷贝数、变异、甲基化、转录组，以及三百六十余例的诊断切片，其中只有约四分之一的人有汇交影像。两个平台共用一个名字，指的是同一个项目下不同覆盖率的两层。

第三条是以为下载下来就靠近可用了。它是一个 DICOM 归档，不是一份特征表：没有器官掩膜、没有病灶轮廓、没有患者级划分、没有统一窗宽窗位。从 56.38 GB 原始 DICOM 到一个能喂进模型的肝癌影像表，中间还差一整套预处理，§5 会展开。

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

下表左列写的是使用者的处境，不是集合的特性。左列对不上，说明它大概率帮不到你。

你的处境	它能帮你什么
想验证某类 CT 或 MR 纹理与 CTNNB1、TP53 等基因状态是否相关	同一批患者的术前影像与 GDC 突变表，按 barcode 直接连
在做肝癌病灶分割，缺一个带分子标签的外部验证集	提供未标注原图，标签需自建；可当目标域，不能当分割真值
需要「影像—病理—基因」三件套做多模态预训练	三件齐全且同主键，是少数不必自行拼凑的来源之一
想研究增强期相、包膜征象与转录组亚型的关系	有增强序列与 GDC 表达谱，但期相靠读头判定，LI-RADS 需自评
需要大样本腹部 CT 训练器官分割	规模不够且无掩膜，应改看腹部器官分割类数据集
想复现某篇肝癌放射组学论文的特征值	barcode 可对齐已核对，但预处理差异会让数值不可比
想研究 TACE 或靶向治疗的疗效与复发	无疗效标签、随访影像极少，做不了；应改看介入疗效专门数据
想找一份能直接训肝癌诊断分类模型的现成数据	无诊断标签、无划分、规模小，不宜作为唯一的标签来源

1.4 它能给到的与给不到的

把「有」与「没有」并排放，比单看任何一边都清楚。一个资源可用不可用，往往不取决于它有什么，而取决于它缺的那一项是不是你的必需项。

维度	有	没有
影像	CT、MR、PT 三模态原始 DICOM	统一协议、统一重建、统一期相标签
标注	外部结果集里的器官分割与派生图	集合本体的像素级病灶掩膜
分子	GDC 上的突变、拷贝数、表达、甲基化、蛋白	集合内部的分子文件（须另去 GDC 取）
病理	GDC 上的 H&E 诊断切片与组织切片	集合内部的切片文件（IDC 另有 DICOM 化副本）
临床	GDC 上的分期、病因、生存	集合内部的结构化临床表（仅有 2016 年快照）
随访	生存与随访天数	成系列的影像随访
疗效	治疗记录字段	结构化的疗效评价与手术/介入/系统治疗结局标签
身份	统一 barcode，跨库可连	除 barcode 之外的跨库影像级主键

1.5 不适合谁：四条边界

如果你的需求是「训练一个能直接跑的肝脏或肝癌分割模型」，它给不了标签。整个集合是一个纯净的 DICOM 归档，没有 SEG、没有 RTSTRUCT、没有 NIfTI 掩膜。会得到一千六百多个序列和零个标注，然后把大部分时间花在勾画上。这类任务应去用带逐例掩膜的肝脏分割数据，库内的 LiTS 是首选，SLIVER07 适合肝实质那一类需求。

如果你的需求是「研究局部治疗的疗效」，它给不了疗效标签。它有术前影像、有分子、有生存，但没有「做了 TACE 之后肿瘤坏死多少」这类结构化终点。这条需求应对应库内的 HCC-TACE-Seg，那边的整条链路就是为这个目的设计的。

如果你的需求是「干净的多中心对照研究」，它给不了协议一致性。官方页面自己写了：为了达到入组目标，组织来自世界各地，因此影像在扫描仪模态、厂商与采集协议上极为异质，且多数影像是常规诊疗的一部分，不是在受控研究或临床试验中采集的。任何依赖固定层厚或固定期相的特征提取都会在这里失效。

如果你的需求是「大规模预训练语料」，它给不了广度。九十七例、单一解剖部位、单一病种，作为预训练语料太小；它更适合当微调与外部验证阶段那个「小而准、带分子标签」的集合。

1.6 三条判断规则

第一条：先确认要的那一层在哪。 原图在 TCIA，分子与生存与切片索引在 GDC，切片文件与云端批量检索在 IDC，器官分割在外部仓库。四层分在四处，这是这个资源最容易被低估的操作成本。

第二条：先看分子侧，再看影像侧。 因为影像是分子队列的子集，反向查找必然遇到大量落空。正确的顺序是先在 GDC 定分析队列，再筛出其中有影像的那部分，并把覆盖率作为一句话写进方法。

第三条：把「九十七」当成一个设计约束，不是缺陷。 它意味着任何结论都要按小样本来处理：效应量估计宽、分亚组后每组只有十几例、训练与验证必须跨队列而不是内部切分。

§2 数据构成与规格

2.1 四级结构：患者、检查、序列、图像

TCIA 的存储模型严格遵循 DICOM 信息模型，分四级。最上层是患者，标识是 PatientID；一位患者下可有多份检查，一份检查对应一次就诊的影像；一份检查下挂若干序列；序列下面是图像实例。集合页给出的四个数字正好对应这四级。

这个结构带来两个实用后果。其一，「例数」一词在这里有歧义，必须说清是患者、检查还是序列。九十七位患者对应二百三十七份检查，平均每人两次以上，这与肝脏肿瘤患者常有术前多期复查、或者同一时期既做 CT 又做 MR 的情况相符。其二，任何按序列统计的指标都会放大患者之间的不均衡：一位做过三期增强 CT 加一次肝脏 MR 的患者可能贡献十几个序列，只做过一次平扫的患者贡献一两个。

层级	DICOM 标识	集合内数量	说明
患者	PatientID	九十七	等于 TCGA 十二位患者 barcode
检查	StudyInstanceUID	二百三十七	平均每患者两次以上
序列	SeriesInstanceUID	一千六百八十八	平均每检查约七个
图像	SOPInstanceUID	十二万五千余幅	平均每序列七十余幅

平均每检查约七个序列这个数，是理解集合形态的钥匙。腹部增强 CT 的一个期相就是一整个序列，平扫、动脉期、门脉期、延迟期四期各一个，再加冠矢状重建就是七八个；肝脏 MR 则更多，T1 同相位、反相位、T2 脂肪抑制、DWI、动态增强各期，一个检查十几二十个序列是常态。序列数远多于检查数，检查数远多于患者数，这条比例关系在所有 TCIA 腹部集合里都成立。

2.2 模态构成与不均

集合的模态一栏写的是 CT、MR、PT 三个词，三者的覆盖量完全不对等。CT 是主体，腹部增强 CT 是肝细胞癌术前评估的标准检查，多数患者的影像是 CT。MR 覆盖一部分患者，用于复查、对比剂禁忌或需要软组织对比的情形，肝脏 MR 的期相划分比 CT 更细，T1、T2、DWI、动态增强的对比意义各不相同。PT 是正电子发射断层，在这个集合里只占极少数，通常是作为分期时的全身评估伴随检查，解剖信息量远低于断层图像。

官方集合页把这条不均写得比较克制——只列了三个模态名，没有给逐模态的患者数。这一点在做样本量规划时必须自行核实：名义上「三模态」，实际每个模态能凑出多少例，只能通过 digest 表或 NBIA 接口逐例统计才知道。

模态	典型用途	在本集合中的角色
CT	术前分期、强化模式评估	主体，多数患者
MR	软组织对比、胆管与血管评估	少数患者，序列最多
PT	全身分期、转移筛查	极少数，多为伴随检查

2.3 一条记录的解剖

下面是一次腹部增强 CT 检查中一个序列的头部字段形态。字段名取自 DICOM 标准，具体取值因站点而异。

#-- 一个序列的 DICOM 头关键字段（标签名取自 PS3.3 / PS3.6）
PatientID            = TCGA-XX-XXXX          # 十二位，与 GDC 的 case submitter_id 完全一致
PatientName          = TCGA-XX-XXXX          # 常与 PatientID 同值，真实姓名不入库
StudyInstanceUID     = 1.3.6.1.4.1.<站点>…   # 一次检查
StudyDate            = 20030811              # 已整体平移，仅保留相对间隔
SeriesInstanceUID    = 1.3.6.1.4.1.<站点>…
SeriesDescription    = LIVER ART               # 自由文本，站点与厂商习惯不同，不可直接当标签
Modality             = CT
BodyPartExamined     = ABDOMEN
SliceThickness       = 5.0                    # 单位 mm，站点之间差异明显
Manufacturer         = <厂商名>                # 多家主流厂商混合
KVP                  = 120
ContrastBolusAgent   = <对比剂名>              # 仅增强序列有值
AcquisitionNumber    = 3                      # 多期扫描的序号，配合 SeriesDescription 判期相

逐项看。PatientID 是整条记录里最重要的一格，它是与 GDC 连通的唯一通道；PatientName 虽也存在，但不承载可用信息，不要把姓名当标识。StudyDate 已被平移，不能与临床表的真实日期直接相减，只能用于计算同一位患者多次检查之间的间隔，因为平移量对同一站点是固定的。SeriesDescription 是自由文本，「LIVER ART」「ART LIVER」「Liver_Arterial」在不同站点指的是同一个意思，把它当结构化期相字段是最常见的翻车点。SliceThickness 与厂商字段合起来解释了为什么这个集合的影像「极为异质」：一例 1.25 毫米薄层与一例 7.5 毫米厚层放一起，任何固定尺度的纹理特征都会失真。

2.4 与 GDC 侧的字段对接

TCIA 侧只有影像与少量 DICOM 元数据，患者层面的信息全在 GDC。对接的落点是 GDC 的 case 实体，它的 submitter_id 就是十二位患者 barcode。按这个键向上取，可以得到诊断、分期、病因、生存；向下取，可以得到样本、等分样、各类组学文件与病理切片。

TCIA 侧字段	GDC 侧字段	对接方式
PatientID	case.submitter_id	十二位直接相等
无	case.disease_type	项目中以肝细胞癌为主，诊断须逐例核
无	diagnosis.primary_diagnosis	组织学诊断
无	diagnosis.ajcc_pathologic_stage	分期字符串
无	demographic.vital_status 与 days_to_death	生存状态与天数
无	各 experimental_strategy 下的文件	按 case 关联到文件
无	病理切片的 slide 实体	另有一层 slide barcode

两个细节必须提。第一，PatientID 是十二位 barcode，而 GDC 的样本 barcode 是十六位，等分样更长；用十六位的样本 barcode 去匹配 PatientID 会全部落空，这在第一次写脚本时几乎必然发生。第二，GDC 上的切片是挂在 slide 实体上的，它的编码比 case 层多两级，做「影像—切片」对应时要先落到 case 层再往下取，不能跨层跳。

2.5 五个版本与它们各自的差别

集合自 2014 年首次发布以来经过五个版本。第一个版本与第二个版本的影像完全相同，都是六十五例、二百零四次检查、一千三百五十一个序列、九万三千余幅，体积 42.59 GB；第三个版本把患者加到九十三例，体积涨到 54.77 GB；第四个版本加四位患者后达到当前规模，体积 56.38 GB；第五个版本改动全在附带的表格上，把临床数据链接换成 GDC 最新电子表格，并新增了来自 GDC 的生物医学表格，影像本体未重新发布。

这一点对使用者很重要：如果你手上有一份 2017 年 1 月以前的影像包，它的图像与当前版本不同，缺了最后加入的四位患者；如果你手上的是 2017 年 1 月以后、2020 年以前的包，图像与当前版本完全一致，唯一差别是附带的临床表格新旧不同。任何声称「用了最新版本影像」的表述，在 2017 年之后的两个版本之间其实没有差别。

版本	日期	患者	检查	序列	体积	主要变化
v1	2014-05-05	六十五	二百零四	一千三百五十一	42.59 GB	首次发布
v2	2016-01-05	六十五	二百零四	一千三百五十一	42.59 GB	重抽临床 TXT，影像未变
v3	2016-06-21	九十三	二百三十三	一千六百四十六	54.77 GB	新增影像数据
v4	2017-01-30	九十七	二百三十七	一千六百八十八	56.38 GB	新增四位患者
v5	2020-05-29	九十七	二百三十七	一千六百八十八	56.38 GB	临床表换 GDC 最新版

从这张表能读出一条趋势：规模在 2017 年 1 月之后冻结。此后四年集合本身没有再进一位患者，版本的推进只体现在外围表格的更新上。这与 TCGA 早已停止入组、影像汇交窗口关闭的事实一致，也说明「等 TCIA 再补点数据」不是一条可行的路线。

2.6 与同类资源的定位差异

把几个平台对同一个名字的口径放在一张表里，差异会立刻显现。

平台或资源	患者数	模态	里有什么
TCIA 集合页	九十七	CT、MR、PT	原始 DICOM 与元数据
GDC 项目页	三百七十七	无影像	临床、组学、切片索引
IDC 集合视图	三百七十七	CT、MR、PT、SM、SEG	云端 DICOM 视图，含切片与外部 SEG
外部器官分割结果集	约为影像子集	SEG	空腔脏器与肝脏的自动分割

判断规则：要原始 DICOM 与最小口径去 TCIA，要分子去 GDC，要云端批量检索和切片视图去 IDC，要现成器官掩膜去外部结果集。 四个入口都能进，但进去看到的东西不是一回事；同一份分析必须说明用的是哪个入口。

§3 核心层 A：barcode 与覆盖率

3.1 为什么这一层先写

对影像数据集来说，身份层的含义不是「这东西是谁」这种静态问题，而是三个具体问题：一位患者的影像能不能唯一定位到某条分子记录？一批影像的边界到哪里为止？同一个名字在不同平台上指的是不是同一批人？这三个问题答不上，后面所有建模都建在流沙上。

这一层对应的是做队列构建的人——需要把影像、分子、病理、生存拼成一张分析表的人。对他们来说，barcode 规则、覆盖率、跨平台口径这三件事的优先级高于任何影像处理技巧。

3.2 barcode 的结构

TCGA 的患者 barcode 是十二位，形如 TCGA-XX-XXXX：前三到四位是项目代号，中间两位是组织来源站点代码（TSS），最后四位是患者序号。样本 barcode 在患者 barcode 后加三段，分别标记样本类型、样品序号与等分样序号，所以更长。切片还有自己的一层编码。

这套规则的意义在于：它是跨库唯一稳定的主键。影像侧没有为患者另造编号，直接复用 TCGA 的编号；分子侧也用它。两侧的匹配因此不需要任何映射表，一次字符串相等就够了。

层级	长度形态	举例说明	是否与影像主键同值
项目	四字符	TCGA	是前缀
患者	十二位	TCGA-XX-XXXX	是，影像的 PatientID
样本	十六位	患者段加样本段	否，需截断
切片	更长	样本段加切片段	否，需截断
文件	UUID	平台内部标识	否

截断这一步是全部对齐工作中唯一的手写逻辑，也是最容易写错的一步。稳妥的写法是把影像侧的 PatientID 原样保留，把 GDC 侧的各级标识都截到十二位再去重，而不是反过来截影像。

3.3 两套例数口径的落差

九十七对三百七十七，覆盖率约四分之一。这个落差不是数据质量问题，而是设计使然：影像汇交是自愿的，需要影像来源站点单独提交 DICOM 并完成去标识与质控，而组织与测序是 TCGA 的强制流程。

落差的后果有三层。第一，分子侧能做全队列的分析，影像侧不能；任何「影像与分子的相关性」结论，都只对那四分之一成立。第二，这四分之一不是随机抽样——它是「恰好有影像来源站点参与汇交」的那部分，医院、时间段、扫描习惯都与其余部分不同，外推要打折扣。第三，写论文时覆盖率必须写明，否则审稿人会问「剩下四分之三去哪了」。

口径	数量	含义
GDC 病例数	三百七十七	有临床与分子记录的病例总数
TCIA 患者数	九十七	有可发布影像的患者数
交集	九十七	影像侧本身就是分子侧的子集
只在 GDC 有记录者	其余二百八十	无影像，只能做分子分析

3.4 集合本体明确不包含什么

这一节把「不包含」写死，避免反复被误解。集合本体不含分割掩膜、不含结构化临床表（只有一个 2016 年 1 月 5 日的临床快照压缩包）、不含分子文件、不含病理切片文件、不含放射组学特征表、不含患者级的训练/验证划分。它在交付形态上就是一个 DICOM 归档加两个索引文件。

官方页面的 Related Datasets 一栏列了两个分析结果集（Crowds-Cure-2017 与 SAROS），那是肝以外的研究，与本集合血缘不同，不要当成它的标注层。IDC 集合视图里的 SM 与 SEG 两个模态不是 TCIA 集合页的口径，前者是 DICOM 化的切片副本，后者是外部生成的器官分割，归属主体不同。

3.5 barcode 之外的第二条身份线

影像与切片之间除了 barcode 还有一条线：切片上传到 GDC 的 slide 实体，其文件名通常带患者 barcode 与样本类型。这条线让「这张 CT 对应哪一张 H&E」成为可能。但它只到样本层，不到病灶层——一位患者若有多个肿瘤结节，切片与影像都是一份，无法逐结节对应。

这个限制在多灶肝癌里是致命的：HCC 复发率高，多灶病例不少，影像上看到的两个强化结节可能对应同一张切片上的两个不同克隆，也可能是一个主灶加一个卫星灶。任何按「一病灶一标签」设计的训练任务，在这里都做不到，只能退到「一患者一标签」。

3.6 身份层的一张速查

问题	答案
影像主键是什么	十二位患者 barcode
分子主键是什么	同一个 barcode（case.submitter_id）
影像侧规模	九十七例
分子侧规模	三百七十七例
交集怎么算	字符串相等，不需要映射表
病灶层能对应吗	不能，只能到患者层
切片层能对应吗	能到样本层，不能到病灶层

§4 核心层 B：影像征象与分子亚型

4.1 这一层为什么是它的全部价值

上面那一层解决「对得上号」，这一层解决「对上了能问什么」。影像基因组学的核心主张是：肿瘤在影像上的形态与强化方式，是其微观结构与分子程序的可见投影。这个主张如果成立，影像就能作为一种无创的分子分型替代或补充；如果不成立，影像就只是形态描述。

TCGA-LIHC 是检验这个主张最合适的公开素材，原因有三：征象可以被标准化描述（LI-RADS 那一套），分子侧有整套组学（突变、拷贝数、表达、甲基化、蛋白），而且两侧同主键。库内其他肝脏数据都缺第二条或第三条——有的有分割没有组学，有的有疗效没有组学。

4.2 分子侧有什么

GDC 侧的项目是三百七十七例，覆盖多个数据类别。变异、拷贝数、甲基化与临床为全队列覆盖，表达与 miRNA 覆盖绝大多数病例，全基因组测序覆盖八成半左右，蛋白阵列只覆盖不到一半。诊断切片覆盖九成七，组织切片全队列都有索引。

数据类别	覆盖情况	对影像配对的含义
临床	全队列	分期、病因、生存都能用
简单核苷酸变异	全队列	突变负荷与驱动基因可用
拷贝数变异	全队列	染色体臂级改变可用
DNA 甲基化	全队列	甲基化亚型可用
转录组	绝大多数	表达亚型与免疫浸润估计可用
miRNA	绝大多数	调控层可用
全基因组测序	八成半	结构变异与融合可用
蛋白阵列	不到一半	蛋白层样本量骤减
诊断切片	九成七	形态与影像可对照

这里有一个容易被忽略的推论：分子侧各层覆盖本就不齐，再乘上影像侧四分之一的交集，某些组合的可用样本会掉到很小的量级。做设计时应该先列出「影像 × 某一分子层」的交集大小，而不是从三百七十七往下假设。

4.3 肝细胞癌的分子地标

谈影像—分子关联，先要知道分子侧有哪些值得关联的东西。肝细胞癌的分子图谱有几个稳定的事实：CTNNB1 激活突变定义了一类以 Wnt 通路活化为特征、形态上偏「炎症少、分化较好」的亚型；TP53 突变与染色体不稳定性、增殖表型相关联，预后偏差；TERT 启动子突变是最常见的体细胞改变之一，几乎贯穿所有亚型；此外还有基于表达谱的若干分类方案，从早期的增殖型与非增殖型二分，到后来加入免疫特征的细分。

这些亚型的存在，正是影像征象可能有意义的前提：如果肿瘤在分子上真是分群的，而不同群在生长方式、血供、包膜形成上有差异，那么影像上就应该有迹可循。动脉期强化程度对应血管密度，包膜对应纤维包膜形成，门静脉癌栓对应侵袭性表型——每一条都能对应到一个可检验的假设。

分子地标	影像上可能的对应	现状
CTNNB1 激活	边界清楚、包膜完整、强化均匀	有文献报告，样本量小
TP53 突变	边缘不规则、坏死区、侵袭性征象	关联方向不一
增殖型表达亚型	体积大、多灶、血管侵犯	重复性待验
免疫浸润高的亚型	强化模式与坏死比例	证据弱

这张表的右列刻意写得保守。已有公开研究确实报告过上述方向的关联，但多数样本量在数十例量级，且不同研究的征象定义与特征提取流程互不相同，因此把这些关联当成「已确立的规律」是不恰当的，当成「值得检验的假设」才是它该有的位置。

4.4 派生结果集是什么，不是什么

IDC 与 Zenodo 上存在若干与本集合一脉相关的派生结果：由自动化流程生成的器官分割（BAMF 在 AIMI Annotations 计划下的产物）、切片层面的地图类结果，以及 DICOM 化的切片副本。这些都是二次加工的产物，不是集合本体的一部分。

派生结果集的价值在于省掉一部分重复劳动，尤其是在需要肝脏与空腔脏器轮廓做定位、但不需要逐例手勾的时候。它的边界在于：自动分割的质量参差，肝脏边界在肋骨与肠管贴邻处容易外溢，肿瘤本身通常不在自动分割范围内。用它做预处理可以，用它当金标准不行。

4.5 影像征象的可复用边界

把 LI-RADS 那套征象用在这个集合上，有三个现实障碍。第一，期相没有结构化字段，动脉期与门脉期只能靠 SeriesDescription 与 AcquisitionNumber 推断，站点间命名习惯不同。第二，没有对比剂剂量与注射方案记录，强化程度的绝对值不可比，只能在同一检查内部做相对比较。第三，没有重建设置的统一，窗宽窗位与重建核不同，纹理特征的可移植性差。

因此，一个稳健的做法是把征象定义成「同一检查内部的相对关系」而不是「绝对阈值」：病灶与肝实质的强化差、病灶与主动脉的强化比、包膜的显示与否。这类定义对协议差异的敏感性远低于绝对 HU 阈值。

4.6 配对实践中的三个坑

第一个坑是拿十六位样本 barcode 去匹配影像。前面提过，会全部落空。解法是统一截到十二位并大写。

第二个坑是忽略「同一患者多次检查」。二百三十七次检查对九十七位患者，有人在多个时间点都留了片子，若不筛「术前基线」，同一患者会在训练集里出现两次以上。解法是读 DICOM 头里的检查日期与序列描述，结合 GDC 的手术日期字段筛出术前那一次。

第三个坑是把病理切片与影像直接按患者对应后，认为两者描述的是同一个病灶。切片通常取自主灶，影像是整个肝脏，多灶病例必然不对应。解法是只保留单灶病例做「影像—病理」层面的分析，或者明确把对应关系降级到患者层。

4.7 病理这一侧的角色

病理在 TCGA-LIHC 里是第三种模态，也是唯一能提供「金标准形态」的模态。GDC 上的切片分两类：诊断切片（HE 染色，用于诊断）与组织切片（制备组学用的组织块）。前者是读片的基础，后者与分子测量直接关联。

病理这一侧对影像基因组学的价值在于：它把「影像征象」与「显微结构」之间的中间层补上了。影像上的包膜对应切片上的纤维包膜，影像上的坏死对应切片上的凝固性坏死，影像上的强化差异对应微血管密度。没有这一层，影像与分子的关联就只能靠统计相关，无法解释机制。

4.8 一个必须提前接受的现实

即便三件套齐全，这个集合也只能支撑「关联」层面的结论，不能支撑「预测」层面的声明。原因很简单：样本量小到无法做严格的训练/验证切分，大多数以它为素材的研究都在同一批患者上做交叉验证，而交叉验证不是独立验证。看到「AUC 0.85」这类数字时，第一个问题永远是「验证集在哪里」。

§5 核心层 C：怎么拿到、怎么接上

5.1 三条取数通道

影像有三条路可以走。第一条是 TCIA 官网的批量清单加官方客户端，适合一次性全量下载。第二条是 NBIA 的检索接口，适合按条件筛序列再下。第三条是 IDC 的云端视图加 DICOMweb 与 BigQuery 表，适合在云上做筛选与批量计算，不必把 56.38 GB 拖到本地。

分子有两条路。第一条是 GDC 门户的图形界面，适合浏览与少量下载。第二条是 GDC 的 API，适合脚本化批量取数。两条用的是同一套后端，口径一致。

#-- 1) 记录集合口径：患者、检查、序列、图像四级数字（免注册）
curl -s "https://services.cancerimagingarchive.net/nbia-api/services/v1/getCollectionValues?Collection=TCGA-LIHC" \
  -o collection_values.json

#-- 2) 取该集合的患者标识，用于与 GDC 做交集
curl -s "https://services.cancerimagingarchive.net/nbia-api/services/v1/getPatient?Collection=TCGA-LIHC" \
  -o tcia_patients.json

这两条调用返回的都是 JSON，不需要账号。第一条给出集合级统计，第二条给出患者列表；两者的患者数应当相同，若不同说明集合在两次调用之间变动过，需重新取。

5.2 用官方接口查集合口径

集合级的四个数字（患者、检查、序列、图像）在页面与接口里都有。接口的好处是可以脚本化、可以记录取数时间，对需要写「截至某日」的论文更友好。

#-- 按序列级别导出，得到「患者 → 检查 → 序列」的完整索引
curl -s "https://services.cancerimagingarchive.net/nbia-api/services/v1/getSeries?Collection=TCGA-LIHC" \
  -o tcia_series.json

#-- 统计每个模态下的序列数与患者数，用来核对「三模态」的实际覆盖
python3 - <<'PY'
import json, collections
rows = json.load(open("tcia_series.json", encoding="utf-8"))
by_mod = collections.defaultdict(set)
for r in rows:
    by_mod[r.get("Modality", "NA")].add(r.get("PatientID"))
for mod, pts in sorted(by_mod.items()):
    print(f"{mod:4s} 患者 {len(pts):3d}")
PY

这段脚本输出的每个模态的患者数，就是「三模态」这句话的实际含义。名义上三个模态，实际能凑出多少，一看便知。

5.3 从 digest 表做本地索引

如果不想碰接口，集合页提供的 digest 表是最省事的入口。它是一张 XLSX，每行一个序列，列里有患者标识、检查标识、序列标识、模态、序列描述与图像数。

#-- 用 digest 表建本地索引：每位患者有几个检查、几个序列、哪些模态
import pandas as pd

d = pd.read_excel("doiJNLP-TCGA-LIHC-01-30-2017-nbia-digest.xlsx")
d.columns = [c.strip() for c in d.columns]

per_patient = d.groupby("PatientID").agg(
    studies=("StudyInstanceUID", "nunique"),
    series=("SeriesInstanceUID", "nunique"),
    images=("ImageCount", "sum"),
)
print(f"患者 {len(per_patient)} 例")
print(f"检查 {per_patient['studies'].sum()} 次")
print(f"序列 {per_patient['series'].sum()} 个")
print(f"图像 {per_patient['images'].sum()} 幅")

print(d.groupby("Modality")["PatientID"].nunique())

用 digest 表的好处是快，几十兆的表格几秒读完；坏处是它是快照，与接口可能相差几天。做正式分析时以接口为准，digest 表用来规划与抽样。

5.4 到 GDC 取配对分子表

GDC 的 API 用 POST 加 filters 的方式检索，返回 JSON 或 TSV。取病例表是为了拿到分子侧的骨架，取文件表是为了知道每个病例有哪些可下载的文件。

#-- 取 GDC 上的病例表：患者标识、分期、生存状态
curl -s -X POST "https://api.gdc.cancer.gov/cases" \
  -H "Content-Type: application/json" \
  -d '{"filters":{"op":"in","content":{"field":"project.project_id","value":["TCGA-LIHC"]}},
       "fields":"submitter_id,diagnoses.ajcc_pathologic_stage,demographic.vital_status",
       "format":"JSON","size":500}' \
  -o gdc_cases.json

返回的 submitter_id 就是十二位 barcode。把它与影像侧的患者列表求交，得到的就是「既有影像又有分子」的那批人。这个交集本身就是做任何影像基因组学分析的第一步。

5.5 三步拿到一张能用的对应表

#-- 影像侧与分子侧取交集，输出可引用的覆盖率
import json, pandas as pd

gdc = json.load(open("gdc_cases.json", encoding="utf-8"))["data"]["hits"]
molecular = {h["submitter_id"].strip().upper() for h in gdc}

tcia = json.load(open("tcia_patients.json", encoding="utf-8"))
imaging = {(p.get("PatientID") or p.get("PatientId", "")).strip().upper() for p in tcia}

both = molecular & imaging
print(f"分子侧 {len(molecular)} 例 / 影像侧 {len(imaging)} 例 / 交集 {len(both)} 例")
print(f"影像覆盖率 {len(both) / len(molecular):.1%}")

pd.Series(sorted(both), name="barcode").to_csv("paired_cohort.csv", index=False)

这段代码产出的 paired_cohort.csv 就是后续所有工作的名单。覆盖率那一行建议直接写进论文的方法段，它是解释样本量来源最省事的一句话。

5.6 三条通道的口径对照

通道	免注册	适合	需要注意
TCIA 官网批量清单	是	全量下载	需官方客户端，体积 56.38 GB
NBIA 检索接口	是	按条件筛序列	返回结构随接口版本变化
IDC 云端视图	是	筛选与云上计算	例数按 GDC 口径，含切片与 SEG
GDC 门户	是（开放层）	浏览与少量下载	受控层需 dbGaP 授权
GDC API	是（开放层）	脚本化批量	每次请求有返回条数上限

5.7 存储与算力的粗略预算

56.38 GB 是压缩后的体积，解压后占地会明显更大，DICOM 大量小文件还会拖慢文件系统。展开前的稳妥估计是压缩包的数倍，且小文件数量以十万计。本地做特征提取时，瓶颈往往不是显存而是文件系统的元数据操作，把序列先打包成 NIfTI 或 HDF5 是常规做法。

算力方面的粗略量级：单机做一例的预处理与特征提取在分钟级，九十七例串行一天内能跑完；若做深度学习训练，九十七例只够训练一个很小的模型或对一个大模型做微调，交叉验证的轮数也会受样本量限制。

§6 与库内词条的互链地图

6.1 关系图谱

库内肝脏方向已有若干词条，各自占一个位置。把它们按「有什么、缺什么」排开，TCGA-LIHC 的不可替代性会立刻显现。

库内词条	核心内容	有无分割掩膜	有无配对组学
TCGA-LIHC	九十七例三模态影像 + GDC 组学	无	有
lits-liver	肝脏与肝肿瘤分割挑战数据	有	无
atlas-liver-tumor	肝肿瘤 MR 分割与分类	有	无
sliver07	肝实质分割，单类掩膜	有	无
hcc-tace-seg	TACE 术前术后配对与疗效	有	无
colorectal-liver-metastases	结直肠癌肝转移与生存	有	无

6.2 与 HCC-TACE-Seg 的分工

这一对最容易被混。两者都是肝细胞癌、都是 CT、都以九十几到两百例的量级存在，名字里都带 HCC。差别在于各自把标签打在哪一侧：TACE 那条把标签打在「治疗之后」，术前术后配对、疗效可评；此条把标签打在「分子之上」，突变、拷贝数、表达、甲基化全有，却没有治疗后影像。

一句话的分工：要疗效看 TACE 那条，要组学看此条。 两条合起来才是肝细胞癌从「诊断」到「治疗反应」的完整链条，任何一条单独都不能替代另一条。

6.3 与分割类词条的关系

LiTS、SLIVER07 与 ATLAS 这三条的共同点是「有像素级标注、没有分子」。它们回答「肝脏和肿瘤的边界在哪」，此条回答「这个肿瘤在分子上属于谁」。两者在流水线上的位置不同：分割类产出掩膜，此条消费掩膜。理想的做法是用分割类训练一个分割模型，把它迁移到 TCGA-LIHC 上生成候选轮廓，再由人工校正后做影像组学特征提取。反过来用它训练分割模型则本末倒置。

6.4 与 TCGA 家族其他成员的关系

库内的 TCGA-KIRC 是最接近的同族词条：同为 TCIA 托管的 TCGA 影像集合，同一套 barcode 规则，同样的「影像在 TCIA、分子在 GDC」架构，同样的日期平移处理。两者可以按同一套代码处理，唯一的差别是解剖部位与模态比例。TCGA-PanCanAtlas 则提供跨项目的分子汇总视角，适合做泛癌层面的对照，但不含影像。

词条	与它的关系
TCGA-KIRC	同架构同族资源，可复用取数与预处理代码
TCGA-PanCanAtlas	泛癌分子汇总，可做跨癌种对照
colorectal-liver-metastases	同为肝脏占位，但病种为转移而非原发

6.5 组合使用的三种配方

配方一：分割迁移 + 组学回归。 用分割类数据训练肝脏与肿瘤分割，迁移到此条生成候选轮廓，人工校正后提取特征，与 GDC 的突变或表达做关联。这条路线工作量大，但结论最稳。

配方二：纯影像表型 + 生存。 不碰分子，只用影像征象与 GDC 的生存字段做生存分析。样本量小，但假设最简，适合做初探。

配方三：病理为主、影像为辅。 主体分析放在切片上（面积大、分辨率高），影像只提供术前分期的宏观信息。适合病理图像方向的研究者。

§7 质量评估与局限性

7.0 阅读本节前的一件事：不要用「训练集」的标准评价它

在给评分之前必须先校正一个框架错位。如果把 TCGA-LIHC 当成一个为机器学习准备好的训练集来评，它会在很多维度上不及格：没有划分、没有掩膜、没有统一预处理、类别不平衡、协议五花八门、样本量小到交叉验证都不稳。但这个评价框架本身就是错的。

它应该被当作一份档案来评。档案的价值在于「保存了什么、与什么连在一起、能不能被可靠引用」，而不在于「开箱可用度」。用档案的标准看，它的核心贡献是保住了那批已完成整套分子测量的肝癌患者的术前影像，并让这些影像可以被任何人用一串公开编号追溯回分子、病理与生存。用训练集的标准看，它是一份需要大量二次加工的原料。

这也是为什么下面两张表要分开看：一张衡量它作为档案的完备性，一张衡量它作为原料的可用性。混在一起看，会得出「既不完整也不能用」这种两头都不对的结论。

7.1 它作为档案：三个不可替代之处

第一，同主键。影像与分子不是事后匹配，而是同一身份的两面。这一点在同规模的公开肝脏资源里几乎找不到第二个。

第二，三模态齐备。CT、MR、PT 三者在一个集合里同时存在，MR 还带动态增强与功能性序列，这让「同一位患者的多种成像方式」成为可直接研究的对象，而不必跨库拼接。

第三，开放。CC BY 3.0，免注册，不需要数据使用协议，也不需要申请；分子侧的开放层同样免注册。这在带临床与基因组配对的影像资源里属于最宽松的一档。

7.2 DAIMS 评分表

下表按数据资产描述与访问的八个维度给出评分，五分制，判断依据全部来自官方页面与平台行为。

维度	评分	判断依据
描述层身份与边界	4	集合名、项目代号、疾病全称、DOI、托管机构齐全；但病例边界存在双口径（九十七对三百七十七），页面未在正文显式解释，故扣一分
描述层文档完备度	4	页面含完整描述、五个版本的逐版统计、引用格式与致谢、四家影像来源站点名单；缺采集协议逐站点说明与期相定义
结构层标识体系	5	患者 barcode 与 GDC 主键完全同值，DICOM 四级标识完整，跨库可直接连，无歧义
结构层层级一致性	4	四级结构严格，但例数在各层级各不相同，页面只给数字不给换算关系；切片另有一层编码需自行理解
结构层模态配对	3	三模态并存是优点，但覆盖严重不均，且页面不提供逐模态患者数，跨模态分析需自行统计
访问层开放程度	5	免注册、CC BY 3.0、提供批量清单与 digest、另有 IDC 的 DICOMweb 与 BigQuery 视图
访问层可复现性	3	图像版本稳定可复现；但协议异质、无统一预处理、无官方划分，同一分析换一批患者往往不可复现
访问层许可清晰度	5	许可单一明确，引用格式与致谢文本官方给定，义务内容写清，无二次限制

分数怎么读。 高分集中在「身份」与「访问」，低分在「模态配对」与「可复现」。这个分布精准描述了这个资源的性格：门开得很大、身份做得很实，但不是为可复现实验设计的。任何依赖「同样的输入得到同样的输出」的工作，都要为这两列付成本。

对你意味着什么。 若在做合规严格的项目，许可清晰度能省掉大量沟通；若在做方法学对比研究，可复现性那一列会迫使把预处理流程完整写进方法段，而这恰恰是许多论文最薄弱的一段。

7.3 已知的、可枚举的局限

局限	具体表现	影响
无掩膜	集合本体零标注	分割与影像组学都要先自建轮廓
规模小	九十七例，且只有分子队列的四分之一	统计功效低，分亚组后每组十几例
模态不均	CT 为主，MR 与 PT 覆盖少	跨模态分析样本骤减
协议异质	厂商、层厚、期相由站点自定	特征分布偏移
日期平移	整体平移三到十年	不能与临床日期相减
随访影像缺	以术前基线为主	纵向建模不可行
无疗效标签	无治疗反应的结构化评价	不能做疗效预测
无质量评分	无信噪比、伪影标记	需自建质控
病灶层不可分	影像对应患者，不是病灶	多灶患者无法逐结节标注

7.4 关于日期的那条限制值得单说

两个平台对日期的处理完全不同，而且官方明说没有协调计划。TCIA 侧把所有日期整体平移了若干天，平移量在三到十年之间，对同一站点、同一集合固定，因此同一患者多次检查之间的间隔被准确保留。GDC 侧的临床日期全部换算成「距病理诊断日的天数」，诊断日为零。

两套逻辑各自自洽，合在一起就有陷阱：把影像头里的检查日期与临床表里的生存天数相减，得到的既不是真实日期差，也不是有意义的间隔。唯一安全的用法是：用 GDC 的相对天数做时间分析，用 TCIA 的日期只做患者内部的检查间隔。

7.5 外部验证矩阵

验证对象	可用证据	结论
例数与检查数	集合页五个版本首尾一致，IDC 与第三方索引可交叉核对	一致（口径需说明）
图像体积	五个版本的变化与新增患者数吻合	自洽
模态	页面、IDC 过滤器、digest 表三处	一致
组学覆盖	GDC 项目页各数据类别	可核，各层覆盖不同
器官分割	外部结果集的 DOI	可核，不属于本体
许可	DOI 记录与集合页一致	一致

7.6 它为何能持续

它能持续，靠的不是团队持续维护，而是三层刚性绑定。

第一层是 TCGA 的机构惯性。项目本身已停止入组，但 GDC 与 TCIA 作为国家级的托管设施长期运行，数据一旦入库就有制度化的保存义务。第二层是下游依赖。肝细胞癌的影像基因组学研究、放射组学方法比较、多模态预训练，都把它当作公开基准之一，引用量累积又反过来巩固它的地位。第三层是许可的开放性。免注册、CC BY 3.0，使它在无法走审批流程的场景（教学、竞赛、商业探索）里成为默认选项，用户基数因此远大于同类的受控数据。

第三条尤其值得说：一个数据集如果不能被随手取到，就很难成为方法学论文里的公共对照；TCGA-LIHC 恰好能被随手取到，于是它在文献里反复出现，出现得越多，越难被替代。

§8 版本与生态

8.1 版本节奏

五个版本的节奏可以读成三段。2014 至 2016 年是快步补齐期，两年内从六十五例走到九十三例，体积从四十二点六吉字节涨到五十四点八吉字节；2017 年初补上最后四位患者后进入冻结期；2020 年的第五版是维护性更新，只换表格不动影像。

这个节奏给使用者的提示很直接：影像侧不会再有增量，等下去没有意义；但表格侧仍可能随 GDC 的更新而更新，若引用临床字段，应注明取数日期。

阶段	时间范围	特征
补齐期	2014 至 2016	患者数与体积快速上升
冻结期	2017 至 2020	影像规模稳定在九十七例
维护期	2020 之后	只更新附带表格，影像不变

8.2 组织方式

集合由 CIP TCGA Radiology Initiative 组织，影像由四家机构贡献：Mayo Clinic（罗切斯特，明尼苏达）、北卡罗来纳大学教堂山分校、Alberta Health Services（加拿大阿尔伯塔）、Lahey Hospital & Medical Center（伯灵顿，马萨诸塞）。这四家对应 barcode 里的四个 TSS 代码，构成了「同一批人为什么影像异质」的直接解释。

影像来源站点	所在	对协议的贡献
Mayo Clinic	明尼苏达州罗切斯特	主力贡献，腹部 CT 与 MR
UNC Chapel Hill	北卡罗来纳州	腹部 CT 与 MR
Alberta Health Services	加拿大阿尔伯塔	腹部 CT
Lahey Hospital & Medical Center	马萨诸塞州伯灵顿	腹部 CT

四家机构、两个国家、三套设备采购习惯，决定了层厚、期相命名与重建核的差异。这不是失误，是自愿汇交模式的必然产物。

8.3 衍生资源的谱系

围绕这个集合，外围长出了四类资源。第一类是 DICOM 化的病理切片副本，把 SVS 转成标准 DICOM 存到 IDC，使切片能与影像在同一个云端视图里检索。第二类是自动器官分割，把空腔脏器与肝脏轮廓生成 SEG。第三类是切片层面的派生地图，用于可视化。第四类是论文里的特征矩阵，散落在补充材料里，没有统一入口。

衍生类型	交付形态	是否属于集合本体
DICOM 化切片	SM	否，IDC 视图
器官分割	SEG	否，外部结果集
切片派生地图	图像	否，外部结果集
论文特征矩阵	补充材料	否

8.4 生态位

在肝癌影像的整体生态里，它的位置是「带分子注释的小规模参考集」。往下是分割挑战赛数据，规模更大、标注更细，但没有分子；往上是泛癌级别的汇总资源，覆盖面广，但单病种深度被压平。它夹在中间，专供「需要把影像与分子连起来」这一类需求。

这个位置相当稳固：挑战赛数据天然不做分子随访，泛癌资源天然不做单病种深挖，中间这一层很难被替代。真正的风险不是被取代，而是被高估——被当成足够大的训练集，然后在一篇论文的很小样本上得出过强的结论。

§9 使用指引

9.1 三种角色的路径

角色	第一步	第二步	第三步
临床研究者	定问题与样本量	在 GDC 取临床与突变	再按 barcode 取对应影像
影像组学工程师	先下 digest 做索引	抽样十余例跑通流程	全量下载与批量特征提取
数据工程	建四层标识的本地表	做 barcode 归一并去重	输出可训练的划分与清单

临床研究者最容易犯的错是先下影像再找分子，结果发现要用的病例一半没有影像。正确顺序是先定分子侧的分析队列，再把有影像的那部分挑出来，并把覆盖率写进方法。影像组学工程师最容易犯的错是直接拖全量然后卡在预处理上，先小样本跑通是唯一省钱的做法。

9.2 一条最短的可用流程

#-- 1) 建目录与取索引
mkdir -p tcga_lihc && cd tcga_lihc
curl -sO "https://www.cancerimagingarchive.net/wp-content/uploads/doiJNLP-TCGA-LIHC-01-30-2017-nbia-digest.xlsx"

#-- 2) 取分子侧病例表
curl -s -X POST "https://api.gdc.cancer.gov/cases" \
  -H "Content-Type: application/json" \
  -d '{"filters":{"op":"in","content":{"field":"project.project_id","value":["TCGA-LIHC"]}},
       "fields":"submitter_id,diagnoses.ajcc_pathologic_stage","format":"JSON","size":500}' \
  -o gdc_cases.json

#-- 3) 用官方客户端按清单下载。需事先安装 TCIA Data Retriever，
#--    清单地址为集合页给出的 doiJNLP-TCGA-LIHC-01-30-2017.tcia

#-- 4) 取交集，输出名单与覆盖率
python3 -c "import json,pandas as pd; d=pd.read_excel('doiJNLP-TCGA-LIHC-01-30-2017-nbia-digest.xlsx'); a={x['submitter_id'].upper() for x in json.load(open('gdc_cases.json'))['data']['hits']}; b=set(d['PatientID'].astype(str).str.upper()); print(len(a),len(b),len(a&b))"

这四步跑完，手上会有三样东西：集合的准确口径、分子侧的全量名单、影像侧的索引。之后才是真正的实验工作。

9.3 引用与致谢

官方给定的引用格式包含作者列表、年份、标题（含版本号）、托管机构与 DOI。除此之外，使用源自 TCGA 的数据还应加上给定的致谢声明，说明结果部分或全部基于 TCGA 研究网络产生的数据。这两条是使用义务，不是可选项。引用时版本号必须写明，因为五个版本的影像内容不同。

9.4 合规清单

事项	要求
许可	CC BY 3.0，允许再分发与商用，需署名
引用	必须引用集合 DOI 与具体版本
致谢	必须包含给定的 TCGA 研究网络声明
再识别	不得尝试还原被平移的真实日期或识别个体
临床字段	若用受控层数据，须符合 dbGaP 的授权范围
二次分发	可以，但需保留许可与出处

§10 AI 使用声明

10.1 这份数据在模型训练中的位置

它适合当「带分子标签的小规模微调集与外部验证集」，不适合当「大规模预训练语料」。九十七例的规模决定它无法支撑从头训练一个视觉骨干，但足以支撑把某个自监督预训练模型接到下游的影像基因组学任务上，或者检验一个在大数据上训出的模型，在「有分子注释的小样本」上是否依然有效。

10.2 三种不该有的期待

第一种是期待它开箱即用。它没有划分、没有掩膜、没有统一窗宽，直接喂模型会把协议差异当成信号学进去。

第二种是期待它代表肝癌总体。它是自愿汇交的影像子集，站点集中在北美四家机构，患者构成必然带站点特征；且 TCGA 的入组本身偏手术切除病例，晚期不可切除患者不在其中。

第三种是期待它给出因果结论。任何基于它的影像—分子关联都是统计上的，样本小、检验多，单条显著结果都需要外部重复验证。

10.3 生成式模型的使用边界

用这批数据训练或微调生成模型时，有两条硬边界。其一，不得生成可被误认为真实患者的数据用于临床决策；其二，即便日期已平移、姓名未入库，影像本身仍属可识别风险范畴，重建结果不应作为「真实病例」公开发布。

10.4 不应由它承担的判断

不应被用来做诊断性能的最终声明，因为没有金标准病灶轮廓；不应被用来做疗效预测，因为没有治疗后影像与疗效标签；不应被用来做预后模型的独立验证，因为大多数以它为训练集的研究都在同一批患者上做交叉验证，那不是独立验证。

常见误读

常见说法	实际情况	证据
它是 TCGA 肝癌的全部患者	只是有影像的四分之一，九十七对三百七十七	TCIA 集合页与 GDC 项目页
它带分割掩膜	集合本体无任何 SEG 或 RTSTRUCT	集合页的 Data Access 表只有 DICOM
每位患者三模态齐全	CT 为主体，MR 与 PT 只覆盖少部分	集合页模态名与 digest 表
一份影像对应一个肿瘤病灶	影像对应患者，病灶层无法拆分	PatientID 是患者层 barcode
影像日期可以与临床日期相减	影像日期整体平移三到十年	集合页的日期处理说明
它能替代 HCC-TACE-Seg 做疗效研究	此条无疗效标签，TACE 那条才对应疗效	两条各自的设计目的
它能替代 LiTS 做分割	无掩膜、九十七例，规模与标注都不够	集合页数据类别与分割类数据对比
用 IDC 上的 SEG 就等于集合有标注	SEG 是外部自动生成的派生结果	IDC 集合页与 Zenodo 的 DOI 归属
集合已经停止更新所以过时了	影像冻结但表格随 GDC 更新，仍是唯一配对来源	五个版本的逐版说明
九十七例够做深度学习从头训练	规模只够微调与外部验证	样本量与交叉验证的现实约束

FAQ

Q1：TCGA-LIHC 有分割掩膜吗？
集合本体没有。TCIA 交付的是原始 DICOM，不含 SEG 或 RTSTRUCT。肿瘤与肝脏轮廓要么自行勾画，要么使用外部结果集，例如 IDC 与 Zenodo 上由 BAMF 在 AIMI Annotations 计划下生成的器官分割。

Q2：TCIA 是九十七例、GDC 是三百七十七例，哪个对？
两个都对，指的不是同一件事。前者是有可发布影像的患者数，后者是 GDC 上该项目有临床与分子记录的病例总数。做影像分析用前者，做分子分析用后者，合并时按患者 barcode 取交集。

Q3：它和 HCC-TACE-Seg 能互相替代吗？
不能。后者有术前术后配对的增强 CT 与疗效标签但没有配对组学；此条有完整组学与病理配对，却没有疗效标签。两条互补，不可互替。

Q4：影像日期能直接与临床日期相减吗？
不行。影像日期被整体平移了三到十年，临床日期则换算成距诊断日的天数。两套口径相减没有意义。

Q5：作者是谁？应该怎么引用？
官方引用格式列为八位作者，第一位是 Mayo Clinic 的 Bradley J. Erickson，托管方为 TCIA，必须带上版本号与 DOI 10.7937/K9/TCIA.2016.IMMQW8UQ。

Q6：为什么影像只有四分之一的人有？
影像汇交是自愿的，需影像来源站点单独提交 DICOM 并完成去标识与质控；组织与测序是 TCGA 的强制流程。自愿汇交的天然结果是覆盖不全。

Q7：MR 的序列这么多，能直接按序列名分期相吗？
不可靠。序列描述是自由文本，同一期相在不同站点写成不同词组。稳妥的做法是结合检查内的采集序号、对比剂字段与浏览图像后人工判定。

Q8：能不能用它做 LI-RADS 评分的机器学习任务？
理论上可以，但需要自行完成两件重活：一是按 LI-RADS 的征象定义逐例读片并标注，二是处理期相不统一的问题。集合本身不提供任何 LI-RADS 标签。

Q9：有随访影像吗？
极少。集合以术前基线检查为主，官方明确写着每位病例的基线检查均为术前。纵向分析价值有限。

Q10：CT 和 MR 能混在一起训练吗？
不建议直接混。两种模态的强度分布没有可比性，直接进同一个归一化流程会引入模态伪影。可行的做法是分模态建模，用多分支结构共享表征。

Q11：病理切片怎么拿到？
切片放在 GDC，以 SVS 格式交付；IDC 另有 DICOM 化的副本（SM 模态），便于与影像在同一云端视图检索。切片索引与影像共用患者 barcode。

Q12：如果我只想快速验证一个想法，最省事的路怎么走？
用 digest 表取二十例左右做子集，按 barcode 从 GDC 取对应的突变与分期，跑一遍最简单的特征—标签关联。这条路线一天内能出结果，适合判断值不值得往下做。

术语表

术语	含义
TCGA	癌症基因组图谱计划，美国 NCI 与 NHGRI 联合发起
TCIA	癌症影像档案馆，美国 NCI 托管影像数据
GDC	基因组数据共享平台，TCGA 的临床与分子数据主入口
IDC	影像数据共享云平台，提供 DICOMweb 与大规模检索
LIHC	TCGA 项目中肝细胞癌的编号
HCC	肝细胞癌，原发性肝癌最常见的类型
barcode	患者编号，十二位，跨库通用的主键
TSS	组织来源站点代码，barcode 中的两位
LI-RADS	肝脏影像报告与数据系统，用于无创诊断肝癌
动脉期强化	对比剂注射后动脉期病灶明显强化，是 HCC 典型征象
廓清	门脉期或延迟期病灶密度低于周围肝实质
包膜	病灶边缘的纤维包膜，延迟期强化
门静脉癌栓	肿瘤侵犯门静脉形成的腔内栓子
影像基因组学	把影像特征与分子状态做关联的研究方向
放射组学	从影像中批量提取定量特征的方法
CTNNB1	编码 β-catenin 的基因，激活突变定义一类 HCC 亚型
TP53	最常见的抑癌基因之一，突变与侵袭性表型相关
TERT	端粒酶逆转录酶基因，启动子突变为 HCC 常见事件
SEG	DICOM 的分割对象，用于存放掩膜
SM	DICOM 的切片显微图像对象
RTSTRUCT	DICOM 的放疗结构集对象，也可存放轮廓
SVS	全切片图像常用格式，病理扫描仪输出
digest	集合的文件摘要表，可用于不下载影像的索引
CC BY 3.0	知识共享署名许可，允许商用与再分发
dbGaP	美国受控数据访问体系

附录 A：核心数字速查

项	值
患者	九十七
检查	二百三十七
序列	一千六百八十八
图像	十二万五千余
体积	56.38 GB
模态	CT / MR / PT
版本	v5 / 2020-05-29
许可	CC BY 3.0
GDC 病例	三百七十七
交集	九十七
DOI	10.7937/K9/TCIA.2016.IMMQW8UQ

附录 B：交付文件清单

文件	内容	说明
批量清单（.tcia）	集合下载清单	配合官方客户端使用
DICOM 摘要（XLSX）	患者、检查、序列、图像的索引	不下载影像也能做规划
临床快照（ZIP）	2016 年 1 月的临床数据	已被 GDC 在线数据取代，仅供对照
影像本体	一千六百八十八个序列	DICOM 格式

附录 C：外部资源对照

资源	提供什么	与本集合的关系
TCIA 集合页	影像与元数据	主入口
GDC 项目页	临床、组学、切片	配对侧
IDC 集合视图	云端 DICOM 视图与切片	检索与云上计算
Zenodo 器官分割	自动生成的器官掩膜	外部结果集
DataCite 记录	DOI 与引用计数	学术计量

附录 D：最小取数脚本

#-- 建一张「患者 → 是否有影像 → 是否有突变」的对照表骨架
import json, pandas as pd

with open("gdc_cases.json", encoding="utf-8") as f:
    hits = json.load(f)["data"]["hits"]

rows = [{"patient": h["submitter_id"].strip().upper(),
         "stage": (h.get("diagnoses") or [{}])[0].get("ajcc_pathologic_stage")}
        for h in hits]
df = pd.DataFrame(rows).drop_duplicates(subset="patient")

digest = pd.read_excel("doiJNLP-TCGA-LIHC-01-30-2017-nbia-digest.xlsx")
img_ids = set(digest["PatientID"].astype(str).str.strip().str.upper())

df["has_image"] = df["patient"].isin(img_ids)
print(df["has_image"].value_counts())
print(df.groupby("stage")["has_image"].mean().round(3))

这段的作用不是建模，而是把「覆盖率」这个最容易被含糊带过的数字算成一个可引用的比例。

附录 E：如果只记五件事

第一，它是九十七位肝癌患者的术前影像，与三百七十七例的分子队列按 barcode 相连，两者不是同一个数。

第二，它没有掩膜，只有原图；要标注得自己做，要做分割请换 LiTS 那类数据。

第三，三模态都有但极不均衡，CT 是主体，MR 的序列最多但患者最少。

第四，它与 HCC-TACE-Seg 互补而非互替：一个有疗效无组学，一个有组学无疗效。

第五，它的价值在于身份统一与许可宽松，不在于规模与标注。

编辑说明

核验时间：2026 年 10 月。核验方式：以 TCIA 集合页正文为主入口（含五个版本的逐版统计与日期处理说明），交叉核对 GDC 项目页的病例与文件计数、IDC 集合视图的模态口径、DataCite 的 DOI 记录。数字口径一律采用官方页面原文，不在本地下载影像重算。章节校核由编辑部按同名模板统一执行。

未覆盖的内容：逐模态的患者级拆分未见官方页面单独给出，因此正文只描述覆盖「不均」而不给分模态例数；序列级质量评估、期相分布、厂商分布与病灶直径分布未做统计，一是超出介绍范畴，二是需要逐例读取 DICOM 头，与「不做审计」的原则相悖。影像基因组学关联的文献综述只点到方向，不列具体效应量。

口径冲突记录：一是患者数，TCIA 集合页的九十七与 GDC 项目页的三百七十七并存，本文按平台分别标注，不合并、不折算。二是模态，集合页只列 CT、MR、PT，IDC 视图另列 SM 与 SEG，前者是 DICOM 化的切片副本，后者是外部生成的器官分割，均不属集合本体，故正文坚持「集合本体不含掩膜」。三是版本，DOI 在 DataCite 注册于 2016 年 1 月，而集合首个版本标注为 2014 年 5 月，两者时间不等，本文按集合页的版本日期叙述，DOI 注册时间只作背景。四是引用作者，DOI 记录列为八位作者，集合页的致谢名单另有机构分区，本文只按 DOI 列出的作者叙述。

本文提及的站内数据集均使用官方英文名，站内链接与文末导航由发布管线按标签统一生成，不在此处手写。