Skip to content

Three-Pattern Learning

Status: concept, demonstrated — the extraction ran automatically over the synthetic world.

Three sets of billing codes — the diagnostic test, the early treatment, the late treatment — are all it takes to define a condition for PRISM. From those three sets, every training example the method needs extracts itself from the coded timelines, with no chart review anywhere in the loop.

Three code sets define a condition

Everything PRISM learns about a condition is anchored to three marks, each a set of standardized billing codes:

markwhat it namesin the prototype
TESTthe diagnostic test whose appearance in a continuation is the screening suggestionCPT-82197, the quantitative serum veladrin ratio of PVE
EARLYtreatment indicating the condition was caught in timerecurring refills of one simple maintenance tablet
LATEtreatment indicating it was missed until it caused lasting damagerecurring clearance sessions at a dialysis-style facility — an ongoing institutional burden

The TEST is the pivot. Every timeline that contains it can be classified mechanically by what follows: early treatment, late treatment, or neither. That classification is the whole of "labeling" in PRISM — no diagnosis field, no outcome adjudication, no clinician judgment.

The synthetic prototype carries two further marks, SIGNAL (the diverse utilization lead-up) and IMPACT (accrued damage on the delayed path), because its condition was injected and every injected row had to be accounted for. Real records need no such marks: the lead-up is simply whatever the timeline contains before the test.

Three arcs fall out

Classifying timelines by the three code sets yields three kinds of example, each teaching a different lesson.

GOOD is the success story: a lead-up pattern, the test, then early treatment and no complications. It teaches the target behavior directly — given a history like this, fire the test, and early treatment follows.

BAD is the tragedy: a similar lead-up plus accumulating damage, a test that finally arrives late, then the long tail of late treatment. Extraction does more than replay it — replaying would teach the model that late is normal. Instead the BAD prompt is paired with a counterfactual continuation: a caught-in-time TEST-then-EARLY graft, lifted from the GOOD template, preferred over the timeline's real drift into LATE. BAD carriers teach the correction, not the mistake.

NOPE is the test that ruled it out: a TEST followed by neither treatment. It is the specificity control — the preferred continuation is to carry on normally, with the test as the dispreferred path, the exact mirror of GOOD. Without NOPE, a model could look good by suggesting the test for everyone; NOPE is what makes silence on unaffected patients a trained behavior rather than an accident (and silence is never reported as clearance). In the prototype, NOPE carriers received a deliberately bare test with no lead-up at all, so nothing in their record can legitimately predict it and any firing on them is a measured false positive.

FAKE — the earliness teacher

Firing the test is only half the goal; PRISM has to surface it earlier than the historical record did. FAKE is the fourth construct, and it is not a kind of patient: it is built from each BAD example by moving the prompt cut roughly twenty rows earlier in the timeline (this round's construction offset). The lesson is identical to BAD's — prefer the caught-in-time graft — but asked from less history. In the prototype's build, BAD prompts end about 11 rows before the test row and FAKE prompts about 31 rows before it. Training on that pairing is literally how "surface it sooner" is taught, and firing on a FAKE prompt at evaluation time is the only way "earlier" is ever measured — there is no lead-time score (evaluation without a hold-out). A worked example shows the construction on a real prototype carrier.

What each arc trains

Extraction renders each arc as a prompt (the history up to a cut) with a preferred and a dispreferred continuation:

kindpromptchosen (preferred)rejected (dispreferred)
GOODSIGNAL lead-upTEST → EARLYbase rows only
BADSIGNAL · IMPACTTEST → EARLY (grafted early)SIGNAL · IMPACT · LATE
NOPEbase rows onlybase rows onlyTEST
FAKESIGNAL · IMPACT, cut ~20 rows earlierTEST → EARLY (grafted early)SIGNAL · IMPACT · LATE

The TEST sits in the preferred column for GOOD, BAD, and FAKE and in the dispreferred column for NOPE — that pairing is the entire design. The rejected column, though, turned out to matter less than the design assumed: the secondary recipe that actually worked is pure SFT on the chosen continuations alone, after a preference-loss detour failed to make the test emittable (two training rounds tells that story). The extraction still defines both columns; the winning recipe used one.

No chart review, at any scale

The extraction is deterministic queries over coded timelines. Nothing in it requires reading a chart or exercising judgment: find the test code, look at what follows, cut, graft, done. Every qualifying case in the data is captured — including rare presentations no annotator would think to look for — and the same queries rerun identically as the data grows.

That is what makes the method a platform rather than a one-condition tool. Adding a condition means declaring its three code sets and re-running the extraction; the model architecture, training recipe, and consensus mechanism do not change. Which conditions qualify — an established non-invasive test, meaningfully better early-vs-late outcomes, sufficient prevalence — is its own question, taken up in platform expansion.

One honest caveat: the prototype's extraction ran over injected arcs, where every classification is clean by construction. Real claims will bring ambiguity — treatments that fit neither code set cleanly, tests repeated across years, coding habits that vary by insurer. What is demonstrated is that the extraction logic works end-to-end and trains the intended behavior; how gracefully the classification rules extend to real records belongs to the next phase.

Bookkeeping only

The marks exist so that database views can slice timelines into training material — and for no other reason. No model ever sees a mark, a pool number, or a patient identifier, in training or at inference; what a model sees is exactly the six-column timeline, nothing more. A mark is a label on the scaffolding, never on the data.

See also