Platform
One appliance between every source and every destination
Routing rules, protocol translation, retries, transforms, and audit - configured from a browser, not from a config file on a server nobody remembers the password to.
DICOM Assist is not a PACS and is not a diagnostic viewer. It is the routing, workflow, and integration layer that keeps imaging data moving across a mixed healthcare environment.
Capabilities
What the platform does
Rule-based routing engine
Route studies by modality, source AE title, source IP/CIDR, DICOM tag values, series description, or SOP class - alone or in combination, evaluated in priority order within a rule set.
Interfaces, not a single listener
Each inbound DICOM interface has its own bind address, port, AE title, TLS posture, allow-lists, enabled services, and rule set, added and enabled from the console without restarting the service.
Multi-protocol destinations
Send to DICOM PACS and VNAs (C-STORE), Amazon S3, Azure Blob, Google Cloud Storage, DICOMweb (STOW-RS), HL7 v2 over MLLP, FHIR REST, a local or UNC folder, and grayscale DICOM film printers.
Remote Gateway
A site-local component receives DICOM locally, spools it durably, and relays outbound-only over mTLS, so central IT never needs inbound firewall access, VPN ingress, or line of sight into the remote site.
Query/Retrieve and prefetch
C-FIND, C-MOVE and C-GET against remote PACS, plus scheduled prefetch built from pickers rather than cron - and each schedule carries its own time zone, so it holds its local hour across daylight-saving changes.
Load balancing and failover
Group destinations for round-robin, weighted, or least-connections distribution, with automatic failover, retries, and dead-letter handling when a target goes offline.
Tag modification in transit
Set, Append, Prepend, Remove, Keep, and Map tag values per rule or per destination, so a receiver's requirements apply to every study sent to it whichever rule routed it. Metadata only - pixel data is never touched.
Modality worklist
Serve MWL C-FIND per interface, fed from HL7, FHIR, and upstream worklist sources, with transforms and field mappings configured as typed fields rather than as a script.
HL7 and FHIR
HL7 v2 MLLP receive and send with ADT parsing and correlation, several concurrent MLLP listeners each with its own rule set, MLLP over TLS, and structured report results returned to the RIS as study-level ORU.
Bulk migration between archives
Move a legacy archive to a new one over Query/Retrieve with resume, cancel, parallelism up to 16, and a reduced-rate window so the migration backs off during reading hours and runs flat out overnight.
Guided orchestration
Author workflows on a designer canvas or in the form builder - trigger, actions, review - covering routing, Query/Retrieve, HL7 actions, and webhooks, without a developer-owned script.
System Health and audit
Every component reported by the stage of the path a study takes - Receive, Route, Send, Orders, Retrieve, Platform - alongside a full audit log, metrics, alerting by email and webhook, and in-console application logs.
Protocols
What it speaks
Receive
- DICOM C-STORE
- DICOMweb STOW-RS
- HL7 v2 MLLP
- FHIR REST
Query
- C-FIND
- C-MOVE
- C-GET
- QIDO-RS
- WADO-RS
- MWL C-FIND
Send
- DICOM C-STORE
- DICOMweb STOW-RS
- Amazon S3
- Azure Blob
- Google Cloud Storage
- HL7 v2 MLLP
- FHIR REST
- Disk / UNC
- Grayscale film print
FHIR ingress accepts and durably stores resources and reports what it holds. It does not yet map an inbound resource onto a study, an order, or a patient update - we say so here rather than let you find out during an evaluation.
Go deeper
Remote Gateway
Connect a site you do not control, with no inbound firewall exception and no VPN ingress.
How the gateway worksDe-identification
Anonymize or Pseudonymize on the way out, fail-closed, with unmatched results held for review.
How de-identification works