DICOMweb is not a replacement for DICOM, and it is not a competing standard. It is a set of web-based services defined within the DICOM standard itself — the same data model and the same objects, exposed over HTTP instead of the traditional DIMSE protocol.
Confusion usually starts with the naming. It helps to think of it as one standard with two transport mechanisms, chosen according to where the software runs.
Classic DICOM: DIMSE over TCP
Traditional DICOM networking uses DIMSE services over a dedicated TCP connection. Two devices establish an association, negotiate what they can exchange, and then perform operations — C-STORE, C-FIND, C-MOVE and the rest.
Several characteristics follow from that design:
- Each device is identified by an AE Title, and both ends must be configured with each other's details in advance
- Communication happens on a dedicated port, conventionally 104 or 11112
- Capabilities are negotiated when the association is established
- C-MOVE in particular requires the receiving system to be pre-configured as a known destination, since the sender initiates a separate connection back
This works extremely well inside a hospital network, where devices are fixed, known to each other, and administered centrally. It works poorly across the internet or through firewalls, and it is awkward for a web browser, which cannot open arbitrary TCP connections at all.
DICOMweb: the same data over HTTP
DICOMweb defines RESTful services that map onto the familiar operations:
| Purpose | Classic DIMSE | DICOMweb |
|---|---|---|
| Query for studies | C-FIND | QIDO-RS |
| Retrieve images | C-MOVE / C-GET | WADO-RS |
| Send images | C-STORE | STOW-RS |
| Worklist | Modality Worklist | UPS-RS (workitems) |
The names are less cryptic than they look:
- QIDO-RS : Query based on ID for DICOM Objects by RESTful Services. An HTTP GET with query parameters, returning JSON or XML
- WADO-RS : Web Access to DICOM Objects by RESTful Services. An HTTP GET that returns the instances themselves, and can return specific frames or rendered images rather than whole objects
- STOW-RS : Store Over the Web by RESTful Services. An HTTP POST carrying instances to be stored
What actually changes
Firewalls and networks
DICOMweb uses HTTP/HTTPS, commonly HTTPS over port 443 in production deployments. It traverses firewalls, proxies and load balancers like any other web traffic — which is precisely what classic DIMSE does not do gracefully.
Browsers become first-class clients
A browser cannot speak DIMSE. It can speak HTTP natively, so zero-footprint web viewers become straightforward. This single fact is why DICOMweb exists.
Security model
DICOMweb inherits the web's security infrastructure — TLS, OAuth 2.0, bearer tokens, standard authentication. Classic DICOM's model is essentially trust based on configured AE Titles and network position, which is weaker and much harder to federate across organisations.
Retrieval model
WADO-RS is a straightforward request-response: ask for something, receive it. Compare that with C-MOVE, where you ask system A to send to system B, and both must have been configured for each other beforehand. For anything crossing an organisational boundary, the difference is substantial.
Granularity
WADO-RS can return a single frame from a multi-frame object, or a rendered JPEG rather than the full DICOM instance. For a viewer displaying one slice at a time over a limited connection, that matters a great deal.
When to use which
Classic DIMSE remains the right choice for:
- Modality to PACS communication inside a hospital network
- Modality Worklist on the scanner
- Established on-premise infrastructure, where it is deeply embedded and works
- Any device whose installed base expects it — which is most imaging equipment
DICOMweb is the right choice for:
- Browser-based and mobile viewers
- Cloud-hosted archives and services
- Teleradiology across the public internet
- Modern application development, where REST and JSON fit the rest of the stack
In practice most systems need both. A typical architecture speaks DIMSE to the modalities inside the hospital and exposes DICOMweb outward for viewers, cloud services and external sharing. Gateways that bridge the two are a common and entirely legitimate component.
Points worth watching
- Support varies. Not every PACS implements all three DICOMweb services, and some implement only WADO-RS. Check the conformance statement rather than assuming
- The data is identical. Both transports carry the same DICOM objects with the same UIDs and attributes — only the delivery differs
- Performance differs by workload. HTTP overhead per request can make bulk transfer of very large studies slower than a DIMSE association, so measure for your case rather than assuming one is faster
The useful mental model is simply this: same data, same identifiers, same standard — different door into the building. Choose the door that suits where your software runs.