DIMSE association, storage, and retrieve

An engineer who begins with HTTP often expects a request to carry a response back over the same connection. Classic DICOM networking has a different shape. Objects move between DICOM Application Entities through DIMSE services, and the roles, negotiation, and destination of an operation must be understood before a log can be interpreted.

Associations and application entities

An Application Entity (AE) is an endpoint participating in DICOM communication. A classic AE is identified in the DICOM configuration by an AE Title together with a network endpoint such as a host and port, rather than by an HTTP URL. In one operation an AE may act as a Service Class User (SCU), initiating a service, and in another it may act as a Service Class Provider (SCP), accepting and performing it. A PACS can therefore receive stored objects as an SCP while initiating queries as an SCU.

Before an operation, the peers negotiate an association. The proposed and accepted presentation contexts describe which SOP Classes and Transfer Syntaxes can be used for the communication. This creates an important diagnostic boundary: a TCP connection can succeed while the DICOM operation still cannot proceed because the peers did not agree on the object class or encoding. A presentation-context rejection is an application-level compatibility failure, not evidence that the network path was absent.

The DIMSE verbs

The common services can be compressed into the following mental model. It is a working vocabulary, not an exhaustive list of DICOM services or query levels.

Operation	Working meaning	Typical role in a workflow
C-STORE	Send a DICOM object to an SCP	Store an image or derived object.
C-FIND	Query using matching and return keys	Find a worklist entry or matching study, series, or instance.
C-MOVE	Ask a source SCP to send matches to a named destination AE	Retrieve through a third-party storage destination.
C-GET	Ask a source SCP to send matches back to the requesting association	Retrieve to the requester when the service is available.
Modality Worklist	A worklist query interaction	Supply scheduled patient and procedure information to a modality.

In a common Query/Retrieve pattern, a workstation first uses C-FIND with keys such as PatientID, StudyInstanceUID, StudyDate, or Modality to obtain matching identifiers. It then uses C-MOVE or C-GET to obtain the corresponding objects. The two-step pattern is useful for reasoning about the system, but an actual implementation can choose different query levels, retrieve services, and orchestration.

C-MOVE is a three-party operation

C-MOVE is the point at which HTTP intuition most often fails. The requester sends a C-MOVE request to a source SCP and includes a destination AE. The source SCP then opens a separate association to that destination and performs C-STORE sub-operations there. The process that asked for the move and the process that receives the objects are therefore not necessarily the same process.

This arrangement lets a lightweight requester ask an archive to deliver a study directly to a viewer, archive, or storage service. It also creates a configuration boundary that does not exist in an ordinary HTTP response: the destination must be known to the source, addressable on the network, and able to accept the relevant C-STORE operations. A requester can successfully issue a query and a move while still receiving no objects locally if it named another destination or did not run a storage SCP at the expected AE.

The final C-MOVE response reports the result of the sub-operations to the named destination. A useful reading of the common status paths is:

Status	Interpretation for the move request
0000	The C-STORE sub-operations to the named destination completed without reported failures.
B000	The sub-operations completed, but one or more failures or warnings were reported; inspect the completed, failed, and warning counters.
A801	The Move Destination is unknown to the source SCP; the destination cannot be used for the move.
A701 or A702	A failure path involving refusal or inability to perform the requested operation, subject to the service definition and implementation context.
Cxxx	An implementation-reported processing failure whose precise meaning depends on the applicable service specification.

The table is intentionally bounded. The exact status semantics and the counts of completed, failed, and warning sub-operations must be read against the applicable DICOM service specification and the implementation log. In particular, 0000 does not mean that the requesting script received bytes over its own association; it means that the requested delivery to the named destination completed without reported failures. An A801 is an explicit unknown-destination failure, not a successful transfer into nowhere.

C-GET provides a different mental model because the objects are sent back over the requesting association. Whether C-GET is available, enabled, or appropriate is an implementation and policy matter. The protocol choice does not remove the need to check object identity, negotiated presentation contexts, and the receiving workflow.

The distinction between requester and destination also explains a common failure report: “the query succeeded, but my script got nothing.” The query may have returned correct identifiers, while the move delivered the objects to a different registered AE. The remedy is to inspect the requested destination, its AE-to- endpoint configuration, and its ability to accept C-STORE before changing the model or the query.

From DIMSE to DICOMweb

DIMSE remains a durable transport for imaging systems, but a web client usually needs a different interaction shape. DICOMweb provides HTTP-based services for querying, retrieving, storing, and work items. It preserves the DICOM object world while changing the transport and its operational boundaries.