DICOMweb Proxy: Connecting WADO-RS, QIDO-RS, STOW-RS, and Legacy PACS

DICOMweb is a family of RESTful web services for searching, retrieving, and storing DICOM imaging resources over HTTP or HTTPS. QIDO-RS searches studies, series, and instances using patient and study attributes. WADO-RS retrieves DICOM objects, metadata, frames, or rendered representations. STOW-RS stores new DICOM objects.

Many health systems run cloud viewers, AI applications, and electronic health record (EHR) workflows alongside Picture Archiving and Communication Systems (PACS), Vendor Neutral Archives (VNAs), and specialty archives. A DICOMweb proxy provides these applications with a consistent web endpoint for connecting to systems that support native DICOMweb services or DICOM Message Service Element (DIMSE) operations.

How DICOMweb Services Work

The DICOM Standard, Part 18 defines the Studies Service and its QIDO-RS, WADO-RS, and STOW-RS transactions. A client may use one or more of these services depending on whether it needs to search for existing studies, retrieve images or metadata, or store new DICOM objects.

These mappings describe common integration patterns, not interchangeable specifications. A proxy must account for the resources, media types, transfer syntaxes, query behavior, and status handling supported by each connected system. Review the vendor’s DICOM conformance statement and DICOMweb capabilities before implementation.

What Is a DICOMweb Proxy?

A DICOMweb proxy presents a DICOMweb endpoint to a web application and mediates access to one or more imaging systems. The proxy may route a request to a native DICOMweb server or translate it for a PACS that supports DIMSE services such as C-FIND, C-GET, C-MOVE, and C-STORE.

The proxy provides modern applications with a consistent HTTP interface, while the health system retains control of routing, source selection, authentication, authorization, logging, and error handling. It can support a phased modernization strategy, but it does not remove the need to test each archive, viewer, and workflow.

How a DIMSE-to-DICOMweb Workflow Works

A production workflow should define each transaction from the client request through the final response. A typical path follows these steps:

1. The client authenticates to the DICOMweb endpoint and sends a QIDO-RS, WADO-RS, or STOW-RS request.
2. The proxy validates the request, confirms the user’s permissions, and selects the intended archive or destination.
3. If the target system uses DIMSE, the proxy translates and routes the request using the configured DICOM operation.
4. The PACS or archive performs the search, retrieval, or store operation and returns a result to the proxy.
5. The proxy converts the response into the required DICOMweb media type and HTTP status response.
6. Monitoring records the transaction, timing, destination, result, and any exception that requires follow-up.

For retrieval, the design must specify whether the proxy uses C-GET, C-MOVE, or a vendor-specific method. C-MOVE introduces destination AE Title and network-routing requirements, while C-GET keeps the retrieval on the established association. Test the selected method against every source archive that the workflow can query.

A Cloud Viewer Example Scenario
A clinician launches a cloud viewer from an EHR. The viewer receives the patient or study context, authenticates, and uses QIDO-RS to locate the study. It then uses WADO-RS to retrieve DICOM instances, metadata, frames, or a rendered representation. If the source is a legacy PACS, the proxy performs the required DIMSE query and retrieval behind the DICOMweb endpoint.

This design keeps the browser-based viewer from connecting directly to the PACS. If the viewer creates a new DICOM object, such as a presentation state or structured report, the workflow can use STOW-RS when the destination supports and accepts that object. The implementation should preserve patient and study identifiers, enforce the user’s access rights, and return clear errors when content is unavailable.

Authentication and Authorization for DICOMweb

DICOMweb transports imaging data, but the standard alone does not make a deployment secure or compliant; it places responsibility for privacy and security on the organizations that implement and deploy the services. Build security controls around the endpoint, the proxy, and every connected system.

• Use HTTPS with current TLS configurations for data in transit, including traffic between the client, proxy, and downstream services where supported.
• Authenticate users and applications through the organization’s approved identity platform, API gateway, or reverse proxy. Common approaches include OAuth 2.0 access tokens and OpenID Connect for user identity.
• Authorize each request with least-privilege roles, scopes, or attributes. Separate permissions for search, retrieval, and storage when the workflow requires different access levels.
• Configure Cross-Origin Resource Sharing only for approved browser applications and origins. Do not use permissive browser settings as a substitute for authentication.
• Protect service credentials and tokens, rotate secrets, validate token audience and expiration, and avoid placing protected information in logs or URLs.
• Record access, routing decisions, failures, and administrative changes in an audit trail that supports operational review and the organization’s compliance program.
• Limit direct exposure of PACS and archives. Place the proxy in a controlled network path and apply rate limits, timeouts, and resource controls that protect downstream systems.

FHIR Integration with DICOMweb

FHIR and DICOMweb solve different but complementary problems. FHIR exchanges clinical and administrative context. DICOMweb searches, retrieves, and stores DICOM imaging resources. FHIR does not replace DICOMweb as the image transport layer.

The HL7 FHIR Imaging Study resource can describe an imaging study and reference an Endpoint that identifies a WADO-RS service. An EHR or clinical application can use FHIR to identify the study and access endpoint, then hand that context to a viewer that retrieves the DICOM content through DICOMweb. The integration should maintain consistent patient identity, Study Instance UID, authorization context, and endpoint selection across both standards.

Common DICOMweb Proxy Implementation Mistakes

• Labeling a proprietary REST wrapper as DICOMweb without confirming that it implements the required resources, transactions, media types, and status behavior.
• Assuming every DICOMweb service maps one-to-one to a DIMSE operation. Retrieval behavior, especially C-GET versus C-MOVE, requires explicit design and testing.
• Exposing the endpoint before defining authentication, authorization, TLS, audit, network segmentation, and browser-access policies.
• Ignoring browser requirements such as Cross-Origin Resource Sharing, token renewal, session expiration, and the handling of failed or partial requests.
• Testing only a small study. Include large and multiframe studies, compressed transfer syntaxes, structured reports, presentation states, encapsulated documents, and other objects used in production.
• Assuming the proxy will automatically correct discrepancies in patient identity or metadata. Define patient matching, tag normalization, routing, and exception rules as separate workflow requirements.
• Using rendered images when the receiving workflow requires original DICOM objects, diagnostic fidelity, full metadata, or downstream processing.
• Skipping tests for retries, timeouts, duplicate stores, unsupported objects, partial failures, monitoring, and reconciliation.

Plan for Conformance, Testing, and Operations

Start with a transaction matrix that lists the client, DICOMweb service, resource, source or destination, corresponding DIMSE operation, transfer syntax, media type, authentication method, authorization rule, timeout, expected status, and exception owner. Use representative production data and test every system path before release.

Operational teams should monitor response time, failed queries, incomplete retrievals, store rejections, archive availability, and authentication errors. A clear support model should identify which team owns the viewer, proxy, identity platform, network, and source archive. This evidence makes it easier to isolate problems and demonstrate that the workflow behaves as designed.

Frequently Asked Questions About DICOMweb

What is DICOMweb?
DICOMweb is the RESTful family of web services defined in Part 18 of the DICOM standard for accessing DICOM imaging resources over HTTP or HTTPS.

What do WADO-RS, QIDO-RS, and STOW-RS do?
QIDO-RS searches studies, series, and instances. WADO-RS retrieves DICOM objects, metadata, frames, or rendered representations. STOW-RS stores new DICOM objects. Confirm which transactions and media types each product supports.

Can DICOMweb connect to a legacy PACS?
Yes. A DICOMweb proxy translates supported web requests into the DIMSE operations used by a legacy PACS, allowing modern applications to connect without replacing the PACS.

How is DICOMweb secured?
Secure deployments use HTTPS and TLS, identity-based authentication, least-privilege authorization, network protections, and audit logging. Organizations must configure and validate these controls for their environment.

DICOMweb and Other DICOM Proxies from Dicom Systems

Dicom Systems offers DICOMweb, Query/Retrieve, DICOM Modality Worklist, and Storage Commitment proxy workflows on the Unifier platform. Together, these workflows translate between DICOMweb and DIMSE, aggregate queries across connected archives, standardize worklist access, and track Storage Commitment results.

Dicom Systems DICOMweb Proxy

Health systems can deploy these proxy workflows independently or combine them with Unifier routing, patient matching, tag transformations, monitoring, and exception handling. The organization chooses which systems to connect and how each workflow should operate.

Connect the Systems You Need

Explore Dicom Systems DICOM Proxy Solutions for details about each proxy workflow. Meet with a Dicom Systems workflow expert to review the systems you need to connect and define the proxy requirements for your environment.