Router-pattern host · Non-device clinical + research archive
XyDromatics VNA Clinical Research —
both lanes, one binary.
The dual-posture archive — non-device software under
FD&C Act §520(o)(1)(D) at GA. Clinical-archive
feature set on the clinical lane (clinical-tag-edit on
metadata, hospital-grade HA, audit trail), PHI-anonymized
research lanes alongside, lane-separation enforcement keeping
them safely apart. The clinical-interpretation features —
the Diagnostic Viewer and clinical reporting — ship in code
but are locked and un-licensable at GA, the same posture as
VNA Clinical.
For institutions running both clinical and de-identified
research operations under one ops team. Both lanes are
non-device at GA and held to the same controls — the research
lane is de-identified research workflow, not a different
regulatory tier than
VNA Research.
Enabling the Diagnostic Viewer + reporting for clinical
interpretation in patient treatment is a future enhancement
with no committed timeframe, and would require a separate
regulatory posture review before any such capability could
ship.
VNA Clinical Research exists for institutions where the same
imaging-IT team runs both clinical operations and
de-identified research cohorts, and the operational cost of
maintaining two separate products outweighs the benefit of a
cleaner research / clinical operational separation. Both lanes
are non-device software at GA, held to the same controls.
The decision matrix:
Pick VNA Clinical Research when:
Same ops team runs clinical and research infrastructure
Cross-lane workflows are common (tag-for-research, longitudinal cohorts)
Clinical and de-identified research data held to the same non-device controls in one host
Bundled licensing + single support relationship is operationally valuable
Pick VNA Clinical + VNA Research separately when:
Clinical and research operations are separately governed (different IT teams, different IRBs)
Research program is run as its own deployment with its own ops footprint
A cleaner operational boundary between clinical and research is preferred over a single footprint
Cross-lane workflows are rare — research is a separate program, not an extension
Capabilities
Both lanes, plus the separation logic.
Capability cards are color-tagged by lane:
Clinical
features mirror VNA Clinical;
Research
features overlap VNA Research; cards marked
Both
are dual-posture-specific.
Clinical lane — non-device archive
Clinical
Everything VNA Clinical does at GA: clinical-tag-edit (metadata only), hospital-grade availability, complete audit trail, EMR/EHR context. Storage and non-interpretive workflow — within the non-device boundary.
Clinical-tag-edit with second-person sign-off (21 CFR Part 11) — edits metadata, never interprets images
Custom-field creation from any data in the system (DICOM, HL7, SR objects)
Active-active HA pair with sub-second failover
EMR / EHR context launch (Epic, Cerner) with HL7 ORU outbound
Same non-device clinical-archive capabilities as VNA Clinical
Diagnostic Viewer + clinical reporting
Locked at GA
The clinical-interpretation capabilities. Present in code, but locked and un-licensable at GA — enabled only for Synthology development partners under a separate non-commercial arrangement, never for customers, so the shipped product cannot be used to clinically interpret stored images in patient treatment. Broader enablement is a future enhancement with no committed timeframe and would require a separate regulatory posture review first.
Diagnostic Viewer (Cornerstone3D) — MPR, 3D volume rendering, MIP / slab, bone removal, W/L sync, cross-viewport reference lines
Critical-results notification system of record — producing/routing an alert a clinician acts on in treatment falls outside the non-device boundary
Locked & un-licensable at GA — a future enhancement, with no committed timeframe, if ever enabled for clinical interpretation
Research lane — anonymized cohorts
Research
Research-mode lanes inside the same archive: PHI-anonymized at lane crossing, cohort-level access control, project partitioning, research-friendly exports.
PHI anonymization at clinical→research lane crossing
Cohort + project-scoped access control with researcher RBAC
IRB-protocol metadata attached to every cohort
NIfTI / BIDS / CSV manifest exports
Honest-broker workflow for IRB-approved re-identification
Cohort lifecycle (creation → active → archived → disposed) with audit
Lane separation enforcement
Both
The architectural feature that makes dual-posture safe: clinical and research data stay logically and operationally separate even though they live in the same host.
Lane-aware identity domains (clinical user ≠ researcher; no role can read both lanes by default)
Per-lane storage partitioning at the catalog level
Lane-specific audit trails — clinical-lane access never appears in research audit and vice versa
Cross-lane access requires explicit dual-permission grant + audit
Cross-lane data movement (clinical → research) goes through anonymization gate; reverse direction requires honest-broker
Lane labels visible in UI, API responses, and exports
Cross-lane workflows
Both
Two common patterns where lanes interact: clinical-to-research (study tagged for research after de-identification, common) and research-to-clinical (rare, requires honest-broker capability).
Tag-for-research workflow — clinician flags a study; anonymization gate de-identifies it via keyed-hash pseudonymization; copy lands in research lane
Cohort-build pipelines pull tagged clinical studies through the gate at scheduled intervals
Built-in honest-broker capability — for system-anonymized studies the source ↔ anon-ID mapping is retained, enabling IRB-authorized re-identification, patient recontact, or longitudinal linkage without external broker entity
External pre-anonymized data (consortium ingest) carries no re-identification path — we never had the mapping
Audit trail captures every cross-lane transition with reason, approver, and IRB protocol reference
Cohort closeout flow ensures research-lane data disposal aligns with IRB protocol
Shared substrate
Both lanes run on the same pluggable storage and catalog substrate as the rest of the VNA family — but with lane-aware partitioning.
Pluggable storage backends — local FS, S3-compatible, NAS
Pluggable catalog DB — PostgreSQL (default) / SQL Server / Oracle (no SQLite)
Per-lane storage tier assignment — clinical hot, research warm, etc.
Lifecycle policies aware of lane semantics (research-lane disposal aligns with IRB; clinical-lane retention with state laws)
Single backup / DR substrate covers both lanes
Hash-chain audit log spans both lanes with lane-tag entries
Operations & administration
Single admin surface, lane-aware. Operators see both postures in one console; lane-specific workflows route to the correct UI.
Web administration UI with lane indicators on every screen
SynthQMS integration for change control on both clinical and research configurations
Audit-export tools support per-lane filtering for clinical-side audit and IRB-side audit independently
Single MSI / Linux deployment covers both lanes
Architecture
Lanes inside one host.
Clinical and research lanes share the host but stay logically
separate. Cross-lane data movement happens only through the
anonymization gate (clinical → research) or the honest-broker
workflow (research → clinical, IRB-approved only).
The two lanes share the host but never share data. Clinical
users see only the clinical lane; researchers see only the
research lane. Cross-lane movement happens through two
controlled pathways: the anonymization gate
(clinical → research, common, audit-trailed), and the
honest-broker workflow (research → clinical, rare, IRB-approved).
Both pathways are themselves audited end-to-end. The host is
non-device software at GA: the clinical-interpretation features
(Diagnostic Viewer + reporting) are present in code but locked
and un-licensable, so neither lane is used to clinically
interpret images in patient treatment.
Use cases
Four dual-posture institution patterns.
Pattern 1
Academic medical center (clinical + research operations under one ops team)
A teaching hospital where the same imaging-IT team runs both production clinical archive and de-identified research cohorts. One ops surface, one upgrade cadence, one license simplifies the day-to-day even though both lanes have to be maintained.
Flow
1Production clinical traffic flows into the clinical lane (non-device archive + tag-edit)
2IRB-approved studies tagged for research at radiologist sign-off
3Anonymization gate de-identifies tagged studies; copy lands in research lane
4Researchers work the cohort; clinicians never see the research lane
5Single QBR covers both clinical SLA + research IRB-renewal metrics
Pattern 2
Pathology dual-posture (clinical signout + research-grade WSI cohorts)
A pathology service that wants both clinical signout reads (regulated, audit-trail) and de-identified research cohorts for AI-application development. Same WSI volumes show up in both lanes — clinical for diagnosis, anonymized cohorts for AI training.
Flow
1Pathology Engine ingests WSI from scanners
2Clinical lane receives WSI for diagnostic signout
3After signout, pathologist tags appropriate cases for research
5Research lane holds the de-identified WSI cohort for AI training and validation
Pattern 3
Cardiology research consortium (single-institution combined posture)
A cardiology service participating in a multi-institution research consortium AND running normal clinical operations. The single-institution archive holds both postures so the local IT team isn't maintaining two infrastructure stacks.
Flow
1Echo and cath-lab studies flow into clinical lane for production reads
2Per-protocol cohort definitions pull qualifying studies through anonymization
3Research lane holds anonymized cardiology cohorts
4Federation layer connects to consortium partners' research lanes
5Audit captures both clinical SLA evidence and consortium contribution provenance
Pattern 4
Migration from VNA Clinical to combined posture
An institution running VNA Clinical adds a research program and elects to consolidate into VNA Clinical Research rather than deploying VNA Research alongside. Data-preserving upgrade flips the same product into dual-posture mode.
Flow
1Existing VNA Clinical deployment is the starting point
2License entitlement upgraded to enable research lanes
3In-place upgrade activates the lane-separation enforcement layer
4Existing clinical data partitions into the clinical lane (no movement)
5Research-lane creation begins fresh with IRB-protocol scoped cohorts
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, all without the AI vendor ever seeing PHI. AI vendors avoid BAA scope; the institution keeps PHI in-house; clinical workflow still gets findings on the right patient.
Flow
1Clinical study qualifies for AI analysis per institutional policy
2Anonymization gate de-identifies via keyed-hash pseudonymization (anon-ID derived from PHI + system encryption key)
3De-identified study sent to AI vendor (vendor sees only the 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 link findings to the original clinical study
6Findings appear in the clinical lane against the correct patient — AI vendor never received PHI
Integration points
Lane-specific writers, lane-specific readers.
Each lane has its own writer / reader integration surface;
cross-lane workflows are themselves named integration points.
Substrate is shared.
Clinical lane writers
Modalities (any DICOM-conformant SCU)
XyDromatics Router (most common, with clinical-traffic rule sets)
OIDC / SAML identity (lane-specific role membership)
Hash-chain audit log spanning both lanes with lane-tag entries
Single backup / DR / monitoring infrastructure
System requirements & sizing
Sized to combined clinical volume + research cohort scale.
Sizing accounts for both lanes — production clinical
throughput on the clinical side and active cohort count on
the research side. HA pair is recommended at every tier
for the production clinical archive.
Tier
Clinical study volume
Active cohorts
CPU
RAM
Typical site
Hospital + research program
< 1,500 studies / day
< 10 active cohorts
8 vCPU per node
32 GB per node
Community hospital with an emerging research program. HA pair recommended for the clinical lane.
Academic medical center
1,500 – 8,000 studies / day
10 – 50 active cohorts
16 vCPU per node
64 GB per node
Teaching hospital with active research program, multi-site clinical, multi-PI research.
Tertiary referral + research consortium
> 8,000 studies / day
50+ cohorts, federated
32 vCPU per node, multi-AZ
128 GB per node
Large IDN with research consortium participation; both lanes scaled independently.
Licensing
Three packages, both lanes always activated.
Unlike VNA Clinical (where the research lane is absent) or
VNA Research (de-identified research only), VNA Clinical
Research always activates both lanes — that’s the point
of the product. All GA tiers are non-device; the Diagnostic
Viewer + reporting are not licensable at GA (locked; a future
enhancement with no committed timeframe). Tiers differ in
advanced features.
VNA Clinical Research Standard
Both lanes activated — clinical archive plus research-mode lanes with anonymization gate.
Full clinical-lane feature set (matches VNA Clinical Core)
Research-lane with PHI anonymization at lane crossing
Cohort + project access control
Lane separation enforcement
Standard exports (NIfTI, CSV manifests)
IRB-friendly audit
Up to 2 PB combined archive
VNA Clinical Research + Tag-Edit
Adds the non-device clinical-tag-edit capability (metadata correction with Part 11 sign-off) and advanced anonymization for the research lane.
Everything in Standard
Clinical-tag-edit with second-person sign-off
Pixel-data redaction for research-lane studies with burned-in PHI
k-anonymity / l-diversity reporting
Honest-broker re-identification workflow
Up to 5 PB combined archive
VNA Clinical Research Enterprise
Everything, plus federation, BIDS export, FHIR R4, multi-site research consortia.
Everything in Standard + Tag-Edit
Multi-site research-consortium federation
BIDS-format exports for neuroimaging
FHIR R4 endpoints
Active-active HA cluster
Multi-AZ + DR site deployment
Unlimited combined archive capacity
Premium support tier eligible
Combined VNA Clinical Research is typically priced 25–40% less
than the sum of separate VNA Clinical + VNA Research deployments,
reflecting shared infrastructure and a single support
relationship. Pricing in your engagement SOW.
Documentation
The controlled-document set.
Every VNA Clinical 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.
For institutional IRBs evaluating dual-posture deployments
Frequently asked
The dual-posture decision questions.
Why would I choose this over VNA Clinical + VNA Research deployed separately?
Operational simplicity. One product, one binary, one upgrade cadence, one license, one ops team, one infrastructure footprint. Institutions where the same imaging-IT team runs both clinical and de-identified research operations get meaningfully easier day-to-day with the combined product. Both lanes are non-device software at GA, held to the same controls — the research lane is not a different regulatory tier. Pick separate VNA Clinical + VNA Research if you want a cleaner operational boundary and your research program is run as its own deployment.
What is the regulatory status of VNA Clinical Research?
At GA it is non-device software under FD&C Act §520(o)(1)(D). Both lanes — the PHI clinical archive and the de-identified research lanes — are non-device and held to the same controls. The product is non-device because the clinical-interpretation features (the Diagnostic Viewer and clinical reporting) ship in code but are locked and un-licensable, so the product cannot be used to clinically interpret stored images in the treatment of a patient. Enabling those features for clinical interpretation would move the product outside the non-device boundary — a future enhancement with no committed timeframe, and one that would require a separate regulatory posture review first.
Which features are locked, and is clinical-tag-edit one of them?
Clinical-tag-edit is NOT locked — it is a non-device GA capability (a licensable tier). It corrects DICOM metadata with a 21 CFR Part 11 second-person sign-off and audit trail; it edits metadata and never interprets images, so it stays within the non-device boundary. What IS locked and un-licensable at GA are the clinical-interpretation features: the Diagnostic Viewer (MPR / 3D / GSPS / hanging protocols / prior comparison, etc.) and the clinical reporting suite (dictation, templates, PowerScribe / Fluency migration). They ship in the binary but cannot be enabled — unlocking them for clinical interpretation is a future enhancement that would move the product outside the non-device boundary.
How do clinical and research lanes stay separated?
Lane-aware identity (a clinical user account has no research lane access by default and vice versa), lane-partitioned storage and catalog, lane-specific audit trails, and explicit cross-lane permission gates. Cross-lane data movement is the only path between them: clinical → research goes through the mandatory anonymization gate; research → clinical (re-identification) requires the honest-broker workflow with IRB protocol authorization. Default-deny on cross-lane access is the design principle.
Can data move between lanes?
Yes — but only through controlled paths with audit. Clinical → research is the common direction: a clinician tags a study for research, the anonymization gate de-identifies it, a copy lands in the research lane (the original stays in the clinical lane unchanged). Research → clinical is rare and requires the honest-broker workflow: an IRB-approved key custodian holds the mapping between source-PHI and anonymized identifiers and can re-link only under documented authorization. Both directions are fully audited.
What is the regulatory posture, and what would change if the interpretation features were enabled?
VNA Clinical Research is non-device software at GA (§520(o)(1)(D)), the same posture as VNA Clinical. The line is simple: a non-device cannot aid or produce any information that is acted upon in the treatment of a patient. Enabling the Diagnostic Viewer and clinical reporting for clinical interpretation in patient treatment is a future, untimed enhancement that would move the product outside the non-device boundary and require a separate regulatory posture review first. There is no date, quarter, or version committed to that enhancement. The security docs (Risk Management File and Threat Model, DOC-2026-150 and -151) are shared with VNA Clinical.
Cost comparison vs VNA Clinical + VNA Research?
Combined VNA Clinical Research is typically priced 25-40% less than the sum of separate VNA Clinical + VNA Research deployments, reflecting the shared infrastructure and single support relationship. The trade is operational: one product and one footprint vs a cleaner operational boundary between clinical and research. Institutions doing the math should also factor in the cost of operating two separate products vs one (different upgrade cycles, different ops on-call, different training).
Can we start with VNA Clinical only and add research lanes later?
Yes — that's a common path. Activating research lanes is a license-entitlement upgrade with an in-place product upgrade (VNA Clinical → VNA Clinical Research is a data-preserving upgrade, not a re-implementation). Existing clinical data partitions into the clinical lane unchanged; research-lane creation begins fresh with IRB-protocol cohort definitions. The reverse direction (Clinical Research → Clinical only) is also supported, with a research-data-disposal flow per IRB protocols.
What about VNA Research as a sibling — are research lanes here equivalent?
Functionally similar. Research lanes in VNA Clinical Research provide cohort access, anonymization, IRB workflows, and research exports just like VNA Research does. Both are non-device software. The difference is operational: VNA Research is a standalone de-identified research archive, while VNA Clinical Research carries the research lanes alongside the PHI clinical lane in one host with lane-separation enforcement. Different institutions will pick different paths based on their research-program governance and operational footprint.
Talk through a dual-posture deployment.
Many institutions land on VNA Clinical Research after starting
out planning two separate products. Tell us about your clinical
+ research operations and we’ll walk through which
posture fits your governance and ops profile.
