How do I set up a DICOM router for moving images and metadata between our scanners and PACS?

Setting up a DICOM router is mostly about defining the workflow, then choosing software/hardware that can reliably receive, route, transform, and forward DICOM objects between scanners, PACS, workstations, and possibly archive/VNA systems.

Here’s a practical way to approach it.

---

1) Clarify what you need the router to do

Common DICOM router use cases:

• Forward studies from scanners to PACS
• Send copies to an archive/VNA
• Route based on modality, AE title, study description, accession number, or destination
• Hold-and-forward if PACS is temporarily unavailable
• Anonymize/de-identify for research or teaching files
• Split routing: send images to PACS and metadata-only to another system
• Convert or normalize some DICOM fields
• Support DICOM C-STORE only, or also:
  • C-FIND / C-MOVE
  • Storage Commitment
  • Worklist
  • MPPS
  • DICOMweb if needed

If your goal is simply “move images from scanners to PACS,” a router can be fairly simple. If you need rules, retries, audit trails, or de-identification, choose a more capable product.

---

2) Pick the router architecture

There are three common patterns:

A. Virtual appliance / VM

Best for most hospitals and imaging centers.

• Easier to back up
• Easy to place in a secure VLAN
• Good for redundancy
• Can run on VMware/Hyper-V/Proxmox

B. Physical appliance

Useful if you want vendor support and simpler maintenance.

• Often easier to certify
• Less flexible
• Hardware refresh depends on vendor

C. Software service on a hardened server

Common when using open-source or custom solutions.

• Most flexible
• Requires more IT involvement
• You are responsible for patching, monitoring, and failover

---

3) Choose the software

You generally want a router that supports:

• DICOM networking as SCP/SCU
• Routing rules
• Queuing and retry
• Logging and audit
• TLS/encrypted transport if possible
• HL7 integration if you need patient/study context
• De-identification if relevant

Examples of categories:

• Commercial DICOM routers: best for support, HA, and regulatory environments
• Open-source DICOM servers/tools: good for labs, smaller sites, or integration projects
• PACS with routing features: sometimes the PACS itself can act as a router

If you’re in a clinical environment, validate the product for your regulatory needs and vendor support expectations.

---

4) Plan the network and security

You’ll need to define:

• AE Titles
  • Scanner AE Title
  • Router AE Title
  • PACS AE Title
  • Any secondary destinations
• IP addresses / DNS
• Ports
  • Standard DICOM is often 104, but many sites use other ports
• Firewall rules
• TLS encryption
• Segmentation
  • Put the router in a secure medical imaging VLAN or subnet
• Time sync
  • NTP is important for logs and troubleshooting

Security recommendations:

• Use TLS for DICOM if supported by all devices
• Restrict incoming connections to known scanner IPs
• Restrict outbound connections to approved PACS/VNA hosts
• Disable unnecessary services
• Use strong admin authentication and role-based access
• Keep audit logs

---

5) Define routing rules

Typical routing rules include:

• Modality-based
  • CT → PACS A
  • MR → PACS A and Archive B
• Site-based
  • Scanner in Room 1 → PACS main
  • Scanner in outpatient clinic → regional PACS
• Study-based
  • Mammography studies → dedicated archive
  • Research studies → anonymization engine
• Destination-based
  • Primary PACS
  • Backup PACS
  • QA workstation
• Conditional rules
  • Route if modality = US and body part = abdomen
  • Route if accession number matches certain pattern

Also decide whether the router should:

• Forward immediately
• Queue and retry on failure
• Store locally until acknowledgment
• Route only after receipt confirmation

For clinical reliability, queueing and retry are highly recommended.

---

6) Decide how metadata should be handled

If you said “moving images and metadata,” you likely mean the router should preserve or transform DICOM tags.

You should define:

• Which metadata must be preserved exactly:
  • Patient ID
  • Study Instance UID
  • Series Instance UID
  • SOP Instance UID
  • Accession Number
  • Modality
  • Study Date/Time
• Which metadata may be modified:
  • Institution name
  • Station name
  • Performing physician
  • Routing comments
• Whether to normalize tags from different scanners
• Whether to strip private tags
• Whether to anonymize PHI for non-clinical destinations

Important:
If you alter UID values, make sure downstream systems can still reconcile images correctly.

---

7) Configure scanner DICOM settings

On each scanner, configure:

• Router as the destination AE
• Router IP and port
• Correct AE title
• Patient/study worklist source if applicable
• Any compression or transfer syntax settings supported by PACS/router

Then test:

• Send a known study
• Verify it arrives in the router
• Verify it forwards to PACS
• Verify all images and objects arrive intact
• Confirm the study is visible in PACS with correct patient metadata

---

8) Configure PACS and other destinations

On the PACS side:

• Add the router as a trusted DICOM sender
• Whitelist router IP/AET
• Confirm storage SCP settings
• Confirm whether PACS accepts compressed transfer syntaxes
• Verify whether PACS requires acknowledgment or storage commitment

If routing to multiple destinations, test each one independently.

---

9) Set up failure handling

A good router should handle failures gracefully.

Make sure it can:

• Queue studies if PACS is offline
• Retry with backoff
• Alert admins on persistent failures
• Preserve ordering if needed
• Detect duplicate instances
• Report partial send failures

Define operational rules:

• How long to retain queued studies
• When to escalate to IT
• What happens if the disk fills up
• How to clear failed jobs safely

---

10) Build monitoring and logging

At minimum, monitor:

• Incoming associations
• Successful forwards
• Failed forwards
• Queue depth
• Disk usage
• Service status
• Network reachability of PACS

Logs should capture:

• Timestamp
• Sender AE/IP
• Study UID
• Destination
• Error code/message
• Retry attempts

If possible, integrate with:

• Syslog
• SIEM
• Email/SMS alerts
• Prometheus/Grafana or similar monitoring

---

11) Validate with a structured test plan

Test cases should include:

• Single CT study from scanner to PACS
• Large multi-series MR study
• Study with secondary capture objects
• PACS outage and recovery
• Duplicate send scenario
• Invalid AE title
• Network interruption mid-transfer
• Modality-specific routing rules
• Metadata preservation after routing
• Any de-identification workflows

Document:

• Expected result
• Actual result
• Acceptance criteria
• Sign-off from radiology/IT

---

12) Consider compliance and governance

Depending on your environment, you may need to address:

• HIPAA / GDPR / local privacy laws
• Audit trails
• Retention policies
• Access control
• Change management
• Validation in a regulated environment
• Vendor BAAs / data processing agreements

For clinical use, get radiology and biomedical engineering/IT approval before deployment.

---

Example simple setup

A minimal setup might look like this:

• Scanner AE title: CT_ROOM1
• Router AE title: DICOM_ROUTER
• PACS AE title: MAIN_PACS

Flow:

1. Scanner sends all studies to DICOM_ROUTER
2. Router receives and logs them
3. Router forwards to MAIN_PACS
4. If PACS is down, router queues and retries
5. Router alerts IT if queue exceeds threshold

---

Example routing logic

• If Modality = CT or MR → send to PACS
• If StudyDescription contains "research" → send to anonymizer and research archive
• If InstitutionName = ClinicB → forward to regional PACS
• If destination fails → retry 10 times over 30 minutes, then alert

---

Recommended implementation checklist

• Identify all scanners and destination systems
• Define AE titles, IPs, ports
• Choose router software/appliance
• Confirm TLS and firewall requirements
• Write routing rules
• Decide metadata handling policy
• Test with sample studies
• Test failure/retry behavior
• Set up monitoring and alerts
• Validate and document go-live procedures

---

If you want, I can also help you with one of these next steps:

1. a vendor-neutral architecture diagram
2. a step-by-step configuration example
3. a list of open-source or commercial router options
4. a sample routing rules table
5. a production checklist for hospital IT