SynthIQ Vendor-neutral · DICOM load balancer · Non-device software · Patent Pending

SynthIQ — the load balancer that speaks DICOM.

Drop-in replacement for F5, NetScaler, or HAProxy in front of any PACS or DICOM Router pool. Routes by Study Instance UID, not TCP 5-tuple. Keeps every study together on one backend — within an association, across separate associations and late re-sends, and across SynthIQ restarts.

Vendor-neutral by design. Works with any DICOM-conformant backend — Synthology fleet, vendor PACS (GE, Siemens, Philips, Fujifilm, Sectra, Visage), research VNAs, cloud-native DICOM endpoints. Heterogeneous pools are a first-class deployment shape — every backend gets in, graded by how much load it can report. Three doors, no dead ends.

Request a demo Read the whitepaper
The problem · Capabilities · Vendor-neutral pool · Architecture · Performance · Use cases · Integrations · Sizing · Licensing · Documentation · FAQ

The problem SynthIQ solves

Generic load balancers scatter clinical studies.

Today: F5 / NetScaler / HAProxy

A modality sends a 1,500-instance CT study to your PACS pool's VIP. The L4 load balancer hashes the TCP 5-tuple and scatters the instances across two, three, or all five backends. The Study Instance UID — the thing that makes those 1,500 instances one exam — is invisible to the LB.

Now no single backend holds the whole exam — each node has a fragment. When that study later has to be re-sent, or forwarded to a second destination (an AI vendor, a VNA, a downstream archive), every node re-transmits its fragment, so the destination receives overlapping, duplicated instances. Per-node counts disagree because each device only ever saw part of the study. There is no single device that is the study's source of truth.

With SynthIQ in front

SynthIQ parses each C-STORE far enough to read the Study Instance UID, then routes it to the same backend that holds (or will hold) the rest of the study. The binding is persistent — every instance of that study lands on the same backend, even ones that arrive in a later association, as a delayed re-send, or after a SynthIQ restart. (Affinity keys on the Study Instance UID alone — SynthIQ groups the instances of one study, not a patient's separate exams, and stores no MRN.)

Result: one backend is the whole study's single source of truth. A re-send, or a forward to an additional destination, happens once — from that one device — so there are no duplicate fragments arriving from multiple nodes. Per-node counts reconcile because each study lives whole on one node. And SynthIQ never caches the pixels: every object streams through and is forwarded; only the routing record (which study went to which backend) is kept.

Want the full analysis? Read the comprehensive whitepaper — covers the problem in depth, the design, operational characteristics, regulatory posture, and an honest comparison against F5, NetScaler, HAProxy, Mirth Connect, Forcare, and vendor-PACS internal LBs.

Capabilities

What SynthIQ actually does.

Study-affinity routing (the core)

The capability no generic L4 load balancer can offer.

  • Reads Study Instance UID from every incoming C-STORE — knows what study each instance belongs to
  • Persistent affinity cache binds each SUID to a specific backend on first sight
  • Every subsequent instance of the same study (same Study Instance UID) routes to the same backend — within an association, across separate associations, late re-sends hours or days later, and across SynthIQ restarts
  • Affinity survives SynthIQ restarts and process crashes (state in SQLite, PostgreSQL, or SQL Server)
  • Honors affinity even if the bound backend is currently slow — the study's earlier instances live there, so the study stays coherent
  • Three-tier waterfall: persistent affinity → least-busy healthy → last-resort fallback

Health-aware backend selection

Routes new studies based on actual backend load, not blind hashing.

  • Polls each backend's health endpoint every 5 seconds (configurable)
  • Tracks per-backend queue depth (received + hold + processing)
  • Routes new studies to the lowest-queue healthy backend — no piling onto saturated nodes
  • Backends that miss heartbeats drop out of new-study candidate selection
  • Affinity-bound studies still attempt their bound backend — that's where the priors are

Vendor-neutral by design

Works with any DICOM-conformant backend. Not just for the Synthology fleet.

  • Drop-in replacement for F5 BIG-IP, NetScaler ADC, HAProxy, AWS NLB — wherever you have a generic L4 LB in front of a DICOM pool
  • Heterogeneous pools supported: SynthIQ can front a mixed pool of vendor PACS, Router instances, third-party DICOM endpoints
  • No proprietary protocol — every backend conversation is plain DICOM via fo-dicom's standard SCU
  • Modalities continue to use their existing AE-title + IP config — SynthIQ presents one VIP per pool
  • DICOM TLS supported (off by default, per-pool toggle)

Inspectable operations

Open admin UI, open state. Your ops team can see what SynthIQ is doing.

  • Read-only admin SPA — JSON APIs for status, pools, affinity, activity
  • Affinity store is a standard SQL database — query the bindings with any SQL tool
  • Routing decisions color-coded in the UI: indigo (affinity hit), green (least busy), yellow (cached association), red (fallback)
  • Every routing decision emits one structured log line — Serilog rolling file + console
  • Storage Commitment surface: query whether a backend has durably committed a study by UID

Vendor-neutral pools

Three doors, no dead ends.

SynthIQ fronts a mixed pool of any DICOM-conformant backend — your existing PACS, an XyDromatics Router, a research VNA, a cloud endpoint, an AI vendor. How smart the balancing gets on a given backend depends on one thing: how much load that backend can tell us. SynthIQ grades each by load-signal fidelity — and never balances a backend on a number it didn't report.

1

Native

Synthology products

Full /api/health — queue depths, load score, associations, disk headroom, throughput.

Richest least-busy, ready for predictive weighting.

2

Certified

Any vendor · self-service

Implements the published SynthIQ Health Contract — one lightweight endpoint returning status, load, and capacity.

Real least-busy — native-grade on the essentials.

3

Adapter

Any vendor · we do the work

Exposes its own existing health/metrics in its own format; SynthIQ normalizes them onto a common load scale.

Real least-busy via a per-vendor shim — zero vendor effort.

4

Liveness

Any DICOM node

No parseable load — an up/down check only, preferring standards-native DICOM C-ECHO (or TCP / HTTP).

Weighted distribution, gated by the probe — never least-busy.

Three doors for any vendor

A third-party backend joins a SynthIQ pool one of three ways: implement the published Health Contract (one small endpoint, self-service certification), let us adapt your existing metrics, or run heartbeat-only. None of them is a dead end — a backend that can only say “I'm alive” still earns reliable failover and weighted distribution. Nothing is excluded; nothing is faked.

The safety principle

A node enters least-busy ranking only when its load is genuinely known. A heartbeat-only node has an unknown load — so SynthIQ distributes to it by weight and watches it with an up/down probe, rather than treating “no signal” as “empty” and flooding it. We never flood a backend we can't measure.

Why it displaces a generic L4 balancer

On the imaging path F5 / NetScaler / HAProxy / NLB SynthIQ
Unit of routing TCP connection (5-tuple hash) DICOM study (Study Instance UID)
Study coherence Split across backends Kept whole on one backend
Health signal TCP-open / HTTP-200 DICOM ingest-queue depth + heartbeat
Least-busy basis Connection count / hash Real reported backend load
A silent backend Looks healthy → gets flooded Balanced by weight → never falsely “least-busy”
Mixed-vendor pool Blind — every node looks alike Graded by load-signal fidelity
Footprint Appliance / cloud-LB license A single software binary
Lock-in Single-vendor balancer One control point for a whole mixed-vendor estate

Keep your F5 or NetScaler for the rest of your traffic — SynthIQ owns the DICOM path, where a connection-level balancer is blind to the study. One control point replaces both the scatter problem and the single-vendor balancer's lock-in across a whole mixed-vendor imaging estate.

What ships today. Study affinity, health-aware least-busy, weighted distribution, the drop-in L4 replacement, the published SynthIQ Health Contract with self-service SynthIQ-Ready certification, the standards-native DICOM C-ECHO liveness probe, and the never-balance-on-a-number-you-didn't-report safety rule are all available now. The one path we build on demand is the per-vendor Adapter — normalizing a vendor's existing metrics onto our load scale — added when a specific integration calls for it.

Architecture

Where SynthIQ sits.

Between your modalities and your backend pool — wherever a generic L4 load balancer lives today. Modalities don't change their config; backends don't change their config; SynthIQ replaces the LB at the same VIP and starts routing by Study Instance UID.

SynthIQ architecture Modalities push DICOM C-STOREs into the SynthIQ Pool. The Storage SCP listener hands each instance to the Routing decision engine, which consults the persistent Affinity store (SQLite / PostgreSQL / SQL Server) for an existing SUID-to-backend binding, then forwards via the SCU pool to one of the configured backend nodes (1, 2, 3). A Heartbeat service polls every backend's /api/health endpoint every 5 seconds to track queue depth. An Admin SPA exposes status, pool config, affinity bindings, and recent routing decisions to the operator. Modalities C-STORE inbound Operator Admin / Ops SynthIQ Pool SCP Routing decision SCU pool Affinity store SQLite · PostgreSQL · SQL Server SUID → backend Heartbeat service polls every 5s tracks queue depth lookup · bind queue depth Admin SPA + JSON APIs Backend 1 Backend 2 Backend 3 DICOM forward /api/health (poll every 5s)

SynthIQ is a single self-contained binary on Windows or Linux. Active-active HA pairing is supported on the Enterprise license tier, sharing affinity state across instances via PostgreSQL or SQL Server. For full architectural depth — three-tier routing waterfall, persistent affinity store internals, failure-mode analysis — see §3 of the whitepaper.

Performance · Measured

The heaviest studies, on the smallest box.

We put SynthIQ on a dedicated performance rig — a 2 vCPU / 8 GB instance, the smallest a cloud will rent — and measured it under the worst DICOM workloads: 3D tomosynthesis and 10,000-slice CT. Because SynthIQ routes rather than renders — it never decodes or buffers pixels; it spools to disk and streams — memory is never the wall.

100%

delivery — 70 tomosynthesis studies + 30,000 CT objects, zero failed

≤ 620 MB

peak memory — on an 8 GB box, ~7 GB always free

65 GB

moved through the 8 GB box (35 GB DBT + 30 GB CT) at 100%

0

memory leaks — heap plateaus under sustained load

Workload (on 2 vCPU / 8 GB) Volume Delivery Peak heap
3D tomosynthesis (DBT) 70 studies / 35 GB 100% 490 MB
High-count CT (incl. 10,000-slice "Alpha CT") 30,000 objects / 30 GB 100% 620 MB

The honest nuance: 2 vCPU / 8 GB never fails on memory or correctness for any modality — but throughput scales with cores. A single 10,000-slice study clears in minutes on a small box, and proportionally faster on more vCPU. Size SynthIQ for the throughput you need, not to survive the biggest study. Full rig methodology, run-by-run tables, and why the memory ceiling isn't there: the SynthIQ capacity whitepaper.

Common use cases

Five deployment patterns.

Pattern 1

Replace a generic L4 LB in front of a PACS pool

The flagship deployment. You run F5, NetScaler, or HAProxy in front of 3-5 backend nodes today. Studies scatter across nodes, so no node holds a whole study — a re-send or re-route duplicates fragments at the destination, and per-node counts disagree. SynthIQ is a drop-in replacement at the same VIP.

Flow

  1. 1 Modalities continue to point at the same VIP (no modality-side change)
  2. 2 SynthIQ replaces the generic LB at the VIP
  3. 3 SynthIQ routes each C-STORE by Study Instance UID to the same backend
  4. 4 Each study lands whole on one backend — re-sends and re-routes to other destinations go from a single source, with no duplicate fragments
  5. 5 Cut over from existing LB during a maintenance window with rollback ready
Pattern 2

Front a heterogeneous DICOM pool (multi-vendor backends)

You have a Router pool plus a legacy PACS plus a research VNA, and modalities need to route to one VIP that fans out. SynthIQ's vendor-neutral design supports a mixed pool: any DICOM-conformant backend qualifies as a pool member.

Flow

  1. 1 Configure SynthIQ pool with backends spanning Router instances + non-Synthology PACS + research VNA
  2. 2 Health-check endpoint is the only requirement per backend
  3. 3 New studies route by least-busy across the mixed pool
  4. 4 Affinity binds studies to their initial backend regardless of vendor
Pattern 3

Bridge a PACS migration cutover (study-affinity preservation)

During a PACS replacement, the old archive and new archive both run. Studies need to keep going to their original archive (until they're fully migrated) while new studies go to the new archive. SynthIQ's affinity store doubles as a deterministic routing rule across the cutover.

Flow

  1. 1 SynthIQ pool includes both old archive and new archive as backends
  2. 2 Affinity rules pin existing studies to the old archive
  3. 3 New studies (no affinity binding) route to the new archive
  4. 4 Migration completes; old archive removed from pool; affinity bindings re-point to new archive
Pattern 4

Distribute to AI vendor + production pool in parallel

AI vendor wants a copy of every CT. Production PACS pool serves clinical reads. SynthIQ fans out: production pool gets the routed copy (with affinity), AI vendor gets every study unconditionally.

Flow

  1. 1 Configure SynthIQ pool A (production, study-affinity routing) for clinical workflow
  2. 2 Configure SynthIQ pool B (AI vendor, fanout to single AI endpoint) on a separate listener
  3. 3 Modality forwards each instance to both VIPs
  4. 4 Pool A maintains affinity; Pool B unconditionally forwards to AI
Pattern 5

Dedicated lane for STAT / urgent studies

Priority work shouldn't queue behind routine volume. Stand up a separate pool with its own AE title, port, and VIP, pointed at a specialized or faster backend; a modality operator chooses the lane by sending an urgent study to that AE title, putting it on a path that runs independently of the routine pool. The clinical decision of what is urgent stays with the operator — SynthIQ provides the dedicated pool and faithfully delivers to it.

Flow

  1. 1 Configure a dedicated pool with its own AE title + port for priority traffic
  2. 2 Point it at the specialized / priority backend (or a faster Router)
  3. 3 A modality operator manually selects that AE title (destination) for a STAT study
  4. 4 The urgent study takes the priority lane; the routine pool keeps its own affinity + least-busy balancing, unaffected

Integration points

What SynthIQ connects to.

Vendor-neutral on every layer. Any DICOM-conformant backend qualifies as a pool member.

Backends (the pool members)

  • XyDromatics Router — first-class integration via /api/health
  • XyDromatics VNA Repository / Migration / Clinical / Research — same /api/health
  • GE Centricity, Siemens syngo.plaza, Philips Vue, Fujifilm Synapse, Merative Merge — any vendor PACS with a health endpoint
  • Hyland Acuo, Agfa, Sectra (vendor-neutral) — heterogeneous mixed pools fully supported
  • AWS HealthImaging, Google Cloud Healthcare API — cloud-native DICOM endpoints

Modalities (inbound)

  • Any DICOM-conformant modality — CT, MR, US, XA, NM, MG, CR, DX, RF, mammography
  • GE, Siemens, Philips, Canon, Fujifilm, Hologic — vendor-agnostic SCP
  • Existing modality config preserved — point at the same VIP that previously hosted F5/NetScaler/HAProxy

Affinity database (state)

  • SQLite (default) — in-process, no external dependency, comfortable up to mid-size deployments
  • PostgreSQL — for HA across multiple SynthIQ instances or 10×+ scale
  • SQL Server (T-SQL MERGE upsert) — for shops standardized on Microsoft data tier
  • Same schema across all three; migration scripts move state between providers

Monitoring / observability

  • JSON APIs returning standard 200/4xx/5xx — scrape with Prometheus exporter (roadmap) or directly
  • Serilog rolling file + console — structured per-decision logging
  • Per-association summary log line: rx=N fwd=N failed=N studies=N cache-hits=N backends=N
  • Optional integration with Synthology SynthGateway for fleet-wide health telemetry

System requirements & sizing

Sized to throughput, not study size.

Tier Study volume CPU RAM Storage Typical site
Entry / single facility < 200 studies / day 2 vCPU 8 GB 50 GB (affinity DB + logs + temp spool) SQLite affinity, single instance, single pool. Measured: 100% delivery of concurrent 3D tomosynthesis + a 30,000-object CT workload at this exact spec.
Standard / community hospital 200 – 1,500 studies / day 4 vCPU 8 – 16 GB 100 GB SQLite or PostgreSQL affinity, single instance, multi-pool if needed. Cores add throughput headroom; RAM stays modest.
High-throughput / academic 1,500 – 8,000 studies / day 8 vCPU 16 GB 100 GB per node PostgreSQL or SQL Server shared affinity; active-active HA pair for resilience. Cores — not RAM — drive the tier.
Enterprise / IDN > 8,000 studies / day 8 – 16 vCPU (HA pool, 2+ nodes) 16 GB per node 100 GB per node Scale OUT — add SynthIQ pool nodes, not bigger boxes. PostgreSQL or SQL Server shared affinity; multi-region considerations.

SynthIQ's own memory footprint stays well under 1 GB regardless of tier (see Performance · Measured above) — it routes, it doesn't render. The RAM above is comfortable headroom for the OS, a co-located affinity database, and burst concurrency; cores and concurrency — not memory — set the tier.

Licensing

Standard and Enterprise.

SynthIQ Standard

The base package — DICOM-aware load balancing, persistent affinity, admin SPA.

  • Single-pool DICOM Storage SCP
  • Persistent study affinity (SQLite, PostgreSQL, or SQL Server)
  • Health-aware backend selection
  • Read-only admin SPA
  • Structured logging
  • DICOM TLS support

SynthIQ Enterprise

Multi-pool deployments + HA + advanced operational tooling.

  • Everything in SynthIQ Standard
  • Multiple parallel pools (fanout, segmentation)
  • Active-active HA pair with shared affinity backend
  • Prometheus exporter
  • Mutating admin endpoints (with auth)
  • Premium support tier eligible
  • Storage Commitment proxying (modality ↔ backend)

Documentation

The controlled-document set.

Every SynthIQ 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-348 Hardware & Software Requirements (SynthIQ) Sizing, OS support, dependencies
DOC-2026-347 DICOM Conformance Statement (SynthIQ) Public — full SOP class + transfer-syntax matrix
DOC-2026-350 EULA Annex (SynthIQ) Annex to the Synthology Master EULA (DOC-2026-063)
DOC-2026-395 Penetration Test Results (SynthIQ) Available under NDA
DOC-2026-396 QA Runner Manual (SynthIQ) Internal QA + customer-validated test runs
DOC-2026-353 User Guide (SynthIQ) Operator + administrator workflows
DOC-2026-351 Installation Guide (SynthIQ) Includes MSI deploy + Linux tarball install

Frequently asked

The questions prospects ask.

Is SynthIQ tied to the Synthology fleet? Can we use it with our existing non-Synthology PACS?

SynthIQ is **completely vendor-neutral**. It speaks standard DICOM to any backend. Mixed pools are explicitly supported: Router instances + non-Synthology PACS + research VNA can all live in one SynthIQ pool. Any DICOM-conformant backend qualifies as a pool member as-is — nothing to build to join. For *first-class* least-busy routing, a backend reports its load one of three ways: implement the published SynthIQ Health Contract (one small endpoint), let us adapt its existing health metrics, or run heartbeat-only and be balanced by weight. Three doors, no dead ends — see the Vendor-neutral pools section above.

How is this different from running iRules on F5 to parse DICOM?

You can write F5 iRules / NetScaler responder policies that parse DICOM headers. Customers who've done it report 2-4 weeks of engineering plus ongoing maintenance burden, and the iRules don't survive F5 firmware upgrades cleanly. SynthIQ ships this as the product's first-class behavior, with a persistent SUID→backend cache that no iRule can provide (iRules are stateless per-connection).

We already run an F5 or NetScaler. Why add SynthIQ?

Your F5 balances TCP connections; it can't see a DICOM study or an ingest queue, so it scatters the instances of one exam across backends and floods whatever node it last hashed to. SynthIQ replaces it **on the imaging path only** — studies stay whole, routing follows real reported backend load, and it's a software binary rather than another appliance license. Keep your F5 / NetScaler for the rest of your traffic; SynthIQ owns the DICOM path.

Will it be as smart with our GE / Siemens / Sectra PACS as with Synthology's own products?

It's smartest with any backend that reports its load — Synthology products do that natively, and any vendor can via the published SynthIQ Health Contract or by letting us adapt their existing metrics. A backend that can only answer a heartbeat still gets reliable failover and weighted distribution — just not queue-depth least-busy. We never pretend to know a load a backend didn't report, and we never flood one we can't measure.

What do we have to build to put our system in a SynthIQ pool?

Nothing to be a pool member — any DICOM-conformant backend qualifies today. For first-class least-busy routing you have **three doors**: implement one small endpoint (the SynthIQ Health Contract) and self-certify, let us write an adapter onto your existing metrics, or run heartbeat-only and be balanced by weight. None of them is a dead end.

What's the regulatory classification?

Non-device software under FD&C Act §520(o)(1)(D) — the statutory carve-out (21st Century Cures Act §3060, 2016) for software solely transferring, storing, converting formats, or displaying medical device data. The classification rests on three properties: SynthIQ stores no clinical data (DICOM payloads pass through, only routing metadata persists), performs no payload transformation (bytes received = bytes forwarded), and routes on study identity (SUID) rather than clinical content. Customers can purchase and deploy without waiting on FDA premarket clearance.

What happens if SynthIQ goes down mid-association?

In-flight C-STOREs error to the modality, which retries — this is standard DICOM behavior and no different than any other proxy outage. The affinity cache is persistent, so SynthIQ comes back up with state intact and same-SUID retries route to the original backend. No study fragmentation.

How long does a typical POC take?

30 days from initial config to bridge-and-decommission of your existing L4 LB. Week 1: install + configure pools + bind affinity cache. Week 2: parallel-run alongside existing LB with same backends. Week 3: cut over half the modalities to SynthIQ; monitor. Week 4: full cutover + decom of old LB.

Does SynthIQ replace XyDromatics Router?

No, they're complementary. Router is a full DICOM workflow product with rule engine, tag transformation, anonymization, hold queue, prefetch. SynthIQ is a load balancer. Many customers run SynthIQ in front of a Router pool — SynthIQ does affinity routing into the pool, each Router instance does its own workflow logic, results are coherent.

What's the upgrade path?

Patch releases (1.X.Y.Z) deploy without downtime via active-active HA on Enterprise. On Standard, a brief maintenance window is required during binary swap. Minor releases (1.X.Y) typically follow a quarterly cadence. Affinity-cache schema evolves with zero-downtime migrations; cache state persists across upgrades.

See SynthIQ in action.

30-day POC. Install in front of your existing DICOM pool alongside your current LB; measure scatter reduction with your real workload; cut over when you're satisfied. We can be set up in your environment within a week.

Request a demo Read the whitepaper