Now generally available · Non-device software (§520(o)(1)(D)) · self-hosted or Synthology-hosted multi-tenant · Book a demo

Synth family · DICOM result relay · Non-device software

SynthCloudConnect — the cross-site DICOM bridge.

Bridges AI-vendor result delivery into firewall-isolated on-prem Router fleets. The AI vendor C-STOREs results to a SynthCloudConnect endpoint; the on-prem Router pulls them down over an existing outbound-initiated mTLS WebSocket. No inbound firewall holes; no Synthology-to-customer initiated traffic.

Two deployment modes. Hosted multi-tenant (Synthology-operated, BAA signed) or self-hosted single-tenant (customer-operated, customer-CA-rooted). Same binary; the startup flag picks the mode. Hosted is the default go-to-market — self-hosted is for customers whose security posture won't accept Synthology-as-Business-Associate.

Book a demo See XyDromatics Router

The problem · Capabilities · Architecture · Use cases · Integrations · Roadmap · Documentation · FAQ

The problem SynthCloudConnect solves

AI vendors live in the cloud. On-prem Routers are firewalled. The gap is real.

The pattern that doesn't work today

Your on-prem Router pseudonymizes a CT study and C-STOREs it to a cloud AI vendor. That works — outbound DICOM C-STORE from your DC to the vendor's cloud is a standard pattern.

Then the AI vendor produces a result and needs to send it back. The vendor is in their cloud. Your Router is behind a firewall that blocks inbound traffic from third parties. Vendor C-STORE inbound to your Router → blocked. Vendor email with a link → not clinical-workflow-compatible. Vendor pushes to your VPN → policy-incompatible with most enterprise security teams.

With SynthCloudConnect in the path

AI vendor C-STOREs the result to a SynthCloudConnect endpoint (either Synthology-hosted or customer-hosted in your own cloud). SynthCloudConnect holds the result in your tenant's queue.

Your on-prem Router has an existing outbound-initiated mTLS WebSocket to SynthCloudConnect (same outbound traffic policy you already approved for SynthGateway support). The WebSocket carries a push notification of the new result. The Router pulls the result over the same connection. Forwards to local PACS via existing DICOM. Zero new inbound firewall holes; zero customer-side network policy change.

Capabilities

What SynthCloudConnect actually does.

Cross-site result bridging (the core)

Closes the gap where AI vendors live in the cloud and on-prem Routers are firewall-isolated.

AI vendor C-STOREs DICOM result to SynthCloudConnect endpoint (cloud or self-hosted)
SynthCloudConnect holds the result in a per-tenant queue with configurable TTL
On-prem Router pulls result over an existing outbound-initiated mTLS WebSocket
Router forwards the result to local PACS / viewer / EMR via existing DICOM C-STORE
End-to-end: no inbound firewall hole, no customer-side network policy change

Outbound-only customer-side transport

Respects enterprise security policies that forbid inbound traffic from any vendor.

WebSocket initiated FROM the on-prem Router OUT to SynthCloudConnect
Long-lived connection, multiplexes notifications + payload pulls over the same channel
Transport adapted from SynthGateway (DCR-2026-025) — proven outbound-initiated mTLS pattern
Customer firewall sees one outbound mTLS connection, no inbound listener
Optional Cloudflare Tunnel mode (Phase 3) eliminates even the outbound TCP allowlist requirement

Per-tenant isolation + audit

Each customer's results live in their own queue + their own crypto subtree.

Tenant identity established at mTLS handshake (cert subject = tenant slug)
Per-tenant SQLCipher hold-queue DB, per-tenant KEK (hosted Tier 1 Standard)
Pseudonymization-preserving — results pass through customer keypair tree without re-mapping
Per-tenant operations console for hold queue + retention + audit visibility
Cross-tenant access restricted to Synthology engineer roles with break-glass logging

Self-hosted single-tenant deployment

For customers whose security posture won't accept Synthology-as-Business-Associate.

Same binary as the hosted variant — startup flag picks deployment mode
Customer-owned cloud (AWS / Azure / GCP IaaS) or on-prem (single VM / DC)
Customer self-issues its own CA at first boot — no Synthology trust root needed
Per-instance perpetual .lic file + annual maintenance, matching SynthIQ / Router pattern
Phase 1: Terraform module; Phase 2: MSI for Windows VM, RPM for Linux VM, Helm chart for k8s

Architecture

Two deployment modes, one binary.

Same .NET host runs in either mode. A startup config flag (--mode=hosted or --mode=self-hosted) picks the deployment topology, trust roots, and commercial framing.

Hosted variant: Synthology-operated multi-tenant cluster (Azure Central US Phase 1; multi-region Phase 4). Per-tenant subscription with metered overages on volume. Continuous upgrade cadence; customer never schedules an upgrade.
Self-hosted variant: customer-operated single-tenant. Same .NET binary, --mode=self-hosted startup flag. Perpetual .lic file. Customer-driven upgrade cadence matching the rest of the Synthology fleet.
Transport: outbound-initiated mTLS WebSocket from on-prem Router → SynthCloudConnect endpoint. Long-lived connection; push notifications and result pulls multiplex over the same channel. Same transport pattern proven by SynthGateway since 2026 Q2.
Trust roots: hosted variant uses Synthology CA (issued via SynthGateway PKI bootstrap). Self-hosted variant uses customer CA (each deployment self-issues at first boot).

Common use cases

Three deployment patterns.

Pattern 1

AI vendor → on-prem Router result delivery

The flagship deployment. Your AI vendor lives in their own cloud, your Router lives in your DC behind a firewall that blocks inbound. SynthCloudConnect bridges the gap with no firewall changes.

Flow

1 On-prem Router sends pseudonymized study to AI vendor (existing outbound C-STORE, unchanged)
2 AI vendor processes and produces a result (DICOM SR, derived SC, or DICOM PR)
3 AI vendor C-STOREs result to SynthCloudConnect endpoint (configured destination)
4 SynthCloudConnect holds the result, sends push notification over the on-prem Router's open WebSocket
5 On-prem Router pulls the result, forwards to local PACS / viewer via existing DICOM

Pattern 2

Multi-site result aggregation

You operate a federation — multiple imaging centers, multiple Router fleets, one AI vendor contract. Each site sends to AI; each site needs its OWN results back. SynthCloudConnect routes results to the originating tenant by mTLS cert subject.

Flow

1 Each Router fleet establishes its own outbound mTLS WebSocket to SynthCloudConnect (one per tenant)
2 AI vendor includes tenant identifier in C-STORE association (or embedded in study metadata)
3 SynthCloudConnect routes result to the matching tenant's queue
4 Each tenant's on-prem Router pulls only its own results — strict tenant isolation

Pattern 3

Customer-hosted single-tenant (compliance-driven)

You're in a regulatory regime (e.g., a country with data-sovereignty laws, or a customer with internal "no third-party BA" policy) that requires SynthCloudConnect to run in your own cloud. Same product, customer-operated.

Flow

1 Customer deploys SynthCloudConnect via Terraform into their own AWS / Azure / GCP region
2 Customer remains the HIPAA covered entity; no BAA with Synthology required for this product
3 Customer self-issues CA; Routers connect to the customer-hosted endpoint
4 AI vendors C-STORE to the customer-hosted endpoint; results never leave customer cloud

Integration points

What SynthCloudConnect connects to.

On-prem endpoints (the result recipients)

XyDromatics Router — first-class integration; AI-vendor routing rules already produce the outbound C-STORE
SynthIQ — receives result via DICOM C-STORE; affinity store ensures it lands on the original-study backend
Customer PACS / viewer — direct delivery via the on-prem Router's existing forwarding rules

AI vendor connections (the result senders)

Aidoc, Riverain, RapidAI, Gleamer, Cleerly, Hyperfine — any AI vendor that produces DICOM SR / SC / PR results
C-STORE delivery to a SynthCloudConnect endpoint (standard DICOM-conformant SCP, no proprietary protocol)
AE-title + tenant identification negotiated at association time

Cloud infrastructure (hosted variant)

Synthology-owned Azure subscription (Central US Phase 1)
Multi-region expansion in Phase 4 (West US, East US, Western Europe)
Per-tenant Kubernetes namespace (Tier 2 Premium) or shared cluster (Tier 1 Standard)
Cloudflare in front of the public endpoint for DDoS protection + cert management

Self-hosted deployment targets

Phase 1: Terraform module — AWS / Azure / GCP IaaS
Phase 2: MSI installer for Windows VM (same packaging as SynthIQ + Router)
Phase 2: RPM / DEB for Linux VM (same systemd unit pattern as the Router family)
Phase 3: Helm chart for in-customer Kubernetes

Availability & roadmap

Generally available — and still expanding.

SynthCloudConnect is generally available: deploy it self-hosted today, or use the Synthology-hosted multi-tenant service. The phases below show what has shipped and what lands next as commercial demand allows.

Phase 0 · IP + regulatory groundwork — DONE

USPTO Serial 99824305 filed · .com + .net domain registrations secured · Non-device software under FD&C Act §520(o)(1)(D) — no FDA Device Listing required · DCR-2026-046 product definition + DCR-2026-047 v2 regulatory classification approved in PROD QMS.
Phase 1 · Self-hosted Terraform release — AVAILABLE NOW

Container image + Terraform module targeting AWS / Azure / GCP IaaS. Customer-CA-rooted trust path. Single-tenant by definition. Available today.
Phase 2 · Hosted multi-tenant Tier 1 Standard — AVAILABLE NOW

Synthology-operated Azure cluster (Central US). Shared cluster + per-tenant KEK + per-tenant SQLCipher DB. BAA signed with each customer.
Phase 3 · MSI / RPM / Helm packaging

Windows VM MSI + Linux VM RPM/DEB + in-customer Kubernetes Helm chart. Same packaging discipline as the rest of the Synthology fleet.
Phase 4 · Multi-region hosted + Tier 2 Premium tenancy

Hosted variant expands to West US + East US + Western Europe regions. Tier 2 Premium per-tenant dedicated namespace or VM for customers with stricter isolation requirements.

Documentation

The controlled-document set.

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

Frequently asked

The questions prospects ask.

Why not just open an inbound firewall hole to the on-prem Router?

Most customer security policies forbid inbound traffic from third-party vendors — including from AI vendors and from Synthology itself. Enterprise security teams require all customer-to-cloud traffic to be outbound-initiated and TLS-terminated at the customer perimeter. SynthCloudConnect respects this posture; the on-prem Router opens the WebSocket *outward*, and the cloud side never initiates anything customer-facing.

How is this different from SynthGateway?

SynthGateway carries telemetry + support traffic (engineer remote-access sessions, health metrics, log telemetry) — a control plane. SynthCloudConnect carries clinical-result payloads — a data plane for DICOM. They use the same outbound-initiated mTLS transport pattern but serve different traffic. They can coexist on the same on-prem Router fleet.

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. Same framework as XyDromatics Router, SynthIQ, and the rest of the Synthology software fleet. SynthCloudConnect transits DICOM result communications and holds them temporarily; it does not alter image data, generate diagnostic output, or make clinical decisions. Customers can purchase and deploy without waiting on FDA premarket clearance. Full classification analysis: DCR-2026-047.

How long do results sit in the queue?

Configurable per-tenant TTL. Default 7 days; max 30 days. After TTL expires, results are purged. On-prem Routers typically pull within seconds of the push notification, so steady-state queue depth is near-zero — the TTL exists to bridge transient on-prem Router outages.

Is SynthCloudConnect available today?

Yes — SynthCloudConnect is generally available. Non-device software under §520(o)(1)(D) (no FDA Device Listing required); USPTO trademark Serial 99824305 filed; the DCR-2026-046 product definition and DCR-2026-047 v2 regulatory classification are approved in PROD QMS. Deploy it self-hosted today — a Terraform module for AWS / Azure / GCP IaaS — or use the Synthology-hosted multi-tenant Tier 1 Standard service. MSI / RPM / Helm packaging and additional hosted regions (Tier 2 Premium) follow on the roadmap.

Does SynthCloudConnect replace SynthGateway?

No — they're complementary. SynthGateway handles operational traffic (remote support, health telemetry); SynthCloudConnect handles DICOM result traffic. A customer site can run both; each has its own WebSocket, its own license feature flag, and its own trust path. They share the underlying transport pattern (mTLS, Cloudflare-fronted endpoint) but are independent products with independent license + audit posture.

See SynthCloudConnect in action.

SynthCloudConnect is generally available — deploy it self-hosted today, or run it on the Synthology-hosted multi-tenant service. Book a demo to see the cloud-to-on-prem result path end to end.

Book a demo See the full product family