Router-pattern host · Flagship Ingest from any modality, route by rules, transform tags, anonymize, prefetch, hold and release. The flagship workflow orchestrator — both the operating-control plane for an imaging department and the integration hub between modality, EMR, PACS, VNA, and reporting.
Capabilities
Organized by functional area. Every capability listed below is part of the shipping product — not roadmap.
Standard inbound and outbound paths for any modality or downstream system.
The core. Rules execute on every received study, deciding what to do with it.
In-flight modification of studies as they pass through the router.
Studies routed to the hold queue wait for human approval before forwarding.
Pull priors and related studies ahead of an appointment to make them available before reads.
Two-way communication with the EMR for orders, results, and worklist generation.
The day-to-day surfaces operators use to run the router.
Architecture
Conceptually: between modalities and downstream systems. In practice, often in front of the entire imaging stack as the single integration point that routes, transforms, and gates every study that flows through.
The Router is a single binary on Windows or Linux. Active-active HA pairing is supported on the Enterprise license tier. State (queue depth, audit log, rule history) persists in a backing database — PostgreSQL, SQL Server, or SQLite for small deployments.
Common use cases
Most Router deployments combine two or three of these. The patterns below are common building blocks; real deployments mix and match.
All modalities forward to the Router; the Router applies routing rules to fan studies out to PACS, VNA, AI applications, and remote-read destinations.
Flow
During a PACS replacement, the Router runs in front of both old and new archives. Studies double-route during the parallel-run window; cutover is a config flip.
Flow
New AI vendor needs a feed of relevant studies (e.g., chest CTs for triage). The Router applies a body-part + modality filter and forwards a copy without disrupting the primary clinical workflow. For AI vendors that don't want BAA scope, the Router can de-identify on the way out and re-identify findings on the way back via keyed-hash pseudonymization.
Flow
Hold-queue rules catch studies matching VIP / employee / behavioral-health criteria. Studies wait for reviewer approval before downstream forwarding.
Flow
Research IRB approves a de-identified study set. The Router applies an anonymization profile and forwards a copy to a research VNA without affecting the clinical archive.
Flow
Integration points
Organized by stack layer. Anything DICOM-conformant is integrable; the lists below highlight the systems we’ve deployed against most often.
System requirements & sizing
The Router scales with study throughput, not with archive size — it’s a transit-and-transform engine, not a long-term store. Sizing tiers below are starting points; final sizing comes out of discovery.
| Tier | Study volume | CPU | RAM | Storage | Typical site |
|---|---|---|---|---|---|
| Small (single facility) | < 200 studies / day | 4 vCPU | 8 GB | 500 GB (queue + audit log) | Imaging center, single-modality clinic, ambulatory site. |
| Medium (community hospital) | 200 – 1,500 studies / day | 8 vCPU | 16 GB | 1 TB | Single hospital, full modality mix, regional reading group. |
| Large (academic / multi-site) | 1,500 – 8,000 studies / day | 16 vCPU (HA pair) | 32 GB per node | 2 TB per node | Academic medical center, multi-hospital health system. |
| Enterprise (national / IDN) | > 8,000 studies / day | 32 vCPU (HA cluster, 3+ nodes) | 64 GB per node | 4 TB per node | Large IDN, national reading network, enterprise-imaging platform. |
Full hardware/software requirements are in DOC-2026-058 (HW/SW Requirements), available under NDA. Includes OS support matrix, supported databases, network requirements, and firewall configuration.
Whitepaper
We measured Router + SynthIQ on a dedicated rig across three host sizes. The finding: routine imaging is CPU-bound, 3D tomosynthesis (DBT) is memory-bound until RAM is ample — then CPU-bound — and disk IOPS is never the limit. Includes the full sizing matrix and the scale-out trigger.
Licensing
The Core package covers the routing engine. Add HL7 and / or Prefetch as separate license features, or step up to Enterprise for everything plus pixel redaction, hold queue, and HA pairing.
The base package — DICOM I/O, rule engine, basic transformation, audit log.
Adds HL7 v2 / FHIR integration and worklist generation.
Adds intelligent prefetch from upstream archives.
Everything, plus pixel redaction, hold queue, and HA pairing.
Licensing is per-deployment, not per-study. Multi-site customers get site-discounted bundles; multi-product customers (Router + VNA Repository, Router + Migration Engine, etc.) get product-bundle pricing. Specific pricing in your engagement SOW.
Documentation
Every Router deployment ships with the documents below, all managed under SynthQMS document control. The DICOM Conformance Statement is publicly available; the rest are shared under mutual NDA.
| Document | Title | Notes |
|---|---|---|
| DOC-2026-058 | Hardware & Software Requirements (Router) | Sizing, OS support, dependencies |
| DOC-2026-074 | DICOM Conformance Statement (Router) | Public — full SOP class + transfer-syntax matrix |
| DOC-2026-064 | EULA Annex (Router) | Annex to the Synthology Master EULA (DOC-2026-063) |
| DOC-2026-394 | Penetration Test Results (Router) | Available under NDA |
| DOC-2026-089 | QA Runner Manual (Router) | Internal QA + customer-validated test runs |
| DOC-2026-387 | User Guide (Router) | Operator + administrator workflows |
| DOC-2026-069 | Installation Guide (Router) | Includes MSI deploy + Linux tarball install |
Frequently asked
No. The Router is happy as the front door of any imaging stack. Common edge-deployment patterns: send modality output directly to a cloud archive via STOW-RS, or hold studies in the Router's queue while a downstream destination is offline. The Router becomes more powerful when paired with a VNA, but it doesn't require one.
All matching rules execute by default — fan-out is the common case (forward to PACS + AI vendor + research archive simultaneously). For exclusive routing, set rules to "stop on match" priority order. Each rule can be tagged with priority and short-circuit behavior.
Studies queue locally with retry policy (configurable: exponential backoff with max retry window). Operators see queue depth on the dashboard. Once the destination recovers, the queue drains automatically. Persistent failures route to a dead-letter queue for manual handling.
Yes — Windows and Linux. The MSI installer covers Windows deployments; a self-contained Linux tarball covers Linux. Both are supported equally; the active-active HA pair can mix OS platforms if needed.
Rules are exportable as JSON and versioned in the SynthQMS document control system. Every rule-set edit creates an auditable change record. The standing rule across the XyDromatics family is that rule changes go through the same document-control workflow as other configuration: draft, review, approve, archive.
Non-device software under FD&C Act §520(o)(1)(D), the 21st Century Cures Act §3060 carve-out for software that transfers, stores, converts, or displays device data without interpreting or analyzing it. No FDA Device Listing required; no premarket review applicable. Same framework as every other Synthology product. See /regulatory for the full posture.
Yes. Common during phased rollouts: existing Laurel Bridge / DicomSys / DataFirst orchestrator continues to handle some rule sets while the XyDromatics Router takes over others. Cutover is rule-set by rule-set rather than big-bang.
Patch releases (1.X.Y.Z) deploy without downtime via active-active HA. Minor releases (1.X.Y) typically follow a quarterly cadence with a 30-day customer-validation window. Major releases (1.X) are annual and include a Migration Plan document under document control.
Each customer is provisioned with a per-customer site encryption key, and all router-pattern products in their portfolio share that key. So a customer running Router + VNA Migration + VNA Clinical Research has the same patient mapped to the same anon-ID across all three products. That cross-product consistency is what makes workflows like "Migration Engine ingests legacy data into VNA Research, then VNA Clinical Research's broker capability re-links findings back to clinical" actually work. Site-key provisioning is part of the multi-product license bundle; it's also a customer-security-governed item, so we coordinate with your security team on key custody, rotation policy, and escrow.
A 30-minute walkthrough with a Synthology engineer — your environment, your routing scenarios, your questions. We’ll come back within one business day with proposed times.