C-MOVEhow a PACS pushes a study to a third party
C-MOVE is the part of DICOM that surprises people most: the one that asks is not the one that receives. The workstation tells the PACS "send this study to destination X", and the PACS connects to X on a separate association and does the C-STORE itself.
- DICOM
- Internal action
- Dashed = reply
Tip: click an arrow or box in the diagram to jump to that step. Time flows top to bottom.
C-MOVE-RQ with a Move Destination
Core stepWhat happens
On an association already opened with a Retrieve SOP Class, the requester sends the C-MOVE request. It carries the AE title of the destination, and an identifier that selects what to move, usually a StudyInstanceUID found with C-FIND.
Why it is needed
The request names the receiver by AE title only. The requester does not tell the PACS where the destination is on the network. That is the PACS's job.
Technical details
- Study Root MOVE 1.2.840.10008.5.1.4.1.2.2.2 (Patient Root: ...2.1.2)
- (0000,0100) CommandField = 0021
- (0000,0600) MoveDestination = DEST_AE (AE title)
- (0008,0052) QueryRetrieveLevel = STUDY
- (0020,000D) StudyInstanceUID = 1.2.840....
The PACS looks up the destination
Key detailWhat happens
The PACS searches its list of known DICOM nodes for DEST_AE, to learn its IP address and port. It also collects the instances that match the identifier.
Why it is needed
This is the most common cause of failed moves. If the PACS does not know the AE title, nothing can be sent and it answers with a failure.
Technical details
- Unknown destination: C-MOVE-RSP failure A801 (move destination unknown)
- Wrong IP or port in the PACS node list: the next step fails
- The requester only needs its own node to be known if it is also the destination
Association from the PACS to the destination
Core stepWhat happens
The C-STORE sub-operations never run on the association of the C-MOVE. PS3.4 says the PACS shall either reuse an established and compatible association to the destination, or establish a new one, acting as Storage SCU and proposing the storage SOP Classes of the images it is about to send. The destination accepts as Storage SCP. A sub-operation counts as failed if no suitable presentation context can be negotiated for an image.
Why it is needed
This second association is why the destination must be listening on its own DICOM port, and why firewalls and NAT can block a C-MOVE that a plain C-STORE would not.
Technical details
- Calling AE = the PACS (some PACS allow a configured alias)
- Called AE = DEST_AE
- Presentation contexts for the SOP Classes in the study
- (0000,1030) MoveOriginatorApplicationEntityTitle may be set in the C-STORE
C-STORE sub-operations
Core stepWhat happens
The PACS sends the images one by one as C-STORE requests with their data sets. These are called sub-operations because they are performed on behalf of the C-MOVE.
Why it is needed
Retrieval reuses the storage service. It is not a separate protocol for moving images.
Technical details
- One C-STORE-RQ per instance
- (0000,1031) MoveOriginatorMessageID = Message ID of the C-MOVE
- Same rules as the C-STORE lesson
C-STORE-RSP from the destination
ConfirmationWhat happens
The destination answers each image with a C-STORE-RSP. The PACS counts the successes, warnings and failures.
Why it is needed
The requester never sees these responses. It only learns about the result through the counts the PACS reports back.
Technical details
- 0000 success: counts as completed
- Bxxx warning: counts as warning
- Failure: counts as failed
C-MOVE-RSP Pending with progress
Key detailWhat happens
While it works, the PACS may send C-MOVE-RSP messages with status Pending to the requester, with the current counts. Pending responses are optional for the SCP. This is what a progress bar in a viewer is built on.
Why it is needed
The requester needs to know when to stop waiting and whether anything failed, without ever touching the images.
Technical details
- (0000,0900) Status = FF00
- (0000,1020) NumberOfRemainingSuboperations
- (0000,1021) NumberOfCompletedSuboperations
- (0000,1022) NumberOfFailedSuboperations
- (0000,1023) NumberOfWarningSuboperations
Final C-MOVE-RSP
ConfirmationWhat happens
When no sub-operations remain, the PACS sends the final response. Success (0000) means every sub-operation succeeded. Warning (B000) means some succeeded and some failed or had a warning, or that all had a warning. Failure means all of them failed. The counts say how many, and for a warning or failure the identifier lists the failed SOP Instance UIDs.
Why it is needed
Success on the C-MOVE depends on the C-STORE results at the destination. A "successful" move that arrived empty is usually a destination or matching problem and is visible in the counts.
Technical details
- 0000 success: all sub-operations completed without failures
- B000 warning: one or more sub-operations failed (or all had a warning)
- A801 move destination unknown, A900 identifier does not match SOP Class, Cxxx unable to process
- A701 out of resources, unable to calculate number of matches; A702 out of resources, unable to perform sub-operations
- FE00 cancelled: the requester sent C-CANCEL-MOVE and the PACS stopped the sub-operations
- (0008,0058) FailedSOPInstanceUIDList: in cancel, failure and warning responses, not in success or pending
All steps at a glance
Glossary
- SCU
- Service Class User. The side that asks for a service, such as a scanner that wants to store images.
- SCP
- Service Class Provider. The side that provides the service, such as a PACS that stores images.
- AE / AE title
- Application Entity: a DICOM application on a device. Its AE title (max 16 characters) is the name other devices use to address it.
- Move Destination
- The AE title in a C-MOVE request that tells the PACS who should receive the images.
- Sub-operation
- One C-STORE the PACS performs for a C-MOVE or C-GET. The responses count them.
- C-GET
- Like C-MOVE, but the images are returned on the same association as C-STORE sub-operations, so no destination is named.
Summary
- C-MOVE tells the PACS: send this to destination X. The images do not come back on the same association.
- The PACS must know the destination: AE title, IP address and port are set in the PACS node list. Unknown means
A801. - The PACS acts as Storage SCU on a different association: it reuses a compatible one to the destination or opens a new one. The destination must accept it as Storage SCP.
- The requester only gets
C-MOVE-RSPmessages with counts: optionalFF00responses while running, then0000,B000or a failure at the end. - C-GET returns images on the same association. It needs no destination or inbound port, but few PACS support it well. DICOMweb (WADO-RS) is the modern HTTP alternative.
The 7 steps in plain text
C-MOVE-RQ with a Move Destination
On an association already opened with a Retrieve SOP Class, the requester sends the C-MOVE request. It carries the AE title of the destination, and an identifier that selects what to move, usually a StudyInstanceUID found with C-FIND.
Why: The request names the receiver by AE title only. The requester does not tell the PACS where the destination is on the network. That is the PACS's job.
The PACS looks up the destination
The PACS searches its list of known DICOM nodes for DEST_AE, to learn its IP address and port. It also collects the instances that match the identifier.
Why: This is the most common cause of failed moves. If the PACS does not know the AE title, nothing can be sent and it answers with a failure.
Association from the PACS to the destination
The C-STORE sub-operations never run on the association of the C-MOVE. PS3.4 says the PACS shall either reuse an established and compatible association to the destination, or establish a new one, acting as Storage SCU and proposing the storage SOP Classes of the images it is about to send. The destination accepts as Storage SCP. A sub-operation counts as failed if no suitable presentation context can be negotiated for an image.
Why: This second association is why the destination must be listening on its own DICOM port, and why firewalls and NAT can block a C-MOVE that a plain C-STORE would not.
C-STORE sub-operations
The PACS sends the images one by one as C-STORE requests with their data sets. These are called sub-operations because they are performed on behalf of the C-MOVE.
Why: Retrieval reuses the storage service. It is not a separate protocol for moving images.
C-STORE-RSP from the destination
The destination answers each image with a C-STORE-RSP. The PACS counts the successes, warnings and failures.
Why: The requester never sees these responses. It only learns about the result through the counts the PACS reports back.
C-MOVE-RSP Pending with progress
While it works, the PACS may send C-MOVE-RSP messages with status Pending to the requester, with the current counts. Pending responses are optional for the SCP. This is what a progress bar in a viewer is built on.
Why: The requester needs to know when to stop waiting and whether anything failed, without ever touching the images.
Final C-MOVE-RSP
When no sub-operations remain, the PACS sends the final response. Success (0000) means every sub-operation succeeded. Warning (B000) means some succeeded and some failed or had a warning, or that all had a warning. Failure means all of them failed. The counts say how many, and for a warning or failure the identifier lists the failed SOP Instance UIDs.
Why: Success on the C-MOVE depends on the C-STORE results at the destination. A "successful" move that arrived empty is usually a destination or matching problem and is visible in the counts.
Common questions
What is a DICOM C-MOVE?
A Query/Retrieve service that instructs the SCP (the PACS) to send images to a named destination AE. The PACS performs C-STORE sub-operations to that destination, as Storage SCU, over a different association than the one carrying the C-MOVE, and reports the outcome to the requester with C-MOVE-RSP messages.
What does "move destination unknown" (A801) mean?
The PACS has no entry for the Move Destination AE title in its list of DICOM nodes, so it does not know where to send the images. Add the destination (AE title, IP address, port) to the PACS configuration. The AE title in the request must match exactly.
The move says success but nothing arrived. Why?
Look at the counts. Zero sub-operations means the identifier matched nothing (for example a wrong StudyInstanceUID or level). If the counts show failures, check the destination: it must be running, accept the PACS AE title as caller, and support the SOP Classes. Also check firewalls from the PACS to the destination port.
What is the difference between C-MOVE and C-GET?
With C-MOVE the PACS sends images to a destination over a different association (reused if one is open, otherwise new). With C-GET the PACS sends the C-STORE sub-operations over the same association as the request, so the requester must propose the storage presentation contexts, acting as Storage SCP, when it opens the association. C-GET works through firewalls and NAT, but it is less widely supported and less often used than C-MOVE.
Can the requester and the destination be the same device?
Yes, and it is the usual case for a workstation: it asks for a study to be sent to itself, and listens on its own AE title and port. Then the "destination" is simply the requester, as seen from the PACS node list.
Why does my C-MOVE work from one workstation but not another?
The PACS looks up the destination AE title in its own list. A new workstation must be added there, with the right IP address and listening port, even if the workstation itself could already query the PACS.