# 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](/content/products/vna-repository/index.html)

### 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](/content/products/vna-migration/index.html)

### 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](/content/products/vna-research/index.html)

### 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](/content/products/vna-clinical-research/index.html)

### 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](/content/products/vna-clinical/index.html)

## 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](/content/regulatory/index.html) — 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.