肾透明细胞癌 TCGA-KIRC — 二百六十七例三模态影像

TCGA-KIRC 是癌症影像档案馆（TCIA）托管的肾透明细胞癌影像集合，名称末尾的 KIRC 是 TCGA 项目编号，对应 Kidney Renal Clear Cell Carcinoma。集合页给出的规模是三组数字：二百六十七例患者、四百三十九次影像检查、二千六百五十四个序列、十九万余幅图像，合计 91.56 GB，模态为 CT、MR 与 CR。这个集合本身不含任何分割掩膜，也不含临床与基因组数据，后两者在基因组数据共享平台（GDC）上，两侧靠一串 TCGA 患者编号对齐。

它在选题上的位置很特殊。TCGA 的四十余个项目里，真正把影像汇交到 TCIA 的只有少数几个，肾癌是泌尿系里影像覆盖最完整的一支，而且三模态并存。更关键的是它与组学共用同一套患者身份：一位患者的 CT 与他的 VHL、PBRM1、BAP1 突变、stage 分期、生存月数，用同一个十二位编号就能串起来。这种「原图 + 病理 + 组学」的三件套，在同规模的公开肾癌资源里几乎没有第二个。

需要提前说清两条边界。第一，它给的是原图和配对组学，不是原图加掩膜，任何需要像素级标注的任务都要先自己补上这一层。第二，影像只覆盖 TCGA-KIRC 全景的一部分，二百六十七例对五百三十七例，落差接近一半，把它当成「TCGA 肾癌全队列」会系统性地低估分母。一屏速览见下表。

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

§1 它要解决的具体麻烦

1.1 一句话结论：它解决的是「同一批人的影像与基因能否对上号」

如果只有一个肾癌影像库，它回答「肾癌长什么样」；如果只有一个组学库，它回答「肾癌的分子分型是什么」。两者各自都能做，但中间那道最贵的问题——「长成这样的肿瘤，分子上是不是有特定的驱动改变」——无论哪一边单独都答不了。TCGA-KIRC 的全部价值落在这道题上：它不是收集尽可能多的腹部 CT，而是把已经做过全套分子测量的那批人的术前片子找回来，配上同一串编号。

这个定位决定了它的所有优点与所有缺点。优点是与组学、病理、生存的配对是「结构性的」而不是「事后匹配的」，官方页面明确写着影像的 Patient ID 与 GDC 中同一病例的 Patient ID 完全相同，且每一位 TCGA 病例在 TCIA 上的基线检查均为术前。缺点是它的影像采集完全服务于「补一刀片子」，不服务于影像学本身的研究设计：没有统一协议、没有重建规范、没有病灶标注。

把这句话再收紧一次：它不生产影像，它把已经散落在七个影像来源站点的常规诊疗影像收拢回来，挂上与分子数据相同的主键。理解这一点，后面的边界就都是自然而然的推论。

1.2 三条常见的错误期待

第一条是把 TCGA-KIRC 当成「肾癌影像数据集」。它是「肾癌影像加了分子注释的那一小批人」，规模只有二百六十七例，且不是为了影像任务采的。想要大样本肾脏影像，用腹部 CT 通用库；想要分割标签，用肾脏肿瘤挑战赛数据；想要组学配对，才轮到它。

第二条是把它和 TCGA 的其他影像集合当成一个整体。TCGA 在 TCIA 下有十余个影像集合，彼此共享 barcode 规则与 barcode 前缀「TCGA」，但病例、模态、标注深度各不相同。肺腺癌的集合没有影像，胶质瘤的集合有 MR 但没有腹部信息，头颈的集合是另一个解剖部位。它们能拼在一起分析的只有「同一套命名规则」，不是「同一份数据」。

第三条是以为下载下来就是「AI-Ready」。它是一个 DICOM 归档，不是一个训练集：没有统一的窗宽窗位、没有器官掩膜、没有患者级划分、没有数据清洗。从 91.56 GB 的原始 DICOM 到一个可训练的肾脏肿瘤数据集，中间还差一整套预处理，这在后文 §5 会展开。

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

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

你的处境	它能帮你什么
想验证某个 CT 纹理特征与 VHL 或 PBRM1 状态是否相关	提供同一批患者的术前 CT 与 GDC 突变表，按 barcode 直接连
在做肾脏肿瘤分割，缺带组学标签的外部验证集	提供未标注的原图，标签需自建；可作目标域，不可作分割真值
需要「影像—病理—基因」三件套的样本做多模态预训练	三件齐全且同主键，是少数不用拼凑的来源之一
想研究增强期相与病理分级的关系	有增强 CT 与 GDC 的分级字段，但期相不统一，需逐例读头
需要大样本腹部 CT 训练器官分割	规模不够，且无掩膜，应去看腹部器官分割类数据集
想复现某篇放射组学论文的影像特征	论文若用此集合，barcode 可对齐；但预处理差异会导致数值不可比
想研究术后复发与随访影像	随访影像极少，只有术前基线，做不了纵向建模

1.4 它能给到的与给不到的

这一节把「有」与「没有」摆在一起看，比单看任何一边都清楚。判断一个数据集能不能用，往往不取决于它有什么，而取决于它缺的那一项是否正好是你的必需项。

维度	有	没有
影像	CT、MR、CR 三模态原始 DICOM	统一协议、统一重建、统一期相
标注	分析结果集里的定性特征表	集合本体的像素级分割掩膜
分子	GDC 上的突变、拷贝数、表达、甲基化、蛋白	集合内部的分子文件（需另去 GDC 取）
病理	GDC 上的数字病理切片	集合内部的切片文件
临床	GDC 上的分期、分级、生存	集合内部的结构化临床表（仅快照 XLSX）
随访	生存与随访天数	系列影像随访
身份	统一 barcode，跨库可连	跨集合统一的影像编号体系外的主键

1.5 不适合谁：四条边界

如果你的需求是「训练一个能直接跑的肾脏肿瘤分割模型」，它给不了你标签。整个集合是一个纯净的 DICOM 归档，没有 SEG、没有 RTSTRUCT、没有 NIfTI 掩膜。你会得到二千六百多个序列和零个标注，然后花掉大部分时间在勾画上。这种任务应该去用肾脏肿瘤挑战赛那类带逐例掩膜的数据。

如果你的需求是「覆盖 TCGA 肾癌全队列的分子分析」，它给不了你全景。它只有二百六十七例有影像的患者，而 GDC 上这个项目是五百三十七例。想用全量做分子分析，直接去 GDC，不必经过 TCIA。

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

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

1.6 三条判断规则

第一条规则：先问「要不要分子」，再问「要不要影像」。 如果只要影像，这里不是性价比最高的选择；如果分子是研究的一半，这里的配对结构就值回全部预处理成本。

第二条规则：先看 GDC 例数，再看 TCIA 例数。 两个数不一样，而且差距是结构性的。任何写进论文的样本量都要说明用的是哪一个口径，否则审稿人一问「为什么不是 537」就会很被动。

第三条规则：先确认你要的那一层标注在哪。 集合本体只有原图，定性特征表在分析结果集，器官分割在外部仓库，分子在 GDC，病理在 GDC。四层分散在四处，这是这个资源最容易被低估的操作成本。

§2 数据构成与规格

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

TCIA 的存储模型严格遵循 DICOM 信息模型，分四级。最上层是患者，标识是 PatientID；一位患者下可以有多次检查，每次检查对应一次就诊的影像；一次检查下挂若干序列，连续图像或同一采集参数下的一组图像构成一个序列；序列下面是图像实例，每幅图对应一个 SOP Instance UID。集合页上的四个数字正好对应这四级：患者、检查、序列、图像。

这个四级结构带来两个实用后果。其一，「例数」这个词在这个集合里是有歧义的，必须说明是患者、检查还是序列。二百六十七位患者对应四百三十九次检查，平均每人多于一次；二千六百五十四个序列平均每次检查约六个序列，这与腹部常规检查「平扫 + 多期增强 + 重建」的序列数相符。其二，任何按序列统计的指标都会放大患者之间的不均衡：一位做过三期增强的患者可能贡献十几个序列，而一位只做平扫的患者只贡献一两个。

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

2.2 模态构成与不均

集合的模态一栏写的是 CT、MR、CR 三个词，但这三个词的覆盖量完全不对等。CT 是主体，腹部增强 CT 是肾透明细胞癌术前评估的标准检查，绝大多数患者的影像是 CT。MR 只覆盖一部分患者，用于碘对比剂禁忌或需要软组织对比的情形。CR 是数字化 X 线摄影，出现在这个集合里主要是作为定位像或胸片一类的伴随检查，解剖信息量远低于断层图像。

这种不均有两重含义。做 CT 研究时可以按患者为单位抽取，样本量接近集合总量；做 MR 研究时样本量会显著缩小，而且 MR 序列内部的参数差异比 CT 更大，T1、T2、DWI、动态增强的对比意义完全不同。跨模态合并时需要格外小心，不同模态的图像强度没有可比性，直接混入同一个归一化流程会引入模态伪影。

2.3 一条记录的解剖

下面是一次检查在一个序列目录下的实际形态。字段值取自 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            = 20020712              # 已整体平移，保留相对间隔
SeriesInstanceUID    = 1.3.6.1.4.1.<站点>.…
SeriesDescription    = ABDOMEN  ENHANCED     # 自由文本，厂商与站点习惯不同，不可直接当标签
Modality             = CT
BodyPartExamined     = ABDOMEN
SliceThickness       = 5.0                   # 单位 mm，站点间从 1.25 到 7.5 都有
Manufacturer         = <厂商名>              # 至少四家主流厂商混合
KVP                  = 120
ContrastBolusAgent   = <对比剂名>            # 有增强时才有，非增强扫描该字段为空

逐项看。PatientID 是整条记录里最重要的一格，它是与 GDC 连通的唯一通道；PatientName 虽然也存在，但不承载可用信息，不要把姓名当标识。StudyDate 已经被平移过，不能用于与临床表的真实日期直接相减，只能用于计算同一患者多次检查之间的间隔，因为平移量对同一站点是固定的。SeriesDescription 是自由文本，同一种「增强门脉期」在不同站点会被写成不同的词组，把它当成期相标签是最常见的翻车点。SliceThickness 与厂家字段则直接解释了为什么这个集合的影像「极为异质」。

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	生存状态与天数
无	各 experimental_strategy 下的文件	按 case 关联到文件

对接时有一个细节必须注意：PatientID 是十二位 barcode，而 GDC 的样本 barcode 是十六位，等分样更长。用十六位的样本 barcode 去匹配 PatientID 会全部落空，这在第一次写脚本时几乎必然发生。

2.5 版本与体积的变化

集合自 2014 年首次发布以来经过三次版本。第一个版本是 2014-10-09，影像部分的体积在三个版本中始终未变；第二个版本是 2016-01-05，从 GDC 门户重新抽取了临床数据（TXT 格式），并附上 59.09 KB 的临床包；第三个版本是 2020-05-29，把临床数据链接换成 GDC 最新的电子表格，并新增了来自 GDC 的生物医学表格。也就是说，三次版本的差异全在附带的表格上，图像本体没有重新发布。

这一点很重要：如果你手上有一份较早下载的影像包，它的图像与当前版本完全一致，唯一的差别是附带的临床表格新旧不同。反过来说，任何声称「用了最新版本影像」的表述，在图像层面与用旧版本没有区别。

版本	日期	图像体积	附带表格的变化
v1	2014-10-09	约 91.6 GB	临床 TXT，50.39 KB
v2	2016-01-05	约 91.6 GB	临床 TXT 重抽，59.09 KB
v3	2020-05-29	约 91.6 GB	换为 GDC 最新电子表格，新增生物医学表

2.6 与同类资源的定位差异

把几个容易混淆的资源放在一张表里，差异会一目了然。左下角的判断规则是本节最该记住的一句话。

资源	核心内容	与它的差异
TCGA-KIRC	术前三模态影像 + GDC 组学配对	有分子、无掩膜、规模中等
KiTS23	肾脏肿瘤分割挑战数据	有逐例掩膜、无组学、独立招募
TCGA-KIRC-Radiogenomics	由本集合派生的定性特征表	一百零三例，只有形态描述与突变状态
IDC 的 tcga_kirc 视图	同一批影像的云端口径	例数按 GDC 计，便于云端检索
GDC TCGA-KIRC	临床、组学、数字病理	无影像（影像在 TCIA）

判断规则：要掩膜去挑战赛数据，要组学配对来这里，要全队列分子分析去 GDC，要在云上做批量检索去 IDC。 四者不冲突，但同一份分析要说明用的是哪一层。

§3 核心层 A：身份与边界

3.1 为什么这一层值得单列

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

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

3.2 barcode 的结构

TCGA 的 barcode 是一套分层编码。十二位的患者 barcode 形如「TCGA-XX-XXXX」，前四位固定为项目代号，中间两位是组织来源站点代码，后四位是病例流水号。十六位再往后接样本类型与序号，更长的还会接等分样与析出物。这个设计的好处是前缀可直接用于筛选，坏处是不同长度的 barcode 长得像，容易被误用。

长度	层级	用途	在 TCIA 中
十二位	患者	跨库主键	写入 PatientID
十六位	样本	区分肿瘤、正常、转移	不出现
更长	等分样 / 析出物	对齐到具体文件	不出现

在这份影像集合里只会遇到十二位，因为影像对应的是「人」而不是「样本」。这一点常被忽略：一位患者可能同时有原发肿瘤与癌旁组织的组学，但影像只有一份，它天然无法区分「这张 CT 对应的是哪个样本」。

3.3 两个例数口径的落差

这是全篇最需要写清楚的一处。TCIA 集合页的患者数是二百六十七，GDC 项目页的病例数是五百三十七。两个数都对，但它们回答的是不同问题。

前者是「在 TCIA 上有可发布影像的患者数」，是一个交集的规模；后者是「GDC 上属于这个项目的患者总数」，是一个并集的规模。差出来的部分，是那些做了组织与分子测量、但没有把影像汇交到 TCIA 的患者。这个缺口不是随机的缺陷，而是汇交机制的产物——影像来自自愿参与的影像来源站点，没有参加的站点其患者自然缺席。

口径	数量	含义	常见误用
TCIA 患者数	二百六十七	有影像可下载的患者	被当成 TCGA 肾癌全队列
GDC 病例数	五百三十七	项目登记的全部患者	被当成「都有影像」
派生分析结果集	一百零三	有定性特征表的子集	被当成「全部影像都评过」

这个落差有一个直接的建模后果：任何以影像为输入的模型，其可用的分子标签只覆盖二百六十七例这一侧；如果训练时把 GDC 的五百三十七例都当成样本，会造成标签与输入严重不匹配。反过来，如果只做分子分析而完全不管影像，那么根本不必要经过 TCIA。

3.4 三个数字之间的另一处落差

除了 TCIA 与 GDC 的落差，还有第二处：派生分析结果集 TCGA-KIRC-Radiogenomics 只有一百零三例。这是由 TCGA 肾癌影像研究组做的一次定性读片，三位放射科医师在不知突变状态的情况下独立评估了肿瘤大小、边缘、成分、坏死比例、生长方式与钙化六组特征，然后把特征与 VHL、BAP1、PBRM1、SETD2、KDM5C、MUC4 六个基因的突变状态做关联。

一百零三在二百六十七里的占比约四成，这说明即便在「有影像」的这一侧，专门做过标准化读片的也只是少数。用它做监督学习时，样本量还要再除以一半以上。这不是缺陷，只是必须知道的分母。

3.5 它明确不包含什么

把「不包含」写全，比把「包含」写全更有用。下面这张表是这个集合最实用的部分。

不包含	具体表现	替代方案
分割掩膜	无 SEG、无 RTSTRUCT、无 NIfTI 掩膜	自行勾画；或取外部 BAMF 器官分割
病灶级标注	无肿瘤轮廓、无病灶编号	用派生结果集的定性特征表描述形态
分子与临床文件	集合本体只有影像	去 GDC 取，按 barcode 连
数字病理切片	切片在 GDC	用 GDC 的诊断切片
随访影像	只有术前基线	无替代，纵向分析放弃或另找队列
结构化疗效评价	无 RECIST 类判定	无替代
统一采集协议	按站点与常规诊疗惯例	无替代，只能分层建模
影像级质量评分	无	需自评（信噪比、伪影、期相）

3.6 与 TCGA 其他项目的边界

正因为集合名里都带「TCGA」，很容易误以为它们可以随便拼。实际情况是：TCGA 在 TCIA 上的影像集合对应不同解剖部位、不同病种、不同采集年份，彼此只在「命名规则」上统一。把肾脏的影像与肺部的影像混在一起做「TCGA 通用影像预训练」在技术上可行，但需要先解决层厚、视场、对比度、重建核的全套差异，收益往往抵不过成本。

更实际的做法是用它作为「器官 + 病种 + 分子」三重标签都明确的中等规模集合，配合大样本的通用影像库做预训练，再在这里做带分子标签的微调与验证。

3.7 身份层的一张三问表

问题	答案	依据
一位患者能唯一定位吗	能，十二位 barcode	PatientID 与 GDC submitter_id 同值
影像与分子保证一一对应吗	不保证到样本层	影像对应人，组学对应样本
项目边界在哪	TCIA 二百六十七 / GDC 五百三十七	两个平台各自的项目口径

§4 核心层 B：配对组与影像表型

4.1 这一层的关键：配对是结构性的，不是事后匹配的

多数「影像 + 组学」数据集是事后拼的：一边找影像队列，一边找组学队列，再用人口学变量近似匹配。这种匹配的可靠性取决于匹配变量选得多细，永远带着一层不确定。TCGA-KIRC 不同：影像与分子共用同一套患者身份，从设计上就不存在「匹不匹配」的问题，只存在「覆没覆盖」的问题。

这个差别在写作与报告里体现为一句很实用的话：它不需要说明配对方法，只需要说明覆盖率。 使用者的精力应该放在「二百六十七例里有多少同时有清楚的突变状态」上，而不是「怎么证明这批影像和这批突变是同一批人」。

4.2 组学那一侧有什么

GDC 侧这个项目的实验策略相当齐全。截至核查时的项目摘要，各策略的病例覆盖大致分为三档：基因组层面的全基因组测序覆盖五百余例，甲基化阵列与 SNP 基因型阵列覆盖五百三十余例，RNA-seq 覆盖五百三十余例，miRNA-seq 覆盖五百一十余例，数字病理的诊断切片覆盖五百一十余例、组织切片五百三十余例，反相蛋白阵列覆盖四百七十余例，全外显子测序覆盖三百八十余例，染色质可及性测序只有十余例。项目合计文件数三万五千余份，总体积约二百九十七 TB。

这些数字的意义不在于「多」，而在于「可以在同一个人身上取到多厚的一摞」。做影像基因组学时，真正要的往往不是最厚的层，而是最全的层——比如「突变 + 分期 + 生存 + 影像」四者同时具备的那批人，交集规模决定了可用样本量。

策略	覆盖病例（约）	在影像配对中的角色
全基因组测序	五百余	结构变异、拷贝数全景
甲基化阵列	五百三十余	启动子甲基化与分型
RNA-seq	五百三十余	表达亚型
miRNA-seq	五百一十余	调控层
诊断切片	五百一十余	形态学对照
反相蛋白阵列	四百七十余	蛋白层
全外显子测序	三百八十余	点突变与 indel
染色质可及性测序	十余	可忽略的极小层

4.3 肾透明细胞癌的分子地标

要理解这个集合为什么值得配组学，需要先知道肾透明细胞癌的分子骨架。这个病种最著名的特征是 3 号染色体短臂缺失，由此带来 VHL 基因失活，进而稳定 HIF 通路、驱动血管生成。除此之外，PBRM1、BAP1、SETD2 这三个位于 3p 的染色质修饰基因也经常同时失活，它们把同一个病种切成几个预后不同的亚群。

这层知识决定了影像基因组学在这里的具体形态：影像特征要能对应到「哪一条染色质修饰通路坏了」，而不是笼统地「有没有突变」。派生结果集的读片结论也正是在这个层面展开的——把边缘清晰度、钙化、生长方式这些肉眼可判的形态特征，与特定基因的状态对上。

基因	通路口径	与影像的已知关联（来自派生结果集的读片报告）
VHL	HIF 通路	未见稳定关联，为本队列最常见的改变
PBRM1	染色质重塑	未见稳定关联
BAP1	染色质修饰	与边缘不清、存在钙化相关
SETD2	组蛋白甲基化	未见稳定关联
KDM5C	组蛋白去甲基化	未见稳定关联
MUC4	黏蛋白	与向外生长的形态相关

需要说明，这张表只记录该研究组在派生结果集摘要里明确写出的关联，不构成对其他基因的否定结论。

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

TCGA-KIRC-Radiogenomics 是一个独立的分析结果集，有自己的 DOI 与许可，体积只有 17.04 KB，内容是一张 CSV：一百零三例患者的读片特征、突变状态与临床变量。它不是影像的子集，而是影像的注释层。

它有两点必须讲清。其一，它是定性特征，不是像素标注。肿瘤大小以毫米记，边缘写「清晰」或「不清」，坏死按四档比例分类，没有坐标、没有轮廓。其二，它的伴随影像是从主集合里按一百零三例重新打包的，约 22.67 GB、一百一十八次检查、七百三十八个序列、四万余幅图像，与主集合的口径不同，不能把两者混着数。

项	TCGA-KIRC 主集合	派生结果集
患者数	二百六十七	一百零三
交付物	原始 DICOM	一张 CSV
标注形态	无	六组定性特征
体积	约 91.6 GB	17.04 KB（图像另计约 22.67 GB）

4.5 影像表型的可复用边界

从这批影像能稳定提取的表型有两类。一类是形态学的，例如最大径、外生比例、是否囊性、有无钙化、边缘规整度，这些在派生结果集里已经有人读过一遍，可以作为参考标准。另一类是纹理与强度的，例如不同期相的直方图、灰度共生矩阵、游程特征，它们是放射组学论文的主体。

第二类的问题在于可重复性。影像异质、期相不统一、层厚不一致，三者叠加会让同一特征在不同患者的数值分布严重偏斜，甚至在不同站点之间形成系统性偏移。任何跨站点建模都必须把站点作为一个显式的协变量纳入，否则模型学到的可能是「哪个站点」，而不是「哪种生物学」。

4.6 配对实践中的三个坑

这三个坑是这类「barcode 配对」资源的通病，在这个集合上尤其明显。

#-- 用 barcode 取交集：切分长度必须精确，否则全部落空
import re
IMG_IDS = {"TCGA-AB-1234", "TCGA-CD-5678"}      # 来自 TCIA digest 的 PatientID
GDC_ROWS = [{"submitter_id": "TCGA-AB-1234-01A"},
            {"submitter_id": "TCGA-CD-5678-01A"}]  # 来自 GDC 的样本 barcode

def to_patient(bc: str) -> str:
    # 十二位患者 barcode = 前三段，用 '-' 切分取前三段最稳
    return "-".join(bc.split("-")[:3])

gdc_patients = {to_patient(r["submitter_id"]) for r in GDC_ROWS}
inter = IMG_IDS & gdc_patients          # 只有在两侧都归一为患者层后，交集才有意义
print(len(inter))

第一坑是用样本层 barcode 去匹配患者层。第二坑是后缀里的「01A」「11A」代表样本类型，若用字符串前缀匹配，可能把正常的「11A」错配成肿瘤。第三坑是大小写，个别站点导出的 PatientID 会带小写或空格，入库前必须先做规整。这三条都不是理论风险，是每次重建队列都会遇到的实际问题。

4.7 病理这一侧的角色

数字病理切片放在 GDC，不在 TCIA 集合内。对本集合的使用者来说，病理的价值在于它提供了一个「独立的形态学参照」：影像上的边缘不清，可以在切片上验证是否为浸润性生长；影像上的坏死比例，可以在切片上核对。三模态（影像、病理、组学）的同主键是它最大的结构性优势，但这个优势的兑现需要用户自己到两个平台分别取数，再把它们拼起来。

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

即便做了完美的配对，能进入「影像 + 突变 + 生存」三方交集的患者也只是二百六十七的一个子集。若再加上「有可用增强期相」与「影像质量合格」，实际可用样本量通常在两位数与低三位数之间。这不是数据缺陷，而是这类「回顾性汇交 + 自愿参与」资源的固有上限。任何基于它的研究，样本量都应该在方法部分如实交代，而不是含糊地写成「TCGA 肾癌队列」。

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

5.1 三条取数通道

这一层对应的是工程实施的人。同一个集合有三条取数路径，各有各的门槛与适用面。

通道	入口	门槛	适用场景
TCIA 官方	集合页的批量清单 + Data Retriever	需装 Java 客户端	全量下载，最稳妥
IDC 云端	Imaging Data Commons 的门户与 API	需 Google Cloud 账号	云端批量检索、按标签筛选
第三方镜像	各类研究仓库（如 Kaggle 上的裁剪版）	无需安装	快速试验，但不是官方口径

第一条是官方路径：从集合页下载一个 .tcia 清单文件，用官方提供的检索客户端发起下载。这条路径的好处是清单与集合版本严格对应，坏处是需要安装与配置桌面客户端，不适合无头服务器。

第二条是云路径：IDC 把 TCGA 系列影像统一编码进 DICOMweb，可以用 REST 接口按集合、模态、解剖部位筛选，再把结果取到本地或直接在同区计算。这条路径适合批量实验，但要注意 IDC 的例数口径与 TCIA 不同，它按 GDC 的病例计。

5.2 用官方 API 查集合口径

TCIA 的公开 API 可以按集合名查询患者数、检查数、序列数，这条命令不需要任何客户端。

#-- 查集合的层级计数与模态分布；Collection 名不区分大小写
curl -s "https://services.cancerimagingarchive.net/nbia-api/services/v1/getCollectionValues?Collection=TCGA-KIRC"

返回是 JSON，每个元素含 collection、modality、count 三个字段。用它可以在动笔前先确认「当前」的序列数是否仍与页面一致，因为 TCIA 偶尔会在不升版本号的情况下补充个别序列。

5.3 在 IDC 上按条件筛选

IDC 的查询走 DICOMweb，下面这条取的是该集合中 CT 模态的患者清单，只取前几列便于核对。

#-- 需要 google-cloud-bigquery 与已认证的 GCP 账号
from google.cloud import bigquery

client = bigquery.Client()
sql = """
SELECT DISTINCT PatientID, Modality, SeriesInstanceUID
FROM `bigquery-public-data.idc_current.dicom_all`
WHERE collection_id = 'tcga_kirc'
  AND Modality = 'CT'
LIMIT 20
"""
for row in client.query(sql).result():
    print(row.PatientID, row.Modality)

这段的重点不在 SQL 本身，而在 collection_id = 'tcga_kirc' 这个过滤条件：IDC 的集合名是全小写加下划线，与 TCIA 页面的「TCGA-KIRC」不同，写错大小写会静默返回零行。

5.4 从 digest 表做本地索引

集合页提供了一个 XLSX 摘要。它是一份「不下载影像也能做规划」的索引，值得先读。

#-- 读 NBIA digest，统计每位患者的检查数与模态，判断是否值得下载
import pandas as pd

df = pd.read_excel("TCIA_TCGA-KIRC_09-16-2015-nbia-digest.xlsx")
#-- 列名随 TCIA 模板变动，先打印确认
print(df.columns.tolist())

per_patient = df.groupby("PatientID").agg(
    studies=("StudyInstanceUID", "nunique"),
    series=("SeriesInstanceUID", "nunique"),
    images=("SOPInstanceUID", "count"),
)
print(per_patient.describe())

用它可以在全量下载前回答三个问题：有多少患者只有一次检查、有多少患者同时有 CT 与 MR、序列数分布的长尾有多长。这三个答案直接决定下载量与后续预处理的复杂度。

5.5 到 GDC 取配对分子表

影像下好之后，第二步是把分子表拉下来。GDC 的 API 支持按项目过滤，下面这条取的是项目内全部病例的临床信息。

#-- 取 TCGA-KIRC 全部病例的临床字段，结果直接落 JSON
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-KIRC"]}},
       "fields":"submitter_id,demographic.vital_status,demographic.days_to_death,diagnoses.ajcc_pathologic_stage,diagnoses.primary_diagnosis",
       "format":"JSON","size":1000}' \
  -o kirc_cases.json

size 要设得足够大，默认值很小，取不满时接口不会报错，只会静默截断。这是取临床表最常见的失手方式。

5.6 三条通道的口径对照

项	TCIA 页面	IDC	GDC
病例数	二百六十七	按 GDC 计，五百三十七	五百三十七
影像	有，DICOM	有，DICOMweb	无
分子	无	无	有
病理	无	有切片引用	有，SVS
主键	PatientID	PatientID	submitter_id

5.7 存储与算力的粗略预算

总体积是压缩后的归档体积，解压并转为常见的研究格式后，实际占用会显著膨胀。若把序列转成单文件的三维数组，二千六百五十四个序列中每个序列动辄几十到几百兆，总占用进入数百 GB 量级。若保留 DICOM 原样，则硬盘压力小但读取慢。

合理的做法是分阶段：先只下二十四位患者试跑流程，确认窗宽窗位、重采样与掩膜生成都走通，再扩大到全量。一次性拖全量再回头改预处理参数，是这类项目里最浪费时间的顺序。

§6 与库内词条的关系

6.1 关系图谱

站内与它关系最近的几类词条可以分成四组。第一组是同属 TCGA 体系的影像与组学条目，它们共享 barcode 规则、共享同一套数据使用协议，是「同一家族」的关系。第二组是肾脏影像方向的条目，与它共享解剖部位，但采集目的与标注深度完全不同。第三组是通用的腹部影像与分割条目，可以作为它的预训练来源或工具参照。第四组是泛癌与多组学的汇总条目，从更高一层覆盖它。

组	词条	关系性质
TCGA 家族	肺腺癌、胶质母细胞瘤、低级别胶质瘤、头颈鳞癌、乳腺浸润癌	同体系、同 barcode、不同部位
TCGA 总览	TCGA 与泛癌图谱	上位覆盖
肾脏方向	KiTS23	同解剖部位，互补标注
腹部通用	CT-ORG、LIDC-IDRI	预训练或工具参照

6.2 与 TCGA 家族其他成员的分工

在 TCGA 家族内部，各影像集合的分工其实按「解剖部位的成像成熟度」自然形成。胶质瘤的集合以 MR 为主，因为脑部 MR 是标准检查；头颈的集合以 CT 与 MR 并重；乳腺与肺的影像在 TCIA 上的覆盖远不如其组学覆盖；肾癌这一支恰好是「三模态都有、与组学配对完整」的一支。

这意味着跨条目引用时要注意：不能因为「都是 TCGA 影像」就在方法上互相照搬。脑 MR 的配准、颅骨剥离、强度归一化，与腹部 CT 的窗宽窗位、期相识别、器官分割，是两套完全不同的工程。

6.3 库内肾癌整块空缺时的替代路径

库内目前没有独立的肾细胞癌组学词条，KiTS23 提供了肾脏肿瘤的分割侧，但它的定位是挑战赛数据，不含配对组学。因此，涉及肾癌「影像—基因型」的问题，这一资源是唯一同时具备两侧的来源。

替代路径有两条。第一条是把它与 KiTS23 组队：KiTS23 提供带掩膜的分割预训练，这一资源提供带分子标签的目标域，两者用各自的病例，不做病例级合并。第二条是把 GDC 的肾癌项目当作分子侧的独立入口，只从这一资源取影像，把组学取数完全交给 GDC 的通用流程。

6.4 与腹部通用影像条目的边界

CT-ORG 这类多器官 CT 分割条目与这一资源的关系不是「同类」，而是「上下游」。上游是通用器官分割可以提供肾脏的粗轮廓，用作这一资源影像的自动预分割；下游是这一资源提供的病例可以检验上游模型在「病态肾脏」上的泛化——肿瘤改变了肾脏的形态，通用模型在这种形态上的表现往往明显下降。

LIDC-IDRI 的关系更远，它是胸部 CT，唯一可借鉴的是它把「多读者标注」组织成数据的方式。派生结果集的三读者独立读片，在方法学上与它的多读者结构同源。

6.5 组合使用的三种配方

配方一：分割预训练 + 分子微调。 在带掩膜的分割数据上训练肾脏与肿瘤分割，再把模型用到本集合的影像上生成伪掩膜，最后把伪掩膜对应的影像特征与 GDC 的突变表关联。风险是伪掩膜的误差会污染下游关联。

配方二：定性特征做弱监督。 用派生结果集的一百零三例定性特征作为监督信号，训练一个预测「边缘清晰度」「坏死比例」的模型，再把模型推广到未读片的那一部分患者，扩充标签。

配方三：纯分子分析，影像只做分层。 把影像当作分层变量（例如按肿瘤最大径分箱），主体分析完全在 GDC 侧进行。这条路线对影像质量最宽容，适合小样本假设。

§7 质量评估与局限性

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

在给评分之前必须校正一个框架错位。如果把 TCGA-KIRC 当成一个为机器学习准备的数据集来评价，它会在很多维度上不及格——没有划分、没有标注、没有清洗、类别不平衡、协议五花八门。但这个评价框架本身就是错的。

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

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

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

第一，同主键。影像与分子不是事后匹配，而是同一身份的两面。这一点在同规模资源里罕见。

第二，可追溯。每份影像都能回到 GDC 的病例、样本、文件，任何一个数字都能被第三方独立核到。

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

7.2 DAIMS 评分表

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

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

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

对你意味着什么。 若你在做需要注册审批的合规项目，这里的许可清晰度能省掉大量沟通；若你在做需要严格对照实验的方法研究，这里的可复现性会迫使你把预处理流程完整写进方法章节，而这恰恰是很多论文最薄弱的一段。

7.3 已知的、可枚举的局限

局限	具体表现	影响
无掩膜	集合本体零标注	分割任务需自建标注
覆盖不全	二百六十七对五百三十七	不能代表全队列
模态不均	CT 为主，MR 与 CR 少数	跨模态分析样本骤减
协议异质	厂商、层厚、期相由站点自定	特征分布偏移
日期平移	整体平移三到十年	不能与临床真实日期相减
随访影像缺	只有术前基线	纵向建模不可行
无质量评分	无信噪比、伪影标记	需自建质控
样本层不可分	影像对应人，不是样本	多病灶患者无法分样本

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

TCIA 与 GDC 对日期的处理方式完全不同，而这两套方式之间没有任何调和计划。TCIA 侧的 DICOM 头里，所有日期都被整体平移了若干天，平移量在三到十年之间，对同一站点、同一集合是固定的，因此同一患者多次检查之间的间隔被准确保留。GDC 侧的临床日期则全部转换成「距病理诊断日的天数」，诊断日本身为零。

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

7.5 外部验证矩阵

验证对象	可用证据	结论
例数与检查数	集合页三个版本一致，IDC 口径可交叉核对	一致（口径需说明）
图像体积	三个版本完全一致	稳定
模态	页面、IDC 过滤器、digest 表三处	一致
组学覆盖	GDC 项目摘要	可核，各层覆盖不同
定性特征	派生结果集的 DOI 与论文	可核，样本为一百零三
分割来源	外部仓库与 IDC 分析结果	不属于本集合本体

7.6 它为何能持续

这个资源能长期存在，靠的不是经费单点支持，而是三层依赖互相咬合。第一层是 TCGA 本身的历史地位：它是一个被写进无数论文的队列，任何研究只要用了它，就必须保证数据可访问，否则复现链条断裂。第二层是云平台把访问成本降到了接近零——IDC 与 BigQuery 让「查一下」变成一条 SQL，这让它从「需要下载 91 GB 的资源」变成「随手可查的资源」，使用频次因此跃升。第三层是授权模式：CC BY 3.0 让商业与非商业用途都不必谈授权，减少了使用摩擦。

这三层咬合的结果是：即便原始的影像来源站点早已不再维护这批数据，集合本身仍会被反复引用。它的存续不依赖任何单个机构的热情，而依赖引用生态的惯性。

§8 版本与生态

8.1 版本节奏

三次版本的节奏很不均匀：2014 年首发，2016 年小修，2020 年再修，此后到核查时没有第四个版本。这个节奏反映的是它的维护模式——它是一个「已完成」的集合，维护工作主要是把附带的表格跟上 GDC 的变化，而不是持续吸纳新病例。

版本	日期	主要动作
v1	2014-10-09	首发，从 GDC 抽取临床 TXT
v2	2016-01-05	重新抽取临床数据
v3	2020-05-29	换用 GDC 最新电子表格，新增生物医学表

对使用者的实际含义：引用时应写明版本号，官方引用格式本身就把「Version 3」写进了标题。若某项分析是在 v2 时期完成的，用它当时的临床表与现在的表可能存在字段差异。

8.2 组织方式

这个集合的组织者不是 TCIA 自己，而是一个名为 TCGA 肾癌影像表型研究组的社区机构。它的运作方式效仿 TCGA 的分析组：参与机构贡献影像，组成影像来源站点组，由该组负责该癌种的数据积累，并有权按既定规则发表一篇标志性论文。派生结果集正是这一机制的产物。

这套机制解释了两件事。其一，为什么是这个病种先有了影像配对：有机构愿意投入。其二，为什么影像只覆盖二百六十七例：贡献是自愿的，没有参加的站点其患者自然缺席。

影像来源站点	所在城市
Memorial Sloan-Kettering Cancer Center	纽约
University of Pittsburgh / UPMC	匹兹堡
Mayo Clinic	罗切斯特
University of North Carolina	教堂山
National Cancer Institute	贝塞斯达
M.D. Anderson Cancer Center	休斯敦
Roswell Park Cancer Institute	布法罗

8.3 衍生资源的谱系

围绕这个集合长出了几类衍生资源，它们的血缘关系值得理清。

第一类是定性读片表，即派生结果集，直接由人类读片产生。第二类是器官分割，由自动化流程在云上批量生成，放在外部仓库，与集合本体分离。第三类是统一的 DICOMweb 编码副本，放在影像数据共享云平台上，供检索与云端计算。第四类是各类研究论文中提取的特征矩阵，散落在论文的补充材料里，没有统一入口。

衍生类型	交付形态	是否属于集合本体
定性读片表	CSV	否，独立结果集
器官分割	DICOM SEG	否，外部仓库
云平台编码副本	DICOMweb	否，平台视图
论文特征矩阵	补充材料	否

8.4 生态位

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

这一定位相当稳固：挑战赛数据天然不做分子随访，泛癌资源天然不做单病种深挖，中间这一层很难被替代。

§9 使用指引

9.1 三种角色的路径

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

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

9.2 一条最短的可用流程

下面这条流程把「从零到一个可训练的小表」压缩成五步，每一步都可以单独验证。

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

#-- 2) 取 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-KIRC"]}},
       "fields":"submitter_id,diagnoses.ajcc_pathologic_stage","format":"JSON","size":1000}' \
  -o gdc_cases.json

#-- 3) 下载影像清单，稍后用官方客户端批量取图
curl -s -O "https://www.cancerimagingarchive.net/wp-content/uploads/TCIA_TCGA-KIRC_09-16-2015.tcia"

#-- 4) 读 digest 建本地索引，确认每个 barcode 对应的检查与序列
python3 -c "import pandas as pd; d=pd.read_excel('TCIA_TCGA-KIRC_09-16-2015-nbia-digest.xlsx'); print(d.groupby('PatientID').size().describe())"

#-- 5) 取交集，得到「既有影像又有分子」的最终名单
python3 -c "import json; a={r['submitter_id'] for r in json.load(open('gdc_cases.json'))['data']['hits']}; print(len(a))"

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

9.3 引用与致谢

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

9.4 合规清单

事项	要求
许可	CC BY 3.0，允许再分发与商用，需署名
引用	必须引用集合 DOI 与版本
致谢	必须包含给定的 TCGA 研究网络声明
再识别	不得尝试重新识别个体
日期	不得尝试还原被平移的真实日期
二次分发	可以，但需保留许可与出处

§10 AI 使用声明

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

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

10.2 三种不该有的期待

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

第二种是期待它代表肾癌总体。它是自愿汇交的影像子集，站点集中在北美七家机构，患者的构成必然带有站点特征。

第三种是期待它给出因果结论。派生结果集报出的关联是统计上的，样本一百零三例，多个基因同时检验，任何单条显著结果都需要外部重复验证。

10.3 生成式模型的使用边界

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

10.4 不应由它承担的判断

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

常见误读

常见说法	实际情况	证据
它是 TCGA 肾癌的全部患者	只是有影像的一部分，二百六十七对五百三十七	TCIA 集合页与 GDC 项目摘要
它带分割掩膜	集合本体无任何 SEG 或 RTSTRUCT	集合页的 Data Access 表只有 DICOM
每位患者都三模态齐全	CT 为主体，MR 与 CR 只覆盖少数	集合页模态构成与 digest 表
一份影像对应一个肿瘤样本	影像对应人，组学对应样本	TCIA 的 PatientID 是十二位患者层
影像日期可以与临床日期相减	影像日期整体平移三到十年	集合页的日期处理说明
派生结果集是主集合的子集	是独立结果集，有自己的 DOI 与体积	结果集页面
IDC 上是另一份数据	是同一批影像的云端编码视图	IDC 与 TCIA 的交叉引用
有增强 CT 就可以直接做期相分析	期相由站点自由命名，无标准标签	集合页说明采集协议极异质
质可以外推到所有肾透明细胞癌	站点集中、自愿参与，非人群抽样	致谢名单中的七家机构
版本更新会带来新影像	三个版本的图像体积完全相同	三个版本的 Data Access 表

FAQ

Q1：这个集合和 GDC 上的 TCGA-KIRC 是两个数据集吗？
不是。它们是同一个 TCGA 项目的两个面：影像在 TCIA，临床、基因组与数字病理在 GDC，两侧用同一串十二位 barcode 连通。不存在「两份数据」，只存在「两个平台」。

Q2：为什么官方说 267 例，我在别处看到 537？
267 是有影像的患者数，537 是 GDC 项目登记的病例总数。前者是交集，后者是全集。写论文时必须说明用的是哪一个，否则样本量会被质疑。

Q3：有没有办法拿到肿瘤掩膜？
集合本体没有。可行路径有三条：自己勾画；使用外部分析流程生成的器官级分割（例如放在 IDC 与 Zenodo 上的肾脏分割）；使用其他带掩膜的肾脏肿瘤数据集做迁移，但那批患者与这里无关。

Q4：CT、MR、CR 各多少例？
集合页只给出三模态合并后的总数，没有分模态拆开。要拿分模态计数，得读 digest 表按模态分组，或查 IDC 的模态过滤结果。

Q5：CE 是临床资料，为什么不放在一起？
TCIA 是影像档案馆，其职责是存影像；TCGA 的临床与基因组由 GDC 统一管理。分开放的好处是各自的许可与访问控制可以分开管理，代价是使用者要自己拼。

Q6：日期为什么对不上？
TCIA 的日期整体平移了三到十年，平移量按站点固定，患者内部的检查间隔被保留；GDC 的日期是相对病理诊断日的天数。两者设计目标不同，官方明说没有调和计划。

Q7：能用于商业项目吗？
可以。许可是 CC BY 3.0，允许商用与再分发，条件是署名并引用 DOI。但要注意 GDC 侧的分子数据有自己的使用协议，商用前需分开确认。

Q8：为什么图像体积三个版本都一样？
因为三次版本的改动只在附带的表格，图像本体自首发以来没有重新发布。这意味着旧版本下载的影像与当前版本完全相同。

Q9：这个集合适合做多模态大模型的训练吗？
作为多模态对齐环节的验证集合适，作为大规模预训练语料不合适。二百六十七例、单一解剖部位、无文本报告，三者叠加限制了它在预训练阶段的价值。

Q10：怎样复现派生结果集里的关联结论？
需要一百零三例的读片特征表、对应的突变状态与影像三份材料。特征表在结果集页面，突变在 GDC，影像在主集合或结果集自带的影像包里。三位读片者的一致性数据在论文中，不在数据里，因此只能复现结论方向，无法复现读片过程。

Q11：属于哪个病种，能不能当肾癌通用集用？
它是肾透明细胞癌，是肾细胞癌里最常见的亚型，但不等于全部肾癌。乳头状肾细胞癌与嫌色细胞癌有各自的项目，不能合并称作「肾癌队列」。

术语表

术语	解释
KIRC	TCGA 项目代号，Kidney Renal Clear Cell Carcinoma
ccRCC	肾透明细胞癌，KIRC 对应的组织学类型
TCIA	The Cancer Imaging Archive，美国 NCI 的癌症影像档案馆
GDC	Genomic Data Commons，基因组数据共享平台
IDC	Imaging Data Commons，影像数据共享云平台
barcode	TCGA 的分层身份编码，十二位为患者层
DICOM	医学数字影像与通信标准，本集合的存储格式
患者 / 检查 / 序列 / 图像	DICOM 的四个层级
PatientID	DICOM 中的患者标识，本集合里等于 TCGA 患者 barcode
SeriesDescription	序列的自由文本描述，厂商与站点习惯不同
期相	增强扫描中对比剂到达的不同时间点，如动脉期、静脉期
掩膜	像素级的区域标注，本集合本体不提供
SEG	DICOM 的分割对象类型
RTSTRUCT	DICOM 的放疗结构集对象，常用于存放轮廓
派生结果集	由主集合二次加工得到的分析结果，不与主集合合并计数
VHL	肾透明细胞癌最常失活的抑癌基因
PBRM1	染色质重塑相关基因，ccRCC 常见突变
BAP1	染色质修饰相关基因，与预后相关
SETD2	组蛋白甲基转移酶基因
放射组学	从影像中批量提取定量特征的方法
影像基因组学	把影像特征与分子状态做关联的研究方向
NBIA	TCIA 的影像检索系统，digest 表由其导出
digest	集合的文件摘要表，可用于不下载影像的索引
CC BY 3.0	知识共享署名许可，允许商用与再分发

附录 A：核心数字速查

项	值
患者	二百六十七
检查	四百三十九
序列	二千六百五十四
图像	十九万余
体积	约 91.6 GB
模态	CT / MR / CR
版本	v3 / 2020-05-29
许可	CC BY 3.0
GDC 病例	五百三十七
派生结果集病例	一百零三
DOI	10.7937/K9/TCIA.2016.V6PBVTDR

附录 B：交付文件清单

文件	内容	说明
批量清单（.tcia）	集合的下载清单	配合官方客户端使用
DICOM 摘要（XLSX）	患者、检查、序列、图像的索引	不下载影像也能做规划
临床数据包	早期版本的临床快照	v3 已改为链接 GDC 表格
影像本体	二千六百五十四个序列	DICOM 格式

附录 C：外部资源对照

资源	提供什么	与本集合的关系
TCIA 集合页	影像与元数据	主入口
GDC 项目页	临床、组学、数字病理	配对侧
IDC	同一批影像的云端视图	检索与云计算
派生结果集	一百零三例定性读片表	注释层
外部器官分割仓库	自动生成的肾脏分割	不属于本体

附录 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"],
         "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("TCIA_TCGA-KIRC_09-16-2015-nbia-digest.xlsx")
img_ids = set(digest["PatientID"].astype(str).str.strip().str.upper())

df["has_image"] = df["patient"].str.upper().isin(img_ids)
print(df["has_image"].value_counts())   # 两类的比例就是覆盖率

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

附录 E：如果只记五件事

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

第二，它没有掩膜，只有原图；要标注得自己做。

第三，三模态都有但极不均衡，CT 是主体。

第四，协议异质是设计使然，不是质量问题，站点必须进模型。

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

编辑说明

核验时间：2026 年 10 月。核验方式：以 TCIA 集合页正文为主，交叉核对 GDC 项目摘要接口与 IDC 集合页的病例计数，另据派生结果集页面的 DOI 与元数据。数字口径一律采用官方页面原文，不在本地下载影像重算。

未覆盖的内容：各模态的患者级拆分未见官方页面单独给出，本文因此未给分模态例数；序列级质量评估、期相分布与厂商分布未做统计，一是超出介绍范畴，二是需要逐例读取 DICOM 头，与「不做审计」的原则相悖。

口径冲突记录：一是患者数，TCIA 页面二百六十七与 IDC 的按项目计五百三十七并存，本文按平台分别标注，不合并。二是覆盖深度，派生结果集一百零三例与主集合二百六十七例并存，前者是读片子集，后者是影像全集，本文分别列出而未做折算。三是分割的归属，官方集合页把自动生成的器官分割指向外部仓库而非集合本体，因此本文坚持「集合本体不含掩膜」的表述。

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

---

相关数据集导航

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

• synthrad — 共享标签：医学影像 / CT / MRI / 肿瘤学 / 多模态影像
• biomedparse — 共享标签：医学影像 / CT / MRI / 肿瘤学 / 多模态影像
• tcga-ucec — 共享标签：医学影像 / CT / MRI / 肿瘤学 / 多模态影像
• tcga-lihc — 共享标签：医学影像 / CT / MRI / 肿瘤学
• cptac-imaging — 共享标签：医学影像 / CT / MRI / 肿瘤学
• qin-gbm — 共享标签：医学影像 / MRI / 肿瘤学 / 多模态影像
• tcia — 共享标签：医学影像 / CT / MRI / 肿瘤学
• idc — 共享标签：医学影像 / CT / MRI / 肿瘤学
• spinal-multiple-myeloma-seg — 共享标签：医学影像 / CT / 肿瘤学 / 多模态影像
• ca-cancer-verse — 共享标签：医学影像 / CT / 肿瘤学 / 多模态影像

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