Imaging Data Commons
K-DenseCommunityCreated by Andrey Fedorov, @fedorovDistributed by K-Dense
- Skill
- Tool integration
- Science and research
- MIT
- Low risk
- Has scripts
AutoGineer summary
Written by AutoGineer from the skill’s own files, not by the author
The Imaging Data Commons (IDC) skill provides a programmatic interface for accessing large-scale public cancer imaging data. It supports discovery, metadata querying, and file downloads for radiology (CT, MR, PET) and pathology datasets. The skill offers multiple access paths, including a Python client for local workflows, a REST API for lightweight metadata retrieval, and an MCP server for interactive discovery. It handles complex data structures, including DICOM hierarchies and derived analysis results, while ensuring users can verify licensing and citation requirements for research and clinical applications.
What it does
- Queries and filters public cancer imaging metadata using SQL or attribute-based selection.
- Downloads DICOM imaging files directly from public cloud storage buckets.
- Provides browser-based visualization URLs for radiology and pathology images.
- Retrieves licensing information and citation formats for selected datasets.
- Supports integration with DICOMweb-compatible tools and PACS systems.
- Enables programmatic cohort building and manifest generation for large-scale data analysis.
When to use it
- When you need to find and download specific cancer imaging datasets for research.
- When you need to perform metadata-driven cohort selection across large imaging collections.
- When you want to visualize medical images without installing local DICOM viewer software.
- When you need to integrate IDC data access into automated Python or shell-based pipelines.
- When you need to verify the licensing terms of specific imaging series before use.
Advantages
- No authentication required for standard public data access.
- Supports both lightweight REST-based metadata queries and heavy-duty local downloads.
- Provides consistent access to versioned data for reproducible research.
- Includes built-in tools for citation and license management.
- Offers flexible directory templating for organized local data storage.
Usage examples
- “Find all MR series for the 'rider_pilot' collection.”
- Returns a list of SeriesInstanceUIDs and metadata for the requested MR images.
- “Download the first 5 CT series from the 'nlst' collection to my local data folder.”
- Downloads the specified DICOM files into the target directory using the default hierarchy.
- “Get a viewer URL for a specific study.”
- Provides a direct link to an OHIF or SLIM viewer instance for the requested study.
- “What are the license terms for the current selection?”
- Returns a breakdown of license types (e.g., CC BY, CC BY-NC) for the selected series.
Install
Download the skill as a ZIP:
https://autogineer.com/agent-skills/k-dense-ai/imaging-data-commons/downloadUnzip it into the cross-client skills folder of your project:
mkdir -p .agents/skills && unzip imaging-data-commons.zip -d .agents/skills
Documentation by Andrey Fedorov, @fedorov
Imaging Data Commons
Overview
Query and download public cancer imaging data from the National Cancer Institute Imaging Data Commons (IDC). No authentication required for data access.
Expected network access: IDC metadata is reachable three ways — a bundled local DuckDB index (offline after installation; additional indices are fetched from GitHub and clinical tables from S3), or the hosted IDC service over MCP or REST (api.imaging.datacommons.cancer.gov, no authentication). File downloads use public GCS (storage.googleapis.com) and AWS S3 (s3.amazonaws.com) — no authentication required. DICOMweb access uses either the public IDC proxy (proxy.imaging.datacommons.cancer.gov, no auth) or the Google Cloud Healthcare API (healthcare.googleapis.com, requires GCP authentication). Optional BigQuery queries (bigquery.googleapis.com) also require GCP authentication. Citation resolution contacts DOI services. Public IDC routes require no credentials; optional Google clients use Application Default Credentials.
Reviewed 2026-09-30: idc-index 0.12.5, idc-index-data 24.2.2, IDC v24; hosted API 3.0.0b3. Recheck at use time.
Choose the access path first. There is no single default: the cheapest correct path depends on the session and the task.
Session already has the IDC MCP server? Route discovery and metadata there — see IDC MCP Server.
Otherwise, is
idc-indexinstalled and current? Runpython scripts/check_version.py. If it passes, useidc-indexfor everything.Not installed, and the task is read-only metadata — counts, attribute values, collection lookups, SQL under 10 000 rows, licenses, citations, viewer URLs? Use the REST API over
curl; do not install anything. Installing costs ~77 MB of packaged index data plus pandas, pyarrow, and duckdb, which a metadata question does not need. See Data Access Options.Not installed, and the task needs more than metadata — downloading files, pandas or plotting, pydicom/SimpleITK, pathology tiling, results past 10 000 rows, or a version-pinned script the user re-runs? Install
idc-index:check_version.pyexits non-zero and prints the exact install command for the running interpreter. Prefer a virtual environment, then restart Python.
idc-index (GitHub) is still the most
capable Python path, with query and download helpers in one client. check_version.py never installs anything itself — it also flags a newer
idc-index or skill release when one exists.
Setup for the idc-index path: use the intended interpreter for scripts/check_version.py
and confirm its meets pinned minimum message before continuing. A launch failure is not a pass.
from idc_index import IDCClient
client = IDCClient()
# Verify IDC data version (should be "v24")
print(f"IDC data version: {client.get_idc_version()}")Download and image-processing examples are illustrative unless noted; see the reference review notes for verification scope.
Core workflow: query metadata with client.sql_query() → download with
client.download_from_selection() → visualize with client.get_viewer_URL(). Python examples
below assume this client; Data Access Options has the REST equivalents. For current data
scale, run the summary query in references/sql_patterns.md or GET /v3/stats.
IDC MCP Server
IDC operates a hosted MCP server at https://api.imaging.datacommons.cancer.gov/mcp
(streamable HTTP, no authentication). Where it is available it complements — it does not
replace — the idc-index workflow below.
Identify it by the MCP resource idc://guide, or by three or more of the tool names
build_cohort, get_cohort_urls, list_analysis_results, and get_idc_version. Generic
names such as run_sql are not evidence on their own. If identification is ambiguous, use
idc-index.
If this session has the server, treat it as authoritative for discovery and metadata —
IDC version, counts, attribute values, cohort building, metadata SQL — and follow the
server's own instructions rather than re-deriving them from this file. Its data version is
whatever the server reports: call get_idc_version instead of relying on the version pinned
in this file.
Return here for what the server does not do: downloading files, local pandas/notebook
analysis, DICOMweb, BigQuery, digital pathology tiling, and reproducible scripts. Hand off by
passing SeriesInstanceUIDs from the server to client.download_from_selection(...), and run
scripts/check_version.py at that point.
If it is not available, the identical service is reachable with no configuration as a REST
API at https://api.imaging.datacommons.cancer.gov/v3 — use it for read-only metadata rather
than installing idc-index, per the routing gate in Overview. Suggest connecting the MCP
server at most once, only for repeated interactive discovery, and never change the user's
configuration yourself.
See references/mcp_guide.md for the tool inventory, handoff patterns, and per-host notes.
When to Use This Skill
Finding publicly available radiology (CT, MR, PET) or pathology (slide microscopy) images
Selecting image subsets by cancer type, modality, anatomical site, or other metadata
Downloading DICOM data from IDC
Checking data licenses before use in research or commercial applications
Visualizing medical images in a browser without local DICOM viewer software
Quick Navigation
Inline below: the MCP/REST routing rules, the IDC data model, the index tables and how they join, the core API patterns (query, download, visualize, license, cite), best practices, and troubleshooting.
Reference Guides (load on demand):
| Guide | When to Load |
|---|---|
index_tables_guide.md | Complex JOINs, schema discovery, DataFrame access |
use_cases.md | End-to-end workflows: training datasets, batch downloads, DICOM reading with pydicom/SimpleITK, pipeline integration |
sql_patterns.md | Quick SQL patterns for filter discovery, annotations, size estimation |
clinical_data_guide.md | Clinical/tabular data, imaging+clinical joins, value mapping |
licensing_and_citation.md | Commercial-use questions, mixed-license cohorts, citation formats |
cloud_storage_guide.md | Direct S3/GCS access, versioning, UUID mapping |
dicomweb_guide.md | DICOMweb endpoints, PACS integration |
digital_pathology_guide.md | Slide microscopy (SM), annotations (ANN), pathology workflows |
bigquery_guide.md | Full DICOM metadata, private elements (requires GCP) |
cli_guide.md | Command-line tools (idc download, manifest files) |
parquet_access_guide.md | Direct Parquet queries via GCS (no idc-index install needed) |
mcp_guide.md | Hosted IDC MCP server: tool inventory, identification, handoff to idc-index |
rest_api_guide.md | Hosted IDC REST API: endpoints, filter syntax, SQL over HTTP, manifests |
IDC Data Model
IDC adds two grouping levels above the standard DICOM hierarchy (Patient → Study → Series → Instance):
collection_id: Groups patients by disease, modality, or research focus (e.g.,
tcga_luad,nlst). Treat(collection_id, PatientID)as the patient key; do not assume PatientID is globally unique.analysis_result_id: Identifies derived objects (segmentations, annotations, radiomics features) across one or more original collections. Use it to find AI-generated or expert annotations, while
collection_idfinds original imaging data (which may itself include deposited annotations).
Key identifiers for queries:
| Identifier | Scope | Use for |
|---|---|---|
collection_id | Dataset grouping | Filtering by project/study |
PatientID | Patient | Grouping images by patient |
StudyInstanceUID | DICOM study | Grouping of related series, visualization |
SeriesInstanceUID | DICOM series | Grouping of related series, visualization |
Index Tables
The idc-index package provides multiple metadata index tables, accessible via SQL or as pandas DataFrames. The REST API exposes the same tables through GET /tables and POST /sql.
Important: client.indices_overview is the authoritative source for current table descriptions, available columns, and their types — query it when writing SQL or exploring data structure. It also answers "which table contains column X"; see references/index_tables_guide.md for that search pattern and full schema discovery.
Available Tables
Always call client.fetch_index("table_name") before querying any index table — it is safe and idempotent for all tables, including those loaded automatically at startup.
| Family | Tables | Granularity |
|---|---|---|
| Core | index (primary metadata for all current data), collections_index, analysis_results_index | series / collection / analysis result |
| Modality acquisition parameters | ct_index, mr_index, pt_index, contrast_index | 1 row = 1 series of that modality |
| Derived objects | seg_index, rtstruct_index, ann_index, ann_group_index | 1 row = 1 series (or annotation group) |
| Microscopy | sm_index, sm_instance_index | 1 row = 1 SM series / instance |
| Geometry, clinical, history | volume_geometry_index, clinical_index, version_metadata_index, prior_versions_index | see guide |
references/index_tables_guide.md has the full inventory with each table's columns and
contents — load it when you need to know what a specialized table actually holds.
prior_versions_index contains historical series versions, including revised versions
whose DICOM SeriesInstanceUID still occurs in index. Pin crdc_series_uuid for historical
content. For "what's new" in the current release use
series_init_idc_version / series_revised_idc_version in the main index table, which are
not equivalent to this table's min_idc_version / max_idc_version.
Joining Tables
SeriesInstanceUID is the universal join key for all series-level specialized tables: sm_index, sm_instance_index, seg_index, ann_index, ann_group_index, contrast_index, volume_geometry_index, rtstruct_index, ct_index, mr_index, pt_index. Always join these to index on SeriesInstanceUID. The exceptions below use different column names.
| Join Column | Tables | Use Case |
|---|---|---|
collection_id | index, prior_versions_index, collections_index, clinical_index | Link series to collection metadata or clinical data |
analysis_result_id | index, analysis_results_index | Link series to analysis result metadata (annotations, segmentations) |
source_DOI | index, analysis_results_index | Link by publication DOI |
segmented_SeriesInstanceUID | seg_index → index | Link segmentation to its source image series (seg_index.segmented_SeriesInstanceUID = index.SeriesInstanceUID) |
referenced_SeriesInstanceUID | ann_index → index, rtstruct_index → index | Link annotation or RTSTRUCT to its source image series |
Note: subjects, updated, and description appear in multiple tables but have different meanings (counts vs identifiers, different update contexts). A UID-only join to prior_versions_index can match several historical revisions; use CRDC UUIDs to distinguish them.
For detailed join examples, schema discovery patterns, key columns reference, and DataFrame access, see references/index_tables_guide.md.
Clinical Data Access
Clinical (non-imaging) attributes — staging, demographics, therapy — live in per-collection
tables. client.fetch_index("clinical_index") loads the dictionary mapping columns to
collections; client.get_clinical_table(name) returns one table as a DataFrame.
See references/clinical_data_guide.md for the discovery workflow, coded-value mapping, and
joining clinical data with imaging.
Data Access Options
| Method | Auth | Best For | Reference |
|---|---|---|---|
idc-index | No | Downloads, pandas analysis, unbounded queries — the most capable path | This document |
| IDC MCP server | No | Discovery, cohort building, metadata when the session already has it | mcp_guide.md |
| IDC REST API | No | Metadata with no install, from any language or shell — the default when idc-index is absent | rest_api_guide.md |
| Direct Parquet (GCS) | No | Version-pinned queries, or results past the REST row cap | parquet_access_guide.md |
| Cloud storage (S3/GCS) | No | Direct file access, bulk transfer, custom pipelines | cloud_storage_guide.md |
| DICOMweb via IDC proxy | No | Tool and PACS integration; daily quota, so testing and moderate use | dicomweb_guide.md |
| DICOMweb via Google Healthcare | Yes (GCP) | The same DICOMweb API at production volume, without the proxy quota | dicomweb_guide.md |
| SlicerIDCBrowser | No | 3D visualization and analysis in 3D Slicer | https://github.com/ImagingDataCommons/SlicerIDCBrowser |
| BigQuery | Yes (GCP) | Full DICOM metadata, private elements, SR measurements — last resort | bigquery_guide.md |
The IDC Portal (https://portal.imaging.datacommons.cancer.gov/) is interactive only — browser-based exploration, manual cohort selection, and download. Unlike every option above it has no programmatic interface, so point a user there to browse or click through data themselves; never use it as a step in a script or workflow.
REST API — the no-install metadata path
https://api.imaging.datacommons.cancer.gov/v3, no authentication: discovery, cohort counts and
manifests, read-only SQL, clinical tables, viewer URLs, licenses, citations. It is the same
service as the MCP server over plain HTTP, so it needs no configuration. It never moves image
bytes — switch to idc-index to download, to get a DataFrame, or for results past 10 000 rows.
B=https://api.imaging.datacommons.cancer.gov/v3
curl -s $B/version # idc_version, idc_index_data_version, api_version
curl -s $B/stats # collections, patients, studies, series, instances, size_TB
curl -s "$B/attributes/Modality/values?limit=5" # real filter values, with counts
curl -s $B/sql -H 'content-type: application/json' \
-d '{"sql":"SELECT collection_id, COUNT(*) n FROM index GROUP BY 1 ORDER BY n DESC LIMIT 3"}'
curl -s $B/cohort/counts -H 'content-type: application/json' \
-d '{"filters":{"terms":{"collection_id":["rider_pilot"]}}}'The filter object always goes under filters — on cohort/counts, cohort/manifest,
cohort/manifest.txt, licenses, and citations alike. A bare filter or an unrecognized key is
a 422 naming the fix; an unfiltered series-enumerating request is a 400, not the whole archive.
Filtered JSON responses echo filters_applied and warnings (inside counts for manifests) — read them, because they name
any predicate the server dropped. A zero count with empty warnings therefore means the filter
matched nothing, not that a value was miscased; miscasing produces a warning that says so.
POST /sql takes one read-only SELECT/WITH over the tables idc-index exposes plus
clinical.<table>; max_rows defaults to 5 000, caps at 10 000, and truncated flags clipping.
GET /attributes lists the 19 filterable attributes — clinical values, segmented anatomy, and
acquisition parameters are not among them and need SQL. Request limits still apply. Use
v3 only: V1 and V2 are superseded and scheduled for shutdown, so port any /v1/- or
Modality_btw-style example a user brings rather than extending it.
Both sides build on idc-index-data, so compare the API's idc_index_data_version against local
idc_index_data.__version__ before mixing them: the major is the IDC data release (24.x.y
serves v24); minor/patch index builds may correct metadata. If the API is a whole
release ahead, idc-index cannot download the extra series — mixed selections can omit
unrecognized UIDs, while wholly unmatched selections raise — so either upgrade it (run scripts/check_version.py for the right command)
or transfer directly from the bucket with s5cmd --no-sign-request.
See references/rest_api_guide.md for the endpoint reference, filter grounding, limits, and the
manifest-based download flow.
Cloud storage organization
All DICOM files live in public buckets mirrored between AWS S3 and GCS, organized by CRDC UUIDs
(not DICOM UIDs) to support versioning, as <crdc_series_uuid>/<crdc_instance_uuid>.dcm. Access
is free (no egress fees) via AWS CLI, gsutil, or s5cmd with anonymous access; use the
series_aws_url column for S3 URLs. Bucket names do not establish a license; query license_short_name for each selected series. See references/cloud_storage_guide.md for the full
bucket list and UUID mapping.
DICOMweb access
IDC data is available via DICOMweb (Google Cloud Healthcare API) for PACS integration and
DICOMweb-compatible tools: a public proxy (no auth, daily quota) for testing and moderate
queries, or Google Healthcare (GCP auth) for production volumes. See
references/dicomweb_guide.md.
Direct Parquet access
The idc-index metadata tables are also published as Parquet on a public GCS bucket
(idc-index-data-artifacts), queryable with DuckDB or pandas. This needs DuckDB installed
For ad-hoc metadata prefer REST /sql; choose Parquet for pinned versions or large results.
A separate public S3 export also includes clinical tables and full BigQuery metadata. See
references/parquet_access_guide.md.
Core Capabilities
The patterns below are the ones that go wrong when recalled from memory rather than checked. Worked examples for each area live in the reference guides named inline.
1. Discovery — enumerate values before filtering on them
Filtering on a guessed Modality or BodyPartExamined string is the most common cause of an
empty result set. Enumerate first:
modalities = client.sql_query("""
SELECT DISTINCT Modality, COUNT(*) as series_count
FROM index
GROUP BY Modality
ORDER BY series_count DESC
""")
print(modalities)The same pattern works for any filter column, optionally narrowed by another —
BodyPartExamined within a Modality, Manufacturer, collection_id. On the REST path this
grounding is a single call — GET /attributes/{attr}/values returns values with counts — and the
cohort endpoints report a miscased value in warnings rather than as an empty result.
Two indices carry curated collection-level metadata the primary index does not, both
requiring client.fetch_index(...) first: collections_index (cancer types, tumor locations,
species, subject counts) and analysis_results_index (derived datasets — AI segmentations,
expert annotations, radiomics — with their source collections and modalities).
Cancer type lives in collections_index.cancer_types, not in index — filtering by
cancer type requires a join:
client.fetch_index("collections_index")
results = client.sql_query("""
SELECT i.collection_id, i.PatientID, i.SeriesInstanceUID, i.Modality
FROM index i
JOIN collections_index c ON i.collection_id = c.collection_id
WHERE c.cancer_types LIKE '%Breast%'
AND i.Modality = 'MR'
LIMIT 20
""")client.sql_query() returns a pandas DataFrame. Confirm column names with
client.get_index_schema('index') or client.indices_overview before writing a query rather
than assuming them.
See references/sql_patterns.md for filter-value discovery, annotation and segmentation
queries, size estimation, clinical linking, and version tracking ("what's new in vX" — use
series_init_idc_version / series_revised_idc_version in index; historical objects use
prior_versions_index).
2. Downloading DICOM files
The two download methods take their first two arguments in opposite order. This is the most common source of broken IDC code — check it rather than recalling it:
| Method | First arg | Second arg | Use when |
|---|---|---|---|
download_from_selection | downloadDir (required) | filter kwargs (optional) | Filtering by collection, patient, study, or series |
download_dicom_series | seriesInstanceUID (required) | downloadDir (required) | Downloading specific series by UID only |
download_from_selection takes filter keyword arguments, NOT a DataFrame. The name
"from_selection" refers to filtering the IDC index by criteria — not to accepting a pandas
DataFrame. To download query results, extract the UIDs into a list first:
# Step 1: Query for series UIDs
series_df = client.sql_query("""
SELECT SeriesInstanceUID
FROM index
WHERE Modality = 'CT'
AND BodyPartExamined = 'CHEST'
AND collection_id = 'nlst'
LIMIT 5
""")
# Step 2: Extract UIDs as a list from the DataFrame
uids = list(series_df['SeriesInstanceUID'].values)
# Step 3: Pass the list to download_from_selection (NOT the DataFrame itself)
client.download_from_selection(
downloadDir="./data/lung_ct",
seriesInstanceUID=uids # list of strings, not a DataFrame
)
# Alternative: download_dicom_series has seriesInstanceUID as FIRST arg (different order!)
client.download_dicom_series(
seriesInstanceUID=uids, # FIRST arg here
downloadDir="./data/lung_ct"
)
# Whole collection: downloadDir is still the FIRST positional argument
client.download_from_selection(downloadDir="./data/rider", collection_id="rider_pilot")Both default to AWS; use source_bucket_location="gcs" for Google. In 0.12.5 the most-specific
selector wins, so use SQL first for intersecting criteria and verify every requested UID exists.
Downloaded files are named <crdc_instance_uuid>.dcm, not by SOPInstanceUID. The DICOM
UIDs are preserved inside the file metadata, not in the filename. Read DICOM headers for the
series UID; crdc_instance_uuid is not a column of the series-level index.
idc download <collection|series-uid|manifest> --download-dir ./data does the same from a
shell. See references/cli_guide.md for the dirTemplate hierarchy options (Python default:
%collection_id/%PatientID/%StudyInstanceUID/%Modality_%SeriesInstanceUID; dirTemplate=""
flattens), manifest downloads with resume, and dry-run size estimation.
3. Visualizing IDC images
viewer_url = client.get_viewer_URL(seriesInstanceUID=uid) # one series
viewer_url = client.get_viewer_URL(studyInstanceUID=study_uid) # all series in a studyReturns a browser URL — nothing is downloaded. The method selects OHIF v3 for radiology or SLIM for slide microscopy automatically. Viewing by study is useful when a single DICOM Study holds several Series (T1, T2, and DWI from one MRI session).
4. Licenses and citations — obligations, not optional steps
IDC data carries license terms and attribution requirements that follow it into any downstream publication or product, and neither is inferable from the pixel data. Check the license before use, and generate citations for whatever you download.
# License breakdown for a selection
licenses = client.sql_query("""
SELECT DISTINCT collection_id, license_short_name,
COUNT(DISTINCT SeriesInstanceUID) as series_count
FROM index GROUP BY collection_id, license_short_name
""")
# Citations for the same selection you downloaded (APA by default)
for citation in client.citations_from_selection(collection_id="rider_pilot"):
print(citation)In the reviewed v24 snapshot, about 97% of IDC data by size is CC BY (commercial use allowed with attribution) and about 3% is CC BY-NC (non-commercial only). Licenses attach to series, not collections — 39 of 176 collections carry more than one — so check the selection you actually intend to use, and note that each component retains its license obligations.
Both tasks are available from all three access paths, so stay on whichever one the session is
already using: idc-index as above, POST /v3/licenses and POST /v3/citations over REST,
or the get_licenses and get_citations MCP tools. See
references/licensing_and_citation.md for the full license inventory, all three routes, the
citation formats (APA, BibTeX, CSL JSON, RDF Turtle), and what to include when publishing.
5. Reaching past the index
Pick the access path with the routing gate in Overview; Data Access Options above is the full routing table.
Before reaching for BigQuery (which needs a Google Cloud project and access), check whether a
specialized index table already has the column you want: search client.indices_overview,
then client.fetch_index(...) and query locally for free. Full instance metadata, per-segment
rows, and SR measurement tables require BigQuery or its public Parquet exports; these are
outside the compact idc-index tables.
Best Practices
Check schema before writing queries — Use
client.get_index_schema('index')(reads cached metadata, no SQL executed) orclient.indices_overviewto see all available columns and their descriptions. The version-tracking columnsseries_init_idc_versionandseries_revised_idc_versionin the mainindextable directly answer "what's new / when was this added" questions without touchingprior_versions_index.Use the index for IDC data content questions - Query the IDC index directly, via
client.sql_query()locally orPOST /v3/sqlover HTTP. Web sources (release notes, blog posts, documentation pages) are frequently out of date and will produce incorrect answers. The index is the authoritative source; use it even when web search is available.Verify the IDC data version at the start of a session -
client.get_idc_version(),GET /v3/version, or the MCPget_idc_versiontool, depending on the path in use (currently v24). For a stale local index, runscripts/check_version.pyand use the upgrade command it printsCheck licenses and generate citations - Query
license_short_nameand respect CC BY vs CC BY-NC terms; usecitations_from_selection()to produce citations fromsource_DOIfor publicationsExplore small, then commit - Use
LIMIT(or a lowmax_rows) while exploring, and check collection size before downloading — some collections are terabytes. Seereferences/cli_guide.mdKeep downloads reproducible - Organize with
dirTemplate(e.g.%collection_id/%PatientID/%Modality) and save the Series UIDs or manifest behind any dataset you build
Troubleshooting
Issue: ModuleNotFoundError: No module named 'idc_index'
Cause: idc-index package not installed
Solution: If the task is read-only metadata, do not install it — use the REST API instead (Data Access Options). Otherwise run
scripts/check_version.pyand use the install command it prints, which targets the running interpreter and pins the vetted version. For data analysis also add pandas, numpy, and pydicom (tested with pandas>=1.5, numpy>=1.23, pydicom>=2.3)
Issue: Download fails with connection timeout
Cause: Network instability or large download size
Solution: Download in smaller batches (10-20 series); see
references/cli_guide.mdfor--use-s5cmd-syncresume and retry guidance
Issue: BigQuery quota exceeded or billing errors
Cause: Project quotas, sandbox limits, or billing configuration prevent the query
Solution: Use idc-index mini-index for simple queries (no billing required), or see
references/bigquery_guide.mdfor cost optimization tips
Issue: Series UID not found or no data returned
Cause: Typo in UID, data not in the current IDC version, or wrong field name
Solution: Test with
LIMIT 5first, check field names againstclient.indices_overview, and confirm the series is in the current version (some old data is deprecated)
Issue: Column not found in index table (e.g., SliceThickness, PixelSpacing, KVP, EchoTime, InjectedDose)
Cause: The
indextable contains series-level metadata only; modality-specific acquisition and reconstruction parameters live in dedicated tables (ct_index,mr_index,pt_index)Solution: Search
client.indices_overviewfor the column to find its table — the loop is under Finding which table contains a column inreferences/index_tables_guide.md— then fetch and join onSeriesInstanceUID:client.fetch_index("ct_index") result = client.sql_query(""" SELECT i.SeriesInstanceUID, i.Modality, c.SliceThickness, c.KVP, c.PixelSpacing_row_mm FROM index i JOIN ct_index c USING (SeriesInstanceUID) WHERE i.collection_id = 'your_collection' """)
Issue: Downloaded DICOM files won't open
Cause: Corrupted download, or an object type the viewer does not handle — SEG, RTSTRUCT, SR, and slide microscopy all need specialized tools
Solution: Inspect
Modality,SOPClassUID, and transfer syntax with normalpydicom.dcmread; forced parsing is not validation. Check download integrity and decoder/viewer support before re-downloading; reserveforce=Truefor diagnosed non-Part-10 inputs.
Resources
Reference guides and their decision triggers are listed in Quick Navigation above.
IDC Portal: https://portal.imaging.datacommons.cancer.gov/explore/
Documentation: https://learn.canceridc.dev/ — Tutorials: https://github.com/ImagingDataCommons/IDC-Tutorials
User Forum: https://discourse.canceridc.dev/ — idc-index: https://github.com/ImagingDataCommons/idc-index
indices_reference — external index-table docs (may be ahead of the installed version)
Citation: Fedorov, A., et al. "National Cancer Institute Imaging Data Commons: Toward Transparency, Reproducibility, and Scalability in Imaging Artificial Intelligence." RadioGraphics 43.12 (2023). https://doi.org/10.1148/rg.230180
Skill updates: releases page; watch the repository (Watch → Custom → Releases)
Files
- ATTRIBUTION.mdAdded by AutoGineer1019 B
- LICENSELicence file added by AutoGineer1.0 KiB
- SKILL.md30.7 KiB
- references/bigquery_guide.md35.4 KiB
- references/cli_guide.md9.3 KiB
- references/clinical_data_guide.md12.1 KiB
- references/cloud_storage_guide.md14.2 KiB
- references/dicomweb_guide.md16.1 KiB
- references/digital_pathology_guide.md15.3 KiB
- references/index_tables_guide.md12.1 KiB
- references/licensing_and_citation.md10.0 KiB
- references/mcp_guide.md9.4 KiB
- references/parquet_access_guide.md9.8 KiB
- references/rest_api_guide.md33.3 KiB
- references/sql_patterns.md16.9 KiB
- references/use_cases.md8.5 KiB
- scripts/check_version.pyScript5.5 KiB
references/dicomweb_guide.md
DICOMweb Guide for IDC
Reviewed 2026-09-30 against IDC endpoint/policy documentation and Google Healthcare conformance. Public QIDO and metadata reads were probed; authenticated Google-store access and pixel/frame retrieval were not executed.
When to Use DICOMweb
Use DICOMweb when you need:
Integration with PACS systems or DICOMweb-compatible tools
Streaming metadata without downloading full files
Building custom viewers or web applications
Using existing DICOMweb client libraries (OHIF, dicomweb-client, etc.)
For most use cases, idc-index is simpler and recommended. Use DICOMweb when you specifically need the DICOMweb protocol.
Endpoints
Public Proxy (No Authentication)
https://proxy.imaging.datacommons.cancer.gov/current/viewer-only-no-downloads-see-tinyurl-dot-com-slash-3j3d9jyp/dicomWeb100% data coverage - Contains all IDC data from all storage buckets
Points to the latest IDC version automatically
Updates immediately on new IDC releases
Per-IP and global daily egress quotas; use when bucket downloads cannot meet the task
No authentication required
Read-only access
Note: "viewer-only-no-downloads" in URL is legacy naming with no functional meaning
Google Healthcare API (Requires Authentication)
https://healthcare.googleapis.com/v1/projects/nci-idc-data/locations/us-central1/datasets/idc/dicomStores/idc-store-v{VERSION}/dicomWebThe pattern is historical, not proof that a store exists for the latest IDC release.
IDC currently documents idc-store-v23, while Google
documents idc-store and an access-request form.
Confirm the provisioned store URL and access with those pages/the IDC health monitor; do
not synthesize idc-store-v24 solely from this client output:
from idc_index import IDCClient
client = IDCClient()
print(client.get_idc_version()) # e.g., "v24" for current versionReplicates
idc-open-data; excludes the other two buckets, so check your selected seriesIDC targets synchronization within 1-2 weeks of a release; this is not guaranteed
Requires authentication and provides higher quotas
Better performance (no proxy routing)
Each release gets a new versioned store
See Content Coverage Differences and Authentication sections below.
Content Coverage Differences
Important: The two DICOMweb endpoints have different data coverage. The IDC public proxy contains MORE data than the authenticated Google Healthcare endpoint.
Coverage Summary
| Endpoint | Coverage | Missing Data |
|---|---|---|
| IDC Public Proxy | 100% | None |
| Google Healthcare API | Only idc-open-data | Two other buckets; possibly newer releases |
What's Missing from Google Healthcare?
The Google Healthcare DICOM store only replicates data from the idc-open-data S3 bucket. It does not include data from two additional buckets:
idc-open-data-cridc-open-data-two
The often-quoted 95.89% coverage is an IDC v21 series-count snapshot. Recalculate the share for the selected release; it is not a current guarantee or a fraction by file size.
See cloud_storage_guide.md for details on bucket organization, file structure, and direct access methods.
Update Timing
IDC Public Proxy: Updates immediately when new IDC versions are released
Google Healthcare: Independently maintained; synchronization within 1-2 weeks is a goal.
Verify the actual store release and query representative selected UIDs before a large job.
Warning from IDC documentation: "Google-hosted DICOM store may not contain the latest version of IDC data!" - Check during the weeks following a new release.
Choosing the Right Endpoint
Use IDC Public Proxy when:
You need complete data coverage (100%)
You need the absolute latest data immediately after a new version release
You don't want to set up GCP authentication
Your usage fits within per-IP quotas (can request increases via [email protected])
You're accessing slide microscopy images frame-by-frame
Use Google Healthcare API when:
Your selected series exist in the particular Google store
You need higher quotas for heavy usage
You want better performance (direct access, no proxy routing)
Checking Your Data Availability
Before choosing an endpoint, verify whether your data might be in the missing buckets:
from idc_index import IDCClient
client = IDCClient()
# Check which buckets contain your collection's data
results = client.sql_query("""
SELECT aws_bucket, COUNT(*) as series_count
FROM index
WHERE collection_id = 'your_collection_id'
GROUP BY aws_bucket
""")
print(results)
# Look for bucket values 'idc-open-data-cr' or 'idc-open-data-two'
# If present, that data won't be available in Google Healthcare endpointImplementation Details
IDC DICOMweb is provided through Google Cloud Healthcare API DICOM stores. The implementation follows DICOM PS3.18 Web Services with specific characteristics documented in the Google Healthcare DICOM conformance statement.
Supported Operations
| Service | Description | Supported |
|---|---|---|
| QIDO-RS | Search for DICOM objects | Yes |
| WADO-RS | Retrieve DICOM objects and metadata | Yes |
| STOW-RS | Store DICOM objects | No (IDC is read-only) |
Not supported: URI Service, Worklist Service, Non-Patient Instance Service, Capabilities Transactions
Searchable DICOM Tags (QIDO-RS)
The implementation supports a limited set of searchable tags:
| Level | Searchable Tags |
|---|---|
| Study | StudyInstanceUID, PatientName, PatientID, AccessionNumber, ReferringPhysicianName, StudyDate |
| Series | All study tags + SeriesInstanceUID, Modality |
| Instance | All series tags + SOPInstanceUID |
Important: Only exact matching is supported, except for:
StudyDate: supports range queries
PatientName: supports fuzzy matching
Query Limitations
Maximum results: 5,000 for studies/series searches; 50,000 for instances
Maximum offset: 1,000,000
Sequence tags (VR SQ) larger than approximately 1 MiB are omitted without a BulkDataURI; other bulk data can have a BulkDataURI. Retrieve the full instance for omitted sequences.
QIDO defaults to 100 studies/series or 1,000 instances. Use
limitandoffsetfor pages, including a final empty-page check; there is no reliable warning header marking exhaustion. WADO series metadata does not use these QIDO pagination parameters.
Code Examples
All examples use the public proxy endpoint. For authenticated access to Google Healthcare, see the authentication section.
Finding UIDs with idc-index
Use idc-index to discover data, then use DICOMweb for metadata access:
from idc_index import IDCClient
client = IDCClient()
# Find studies of interest
results = client.sql_query("""
SELECT StudyInstanceUID, SeriesInstanceUID, PatientID, Modality
FROM index
WHERE collection_id = 'tcga_luad' AND Modality = 'CT'
LIMIT 5
""")
# Use these UIDs with DICOMweb
study_uid = results.iloc[0]['StudyInstanceUID']
series_uid = results.iloc[0]['SeriesInstanceUID']
print(f"Study: {study_uid}")
print(f"Series: {series_uid}")QIDO-RS: Search by UID
import requests
base_url = "https://proxy.imaging.datacommons.cancer.gov/current/viewer-only-no-downloads-see-tinyurl-dot-com-slash-3j3d9jyp/dicomWeb"
# Search for a specific study
study_uid = "1.3.6.1.4.1.14519.5.2.1.6450.9002.307623500513044641407722230440"
response = requests.get(
f"{base_url}/studies",
params={"StudyInstanceUID": study_uid},
headers={"Accept": "application/dicom+json"},
timeout=60,
)
response.raise_for_status()
if response.status_code == 200:
studies = response.json()
print(f"Found {len(studies)} study")QIDO-RS: List Series in a Study
import requests
base_url = "https://proxy.imaging.datacommons.cancer.gov/current/viewer-only-no-downloads-see-tinyurl-dot-com-slash-3j3d9jyp/dicomWeb"
study_uid = "1.3.6.1.4.1.14519.5.2.1.6450.9002.307623500513044641407722230440"
response = requests.get(
f"{base_url}/studies/{study_uid}/series",
headers={"Accept": "application/dicom+json"},
timeout=60,
)
response.raise_for_status()
if response.status_code == 200:
series_list = response.json()
for series in series_list:
# DICOM tags are returned as hex codes
series_uid = series.get("0020000E", {}).get("Value", [None])[0]
modality = series.get("00080060", {}).get("Value", [None])[0]
description = series.get("0008103E", {}).get("Value", [""])[0]
print(f"{modality}: {description}")QIDO-RS: List Instances in a Series
import requests
base_url = "https://proxy.imaging.datacommons.cancer.gov/current/viewer-only-no-downloads-see-tinyurl-dot-com-slash-3j3d9jyp/dicomWeb"
study_uid = "1.3.6.1.4.1.14519.5.2.1.6450.9002.307623500513044641407722230440"
series_uid = "1.3.6.1.4.1.14519.5.2.1.6450.9002.217441095430480124587725641302"
response = requests.get(
f"{base_url}/studies/{study_uid}/series/{series_uid}/instances",
params={"limit": 10},
headers={"Accept": "application/dicom+json"},
timeout=60,
)
response.raise_for_status()
if response.status_code == 200:
instances = response.json()
print(f"Found {len(instances)} instances")
for inst in instances[:3]:
sop_uid = inst.get("00080018", {}).get("Value", [None])[0]
print(f" SOPInstanceUID: {sop_uid}")WADO-RS: Retrieve Series Metadata
import requests
base_url = "https://proxy.imaging.datacommons.cancer.gov/current/viewer-only-no-downloads-see-tinyurl-dot-com-slash-3j3d9jyp/dicomWeb"
study_uid = "1.3.6.1.4.1.14519.5.2.1.6450.9002.307623500513044641407722230440"
series_uid = "1.3.6.1.4.1.14519.5.2.1.6450.9002.217441095430480124587725641302"
response = requests.get(
f"{base_url}/studies/{study_uid}/series/{series_uid}/metadata",
headers={"Accept": "application/dicom+json"},
timeout=60,
)
response.raise_for_status()
if response.status_code == 200:
instances = response.json()
print(f"Retrieved metadata for {len(instances)} instances")
# Extract image dimensions from first instance
if instances:
inst = instances[0]
rows = inst.get("00280010", {}).get("Value", [None])[0]
cols = inst.get("00280011", {}).get("Value", [None])[0]
print(f"Image dimensions: {rows} x {cols}")Combined Workflow: idc-index Discovery + DICOMweb Metadata
from idc_index import IDCClient
import requests
# Use idc-index for efficient discovery
idc = IDCClient()
results = idc.sql_query("""
SELECT StudyInstanceUID, SeriesInstanceUID, Modality, SeriesDescription
FROM index
WHERE collection_id = 'nlst' AND Modality = 'CT'
LIMIT 1
""")
study_uid = results.iloc[0]['StudyInstanceUID']
series_uid = results.iloc[0]['SeriesInstanceUID']
print(f"Found: {results.iloc[0]['SeriesDescription']}")
# Use DICOMweb to stream metadata without downloading files
base_url = "https://proxy.imaging.datacommons.cancer.gov/current/viewer-only-no-downloads-see-tinyurl-dot-com-slash-3j3d9jyp/dicomWeb"
response = requests.get(
f"{base_url}/studies/{study_uid}/series/{series_uid}/metadata",
headers={"Accept": "application/dicom+json"},
timeout=60,
)
response.raise_for_status()
if response.status_code == 200:
metadata = response.json()
print(f"Retrieved metadata for {len(metadata)} instances without downloading files")Common DICOM Tags Reference
DICOMweb returns tags as hexadecimal codes. Common tags:
| Tag | Name | Description |
|---|---|---|
| 00080018 | SOPInstanceUID | Unique instance identifier |
| 00080020 | StudyDate | Date study was performed |
| 00080060 | Modality | Imaging modality (CT, MR, PT, etc.) |
| 0008103E | SeriesDescription | Description of series |
| 00100020 | PatientID | Patient identifier |
| 0020000D | StudyInstanceUID | Unique study identifier |
| 0020000E | SeriesInstanceUID | Unique series identifier |
| 00280010 | Rows | Image height in pixels |
| 00280011 | Columns | Image width in pixels |
Authentication for Google Healthcare API
To use the Google Healthcare endpoint with higher quotas:
import os
from google.auth import default
from google.auth.transport.requests import AuthorizedSession
# Get ADC; AuthorizedSession refreshes expiring tokens automatically.
credentials, project = default(scopes=["https://www.googleapis.com/auth/cloud-platform"])
session = AuthorizedSession(credentials)
# Set IDC_DICOMWEB_URL to the verified provisioned Google store URL (ending /dicomWeb).
base_url = os.environ["IDC_DICOMWEB_URL"].rstrip("/")
response = session.get(
f"{base_url}/studies",
params={"limit": 5},
headers={
"Accept": "application/dicom+json"
},
timeout=60,
)
response.raise_for_status()Prerequisites:
Google Cloud SDK installed (
gcloud)Authenticated:
gcloud auth application-default logingoogle-authandrequestsinstalled; account authorized for the selected Google storeIDC_DICOMWEB_URLset to the verified endpoint. Google documents an access-request form; follow it if ADC alone is insufficient. No authenticated access was verified in this refresh.
Troubleshooting
Issue: 400 Bad Request on search queries
Cause: Using unsupported search parameters. The implementation only supports specific DICOM tags for filtering.
Solution: Use UID-based queries (StudyInstanceUID, SeriesInstanceUID). For filtering by Modality or other attributes, use
idc-indexto discover UIDs first, then query DICOMweb with specific UIDs.
Issue: 403 Forbidden on Google Healthcare endpoint
Cause: Missing authentication or insufficient permissions
Solution: Run
gcloud auth application-default loginand ensure your account has access
Issue: 429 Too Many Requests
Cause: Rate limit exceeded
Solution: Honor
Retry-After, back off, and use public buckets for complete files. A daily proxy egress cap is not fixed by repeated retries; do not rotate IPs to bypass it.
Issue: 204 No Content for valid UIDs
Cause: UID may be from an older IDC version not in current data, or data is in buckets not replicated by Google Healthcare
Solution:
Verify UID exists using
idc-indexquery firstCheck if data is in
idc-open-data-croridc-open-data-twobuckets (not available in Google Healthcare endpoint)Switch to IDC public proxy for 100% coverage
Verify store release/access; synchronization timing is not guaranteed
Issue: Large metadata responses slow to parse
Cause: Series with many instances returns large JSON
Solution: Use
limit/offseton QIDO instance searches, or retrieve metadata for a specific instance by appending/instances/{SOPInstanceUID}/metadata; do not assumelimitpaginates WADO series metadata
Issue: Response missing expected attributes
Cause: DICOM sequences larger than ~1 MB are excluded from metadata responses
Solution: Retrieve the full DICOM instance using WADO-RS instance retrieval if you need all attributes
Resources
IDC Documentation:
IDC DICOM Stores - Data coverage and bucket details
IDC DICOMweb Access - Endpoint usage and differences
IDC Proxy Policy - Quota policies and usage restrictions
IDC User Guide - Complete documentation
DICOMweb Standards and Tools:
Related Guides:
cloud_storage_guide.md- Direct bucket access, file organization, CRDC UUIDs, and versioningbigquery_guide.md- Advanced metadata queries with full DICOM attributes
Requirements and compatibility
Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta
“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.
Needs: Needs an MCP server, Needs Python
The author says: Requires network access for hosted APIs, index fetching, citations, and downloads. Local Python workflows target idc-index 0.12.5; BigQuery and Google Healthcare require Google credentials.
Security
What our scanner noticed· Low risk
- Instructions that use the network
- Scripts that your agent may run
This skill includes scripts that your agent may run. Read them before you use it.
A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.
Attribution and licence
- Created by
- Andrey Fedorov, @fedorov
- Publisher
- K-Dense (Community)
- Distributed by
- K-Dense
- Source
- K-Dense-AI/scientific-agent-skills · skills/imaging-data-commons · commit a25cf9e
- Licence
- MIT License (redistribution allowed)
- LICENSE (added by AutoGineer from LICENSE.md)
- ATTRIBUTION.md (written by AutoGineer)
- Synced
AutoGineer is not affiliated with or endorsed by Andrey Fedorov, @fedorov or K-Dense.
Download ZIP
The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download imaging-data-commons.zip