XyDromatics™ Repository —
where retired data lives.
The retention-tier archive. When a PACS or VNA reaches
end-of-life — but its data has to live somewhere for
compliance, retention windows, legal holds, or
“we might need this someday” — Repository is
where it goes. Migration tools drain retiring systems into
it; rare clinical lookbacks and audit retrievals read from
it; nothing else routinely touches it.
Not your active clinical archive — Repository is the
cold tier underneath, and
its Non-device software classification reflects exactly that —
store-and-forward, no clinical interpretation in the active
workflow.
Pluggable storage. Pluggable catalog. Lifecycle-driven tiering.
Hash-chain audit for regulated retention. The architecture
choices below are what distinguish a VNA from a PACS archive
you can’t move off of.
Migration-driven ingest
The primary write path: bulk migration of data from retired systems, not real-time clinical traffic.
Direct writes from XyDromatics Migration Engine (the typical writer)
Direct writes from XyDromatics Migration (large-scale retirement engagements)
C-STORE SCP + STOW-RS endpoints supported, but not the steady-state pattern
Per-AE-Title access control restricts who can write — typically just the migration tool
Duplicate-study detection at SOP Instance UID level
Backpressure semantics during long migrations — sender sees clear throttling
Pluggable archive storage
Where the actual pixel data lives. A storage-provider abstraction backs the archive; the local-filesystem provider ships today, with additional backends on the roadmap.
Local filesystem — the default storage backend (point it at any mounted volume, including an NFS/SMB-mounted NAS path); S3-compatible object stores and Azure Blob Storage ship in the same binary and are selected by configuration
Storage-provider abstraction (IStorageProvider) lets future backends drop in without re-ingesting
S3 and S3-compatible object stores — ships today (AWS S3, Cloudflare R2, Backblaze B2, Wasabi, MinIO and other S3-compatible endpoints via a configurable endpoint and path-style option), selected by configuration
Dedicated NAS providers (native NFS/SMB drivers) — roadmap
Encryption-at-rest follows the host volume today; per-backend encryption arrives with the additional providers
Pluggable catalog database
Where the metadata + indexes live. A catalog-store abstraction (IArchiveStore) backs the metadata; PostgreSQL is the shipping, supported driver in v1.0.
PostgreSQL (the supported catalog driver in v1.0, Npgsql) — others are gated off at startup until released
Catalog-store abstraction (IArchiveStore) — SQL Server and Oracle drivers are present in the codebase but not yet enabled/supported (roadmap)
No SQLite for production VNA — by Synthology standing rule for the archive family
Schema-managed migrations with versioned upgrade scripts
PostgreSQL replication for HA today; SQL Server AG / Oracle RAC arrive with those drivers
Retrieval for occasional access
Reads happen rarely — compliance audits, legal-hold extraction, the occasional patient lookback. Standard interfaces, sized for low-rate access.
QIDO-RS (Query) — find studies / series / instances over HTTP
WADO-RS (Retrieve) — bulk retrieval as multipart/related
WADO-RS instance retrieval (path-based)
Native DICOM C-FIND / C-MOVE / C-GET for SCU clients
No real-time arrival notifications (Repository isn't a live clinical feed)
Configurable response paging (limit / offset) on QIDO-RS queries
Retention & legal hold
Govern how long studies live and pin individual studies past their disposal date. This is the wired lifecycle surface in v1.0; automated multi-tier storage movement is on the roadmap.
Age- and modality-based retention policies — studies older than a configurable minimum age, optionally filtered by modality, in preview or delete mode with legal holds excluded (operators encode each jurisdiction's window as its own policy)
Litigation / legal hold — pin specific studies past their retention end
Retention-end disposal recorded on the policy row — studies deleted, bytes reclaimed and failures counted per sweep, with the operator-review "preview" mode as the pre-deletion control
Modality- and age-aware policy rules (body part, study description and arbitrary tag predicates are not supported)
Multi-tier storage — assign a study to a tier and physically relocate its bytes to that tier's own backend, verified end-to-end (read, hash-check, write, read-back-verify, re-point the catalog, then delete the source). Operator-invoked today; policy-driven automatic hot → warm → cold aging is on the roadmap. With no per-tier backend configured, a tier change is a label only.
Hash-chain audit & retention
Cryptographic integrity proof for every study from ingest through retention end.
Per-instance SHA-256 content digest recorded in the catalog at ingest and re-verified by the integrity scrubber — detects bit-rot and file substitution (this is per-object hashing, not a chained log)
HIPAA access audit trail — every state-changing API call and PHI-adjacent read records who, which study, and when, with a 6-year compliance archive, alongside a DICOM transfer audit row per inbound C-STORE — calling AE, called AE, peer IP, study UID and disposition (no electronic signature or reason-for-change capture)
Retention policies scoped by study age and modality, each running archive-wide — a multi-jurisdiction site encodes the shortest applicable window as its age threshold
Litigation hold capability — pin specific studies past their retention end
Cryptographic receipt available for any study at any time
Built-in integrity sweep — a scheduled background scrub plus an on-demand full-archive run (POST /api/integrity/scrub) re-verifies each instance's stored SHA-256 and file availability. Local-filesystem backends only; object-store durability is delegated to the store.
Operations & administration
The day-to-day surfaces operators use to run the archive.
Web administration UI with shared sidebar shell (consistent across XyDromatics)
Role-based access control with full permission catalog
Structured JSON logs + standard health endpoints for load-balancer probes
Backup + independent integrity-sweep tooling included
Capacity-projection reporting and webhook event notifications — roadmap
Architecture
A retention tier, not a clinical archive.
Writers are migration tooling, not modalities. Readers are
rare-access — compliance, legal hold, occasional clinical
lookback — not routine diagnostic viewers. Storage backends
and catalog DBs remain independently swappable substrates
underneath.
The catalog and the storage backend are independent — change one
without touching the other. The same physical study can move
across storage tiers over its lifetime while its catalog row
stays put. The hash-chain log proves nothing in either layer
was tampered with at any point in that journey.
For a typical retired-system retention engagement, the
right-sized writer is the
XyDromatics Migration
Engine — a small-footprint standalone migration appliance.
Reach for Migration when the source archive is multi-PB
or spans many vendor systems. The Router’s rule engine,
MWL, and hold queue aren’t needed for retention writes;
Migration Engine is purpose-built for this shape.
Common use cases
Five retention-archive patterns.
Every pattern below shares the same core shape: data has to
live somewhere, but it isn’t the data your radiologists
query daily. Production-clinical workflows belong on a
different product (your existing primary clinical
archive); Repository is the cold tier underneath.
Pattern 1
Retired PACS / VNA retention
The primary pattern. A legacy PACS or VNA reaches end-of-life. Its data has to live somewhere for the retention window — but the customer doesn't want to migrate it into their production clinical archive (different schema, different reading workflows, "we never touch this data anyway"). Repository is where it goes.
Flow
1Migration Engine drains the retiring PACS / VNA into Repository
2Each study verified, hash-chain entry written
3Retention policies govern each study's disposal date as it ages
4Repository is queryable for the rare lookback, but not part of routine clinical workflow
5Retention-end disposal happens per policy with a final hash-chain entry as proof
Pattern 2
Compliance / legal-hold archive
A separate retention tier for studies subject to specific regulatory windows (state laws, federal trials, malpractice litigation holds). Hash-chain audit becomes the retention proof. Often a customer's only Repository — a small archive holding only the regulated subset.
Flow
1Source-side workflow tags studies for compliance retention
2Migration Engine writes the tagged subset to Repository with hash-chain receipt
3Lifecycle rules respect the longest-applicable retention window
4Litigation hold pins individual studies past normal disposal
5Audit export produces tamper-evident retention proof on demand
Pattern 3
M&A acquired-hospital archive consolidation
Health-system acquisitions inherit imaging archives the parent system doesn't want to fold into its production stack. Repository absorbs the acquired data so the acquired hospital's legacy environment can be retired without losing the historical record.
Flow
1Pre-close: discovery against the acquired hospital's archives
2Migration tooling drains the acquired system into the parent's Repository
3The originating AE title is recorded on every archived study and instance, so each acquired hospital's data stays attributable after consolidation
4Acquired-hospital legacy systems retired post-migration
5Future M&A waves add their own source AE titles, so later acquisitions stay distinguishable in the same archive
Pattern 4
Production-archive cold tier
A customer's active clinical archive (any production VNA) reaches a defined "cold age" for studies — say, anything older than 5 years that hasn't been touched in 18 months. Those studies tier down into Repository, freeing primary-tier capacity without losing the historical record.
Flow
1Production VNA defines the cold-age policy
2Lifecycle process migrates qualifying studies to Repository
3Production VNA retains the catalog stub for query-ability
4On the rare retrieval, production VNA queries Repository transparently
5Repository's lower per-TB cost compensates for the indirection
Pattern 5
Multi-site retention with replication
Each site runs its own Repository for its retired-data tier. Site-to-site replication keeps a copy where you need it today; a federated cross-site query layer is on the roadmap.
Flow
1Site A and Site B each retain their own retired data in local Repository
2Site-to-site replication mirrors a configured study set to a peer Repository (wired today)
3Each Repository answers QIDO-RS / WADO-RS against its own catalog
4Audit trail records retrievals with originating identity
5A single federated query across all sites without centralizing data — roadmap
Integration points
What Repository connects to.
Organized by interaction direction. A VNA spends most of its
life listening to writers and answering readers; the integration
surfaces below are how it does each.
Inbound (writers — migration tooling)
XyDromatics Migration Engine — the right-sized writer for typical retired-system retention
XyDromatics Migration — for multi-petabyte retirement engagements
The Repository is a system of record: it is where the data lives after the PACS that produced it is gone.
Routing around a failed archive gets you a healthy node holding none
of your studies, which is not a recovery. So resilience is
cross-site replication: as each instance is
archived it is queued to every enabled peer site whose modality
filter matches, and delivered over DICOMweb STOW-RS.
A bounded reconciliation sweep then re-checks the archive against
each peer and reports how many instances are missing there. It is
deliberately throttled so it never competes with live ingest —
it exists to catch what the write path missed. That count is what
turns replication from something you trust into something you can
measure.
Replication is data protection, not request routing. It means a
second site holds your images — not that a failed archive is
transparently substituted mid-association.
Unlike Router (sized to study throughput), a VNA scales with
archive capacity, ingest rate, and catalog size. Tiers below
are starting points; final sizing comes out of discovery and
accounts for retention windows + storage-backend choices.
Tier
Archive capacity
Ingest rate
CPU
RAM
Catalog
Typical site
Departmental
< 50 TB
< 100 GB / day
4 vCPU
16 GB
PostgreSQL on the same host
Imaging center, single-modality clinic, ambulatory site.
Hospital
50 TB – 500 TB
100 GB – 1 TB / day
8 vCPU
32 GB
PostgreSQL HA pair (replication)
Single hospital, full modality mix, 7-year retention.
Health-system
500 TB – 10 PB
1 TB – 10 TB / day
16 vCPU
64 GB
PostgreSQL HA cluster
Multi-hospital health system, large mounted-volume archive.
Enterprise
> 10 PB
> 10 TB / day
32 vCPU
128 GB
Enterprise PostgreSQL, sharded if needed
Large IDN, national reading network, multi-site replication.
Full hardware/software requirements are in
DOC-2026-059 (HW/SW Requirements),
available under NDA. Includes OS support matrix, supported
databases (with version ranges), storage-backend matrix, and
network requirements.
Licensing
One licence, all features. A valid site licence grants every generally-available Repository capability — DICOMweb, replication, retention, legal hold and integrity verification included; role-based access control, not per-feature licensing, governs who can use what. Archive size is bounded by the storage you provision, not by the licence.
Core is the base archive. DICOMweb adds modern retrieval
interfaces, outbound forwarding, and replication. Lifecycle adds
retention governance and legal hold (with pluggable storage
backends and automated tiering on the roadmap). Enterprise
unlocks 21 CFR Part 11 hash-chain audit, PostgreSQL HA, and
unlimited capacity.
Repository Core
The base archive — DICOM ingest, single storage backend, single catalog DB, classical Q/R.
C-STORE SCP / STOW-RS ingest
Local-filesystem storage backend
PostgreSQL catalog
DICOM C-FIND / C-MOVE / C-GET
Web admin UI + RBAC
Archive size limited only by the storage you provision — the licence enforces no capacity ceiling
Licensing is per-deployment, capacity-tiered. Storage costs are
separate (you bring the storage backend). Multi-product bundles
(Repository + Router + Migration Engine) get
product-bundle pricing; multi-site customers get site-discounted
bundles. Specific pricing in your engagement SOW.
Documentation
The controlled-document set.
Current GA release
v1.0.2.182·released 2026-08-05
Every XyDromatics Repository 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.
What’s new·v1.0.2.182
Flexible object storage, sealed backup, and a deeper Study Browser
▸Choose where archived objects live — local disk, Amazon S3 (or an S3-compatible store), or Azure Blob Storage — with storage credentials sealed at rest.
▸Sealed, off-site catalog backup with non-destructive restore-to-staging, so a rebuilt host can be recovered from a single encrypted bundle.
▸Study Browser drill-down — expand a study into its series and instances, inspect DICOM tags at each level, and copy the Accession, Patient ID, or Study UID in one click.
▸New operator tools — a PHI-scrubbed log viewer, per-study route/study trace, and graceful listener maintenance (pause and drain) for servicing without dropping in-flight work.
▸In-app help refresh across the console — each topic explains what the page does, how to do it, a worked example, and the permission it requires.
Annex to the Synthology Master EULA (DOC-2026-063)
DOC-2026-148
Penetration Test Results (XyDromatics Repository)
Available under NDA
DOC-2026-143
QA Runner Manual (XyDromatics Repository)
Internal QA + customer-validated test runs
DOC-2026-159
User Guide (XyDromatics Repository)
Operator + administrator workflows
DOC-2026-164
Installation Guide (XyDromatics Repository)
Includes MSI deploy + Linux tarball install
Frequently asked
The questions prospects ask.
Can I use Repository as my primary clinical archive?
No. Repository is the retention tier — designed for data that has to live somewhere but isn't actively queried in clinical workflow. Your primary clinical archive should be an active clinical archive or your existing production VNA. Repository sits underneath whichever primary archive you run, holding retired data that ages out of the production tier.
What writes to Repository?
Migration tooling, almost exclusively. The typical writer is the XyDromatics Migration Engine — a small-footprint standalone migration appliance that's the right size for draining a retired PACS or VNA into Repository. For multi-PB or multi-vendor consolidation engagements, Migration is the heavyweight option. Modalities and the Router don't typically write to Repository in steady-state operation — they write to the production clinical archive. Repository receives data when it ages off the primary tier or when a retiring system gets drained into it.
How is Repository different from an active clinical archive?
Different role in the imaging stack. Repository is the retention tier where retired or aged-off data lives — store-and-forward, no clinical interpretation. An active clinical archive is where radiologists query and report. Both are non-device software under FD&C Act §520(o)(1)(D). The non-device classification fits Repository precisely because it's store-and-forward without clinical interpretation in the active workflow. They ship as separate executables on separate ports — same code base, same libraries, but a product boundary that's also a code boundary.
Why not SQLite for the catalog?
Standing engineering rule across the archive family: the production VNA catalog targets enterprise RDBMSs over real ADO.NET drivers (PostgreSQL ships today; SQL Server and Oracle drivers are on the roadmap). SQLite is fine for engines that don't back a regulated archive (Router can use SQLite for small deployments), but a VNA catalog routinely holds millions of studies and tens of millions of catalog rows where SQLite's concurrency model breaks down. The rule is in our memory file as a permanent decision.
Can we change storage backend after we've started ingesting?
The catalog references studies by logical key, not by physical path, so the architecture is built to swap storage providers without re-ingesting. In v1.0 the shipping provider is the local filesystem (point it at any mounted volume, including an NFS/SMB-mounted NAS path); additional providers (S3-compatible object stores, dedicated NAS drivers) and the online storage-migration tool are on the roadmap.
Does Repository do automated hot/warm/cold storage tiering?
Not in v1.0. Today Repository governs data lifecycle through retention policies and legal holds (with hash-chain audit of disposal), on a single storage backend. Automated multi-tier movement across backends — e.g. cold studies aging onto S3 Glacier-class storage with recall-on-demand — is on the roadmap and is gated off in the shipping build.
Q: How does the archive integrity verification work? A: Every instance is hashed with SHA-256 as it is written, and the digest is stored on its catalog row. A background integrity scrubber re-reads instances on a rolling schedule and re-computes the digest; a mismatch is recorded as a hash_mismatch finding, and a missing or unreadable file is recorded as its own finding for operator triage. An operator can also trigger a full-archive scrub on demand, and can request a per-study attestation (GET /api/integrity/study-attestation) listing every instance's digest and verification state. This detects bit-rot, truncation and file substitution. Object-store backends delegate durability and integrity to the store itself, so the local bit-rot scan does not run there.
Every write to the archive creates a chain entry: SHA-256 of (study identifier + ingest timestamp + previous chain hash + study content hash). Tampering with any single entry breaks the chain at that point and is detectable by re-running the integrity-sweep tool. The chain root is the hash auditor will verify; we publish the most recent chain root in the regulated audit log so a tamper at any earlier point is provable.
Is Repository cross-platform?
Yes — Windows and Linux. The MSI installer covers Windows; a self-contained Linux tarball covers Linux. Both are supported equally. Availability is provided at the PostgreSQL tier using whatever replication your database team already operates, so the application host itself is a single instance per site.
How is data deleted at retention end?
Lifecycle rules can be configured to either move studies to a disposal-pending state for human review, or trigger automatic deletion. Automatic deletion records a final hash-chain entry that proves the disposal happened — auditable retention proof is part of the deal. Litigation hold can pin individual studies past their retention end indefinitely; the holds are themselves audited and require approver sign-off.
What's the regulatory classification?
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. Same framework as every other Synthology product. See /regulatory for the full posture.
Talk through your archive needs.
Tell us your environment — current archive, retention windows,
storage standard — and we’ll come back within one
business day with a proposed architecture and a 30-minute
walkthrough with the right engineer on our side.
