cancer-data-aggregator

name	cancer-data-aggregator
description	Search and cross-reference harmonized cancer metadata ACROSS all NCI CRDC repositories at once — GDC (genomics), PDC (proteomics), IDC (imaging), GC (general/CDS), and ICDC (canine) — from one model, via the `cdapython` Python package or its open REST service. Use when the user needs to: find which repositories hold data for a disease, project, or cohort; locate data that spans multiple commons (e.g. CPTAC across GDC+PDC+IDC); build a cross-modal cohort (subjects with BOTH imaging and sequencing, or matched tumor+normal BAMs); cross-reference subjects/files/specimens across data centers; search by harmonized clinical terms (diagnosis, anatomic_site, age, sex, treatment, mutation); or collect DRS URIs to hand files off to a cloud workspace. CDA harmonizes and LOCATES metadata only — it does not download files or run analyses. For deep single-repository analysis (gene-expression matrices, mutation frequency, survival, BAM slicing → `genomic-data-commons`; proteomics quantitation → `proteomic-data-commons`; DICOM imaging → the imaging-data-commons; GC-only data → `general-commons`), locate the data with CDA, then hand off to that commons' skill.
compatibility	Python 3.9+ with the `cdapython` package (`pip install git+https://github.com/CancerDataAggregator/cdapython.git@develop`), which depends on pandas. As of June 2026 that install resolves to **cdapython 2.1.0**, and its default endpoint is already the production service (`get_api_url()` → `https://cda.datacommons.cancer.gov`), so `set_api_url` is optional. No API key or auth required — all CDA metadata is open. The REST service (https://cda.datacommons.cancer.gov/) needs only `requests`. Actually downloading data files (via their DRS URIs) happens outside CDA in a cloud workspace, and controlled-access data still requires the user's dbGaP authorization there.
metadata	{"author":"integrations","source-integration":null,"source-uuid":null}

Cancer Data Aggregator (CDA)

CDA is a service of the NCI Cancer Research Data Commons (CRDC). It pulls metadata from the CRDC repositories, then cleans, harmonizes, and cross-references it into one searchable model so you can find subjects/files/specimens across data centers, discover a disease described differently at each repository, and compile everything from a program (e.g. CPTAC) no matter where it landed.

Data sources: GDC (genomics), PDC (proteomics), IDC (imaging), GC (General Commons, formerly CDS), ICDC (canine). Primary interface: the cdapython Python package. Underneath: an open REST service at https://cda.datacommons.cancer.gov/.

When to use CDA — and when to defer

Reach for CDA when the question is cross-repository or "where is the data?":

• Which commons hold data for this disease / project / cohort? Does anything span several?
• Find subjects/files that appear in more than one repository (e.g. GDC subjects who also have PDC or IDC data); compile a program like CPTAC across GDC + PDC + IDC.
• Build a cross-modal cohort: subjects with both CT images and somatic-mutation files; matched tumor + normal BAMs; VCFs for the same patients in blood and tumor.
• Harmonized search by clinical terms across everything at once (diagnosis, anatomic_site, age, sex).
• Collect drs_uris for a file set to load into a cloud workspace.

Defer to the specialized commons' skill once the data is located and the task is deep, single-repository analysis CDA does not do — CDA is metadata-only:

If the user wants…	Use
Gene-expression matrices, mutation frequency, survival curves, BAM slicing, CNV/SSM analysis	genomic-data-commons
Proteomics quantitation / PDC study tables	proteomic-data-commons
DICOM imaging series / viewers	the imaging-data-commons
Data that lives only in General Commons	general-commons

The pattern is locate with CDA → hand off: CDA finds the data and yields DRS URIs; the specialized commons (or a cloud workspace) analyzes or downloads it.

Authentication

None. Every cdapython call and REST request is anonymous — all CDA metadata is open. CDA does not download data; controlled-access still needs dbGaP authorization when you later resolve its DRS URI in a cloud workspace. See .