Historical + fleet analytics · Aggregate-only · Non-device software

SynthInSight™ — the questions your dashboards can't answer.

A standalone analytics surface over the operational history your Synthology products archive. All-time and cross-router aggregate questions, answered by an embedded columnar engine — entirely off the hot ingest path.

Aggregate-only by design. Counts, distinct-counts, and daily series — never row-level PHI. Deploys independently of every other product, on Windows or Linux.

Request a demo See the product

Identifiers & classification

Classification: General-purpose business software · Non-medical-device
Product code: N/A
Clinical function: None
Platforms: Windows · Linux
Data posture: Aggregate-only (no row-level PHI)
FDA listing: Not required (not a medical device)

Full regulatory posture →

The problem · Capabilities · See it · API · Use cases · Integrations · Availability · Sizing · Licensing · Documentation · FAQ

Current GA release v1.0.2.91·released 2026-08-02

The problem SynthInSight solves

Operational databases are built for ingest, not history.

The hot-path squeeze

A router\'s operational database has one job during the day: keep up with C-STORE ingest. To stay fast it prunes old rows past a retention window. That keeps ingest healthy — but it means the long-tail history is gone, and any heavy "all-time" query you do run competes with live ingest for the same database.

Run a multi-year scan against that database and you slow the thing clinicians depend on. Don\'t run it, and you can\'t answer the question.

With SynthInSight

Each product archives the rows it prunes to a compact, columnar-ready gzipped-NDJSON file — off the hot database. SynthInSight reads that archive with an embedded columnar engine built for big aggregate scans.

All-time and cross-router questions get answered on a surface that never touches the ingest path — and the answers are aggregate-only, so there\'s no row-level PHI to govern.

Capabilities

What SynthInSight actually does.

All-time + cross-router analytics

The questions your live operational dashboards can't answer.

Aggregate queries over the full archived history — beyond the operational database's rolling retention window
Counts, distinct-counts, daily series, breakdowns, timeseries and percentiles across every archived table — Router, SR Engine, Pathology, Migration Engine, VNA Migration, Encounter Engine, De-Identification Engine, SynthIQ and Repository all write archives today
Cross-router: point one SynthInSight at the archives of several routers to answer fleet-wide questions
Filter daily series by event type (received / forwarded / failed …)
Queries run entirely off the hot path — analytics load never competes with C-STORE ingest

Managed-writer / native-reader split

The architecture that keeps the regulated products native-dependency-free.

Each product WRITES with Synthology.Shared.Analytics.EventArchiver — pure-managed, BCL-only, zero native dependency
Archive format is gzipped NDJSON, Hive-style date-partitioned: {root}/{table}/dt=YYYY-MM-DD/part-*.ndjson.gz
SynthInSight READS with an embedded DuckDB columnar engine — the only place the native query engine lives
No regulated ingest product ever pulls in the DuckDB native binary
Immutable part files — never rewritten in place; closed partitions compact to columnar Parquet, and oldest-first purge protects a full archive volume

Aggregate-only — PHI-safe by design

A reporting surface, not a data browser.

Returns counts, distinct-counts, daily series, and de-identified records — never a patient identifier
COUNT(DISTINCT patient_id) is a number, never the identifiers
No study browsing, no pixel access; record export is de-identified only (no patient identifiers)
Row-level PHI access stays on the customer's on-prem clinical systems, by design

Gated + independently deployable

Locked down and decoupled from the rest of the fleet.

Bearer-token-gated API (Authorization: Bearer …); fail-safe deny when no token is configured
/api/health + /api/version stay open for liveness / monitoring probes
Deploys independently of SynthIQ and every other product — analytics is never gated on a product you may not own
Co-locate with a router reading its local archive, or point at an aggregated/mounted path
Windows MSI or Linux (systemd) — installs the same on both

API surface

A small, PHI-free HTTP API.

Liveness is open; every analytics endpoint is bearer-gated and returns aggregates or de-identified records — never a patient identifier.

Method	Path	Auth	Returns
GET	/api/health	open	status, version, archive root, archive_exists, auth_required
GET	/api/version	open	product + version
GET	/api/analytics/{table}/count	Bearer	all-time row count for a table
GET	/api/analytics/{table}/distinct?column=	Bearer	COUNT(DISTINCT column) — a number, PHI-safe
GET	/api/analytics/{table}/daily?event_type=	Bearer	per-day series, optionally filtered by event type

See it

Fleet history, on screen.

Live captures from a running installation — click any screen to enlarge it.

The whole archive

Switch from a 30-day window to everything the fleet has ever reported — 100,000+ events, 7,500 studies — with the same breakdowns by application, event type and modality.

Common use cases

Three things people reach for it for.

Pattern 1

Answer "all-time" questions past the retention window

Operational databases prune old rows to stay lean and keep ingest fast. SynthInSight preserves the full history off the hot path so you can still ask all-time questions.

Flow

1 A product prunes its operational log past the retention window (rollups keep recent aggregates)
2 Before each prune, the product archives the rows it is about to delete to gzipped NDJSON
3 SynthInSight reads the archive and answers since-install / multi-year aggregate questions
4 The hot database stays bounded; long-term history lives in the archive (oldest days are purged only if the archive volume fills past 85%)

Pattern 2

Cross-router fleet analytics within a customer deployment

A health system running several routers wants one place to see totals across all of them — without standing up a heavyweight warehouse.

Flow

1 Each router writes its archive to a shared path or mounted volume
2 SynthInSight points at the aggregated archive root
3 Aggregate queries fan across every router's partitioned part files (union by name)
4 Fleet-wide counts, distinct-counts, and daily trends from a single endpoint

Pattern 3

Forensic / audit lookback off the hot path

A compliance or capacity question needs a heavy scan over months of events — the kind of query you never want to run against the live ingest database.

Flow

1 SynthInSight scans the columnar archive with DuckDB
2 Heavy aggregate scans run on the analytics surface, not the operational DB
3 The C-STORE ingest path is never touched by the query

Integration points

What feeds it, what reads it.

Producers (what feeds the archive)

XyDromatics Router — first producer; archives routing_log (operator enables it in Settings → SynthInSight Analytics Archive)
SR / Migration / Pathology / Encounter Engines + archive family — as each adopts the Synthology.Shared.Analytics writer
The product↔SynthInSight link is a shared filesystem path / mounted volume — no network call from the product

Consumers (who reads SynthInSight)

Operators + dashboards via the bearer-gated HTTP API
SynthIQ may optionally consume the same engine for fleet observability (roadmap)
Any tool that can make an authenticated HTTP GET

Roadmap

Tier-2 fleet-central analytics fed by the SynthGateway health_telemetry channel (cross-site, Synthology-operated)
Richer query surface (additional aggregates, more archived tables) as producers expand

Availability

One instance, and one copy you should not rely on.

SynthInSight receives no DICOM and runs no external database. It is a single read-mostly analytics engine over a local analytics lake, so there is no pool to join and nothing to fail over — if the host is down, dashboards are unavailable until it returns, and no clinical traffic is affected either way.

The part that deserves your attention is durability, not uptime. Products keep roughly a week of analytics locally and then prune, so the lake SynthInSight holds is the only long-term copy of your operational history. Lose that host without an off-host copy and the history is gone — not degraded, gone.

Turn on lake replication. It mirrors the lake to immutable off-host storage, authenticated by the host’s managed identity so there is no credential to store or rotate. Because lake partitions are immutable, replication is incremental — anything already at the destination is skipped. It ships off by default, which means it is a deployment decision someone has to actually make. Make it.

How availability works

System requirements & sizing

Light to run.

A read-only analytics host — most of the weight is RAM for DuckDB on heavy scans. Storage is the archive itself, which lives where the producing products write it.

Tier	Scope	CPU	RAM	Storage	Notes
Single router	one product's archive	2 vCPU	4 GB	archive size + headroom	Co-located with the router; reads its local analytics-archive.
Small fleet	2–5 routers	4 vCPU	8 GB	aggregated archive	Points at a shared/mounted aggregated archive root.
Large fleet	6+ routers / multi-year history	8 vCPU	16 GB	aggregated archive	More RAM helps DuckDB on heavy multi-year scans.

Licensing

Standard and Enterprise.

SynthInSight Standard

Single-archive historical analytics over one product's event archive.

Aggregate query API (count / distinct-count / daily series)
Reads one product's gzipped-NDJSON archive
Bearer-token-gated API
Windows + Linux install

SynthInSight Enterprise

Cross-router / fleet analytics + the path to fleet-central.

Everything in Standard
Cross-router (multi-archive) aggregation
Multi-year retention scans
Tier-2 fleet-central via SynthGateway (Enterprise; on the gateway-colocated install)
Premium support tier eligible

Documentation

The controlled-document set.

Current GA release v1.0.2.91 · released 2026-08-02

Every SynthInSight deployment ships with the documents below, all managed under SynthQMS document control. They are shared under mutual NDA.

What’s new·v1.0.2.91

Faster, more resilient operational analytics — with new views and self-service config backup

Faster analytics dashboards — views refresh quickly even as your operational history grows, with result caching and columnar storage behind the scenes.
More resilient reporting — analytics keep working when an upstream data source changes shape, instead of failing.
New operational views — routing activity from SynthIQ now appears in analytics, alongside a built-in Log Files viewer and search across Settings.
Self-service configuration backup and restore to off-site storage, plus configuration export/import between installs.
Simpler licensing — activate in the app with an activation token (no license file to manage), and the app keeps your license current automatically. In-app Help expanded to a task-oriented format across the console.

Document	Title	Notes
DOC-2026-389	Hardware & Software Requirements (SynthInSight)	Sizing, OS support, DuckDB native bundled
DOC-2026-417	EULA Annex (SynthInSight)	Annex to the Synthology Master EULA (DOC-2026-063)
DOC-2026-391	End User Guide (SynthInSight)	Operator + administrator analytics workflows
DOC-2026-390	Installation Guide (SynthInSight)	Windows MSI deploy + Linux systemd tarball install

Frequently asked

The questions prospects ask.

Does SynthInSight ever see patient data?

The query surface is **PHI-free** — it returns counts, distinct-counts, daily series, and de-identified record-level rows drawn from a per-table allow-list of PHI-free columns. It never returns a patient identifier: patient_id, patient_name, accession, study UID and SOP instance are excluded from every row export, so a `COUNT(DISTINCT patient_id)` returns a number, not the identifiers. Row-level PHI access stays on your on-prem clinical systems by design. The underlying archive can contain operational fields, so you control where the archive lives and who can reach the (bearer-gated) SynthInSight host.

How does a product feed SynthInSight?

Each product writes a compact gzipped-NDJSON event archive off its hot database (the Router does this when you enable it in Settings → SynthInSight Analytics Archive and set an archive path). SynthInSight points at that same path — a shared directory or mounted volume. The link is the filesystem, not a network call from the product, so there is no inbound dependency on SynthInSight.

Do I need SynthIQ to run SynthInSight?

No. SynthInSight deploys completely independently — analytics is never gated on a product you may not own. SynthIQ may optionally consume the same engine for fleet observability on the roadmap, but that is not required.

Why DuckDB / NDJSON instead of SQL Server or Postgres?

The architecture is a managed-writer / native-reader split. Products write with a pure-managed, zero-native-dependency writer (gzipped NDJSON) so the regulated ingest products never pull in a native query engine. SynthInSight is the only place the native columnar engine (DuckDB) lives, and columnar storage is the right shape for the big aggregate scans an operational row-store handles poorly.

What's the regulatory classification?

General-purpose business software — not a medical device. SynthInSight is an operational-analytics console: it never transfers, stores, converts, or displays a medical image or any medical device data, so FDA medical-device regulation does not apply and no §520(o)(1)(D) exclusion is claimed or needed. It performs no clinical function, and the only records it surfaces are de-identified — never a patient identifier.

Windows or Linux?

Both. SynthInSight ships a Windows MSI and a Linux (systemd) tarball — the same self-contained .NET payload with the DuckDB native bundled.

See SynthInSight on your data.

Turn on the analytics archive in your router\'s settings, point SynthInSight at it, and ask the all-time questions you couldn\'t before — without touching the ingest path.

Request a demo All products