XyDromatics Research Router-pattern host · RUO

XyDromatics™ Research — de-identified by design.

The Research Use Only sibling of the archive 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, DICOM Part 10 cohort snapshots), 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. Research and clinical postures kept structurally separate, with the regulatory boundary mirrored at code boundary.

The regulatory posture

“Research Use Only” isn’t a marketing slogan.

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 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 emit and no clinical-tag-edit — those code paths are absent from the binary. The read-only FHIR R4 gateway serves DiagnosticReport projections of the already-de-identified catalog and performs no clinical interpretation.

3. License enforcement

anonymization_enforced=true is a runtime composition invariant, not a config flag or a licence field — observable on /health.

4. Separate process boundary

Different executable, different port from the clinical archive. 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 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 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)
  • A single fixed anonymization profile — DICOM PS3.15 Annex E Basic Profile with PatientName set to RESEARCH and a fresh random PatientID; per-protocol tag-retention overrides are not configurable
  • Burned-in-PHI safety by refusal — an object flagged BurnedInAnnotation=YES is rejected at ingest (no catalog row, no bytes on disk); OCR-based pixel redaction is a separate product, the XyDromatics De-Identification Engine
  • Dates handled per the PS3.15 Annex E Basic Profile (removed or replaced) — calendar identification is broken, but no date-shift jitter is applied, so intra-patient date intervals are not preserved
  • One-way de-identification at ingest — DICOM PS3.15 Annex E Basic Profile mints fresh Study/Series/SOP UIDs and a new random patient identifier on every object; no keying material and no UID map are retained, so anon-IDs are not stable across timepoints
  • No mapping is retained anywhere — the ingest anonymizer discards its UID map after every object by design, so the Research host cannot reconstruct the original PHI from any operator-accessible state
  • Verification before commit — the DICOM ingest path refuses any object it cannot de-identify (the SCP returns failure; no catalog row, no bytes on disk), and the index-in-place path admits only objects that pass a non-mutating de-identification verifier behind an operator sample-review attestation

Cohort management and access control

A cohort is a saved, versionable query that can be frozen into a saved snapshot. Access to cohorts is governed by role permissions, and those permissions apply across the whole archive rather than to individual cohorts.

  • Cohort access is gated by role permissions (view_cohorts / manage_cohorts) — every holder of the permission sees every cohort; there is no per-user or per-cohort scoping
  • No honest-broker or re-identification path — de-identification at ingest is one-way by design; a protocol requiring re-link must retain the mapping source-side or use an external honest broker before data reaches Research
  • Cohorts carry a name, description, criteria, version, status, creator and timestamps — there is no IRB-protocol field or protocol registry
  • Audit trail records every cohort-data access with researcher identity
  • Cohorts are deleted manually via DELETE /api/cohorts/{id} — there is no expiry date and no automatic purge at protocol end

Research-friendly export formats

A cohort snapshot is frozen and exported as DICOM Part 10, with the member list retrievable as JSON. Format conversion for downstream tooling is the researcher's step, not the archive's.

  • DICOM Part 10 export — a cohort snapshot's instances are written to a server-side directory as {studyUid}/{seriesUid}/{sopUid}.dcm, with no format conversion
  • Cohort snapshots record study, instance, byte and distinct-subject counts; the frozen study list is retrievable as JSON via GET /api/cohorts/{id}/members (no CSV or Parquet manifest generation)
  • DICOM-SR extraction to structured JSON / FHIR DiagnosticReport
  • Export-job audit trail (what cohort, what format, when, by whom)

Re-identification risk controls

De-identification quality matters. RUO does not mean best-effort — it means defensible within the limits of the anonymization standard. De-identification here is ONE-WAY by design: there is no re-identification path and no broker.

  • Every cohort snapshot records a frozen distinct-subject count alongside its study, instance and byte totals
  • k-anonymity floor on cohort queries and exports — result sets below the distinct-subject floor (fixed at 11) are suppressed, and every snapshot records a frozen distinct-subject count. No l-diversity metric
  • Free-text-field scanning (study description, comments) for residual PHI
  • Documented re-identification model assumptions per IRB
  • No re-identification path from this system — ingest de-identification retains no source ↔ anon-ID mapping; external honest-broker arrangements are required for any protocol needing re-link
  • 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 Research.

  • `anonymization_enforced=true` is a runtime composition invariant, not a licence option or a config flag — /health reports the AND of two DI type probes (the de-identifying C-STORE receiver and the verifying index-in-place admission policy), and no config or licence field can switch either off
  • /health endpoint exposes `anonymization_enforced:true` for external auditing
  • No clinical-tag-edit code paths in the binary (separate executable from the clinical archive)
  • No HL7 ORU emit and no clinical reporting workspace. The read-only FHIR R4 gateway does serve ImagingStudy and DiagnosticReport projections of the de-identified catalog — metadata only, with no clinical interpretation.
  • 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
  • Archive-wide storage-utilization reporting; each frozen snapshot separately records its own study, instance and byte counts
  • SynthQMS integration is limited to licence activation — there is no document-control or protocol-versioning integration

Architecture

Anonymization is the gate, not an option.

The diagram below shows the load-bearing element: every study entering Research passes through anonymization before landing in the archive. There is no bypass path.

XyDromatics Research architecture PHI-bearing data flows from production clinical sources (the customer's existing VNA, etc.) through a mandatory anonymization gate before entering Research. Researchers query their assigned cohorts, exporting in research-friendly formats. Anonymization failures route to quarantine and never enter the live RUO archive. CLINICAL SOURCES PHI-bearing ANONYMIZATION GATE mandatory · code-enforced RUO ARCHIVE de-identified only Clinical sources Clinical PACS Production VNAs Site-local archives contain PHI Anonymization gate DICOM PS3.15 Annex E + IRB profile Pixel redaction · UID remap · date shift Verification before commit de-identified Research Cohort archive Project partitioning RUO · not a medical device Anonymization-failure quarantine Never enters the live RUO archive cohort scope Research consumers PIs · AI training DICOM Part 10 cohort export

The anonymization gate is the architectural feature that makes 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 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 accumulate over years, and the cohort definition is versioned so it can be re-run as new data lands. Note the boundary before you design the protocol around it: de-identification here is one-way and per-instance, so the same patient does NOT resolve to a stable identifier across timepoints. A protocol that depends on longitudinal subject linkage needs that linkage maintained outside this archive.

Flow

  1. 1 IRB approves the study + anonymization profile
  2. 2 Production clinical archive forwards qualifying studies through anonymization gate
  3. 3 Research re-anonymizes on arrival and stores the result — UIDs are remapped independently per instance, and no source-to-anon mapping is retained anywhere on the host
  4. 4 PI and named researchers work from the shared cohort definition; archive access is granted by role permission
  5. 5 At protocol end: cohort export + audit-trail report for IRB closeout
Pattern 2

AI training data preparation

An AI-application vendor (internal or external) needs a labeled training corpus from de-identified imaging. Research holds the anonymized corpus and exposes it via cohort-scoped export pipelines.

Flow

  1. 1 Cohort definition: modality, body part, date range, label criteria
  2. 2 Anonymization runs at ingest; pixel-data redaction on overlays
  3. 3 Export pipeline produces NIfTI + label manifest per training run
  4. 4 Audit trail records every export — defensible against later "where did this data come from?" questions
  5. 5 Cohort 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 Research instance after local-site anonymization. Researchers query one shared archive holding every site's contribution, without seeing source-site identities.

Flow

  1. 1 Each site's production archive forwards qualifying studies through site-local anonymization
  2. 2 Site-of-origin metadata stripped or coded per consortium policy
  3. 3 One shared Research archive holds every site's contribution
  4. 4 A single cohort definition spans all contributed studies, because they share one archive
  5. 5 The contributing AE title is recorded on each study at ingest, so contribution can be reconstructed from the audit record
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

  1. 1 All clinical studies forwarded through anonymization at ingest
  2. 2 Research holds the population corpus with longitudinal linkage via consistent UID remapping
  3. 3 Analytics platforms run cohort queries (e.g., "all 60+ y.o. patients with low-dose CT in 2024 with follow-up imaging")
  4. 4 Reports aggregate at population level — no individual identification
  5. 5 IRB 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

  1. 1 Clinical source archive forwards qualifying studies through the anonymization gate
  2. 2 Gate uses keyed-hash pseudonymization (anon-ID derived from PHI + system encryption key) — same patient always maps to same anon-ID
  3. 3 De-identified studies sent to AI vendor (vendor sees only anon-ID)
  4. 4 AI vendor analyzes, returns findings tagged with the same anon-ID
  5. 5 System uses the retained mapping to re-identify the anon-ID and forward findings to the source clinical archive linked to the correct patient
  6. 6 AI 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? Research holds the validation cohort with ground-truth labels; AI vendor receives only de-identified data.

Flow

  1. 1 Validation cohort defined by study criteria — modality, date range, body part and coded findings
  2. 2 Cohort de-identified into Research with ground-truth labels attached
  3. 3 Cohort snapshot exported as de-identified DICOM Part 10 and delivered to the AI vendor — the export is the boundary, not an in-archive account
  4. 4 Performance metrics computed against ground truth
  5. 5 Validation report archived; cohort retained per data-use agreement

Integration points

What 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 (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 Research (PHI would land un-anonymized)

Outbound (research consumers)

  • Researcher workstations querying cohorts
  • AI training pipelines fed from frozen cohort snapshots exported as DICOM Part 10
  • Statistical analysis platforms (R, SAS, Python via cohort manifests)
  • External validation engagements (scoped cohort export with data-use agreement)
  • Population-health analytics platforms

Anonymization & governance

  • DICOM PS3.15 Annex E baseline profile (mandatory)
  • Pixel-data redaction tooling (burned-in PHI, overlays, scanout)
  • IRB-protocol versioning via SynthQMS document control

Storage & catalog (shared with the archive family)

  • Local filesystem (default for departmental research)
  • S3-compatible object stores
  • On-prem NAS (NFS / SMB)
  • PostgreSQL / SQL Server / Oracle catalog (no SQLite)

Identity & audit

  • Local accounts with optional LDAP / Active Directory bind for the web admin UI (SAML and OIDC federation are not implemented)
  • Researcher accounts separate from clinical RBAC (different identity domain)
  • Cohort-query access logs recording researcher identity, the query surface and a hash of the predicate
  • IRB-observer read-only access role
  • Audit-export tool for IRB renewal cycles

Availability

Resilience here means a second copy.

A research archive is a system of record for cohorts that may have taken years to assemble and cannot simply be re-sent from a modality. Routing around a failed archive gets you a healthy node holding none of your studies, which is not a recovery. So resilience is cross-site replication: as each instance is archived it is queued to every enabled peer site whose modality filter matches, and delivered over DICOMweb STOW-RS.

A bounded reconciliation sweep then re-checks the archive against each peer and reports how many instances are missing there. It is deliberately throttled so it never competes with live ingest — it exists to catch what the write path missed. That count is what turns replication from something you trust into something you can measure.

Replication is data protection, not request routing. It means a second site holds your images — not that a failed archive is transparently substituted mid-association.

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+ 16 vCPU per node 64 GB per node Multi-site consortium contributing into one shared archive.

Licensing

One licence, anonymization always-on. A valid site licence grants every generally-available VNA Research feature; role-based access control, not per-feature licensing, is the access-control plane. The de-identification gate is unconditional and is not a licensable option. The only separately granted lane is the Tier-2 advanced-viewer set (MPR, 3D volume, GSPS and related), which requires an explicit partner licence.

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 archive capacity and support, not in the anonymization guarantee.

Research Core

Single-institution RUO archive with full anonymization and role-gated cohort management.

  • PHI anonymization at ingest (DICOM PS3.15 Annex E baseline)
  • Cohort management with role-based access control
  • Cohort export as DICOM Part 10 files to a server-side destination directory
  • IRB-friendly audit trail
  • Web admin UI with researcher-flavored RBAC
  • Up to 500 TB archive

Research + Advanced Anonymization

Adds re-identification risk controls and pixel-data redaction for studies with burned-in PHI.

  • Everything in Core
  • Burned-in-annotation refusal at ingest (OCR pixel redaction is delivered by the separate XyDromatics De-Identification Engine)
  • Free-text-field PHI scanning

Research Enterprise

Differs by install count and services, not by capability — every cohort, anonymization and audit feature ships with the product.

  • Everything in Core + Advanced Anonymization
  • Site-to-site replication — a configured study set is copied to peer archives over DICOMweb STOW-RS (each site still answers queries against its own catalog; there is no federated query layer)
  • 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 for institutions running a combined clinical and research posture.

Documentation

The controlled-document set.

Current GA release v1.0.3.155 · released 2026-08-06

Every XyDromatics 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.

What’s new·v1.0.3.155

Expanded in-app help for the permission-gated research archive

  • In-app help now covers the Log Files viewer and related workflows — each topic explains what the page does, how to do it, a worked example, and the permission it requires.
  • Research-Use-Only archive and Study Browser access, gated by role-based permissions.
  • Support-role sessions are locked out of patient identifiers by role-based access control.
  • Refreshed End-User and Installation guides.
  • Ships with the approved EULA and clears a full QA + security-test pass on the release build.
Document Title Notes
DOC-2026-130 Hardware & Software Requirements (XyDromatics Research) Sizing, OS support, dependencies
DOC-2026-140 DICOM Conformance Statement (XyDromatics Research) Public — full SOP class + transfer-syntax matrix
DOC-2026-135 EULA Annex (XyDromatics Research) Annex to the Synthology Master EULA (DOC-2026-063)
DOC-2026-150 Penetration Test Results (XyDromatics Research) Available under NDA
DOC-2026-145 QA Runner Manual (XyDromatics Research) Internal QA + customer-validated test runs
DOC-2026-163 User Guide (XyDromatics Research) Cohort workflows, export pipelines, IRB protocols
DOC-2026-166 Installation Guide (XyDromatics Research) Includes MSI deploy + Linux tarball install

Additional documents

XyDromatics 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 (XyDromatics Research) Formal Research Use Only labeling per 21 CFR 809.10(c)(2)(i)
DOC-2026-403 Anonymization Profile Catalog (XyDromatics Research) Anonymization profile catalog and tag-retention rationale
DOC-2026-404 De-Identification Verification SOP (XyDromatics Research) How XyDromatics Research validates anonymization quality
DOC-2026-405 IRB Reviewer Briefing Pack (XyDromatics Research) For institutional IRBs evaluating XyDromatics 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.

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), applied uniformly at ingest as a single fixed profile — there is no per-protocol or per-cohort variation of the tag set, and no date-shift jittering. Patient identity is replaced with a RESEARCH placeholder and a randomly generated identifier, so de-identification here is one-way by design. Pixel-data redaction handles burned-in PHI in overlays, scanout and secondary captures.

Can we re-identify patients if the protocol requires follow-up?

No — not from Research. De-identification at ingest is deliberately one-way: the PS3.15 Annex E Basic Profile mints fresh Study/Series/SOP UIDs and a new random patient identifier on every object, and the anonymizer discards its UID map after each call so the Research host cannot reconstruct the original PHI from any operator-accessible state. There is no broker role, no mapping store and no re-identification endpoint. If a protocol requires re-identification or patient recontact, the mapping must be retained by the source-side clinical system or an external honest broker before studies are forwarded into Research. The same applies to studies ingested already de-identified from external sources. 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 are governed in SynthQMS as controlled documents. The protocol lives there as paperwork — Research holds no protocol object, so a protocol does not carry its own anonymization profile, access list or retention rule inside the archive. What Research contributes is the evidence: the audit-export tool produces IRB-renewal-ready documentation of who queried what, when, and what was exported. An IRB-observer read-only role lets a reviewer audit the deployment directly.

Can Research be deployed alongside a production clinical archive?

Yes -- this is a common pattern. A production clinical archive handles the clinical workflow; Research holds the de-identified research corpus. Studies flow from the clinical archive 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 the clinical side, and vice versa.

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, and which were retained). Second: free-text-field PHI scanning catches residual PHI in study descriptions, comments, and other free-text tags. Third: k-anonymity floor on the query surface — result sets below 11 distinct subjects are suppressed outright. The floor is a fixed archive-wide value, not a per-protocol threshold.

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 Research, freeze the cohort as a snapshot, and export it as de-identified DICOM Part 10. Hand the vendor the EXPORT — do not give them an account on the archive. Cohort permissions are archive-wide, so any account that can read one cohort can read them all; the export boundary is what confines a vendor to the agreed data. The audit trail records every export, and retention follows the protocol's 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.