VNA Family

Five archive hosts. One regulatory class per binary.

The XyDromatics VNA Family is five sibling products built on a shared Router-pattern scaffold. Each sibling has a single, deliberate regulatory framework that matches its intended use — four are non-device software under FD&C Act §520(o)(1)(D), and one (Clinical Tier 2) is on the SaMD Class II 510(k) path because it performs diagnostic-archive functions beyond the §520(o) carve-out.

The split is intentional. Regulatory class is a code boundary, not a config flag — different classifications mean different binaries. A customer deploying VNA Repository for legacy archive doesn’t accidentally pull in Clinical Tier 2 functionality, and an eventual VNA Clinical Tier 2 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

  • Type: Non-device
  • Description: Retention-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.
  • Classification: Non-device · §520(o)(1)(D)
  • Availability: Available today
  • Learn more: Link

XyDromatics VNA Migration

  • Type: Non-device
  • Description: Legacy-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.
  • Classification: Non-device · §520(o)(1)(D)
  • Availability: Available today
  • Learn more: Link

XyDromatics VNA Research

  • Type: Non-device
  • Description: Research-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.
  • Classification: Non-device · §520(o)(1)(D) · RUO
  • Availability: Available today
  • Learn more: Link

XyDromatics VNA Clinical Research

  • Type: Non-device
  • Description: Clinical-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.
  • Classification: Non-device · §520(o)(1)(D)
  • Availability: Available today
  • Learn more: Link

XyDromatics VNA Clinical (Tier 2)

  • Type: Class II
  • Description: Diagnostic clinical archive — SaMD Class II
    The production clinical archive — actively queried for diagnosis. Clinical-tag-edit capability, built-in reporting platform with PowerScribe / Fluency template-import compatibility, hospital-grade HA pairing, complete audit trail of every clinical-tag change. This is the one product in the family that performs functions beyond §520(o)(1)(D) and is therefore on a Class II 510(k) path.
  • Classification: SaMD Class II · 510(k) in development
  • Availability: Not commercially released until 510(k) cleared
  • Learn more: Link

Why split the family

Regulatory boundaries are code boundaries.

One classification per binary

Four of the 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. The fifth (Clinical Tier 2) goes beyond the carve-out because clinical-tag-edit is a clinical-interpretation function. Different statutory framework ⇒ different binary. The customer never has to wonder which one they’re running.

Code segregation enforces the boundary

The Non-device 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 Class II functionality on a Non-device 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 diagnostic workflow (and waiting on our 510(k) clearance) is on the Clinical Tier 2 path. The four Non-device siblings ship today; Clinical Tier 2 ships when the FDA grants clearance.

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, Class II SaMD path for Clinical Tier 2).
  • 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.