The DICOM Routing Loop That Paralyzed a Regional PACS

A PACS rarely crashes with a bang. It chokes quietly. A study arrives, gets forwarded, gets accepted, gets forwarded again—and by the time anyone notices, the storage volume is full of duplicate CT slices nobody ordered, the network pipe is saturated, and three radiologists are staring at a viewer that will not load.

The culprit is often not ransomware or a failed disk. It is a DICOM routing loop: a failure that hides inside a perfectly normal-looking routing table until the same object begins circulating through the imaging network. The infrastructure continues to behave exactly as configured. That is what makes the incident so difficult to stop.

The vendor pitch for any enterprise imaging platform promises seamless interoperability. What lands in the data center is usually a patchwork of routing rules layered over time by successive administrators, each of whom inherited a table they did not fully audit before editing it. The loop is not necessarily a software bug. It is an emergent property of configuration, trust relationships, and forwarding behavior. When it fires, the postmortem often blames the wrong thing: the network, the viewer, the archive, or the modality that happened to generate the first visible error.

The Mechanics of Infinite DICOM Loops: How Routing Rules Fail

A DICOM transfer does not depend on a universal three-field formula. An association is negotiated through several pieces of information and policy: the calling and called Application Entity Titles, network addressing, transport parameters, supported presentation contexts, proposed and accepted transfer syntaxes, authentication or access controls where implemented, and the service-specific behavior expected by both systems.

The AE title, IP address, and port still matter. They are often the first things administrators check because they are visible, concrete, and easy to compare. But a successful association also requires the two systems to agree on what they are trying to do. The SCU proposes abstract syntaxes and transfer syntaxes; the SCP accepts or rejects the proposed presentation contexts. A connection can reach the right host and port and still fail because the calling AE is not recognized, the called AE is wrong, the requested SOP Class is not supported, or the systems have no compatible transfer syntax.

That distinction matters when diagnosing a routing loop. A rejected association is not proof that the routing logic is safe. It may simply mean that one leg of a circular path is failing noisily while another leg continues to accept and forward objects.

A DICOM router is, functionally, a rules engine wrapped around one or more DICOM services. It listens for incoming associations, negotiates the requested operations, and forwards selected objects to downstream destinations based on conditions such as:

• modality and sending AE title;
• study or series description;
• body part and procedure information;
• institution, site, or department;
• SOP Class UID;
• patient or accession metadata;
• destination availability and routing priority.

Each rule is a small piece of conditional logic. Every incoming object, study, or operation is evaluated against that logic. The danger is not simply that two rules exist. The danger is that their combined behavior is not obvious when read one rule at a time.

Consider a new MRI scanner in Building C. An administrator adds a rule that sends its studies to an AI service. An older rule already sends all MR studies to the enterprise archive. That overlap may be harmless if the router treats the destinations as independent and the receiving systems do not forward the objects. It becomes dangerous when the AI service forwards completed studies to the archive, while the archive or an adjacent router has a broad rule that sends incoming MR objects back toward the AI service.

Now the same study has two legitimate-looking paths. The archive sees an object that matches its general MR rule. The AI service sees an object that matches its own forwarding condition. Neither component necessarily knows that the object has already passed through the other. Unless the systems preserve routing history or enforce a hop limit, the object can be accepted and retransmitted repeatedly.

The loop may operate at study level, series level, or object level. It may affect only a new research object type or every image from one modality. It may also remain dormant until a particular combination of metadata appears. A rule based on modality can behave safely for ordinary CT images and become circular when a segmentation object, structured report, or secondary capture image enters the same path.

The services involved also change the symptoms:

• C-STORE carries the actual object transfer and is the most direct vehicle for repeated image forwarding.
• C-FIND can create repeated query traffic against a worklist, archive, or other Query/Retrieve SCP when a routing or orchestration layer keeps reissuing the same request.
• C-MOVE combines a Query/Retrieve request with subsequent C-STORE sub-operations, creating more than one association path to inspect.
• C-GET retrieves objects over the existing association rather than using the separate move-destination pattern, so its failure signature is different.
• C-ECHO is a connectivity check, not an image-forwarding mechanism, but repeated health checks can add noise and consume association capacity when a misconfigured component treats failure as a reason to retry without restraint.

The protocol does not create the underlying configuration error. It determines how that error becomes visible: duplicate objects, association storms, repeated queries, incomplete moves, or a combination of all four.

A routing loop does not announce itself. It makes the network slow, then the storage slow, then the radiologist slow—and by then, the damage is already operational.

The fastest way to understand a suspected loop is to stop thinking in terms of isolated devices. Draw the actual path of an object through the environment, including every router, archive, AI endpoint, research node, and failover destination. Then ask a less comfortable question: if this destination receives the object, what can it do next?

That second step is where many investigations stop too early. A routing rule that looks one-way in the source system can become circular when the destination has its own forwarding behavior.

Anatomy of a PACS Crash: Bandwidth Saturation and Association Errors

What the on-call administrator sees first is not the loop itself. It is the symptom layer.

C-FIND queries begin timing out. C-MOVE requests return incomplete results. Studies appear in PACS with repeated series or duplicate SOP Instance UIDs. A modality reports DICOM association failures. The viewer opens slowly, then fails to retrieve priors. A router’s queue grows faster than it drains. Storage alerts arrive after the network alerts because the storage system is often the second place where the loop becomes impossible to ignore.

Association logs are especially useful because they show which leg of the process is failing. A message such as CallingAENotRecognized generally means the receiving SCP does not recognize the calling AE as an allowed peer. That can indicate a missing registration, a typo, a stale configuration, or traffic arriving at the wrong endpoint. It does not by itself explain why the object was sent there. The routing decision must be traced separately.

Other association-level clues include:

• a called AE title rejected even though the IP address is reachable;
• presentation contexts refused because the destination does not support the requested SOP Class;
• transfer syntax negotiation failures after the TCP connection succeeds;
• repeated association attempts from the same AE at short intervals;
• C-STORE responses indicating temporary or permanent failure;
• C-MOVE responses reporting failed, warning, or remaining sub-operations;
• multiple destinations receiving the same object within a narrow time window.

Bandwidth saturation is the visible damage. A large CT or MR study forwarded across several network segments can consume significant capacity even when each individual transfer appears ordinary. Repetition multiplies the load. When the loop touches more than one modality—CT slices, MR volumes, ultrasound cine loops, PET data, or derived objects—the storage and bandwidth impact compounds quickly.

The router continues accepting associations because that is what it has been configured to do. The receiving system may continue acknowledging objects because, from its own perspective, each object is valid and the sender is authorized. A valid SOP Instance UID does not automatically tell every component that the object has already passed through that component. DICOM provides identifiers and service semantics; it does not, by itself, impose a universal enterprise-wide loop-prevention policy.

The hidden damage is the loss of trust in the system.

Radiologists do not know why the viewer is sluggish. They assume PACS is down again. Referring clinicians cannot tell whether a missing study is delayed, rejected, or simply hidden among duplicates. Research teams may find that derived objects are delayed behind clinical traffic. The reading-room conversation shifts from the quality of the images to whether anyone can trust the archive.

That cost does not always appear in the technical postmortem. It appears in delayed reads, repeated support calls, manual reconciliation, and the next conversation about whether the imaging platform is reliable enough for the next integration project.

The timestamp sequence is often more informative than a single error code. If the same SOP Instance UID appears at the archive, AI endpoint, and router within a repeating interval, the pattern points toward forwarding behavior. If the object appears once but the association is retried repeatedly, the issue may be acknowledgement handling, timeout configuration, or a destination that accepts the connection but fails during storage.

That distinction prevents a common mistake: treating every repeated transmission as proof that the sender is malfunctioning. The sender may be retrying because the receiver is not returning the expected status, or because an intermediate router is generating a new delivery request after the original transfer has already succeeded.

Validating AETs and SCP/SCU Handshakes to Prevent Circular Traffic

Most loop incidents come back to the same root cause: someone added a routing rule without verifying what the existing rules already did. The fix is not exotic. It is tedious, and it lives in the part of the configuration that nobody wants to maintain—the AE title registry, peer definitions, route history, and change record.

AE titles should be treated as identifiers with operational meaning, not as decorative labels. A title may identify a modality, a router listener, a PACS service, a failover node, or a logical destination. Confusing a physical host with a logical AE is a reliable way to create misleading troubleshooting data. Two systems can also be network-reachable while still being unable to negotiate a usable association because their AE configuration or supported presentation contexts do not align.

C-MOVE deserves special attention because its data path is easy to describe incorrectly.

In a C-MOVE transaction, the requesting SCU asks a Query/Retrieve SCP to retrieve matching instances and specifies a Move Destination AE. The Query/Retrieve SCP then performs C-STORE sub-operations to that named destination AE. In practice, it establishes a separate association to the Move Destination’s DICOM Storage SCP, using the destination AE’s configured network location and negotiated presentation contexts. The destination is not simply receiving data over the original C-MOVE association, and the Query/Retrieve SCP is not necessarily opening a connection back to the original requesting SCU.

That creates at least two relationships to validate:

1. The requesting SCU must be allowed to issue the C-MOVE request to the Query/Retrieve SCP.

2. The Query/Retrieve SCP must be able to resolve and reach the specified Move Destination AE and send it the requested objects through C-STORE.

If the Move Destination is unknown, unreachable, incorrectly registered, or unable to accept the relevant SOP Classes, the C-MOVE may report failed or warning sub-operations. If a routing layer reacts to that failure by sending the request or retrieved objects toward a fallback destination, the original association problem can become part of a circular traffic pattern.

A reasonable pre-deployment review before adding a routing rule should cover more than a ping and a test image:

• Audit the existing rules. List every rule that can match the same modality, AE pattern, study description, body part, site, or object type. The overlap is where the loop starts.
• Verify AE title ownership. Each logical AE should have a clear owner, purpose, listener, and destination role. Document whether it is an SCU, an SCP, or both for the service in question.
• Check peer registration at every hop. A downstream SCP must explicitly recognize the upstream calling AE. For C-MOVE, also verify the Move Destination AE in the Query/Retrieve configuration.
• Compare negotiated capabilities. Confirm that the relevant SOP Classes and transfer syntaxes are accepted by the destination. A network connection alone is not a DICOM interoperability test.
• Inspect retry behavior. Set bounded retries and meaningful backoff. A failed store should not trigger an unlimited series of immediate reattempts.
• Test one study and trace it. Use a controlled study with known identifiers. Observe the original association, every forwarding association, the response status, and the final location of each object.
• Test failure paths deliberately. Temporarily make a destination unavailable or reject a selected SOP Class. Confirm that the router quarantines, alerts, or stops rather than forwarding blindly to another destination.
• Review the route after deployment. A successful test proves only that one path worked. It does not prove that a later failover, duplicate rule, or new derived object cannot create a cycle.

In DICOM, a reachable endpoint is not necessarily a valid peer, and a valid peer is not necessarily a safe destination.

The registry should also record who is permitted to send what. A PACS may accept CT and MR images from a modality but not structured reports from a research service. An AI platform may accept native images and return derived segmentations, but it should not automatically become a general-purpose forwarder for every object it receives.

This is where many pacs dicom integration errors become routing errors. The initial failure is an interoperability mismatch. The response is an overly broad fallback rule. The fallback sends the object to a system that generates another response or forwarding event. The environment then treats the secondary behavior as a new problem instead of recognizing the original design flaw.

Architecting Loop-Prevention: Implementing Strict Routing Logic

Vendors will tell you that their routing engines have loop detection. Some do. The protection may be a hop counter, a time-to-live value, a routing-history field, a duplicate-object check, or a destination-specific delivery ledger. These controls are useful, but they are not interchangeable.

A local hop counter cannot reliably prevent a loop that crosses multiple routing engines unless the relevant state is preserved across those engines. One system may record that an object has passed through it while another creates a fresh forwarding event without seeing that history. A time-based expiry can stop an object eventually, but it may still allow a damaging burst of duplicate traffic before the expiry takes effect. A duplicate check may suppress identical SOP Instance UIDs while allowing transformed or regenerated objects to circulate under new identifiers.

The safest design is to make the routing logic loop-free by construction and use automated detection as a second line of defense.

Separate clinical destinations from processing destinations

A clinical archive, a diagnostic viewer, an AI service, and a research repository do not have the same role. They should not be treated as interchangeable nodes in a general forwarding mesh.

A modality may send a native study to PACS and to an approved AI endpoint. The AI endpoint may return derived objects to PACS. That does not mean PACS should forward every derived object back to the AI endpoint. The return path needs its own explicit condition, usually based on source AE, object type, series description, or a reliable processing marker.

The more destinations a single rule includes, the harder it becomes to understand the resulting graph. Separate routes make ownership and failure behavior visible.

Prefer explicit routes over broad catch-alls

Dynamic discovery is attractive in theory. In a regional imaging environment with a relatively stable topology, explicit configuration is usually easier to audit.

A rule that says “send MR from this scanner to the archive” is already broad. A rule that says “send everything from any recognized MR AE to every available destination” is an invitation to future ambiguity. New scanners, new derived objects, and new research services will eventually match it.

A safer route identifies the source, object class, intended destination, and permitted action. Unknown combinations should be held for review or rejected with an actionable log message. They should not fall through to a catch-all destination simply because the system needs somewhere to put them.

Make one destination the result of one decision

One destination per condition is not always possible, but it is a useful default. If a study must be sent to several systems, represent those deliveries as separate, documented routes rather than as hidden side effects of overlapping conditions.

For example, a rule for an MR scanner can send the original objects to PACS. A separate rule can send only eligible native series to an AI service. Another rule can accept only the AI service’s derived objects back into PACS. Each path has a defined direction and a defined object scope.

That structure makes a circular path easier to spot during review. It also makes it possible to disable one integration without stopping every other delivery.

Enforce a deny-by-default policy for unknown peers

If a router receives a study from an AE title that is not explicitly trusted, it should not forward the object to a default destination merely because the metadata looks familiar. The system should reject, quarantine, or hold the object according to the organization’s operational policy, and it should produce a log that identifies the source and reason.

This is especially important in environments with duplicated vendor appliances, cloned virtual machines, and failover nodes. A copied configuration can create an apparently legitimate AE title at an unexpected address. Without strict peer validation, the router may accept traffic from the wrong node and make the resulting loop look like a modality problem.

Use route history and bounded retries

Where the platform supports it, preserve forwarding history or another reliable marker that allows downstream components to identify an object’s prior route. Do not assume that a vendor’s internal hop counter will survive every transformation or handoff.

Retry behavior should also be bounded. A transient destination outage needs a retry schedule and an escalation path. It does not need an unlimited stream of immediate associations. Exponential backoff, queue limits, circuit breakers, and quarantine queues are not glamorous features, but they determine whether a small integration fault remains small.

Put routing changes under change control

Every route change should have:

• a stated source and destination;
• the SOP Classes and metadata conditions in scope;
• an identified owner;
• a test case;
• a rollback plan;
• an observation window;
• a record of the resulting logs and queue behavior.

The reviewer should not be the person who wrote the rule. A second set of eyes is valuable because routing logic is full of assumptions that look obvious to its author and invisible to everyone else.

Loop prevention is not a single feature. It is a discipline applied across topology, configuration, logging, and operations. The discipline is the part of enterprise imaging that does not ship in the box.

SOP Class UID Management and the Risks of Automated Forwarding

The SOP Class UID is one of those DICOM fields that everyone knows exists and almost nobody audits until an integration breaks. It identifies the type of composite or normalized object being handled: a CT image, an MR image, an ultrasound object, a PET image, a segmentation, a structured report, or another defined DICOM object class.

The UID is not the entire story. Transfer syntax, implementation behavior, required attributes, and destination support also matter. But the SOP Class UID is a critical routing signal because it tells the receiving system what kind of object it is being asked to store or process.

The problem with automated forwarding is that a rule often does not inspect the SOP Class UID at all. It looks only at modality, calling AE, or study description. That can work while every sender produces the same familiar image objects. It becomes fragile when a scanner begins sending a new object type, when an AI pipeline returns derived findings, or when a research workflow introduces segmentations and structured reports.

A radiotherapy plan or segmentation object may satisfy a broad “send all MR” condition even though the downstream viewer or archive component handles it differently. The receiving system may reject it, accept it with a warning, place it in a non-displayable area, or retain it without the metadata that the next processing step expects. None of those outcomes should be described as an automatic conversion into a default class. DICOM does not provide a universal fallback that silently changes an unsupported object into a different SOP Class UID.

The operational risk is still serious. If the sender interprets a failed or incomplete response as a reason to retry, and a router interprets the same event as a reason to forward elsewhere, the original SOP Class mismatch can help produce a traffic storm. The loop is created by the surrounding automation, not by the UID itself.

Practical rules for SOP Class UID handling include:

• Match SOP Class UID explicitly when the destination is type-specific. A PET workstation should not receive MR segmentations merely because a modality rule fired.
• Maintain an acceptance matrix. Record which SOP Classes each modality, router, archive, AI service, and research system can send, receive, display, or process.
• Quarantine unknown or unsupported objects. Preserve the object and its diagnostic context rather than dropping it without an alert.
• Separate native and derived objects. Segmentations, structured reports, presentation states, and AI findings should have routes appropriate to their lifecycle and intended consumer.
• Review transfer syntaxes as well as SOP Classes. A destination can support the object class and still reject the association or storage operation because the negotiated encoding is not supported.
• Track return paths. If a processing system sends derived objects back to PACS, ensure the inbound route does not match the rule that originally sent the native study to processing.
• Inventory actual traffic. Compare the SOP Classes emitted by each source with those documented in the integration specification. New object types often appear before anyone updates the routing table.

The distinction between image ingestion and image processing is important here. A PACS may be able to store an object without presenting it correctly in the diagnostic viewer. An AI service may be able to parse a CT series but not a secondary capture or a structured report. A research repository may preserve an object faithfully while offering no clinical workflow for it. “Accepted” is not the same as “usable,” and “stored” is not the same as “routed safely.”

Reading the Logs as a Graph, Not a List

A conventional incident review starts with the first error in a log. That is often the wrong starting point. In a routing incident, the first visible error may be downstream of the configuration change that created the cycle.

Build a timeline around identifiers:

1. Select a study, series, or SOP Instance UID that appears to have been duplicated.

2. Find every association involving that identifier or its related accession and study metadata.

3. Record the calling AE, called AE, source address, destination address, operation type, response status, and timestamp.

4. Group the events by route rather than by device.

5. Look for a repeating sequence in which the object returns to a system it has already visited.

6. Compare the same sequence for an object that completed normally.

This approach distinguishes a true dicom auto routing loop from a simple retry storm. A retry storm may show one sender repeatedly attempting one destination. A loop shows an object or request moving through multiple destinations and returning to an earlier point. The difference determines the containment action.

Containment should be deliberate. Disabling the most permissive forwarding rule is often safer than shutting down every DICOM listener, but only if the team knows which rule is responsible. If that is unclear, isolate the suspected processing or failover destination, cap queues, and protect the archive from further writes while preserving logs. Do not delete duplicate objects during the active incident unless the organization has a tested reconciliation process. The duplicates may be the evidence needed to reconstruct the path.

After the loop is stopped, check for partial studies and failed sub-operations. A routing loop can create an archive full of complete duplicates while also leaving other studies incomplete because the association backlog prevented normal traffic from being serviced. Restoring free space does not restore workflow integrity.

The Cost of “Just One More Rule”

Regional PACS networks do not collapse because of one dramatic failure. They collapse because routing decisions accumulate under time pressure, by people who did not have time to test them, in an environment where the cost of a loop is paid by the next shift.

The pattern is familiar. A new scanner needs a destination. A temporary AI integration needs a copy of the study. A failover archive is added after an outage. A research group asks for derived objects. Each request is reasonable in isolation. The routing table becomes unreasonable as a system.

That is why radiology workflow optimization issues often turn out to be configuration-governance issues. The network may have enough capacity under normal traffic. The PACS may have enough storage under normal retention. The viewer may be perfectly healthy. The failure emerges only when several valid rules interact and no component has a complete view of the resulting route graph.

The fix is not automatically a new vendor product or a more elaborate anomaly detector. Detection helps, especially when it exposes repeated SOP Instance UIDs, unexpected fan-out, queue growth, or a rising association rate. But detection does not replace design. The durable controls are less exciting:

• an authoritative AE title and peer registry;
• explicit route ownership;
• SOP Class-aware forwarding;
• bounded retries and queue protection;
• preserved routing history where supported;
• tested failover behavior;
• review of overlapping rules;
• change control with rollback;
• alerts that name the source, destination, operation, and object type.

A useful postmortem should answer more than “which device failed?” It should answer:

• Which rule first allowed the object to leave its intended path?
• Which destination accepted and retransmitted it?
• Why did the next component consider the retransmitted object eligible?
• Which response status or timeout triggered the retry?
• Why did loop prevention not stop the cycle?
• How will the same object type behave after the next integration is added?

The radiologist in the reading room does not care about routing tables. They care about whether the next study loads and whether the prior examination is available when the report is being written. The IT administrator does not care about routing tables either—until the day they care about nothing else.

Build the routing architecture as if you will be the person paged at 2 a.m. when it goes wrong. That means treating every new forwarding rule as a change to a networked workflow, not as a harmless line in a configuration screen. A DICOM association can be perfectly valid and still be part of an invalid route. A destination can accept an object and still send it somewhere it should never go.

The most resilient PACS is not the one with the most automation. It is the one whose automation has clear boundaries, visible assumptions, and a reliable way to stop.