Platform Expansion
Status: vision — the expansion template beyond the first conditions.
The machinery that extracts training material, trains the ensemble, and counts votes never knows what condition it is screening for. Expanding PRISM is therefore not an engineering problem — it is a selection problem, and the selection has four hard criteria.
The four criteria
A candidate condition must pass all four. This is a conjunctive filter, not a scorecard: a condition that is common, devastating, and treatable but has no simple test is out.
| criterion | what it requires | why it is required |
|---|---|---|
| Established non-invasive test | A routine blood or urine test with defined reference ranges, orderable by any physician | The suggestion must be trivially actionable; physicians must know exactly what to order and how to read it |
| Early-vs-late outcome difference | Catching it early must lead to meaningfully better outcomes than catching it late | Screening that does not change the patient's trajectory is cost without benefit |
| Sufficient prevalence | Enough diagnosed patients in claims data to yield GOOD and BAD training examples | The three-pattern extraction learns from real utilization phenotypes; a one-in-a-million condition cannot supply them |
| Clear early-treatment pathway | A specific, accessible intervention that follows a positive test | Detection without a next step helps no one — and generates no documented early detection to be paid on |
The last column of the last row is not incidental. Under results-based compensation, PRISM is paid only when a suggestion leads to a documented early detection followed by early treatment. A condition failing the outcome-difference or treatment-pathway criteria could never generate that event, so the business model and the selection criteria enforce each other.
Non-invasive as a focusing mechanism
The non-invasive constraint reads like a limitation; it functions as the discipline that keeps everything else workable.
A blood or urine draw needs no sedation, no recovery, no specialist gatekeeping, and no dedicated appointment. It integrates into visits that are already happening: a suggested test can be drawn alongside the labs a patient was getting anyway at an annual physical or a chronic-condition follow-up, adding a line to a requisition rather than a task to a life. Patients rarely decline a blood draw their physician recommends, and physicians can order one without a risk-benefit consultation.
The constraint also underwrites PRISM's error tolerance. The consensus approach accepts that individual models are noisy, and the constructive-only architecture means the worst case of a wrong suggestion is an unnecessary test — but that math only stays comfortable when the unnecessary test is a cheap, essentially risk-free draw. Non-invasiveness is what keeps a false flag nearly free.
A worked illustration: hypothyroidism
Hypothyroidism shows what a passing condition looks like against the criteria. Naming it here illustrates the filter, not an announcement — whether its precursor pattern is actually learnable from claims data is an empirical question, per condition, that only the real-data phase can answer.
| criterion | hypothyroidism |
|---|---|
| Established test | Thyroid function panel (TSH and related assays) — a standard blood draw with well-defined reference ranges |
| Outcome difference | Untreated, it drifts for years through fatigue, weight and lipid changes, and cardiovascular strain; treated, it is a managed condition |
| Prevalence | Common in any insured population, and substantially underdiagnosed |
| Treatment pathway | Daily oral levothyroxine — inexpensive, well-understood, monitored with the same blood test |
The shape should look familiar: a slow prodrome of vague, scattered complaints, one simple test, and a managed life on an ordinary refill. That is deliberately the shape of PVE's GOOD arc — the fabricated condition was designed as a clean instance of exactly this class.
Adding a condition
Onboarding a new condition means defining three code sets: its TEST (the diagnostic that fires), its EARLY (what managed treatment looks like in claims), and its LATE (what the missed case costs). From those definitions, the extraction machinery derives GOOD, BAD, and NOPE examples — and constructs FAKE ones — automatically; the training rounds and the consensus vote are unchanged.
The 2026 synthetic prototype demonstrated this end-to-end: an entire condition was defined purely as code sets, and the pipeline carried it from definitions to consensus votes with no condition-specific component anywhere. Clinical expertise concentrates at exactly one point — choosing the codes — and everything downstream is the same machinery. That is the vision claim: the marginal cost of a condition is a code-definition exercise and a training round, not a new system. It has been proven on a manufactured condition and remains untested on a real one.
What PRISM will not target
PRISM will not suggest colonoscopies, biopsies, MRI or CT studies, or anything requiring preparation, sedation, or specialist scheduling. It will not target conditions where earlier detection does not change the outcome, conditions without an established treatment response, or conditions too rare to supply training examples.
The refusal list is a design feature, not an apology. Every exclusion protects a property the rest of the system depends on: cheap false flags, frictionless follow-through, and a suggestion a physician can act on in the same visit. A system that is explicit about what it will not do is easier to hold accountable for what it will.
See also
- Three-pattern learning — how TEST/EARLY/LATE definitions become training material
- Prototype overview — the machinery demonstrated end-to-end on a manufactured condition
- Constructive-only — why a wrong suggestion costs one blood draw
- Results-based compensation — the business model that enforces the same criteria
- The screening gap — the class of condition this template exists to catch