The third-party destination in C-MOVE

C-MOVE is worth isolating because it changes what a successful retrieve means. In an HTTP interaction, the client normally receives the requested representation from the server it contacted. In a C-MOVE interaction, the requester asks a source SCP to deliver matching objects to a separately named destination AE. The source then communicates with that destination through a new association and uses C-STORE.

The three parties are therefore:

1. the requesting SCU, which identifies the objects and names the destination;
2. the source SCP, which performs the move and reports its status; and
3. the destination AE, which receives the objects through C-STORE.

The pixels travel from the source to the destination, not necessarily back to the requesting process. This is a compact mental model for the operation, not a claim that every product exposes the same user interface or deployment topology.

Read the final status in context

The source SCP may send pending responses while it performs the sub-operations. Its final response is returned after the C-STORE activity to the named destination has finished. In the status vocabulary used here, 0000 represents completion without reported failures, while B000 means that the sub-operations completed with one or more failures or warnings. A801 identifies an unknown move destination. A701 means that the SCP was unable to calculate the number of matches, A702 means that it was unable to perform the sub-operations, and Cxxx represents an inability to process the request whose precise meaning follows the service definition. The completed, failed, and warning counters remain part of the interpretation.

This distinction matters operationally. If a destination AE is unknown, the source cannot start the requested delivery and reports a failure. If the destination is known but unavailable or unable to accept an object, the failure is reflected in a warning or failure path rather than being silently converted into a successful local response. A genuine 0000 still says only that the named destination accepted the sub-operations without reported failures. It does not say that the requesting script was the destination, that a particular viewer displayed the objects, or that a later user could retrieve them.

Consequently, “success but nothing arrived in my script” can be an expectation mismatch. The script may not have been the destination AE, may not have been running a storage SCP, or may have named a destination whose receiving process was different from the one being observed. The correct diagnosis starts with the destination in the C-MOVE request and follows the separate C-STORE association.

C-GET is the contrasting two-party retrieve when supported: the source sends the objects back through the requesting association. It avoids the separate destination configuration, but its availability and suitability are still matters for the particular DICOM implementation and local policy. Neither service removes the need to verify what was requested, where it was sent, and whether the receiver can use it.

The C-MOVE example exposes a general informatics lesson. A response status describes the protocol operation that produced it; it does not automatically describe the state of a downstream viewer, archive, or clinical workflow. Those later promises need their own evidence, which is why transport must be kept distinct from availability and clinical visibility.