Routes

A route sends the instances of one source to one or more destinations. Configuration › Routes.

First match wins

Routes are checked top to bottom, and an instance goes to the destinations of the first route whose source accepts it. Put specific routes above general ones:

Order	Route	Source	Destinations
1	CT to PACS and AI	CT1, header Modality Equals CT	PACS, AI service
2	Everything from CT1	CT1	PACS

Here CT images go to both destinations, and anything else CT1 sends (dose reports, secondary captures) to the PACS only. Move routes up and down with the arrows on the routes list; every node picks up the new order within seconds.

To send one instance to several places, list several destinations on one route; routes do not combine.

Priority

A route can be High (its instances are sent before everything else queued for a destination) or Low (sent when nothing else waits). Optionally, instances the sender marks HIGH in its C-STORE request count as high priority. The priority is kept across restarts, retries and group failover, and passed on in each C-STORE.

Waiting for the whole study

Wait for the whole study holds the route’s instances until no new instance of the study has arrived for the quiet time (default 60 s), or for the maximum hold (60 minutes) at most, then sends the study as a whole. Destinations, and group members, are chosen at that moment.

• Study conditions look at the whole study: it is sent only if at least one instance meets all of them (any series whose SeriesDescription contains AXIAL, say), and optionally only if it has a minimum number of instances.
• A study that does not qualify is recorded as filtered in the history and kept in the resend cache, so it can still be sent by hand.
• Held studies are kept on the node’s disk and survive restarts. Instances that arrive after the release start a new hold.
• An instance without a Study Instance UID cannot be grouped, and is sent at once.

Holding suits destinations that want complete studies: AI services, outside readers, and routes with study conditions.

Prior studies and reconciliation

• Prior studies: when a new study arrives, fetch the patient’s relevant earlier studies from the archives and send them along.
• Patient reconciliation: check each study’s patient against its order, and hold those that do not match.

Active hours

A route can apply only at certain times: Active hours in its editor lists periods (days of the week, and a start and end time; a period that ends before it starts runs past midnight), by each node’s local time. Outside them the route is skipped, and instances go on to the routes below it. The routes list marks such routes Hours.

Example: after hours to a teleradiology service. Two routes for the same source:

1. After hours, to the teleradiology destination, with the periods 19:00–07:00 (every day) and Sat, Sun 07:00–19:00;
2. Daytime, below it, to the local reading destinations, with no hours.

Weekday studies arriving between 07:00 and 19:00 go to the daytime route; the rest go to the teleradiology service.

Hours are checked when a sender connects, and again for each instance. A sender that connects when no route of its source applies is refused, and tries again later, as senders do. The route tester explains a route that is outside its hours (at the central server’s time), and the dry run tries such routes both in and outside their hours.

The route tester

Configuration › Route tester takes a sender (calling and called AE titles, address, port) and, optionally, header values, and shows which route would take the instance, which source decides its transfer syntaxes, and why every other route did not match. It uses the saved configuration.

Changes take effect at once

Every change reaches every node within about two seconds, without a restart: new routes and edits apply from the next instance; destinations whose address changed reconnect, keeping their queues. Configuration › Version history keeps every change, to compare or restore.

Seeing what a change would do

What would this change? in the source, destination and route editors replays recent traffic through the configuration with the change, without saving it. It lists each sender (AE titles, address, modality) whose instances would go to another route or other destinations, or be refused or accepted where they were not, with how many instances and studies that was over the last day, 7 days or 30 days. Where the route and destinations stay the same but what they do changes (a destination’s address, a source’s modifications), the sender is listed with what was edited. Nothing is sent, and nothing about patients is shown.

A route’s Position in its editor (first, before another route, or last) is replayed too, so a new route meant to catch some of another route’s traffic can be checked in the place it will go. Saving moves it there.

The same comparison is on the test page (what the changes under test do) and in the restore dialog of Version history (what restoring a version would do).

The history keeps who sent each instance and its modality, not every header value:

• A route condition on another element (body part, station name…) is tried both ways. A sender that would be handled differently only one way is listed as may be handled differently, naming the condition.
• The port an instance arrived on is not kept either. Where a source asks for a port, each port the router listens on is tried the same way.
• Scripts are not run: a changed script is named, not replayed.

Testing changes on a node first

To try changes before every node gets them, start a test under Configuration › Test on a node and choose the test nodes. From then on, what you save goes to those nodes only; every other node keeps the version the test started from. A banner on the Configuration tab says so while the test lasts, and the Nodes tab marks the test nodes.

1. Start the test and choose one node (or a few).
2. Make the changes as usual: routes, sources, destinations, settings. The test page lists everything changed since the test started, and whether each test node runs it yet.
3. Send traffic to a test node. Point one modality at it, or give it an address of its own. Behind a load balancer, only part of the traffic reaches it.
4. Then either:
   • Make live on every node. Every node gets the changes within seconds, and the test ends.
   • Discard the changes. The configuration and alert settings go back to the version the test started from, as a new version, on every node (the test nodes too). As with a restore, passwords entered meanwhile are not undone.

Some things are not held back by a test:

• What the central service does itself follows the changes at once: alerts and reports, HL7 it sends, the worklist.
• Passwords, tokens and keys are the same on every node: a new password for a destination is used everywhere. What the other nodes still use is kept until the test ends, even if the test removes it: a destination’s password, a de-identification key, a patient ID map.

With two-person approval on, making the changes live and discarding them need a second administrator, like any other change. Starting a test and choosing its nodes do not, since they change no node’s configuration.