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 what it does

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

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
Count, count-distinct, and per-day series over each archived table (routing_log today; more as products adopt the archiver)
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 — the archive is an append-only forensic record

Aggregate-only — PHI-safe by design

A reporting surface, not a data browser.

Returns counts / distinct-counts / daily series only — never row-level records
COUNT(DISTINCT patient_id) is a number, never the identifiers
No study browsing, no pixel access, no per-record export
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, aggregate-only HTTP API.

Liveness is open; every analytics endpoint is bearer-gated and returns aggregates only.

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

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; history is never lost

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 + VNA 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

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 (roadmap)
Premium support tier eligible

Documentation

The document set.

Document	Title	Notes
Install Guide	Windows MSI + Linux systemd deployment	Self-contained payload; DuckDB native bundled. Set the bearer token + archive root, then start the service.
API Reference	Aggregate analytics HTTP API	health / version (open) + count / distinct / daily (bearer-gated).
Architecture Note	Managed-writer / native-reader analytics warehouse	OLTP/OLAP split; gzipped-NDJSON archive; embedded DuckDB reader.
EULA Annex	SynthInSight EULA Annex	Annex to the Synthology Master EULA.

Frequently asked

The questions prospects ask.

Does SynthInSight ever see patient data?

The query surface is **aggregate-only** — it returns counts, distinct-counts, and daily series, never row-level records. 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?

Non-device software under FD&C Act §520(o)(1)(D). SynthInSight transfers, stores, and displays aggregate operational metadata; it performs no clinical function and surfaces no row-level patient data.

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