Five archive hosts. One intended use per binary.
The XyDromatics VNA Family is five sibling products built on a shared Router-pattern scaffold. Each sibling has a single, deliberate intended use that matches its deployment — and all five are non-device software under FD&C Act §520(o)(1)(D), transferring, storing, converting, and displaying medical device data without clinical interpretation.
The split is intentional. Intended-use scope is a code boundary, not a config flag — different intended uses mean different binaries. A customer deploying VNA Repository for legacy archive doesn’t accidentally pull in VNA Clinical functionality, and a VNA Clinical deployment doesn’t pull in non-clinical retention features.
Five siblings
Pick the host that matches your use case.
Each sibling has its own product page with full architecture, capability matrix, deployment guide, and regulatory framing.
XyDromatics VNA Repository
Non-deviceRetention-tier vendor-neutral archive
The cold storage of last resort for data that has to live somewhere but isn't actively queried in clinical workflow. Where data from retired PACS, decommissioned VNAs, M&A-acquired-hospital archives, and retention-window compliance goes.
XyDromatics VNA Migration
Non-deviceLegacy-PACS drain into VNA Repository
One-time / project-scoped bulk ingest from legacy PACS into the Repository. Source discovery, batched retrieval, transform pipelines, crosswalk CRUD, rejection-queue triage. Migration forwards to the Repository over the wire — no shared process space — keeping the regulatory boundary visible.
XyDromatics VNA Research
Non-deviceResearch-use-only DICOM storage
Research-use-only (RUO) DICOM storage for institutions running their own research programs. De-identified study aggregation, cohort building, IRB-aligned access controls. Explicitly labeled "Not for diagnostic use" at every interaction surface.
XyDromatics VNA Clinical Research
Non-deviceClinical-research workflows on RUO data
Clinical-research workflow orchestration: cohort definition, study aggregation, de-identification gates, IRB-aligned auditing. Sits adjacent to Research; the two share a binary scaffold but Clinical Research has the workflow layer on top.
XyDromatics VNA Clinical
Non-deviceDiagnostic clinical archive — Non-Device · §520(o)(1)(D)
The production clinical archive — actively queried in clinical workflow. Audit-trailed clinical-tag-edit (metadata correction with second-person sign-off), report transport with PowerScribe / Fluency template compatibility, and hospital-grade HA pairing. Its clinical-interpretation features (diagnostic viewer + report authoring) ship locked and un-licensable at GA — enabled only for Synthology development partners under a separate non-commercial arrangement, never for customers — which is what keeps the shipped product non-device software under FD&C Act §520(o)(1)(D).
Why split the family
Regulatory boundaries are code boundaries.
One intended use per binary
All five siblings perform functions that fall squarely within FD&C Act §520(o)(1)(D) — they transfer, store, convert formats, and display medical device data without clinical interpretation. Per the controlling statute, they are not devices. Each sibling is scoped to a single intended use, so its capability set stays bounded. Different intended use ⇒ different binary. The customer never has to wonder which one they’re running.
Code segregation enforces the boundary
The retention and research siblings have no compile-time
reference to Synthology.Vna.Clinical.Reporting
or to the clinical_tag_edit
license feature. A licensing mistake or a config-flag
slip can’t accidentally enable clinical-archive
functionality on a retention host — the code
isn’t in the binary to enable.
Customer deployment matches the regulatory frame
A customer building a legacy-archive consolidation deploys Repository + Migration. A customer running an institutional research program deploys Research or Clinical Research. A customer running a production clinical archive deploys Clinical. All five Non-device siblings ship today as non-device software under FD&C Act §520(o)(1)(D).
Audit visibility
Because each binary has one classification, a regulatory audit on any single product is bounded: the SBOM is one binary’s SBOM, the threat model is that product’s threat model, the change-control gate is that product’s gate. No "this feature is in scope of regulation A in this license tier but not in that tier" arguments.
More detail
Where to read further.
- /regulatory — the firm-level posture page (FD&C Act §520(o)(1)(D), ISO 13485–aligned QMS, CVD program).
- Individual sibling product pages linked above each carry their own capability matrix, deployment guide, DICOM Conformance Statement reference, and per-binary regulatory framing.
- For procurement teams: each sibling can be evaluated independently. We do not require the family to be deployed as a bundle.