Archive Family

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.

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.

Availability

An archive of record keeps a second copy.

The rest of the imaging fleet is made resilient by routing around a failed node. That does not work for an archive: routing around one gets you a healthy host holding none of your studies, which is not a recovery. What protects an archive is that the data exists somewhere else.

So every archive host replicates cross-site. As each instance is stored it is queued to every enabled peer whose modality filter matches, and delivered over DICOMweb. A bounded reconciliation sweep then re-checks the archive against each peer and reports how many instances are missing there — deliberately throttled so it never competes with live ingest. 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.

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.