How it works
The traceability record, the five-step sequence, the boundary between your quality system and ours, the regulatory split, and the services you can hand us.
The differentiator
Traceability is not a feature added to the product. It is the reason to use a service rather than a script on a server, and it is the property the product is named for.
Instruments differ in what they emit, so the strength of the evidence differs too. Every result carries a provenance class — a machine-readable statement of exactly how much of the chain we can vouch for. How we grade evidence →
What happens
Traceability is not one of the steps — it accumulates at all of them. That is the difference between an audit log and an evidence record.
The instrument, or the agent acting for it, presents a certificate provisioned per device and bound to a site at enrolment. No inbound connections into the clinic.
Known device, known site, known specimen identifier. An unknown device or an unrecognised token raises an exception. Nothing is ever inferred.
Your signed container runs in a sealed runtime — pinned digest, fixed CPU family, single-threaded numerics, no network egress, hard timeouts. Admission is gated on your golden dataset reproducing bit-for-bit.
The report is built from a version-locked template. Where a qualified person must review before release, the approval is captured with identity, server timestamp and the stated meaning of the signature — and a modified result stays permanently distinguishable from an unmodified one.
Delivery is acknowledged, and an unacknowledged result escalates rather than disappearing.
Your customer's EHR retrieves the report as structured data. No interface build per site.
Authenticated and time-limited. The notification itself carries no clinical content.
To addresses preconfigured per site. Notification only — the report stays behind the link.
The boundary
There is no informal channel between your quality system and our runtime — only artefacts you have built, signed and can identify by digest.
YOU
THE CONTRACT SURFACE
Five artefacts. Nothing else crosses.
DXTRACE
A stale calibration refuses to compute rather than producing a plausible wrong number. Your registry of which instrument belongs to which site can start as a spreadsheet — and if any of this is inconvenient, we can build it for you under a separate contract.
Regulatory posture
A medtech leadership team asks this before anything else, so we answer it unprompted. Hosting your algorithm does not make us a device manufacturer.
| Responsibility | You | DxTrace |
|---|---|---|
| Intended use and clinical claim | Owns | None |
| Algorithm design, validation, change control | Owns | Executes only |
| IEC 62304 lifecycle for the algorithm | Owns | Can support |
| Analytical and clinical validation | Owns | Supplies environment evidence |
| Execution environment fidelity | Specifies requirements | Owns and evidences |
| Traceability, audit trail, retention | Consumes | Owns |
| Patient identity and PHI | Owns entirely | Never holds |
| Supplier qualification of the supplier | Owns | Supports with evidence |
DxTrace is a component supplier under your design controls — not a device manufacturer, and not the holder of any claim. That distinction is deliberate, and we will evidence it.
To be confirmed against your final intended-use statement with your own regulatory counsel.
Optional services
Under a separate contract. Even where we write the code, you direct, review, approve and own the algorithm within your quality system — and we will say so in writing.