The Diagnostic Dilemma That Hides in Your Retrieval Protocol
A neuroradiologist at the satellite site needs to compare today's brain MRI against a scan performed eighteen months ago at the main facility — a scan that exists only on a remote archive behind two firewalls and a network address translation boundary. The query succeeds. The images do not arrive. The status code flashes back: 0xA801, Unknown Destination AE Title. The clinician waits. The patient waits. Somewhere in the architecture of a DIMSE retrieval command, a single network association requirement has turned a thirty-second task into a help desk ticket.
This is not an exotic failure mode. It is the default behavior of one of the two fundamental retrieval mechanisms in the DICOM standard, and understanding why it happens — and what the alternative offers — is essential for anyone designing, maintaining, or troubleshooting enterprise imaging workflows. The difference between C-MOVE and C-GET is not a matter of preference or convention. It is a question of network topology, association management, and whether your imaging infrastructure can tolerate the assumption that every device on the network can accept inbound connections.
The DIMSE Retrieval Paradigm: Two Commands, One Purpose
The DICOM standard defines retrieval through DIMSE-C services, and at the protocol level, both C-MOVE and C-GET accomplish the same clinical goal: they instruct a service class provider — typically a PACS server — to locate matching image instances and transmit them to a storage destination. The query itself uses C-FIND, but once the relevant study or series has been identified, the retrieval step activates one of these two commands, each encoded with a distinct command field value. For C-MOVE-RQ, the tag (0000,0100) carries the value 0021H; for C-GET-RQ, it is 0010H. These are not interchangeable labels. They describe fundamentally different network transactions.
The choice between C-MOVE and C-GET is not about features — it is about which network assumptions your infrastructure can safely make.
What happens after the request is issued diverges sharply. Both commands trigger C-STORE sub-operations to deliver the actual image data, but the path that data travels — and the connections it requires — determines whether the retrieval succeeds or silently fails behind a firewall.
Association Management and Network Topology
This is where the architecture matters most, and where clinical environments routinely stumble.
Under the DICOM standard — specifically PS3.4, Section C.4.2 — every C-STORE sub-operation initiated by a C-MOVE request must execute on a separate association from the one handling the C-MOVE command itself. The PACS receiving the C-MOVE-RQ does not send the images back on the same TCP connection. Instead, it performs a role reversal: the C-MOVE service class provider becomes a C-STORE service class user, opening a brand-new TCP association to a destination application entity. That destination must already be known to the server — its AE Title, IP address, and listening port must be pre-configured in the PACS system.
C-GET operates on an entirely different principle. The requesting client sends the C-GET-RQ on its existing association, and the server performs the C-STORE sub-operations as "turned around" transfers back to the same connection. No new TCP session is initiated. No destination AE Title needs to be registered in advance on the server side. The images flow back on the same channel the request traveled out on.
| Architectural Parameter | C-MOVE | C-GET |
|---|---|---|
| Association for retrieval | Separate, new TCP connection | Same connection as request |
| Role of PACS during transfer | Switches from SCP to SCU | Remains SCP, pushes data back |
| Destination registration | Required (AE Title, IP, port) | Not required |
| Inbound connection to client | Yes — client must listen | No — client already connected |
| Command Field (0000,0100) | 0021H | 0010H |
| NAT / firewall tolerance | Poor | Good |
The implications for network design are substantial. In a controlled local area network where every PACS node sits behind the same perimeter and all IP addresses are statically assigned, C-MOVE works reliably because the pre-configuration overhead is a one-time administrative task, and firewalls between internal nodes are typically permissive for DICOM traffic on port 104 or the alternate port 11112. The moment the retrieval crosses a WAN boundary, a VPN tunnel, or — most commonly in modern hybrid architectures — a cloud-hosted archive, those assumptions dissolve.
The C-MOVE Workflow: Role Switching and Destination Pre-configuration
To understand why C-MOVE fails where network barriers exist, it helps to trace the transaction step by step, because the failure is not in the command itself but in the architectural model it assumes.
When a radiology workstation sends a C-MOVE-RQ to a PACS, it includes the AE Title of the destination where images should be sent — often the workstation itself, or a separate storage node. The PACS receives this request, queries its local database for matching instances, and for each series or instance found, initiates a new outbound C-STORE operation toward that destination. The PACS must know, in advance, that the destination AE Title corresponds to a specific IP address and a port where a listener is actively waiting.
This design emerged in an era when imaging networks were architecturally flat — a departmental PACS serving a handful of modalities and review stations, all on the same subnet, all managed by the same IT team. In that context, registering a few AE Titles with their network coordinates is trivial. The system works precisely because the network is predictable.
C-MOVE was designed for a world where every device on the imaging network was known, reachable, and listening — assumptions that WANs and cloud deployments no longer guarantee.
The role reversal is elegant from a protocol perspective: the PACS becomes the client, driving data toward a waiting server. But this elegance depends on a network condition that is increasingly difficult to guarantee — that the destination can accept inbound TCP connections. In a hospital LAN, this is usually unremarkable. Across a WAN link connecting a clinic to a cloud archive, behind a carrier-grade NAT or a corporate firewall that restricts inbound DICOM ports, the C-STORE sub-operation simply cannot establish its connection. The PACS attempts the transfer, times out or receives a connection refused, and returns a status code indicating the failure. The requesting client sees nothing arrive.
Overcoming Firewall Barriers with C-GET Retrieval
C-GET was not always treated as a first-class citizen in the DICOM ecosystem. For years, many PACS vendors implemented only C-MOVE for retrieval, treating C-GET as optional or omitting it entirely from their conformance statements. This created a self-reinforcing cycle: clients assumed C-GET was unavailable and built workflows exclusively around C-MOVE, which in turn gave vendors little incentive to prioritize C-GET support. David Clunie's clarifications in 2016 helped shift this perception, particularly around C-GET's suitability for wide area networks where the pre-configuration and inbound connection requirements of C-MOVE become practical barriers.
The structural advantage of C-GET across firewalls is straightforward: because the retrieval happens on the existing association, no new inbound connection to the client is required. The client has already established an outbound TCP session to the PACS, and the image data flows back through that same channel. NAT traversal is not an issue because there is no reverse connection to traverse. Firewalls that block unsolicited inbound DICOM traffic are irrelevant because no such traffic is generated.
This does not make C-GET universally superior. In local environments with generous network policies and stable IP assignments, C-MOVE's destination flexibility — the ability to send images to any pre-registered node, not just the requesting client — remains useful. A radiologist at workstation A can retrieve a study and have it routed to a 3D post-processing server at node B, a capability that C-GET does not provide because it returns data only to the requesting entity.
For organizations building or modernizing their infrastructure, the practical guidance is contextual:
1. Campus LAN with static IPs — C-MOVE is well-established and supports routing to arbitrary destinations; use it if your PACS has pre-configured all relevant AEs.
2. WAN retrieval across firewalls or NAT — C-GET eliminates the inbound connection requirement and avoids destination pre-configuration; prefer it for cross-site or cloud-bound workflows.
3. Hybrid deployments — some systems offer DICOMweb (WADO-RS) as an HTTP-based alternative that sidesteps DIMSE association complexity entirely, though its adoption across legacy modalities remains uneven.
4. Vendor conformance verification — always confirm C-GET SCP support in the PACS conformance statement before designing a workflow around it; availability is broader than it was a decade ago but not yet universal.
Consider the implications for a teleradiology practice reading studies from multiple hospital partners. Each partner's PACS may sit behind different firewall policies, different NAT configurations, different IT governance models. Building a C-MOVE workflow requires each partner to pre-configure the teleradiology service's AE Title with its external IP and listening port — and to maintain that configuration as infrastructure changes. A C-GET workflow requires only that the teleradiology client can reach the PACS over an outbound connection, which is typically far easier to arrange with the partner's network security team.
Strategic Implementation in Modern Enterprise Imaging
The trajectory of enterprise imaging platforms points toward protocol flexibility rather than protocol dogma. Modern PACS solutions increasingly support C-GET alongside C-MOVE, and the rise of DICOMweb introduces an HTTP-native retrieval path that works natively across web infrastructure without any DICOM association management at all. The question for clinical architects is not which single protocol to standardize on, but which retrieval mechanism to invoke under which network conditions.
A pragmatic approach looks at the network path between the requesting client and the archive and selects accordingly:
- Same subnet, known destinations, established AE configuration → C-MOVE remains the workhorse, and its destination routing capability is genuinely useful for workflow orchestration.
- Cross-site, cloud-adjacent, or behind NAT → C-GET eliminates the most common failure mode — the unreachable inbound listener — at the cost of limiting data return to the requesting client only.
- Web-native or API-driven integrations → DICOMweb's WADO-RS provides a retrieval method that operates over standard HTTP, inherits the firewall and proxy infrastructure of the web, and requires no DIMSE-level association management at all.
Orthanc's addition of native C-GET SCP support in version 1.7.0 is a meaningful signal: an open-source, lightweight PACS that prioritizes interoperability chose to implement C-GET not as a legacy checkbox but as a functional retrieval path for environments where C-MOVE's network assumptions do not hold. This reflects a broader recognition that the original DIMSE retrieval model was designed for network topologies that no longer describe most real-world deployments.
The subtle degradation of workflow efficiency caused by retrieval failures — the delayed reads, the help desk escalations, the manual workarounds — accumulates over time in ways that are difficult to measure but easy to feel. Every failed C-MOVE attempt is a moment where the clinical workflow pauses, where the radiologist's attention shifts from interpretation to infrastructure troubleshooting, where the promise of seamless image access breaks against a network boundary that someone, somewhere, assumed would not exist.
This shift allows us to think about retrieval not as a fixed protocol choice made once during PACS procurement, but as a dynamic decision embedded in the workflow layer — a decision that adapts to the network path, the destination topology, and the security posture of each individual transfer. The clinicians who depend on imaging access should never need to know which DIMSE command is being used. That invisibility is the goal. It is also, still, the work.