DICOM Assist

Remote Gateway

Connect a site without asking for a firewall exception

The part of a connection project that stalls for weeks is rarely the DICOM. It is the inbound rule. The Remote Gateway removes the request.

How it works

Outbound-only, spooled, and routed by the same rules

  1. Receive locally

    The gateway runs a DICOM listener at the remote site. Modalities send to it exactly as they would send to any local node.

  2. Spool to disk

    Every instance is written to a durable local spool before it is acknowledged, so a link outage delays delivery instead of losing studies.

  3. Relay outbound

    The gateway dials your HQ install over mutually-authenticated TLS and uploads asynchronously. The connection is always outbound.

  4. Route at HQ

    An upload enters the same ingest queue as a direct C-STORE and is routed by the same rules, carrying the gateway's AE title so a rule can tell it apart.

What you get

No inbound firewall rule

The gateway opens the connection and HQ never opens one to the site, so there is no port to forward, no inbound NAT entry to publish, and no VPN tunnel to maintain between the two networks. The site's ordinary outbound path is all it uses.

Return traffic rides the same connection

Work going the other way - a study to dispatch to the site's own PACS, a configuration change, a query to run against a PACS only the site can reach - is sent down the long-lived connection the gateway already opened. Nothing at HQ ever dials the site to deliver it.

Managed from HQ

Gateway configuration is authored centrally and delivered to the gateway, so a remote site does not need a local administrator to change a destination.

Local dispatch

Where the recipient is local to the remote site, HQ relays the study back down through the gateway rather than sending it across the link twice.

Standby gateways

A site can name standby gateways, and a retrieve falls to them when the gateway a remote node is bound to cannot carry the work.

Heartbeat telemetry

Each gateway reports its own health on a heartbeat, with bounded local logs, so a site that goes quiet is visible from the HQ console.

De-identification stays at HQ

By design the gateway does not de-identify. There is one implementation with one set of guarantees, and it runs at HQ - including for studies the gateway sent up.

Limits worth knowing

What gateway health does and does not tell you

  • Health is derived from what a gateway reports about itself. A healthy gateway in front of a dead archive still reads as healthy - this is not an end-to-end path check, and we do not describe it as one.
  • A degraded gateway is outranked by a healthy standby, never evicted. If no standby is healthy the work stays where it is, because degradation is inferred and should not take down a path that would have worked.
  • This is failover, not load balancing. A reachable, working binding always wins; traffic is not spread across gateways to share load.

Have a site you cannot open a port into?

Tell us the constraint. Most of the ones we hear are the reason this component exists.

Talk it through with us