XyDromatics VNA Repository — where retired data lives.

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 VNA Clinical or your existing production VNA. Repository sits underneath whichever primary archive you run, holding retired data that ages out of the production tier.

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, VNA 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.

Different role in the imaging stack. VNA Repository is the retention tier where retired or aged-off data lives — store-and-forward, no clinical interpretation. VNA Clinical is the active clinical archive 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.

Standing engineering rule across the VNA 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.

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.

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.

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.

Yes — Windows and Linux. The MSI installer covers Windows; a self-contained Linux tarball covers Linux. Both are supported equally; HA pairs can mix OS platforms.

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.

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. No FDA Device Listing required; no premarket review applicable. Same framework as every other Synthology product. See /regulatory for the full posture.