XyDromatics VNA Clinical Router-pattern host · Non-device clinical archive

XyDromatics VNA Clinical — the non-device clinical archive.

Non-device software under FD&C Act §520(o)(1)(D). Audit-trailed clinical-tag-edit (metadata correction, not interpretation), hospital-grade HA pairing, full DICOM + DICOMweb I/O, and a complete 21 CFR Part 11 audit trail. The clinical-interpretation features — a Diagnostic Viewer and a Clinical Reporting suite — ship in code but are locked and un-licensable at GA, which is exactly what keeps the product non-device: it can’t be used to clinically interpret stored images in patient treatment.

Because the Diagnostic Viewer + Reporting stay locked and un-licensable, the GA product is non-device software under FD&C Act §520(o)(1)(D).

Request a demo Why is this separate?
Why separate · Capabilities · Use cases · Integrations · Regulatory · Sizing · Licensing · Documentation · FAQ

The regulatory line

A code boundary that mirrors a regulatory boundary.

All five XyDromatics VNA products are non-device software today under FD&C Act §520(o)(1)(D) — storage and forwarding without clinical interpretation. What separates VNA Clinical (and Clinical Research) from Repository, Migration, and Research is that they carry the clinical-INTERPRETATION features — a Diagnostic Viewer and a Clinical Reporting suite — in code. In the GA build those features are locked and un-licensable, so the product still can’t be used to clinically interpret stored images in patient treatment. That locked boundary is what keeps it non-device.

We could have shipped one binary with everything license-gated. We chose not to. Shipping separate executables on separate ports means the interpretation code never runs inside the non-device-only processes — the boundary is a code boundary, not just a license check. Because the Diagnostic Viewer + Reporting stay locked and un-licensable in every shipped build, VNA Clinical remains non-device software under FD&C Act §520(o)(1)(D).

Non-device-only siblings

Repository · Migration · Research

FD&C Act §520(o)(1)(D) · no interpretation code shipped

Carry interpretation features (locked at GA)

Clinical · Clinical Research

Non-device software · §520(o)(1)(D)

Capabilities

What ships at GA — and what stays locked.

Two clinical-interpretation capabilities (marked Locked at GA) ship in code but are un-licensable in the GA build — which is what keeps the product non-device under §520(o)(1)(D). Everything else is available + licensable now and stays within the non-device boundary, comparable to VNA Repository with stricter availability and audit requirements.

Clinical-tag-edit

A GA non-device capability: it corrects DICOM METADATA, it does not interpret images. License-gated, audit-trailed, second-person sign-off.

  • Modify clinical DICOM tags after ingest (PatientName, AccessionNumber, StudyDescription, BodyPart, etc.)
  • Required reason text for every edit — captured in audit trail
  • Second-person electronic-signature workflow (21 CFR Part 11 §11.50)
  • Pre-edit + post-edit content fully retained — edits never destroy original
  • Configurable per-tag policies (which tags can be edited, by whom, with what approval)
  • Withdraw/re-issue downstream notifications when key tags change

Diagnostic Viewer

Locked at GA

A clinical-interpretation capability that ships in code but is LOCKED and un-licensable at GA — enabled only for Synthology development partners under a separate, non-commercial arrangement, never for customers. It cannot be enabled in the shipped GA build, which is what keeps the product non-device under §520(o)(1)(D).

  • Cornerstone3D rendering with MPR and 3D volume rendering
  • GSPS presentation states, Key Object Selection, secondary capture
  • CAD marker overlay / DICOM SR parsing, mammography hanging protocol
  • Prior-study comparison, patient timeline, cross-viewport reference lines
  • Bone removal, MIP / slab, window-level sync
  • Present in code, locked & un-licensable at GA — not reachable in the shipped build

Clinical Reporting suite

Locked at GA

A clinical-interpretation capability that ships in code but is LOCKED and un-licensable at GA — enabled only for Synthology development partners under a separate, non-commercial arrangement, never for customers. It cannot be enabled in the shipped GA build, which is what keeps the product non-device under §520(o)(1)(D).

  • Self-contained reporting workspace with voice-recognition dictation
  • Report template management; PowerScribe / Fluency migration
  • Patient-registration portal; auto-order from DICOM ingest
  • Custom fields from DICOM metadata, HL7 fields, DICOM SR objects, EMR context, prior-study attributes
  • Amendment / addendum / version-history workflow with audit trail
  • Present in code, locked & un-licensable at GA — not reachable in the shipped build

Hospital-grade availability

Active-active HA pair is the default deployment shape. SLA-backed uptime targets, automatic failover, no clinical downtime during patches.

  • Active-active HA pair with shared catalog state
  • Sub-second failover detection
  • Rolling-upgrade support — patch one node while the other serves clinical traffic
  • Multi-AZ deployment patterns (cloud) and multi-rack patterns (on-prem)
  • Synthetic-monitoring agent included
  • 99.95% uptime SLA available under Managed Services

DICOM I/O

Standard inbound and outbound paths, with the same pluggable storage substrate as VNA Repository.

  • C-STORE SCP (DICOM Store) — direct from any modality or routing layer
  • STOW-RS endpoint
  • C-FIND / C-MOVE / C-GET
  • QIDO-RS / WADO-RS / WADO-URI (DICOMweb)
  • Pluggable storage backends — local FS, S3-compatible, NAS
  • Pluggable catalog DB — PostgreSQL / SQL Server / Oracle (same as VNA Repository)

Audit trail (Part 11-aligned)

Every clinical-tag change recorded with the rigor 21 CFR Part 11 demands. A non-device GA capability.

  • Complete change log: timestamp, user identity, reason, pre/post values
  • Cryptographic hash chain over the audit log (tamper-evident)
  • Electronic-signature compliance (Part 11 §11.50, §11.70, §11.100)
  • Session-binding for signatures (signature applies to specific records, not bulk)
  • Audit-record export for inspection / litigation
  • Audit retention separable from study retention (audit can outlast the study)

Operations & administration

The day-to-day surfaces operators use, plus tight change-control tooling for the clinical-tag-edit policies.

  • Web administration UI (shared sidebar shell, consistent across XyDromatics)
  • Role-based access control with permission catalog
  • Real-time dashboard — ingest, retrieval, audit-event volume, HA health
  • Change-control workflow for any configuration touching clinical-tag-edit policies
  • SynthQMS integration — every config change becomes a QMS-controlled record
  • Direct integration with the validation report set

Use cases

Three typical clinical-archive patterns.

All three patterns run on the non-device GA build — storage, audit-trailed clinical-tag-edit, and non-interpretive workflow. Clinical interpretation stays in your existing viewer and reporting tools — VNA Clinical’s own Diagnostic Viewer + Reporting are locked at GA, which keeps the product non-device under §520(o)(1)(D).

Pattern 1

Clinical archive replacement

Replace a legacy clinical PACS archive with VNA Clinical. Same modality flow, same EMR integration, with audit-trailed clinical-tag-edit on top of the non-device store-and-forward you'd get from VNA Repository.

Flow

  1. 1 Modalities + Router forward studies to VNA Clinical
  2. 2 Diagnostic reports flow in via HL7 ORU / DICOM SR / FHIR DiagnosticReport
  3. 3 Clinical-tag corrections (wrong patient, wrong accession, etc.) handled in-system with audit trail
  4. 4 Long-term storage tier mirrors VNA Repository feature set
  5. 5 Clinical interpretation stays in your existing viewer/reporting tools — VNA Clinical's own viewer + reporting are locked at GA
Pattern 2

Tag-correction workflow consolidation

Today, tag corrections live in 4-6 different systems (PACS native edit, RIS, modality QC station, EMR override, manual ticket). Consolidate to one auditable workflow inside VNA Clinical.

Flow

  1. 1 Tag-correction request enters the queue (HL7-driven, RIS-driven, or manual)
  2. 2 Authorized user (per RBAC + per-tag policy) opens the edit in the audit-trailed UI
  3. 3 Required reason text + second-person sign-off captured
  4. 4 Edit applied; downstream subscribers notified per policy
  5. 5 Audit log retains pre + post for the full retention window
Pattern 3

Dual-deployment with VNA Repository

Customers running VNA Repository as the primary archive can layer VNA Clinical for the audit-trailed clinical-tag-edit + report-routing workflow without disturbing the retention-tier archive.

Flow

  1. 1 VNA Repository remains the long-term retention archive
  2. 2 VNA Clinical handles the clinical-tag-edit + report-integration workflow on a subset of active studies
  3. 3 Synchronization replicates corrected tags from Clinical back to Repository
  4. 4 Both products are non-device software under §520(o)(1)(D)
  5. 5 Customers ready to consolidate can later collapse to VNA Clinical Research (combined posture)

Integration points

What VNA Clinical connects to.

A clinical archive integrates deeply with the EMR and the reporting layer — bidirectional report-object sync and context launch — all within the non-device boundary (it transports report objects; it does not interpret images at GA). Acting as the critical-results notification system of record is not part of the non-device build under §520(o)(1)(D).

Inbound (writers)

  • Modalities (any DICOM-conformant SCU)
  • XyDromatics Router (most common)
  • Reporting platforms (HL7 ORU, DICOM SR, FHIR DiagnosticReport)
  • Manual upload via web admin (audited)

Outbound (readers)

  • Diagnostic viewers (Q/R + DICOMweb)
  • EMR / EHR systems (HL7, FHIR, image-context-launching)
  • Critical-results notification systems
  • Image-sharing portals (governed by export policies)

EMR / EHR (deep clinical integration)

  • Epic Radiant + Cupid context launch
  • Cerner PowerChart context launch
  • HL7 ORU result distribution
  • FHIR DiagnosticReport / ImagingStudy / Observation
  • Bidirectional report-amendment sync

Report transport (report objects move; authoring is locked at GA)

  • HL7 ORU, DICOM SR, FHIR DiagnosticReport — inbound for legacy reports, outbound for results distribution
  • Report-to-study linkage and reverse navigation
  • The native Clinical Reporting suite (authoring, dictation, templates, PowerScribe / Fluency migration) ships in code but is locked & un-licensable at GA
  • Because native authoring stays locked, the product remains non-device under §520(o)(1)(D)
  • Interpretation + report authoring stay in your existing reporting tools

Storage & catalog (shared with VNA Repository)

  • Local filesystem (default for small deployments)
  • S3-compatible object stores
  • On-prem NAS (NFS / SMB)
  • PostgreSQL / SQL Server / Oracle catalog
  • No SQLite for VNA family (standing engineering rule)

Authentication, audit, observability

  • OIDC / SAML for the web admin UI with second-person sign-off
  • Active Directory / Azure AD federation
  • Prometheus metrics + structured JSON logs
  • SynthQMS integration for change control
  • Hash-chain audit log with independent verification

Regulatory

Non-device software under §520(o)(1)(D).

A calm, plain statement of where VNA Clinical sits. The line is simple: a non-device cannot aid or produce any information that is acted upon in the treatment of a patient. No pending submission, no timeline to wait on — just the boundary that keeps the GA product non-device.

Classification

Non-device software

Non-device software under FD&C Act §520(o)(1)(D) — storage, forwarding, and non-interpretive workflow. No FDA Device Listing required; no premarket review applicable.

Interpretation features

Present in code, locked at GA

The Diagnostic Viewer and Clinical Reporting suite ship in code but are locked and un-licensable in the GA build. They can’t be enabled, so the product can’t be used to clinically interpret images in patient treatment.

Boundary

A code boundary, not a license check

The interpretation code ships in separate executables on separate ports and is locked & un-licensable, so it never runs in the shipped build. The product stays non-device under §520(o)(1)(D) — no current status to revisit, no pending submission.

VNA Clinical is available as non-device software under FD&C Act §520(o)(1)(D). The clinical-interpretation features stay locked and un-licensable in the shipped build, which is what keeps the product non-device. See /regulatory for the full posture.

System requirements & sizing

Sized to clinical study volume + HA mandatory.

HA pairing is mandatory at every tier — this is a clinical system, not an archive you can take down for an evening of maintenance. Tiers below are starting points; final sizing comes out of discovery and accounts for retention windows + DR-site requirements.

Tier Study volume CPU RAM HA topology Typical site
Hospital (single) < 1,000 studies / day 8 vCPU per node 32 GB per node Active-active HA pair (mandatory) Community hospital, regional reading group.
Health-system 1,000 – 5,000 studies / day 16 vCPU per node 64 GB per node Active-active HA pair, multi-AZ Multi-hospital health system.
Academic medical center 5,000 – 15,000 studies / day 32 vCPU per node, 3+ nodes 128 GB per node Active-active cluster, multi-AZ + DR site Tertiary referral center, trauma center.
Enterprise / IDN > 15,000 studies / day 64 vCPU per node, 5+ nodes per site 256 GB per node Federated multi-site, each with HA cluster Large IDN, national reading network.

Full hardware/software requirements are in DOC-2026-059 (HW/SW Requirements), available under NDA. Includes OS support matrix, supported databases (with version ranges), HA topology requirements, DR-site recommendations, and network requirements.

Licensing

Three packages.

Core gives you a clinical-grade archive without the tag-edit feature — useful for environments that want the higher availability + audit trail without the audit-trailed tag-edit workflow yet. Tag-Edit adds the metadata-correction capability. Enterprise unlocks federation, DR, and FHIR R4. All three are non-device GA tiers under §520(o)(1)(D).

The clinical-interpretation features — the Diagnostic Viewer and the Clinical Reporting suite — are not licensable at GA. They ship in code but are locked and un-licensable, which is what keeps the product non-device under §520(o)(1)(D).

VNA Clinical Core

The base non-device clinical archive. Full DICOM + DICOMweb + audit trail. Clinical-tag-edit is included but feature-gated by license — you can deploy without enabling it if your clinical workflow doesn't require it.

  • Full DICOM + DICOMweb feature parity with VNA Repository
  • Hospital-grade HA pair
  • Diagnostic-report transport (HL7 ORU + DICOM SR)
  • 21 CFR Part 11-aligned audit trail
  • Up to 1 PB archive capacity

VNA Clinical + Tag-Edit

Adds the audit-trailed clinical-tag-edit capability (metadata correction, not interpretation) with second-person sign-off and per-tag policy controls. A non-device GA capability.

  • Everything in Core
  • Clinical-tag-edit workflow
  • Per-tag editable / locked policy configuration
  • Second-person electronic-signature requirements
  • Withdraw / re-issue notifications on critical tag changes
  • Up to 5 PB archive capacity

VNA Clinical Enterprise

Everything, plus FHIR R4, multi-site federation, and advanced audit features.

  • Everything in Core + Tag-Edit
  • FHIR R4 endpoints
  • Multi-site federation (federated query + cross-site retrieval)
  • Multi-AZ + DR site deployment patterns
  • Audit retention separable from study retention
  • Unlimited archive capacity
  • Premium support tier eligible

Pricing structure mirrors VNA Repository (per-deployment, capacity-tiered), reflecting the additional availability + audit + support requirements of a clinical-grade archive. Multi-product bundles (VNA Repository + VNA Clinical + Router) get bundle pricing. Specific pricing in your engagement SOW.

Documentation

The controlled-document set.

Every VNA Clinical 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.

Document Title Notes
DOC-2026-131 Hardware & Software Requirements (VNA Clinical) Sizing, OS support, dependencies
DOC-2026-141 DICOM Conformance Statement (VNA Clinical) Public — full SOP class + transfer-syntax matrix
DOC-2026-136 EULA Annex (VNA Clinical) Annex to the Synthology Master EULA (DOC-2026-063)
DOC-2026-151 Penetration Test Results (VNA Clinical) Available under NDA
DOC-2026-146 QA Runner Manual (VNA Clinical) Internal QA + customer-validated test runs
DOC-2026-161 User Guide (VNA Clinical) Operator + administrator workflows
DOC-2026-167 Installation Guide (VNA Clinical) Includes MSI deploy + Linux tarball install

Frequently asked

The questions prospects ask.

Why is this a separate product from VNA Repository?

Both are non-device software under FD&C Act §520(o)(1)(D). What sets VNA Clinical apart is that it carries the clinical-interpretation features — a Diagnostic Viewer and a Clinical Reporting suite — in code. In the GA build those features are locked and un-licensable, so VNA Clinical still can't be used to clinically interpret stored images in patient treatment, which is what keeps it non-device. We ship the interpretation code in separate executables on separate ports so that the non-device-only siblings (Repository, Migration, Research) never carry it at all — the boundary is a code boundary, not just a license flag.

What does "clinical-tag-edit" actually mean?

The ability to correct DICOM tags that carry clinical meaning after ingest — PatientName, PatientID, AccessionNumber, StudyDescription, BodyPartExamined, ProcedureCodeSequence, and others per institutional policy. Tag corrections are a real clinical need (wrong-patient-on-modality, mis-coded orders, EMR-VNA divergence, etc.). Crucially, this edits METADATA — it does not interpret images — so it stays within the non-device boundary. The feature is license-gated, audit-trailed, and requires second-person sign-off per 21 CFR Part 11 §11.50.

What's the regulatory classification?

VNA Clinical is non-device software at GA under FD&C Act §520(o)(1)(D). The clinical-interpretation features (Diagnostic Viewer + Reporting) ship in code but are locked and un-licensable, so the GA product is not a medical device and needs no premarket review. Because those features can't be enabled, the product cannot be used to clinically interpret stored images in patient treatment — which is exactly the boundary that keeps it non-device.

Can we use the Diagnostic Viewer or Reporting today?

Not for clinical interpretation. Both ship in the GA build but are locked and un-licensable — they cannot be enabled. Today, clinical interpretation and report authoring stay in your existing viewer and reporting tools; VNA Clinical handles storage, DICOM / DICOMweb I/O, audit-trailed clinical-tag-edit, and report-object transport (HL7 ORU / DICOM SR / FHIR DiagnosticReport). Because the viewer + reporting stay locked, the product remains non-device under §520(o)(1)(D).

Is the clinical-tag-edit feature locked off in the MSI?

No — clinical-tag-edit is a non-device GA capability. It ships in every VNA Clinical install and is enabled by license entitlement (a deliberate design control, audit-trailed, with second-person sign-off). The features that ARE locked and un-licensable at GA are the clinical-interpretation ones — the Diagnostic Viewer and the Clinical Reporting suite. The non-device-only siblings (Repository, Migration, Research) physically cannot run any of this code — it ships in a different binary.

How does this interact with our existing PACS / RIS for tag corrections?

Most environments have 4–6 places where tag corrections happen today (PACS native edit, RIS, modality QC station, EMR override, manual tickets). VNA Clinical can serve as the system of record for clinical-tag-edit, with integration paths back to source systems. This is itself an implementation engagement; we don't recommend turning the feature on without a workflow-design phase that maps every existing correction path to the new system.

What's the upgrade path from VNA Repository?

Data-preserving in-place upgrade. Same catalog DB, same storage backend, additive feature set. The catalog row schema is forward-compatible; the binary swap activates the new capabilities. Downtime depends on the HA configuration: with an HA pair the upgrade is rolling (one node at a time), with a single node it's typically a 30-60 minute maintenance window. License entitlement controls which features are reachable post-upgrade.

What about VNA Clinical Research?

A combined Clinical + Research host for institutions that operate both production clinical archives and de-identified research workflows. Same non-device posture under §520(o)(1)(D) — it also carries the interpretation features in code, locked at GA — with research-mode lanes added for de-identified study sets. See /products/vna-clinical-research for details. Pick that sibling if you want both postures in one binary; pick VNA Clinical if your research data lives elsewhere.

Plan a clinical-archive deployment.

VNA Clinical is available now as non-device software — storage, audit-trailed clinical-tag-edit, and non-interpretive clinical workflow. The clinical-interpretation features (Diagnostic Viewer + Reporting) stay locked and un-licensable, which keeps the product non-device under §520(o)(1)(D). We’ll talk through the deployment that fits your environment.

Request a demo All products