Three archive hosts. One intended use per binary.
The XyDromatics™ Archive Family is three sibling products built on a shared Router-pattern scaffold. Each sibling has a single, deliberate intended use that matches its deployment — and all three are non-device software under FD&C Act §520(o)(1)(D), transferring, storing, converting, and displaying medical device data without clinical interpretation.
The split is intentional. Intended-use scope is a code boundary, not a config flag — different intended uses mean different binaries. A customer deploying Repository for legacy archive doesn’t accidentally pull in Migration’s bulk-drain pipelines, and a Research deployment doesn’t pull in non-research retention features.
Three siblings
Pick the host that matches your use case.
Each sibling has its own product page with full architecture, capability matrix, deployment guide, and regulatory framing.
XyDromatics Repository
Non-deviceRetention-tier vendor-neutral archive
The cold storage of last resort for data that has to live somewhere but isn't actively queried in clinical workflow. Where data from retired PACS, decommissioned VNAs, M&A-acquired-hospital archives, and retention-window compliance goes.
XyDromatics Migration
Non-deviceLegacy-PACS drain into Repository
One-time / project-scoped bulk ingest from legacy PACS into the Repository. Source discovery, batched retrieval, transform pipelines, crosswalk CRUD, rejection-queue triage. Migration forwards to the Repository over the wire — no shared process space — keeping the regulatory boundary visible.
XyDromatics Research
Non-deviceResearch-use-only DICOM storage
Research-use-only (RUO) DICOM storage for institutions running their own research programs. De-identified study aggregation, cohort building, IRB-aligned access controls. Explicitly labeled "Not for diagnostic use" at every interaction surface.
Why split the family
Regulatory boundaries are code boundaries.
One intended use per binary
All three siblings perform functions that fall squarely within FD&C Act §520(o)(1)(D) — they transfer, store, convert formats, and display medical device data without clinical interpretation. Per the controlling statute, they are not devices. Each sibling is scoped to a single intended use, so its capability set stays bounded. Different intended use ⇒ different binary. The customer never has to wonder which one they’re running.
Code segregation enforces the boundary
Each sibling ships as its own binary with only its intended-use code compiled in. A licensing mistake or a config-flag slip can’t accidentally enable another sibling’s functionality on the wrong host — the code isn’t in the binary to enable.
Customer deployment matches the regulatory frame
A customer building a legacy-archive consolidation deploys Repository + Migration. A customer running an institutional research program deploys Research (RUO). All three Non-device siblings ship today as non-device software under FD&C Act §520(o)(1)(D).
Audit visibility
Because each binary has one classification, a regulatory audit on any single product is bounded: the SBOM is one binary’s SBOM, the threat model is that product’s threat model, the change-control gate is that product’s gate. No "this feature is in scope of regulation A in this license tier but not in that tier" arguments.
More detail
Where to read further.
- /regulatory — the firm-level posture page (FD&C Act §520(o)(1)(D), ISO 13485–aligned QMS, CVD program).
- Individual sibling product pages linked above each carry their own capability matrix, deployment guide, DICOM Conformance Statement reference, and per-binary regulatory framing.
- For procurement teams: each sibling can be evaluated independently. We do not require the family to be deployed as a bundle.