Every AI radiology deployment I have worked on has a component nobody put on the architecture slide, and it is usually the one that decides whether the go-live happens on schedule. It is the DICOM router: the thing standing between the modalities and the engine, quietly deciding which studies get analysed and which never do.
What is a DICOM router?
A DICOM router is a network node that receives imaging studies, applies rules to decide where each one should go, and forwards it on. It is itself an Application Entity with its own AE title, so to every other device on the network it looks like an ordinary destination. In an AI deployment it is the component that decides which studies the engine ever sees.
The vocabulary matters, because the vendor questionnaire will use it. An AE title is the short name identifying a node — up to sixteen characters, case-sensitive, paired with an IP address and a port. An association is the negotiated connection between two AEs, during which they agree which object types and compression formats they will exchange. C-STORE pushes an object, C-FIND queries, and C-MOVE asks a third party to send images to a named destination AE title — which means the destination must already be configured on the system you are asking to do the moving, not on the system making the request. Storage commitment is the receiver formally accepting that it holds the object and the sender may delete its copy. The definitions live in the DICOM standard.
How a study actually reaches an AI engine
A study reaches an AI engine in five steps: the modality finishes acquiring it, a router receives it over a DICOM association, the router evaluates rules against the study's header tags, it forwards a copy to the engine's listener, and the engine returns a result that must be delivered somewhere a clinician will look. Each of those five is a design decision.
1. The modality finishes
DICOM has no "study complete" message. Routers infer completion from a modality performed procedure step, or from a quiet timer after the last instance lands. Timers are simpler and occasionally wrong.
2. The router receives
The modality opens an association and issues C-STORE. If the two ends cannot agree on a compression format during negotiation, the transfer fails here, before any rule is evaluated.
3. The router decides
Rules run against header tags only. Nothing has looked at a pixel yet. This is the entire basis of the decision, and it is thinner than most people assume.
4. The engine receives a copy
A copy, not the original. Where the router sits beside the clinical path rather than inside it, the study still travels to PACS normally, so a failure at the AI end does not delay the read. In-line topologies do not give you that separation — which is one of the costs of routing on receipt.
5. The result comes back
As a DICOM object, an HL7 message, or an API callback. Where it lands is the question most projects answer last and should answer first.
What the router knows when it decides
At the moment it decides, a router knows only what is in the study header — a handful of tags whose reliability varies enormously between hospitals, and between technologists in the same hospital. Rules built on the unreliable ones look correct in testing, because testing uses studies somebody chose, then fail on a real Monday morning.
| Tag | How dependable it is | Use it for |
|---|---|---|
| Modality (0008,0060) | Highly dependable — coded, short list | The first filter in every rule set |
| StationName (0008,1010) | Dependable once your estate is mapped | Targeting one scanner or one site |
| InstitutionName (0008,0080) | Dependable, sometimes blank on older units | Separating sites in a group |
| StudyDescription (0008,1030) | Free text — varies by technologist and shift | Hints, not hard rules |
| BodyPartExamined (0018,0015) | Frequently empty; inconsistently populated | Never as a sole condition |
| ProtocolName (0018,1030) | Consistent within a scanner, not across them | Per-scanner rules only |
| AccessionNumber (0008,0050) | Present when the order came first | Tying results back to the order |
Expert Insight: build on the coded tags, not the typed ones
The most common routing bug I see is a rule matching the word "CHEST" inside StudyDescription. It works until someone types "Chest PA/Lat" with a slash, or the site revises its procedure catalogue. Anchor rules on Modality and StationName, which are coded or configured, and let free text only narrow what those have already selected.
What you should not send to AI
Deciding what to exclude is as much a design task as deciding what to include. The standing exclusions are prior studies pulled for comparison, scouts and dose reports, modalities the engine does not support, and patient ages the model was not trained on. A routing rule is an allow-list with exceptions, not a firehose. Write them down before go-live, because otherwise every one of them is discovered in production.
- Paediatric studies, unless the model was trained on paediatric anatomy. Filter on age, and decide what happens when the age field is empty.
- Scouts, localisers and dose reports — DICOM objects arriving in the same stream that carry nothing diagnostic.
- Prior studies pulled for comparison. Routing these re-processes years of history and can flood you with findings on people not under active care.
- Repeat sends after a correction. A demographic fix often re-sends the study; without a de-duplication window you act on the same analysis twice.
- Modalities the engine does not support, which produce failures rather than refusals, filling logs nobody reads.
De-identification: what has to happen before a study leaves the building
If studies leave your network for a cloud AI engine, de-identification at the router is where the privacy review is either satisfied or lost. Removing the patient name is the easy part. What fails an audit is the identifiers you cannot see in the header, and the pixel data nobody thought to check.
Three hard problems, in the order they bite. Burned-in annotation: ultrasound frames and secondary captures often carry name and date of birth rendered into the pixels, where no tag-based scrub reaches them. Private tags: manufacturers write vendor-specific elements that can carry accession numbers or local identifiers, so a scrub clearing only the standard patient module leaves them intact. And the link back: you still need to re-associate results with the right patient, which means a reversible pseudonym held on your side of the boundary. The DICOM standard publishes confidentiality profiles for this — use them as your checklist. All of it belongs at the router, before the study crosses the boundary, and separate from the archive that stores the images of record.
Four ways DICOM routing fails in production
DICOM routing failures are rarely dramatic. Nothing crashes; studies simply stop arriving, or arrive twice, or arrive with nowhere to go. Four failure modes account for most production incidents — routing loops, duplicate sends, images that land before the order, and results with no destination — and all four are prevented at design time rather than debugged at three in the morning.
The routing loop
The AI result returns as a DICOM object, the router's rule matches it, and it goes round again until someone notices the traffic. Exclude the engine's own AE title and its SOP classes explicitly.
Duplicate sends
An association times out, the sender retries, and one study becomes two analyses and two findings. De-duplicate on study instance UID within a defined window, not on arrival time.
Images before the order
Images land ahead of the worklist entry, so there is no accession number to attach and the result has nowhere to return. DICOM worklist integration closes this gap.
Results with no destination
Nobody decided whether the finding lands in PACS as a secondary capture, in the RIS, or in a separate viewer. It silently lands nowhere, and the pilot is judged a failure.
Router or API: choosing the integration shape
There are two shapes for getting a study to an AI engine. A DICOM router speaks DICOM to a listener, so the engine looks like another node on the imaging network. An API integration means something in the middle converts each study into an HTTP request. Both work, they fail differently, and they need different people to maintain them.
A router is the natural choice when images already move by DICOM and the team maintaining it is the team that already administers PACS. The category runs from commercial routers and integration engines — Laurel Bridge and Mirth Connect are examples people recognise — to open-source projects such as the dcm4che toolkit and Orthanc. An API suits a different situation: Fractify's REST API for developers accepts scans at $0.25 per scan and fits where studies are already handled by an application rather than a modality. It is a clinical decision support tool; a qualified clinician reviews every finding. Fractify also accepts DICOM directly, so the choice is about your estate, not about what the engine will take.
Where I would not put a router
I would not stand up a routing layer for a single-site clinic with one or two modalities and low volume. A router is a service: it needs monitoring, a rule set somebody owns, and a person who can read an association log at eight in the morning. Below a certain volume that overhead costs more than the workflow it saves, and a direct upload path is the honest answer. Count the studies you would actually route in a week, and decide on that number rather than on a diagram.
The remaining question is order of operations. Routing on receipt from the modality gets results to the reader sooner; routing on arrival at the PACS is more reliable, because the study is complete and demographics have usually been corrected. Stroke and emergency pathways generally justify receipt-side routing and its extra failure modes; routine outpatient work generally does not. Decide per pathway, document why, then carry that decision into your hospital deployment plan alongside what the IT team needs before go-live and how AI handles multi-slice CT uploads — before anyone configures an AE title.
Frequently asked questions
These are the questions PACS administrators ask most often when an AI engine is added to an imaging network. They cover what a DICOM router does, how it differs from a PACS, how to send only selected studies, how de-identification works at the routing layer, and where AI results end up once a study has been analysed. The destinations themselves, and what each one costs you, are compared in where AI findings live in a vendor neutral archive.
What is a DICOM router used for?
A DICOM router receives imaging studies from modalities or a PACS, evaluates rules against each study's header tags, and forwards it to one or more destinations. It is used to send selected studies to an AI engine, split traffic between sites, and de-identify studies before they leave the network.
Do I need a DICOM router to use AI on medical images?
No. A router is one of two integration shapes. The alternative is an API integration, where an application converts each study into an HTTP request instead of a DICOM push. A router suits estates where images already move by DICOM; an API suits smaller sites where a routing layer would be overhead.
What is the difference between a DICOM router and a PACS?
A PACS stores studies and presents them for reading, with a viewer, a worklist and long-term storage. A router stores nothing permanently — it receives, decides and forwards. Some products do both, so the useful question is which role a system plays in your network rather than what it is called.
Is there a free or open source DICOM router?
Yes. The dcm4che toolkit and Orthanc are open-source projects that act as DICOM nodes and forward studies, and integration engines such as Mirth Connect and dedicated routers such as Laurel Bridge occupy the same category, with licensing that varies by product and version — check the terms for the release you intend to run. The real cost is rarely the licence but the person who owns the rule set.
How do you route only certain studies to an AI engine?
You write rules against header tags. Anchor them on dependable coded tags such as Modality and StationName, then narrow with free-text tags like StudyDescription only as a secondary condition. Add explicit exclusions for scouts, prior studies pulled for comparison, unsupported modalities, and ages the model was not trained on.
Can a DICOM router anonymise studies before sending them to the cloud?
Most routers can remove or replace identifying tags, and the DICOM standard defines confidentiality profiles describing how. Two things are harder: patient details burned into pixel data on ultrasound and secondary captures, and private vendor tags carrying local identifiers. You also need a reversible pseudonym so results can be matched back to the patient.
Where do AI results go after the study is analysed?
That is a design decision you make before go-live, not something the engine decides for you. The router's job is to deliver the result to a destination somebody has already chosen; when nobody chooses, results land nowhere and the gap is found weeks later. The trade-offs between the possible destinations are set out in our article on where AI findings live.
What is an AE title and why does the AI vendor keep asking for it?
An Application Entity title is the short name — up to sixteen characters, case-sensitive — identifying a DICOM node on the network. The vendor needs yours because a receiving system usually rejects associations from AE titles it does not recognise, and because C-MOVE requests name a destination by AE title rather than address.
See Fractify working on your own scans — live demo takes 15 minutes.
Request a Free Demo →