WADO-RS

WADO-RS models DICOM data as uniquely addressable web resources using a hierarchical URI structure. Each Study, Series, and Instance is accessed via a predictable path, enabling standard HTTP caching, proxying, and load-balancing infrastructure to be used without custom DICOM networking stacks.

• URI Pattern: {service}/studies/{StudyInstanceUID}/series/{SeriesInstanceUID}/instances/{SOPInstanceUID}
• HTTP Methods: Uses GET for retrieval, supporting conditional requests via ETags and If-Modified-Since headers
• Statelessness: Each request is independent, eliminating the need for persistent DICOM associations

WADO-RS supports content negotiation through HTTP Accept headers, allowing clients to request DICOM data in the format most suitable for their processing pipeline. This decouples the storage format from the delivery format.

• application/dicom: Returns the raw binary DICOM Part 10 file for full-fidelity transfer
• application/dicom+xml: Returns native DICOM data encoded as XML per Part 19, ideal for XSLT processing
• application/dicom+json: Returns DICOM data as JSON per Part 18 Annex F, optimized for web application consumption
• Transfer Syntax Conversion: The server may transcode the pixel data to a requested transfer syntax, such as JPEG-LS Lossless to JPEG 2000 Lossless

A critical feature for multi-frame DICOM instances such as cine loops, whole slide images, and dynamic contrast-enhanced series. WADO-RS allows clients to request individual frames or ranges of frames without retrieving the entire multi-gigabyte object.

• Frame URI: Append /frames/{frameNumber} to the instance URI to retrieve a single frame
• Byte Range Support: Uses HTTP Range headers to request specific byte segments of a single frame for progressive rendering
• Accept Header Control: Clients can request frames transcoded to a specific media type, e.g., image/jpeg for a thumbnail preview, reducing bandwidth for viewing clients

WADO-RS enables the retrieval of DICOM metadata without the bulk pixel data, a critical optimization for study list queries, radiation dose reports, and structured report parsing. This is achieved by requesting the instance resource with an application/dicom+json or application/dicom+xml Accept header and the server omitting the 7FE0,0010 Pixel Data element.

• Reduced Payload: A metadata-only response for a CT study may be kilobytes instead of hundreds of megabytes
• Bulk Data URIs: When metadata is returned, large attributes like pixel data and waveforms are replaced with BulkDataURI references that can be fetched separately on demand
• Use Case: Enables rapid dashboard population of patient demographics and acquisition parameters without saturating network bandwidth

WADO-RS supports a dedicated endpoint at /rendered that allows a client to request a server-side rendered representation of a DICOM instance, frame, or thumbnail. The server performs the rendering and returns a consumer image format.

• Rendered URI: {service}/studies/{StudyInstanceUID}/series/{SeriesInstanceUID}/instances/{SOPInstanceUID}/rendered
• Query Parameters: Supports viewport for window center/width, annotation to toggle burned-in patient info, and quality for JPEG compression level
• Thumbnail Endpoint: A dedicated /thumbnail sub-resource returns a small, fixed-size representation for efficient image strip navigation

Unlike the legacy DIMSE protocol which requires complex IPSec or TLS tunneling configurations, WADO-RS inherits the mature security ecosystem of HTTPS. This simplifies compliance with HIPAA and GDPR mandates for data in transit.

• Transport Security: Standard TLS 1.3 encryption with mutual certificate authentication
• Authorization: Integrates with OAuth 2.0 and OpenID Connect bearer tokens for fine-grained access control to specific studies
• Audit Logging: Standard HTTP server access logs capture every retrieval transaction, simplifying the DICOM Audit Trail (ATNA) integration profile requirements