Short answer: DICOMweb is the set of web services defined in Part 18 of the DICOM standard. It exposes a DICOM archive over plain HTTPS: QIDO-RS (Query based on ID for DICOM Objects) searches for studies, series and instances; WADO-RS (Web Access to DICOM Objects) retrieves them, as full DICOM files, as metadata in JSON, or as rendered JPEG/PNG; STOW-RS (Store Over the Web) uploads new objects. The older WADO-URI retrieves one object through query parameters. Browser-based viewers use DICOMweb because they cannot speak classic DICOM networking.
Classic DICOM vs DICOMweb
Classic DICOM networking (Parts 7 and 8 of the standard) uses a binary protocol over TCP with services such as C-FIND, C-MOVE, C-GET and C-STORE between configured nodes. DICOMweb (Part 18) maps the same operations onto HTTP: QIDO-RS to search, WADO-RS to retrieve and STOW-RS to store, which works across the internet and from browsers.
Classic DICOM (Part 7 and 8) uses its own binary protocol over TCP with named services: C-FIND to query, C-MOVE or C-GET to retrieve, C-STORE to send. It needs a configured "association" between two known nodes (AE titles, IP addresses, ports), which is fine inside a hospital and hard across the internet. DICOMweb maps the same ideas onto HTTP:
| Task | Classic DICOM | DICOMweb |
|---|---|---|
| Find a study | C-FIND | QIDO-RS: GET /studies?PatientID=… |
| Retrieve a study | C-MOVE / C-GET | WADO-RS: GET /studies/{StudyInstanceUID} |
| Read metadata only | C-FIND at instance level | WADO-RS: GET /studies/{uid}/metadata |
| Get a viewable image | retrieve then render locally | WADO-RS rendered: GET …/instances/{uid}/rendered |
| Send images to an archive | C-STORE | STOW-RS: POST /studies |
| Manage worklists | MWL (C-FIND on a worklist) | UPS-RS |
The resource hierarchy follows DICOM's own model: a study (one visit to the scanner) contains series (one acquisition each), which contain instances (single images or multi-frame objects), each identified by a globally unique UID.
QIDO-RS: searching
QIDO-RS is the DICOMweb search service. A client sends GET /studies, /series or /instances with query parameters such as PatientID, StudyDate or ModalitiesInStudy and the Accept header application/dicom+json. The archive returns a JSON array in which each DICOM attribute is keyed by its eight-digit tag together with its value representation and values.
GET /dicomweb/studies?PatientID=12345&StudyDate=20260101-20261231&ModalitiesInStudy=CT
Accept: application/dicom+json
The response is a JSON array of studies. Each attribute is keyed by its tag (group and element as eight hex digits), with its value representation and values:
[{
"00080020": {"vr": "DA", "Value": ["20260314"]},
"00080060": {"vr": "CS", "Value": ["CT"]},
"00100010": {"vr": "PN", "Value": [{"Alphabetic": "DOE^JANE"}]},
"0020000D": {"vr": "UI", "Value": ["1.2.840.113619.2.55.3.2831164356.781.1710415000.1"]},
"00201206": {"vr": "IS", "Value": [3]},
"00201208": {"vr": "IS", "Value": [412]}
}]
Here 00201206 is Number of Study Related Series and 00201208 is Number of Study Related Instances. The tag numbers are explained in DICOM tags explained.
WADO-RS: retrieving
WADO-RS is the DICOMweb retrieval service. GET /studies/{StudyInstanceUID} returns a whole study as DICOM Part 10 files in a multipart response; the /metadata suffix returns headers as JSON without pixel data; /frames/{n} returns one frame's pixels; and /rendered returns a server-rendered JPEG or PNG with window, viewport and quality parameters.
GET /studies/{study}withAccept: multipart/related; type="application/dicom"returns every instance as a DICOM Part 10 file, one part each.GET /studies/{study}/metadatareturns the headers of all instances as JSON, without pixel data. Viewers call this first to build the layout, then fetch pixels frame by frame.GET /studies/{study}/series/{series}/instances/{instance}/frames/1returns one frame's pixel data, optionally transcoded (transfer-syntaxparameter).GET …/instances/{instance}/renderedwithAccept: image/jpegreturns a server-rendered image, withwindow,viewportandqualityparameters. This is what a lightweight patient portal uses to show a preview.
STOW-RS: storing
STOW-RS is the DICOMweb storage service. A client sends POST /studies with a multipart/related body in which each part is one DICOM file. The archive replies with a list of accepted and failed instances and the reason for each failure, and checks that any Study Instance UID given in the URL matches the uploaded files.
POST /dicomweb/studies
Content-Type: multipart/related; type="application/dicom"; boundary=abc
Each part is one DICOM file. The response lists accepted and failed instances with reasons (wrong SOP class, duplicate UID). Archives validate that the Study Instance UID in the URL, if given, matches the files.
Security
DICOMweb has no login of its own; it relies on HTTPS and whatever the server puts in front: OAuth 2.0 bearer tokens in most modern archives, often combined with SMART on FHIR scopes when the viewer is launched from an EHR. Logging who retrieved which study is the archive's job, not the protocol's.
Where it is used
Every major PACS and vendor-neutral archive now offers a DICOMweb endpoint, and open-source archives (Orthanc, dcm4chee, Google Cloud Healthcare API, Azure DICOM service) are DICOMweb-first. Web viewers such as OHIF are built entirely on QIDO-RS and WADO-RS. In a FHIR world, an ImagingStudy resource points to a DICOMweb endpoint; the pixels never go through FHIR.
Anpheros does not store images. A patient's record can hold the radiology report as a DocumentReference or DiagnosticReport and, where a hospital provides one, a link to its viewer; the DICOM data itself stays in the hospital's archive. For getting your own images as a patient, see How to get your CT or MRI images.
Related pages
- FHIR ImagingStudy vs DICOMweb
- DICOM tags explained
- PACS vs RIS vs VNA
- How to get your CT or MRI images (DICOM)
- Healthcare interoperability standards: the map
- DICOM vs FHIR for developers
Sources
- DICOM PS3.18: Web Services
- DICOM PS3.7: Message Exchange
- DICOMweb overview (DICOM Standards Committee)
- OHIF Viewer documentation
Frequently asked questions
Is DICOMweb a different standard from DICOM?
No. It is Part 18 of the same DICOM standard. The objects, tags and UIDs are identical; only the transport changes from DICOM's own protocol to HTTP.
What is the difference between WADO-URI and WADO-RS?
WADO-URI is the older service: one object per request, selected with query parameters (?requestType=WADO&studyUID=…). WADO-RS is RESTful, can return whole studies or series, metadata as JSON and individual frames, and is what new systems implement.
Can I use DICOMweb without a PACS?
You need some archive that implements it. Open-source servers such as Orthanc and dcm4chee provide DICOMweb out of the box and are commonly used for development and for small clinics.
Does FHIR replace DICOMweb?
No. FHIR describes the study (ImagingStudy) and the report (DiagnosticReport); DICOMweb delivers the images. A viewer uses both: FHIR to find out that a study exists, DICOMweb to show it.
Try it in Anpheros Daily
Keep your scan and test reports in one place in Anpheros Daily, ready to show at your next visit.
How it works in the app →
Anpheros builds a medical record that the patient controls and can share with any clinic, on an HL7 FHIR R4 platform, based in the EU. These guides help you understand and organise your health; they do not replace your doctor.
About Anpheros →
AnpherosThe more you log, the clearer your record
Your health history in one place, under your control.
Free · Works in your browser · No card
