How to choose a DICOM router

Search for a DICOM router and you will find a dozen products that all describe themselves the same way: receive studies, apply rules, forward to destinations. On that description they are interchangeable. They are not, and the differences tend to appear in the weeks after installation rather than during the demo — when a cloud archive is added, when a modality starts writing a study description nothing recognizes, or when a link goes down for an afternoon.

What follows is a checklist you can apply to any candidate, commercial or open source. It is deliberately not a feature matrix; it is the set of questions that separate a router that moves images from one that holds an imaging network together.

What every router does

Start by discounting the things that are table stakes, because vendors lead with them and they tell you nothing. Any serious DICOM router receives over C-STORE, matches studies against configurable rules, forwards to one or more destinations, and supports query and retrieve with C-FIND and C-MOVE. If a product cannot do those, it is not a router. If it can, you have learned only that it qualifies for consideration.

The useful questions are about the edges: what it accepts beyond classic DICOM, what it knows besides the pixel data, what it can repair, and how it behaves when something is unavailable.

Does it reach the cloud?

This is the fault line in current products. A router written for an all-on-premises world speaks classic DICOM to classic nodes. A Google Cloud Healthcare DICOM store, an Azure DICOM service, or a generic DICOMweb endpoint is not a classic node — it speaks STOW-RS, QIDO-RS, and WADO-RS over HTTPS, behind cloud authentication that has to be obtained and refreshed.

Ask specifically whether the router can store to and query from a cloud DICOM store, not merely whether it "supports DICOMweb" — those are different claims, and one-way upload is common. It matters even if you are fully on-premises today, because the migration is the moment you will want the router to write to both the old archive and the new one simultaneously. That is a configuration change in a router that can do it, and a procurement cycle in one that cannot.

Does it understand orders?

Most DICOM routers see only what the modality sent. But a great deal of what you want to decide depends on information that lives in the HL7 order rather than the image header — which facility the exam belongs to, which reading group should get it, whether the patient has priors worth fetching, what the exam was actually ordered as.

A router that ingests HL7 ORM and ORU can use that context in its rules. One that does not forces you to solve the same problems with a separate interface engine, and then to keep two rule sets in agreement — which is where routing logic quietly drifts apart over a couple of years. If a candidate ignores HL7, ask what else in your stack will have to absorb that work. Bridging the two is the reason RadFuzion is described as a DICOM router with an HL7 brain.

Can it fix data in flight?

Imaging metadata arrives imperfect and it always will. A technologist keys the wrong MRN. A modality writes CHEST where the RIS expects XR CHEST 2V. An outside study comes in with an accession that collides with yours. A scanner produces Enhanced multi-frame objects your archive cannot read.

A router positioned between the modality and everything downstream is the natural place to correct all of that, and the question is how much of it the product will actually do: tag coercion and remapping, study merge and split, UID normalization, transfer-syntax conversion, de-identification. Ask whether corrections can be automatic — expressed as a rule that runs every time — rather than a manual tool someone has to remember to open. RadFuzion handles the recurring cases by rule and the one-off cases with a tag editor that also reaches studies already in the cloud.

What happens when something breaks?

Demos happen on healthy networks. Production does not. The most important behavior in a router is what it does when a destination stops answering — and it is the hardest thing to evaluate from a brochure.

The answer you want is that the router keeps accepting studies, stores them, retries on a sensible schedule, and drains the backlog automatically when the destination returns, with the modality having seen a successful send throughout. The answers you do not want are that forwarding fails outright, that studies queue on the modality, or that recovery requires someone to re-send by hand the next morning. Ask what the retry schedule is, how long studies are held, and what an operator sees while a destination is down.

Ask the same question about the reading room. If the archive is unreachable for an afternoon, does anything let radiologists keep working? That capability usually lives outside the router — but a router already holding recent studies locally is well placed to provide it, which is how downtime reading works in RadFuzion.

Can you test a rule before it goes live?

Routing rules are production configuration with clinical consequences. A mistake does not throw an error; it silently sends studies somewhere wrong, or nowhere, and you find out when someone cannot locate an exam.

So ask whether rules can be evaluated without forwarding anything: given this accession, or this hypothetical set of tags, which rules match and where would the study go? A product that can answer that lets you change routing on a live system with confidence. A product that cannot means every rule change is tested in production on real patients' studies. This is one of the least-marketed and most valuable capabilities in the category.

Open source or commercial?

Open-source DICOM tooling is genuinely capable, and for a single-purpose job — a store-and-forward hop, a test node, a research pipeline — it is often the right answer. The honest trade-off is not capability but ownership: you are accepting responsibility for integration, upgrades, security patching, and being the person who debugs it at 2 a.m. when studies stop flowing.

That is a reasonable trade if you have the in-house expertise and the imaging network is small enough to hold in one head. It becomes a poor one when the router is load-bearing across multiple sites, when downtime has clinical consequences, or when the person who configured it leaves. Judge it as a staffing decision rather than a licensing one — and be realistic about who covers it when they are on holiday.

The evaluation checklist

Condensed to the questions worth asking every candidate:

• Can it store to and query from cloud DICOM stores, or only classic DICOM nodes?
• Can it ingest HL7 orders and use them in routing decisions?
• Can it correct tags, merge and split studies, and transcode in flight — by rule, not by hand?
• What happens to studies when a destination is unavailable, and how do they recover?
• Can a rule be tested against a real study without forwarding it?
• Can one study go to several destinations at once, including during a migration?
• Is there an audit trail of what was routed, changed, and by whom?
• How is it managed across multiple sites — one console, or one install per site?
• Who is responsible when it stops working at 2 a.m.?

Most products answer the first few well. The ones worth shortlisting answer all of them — and the last question is the one people skip and later regret. If you want to work through the list against a running system, the live preview has rule-based routing, cloud destinations, tag editing, and rule testing on sample studies, with no signup.