Zero Integration
Status: vision — the deployment model designed for the real-data phase.
PRISM is designed to deploy inside an insurer without changing anything the insurer or its providers already do: no new data capture, no new interfaces, no workflow changes, and no patient data leaving the building.
Runs on data the insurer already has
Every medical encounter that generates a bill already creates a claim. Every prescription filled through insurance is already recorded. Every lab test, specialist visit, and admission already flows through the insurer's claims processing — validated for payment, standardized into documented code systems, and stored. This is the insurance vantage point: payers are the one party that already holds the complete cross-provider journey.
PRISM reads a simplified rendering of that existing data — the six-column timeline format built from standardized codesets — and nothing else. No new fields are captured, no additional coding precision is demanded of providers, no supplementary documentation is created. The data quality problems have largely been solved already by the payment process itself: claims must be accurate to be paid, so the coding discipline PRISM depends on is enforced by incentives that predate it. And because the timeline format carries only age, sex, and coded events, the system operates anonymous by architecture — it never needs names, addresses, or clinical notes.
No new interfaces, no workflow changes
Nobody logs into PRISM. Physicians receive no alerts from a new system, learn no new software, and document nothing extra. When the ensemble reaches consensus on a patient, the suggestion travels through whatever channel the insurer already uses for provider correspondence — care-gap notices, provider portals, secure messaging — and arrives looking like the insurer communications a practice already knows how to process. The physician's response, ordering the suggested test or declining to, follows their existing procedures and remains entirely their decision.
Patients see even less. They never interact with PRISM and never receive anything from it; if their physician acts on a suggestion, the experience is an ordinary test order. Lab staff, billing departments, and the insurer's IT organization all handle PRISM-suggested tests exactly as they handle any other, with one exception: the suggested test carries a tracking code, which is how results-based compensation is settled and how the patient's cost for the test is covered.
PRISM-managed hardware inside the insurer's facility
The computation runs on hardware PRISM supplies, installs, and manages remotely, racked inside the insurer's own data center. The division of responsibility is deliberately narrow:
| party | provides |
|---|---|
| client insurer | rack space, power, network connectivity, read access to claims data |
| PRISM | the hardware, all software, remote management, monitoring, and replacement units when components fail |
The units are racks of consumer GPUs — one ensemble model per card, orchestrated by a management server — per the cluster architecture. The prototype's hardware results are the concrete sizing evidence: a full-context model fits on a single 16 GB consumer card, so the racks are ordinary, air-cooled, and cheap to scale linearly. If a card or node fails, the ensemble degrades gracefully and a replacement ships; local staff swap units with simple instructions.
Because the hardware sits inside the insurer's facility on an isolated network segment, patient data never leaves the building. PRISM's remote access is for managing its own machines, not for reading the client's data outward — the claims data stays where it already lives, and only model management traffic crosses the boundary.
True background operation
Nothing triggers PRISM. It is not a tool a physician queries or an analysis someone requests; it runs continuously in the background, working through the covered population on rolling cycles, ingesting new claims as they settle, and surfacing a suggestion only when independent models agree. Model refresh is likewise automatic, on the continuous retraining cycle. The insurer's staff neither operates the system nor waits on it; suggestions simply arrive through the channels above when consensus warrants one.
Honest limits
This deployment model is designed, not deployed. The 2026 synthetic prototype proved the method on a five-node fleet under PRISM's own control; no installation has yet run inside an insurer's facility. The open questions are the practical ones: negotiating remote-management access with a client's security team, the mechanics of the read-only claims feed, and operational cadence at real population scale. What the design fixes now is the shape of the answer — existing data, existing channels, PRISM's hardware, the client's building.