Skip to content
Imaging Evidence Path

DICOMweb: the same imaging world through HTTP

Tonight · ~20 min · read · energy: low · setup: none

DIMSE works, but it is not web-friendly. DICOMweb is a REST/HTTP re-skin of the same services, designed for web/mobile/FHIR-native clients and — increasingly — AI services. This lesson maps the web verbs to the DIMSE verbs you just learned, so you recognise one transport when you see the other.

The anchor: same concepts, a parallel transport

DICOMweb is not a replacement for DIMSE; it is a parallel transport for the same objects and concepts. A hospital runs both: classic PACS/RIS integrations often use DIMSE, while web viewers, mobile apps, FHIR-native systems and AI orchestrators increasingly prefer DICOMweb. Knowing which transport an integration uses matters, because authentication, batching, and paging differ between them.

The web verbs, mapped to DIMSE

Service Maps to What it does
QIDO-RS (Query based on ID for DICOM Objects) C-FIND Query studies/series/instances via HTTP.
WADO-RS (Web Access to DICOM Objects) C-GET Retrieve objects/pixels/metadata via HTTP (JSON metadata or binary pixels).
STOW-RS (Store Over the Web) C-STORE Upload objects via HTTP.
UPS-RS (Unified Procedure Step RESTful) workitem/workflow The REST interface to the DICOM Unified Procedure Step model — the web form of the workitem/worklist workflow that AIW-I uses to dispatch and track inference tasks.

The names are baroque, but the mapping is one-to-one with lesson 2: QIDO = find, WADO = get, STOW = store. Once you know the DIMSE verb, you know the DICOMweb service.

A concrete feel: QIDO then WADO

A web viewer fetching a study does roughly:

# QIDO-RS: find series in a study (returns JSON)
GET /studies/{studyInstanceUID}/series


# WADO-RS: retrieve a series' pixels (binary, or metadata as JSON)
GET /studies/{studyInstanceUID}/series/{seriesInstanceUID}
Accept: multipart/related; type=application/octet-stream

Note what is missing relative to C-MOVE: there is no separate destination AE, no storage SCP to run. The client just issues an HTTP GET and receives the bytes. That simplicity is the whole point — and why AI services built on HTTP prefer DICOMweb. The IHE AIW-I profile uses UPS-RS (the workitem service) to dispatch and track inference tasks over exactly this kind of interface.

What changes when you switch transports

  • Authentication — DICOMweb usually rides on HTTP auth (OAuth/OIDC bearer tokens), whereas DIMSE association security varies (TLS, AE-title ACLs).
  • Paging and batching — QIDO returns result counts and ranges; large retrieves may be paginated or chunked differently than DIMSE.
  • Object renderability — the same object-types compatibility problem exists: a viewer that cannot render DICOM SEG will not magically render it just because it arrived over WADO-RS. The viewer-support failure of lesson 6 is transport-independent.
Stop and think — then reveal

A web viewer retrieves a tumour SEG over WADO-RS and displays the CT, but the SEG does not render. The transfer “succeeded” (HTTP 200, bytes received). Is this a transport problem or a viewer problem?

A viewer problem — transport-independent. WADO-RS delivered the SEG bytes fine; the reading workstation simply cannot render DICOM SEG objects (no decoder, or no overlay support). The same failure would occur if the SEG had arrived via C-STORE over DIMSE. This is exactly why “the object exists in the archive” does not imply “the radiologist sees it” — the subject of lesson 6. Switching transports fixes plumbing, not capability.

What to retain

  1. DICOMweb (QIDO/WADO/STOW/UPS) is an HTTP re-skin of the same services as DIMSE (C-FIND/C-GET/C-STORE/worklist) — a parallel transport, not a replacement.
  2. QIDO = find, WADO = get, STOW = store, UPS-RS = workitem/workflow (used by AIW-I).
  3. It removes DIMSE’s strangeness (no destination AE, no storage SCP) — one HTTP GET returns the bytes — which is why AI/web clients prefer it.
  4. Authentication and paging differ by transport; viewer capability problems (e.g. cannot render SEG) are transport-independent.

Next: with both transports mapped, how does an AI service actually enter this workflow?