XyDromatics VNA Research —
de-identified by design.
The Research Use Only sibling of the VNA family. PHI
anonymization at ingest is mandatory and enforced in the
binary, not just in the label. Cohort-level access control,
project partitioning, research-friendly exports (NIfTI,
BIDS, CSV manifests), IRB-aware audit trail.
Deliberately not a medical device. RUO labeling under
21 CFR 809.10(c)(2)(i) keeps clinical decision-making out
of scope by design — that’s what
VNA Clinical is
for. Research and clinical postures kept structurally
separate, with the regulatory boundary mirrored at code
boundary.
RUO is a regulatory category defined by FDA in 21 CFR
809.10(c)(2)(i): a product labeled exclusively for research,
not for clinical diagnosis or treatment decisions. Products
in this category sit outside FDA medical-device
classification because their intended use is investigational
— and crossing into clinical use would require a different
regulatory pathway.
For VNA Research that means three things, all enforced:
1. Mandatory anonymization
Every study passes through anonymization at ingest. Un-anonymized data never lands.
2. No clinical code paths
No HL7 ORU, no DiagnosticReport, no clinical-tag-edit. The binary cannot reach clinical workflows.
3. License enforcement
anonymization_enforced=true is a license setting, not a config flag — observable on /health.
4. Separate process boundary
Different executable, different port from VNA Clinical. Code that handles clinical data never runs in this process.
That last point is the same engineering principle applied
across the family — every product is non-device software
under FD&C Act §520(o)(1)(D): regulatory class boundary
mirrored at code boundary. Researchers, IRB reviewers, and
FDA inspectors all evaluate the same product with the same
posture.
Capabilities
What VNA Research does — and doesn’t do.
Two capabilities (marked
RUO)
are the regulated boundary that keeps this product out of
FDA medical-device territory. The rest are research-workflow
features built on top.
PHI anonymization at ingest
RUO
The load-bearing capability. Every study entering VNA Research passes through anonymization before it lands in the archive — never lives un-anonymized in this product.
DICOM PS3.15 Annex E — Basic Confidentiality Profile (mandatory baseline)
Per-IRB-protocol anonymization profile overrides (study-specific tag retention)
Pixel-data redaction for burned-in PHI (overlays, scanout, secondary captures)
Date-shift jittering to preserve longitudinal relationships while breaking calendar identification
Keyed-hash UID remapping — same patient always maps to the same anon-ID (longitudinal linkage); the system's encryption key is the keying material
Mapping retained in the IRB-protected layer to enable later authorized re-identification of system-anonymized studies
Verification step before commit — anonymization failures route to quarantine, never to the live archive
Cohort + project access control
Researchers don't need access to the whole archive — they need access to their cohort. Access control happens at the cohort/project level, not per-AE-Title.
Per-cohort read access (a researcher only sees their own cohort)
Per-project data partitioning with logical isolation
Honest-broker capability for studies anonymized by this system — IRB-gated re-identification, patient recontact, and longitudinal linkage
IRB-protocol metadata attached to every cohort
Audit trail records every cohort-data access with researcher identity
Cohort expiration — automatic archive purge at protocol end
Research-friendly export formats
Researchers run their tools against NIfTI, BIDS, and tabular cohort manifests — not against raw DICOM. Export pipelines convert at request time.
NIfTI conversion (1- and 2-volume)
BIDS-format export (Brain Imaging Data Structure) for neuroimaging studies
CSV / Parquet cohort manifests with selected DICOM tags as columns
DICOM-SR extraction to structured JSON / FHIR DiagnosticReport
Configurable per-modality export pipelines
Export-job audit trail (what cohort, what format, when, by whom)
Re-identification risk controls
De-identification quality matters. RUO doesn't mean "best-effort" — it means defensible against re-identification within the limits of the anonymization standard, with built-in broker capability for IRB-authorized re-link.
k-anonymity / l-diversity reporting per cohort
Free-text-field scanning (study description, comments) for residual PHI
Configurable risk thresholds with cohort-level gating
Documented re-identification model assumptions per IRB
Built-in honest-broker capability — keyed-hash pseudonymization keeps the source ↔ anon-ID mapping consultable without external assistance, IRB-protocol-gated
External pre-anonymized data: no re-identification path (no mapping captured)
Audit-ready report generation for IRB renewal cycles
RUO boundary enforcement
RUO
The "not a medical device" labeling is enforced in code, not just in the EULA. Clinical-decision pathways are physically unreachable from VNA Research.
Mandatory `anonymization_enforced=true` license setting (cannot be disabled by config)
/health endpoint exposes `anonymization_enforced:true` for external auditing
No clinical-tag-edit code paths in the binary (separate executable from VNA Clinical)
No HL7 ORU / DiagnosticReport emit (no clinical reporting integration)
RUO labeling on web UI, API responses, and exported manifests
License-feature gating prevents cross-loading of clinical capabilities
Operations & administration
Research-flavored admin surface — IRB protocols, data dictionaries, cohort definitions instead of clinical workflows.
Web administration UI with shared sidebar shell (consistent with the XyDromatics family)
Role-based access control (researcher / PI / data steward / IRB observer)
Cohort definition workflow with version history
Data dictionary management per protocol
Storage-utilization reporting per cohort + per project
SynthQMS integration for protocol changes as controlled documents
Architecture
Anonymization is the gate, not an option.
The diagram below shows the load-bearing element: every
study entering VNA Research passes through anonymization
before landing in the archive. There is no bypass path.
The anonymization gate is the architectural feature that makes
VNA Research possible as an RUO product. Without it, the
archive would hold PHI and would need a different regulatory
classification entirely. Anonymization failures route to
quarantine — never to the live archive — so a partially-
anonymized study can’t accidentally land alongside
properly-anonymized cohort data.
Common use cases
Five research-workflow patterns.
What customers actually deploy VNA Research for. Each pattern
assumes the standard IRB protocol governance and consortium
/ data-use agreements that academic research requires.
Pattern 1
Longitudinal research cohort
A multi-year IRB-approved study following a defined cohort. Studies arrive over years; researchers need consistent anonymization (same patient → same anon UID across all timepoints) and project-scoped access.
Flow
1IRB approves the study + anonymization profile
2Production clinical archive forwards qualifying studies through anonymization gate
3VNA Research stores anonymized studies with consistent UID remapping
4PI + named researchers access only their cohort via the cohort-level RBAC
An AI-application vendor (internal or external) needs a labeled training corpus from de-identified imaging. VNA Research holds the anonymized corpus and exposes it via cohort-scoped export pipelines.
Flow
1Cohort definition: modality, body part, date range, label criteria
2Anonymization runs at ingest; pixel-data redaction on overlays
3Export pipeline produces NIfTI + label manifest per training run
4Audit trail records every export — defensible against later "where did this data come from?" questions
5Cohort retention and disposal align with the data-use agreement
Pattern 3
Multi-institution research consortium
Three academic medical centers collaborate on a study. Each contributes data into a shared VNA Research instance after local-site anonymization. Researchers query across the federated cohort without seeing source-site identities.
Flow
1Each site's production archive forwards qualifying studies through site-local anonymization
2Site-of-origin metadata stripped or coded per consortium policy
3Shared VNA Research holds the federated cohort
4Researchers query across all sites with a single cohort definition
5Per-site contribution audit retained for paper-authorship attribution
Pattern 4
Population-health analytics
Health-system epidemiology and quality teams need access to anonymized imaging at population scale to track quality metrics, screening rates, follow-up adherence. Research-Use-Only because outputs feed quality reports, not individual clinical decisions.
Flow
1All clinical studies forwarded through anonymization at ingest
2VNA Research holds the population corpus with longitudinal linkage via consistent UID remapping
3Analytics platforms run cohort queries (e.g., "all 60+ y.o. patients with low-dose CT in 2024 with follow-up imaging")
4Reports aggregate at population level — no individual identification
5IRB protocol covers the population-health use under the institutional QI / research framework
Pattern 5
AI-vendor integration without sharing PHI
Send studies to an AI vendor for analysis without exposing PHI — and still get the findings linked back to the right patient. Keyed-hash pseudonymization makes the round-trip work: de-identify on the way out, re-identify on the way back. AI vendors avoid BAA scope; the institution keeps PHI in-house; clinical workflow still gets findings on the right patient.
Flow
1Clinical source archive forwards qualifying studies through the anonymization gate
2Gate uses keyed-hash pseudonymization (anon-ID derived from PHI + system encryption key) — same patient always maps to same anon-ID
3De-identified studies sent to AI vendor (vendor sees only anon-ID)
4AI vendor analyzes, returns findings tagged with the same anon-ID
5System uses the retained mapping to re-identify the anon-ID and forward findings to the source clinical archive linked to the correct patient
6AI vendor never received PHI; clinical workflow benefits from AI findings; HIPAA exposure minimized
Pattern 6
AI-application validation against retrospective data
Validating a clinical AI application against historical performance — does it perform as claimed against our patient population? VNA Research holds the validation cohort with ground-truth labels; AI vendor receives only de-identified data.
Flow
1Validation cohort defined per protocol (modality + clinical scenario + ground-truth source)
2Cohort de-identified into VNA Research with ground-truth labels attached
3AI vendor receives access scoped to validation cohort only
4Performance metrics computed against ground truth
5Validation report archived; cohort retained per data-use agreement
Integration points
What VNA Research connects to.
The integration surface is research-flavored: identity
domains separate from clinical, IRB-protocol governance,
export pipelines for research tools, and the always-mandatory
anonymization gate sitting between PHI sources and the RUO
archive.
Inbound (anonymization-gated)
Production clinical archive (VNA Clinical, customer's existing VNA, etc.) — feeds qualifying studies through the gate
Site-local anonymization tools at multi-institution consortia
Direct STOW-RS supported but rarely used (anonymization should run upstream)
Modalities NEVER write directly to VNA Research (PHI would land un-anonymized)
Outbound (research consumers)
Researcher workstations querying their own cohorts
AI training pipelines (export to NIfTI, BIDS, label manifests)
Statistical analysis platforms (R, SAS, Python via cohort manifests)
External validation engagements (scoped cohort export with data-use agreement)
Honest-broker integration for protocols requiring re-identification
k-anonymity / l-diversity reporting for risk assessment
IRB-protocol versioning via SynthQMS document control
Storage & catalog (shared with the VNA family)
Local filesystem (default for departmental research)
S3-compatible object stores
On-prem NAS (NFS / SMB)
PostgreSQL / SQL Server / Oracle catalog (no SQLite)
Cohort partitioning at the catalog level
Identity & audit
OIDC / SAML for the web admin UI
Researcher accounts separate from clinical RBAC (different identity domain)
Per-cohort access logs with researcher identity
IRB-observer read-only access role
Audit-export tool for IRB renewal cycles
System requirements & sizing
Sized to cohort scale, not population.
Research workloads are different from clinical: bursty
(cohort builds + export jobs) rather than continuous, and
read-heavy rather than write-heavy. Sizing reflects active
cohort count and aggregate cohort size more than ingest
throughput.
Tier
Cohort scale
CPU
RAM
Typical site
Departmental
< 10 active cohorts, < 50 TB
4 vCPU
16 GB
Single research group, single PI, departmental infrastructure.
Institutional
10–50 active cohorts, 50 – 500 TB
8 vCPU
32 GB
Academic medical center research-IT, multiple PIs, multiple modalities.
Multi-institution
50+ cohorts, 500 TB+, federated query
16 vCPU per site, federation layer
64 GB per node
Research consortium, federated multi-site query.
Licensing
Three packages, anonymization always-on.
The anonymization-enforced license setting is mandatory at
every tier — there’s no Core-without-anonymization path
because there can’t be (that wouldn’t be RUO).
Tiers differ in advanced anonymization and federation
features.
VNA Research Core
Single-institution RUO archive with full anonymization and cohort-level access control.
PHI anonymization at ingest (DICOM PS3.15 Annex E baseline)
Cohort + project access control
Standard export formats (NIfTI, CSV manifests)
IRB-friendly audit trail
Web admin UI with researcher-flavored RBAC
Up to 500 TB archive
VNA Research + Advanced Anonymization
Adds re-identification risk controls and pixel-data redaction for studies with burned-in PHI.
Date-shift jittering with longitudinal preservation
VNA Research Enterprise
Multi-institution federation, BIDS exports, and full IRB lifecycle tooling.
Everything in Core + Advanced Anonymization
Multi-site federation layer
BIDS-format export for neuroimaging
Per-IRB-protocol anonymization profile management
Cohort lifecycle (creation → active → archived → disposed) with audit
IRB-observer role and audit-export tooling
Unlimited archive capacity
Pricing reflects the research-workload profile — typically
per-institution annual subscription with cohort-count and
storage-capacity tiers. Bundle pricing is available with VNA
Clinical for institutions running both postures, or with
VNA Clinical Research for a single-binary combined deployment.
Documentation
The controlled-document set.
Every VNA Research 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-130
Hardware & Software Requirements (VNA Research)
Sizing, OS support, dependencies
DOC-2026-140
DICOM Conformance Statement (VNA Research)
Public — full SOP class + transfer-syntax matrix
DOC-2026-135
EULA Annex (VNA Research)
Annex to the Synthology Master EULA (DOC-2026-063)
DOC-2026-150
Penetration Test Results (VNA Research)
Available under NDA
DOC-2026-145
QA Runner Manual (VNA Research)
Internal QA + customer-validated test runs
DOC-2026-163
User Guide (VNA Research)
Cohort workflows, export pipelines, IRB protocols
DOC-2026-166
Installation Guide (VNA Research)
Includes MSI deploy + Linux tarball install
Additional documents
VNA Research-specific documents beyond the standard set. Items
marked Pending are tracked for
authoring under SynthQMS change control.
Document
Title
Notes
DOC-2026-402
RUO Labeling Statement (VNA Research)
Formal Research Use Only labeling per 21 CFR 809.10(c)(2)(i)
DOC-2026-403
Anonymization Profile Catalog (VNA Research)
Standard + per-IRB-protocol profiles
DOC-2026-404
De-Identification Verification SOP (VNA Research)
How VNA Research validates anonymization quality
DOC-2026-405
IRB Reviewer Briefing Pack (VNA Research)
For institutional IRBs evaluating VNA Research deployments
Frequently asked
The questions PIs and IRBs ask.
Why isn't this an FDA-listed medical device?
It's deliberately not. "Research Use Only" is a regulatory category defined in 21 CFR 809.10(c)(2)(i): a product labeled for research use, not for clinical diagnosis or treatment decisions. RUO products sit outside the FDA medical-device classification system because their intended use is investigational. Crossing into clinical use would require a different regulatory pathway -- which is exactly what VNA Clinical is for.
Can researchers use this archive for clinical decisions?
No. The RUO labeling is enforced in two places. First, the web UI, API responses, and exported manifests carry the RUO label. Second -- and more importantly -- the binary itself physically cannot run clinical-decision code paths. There's no HL7 ORU emission, no DiagnosticReport integration, no clinical-tag-edit, no critical-results notification. The license-feature enforcement keeps the RUO boundary at code level, not just at label level.
What anonymization standard do you use?
DICOM PS3.15 Annex E (Basic Confidentiality Profile) as the mandatory baseline, with per-IRB-protocol overrides for tag retention. Pixel-data redaction handles burned-in PHI in overlays, scanout, and secondary captures. Date-shift jittering preserves longitudinal relationships within a patient while breaking calendar identification. The specific profile applied to a cohort is captured in the cohort metadata for IRB and audit purposes.
Can we re-identify patients if the protocol requires follow-up?
Yes — for studies that entered VNA Research through its own anonymization gate, with no external assistance required. The anonymization gate uses keyed-hash pseudonymization: the system's encryption key is the keying material for the hash that produces each anon-ID. Same patient always maps to the same anon-ID (preserves longitudinal linkage); the key remains under the system's key-management custody. The honest-broker capability is built into the system — a designated broker role (with explicit permission, audit-trailed, IRB-protocol-gated) consults the mapping to support patient recontact, longitudinal-linkage confirmation without exposing PHI to researchers, or — under narrow protocol authorization — returning identified data for specific IRB-approved purposes. No external honest-broker entity needed. Important constraint: studies ingested already-de-identified from external sources (consortium partners, etc.) cannot be re-identified — we never had the mapping or the source PHI in the first place.
How does this interact with our IRB?
IRB protocols become controlled documents in SynthQMS. Each protocol carries its own anonymization profile, access list, data-use agreement reference, and retention policy. The audit-export tool produces IRB-renewal-ready documentation: who accessed what cohort, when, what was exported, and to whom. Optional IRB-observer read-only role lets an IRB reviewer audit the deployment in real time.
Can VNA Research be deployed alongside VNA Clinical?
Yes -- this is a common pattern. VNA Clinical handles the production clinical archive; VNA Research holds the de-identified research corpus. Studies flow from Clinical through the anonymization gate into Research. The two run as separate executables on separate ports, with separate identity domains -- a researcher account on Research has no access to Clinical, and vice versa. For combined-posture institutions that want one host running both, see VNA Clinical Research.
How do you verify the anonymization actually worked?
Three layers. First: every anonymization run produces a verification report (which tags were removed, which were remapped, which were retained per protocol). Second: free-text-field PHI scanning catches residual PHI in study descriptions, comments, and other free-text tags. Third: k-anonymity / l-diversity reporting per cohort gives a quantified re-identification-risk metric that an IRB can evaluate against protocol-specific thresholds.
What's the right pattern for an AI-vendor validation engagement?
Define the validation cohort under an IRB-approved protocol. Pull qualifying studies through anonymization into VNA Research. Grant the AI vendor a researcher account scoped to that cohort only. Vendor receives only de-identified data and cannot reach beyond their assigned cohort. Validation results flow back per data-use agreement; the audit trail records every export. Cohort retention follows the protocol's retention clause.
Plan a research-archive deployment.
Whether the goal is a longitudinal cohort, an AI-training
corpus, or a federated multi-institution study, the
conversation starts with your IRB protocol and your
anonymization profile. We’ll come back within one
business day.