Operating the re-test cycle data plane

The re-test cycle data plane (B-1) is the clinical-outcome substrate the intelligence layer learns from: it captures a baseline lab for a member on an active intervention, prompts a re-test on a schedule, and on the follow-up lab closes the cycle into a canonical Outcome Record. It lives in the clinical service and is dark by default.

It exists because the clinical moat is gated on one unproven behavior — will members re-test? (historically: ~0 did). Rather than answer that with manual concierge outreach, the data plane instruments re-test induction so the rate is measured by the system. See the intelligence concept for how the Outcome Record feeds the loop.

The lifecycle

baseline_set ──(window due)──▶ prompted ──(follow-up lab)──▶ retested
      └──────────────(window + grace, no follow-up)──────────▶ expired

1. Baseline — POST /v1/retest-cycles captures a baseline biomarker + links the intervention (protocol/stack), computing retest_due_at = baseline + window (default 90 days). Idempotent on (patient, marker, baseline draw).
2. Prompt — the sweep (every 6h) finds open cycles whose window is due and emits clinical.retest.prompted.v1 (respecting a re-prompt interval + max prompt count). This is the system-measured replacement for manual outreach.
3. Record — when a follow-up lab arrives (clinical.biomarker.added.v1), an isolated handler closes the open cycle, computing the delta + a range-aware outcome direction, and emits clinical.retest.recorded.v1 — the Outcome Record.
4. Expire — cycles past the window + grace (default 30 days) with no follow-up are closed to expired, so the join window stays bounded.

Two flags — both off

The split mirrors AI-insights: with retest-cycle on alone, the system passively measures organic re-test behavior (cycles open and close, nothing is sent). Turning retest-prompt on additionally nudges members. Either is one flag flip to roll back.

Events

All three carry biomarker codes, timing, and outcome direction only — never raw values (ADR-0046). recorded.v1 is the wire the intelligence layer’s Outcome Join will attribute back to a serving decision once the clinical track activates.

PHI + erasure

retest_cycles holds the raw baseline/follow-up values; the retest_cycles_safe view omits them (values, units, delta). Cross-service reads + the platform_readonly role use the safe view. Erasure deletes a member’s cycles via the clinical erasure path (keyed by patient_id, the canonical loop user uuid — ADR-0071). Every state change is audited with PHI-safe details only.

Activation steps (what flipping the flags requires)

The data plane is complete and dark. Reaching live member prompts needs, in order:

1. B-0 — health.* RLS enablement (sign-off gated) before real PHI flows.
2. Enrol an opt-in cohort via POST /v1/retest-cycles (or wire baseline auto-capture from lab ingestion).
3. A comms consumer for clinical.retest.prompted.v1 to render + deliver the nudge (clinical stays PHI-minimal and never handles the recipient address) — and link the flag provider secret to the sweep cron so retest-prompt evaluates non-default.

Until then the sweep prompts nothing (the flag fails closed) and no member is contacted.

The go/no-go gate (B-2)

GET /v1/retest-cycles/stats aggregates the data plane into the one number the clinical moat hangs on: the re-test rate = retested / (retested + expired) among closed cycles, plus per-status counts and average days-to-retest. This makes “will members re-test?” answerable from the system instead of a hand-run concierge probe — read-scoped, aggregate counts only (no PHI). Watch it as the opt-in cohort runs; a plausibly-high rate is the green light for the clinical model (B-4).

Health

The sweep is an SST Cron (clinical-retest-cycle-sweep, rate(6 hours)). A failed cycle never aborts the batch — it is retried next run. See the clinical service runbooks under services/clinical/.