STOW-RS

STOW-RS accepts DICOM instances packaged as a multipart/related MIME body within a single HTTP POST request. Each part contains one DICOM SOP Instance, allowing batch storage of an entire study in a single transaction. The Content-Type header must be set to multipart/related; type="application/dicom" with a specified boundary delimiter. This eliminates the overhead of negotiating a separate DICOM association for each image, dramatically simplifying firewall traversal and load balancer configuration compared to the legacy DIMSE C-STORE protocol.

The standard STOW-RS endpoint follows a predictable RESTful pattern: POST {base-url}/studies to store a new study, or POST {base-url}/studies/{studyInstanceUID} to append instances to an existing study. This resource-oriented design aligns with modern API gateway and microservice architectures. The server returns an XML or JSON response containing the success or failure status for each stored instance, including any Warning or Failure Reason codes, enabling robust programmatic error handling without parsing DICOM command sets.

Unlike the stateful DICOM Association Negotiation required by DIMSE, STOW-RS is inherently stateless. Each HTTP request is independent and self-contained, carrying all necessary authentication and payload data. This statelessness enables horizontal scaling behind a standard load balancer without sticky sessions, simplifies retry logic on failure, and allows the use of commodity CDN and reverse proxy infrastructure. The server does not maintain a persistent TCP connection context between transactions, reducing memory pressure on the storage SCP.

STOW-RS leverages standard HTTP authentication mechanisms, including OAuth 2.0 Bearer Tokens, JWT, and TLS mutual authentication, rather than relying on the limited DICOM User Identity Negotiation extension. This allows seamless integration with enterprise Identity and Access Management (IAM) systems and Single Sign-On (SSO) providers. Security teams can apply consistent web application firewall (WAF) rules and API rate limiting policies to DICOM storage traffic, unifying the security posture for imaging data with the rest of the enterprise API ecosystem.

The STOW-RS response body provides a detailed, per-instance accounting of the storage operation. For each SOP Instance submitted, the server returns a ReferencedSOPSequence item containing the retrieveURL for subsequent WADO-RS access, the SOPClassUID, and the SOPInstanceUID. Failures are reported with a Failure Reason code (e.g., Processing failure, Duplicate SOP Instance) and an optional human-readable Comment. This granular feedback enables the client to implement precise retry logic for only the failed instances rather than re-sending an entire batch.

When posting to the {base-url}/studies endpoint, STOW-RS treats the entire multipart payload as an atomic transaction for the creation of a new Study resource. The server assigns a new Study Instance UID and returns it in the Location response header. This allows a modality or acquisition gateway to transmit all images, structured reports, and presentation states for a complete patient exam in one round-trip, ensuring referential integrity. The client does not need to pre-coordinate the Study UID, simplifying the workflow for Secondary Capture and conversion scenarios.