DICOM C-STORE vs DICOMweb STOW-RS

Both C-STORE and STOW-RS move DICOM instances from one system to another. People often call them “the same thing over a different wire.” The differences matter once you build against either one, especially if your service lives outside a hospital’s network.

C-STORE: the classic DIMSE operation

C-STORE is a DIMSE (DICOM Message Service Element) operation — part of the original DICOM network protocol, designed in the era before REST APIs existed. To send an instance with C-STORE:

1. The sender opens a DICOM association with the receiver — a stateful, negotiated session, not a simple request/response. Both sides agree on which SOP classes and transfer syntaxes they’ll use (read our guide explaining SOP Classes and Transfer Syntaxes).
2. The sender issues a C-STORE request inside that association, carrying the instance.
3. The receiver replies with a status code inside the same association.
4. The association stays open for further C-STORE operations, or closes.

This is efficient for what it was built for. Two systems on the same network, talking a shared binary protocol, can push many instances through one session — a whole CT study, for example (to understand how exams split into instances and series, see our guide explaining DICOM Instances, Series, and Studies). In hospital workflows, these images typically arrive populated with patient and order metadata directly from DICOM Modality Worklist.

It’s also why C-STORE traffic doesn’t look or behave like typical web traffic. There’s no URL, no HTTP verb, and the “connection” is really a long-lived, multi-message session with its own handshake.

STOW-RS: DICOM instances over standard HTTP

STOW-RS (“Store Over the Web, RESTful Services”) is part of DICOMweb, the DICOM Standard’s HTTP-based transfer family (alongside QIDO-RS for querying and WADO-RS for retrieval). STOW-RS delivers the same DICOM instances, but as a standard HTTP request:

POST /studies HTTP/1.1
Content-Type: multipart/related; type="application/dicom"; boundary=...

--boundary
Content-Type: application/dicom

<binary DICOM instance>
--boundary--

Each instance (or batch of instances) is one HTTP request. There’s no association to negotiate and no stateful session to keep open. Every request is self-contained — exactly the shape web infrastructure like load balancers, HTTPS, and standard client libraries already knows how to handle.

The practical difference: what your team has to build

Most cloud PACS, AI diagnostic platforms, and archive products are built like a typical web API. For them, receiving STOW-RS is a much smaller lift than receiving raw C-STORE — no DIMSE association handling, just one more HTTP endpoint.

Where this shows up in practice

Hospital-side equipment (scanners, PACS, workstations) almost always speaks C-STORE natively — that’s what’s built into the imaging hardware. Your service, on the other hand, is better off receiving STOW-RS: standard HTTP is what your team already knows how to test, monitor, and scale.

That mismatch — DICOM-native senders on one side, an HTTP-native service on the other — is exactly the gap covered in our guide on receiving DICOM over the public internet.

Dicomly’s endpoints accept the sender’s native C-STORE connection, secured with mTLS (see how mutual TLS authenticates each DICOM sender). Each instance then reaches your service as a real-time STOW-RS HTTPS POST, so you only ever build against the web-native side of the protocol.

Try it with your own endpoint

Want to see a STOW-RS delivery land at your own endpoint? The quickstart walks through creating an endpoint and sending a test image, or request early access to connect your first hospital sender.