Medical Imaging & Interoperability

DICOMweb Explained for Product Teams (QIDO, WADO, STOW)

Published July 12, 2026 · Influrion Editorial Team

Classic DICOM networking (C-STORE, C-FIND, C-MOVE) predates the modern web and is awkward to use from a browser or mobile app. DICOMweb is the fix: it exposes the same imaging operations as ordinary RESTful HTTP services. If you're building an imaging product, DICOMweb is usually the interface you actually want to work with.

DICOMweb exposes three RESTful services over HTTPS: QIDO-RS to query, WADO-RS to retrieve, and STOW-RS to store DICOM data.Web clientviewer / appDICOMwebserver (PACS/VNA)GET · QIDO-RSquery — find studies/seriesGET · WADO-RSretrieve — download imagesPOST · STOW-RSstore — upload new instancesAll over ordinary HTTPS — no legacy DICOM networking required on the client.
DICOMweb turns DICOM into web APIs: QIDO-RS to query for studies, WADO-RS to retrieve images, and STOW-RS to store them — all over HTTPS, so browser and mobile clients can reach imaging without classic DICOM networking.

The three services you need to know

DICOMweb is really three RESTful APIs, each with a memorable name:

  • QIDO-RS — Query. "Query based on ID for DICOM Objects." A GET request that searches for studies, series, or instances matching criteria (patient, date, modality). This is how your app finds what's available.
  • WADO-RS — Retrieve. "Web Access to DICOM Objects." A GET that downloads the actual images (or metadata, or rendered frames). This is how your app shows an image.
  • STOW-RS — Store. "Store Over the Web." A POST that uploads new DICOM instances to the server. This is how your app saves imaging.

Query, retrieve, store — over plain HTTPS, with JSON metadata and standard content types.

Why product teams prefer it

  • Web-native. No special DICOM networking stack on the client — any HTTP client works, including browsers and mobile apps.
  • Firewall-friendly. It's just HTTPS on standard ports, which is far easier to deploy and secure than classic DICOM associations.
  • Granular. WADO-RS can return rendered frames or thumbnails, so you don't have to pull a whole multi-hundred-image study just to show one slice.
  • Familiar security. You secure it like any other API — TLS, tokens/OAuth, access control, and audit logging.

Where it fits with the rest of the stack

DICOMweb doesn't replace PACS — it's a modern access layer in front of PACS or a VNA. Many enterprise PACS/VNA products expose DICOMweb endpoints today. In a typical build:

  • Your web/mobile viewer uses QIDO-RS to list a patient's studies, then WADO-RS to render the selected images.
  • An upload or AI-output workflow uses STOW-RS to write results back.
  • A FHIR ImagingStudy resource can reference the study so the EHR knows it exists, while the pixels are served via WADO-RS.

Things that still bite

  • Not every server implements every option. Rendered vs raw retrieval, bulk data handling, and supported query parameters vary — check the specific server.
  • Study size and performance. Retrieving a full study is still a lot of data; use metadata queries, thumbnails, and frame-level retrieval to keep viewers responsive.
  • Auth and PHI. DICOMweb makes imaging reachable over the web — which means access control, token handling, and audit logging have to be right.

How we approach it

Imaging interoperability — classic DICOM, DICOMweb, PACS/VNA integration, and FHIR — is our core specialization. We build viewers and imaging workflows on DICOMweb where it fits, bridge to classic DICOM where it's required, and keep PHI protected end to end. If you're planning an imaging product, tell us what you're building and we'll help you scope the integration.