DICOMweb (DICOM PS3.18): WADO-RS, STOW-RS, QIDO-RS, UPS-RS, and HL7 FHIR ImagingStudy Integration

DICOMweb is the suite of RESTful HTTP/HTTPS web services defined in DICOM PS3.18 (Part 18: Web Services) of the Digital Imaging and Communications in Medicine (DICOM) standard for querying, retrieving, storing, and orchestrating medical imaging objects and workflows over modern web architectures. Whereas traditional hospital Picture Archiving and Communication Systems (PACS) and imaging modalities communicate over persistent, stateful TCP/IP sockets using the binary DIMSE (DICOM Message Service Element) protocol, DICOMweb exposes imaging studies, series, instances, and pixel frames as URI-addressable web resources using JSON/XML metadata and multipart MIME payloads.

In enterprise radiology, zero-footprint HTML5 DICOM viewers, cloud Vendor Neutral Archives (VNAs), and multi-site medical imaging AI pipelines, DICOMweb serves as the web-native transport bridge that connects high-volume pixel repositories to Electronic Health Records (EHRs) and HL7 FHIR servers.

What Is DICOMweb and How Does It Modernize PACS Imaging Exchange?

Historically, clinical imaging networks relied on point-to-point DIMSE commands—such as C-STORE (pushing images), C-FIND (searching a PACS or fetching a DICOM Modality Worklist [MWL]), and C-MOVE (initiating a separate reverse TCP connection to transfer images)—which require pre-configured Application Entity Titles (AE Titles), static IP addresses, and open non-HTTP firewall ports. This architecture complicates browser-based viewing, cloud PACS deployment, and cross-institutional image sharing.

DICOMweb (standardized in DICOM PS3.18) resolves these infrastructure bottlenecks through four architectural upgrades:

1. Standard HTTPS and OAuth 2.0 Security: Operates over port 443 using standard TLS 1.2/1.3 encryption, API gateways, and OAuth 2.0 / OpenID Connect bearer tokens (including SMART on FHIR scopes) rather than unauthenticated LAN AE Titles.
2. The DICOM JSON Model (PS3.18 Annex F): Encodes DICOM header tags (such as 0010,0020 Patient ID or 0020,000D Study Instance UID) as lightweight application/dicom+json objects containing the 8-character hexadecimal tag key, the 2-character Value Representation (vr, such as UI, PN, or DA), and a Value array or BulkDataURI pointer.
3. Sub-Instance and Frame-Level Granularity: Allows browser and mobile clients to fetch study metadata or render a single 2D slice from a 2,000-slice CT or whole-slide digital pathology image without downloading the entire multi-gigabyte DICOM Part 10 file first.
4. Decoupled Metadata and Bulk Pixel Streaming: Separates searchable header attributes from heavy binary pixel arrays or waveform buffers using multipart/related MIME streaming.

How Do WADO-RS, STOW-RS, QIDO-RS, and UPS-RS Work in DICOMweb?

The DICOM PS3.18 specification partitions imaging interoperability into four RESTful transaction families, each replacing a legacy DIMSE operation:

DICOMweb Service	Legacy DIMSE Equivalent	HTTP Method & Typical URI Pattern	Core Technical Function & MIME Payloads
QIDO-RS (Query based on ID for DICOM Objects)	C-FIND (Study/Series/Instance Query)	GET /studies?PatientID=...&ModalitiesInStudy=CT GET /studies/{study}/series	Searches for studies, series, or instances by DICOM tag attributes; returns lightweight application/dicom+json arrays without pixel data.
WADO-RS (Web Access to DICOM Objects)	C-MOVE / C-GET (and legacy WADO-URI)	GET /studies/{study}/series/{series}/instances/{instance}/frames/{frame} GET /studies/{study}/metadata	Retrieves full DICOM Part 10 instances (multipart/related; type="application/dicom"), metadata-only JSON, uncompressed/compressed bulk pixel frames, or server-rendered JPEG/PNG consumer images (/rendered).
STOW-RS (Store Over the Web)	C-STORE	POST /studies or POST /studies/{study}	Uploads binary DICOM Part 10 instances—or split JSON metadata plus bulk pixel streams—from scanners, clinical apps, or AI inference engines into a PACS/VNA.
UPS-RS (Unified Procedure Step)	Modality Worklist (MWL) & MPPS	POST /workitems PUT /workitems/{uid}/state GET /workitems?ups-state=SCHEDULED	Creates, queries, claims, and updates scheduled imaging procedure steps, radiologist reading worklists, and AI post-processing task states with WebSocket event subscriptions.

DICOM Modality Worklist (MWL) vs. UPS-RS

In hospital Radiology Information System (RIS) workflows, the classic DICOM Modality Worklist (MWL) uses a DIMSE C-FIND query from the CT, MRI, or ultrasound console to pull scheduled patient demographics and accession numbers so technologists do not mistype patient names. In modernized cloud and AI orchestration architectures, UPS-RS (Unified Procedure Step over REST) extends worklist management to web clients and AI triage algorithms, allowing a PACS or orchestrator to assign an imaging study to an AI container, track transition from SCHEDULED to IN PROGRESS to COMPLETED, and receive the resulting DICOM Structured Report (SR) or Segmentation (SEG) object via STOW-RS.

How Does DICOMweb Link with the HL7 FHIR ImagingStudy Resource?

Clinical applications rarely use DICOMweb in isolation; instead, they pair HL7 FHIR (for clinical context, orders, and diagnostic reports) with DICOMweb (for pixel and tag access) using a dual-standard architecture defined by the HL7 Imaging Integration Work Group and IHE Radiology profiles:

• Order to Acquisition (ServiceRequest → Modality): When a physician orders an imaging exam in the EHR, the order is represented in FHIR as a ServiceRequest resource (carrying the Accession Number and LOINC/CPT procedure code).
• The ImagingStudy Resource as the Bridge: Once the modality acquires the scan and stores it to the PACS/VNA, the system creates an HL7 FHIR ImagingStudy resource. Rather than embedding heavy DICOM pixel bytes inside the FHIR server, the ImagingStudy resource stores:
  1. Clinical references to the Patient, ordering ServiceRequest, and resulting DiagnosticReport.
  2. The hierarchical DICOM Unique Identifiers: ImagingStudy.identifier (the DICOM StudyInstanceUID, prefixed with urn:dicom:uid:), ImagingStudy.series.uid (SeriesInstanceUID), Modality code (`CT`, `MR`, `DX`), body site (SNOMED CT), and ImagingStudy.series.instance.uid (SOPInstanceUID).
  3. ImagingStudy.endpoint / series.endpoint: A direct reference to a FHIR Endpoint resource whose connectionType is set to dicom-wado-rs, dicom-qido-rs, or dicom-stow-rs and whose address provides the base HTTPS URL of the DICOMweb server.
• Zero-Footprint Clinical Viewing & AI Inference: An EHR-launched SMART on FHIR app or radiology AI tool queries the FHIR server for GET /ImagingStudy?patient=123, extracts the StudyInstanceUID and the referenced DICOMweb Endpoint.address, and immediately streams the image frames via WADO-RS: GET [Endpoint.address]/studies/[StudyInstanceUID]/series/[SeriesInstanceUID]/rendered. Every vendor’s supported DICOMweb services, transfer syntaxes, and media types are formally declared in its DICOM Conformance Statement.

Frequently Asked Questions

What is DICOMweb and how does it modernize PACS imaging exchange?

DICOMweb (defined in DICOM PS3.18) is the RESTful HTTPS web services standard for medical imaging. It modernizes PACS and VNA exchange by replacing stateful, firewall-sensitive TCP/IP DIMSE socket connections with standard HTTP GET, POST, and PUT calls, JSON metadata (`application/dicom+json`), OAuth 2.0 authorization, and frame-level streaming for web and cloud applications.

How do WADO-RS, STOW-RS, and QIDO-RS work in DICOMweb?

In DICOMweb, QIDO-RS searches the PACS/VNA for studies, series, or instances using HTTP GET parameters and returns JSON metadata; WADO-RS retrieves full DICOM instances, metadata, raw pixel frames, or rendered JPEG/PNG images via HTTP GET; and STOW-RS uploads new DICOM scans or AI-generated secondary captures/segmentations to the archive via HTTP POST.

How does DICOMweb link with the HL7 FHIR ImagingStudy resource?

The HL7 FHIR ImagingStudy resource links clinical EHR records (`Patient`, `ServiceRequest`, `DiagnosticReport`) to a DICOMweb server by storing the DICOM StudyInstanceUID, SeriesInstanceUID, and SOPInstanceUID alongside a reference to a FHIR Endpoint resource (`connectionType = dicom-wado-rs`). A web viewer or AI application reads the UIDs and endpoint URL from FHIR and fetches the actual image pixels directly from the DICOMweb server.