What is DICOMweb? QIDO-RS, WADO-RS, and STOW-RS explained

DICOMweb is DICOM’s web-native transport layer — a family of RESTful services defined in DICOM Part 18 that makes medical imaging data accessible over standard HTTP. DICOMweb does not replace the DICOM image format or the metadata model. It replaces the proprietary DIMSE network protocol that DICOM systems used to communicate before cloud infrastructure, browser-based viewers, and AI pipelines made that protocol’s architectural assumptions unworkable.

The three core DICOMweb services cover the full imaging data cycle. QIDO-RS queries for studies, series, and instances by returning JSON metadata without transferring pixel data. WADO-RS retrieves pixel data and metadata at the study, series, or instance level and streams them directly to the requesting client over HTTPS. STOW-RS stores DICOM instances to a remote system via HTTP POST, with no Application Entity pre-registration required on either side. A fourth service, UPS-RS, extends DICOMweb into workflow management, serving as the REST equivalent of the DICOM Modality Worklist. DICOMweb was formally published in 2011 as DICOM Supplement 161 and incorporated into DICOM Part 18.

DICOMweb sits as the fourth layer of the imaging standards stack. DICOM defines the image format. HL7 V2 handles ordering and results messaging. HL7 FHIR provides cross-system API interoperability. DICOMweb is the transport that moves DICOM-format data between those systems over the web. Medicai’s cloud PACS and zero-footprint viewer are built on DICOMweb — QIDO-RS for worklist population, WADO-RS for progressive image streaming, STOW-RS for AI result ingestion and study import.

What DICOMweb is — and where it sits in the standards stack

DICOMweb is a family of RESTful services defined in DICOM Part 18. It is not a separate standard from DICOM — it is DICOM’s web-native transport layer, published alongside the original DIMSE services rather than superseding them in the specification. What it changes is not the data format or the meaning of the information, but how that data moves between systems.

The imaging standards stack that most modern radiology environments run on has four layers.

DICOM defines the image format and the metadata structure—the .dcm file and the tags within it. HL7 V2 handles the ordering and results messaging that connects RIS, EHR, and PACS — ORM, ORU, and ADT.

HL7 FHIR provides the API interoperability layer for cross-system data exchange and patient-facing applications.

DICOMweb is the transport that makes DICOM-format imaging data accessible via standard HTTP — the layer that replaces proprietary DIMSE connections with web services any HTTP client can use.

DICOM was designed in the late 1980s, when the dominant networking model was persistent peer-to-peer connections among known, pre-configured systems within a closed hospital network. That model served its purpose for three decades. It does not map onto cloud infrastructure, browser-based viewers, mobile access, or AI pipelines. DICOMweb was defined to solve that mismatch: same data, same format, same metadata semantics — accessible via the web services model everything else in modern IT runs on.

DICOMweb was formally defined in 2011 as DICOM Supplement 161 and incorporated into DICOM Part 18. The three core services — QIDO-RS (query), WADO-RS (retrieve), and STOW-RS (store) — together cover the full read/write cycle for imaging data over HTTP. A fourth service, UPS-RS (Unified Procedure Step over REST), extends DICOMweb into workflow management, covering the same pre-acquisition scheduling that DICOM Modality Worklist handles over DIMSE.

DIMSE: what DICOMweb replaces, and why the distinction matters

Understanding DICOMweb requires understanding what it replaces. DIMSE — DICOM Message Service Element — is the original DICOM service model. It defines how DICOM systems communicate over persistent TCP/IP connections using a DICOM-specific request-response protocol. Every DIMSE operation assumes both endpoints are pre-configured DICOM Application Entities (AEs) that know each other by name.

The DIMSE services that appear throughout the radiology workflow map directly to DICOMweb equivalents:

DIMSE service	DICOMweb equivalent	Function	Key difference
C-FIND	QIDO-RS	Query for matching studies/series/instances	DIMSE requires AE pre-registration; QIDO-RS requires only HTTP auth and a URL
C-MOVE	WADO-RS	Retrieve image data	C-MOVE pushes to a third AE the client designates; WADO-RS streams directly to the requester
C-GET	WADO-RS	Retrieve image data directly	C-GET requires the client to act as an SCP (server); WADO-RS requires only HTTP client capability
C-STORE	STOW-RS	Store DICOM instances to a remote system	C-STORE requires a pre-established association; STOW-RS is a stateless HTTP POST
C-ECHO	(HTTP OPTIONS / health check)	Connectivity verification	DIMSE-specific ping; DICOMweb uses standard HTTP mechanisms
N-CREATE / N-SET (MPPS)	UPS-RS	Procedure step management	UPS-RS extends DICOMweb into workflow management; covers Modality Worklist and MPPS over REST

Three DIMSE limitations that DICOMweb directly resolves are worth naming explicitly, as they explain why cloud PACS and web viewers were not architecturally possible under DIMSE.

AE Title pre-registration

Every DIMSE operation requires both the calling and called Application Entity to be statically configured in advance. A new system added to the network — a viewer workstation, a cloud node, an AI server — must be registered in every PACS and archive it needs to communicate with before it can send or receive a single message. DICOMweb replaces AE Title negotiation with standard HTTP authentication. Any system with valid credentials and a network path to the HTTPS endpoint can participate immediately.

The C-MOVE three-party problem

DIMSE study retrieval works by having the client send a C-MOVE request to the archive, instructing it to push the images to a third AE — the client’s own storage SCP. This requires the client to be running a DICOM storage server that listens on a network port. If the receiving AE is a browser or a cloud function, this is impossible. WADO-RS eliminates the third party entirely: the client requests the images, the server streams them directly to the requester over the same HTTP connection.

Firewall traversal

DIMSE uses non-standard TCP ports and persistent connection associations that require specific inbound firewall rules for every communicating pair. In a cloud or teleradiology context, this means VPN tunnels, port-forwarding rules, and network engineering effort for every new connection. DICOMweb uses port 443 HTTPS — the same port as every other web application, already open in virtually every network — and stateless requests that require no persistent connection.

The three DICOMweb services: QIDO-RS, WADO-RS, and STOW-RS

Each DICOMweb service covers one operation in the imaging data lifecycle. QIDO-RS finds data. WADO-RS retrieves it. STOW-RS stores it. Together, they cover everything DIMSE C-FIND, C-MOVE, C-GET, and C-STORE provide, with the addition of returning structured JSON metadata alongside or instead of raw DICOM binary.

QIDO-RS — Query based on ID for DICOM Objects

What it does: QIDO-RS is a search service. It accepts HTTP GET requests with query parameters and returns JSON metadata about matching DICOM studies, series, or instances. No pixel data moves in a QIDO-RS response — only metadata.

The URL structure reflects the DICOM information model hierarchy. A study-level query searches across all studies. A query at the series level searches within a specified study. A query at the instance level searches within a specified series. The three resource URLs follow this pattern:

{base}/studies?PatientID=MRN123&StudyDate=20250210&Modality=CT
{base}/studies/{studyUID}/series
{base}/studies/{studyUID}/series/{seriesUID}/instances

The response is a JSON array where each element is a DICOM dataset represented as JSON — attributes keyed by DICOM tag number, with values encoded according to the DICOM JSON Model. This is the same metadata that lives in DICOM file headers, delivered in a format any web developer can parse without a DICOM library.

Operational use case

Every worklist or study list in a DICOMweb-enabled viewer — the list of today’s unread studies, the prior study search panel, the patient timeline — is driven by QIDO-RS queries. When a radiologist opens a PACS web interface and sees their worklist load, a QIDO-RS call has retrieved the study metadata. When they search for a patient’s prior CTs, another QIDO-RS call filters by patient ID and modality. No images transfer until the radiologist actually opens a study.

What to verify in conformance statements

QIDO-RS conformance must specify which resource levels are supported (studies, series, instances), which DICOM attributes can be used as query parameters (the minimum required by the standard includes PatientID, StudyDate, Modality, and AccessionNumber), and which attributes are included in the response. Systems that return sparse metadata — for example, not including Accession Number or Study Description — create downstream display problems in viewers that depend on those fields for worklist population.

WADO-RS — Web Access to DICOM Objects by RESTful Services

What it does: WADO-RS is a retrieval service. It accepts HTTP GET requests and returns pixel data, metadata, or both. It is the service that actually moves images from the archive to the viewer.

WADO-RS exposes three retrieval resources: a study (all instances), a series (all instances within a series), or a single instance. A metadata sub-resource on each returns DICOM JSON metadata without pixel data — useful when the viewer needs header information but not yet the images:

{base}/studies/{studyUID}                          — all instances
{base}/studies/{studyUID}/series/{seriesUID}       — series
{base}/studies/{studyUID}/series/{seriesUID}/instances/{sopUID}  — one instance
{base}/studies/{studyUID}/metadata                 — JSON metadata only

The response format is controlled by the HTTP Accept header in the request. The server can return multipart DICOM (raw .dcm instances), JPEG, JPEG 2000, or JSON metadata depending on what the client requests and what the server supports. A browser-based viewer typically requests JPEG or JPEG 2000 because browsers can render these natively. A downstream system processing raw DICOM data requests multipart DICOM.

WADO-RS versus WADO-URI. WADO-URI is the older, non-RESTful predecessor to WADO-RS. It returned a single image via a URI query string (?requestType=WADO&studyUID=…&seriesUID=…&objectUID=…) and supported only JPEG output. WADO-URI is still encountered in legacy systems. WADO-RS is the current standard, supports all resource levels and multiple return formats, and is what DICOM conformance statements reference when they claim DICOMweb support. When evaluating a system, verify whether WADO-RS or only WADO-URI is implemented.

Transfer syntax and transcoding. The format in which pixel data is stored in the archive — the DICOM transfer syntax — may differ from the format the client can render. A CT stored as JPEG 2000 lossless needs to be transcoded to JPEG or rendered via a JavaScript DICOM decoder before a browser can display it. A DICOMweb server that supports on-the-fly transcoding handles this transparently. One that does not require the viewer to include a client-side DICOM decoder library (OHIF and similar open-source viewers do this). Transcoding support — and which transfer syntaxes are supported in each direction — must be documented in the conformance statement.

Operational use case: When a radiologist opens a study in a zero-footprint viewer, the viewer first sends a WADO-RS request for the series metadata (to populate the thumbnail panel and sequence the series), then progressively sends WADO-RS requests for instance pixel data as the radiologist scrolls. A CT with 500 axial slices does not load all 500 images before display — the viewer requests the current slice and buffers adjacent slices, driven by WADO-RS instance-level requests against the series.

STOW-RS — Store Over the Web by RESTful Services

What it does: STOW-RS is a store service. It accepts HTTP POST requests containing one or more DICOM instances and persists them to the server. It is the write half of the DICOMweb protocol — the equivalent of DIMSE C-STORE, without the AE pre-registration requirement.

A STOW-RS request sends DICOM instances as a multipart HTTP body to a studies endpoint:

POST {base}/studies

Content-Type: multipart/related; type=”application/dicom”

[multipart body: one or more DICOM instances]

The server response confirms which instances were stored successfully and which failed, and provides a reason for each rejected instance. A partial success — some instances stored, some rejected — is a valid STOW-RS response, which matters for error handling: the client must inspect the response and retry or alert on any rejected instances rather than assuming all-or-nothing success.

Operational use cases: STOW-RS covers three distinct write scenarios in the imaging workflow. First, direct modality upload: a DICOMweb-native modality or imaging gateway posts newly acquired instances directly to a cloud PACS STOW-RS endpoint without requiring DIMSE configuration. Second, AI result ingestion: an AI model that has processed a study posts its output — annotated images, secondary capture instances, structured report objects — back to the PACS archive via STOW-RS. Third, study import: an external imaging system, patient portal upload, or CD digitization workflow sends studies to the archive via HTTP POST, with no DICOM AE configuration on either side.

Authentication on STOW-RS uses the same OAuth 2.0 / OpenID Connect model as QIDO-RS and WADO-RS. The absence of AE Title negotiation means that authentication — who is authorized to write what — must be enforced at the HTTP layer through proper OAuth scopes and access control policies. A STOW-RS endpoint that accepts unauthenticated POST requests has no equivalent of DIMSE’s AE allow-list, which was itself a weak security control but provided some perimeter protection. DICOMweb’s use of standard web auth is strictly stronger, but it must be correctly implemented.

What DICOMweb enables that DIMSE cannot

The significance of DICOMweb is not the protocol mechanics — it is what those mechanics make possible at the architectural level. Four capabilities that either do not exist or require significant engineering workarounds under DIMSE are native to DICOMweb.

Zero-footprint clinical viewing

A DIMSE-based viewer requires local DICOM client software: a thick-client application installed on a workstation, configured with AE Title credentials, and connected to the PACS via VPN or a direct network link. The viewer is a DICOM Application Entity. The workstation is registered in the PACS. A radiologist at a remote location needs a VPN, an installed application, and IT-provisioned credentials for every archive they need to access.

A DICOMweb viewer is a web application. The browser calls QIDO-RS to populate the worklist, WADO-RS to retrieve images, and renders them using JavaScript. The radiologist needs only a browser and HTTPS credentials. The reading workstation is not a DICOM AE — it is an HTTPS client. This is the architectural foundation of teleradiology at scale, of reading from home, and of consultant access from outside the institution.

Zero-footprint viewing was possible in limited forms before DICOMweb — WADO-URI enabled single-image JPEG retrieval in browsers — but full diagnostic reading with series navigation, multi-planar reconstruction, and window/level adjustment over a pure browser interface requires WADO-RS. The generation of clinically capable web viewers (OHIF, Cornerstone, and derivatives) is built on DICOMweb, specifically on WADO-RS’s ability to stream pixel data at multiple resource levels with appropriate transfer syntax negotiation.

Cloud PACS architecture

A DIMSE-based PACS is a closed network node. Its storage and retrieval services are accessible only to DICOM Application Entities configured to communicate with it, which, in practice, means systems on the same network segment or connected via dedicated tunnels. Scaling a DIMSE-based PACS horizontally — adding compute nodes to handle higher load — requires each node to be a registered DICOM AE, which reintroduces the pre-registration problem for every client that might reach any node.

A DICOMweb PACS is a standard HTTPS service. It can be hosted in any cloud provider with no infrastructure assumptions beyond a stable URL and a TLS certificate. Any client with credentials can reach it from anywhere. Horizontal scaling is handled at the load balancer level, invisible to clients, because each DICOMweb request is stateless. There is no connection association to maintain across requests, no AE session to preserve. This is why the transition from on-premise PACS to cloud PACS is architecturally a transition from DIMSE to DICOMweb. The data format and the metadata model remain DICOM; the transport and the infrastructure model change entirely.

AI pipeline integration

An AI model that needs to access imaging data for training or inference under a DIMSE model must be configured as a DICOM AE — or must go through a DICOM gateway that translates between DIMSE and whatever interface the AI system actually uses. Every new AI application requires a registered AE, a network path to the PACS, and a DIMSE service configuration. In a large institution running multiple AI applications across multiple PACS nodes, this becomes a configuration management problem at scale.

A DICOMweb-enabled PACS exposes imaging data as HTTP resources. An AI pipeline queries for relevant studies using QIDO-RS, retrieves pixel data using WADO-RS, processes it, and posts the results back using STOW-RS. The AI system is an HTTP client. No DICOM AE configuration is required. The same credentials and endpoint URL that a viewer uses are used by the AI pipeline. New AI applications are added by provisioning credentials, not by configuring DICOM associations. This is why the growing market of PACS-integrated AI applications depends on DICOMweb adoption as a prerequisite.

FHIR linkage and cross-system access

The HL7 FHIR ImagingStudy resource carries DICOMweb endpoint URLs as part of its data model. Specifically, the series.endpoint and endpoint fields in an ImagingStudy resource reference WADO-RS URLs that resolve to the actual imaging data. When an EHR retrieves a FHIR ImagingStudy resource for a patient and wants to display the images, it follows those WADO-RS references. The FHIR administrative record and the DICOM imaging data are linked by DICOMweb URLs.

This integration is what closes the loop between the clinical record and the images in a FHIR-native architecture. A referring physician viewing a patient encounter in an EHR can open imaging directly from the FHIR ImagingStudy resource — not by launching a separate PACS viewer with separate credentials, but by following a WADO-RS URL from within the EHR’s own interface. That capability requires the PACS to expose a DICOMweb endpoint that the EHR can reach.

Evaluating DICOMweb support: what conformance actually means

The phrase “supports DICOMweb” in a vendor data sheet is not a conformance claim — it is a marketing statement. The gap between partial DICOMweb implementation and the full service coverage required for clinical workflows is significant. Four areas to evaluate in conformance statements and procurement conversations.

Service and resource level coverage

Each DICOMweb service (QIDO-RS, WADO-RS, STOW-RS) must be verified independently, and within each service, which resource levels are supported — study, series, and instance. A system that supports QIDO-RS at the study level but not the series or instance level cannot support the series-level navigation a viewer requires. A system that supports WADO-RS but only at the study level — returning all instances in a study as a bulk download — cannot support progressive instance-by-instance streaming.

DICOM Conformance Statements must document which services and resource levels are supported. Any system claiming DICOMweb conformance that cannot produce a Conformance Statement documenting this should be treated as unverified.

Media types and transfer syntax support

WADO-RS response format is negotiated via the HTTP Accept header. A fully conformant WADO-RS server can return multipart DICOM (raw instances), JPEG, JPEG 2000, and DICOM JSON metadata. A server that only returns JPEG forces the client to use lossy compression regardless of clinical requirements. A server that cannot return DICOM JSON metadata forces the client to parse raw DICOM binary headers for metadata.

For zero-footprint viewers, the critical question is whether the server supports on-the-fly transcoding — converting from the stored transfer syntax to the requested format. A server that stores JPEG 2000 lossless and can return JPEG on demand allows the browser to render images without a client-side DICOM decoder. One that cannot transcode shifts the decoding burden to JavaScript running in the browser, adding latency and requiring a larger client-side library.

Authentication and authorization model

DICOMweb services use standard web authentication — OAuth 2.0 for authorization, OpenID Connect for identity. This means DICOMweb access should integrate with the institution’s existing identity provider: Active Directory via SAML, Okta, Azure AD, or any OAuth 2.0-compatible IdP. Verify that the DICOMweb server supports OAuth 2.0 token validation and that scopes are defined granularly enough to distinguish read access (QIDO-RS and WADO-RS) from write access (STOW-RS).

Systems that implement DICOMweb endpoints with proprietary authentication schemes — API keys, custom header tokens, or basic auth only — are not interoperable with FHIR Smart App Launch or with standard EHR integration patterns. This matters if the deployment goal includes EHR-embedded viewing or cross-enterprise imaging access.

UPS-RS for workflow management

Unified Procedure Step over REST (UPS-RS) extends DICOMweb into workflow management. It covers the use cases that DICOM Modality Worklist and MPPS cover over DIMSE — pre-acquisition scheduling queries and acquisition completion signals — but via HTTP rather than DIMSE C-FIND and N-CREATE/N-SET. UPS-RS is the successor to the DICOM Modality Worklist in DICOMweb.

In a fully DICOMweb-native environment — cloud PACS, web-connected modalities, no DIMSE infrastructure — UPS-RS handles the scheduling side of the workflow that MWL handles in traditional environments. Most vendor implementations in 2025 support UPS-RS partially or not at all, which means hybrid environments running DIMSE MWL for scheduling and DICOMweb for storage and retrieval remain common. Verify specifically whether UPS-RS is in the conformance statement if the deployment includes DICOMweb-native modalities.

How DICOMweb connects to the rest of the imaging standards cluster

DICOMweb closes the web-native transport gap in the standards stack. The posts below each touch DICOMweb at specific points in the imaging workflow:

• DICOM Modality Worklist (MWL): MWL is the DIMSE-based pre-acquisition scheduling service — C-FIND at Step 4 of the IHE SWF sequence. UPS-RS is its DICOMweb equivalent. The MWL guide covers the DIMSE implementation; this post defines where DICOMweb fits in that same workflow position in cloud-native environments.
• DICOM web viewer: The DICOM web viewer post describes QIDO-RS, WADO-RS, and STOW-RS in the context of viewer products. This post is the underlying protocol reference — what those services actually do, how they work technically, and how to evaluate vendor conformance.
• HL7 FHIR vs. V2: FHIR’s ImagingStudy resource links to WADO-RS endpoints. DICOMweb is the protocol that enables FHIR imaging integration. The FHIR vs. V2 post covers the HL7 layer; this post covers the imaging transport layer that those FHIR references resolve to.
• VNA (Vendor Neutral Archive): VNA interoperability depends on DICOMweb. A VNA that exposes a DICOMweb interface can be queried and retrieved by any conformant viewer or system without integration engineering. DICOMweb is the interface that makes the “vendor neutral” claim operationally meaningful.
• PACS Interoperability: The IHE XDS-I.b profile — cross-enterprise imaging sharing — uses WADO-RS as the retrieval mechanism for imaging documents registered in the XDS document registry. DICOMweb is the transport layer underneath the IHE profile in cross-enterprise scenarios.
• HL7 entity post: The HL7 and DICOMweb posts together complete the standards stack description: HL7 V2 for ordering and results messaging, FHIR for API interoperability, DICOM for image format, DICOMweb for imaging data transport. Any post in the cluster that references “the modern imaging standards stack” now has a defined set of four anchor posts to link to.