Skip to content

How the Product Learns — Rx360 AI Learning Strategy & Spec

Date: 2026-06-03 · Owner: Gene (Pharmacy Ops) · Scope: the whole product's AI — Balance Meter algorithm · medication matching · label scanner · smart scheduling. Form: strategy (what/why/guardrails) + a build-ready spec per learning system.

Posture (per Elliot): build the smartest, fastest, most personalized learning system in the category — then let counsel draw the "too clinical" line. Boundary items are marked ⚖ LEGAL-REVIEW. We keep member-facing claims wellness-safe (the device-classification line); the internal intelligence aims high.

Part 1 — Strategy

1.1 The thesis

Every member interaction and every pilot cycle makes the model better → better signal → more engagement → more data → a better model. That compounding, personalized engine is the moat and the acquisition thesis (deck S15/S19). Competitors ship a static algorithm; we ship one that learns each member and the population.

1.2 The four things the product learns

  1. Balance Meter algorithm — each member's own normal, and (from the pilot) which inputs actually predict change → moves us from literature-set weights to learned, individualized ones.
  2. Medication matching — the most-likely form/route/strength/frequency per drug, sharpened by every user/pharmacist correction (the Faraz spec §7).
  3. Label scanner / OCR — field extraction and drug disambiguation, learned from corrected reads + per-jurisdiction label patterns (ties to the Scanner Label Requirements KB).
  4. Smart scheduling — each member's real dosing rhythm → personalized reminder timing + tolerance windows (the next patent topic).

1.3 Cross-cutting guardrails (apply to all four)

  • Wellness-lane outputs. The member sees wellness signals — never a learned diagnosis, prediction, or dosing instruction. Learning makes the experience smarter, not the claims bolder.
  • Provenance-weighted inputs. self < scan/import < pharmacist-verified — high-trust signals teach faster (same model as the Balance Meter).
  • Human-in-the-loop for anything clinical-adjacent. The pharmacist is the trust gate; nothing clinical auto-deploys without sign-off (Matilda) + validation.
  • Privacy & consent. Member-level data stays local/secure; only de-identified aggregates train shared models; learning is consented and explainable.
  • Never learn to harm. No learned dosing advice, no learned auto-changes to a regimen, no silent clinical decisions.
  • ⚖ LEGAL-REVIEW the edges. Where learning trends toward CDS/device (a learned fall predictor, learned dosing/scheduling intelligence) — build it, flag it, let counsel set the limit.

Part 2 — Spec (per learning system)

Format for each: signals in → what's learned → update cadence → guardrails → metric.

2.1 Balance Meter algorithm

  • Signals in: live gait/IMU + PPG; the member's rolling baseline; medication-change events; conditions; (pilot) reported falls/near-falls + gait drift.
  • What's learned:
  • the per-member personal baseline ("your usual") — continuously;
  • population priors by age/cohort;
  • which Layer-1 inputs actually predict change → re-weight candidates (move off literature-only weights);
  • the delta-threshold curve (the sensitivity dial) calibrated against outcomes (today provisional, pilot-validated).
  • Update cadence: baseline = continuous/online; weight + threshold recalibration = offline, per pilot cycle, validated before any deploy.
  • Guardrails: no weight/threshold change ships without validation + clinical sign-off; output stays a band (no number); still labeled "composite index, not a validated predictor" until outcome-validated. ⚖ a learned fall predictor is the device line — staged for an acquirer.
  • Metric: band stability / false-positive rate; (exploratory) concordance of "Worth a Look" weeks with reported falls; personalization lift vs the static model.

2.2 Medication matching (from the Faraz spec §7)

  • Signals in: user swaps of a default; pharmacist corrections; scan corrections.
  • What's learned: per-drug priors (modal form/strength/frequency) — globally and per population/age band; brand↔generic preference; common SIG patterns.
  • Update cadence: priors updated in batch; pharmacist-verified corrections promote a default faster (high trust).
  • Guardrails: never learn to auto-commit a high-risk default beyond the confidence gate; never learn a "dose recommendation"; every learned default stays editable.
  • Metric: auto-fill acceptance rate (defaults accepted unedited) — the north-star; rises as the loop runs.

2.3 Label scanner / OCR

  • Signals in: corrected label reads; multi-frame stitch outcomes; per-jurisdiction label layouts (Scanner Label Requirements KB).
  • What's learned: label-field extraction; drug-name disambiguation; jurisdiction-specific label structure (CA vs WA, etc.).
  • Update cadence: retrain on the corrected corpus; the end-of-scan analysis pass stays the anti-hallucination gate.
  • Guardrails: confidence-gated; human confirm before commit; never hallucinate a field — absent = absent, not guessed.
  • Metric: field-extraction accuracy; hallucination rate (→ 0).

2.4 Smart scheduling (ties to the next patent topic)

  • Signals in: dose-confirmation timing; missed-dose patterns; snooze/skip behavior; drug-class cadence (q8h / daily / weekly / monthly) + tolerance windows.
  • What's learned: the member's actual rhythm → personalize when and how to remind, and the tolerance window per drug; predict a likely miss → pre-empt with a gentler/earlier nudge.
  • Update cadence: continuous personalization per member.
  • Guardrails: wellness-lane — these are reminders, not clinical dosing instructions; never auto-change a regimen; the cadence/tolerance intelligence is the patent-novel area. ⚖ flag the line; this feeds the Smart-Scheduling invention brief.
  • Metric: dose-confirmation rate; missed-dose reduction (framed as engagement, not an efficacy claim).

Part 3 — The learning infrastructure (cross-system)

  • Data governance: provenance tags on every input; consent + explainability; member-level data stays local/secure; only de-identified aggregates train shared models (the data-classification rule).
  • Model lifecycle (the safety rail): learn (offline) → validate → clinical sign-off where clinical → gated deploy → monitor. No silent auto-deploy of any clinical-affecting change.
  • The flywheel: data → learn → better model → better signal → more engagement → more data. The compounding loop is the asset.
  • Trust gate: the pharmacist (and Matilda's clinical sign-off) is the human-in-the-loop for anything that touches the clinical boundary.

Part 4 — Why this is the acquisition thesis

A static algorithm is copyable. A compounding, personalized, multi-system model — that has learned millions of member-baselines, the real dispensing priors, the jurisdiction label patterns, and each member's dosing rhythm — is not. We build that engine in the wellness lane; an acquirer unlocks the regulated/predictive claims on top of a model that's already smart. That's the moat, and the multiplier on the valuation.

Part 5 — Open questions (per "ask, don't guess")

  1. Validation-gate ownership — Matilda signs off clinical model changes; who owns the ML validation pipeline + the deploy gate?
  2. Data/consent + hosting — where do models train/run; what's the consent language; on-device vs cloud for member-level signals?
  3. Smart-scheduling overlap — §2.4 is also the next patent topic. Should the cadence/tolerance learning be specced here or carved into the Smart-Scheduling invention brief (or both, cross-referenced)?
  4. ⚖ The legal pass — same counsel review as the Faraz spec: how far do we go on learned fall-prediction (§2.1) and learned scheduling intelligence (§2.4) before they cross into device/CDS?
  5. Build sequencing — which loop ships first? (Med-matching is closest — the corrections data starts flowing at onboarding.)