Rx360 — Workstream Roadmaps to Completion¶

Date: 2026-07-03 · Owner: Gene Lang, PharmD — Director of Pharmacy Operations Built by: multi-agent Workflow (per-workstream roadmap agents, each grounded in that workstream's actual docs), adversarially critiqued. Companion: Rx360_Master_Product_Roadmap_2026-07-03.md (the synthesized cross-workstream view — critical path, phase gates, next actions). Status: 🟡 Draft — a planning artifact, not a commitment. Dates are relative (Now/Next/Later) unless a source doc gives a real one.

Fall Barometer / Balance Meter (the fall-risk product)¶

Where it stands now¶

Locked / validated: - Canonical scoring model is the frozen spine. Balance_Meter_Canonical_Model_2026-05-20.md defines the full two-layer architecture: Layer 1 (baseline risk, 0–100, six capped categories — fall history 30, meds 22, conditions 22, mobility 18, sensory 14, mood 10) and Layer 2 (live gait deviation from personal baseline → band). It is marked ✅ CURRENT — single source of truth and is trade-secret (weights/caps/curves must never leave the core team). - Medication portion is calibrated. The cap of 22 lands at the p95 of 754 anchor-site seniors (Sandbox_Calibration). This is the one Layer 1 sub-component with real cohort calibration, not just literature grounding. - Wearer-facing band words are LOCKED (2026-06-29): Steady / Some Change / Worth a Look. Neutral med-change card copy (no drug attribution) is Matilda-approved and locked (6/07). - Two model refinements landed (Gene's calls): the orthostatic×antihypertensive interaction bonus was removed 6/29 (double-counted physiology); the model now carries exactly one interaction bonus (cognitive + polypharmacy). The evidence-receipts file independently corroborated the collapse to one interaction. - Fall-risk evidence base is verified. _Fall_Risk_Evidence_Receipts_2026-06-30.md carries 17 CONFIRMED effect sizes, each with a real PMID + ≥25-word verbatim quote per Hard Rule #8, plus 6 flagged/recast items that were caught and not shipped.

Designed, not built: - The intake/onboarding flow (Fall_Prediction_Monitoring_Intake_Spec_2026-05-19) is a complete working-draft spec: universal 3-respondent model (pharmacist/caregiver/wearer), STEADI 12-item screen, provenance tagging, 26-screen flow, full JSON data model. Status is "Working draft — for design review" — spec'd, not implemented. - The three-versions scaling (No-Wearable → +Mark I → +Mark II) is current product direction (Balance_Meter_Three_Versions_Spec_2026-06-07) — one model, graceful degradation. But it hinges on an un-signed positioning decision (Decision 1: making the band member-facing below Mark II reopens the 4/28 "consumer output begins Mark II" rule). - The gait/biomechanics DSP pipeline (Fall_Barometer_Gait_Biomechanics_Signal_Pipeline_2026-06-30) is a citation-verified technical grounding reference, explicitly 🟡 Draft — not yet engineering-reviewed or pharmacist-signed-off. It narrows the engineering search space; it does not specify a shippable implementation.

Not started / open engineering gaps (from the pipeline doc's own "open items"): - Bout / walking-window detection — flagged as "the single most important unbuilt prototype." No windowing scheme, sample-rate decision, or segmentation algorithm chosen. Nothing downstream can be implemented until this exists. - Sit-to-stand has no validated wrist-worn method (best validation is thigh-mounted) — needs a build/no-build/scope-out decision. - Delta-gate threshold conflict is unresolved: Sensor/DataFlow spec's ~18%/25% vs. Canonical Model's ~12%/15%. Neither has independent published support; both are pilot-calibration-gated.

Blocked: - The canonical-model source file is FROZEN pending Gene + Matilda sign-off (STATE lines 20–21). The 6/30 evidence work is verified but nothing is baked in — the receipts file states plainly: "Final weights are Gene + Matilda's call; nothing is baked until they sign." This is the gating event for the whole workstream.

Anchored constraints (do not drift): - Mark I has no automatic fall detection (manual SOS only) and no barometer/no PPG — its Layer 2 is IMU-gait-only. Automatic fall detection + the full Balance Meter is Mark II (RxBALANCE). - The pilot is usability-primary + a safety line — not efficacy, not a PDC/fall-outcome claim. The model is a "composite risk index informed by validated screens, not a validated fall predictor." Fall-outcome validation needs the pilot, which is not scoped to prove it.

Milestones to completion — Now / Next / Later¶

NOW (0–3 mo)

Gene + Matilda evidence sign-off session. Deliverable: Matilda confirms the fall-history-dominant / medication-second ordering + the diminishing-returns curve + the single interaction bonus, and endorses the 6/30 evidence integration (diabetes term, hypotension terms, A5 med terms, live-gait up-weight). Exit: canonical-model file UNFROZEN and the endorsed weights baked in; disclosure-appendix language upgraded from "pending sign-off" to "clinically endorsed." This gates everything below.
Resolve the delta-gate threshold conflict on paper. Deliverable: one reconciled mechanism (which pair of thresholds, and the rationale) — numbers stay pilot-gated. Exit: Sensor/DataFlow spec and Canonical Model agree; no two docs cite conflicting %.
Bout/walking-window detection prototype (the top unbuilt item). Deliverable: a chosen windowing + sample-rate + segmentation approach (ElderNet-style 10s windows vs. onboard heuristic; downsample-vs-native) validated on bench against a reference wearable. Exit: raw Mark I IMU → gait-speed/cadence output for a walking bout, sane direction/magnitude. Owner needs Mike + firmware.
Positioning Decision 1 to the room. Deliverable: Gene/Peyman/counsel ruling on whether the band goes member-facing below Mark II (No-Wearable standing read + Mark I live band). Exit: logged as a Locked Decision; the three-versions spec either proceeds or reverts to Mark-II-only consumer output.
Intake spec → design review → build-ready. Deliverable: close the 8 open clinical/ops decisions in §11 (STEADI wording lock, wearer-routing rule, re-ask cadence, conditions list, orthostatic Mark I fallback, pharmacist admin workflow, public name + the word "prediction"). Exit: spec moves from "working draft" to "approved for build"; Faraz/Sana lane can consume it.

NEXT (3–9 mo)

Layer 1 engine built + wired to the medication brain. Deliverable: the intake data model + Layer 1 scoring service implemented, consuming the FRID/Beers/NTI tags from the medication engine. Exit: a real wearer profile produces a Layer 1 baseline with a provenance-weighted confidence flag; No-Wearable standing read renders in wellness-safe language. (Depends on the brain being built — see Dependencies.)
Mark I Layer 2 gait signal (IMU-only) in firmware. Deliverable: cadence + gait-speed-Δ + step-timing variability computed on-device from the bout detector; asymmetry/double-support flagged low-confidence per the pipeline recommendation. Exit: a live band trips on a real gait change with the wider Mark I confidence envelope; no barometer/PPG claims anywhere.
Pilot instrumentation for calibration (not efficacy). Deliverable: the pilot captures Rx360 gait output vs. observed/self-reported walking bouts to sanity-check direction/magnitude, within the usability-primary + safety-line frame. Exit: enough field data to move delta-gate thresholds from "mechanism-locked" toward "numbers proposed" — explicitly not a fall-outcome validation.
Version-transition continuity + provenance stamping. Deliverable: re-baseline logic on every upgrade (No-Wearable→Mark I→Mark II), score stamped with the version that produced it, upgrade framed as precision-gain not risk-spike. Exit: an upgrade never trips a "Worth a Look" from the basis change alone.

LATER (9+ mo / commercial)

Mark II full Layer 2 (RxBALANCE). Deliverable: barometer fall-confirm + full gait suite + optional PPG orthostatic self-test + Pill Bottle adherence feeding the med weighting; all four surfaces (member/caregiver/Base Station/clinical) + auto-emergency calling. Exit: the productized RxBALANCE the 5-20 canonical was written for.
Sit-to-stand: build, scope-out, or ship-low-confidence. Deliverable: the §3 scope decision executed — either a dedicated wrist validation pass or explicit exclusion from Layer 2 claims. Exit: no unvalidated sit-to-stand accuracy claim ships.
Full-sensor calibration + external claim discipline. Deliverable: pilot-plus data closes the remaining Layer 1 non-medication weights (currently literature-OR-grounded, not outcome-validated). Exit: each metric either has its own validation or is labeled low-confidence in UI/claims; positioning-vs-competitors claims stay internal until Rx360 has its own validation data.

Dependencies¶

This workstream NEEDS from others: - Sign-offs (the pacing gate): Gene + Matilda on the model/evidence (blocks the freeze); Patrice to close the FRID-surfacing + operational alert-tier decisions in her lane; clinical + legal on the public name and the word "prediction." - Medication brain (designed, not built): the Balance Meter's Layer 1 medication layer is the through-line across all three versions and shares one source of drug truth with the medication engine (FRID/Beers/NTI tags + Smart-Scheduling forgiveness KB). It cannot reach full fidelity until the brain — currently owned by Faraz + the Sana team (med-entry handed off 7/01) — is built, and the clinical KB layers are still preliminary pending Dr. B pharmacist sign-off. - Device / firmware (Mike + hardware): the bout detector, on-device compute budget, sample-rate decision, and Mark I IMU gait pipeline. Mark II adds barometer/PPG/wear-detect/Pill Bottle — all in hardware's lane and in validation, not shipped. - Pilot: the only path to move any threshold from mechanism-locked to numeric — but must stay inside the usability-primary + safety-line frame (no efficacy claim). - Medication-list module: the intake §17 links to it and pulls the FRID result; it does not duplicate it. Blue Button 2.0 import (claims-verified provenance) is a future upgrade path.

OTHERS need from this workstream: - The medication engine benefits from the shared FRID tagging schema — the Balance Meter is a primary consumer of the med brain's drug-truth, so its requirements should shape the schema. - Pharmacy Operations (Patrice): the intake's pharmacist admin workflow (RxPASSPORT surface vs. separate portal vs. paper-then-keyed) shapes the anchor-site front-end. - Design/engineering: the intake spec + three-versions spec are the build-ready inputs for the consumer + clinical surfaces once approved. - Counsel / positioning: Decision 1 (member-facing below Mark II) is a company-level positioning call that ripples into GTM ("daughter orders for mom" day-one No-Wearable read).

Human gates & risks¶

Non-engineering gates (in the order they'll actually bite): 1. Gene + Matilda model/evidence sign-off — the hard freeze. Nothing bakes until this lands. 2. Patrice (pharmacy ops) — FRID-surfacing + alert-tier + pharmacist admin workflow decisions. 3. Dr. B pharmacist sign-off on the preliminary clinical KB layers the med backbone depends on. 4. Clinical + legal — public name lock and the word "prediction"; wellness-lexicon discipline on every No-Wearable string (this version drifts closest to "health-risk-assessment"). 5. Positioning Decision 1 (Gene/Peyman/counsel) — member-facing below Mark II. 6. Hardware feasibility — on-device compute budget for the segmentation algorithm; whether sit-to-stand/turns can be derived passively from a wrist sensor at all. 7. BAA gate — any fax/eRx or claims-import (Blue Button) path needs a signed BAA before go-live.

Top risks: - The frozen model is a single point of blockage. Every downstream milestone waits on one sign-off session; if Matilda's review reopens the fall-history/medication ordering or the interaction bonus, the whole schedule slips. Mitigation: run milestone 1 first, tightly scoped to the 6/30 evidence deltas. - Wrist-sensor accuracy in the target population is genuinely uncertain. The pipeline doc is candid: double-support and asymmetry are Apple's weakest-validated metrics even from a pocket phone and worse in seniors specifically; sit-to-stand has no validated wrist method. Over-claiming precision (internally or externally) is the real hazard. Mitigation: prioritize cadence (the one metric with a wrist-accelerometer fall-risk association), flag the weak metrics low-confidence, keep competitor-outperformance claims out until Rx360 has its own data. - Lexicon/regulatory drift on No-Wearable. A questionnaire-plus-meds "standing read" with no live signal is the closest thing to a health-risk-assessment — one "your fall risk is High" string breaches the wellness lane. Mitigation: heaviest lexicon/legal discipline on exactly this surface; band words and neutral med-card copy are already locked, hold that line.

Rough effort¶

NOW (0–3 mo): mostly sign-offs + decisions + one hard prototype. The bout detector (milestone 3) is the real engineering lift and needs Mike + firmware; the rest is meetings and spec-closure that Gene largely paces. Biggest schedule risk is calendar (getting Matilda + Patrice + counsel in the room), not build hours.
NEXT (3–9 mo): the heaviest build phase — Layer 1 engine + intake implementation (gated on the brain being built by Faraz/Sana) and Mark I on-device gait. Realistically bounded by the medication-brain build timeline, which is not yet dated. TBD / needs Gene on the brain's delivery date and Sana's capacity.
LATER (9+ mo): Mark II full Layer 2 + full-sensor calibration — hardware-validation-paced, commercial-horizon.

Single biggest unknown: whether a wrist-worn IMU can produce a fall-relevant gait signal accurate enough in the senior population to justify a live band — the pipeline doc shows the nearest precedent (Apple) is weakest exactly there, and Rx360 has no in-house gold-standard (force-plate/pressure-mat) to validate against. Everything from Mark I Layer 2 onward rides on the bout detector clearing that bar in the pilot. Secondary unknown: the medication-brain delivery date (owned by Faraz/Sana, undated), which paces the whole NEXT phase.

Sources: _VP_Priorities/Fall_Risk/Balance_Meter_Canonical_Model_2026-05-20.md · _VP_Priorities/Product_Specs/Balance_Meter_Three_Versions_Spec_2026-06-07.md · _VP_Priorities/Product_Specs/Fall_Barometer_Gait_Biomechanics_Signal_Pipeline_2026-06-30.md · _VP_Priorities/Fall_Risk/Fall_Prediction_Monitoring_Intake_Spec_2026-05-19.md · _VP_Priorities/_Fall_Risk_Evidence_Receipts_2026-06-30.md · STATE.md head markers.

Medication-Intelligence "brain" (KB + knowledge graph + retrieval + clinical rail)¶

Where it stands now¶

Honest read: this is a fully designed, extensively specced, but not-yet-built platform. There is no running graph, no deployed retrieval layer, and no live clinical rail. What exists is a coherent architecture and a partial, active engineering effort on the input end of it.

Designed / specced (paper-complete, not code): - The whole platform architecture is written down: layered stack, build-vs-buy per layer, interface contracts (MCP door, FHIR medication object, retrieval contract, rail contract, event schema) — AI_Foundation_Architecture_Spec_for_Faraz_2026-06-04. The load-bearing decisions are locked-in-principle in _KB_SYNTHESIS (the "12 decisions"). - The drug/clinical knowledge graph is a staged build plan (Drug_KG_Phased_Build_Plan_2026-06-29), grounded in the KB docs — node/edge model, terminology spine (RxNorm/RXCUI · RxClass · SNOMED CT + ICD-10-CM · OpenFDA/DailyMed). Explicitly labeled "🟡 SCOPE / SEQUENCE / EFFORT — this is the build plan, not the build." - The Medication Intelligence Engine (the input/enrichment engine that resolves messy input → one structured medication object) is a full phased plan with a concrete FHIR/NCPDP medication-object contract sketch (Medication_Intelligence_Engine_PHASED_PLAN_2026-06-04, §6). - Supporting specs exist and are cited as canonical: matching guardrails + LASA, curated drug KB + tagging schema, API integration guide, AI-learning strategy, SIG builder bundle, label-requirements KB (97 jurisdictions), NCPDP SCS reference. - The deterministic clinical rail ("blast door") is designed in detail (KB 03 + arch spec §5) — fail-closed, allow-listed output schema (reminder|confirmation|insight), pharmacist-queue routing, no-streaming, HITL-in-code. Design only; nothing enforces it yet.

Actually moving (input/med-entry lane, not the graph engine): - Faraz + the Sana team own the build/med-entry lane; Gene handed off med entry 7/01 (ledger D-002). - Structured SIG Schema v1 bundle shipped. NDC POC greenlit (OpenFDA + RxNorm). Metformin extraction reviewed — 84% combo products, P0 identity/join gaps flagged. - v1 engineering package SENT 6/10. v2 (172-file package + Direction deck) is STAGED on Gene, not sent (ledger D-010 @ STAGED). D-011 Meenakshi extraction-guidance reply also STAGED (D-011 @ STAGED).

Blocked / preliminary (the load-bearing gate): - Clinical KB content is PRELIMINARY. The drug-forgiveness/tolerance data (27 classes) and the FRID/risk tables carry status: preliminary pending Dr. B pharmacist sign-off. By the brain's own rule, no preliminary fact can drive member-facing behavior until a pharmacist flips it to validated — so even once the graph is built, it can't legally emit clinical content to members until sign-off lands. - The Fall Barometer's fall-risk model — which the brain's FRID-load query must reproduce — is itself verified (17 PMID-backed effect sizes) but PENDING Gene + Matilda sign-off, with the canonical-model source FROZEN until that lands. So the brain's most valuable first query (FRID load feeding the Barometer) has a downstream dependency that is itself frozen.

Not started: graph DB provisioning, terminology ingest (RxNorm/SNOMED/RxClass load), the graph itself, the retrieval layer, the rail-in-code, the event backbone/de-ID gateway, the MCP server, evals/gold set. Mike (AI architect) is being onboarded to own several of these open decisions but is gated on his NDA (inferred — same NDA blocking his docs-site access per the current-state brief).

Milestones to completion — Now / Next / Later¶

NOW (0–3 mo) — decisions, licenses, and the seedable graph 1. Lock the four gating decisions (Drug_KG_Phased_Build_Plan §"Decisions needed"): graph DB (Neo4j AuraDB vs Amazon Neptune), pharmacist reviewer + cadence for preliminary→validated, v1 scope (ship Phases 0–1 alone vs hold for full stack), BAA posture for the Member/Event layer. Exit: all four recorded in DECISIONS.md. 2. Start the UMLS/SNOMED license request. It's the named Phase-0 blocker with real lead time. Exit: UMLS account approved (or a decision to defer SNOMED and anchor on RxNorm/RxClass only for v1). 3. Onboard Mike + close his NDA, then have him drive his four owned decisions to recommendations (graph DB, retrieval stack, rail enforcement, eval/observability). Exit: NDA signed; Mike has a written recommendation on each. 4. Send the staged v2 package (D-010) + Meenakshi guidance (D-011) to unblock the Faraz/Sana input lane. Exit: ledger shows D-010, D-011 @ SENT (Gene's approval gate — nothing posts without it). 5. Phase 0 — terminology spine + governance scaffolding (per KG plan): ingest RxNorm/RxClass/OpenFDA into staging, build RXCUI↔NDC and RXCUI↔class crosswalks (reuse the Smart Add / NCPDP work), stand up the provenance/governance schema (author≠approver, status gate, de-ID gateway in front of any Member/Event data). Exit: a queryable staging store with the crosswalks + the provenance block enforced.

NEXT (3–9 mo) — a graph that answers, safely 6. Phase 1 — seed the clinical graph from existing curated assets, FRID-load query first (highest-value operation; feeds the Barometer's med category). Everything ships status: preliminary. Exit: FRID-load query reproduces the current Balance Meter med-scoring inputs on a validation set — but see the frozen-model caveat below. 7. Pharmacist sign-off pipeline live (Dr. B): the non-skippable, event-logged gate that moves seeded facts preliminary→validated. Exit: at least the FRID + forgiveness tables for the pilot's actual drug set are validated. 8. Phase 2 — retrieval layer (structured-first → vector → GraphRAG, fixed trust order; Self-RAG/CRAG grounding; every answer cites its kb_entry_id). Exit: the engine answers identity/class/FRID/interaction/forgiveness from the graph, not a free LLM; ungrounded answers refused. 9. Phase 3 — deterministic clinical rail in code (fail-closed, allow-listed schema, pharmacist-queue routing, no-streaming, HITL-in-code). Exit: rail-escape-rate measured against a clinician gold set; target clinical-line leakage = 0; nothing member-facing emits without passing the rail. 10. Medication-object contract locked + the input engine emits it (engine plan Phase 0–2 on the Faraz/Sana side, converging with the graph). Exit: one structured medication object per drug, provenance-tagged, consumed by ≥1 downstream engine.

LATER (9+ mo / commercial) — product integration, scale, learning 11. Phase 4 — product integration + learning loop: graph powers Smart Scheduling (forgiveness-aware timing), the Fall Barometer (FRID load + the cross-engine medication-change event), and med-input enrichment; Kafka event stream + de-ID gateway feed the learning plane; pharmacist gate on every promoted fact. Exit: two+ engines running off the shared graph in the pilot/build env, learning loop logging corrections behind the de-ID boundary. 12. Serving/scale tier + evals/MLOps: three-tier (on-device → BAA private-cloud → cloud), caching, offline fallback; clinician gold set as the eval contract; drift/holdout/canary+rollback; GMLP+PCCP so wellness→SaMD needs no re-architecture. Exit: eval suite gates every change; scale posture documented for the enterprise/CVS pitch. 13. Optional pitch artifact — the Replit end-to-end demo (engine plan Phase 5): messy input → structured object → schedule + fall-risk read + refill, on synthetic data. Can run off Phase 0/1 + mocked downstream, so it needn't wait for the full build. Exit: shareable URL, sample data only, no PHI.

Dependencies¶

This workstream NEEDS from others: - Pharmacist (Dr. B): sign-off pipeline for preliminary→validated. Hard blocker — the graph is "only as shippable as its sign-off pipeline" (KG plan). Without it the brain can hold clinical facts but can't surface them to members. - Fall Barometer / Balance-Meter side: the canonical fall-risk model's Gene+Matilda sign-off must land and the FROZEN source unfreeze before the FRID-load query can be validated against "current" scoring. The medication-change event's canonical contract is owned by the BalanceMeter/patent side, not here — the brain consumes it, doesn't define it. - Gene: the four gating decisions; approval to SEND the staged packages (D-010/D-011); BAA posture call. - Mike (AI architect): NDA + recommendations on graph DB / retrieval / rail / eval. - Faraz + Sana team: the med-input engine that produces the medication object the graph enriches; the NDC/RxNorm crosswalk work to reuse in Phase 0. - Counsel/BAA: a signed BAA is a go-live prerequisite for the BAA-private-cloud tier and any Member/Event (PHI-adjacent) layer. (Patent timing note: the KG was deliberately deferred until after the 2026-06-26 filing; STATE shows that filing "believed FILED, no serial" — UNCONFIRMED. Build can proceed since the date passed, but the filing status should be confirmed before anything derived from disclosed IP ships externally.) - Docs-site thread: site_manifest.yml references the canonical spec paths — any physical consolidation of Product_Specs/ med docs must be coordinated or paths break.

What OTHERS need from this workstream: - Smart Scheduling: the ForgivenessProfile (tolerance windows) for forgiveness-aware reminder timing. - Fall Barometer: the FRID-load query (its medication-risk input) + consumption of the medication-change event. The scoring stays in the Barometer; the brain supplies inputs, not the score. - All five engines: the single MCP door + the provenance envelope on every response, so they stop building five half-brains. - Pilot / enterprise pitch: the structured medication object + (optionally) the Replit demo as the proof artifact.

Human gates & risks¶

Non-engineering gates that will actually pace this: - Pharmacist sign-off (Dr. B) — the single biggest pacing gate. preliminary→validated is a human, event-logged step per fact/class; nothing member-facing moves without it. - Gene + Matilda fall-model sign-off — gates the FRID-load query's validation and unfreezes the canonical model the brain must reproduce. - UMLS/SNOMED licensing — external approval with real lead time; the named Phase-0 blocker. (Mitigation: v1 could anchor on RxNorm/RxClass and defer SNOMED — a Gene decision.) - Mike's NDA — gates the architect who owns four load-bearing decisions. - Counsel / BAA — signed BAA before the private-cloud/PHI tier goes live; patent-filing status confirmation before IP-derived material ships externally. - Gene's send approvals — D-010/D-011 sit STAGED; nothing posts to Faraz/Drive without explicit approval.

Top risks: 1. The preliminary-content bottleneck becomes the critical path. You can build the entire graph and retrieval stack and still not emit a single clinical fact to a member until pharmacist review clears the pilot's drug set. If sign-off cadence isn't resourced now, engineering finishes and the product still can't ship. Mitigation: stand up the sign-off pipeline in NEXT, not LATER; scope v1 validation to the pilot's actual drug list, not all 27 classes. 2. Scope creep into the LLM. The whole design rests on "structured-first, LLM-last, rail-always." The standing temptation is to let the model "fill gaps" for clinical content. If the rail (Phase 3) isn't built before any model can emit, clinical-line leakage stops being a bounded, engineered zero and becomes a statistical hope — and that's the wellness/SaMD boundary. Mitigation: honor the build order — rail before generate. 3. Two-graph / two-store drift and cross-workstream coupling. The lakehouse-is-truth / graph-and-vector-are-projections discipline is easy to violate under delivery pressure; and the FRID/medication-change seam couples this workstream to a Barometer model that's currently frozen. A slip on either side stalls the highest-value first deliverable. Mitigation: keep the graph a synced projection (never a hand-maintained second truth); sequence the FRID-load query to the Barometer sign-off, not ahead of it.

Rough effort¶

Per the KG plan's own estimates (steady-pace, assuming resourcing and that the human gates clear on schedule):

Phase	Focus	Effort
0	DB choice + terminology spine + governance	2–3 wks
1	Seed graph from existing KBs (FRID-load first)	3–4 wks
2	Retrieval (structured→vector→GraphRAG)	4–6 wks
3	Deterministic clinical rail	3–4 wks
4	Product integration + learning loop	6–8 wks

~5–6 months end-to-end for the graph engine at a steady pace; Phases 0–1 (~6–7 wks) deliver standalone value (a queryable drug/class/risk graph + the FRID-load query) and can ship before the rest. The input-engine lane (Faraz/Sana) runs partly in parallel and is already underway. The full platform (serving/scale + evals/MLOps + all engines integrated) is the LATER band and is realistically a 9–18 month horizon — TBD / needs Gene on resourcing (headcount, whether Mike leads platform vs advises).

Single biggest unknown: the pharmacist sign-off throughput — how fast Dr. B can move seeded facts preliminary→validated, and whether the fall-model sign-off (Gene+Matilda) lands soon enough to validate the FRID-load query. Every engineering estimate above assumes these human gates clear roughly on schedule; if they don't, the brain gets built but stays mute for member-facing clinical content. Second-order unknown: resourcing — the plans name owners but not committed FTE, and no dates for Mike's onboarding or the license approval (TBD / needs Gene).

Key files: /Users/melts/Desktop/Rx360_Operations/_VP_Priorities/Med_Intelligence/00_START_HERE.md · /Users/melts/Desktop/Rx360_Operations/_VP_Priorities/AI_Foundation/Brain_Build_Brief_2026-06-29.md · /Users/melts/Desktop/Rx360_Operations/_VP_Priorities/AI_Foundation/Drug_KG_Phased_Build_Plan_2026-06-29.md · /Users/melts/Desktop/Rx360_Operations/_VP_Priorities/Product_Specs/Medication_Intelligence_Engine_PHASED_PLAN_2026-06-04.md · /Users/melts/Desktop/Rx360_Operations/_VP_Priorities/AI_Foundation/KB/_KB_SYNTHESIS.md · /Users/melts/Desktop/Rx360_Operations/_VP_Priorities/Product_Specs/AI_Foundation_Architecture_Spec_for_Faraz_2026-06-04.md

Wearable device — hardware, firmware, sensors (Mark I → Mark II)¶

Where it stands now¶

Honest read, grounded in the four workstream docs plus the current-state brief:

Shipped / in-hand (Mark I): - BOM frozen, chips selected. Post-Tiger-Team Mark I BOM is locked at chip level (Apr-5 Hardware page): Nordic nRF9151 (cellular + optional NTN), nRF5340 MCU (+nRF52840), nPM1300 PMIC, Infineon IM72D128 mic, MAX98357 audio driver, LSM6DSV320 IMU, AKM AK09940A magnetometer, AT42QT1010 cap sensor, plus LED/haptic/battery parts. The Jamie brief calls this "BOM v7 locked, firmware in progress." - ≤10 functional pilot devices as of 4/21 (per brief). - Firmware v0.2 is real behavior, not spec-only: three parallel state machines (SOS path, medication nudge, IMU fall-candidate cascade) plus passive inputs (cap-touch wear proxy, charge, battery). Battery <5% Reservation Mode preserves the SOS path. BLE event grammar (0x02–0x06) is defined and is the caregiver-app integration contract. - Connectivity: LTE-M primary → NTN satellite fallback (3GPP NTN, not Iridium), 10s cell timeout before sat. - Sensors physically present on Mark I: IMU (320 Hz accel+gyro), GPS, mic/speaker, cap-touch, magnetometer (on the Apr-5 BOM; the sensor spec still flags it "⚠ confirm with Emil"). No barometer, no PPG, no dedicated wear-detect — formally confirmed in §13.1 of the Hardware Truth Synthesis.

Anchored fact (do not soften): Mark I has NO product-level fall detection. Firmware v0.2 runs an IMU fall-candidate cascade (free-fall → impact → 1s stillness → FALL_DETECTED) but no auto-SOS — manual confirm only. Automatic fall detection is a Mark II (RxBALANCE) feature. Externally, Mark I is "manual SOS / Support-Circle alert only" per the 6/29 positioning note in the Jamie brief.

Designed, not built: - Mark II sensor additions (barometer, dedicated wear-detect, PPG) are specified and Mark-pathed in the 6/8 Sensor & Data-Flow Spec, but there is no evidence in these docs of a Mark II BOM being locked or a Mark II device existing. The Jamie brief is still proposing the Mark II BOM (skin temp YES, PPG-standard vs Enhanced, ECG NO, NFC DEFER, dual-carrier EVALUATE) — those are open decisions for Jamie/Emil, not resolved. Note the internal tension: the Jamie brief (5/12) argues PPG should be standard; the Hardware Truth Synthesis and 6/8 spec still list PPG as "Enhanced set." That's an unresolved BOM decision (inferred from the doc conflict). - Mark II ecosystem (Base Station Mark II with screen, Pill Bottle RFID/OCR accessory, Smart Pill Dispenser) is architecturally described but scope-incomplete — the Smart Pill Dispenser doc was truncated in-source. The 6/8 sensor spec is band-only; it does not spec the accessories. - Fall-detection canonical state machine (free-fall → impact → altitude drop → stillness → 9-intent voice → resolution) and the 9 intent categories / 5 outcomes AI voice flow are fully described (Hardware Truth §2) but firmware for it does not exist — v0.3 is "planned, TBD." - On-device IMU gait-feature DSP — named in the 6/8 spec as "the single most important prototype" and it is not built. The signal-computation detail lives in a companion pipeline doc (6/30); implementation is open.

Blocked / gated: - The Balance Meter fall-risk model (the algorithm this hardware feeds) is pending Gene + Matilda sign-off; canonical-model source file is FROZEN. Hardware can proceed on the sensor/DSP side, but the scoring layer that consumes gait features is locked until sign-off. - Mark I "Simple version" fall confidence is intrinsically reduced: without barometer + dedicated wear-detect, Mark I "cannot run the full Balance Meter framework" (§13.3). Mark I is explicitly a constrained subset — IMU motion-tier only, ~60–70% of full signal, band shows "learning" not a calibrated 3-band output.

Open engineering items (normal cadence, not blockers): NTN provider final selection; PCB layout under the 628 mm²/side constraint; magnetometer presence confirmation; tremor-tolerant button-hold timing (Q1 on the Apr-28 gestures page, still open); time-critical-med snooze rule (needs pharmacist-flag definition).

Milestones to completion — Now / Next / Later¶

NOW (0–3 mo) — finish Mark I, unblock the algorithm interface - M1. Freeze Mark I firmware v0.2 for pilot. Exit: firmware flashed on the ≤10 pilot devices; SOS path + med-nudge + fall-candidate cascade + Reservation Mode all pass a bench-test matrix; BLE event codes verified against the caregiver-app contract. - M2. Lock the two open Mark I interaction rules. Exit: (a) tremor-tolerant hold-time decision made per Apr-28 Q1 (prototype with 3–5 users); (b) time-critical-med snooze/grace rule defined with a pharmacist sign-off gate. Both documented back into the interaction model. - M3. Confirm magnetometer on Mark I + finalize NTN provider. Exit: Emil confirms AK09940A is populated and usable for turn/heading; one NTN partner selected with a coverage claim engineering will stand behind. - M4. Build the Layer-1 baseline calculator (software, no hardware). Exit: STEADI + meds → sensitivity gauge runs and validates against the existing senior cohort — this is buildable today and does not wait on the frozen canonical model's cutoffs (mechanism-locked, numbers pending pilot). - M5. Ship the on-device IMU gait-feature DSP prototype. Exit: a walking bout on a Mark I band produces the gait feature vector (speed, cadence, asymmetry, step-time variability, double-support, sway) on-device and syncs features (not raw 320 Hz) over BLE; validated against the 6/30 pipeline spec. Note the wrist-worn-gait caveat — harder than the foot/waist literature.

NEXT (3–9 mo) — lock Mark II hardware, extend firmware to fall detection - M6. Lock the Mark II BOM. Exit: Jamie → Emil hand-off produces a signed BOM resolving the open decisions — barometer (required), dedicated wear-detect (required), PPG standard-vs-Enhanced settled, skin-temp in/out, ECG dropped, NFC deferred, dual-carrier/indoor-location evaluated. Clean V1/V2 designations (fixes the three spreadsheet contradictions). - M7. Mark II board bring-up. Exit: first Mark II prototype boards fabbed under the PCB-area constraint with barometer + wear-detect + PPG populated and enumerating. - M8. Firmware v0.3 — fall DETECTION. Exit: extend the state machine with barometer altitude-drop confirmation and the 9-intent voice-confirm cascade; auto-emergency-calling on no-response working on Mark II hardware. (This is the Mark I→Mark II capability jump; keep it firmly labeled Mark II.) - M9. Wire the full Balance Meter calc chain — gated on sign-off. Exit: gait features → daily metrics → 30-day personal baseline → Layer-2 deviation → 3-band output, contingent on Gene+Matilda un-freezing the canonical model. Until then, Mark II runs the same "learning" band as Mark I.

LATER (9+ mo / commercial) - M10. Mark II ecosystem accessories. Exit: Base Station Mark II (screen + 4th UI surface sync), Pill Bottle RFID/OCR accessory, and a fully-scoped Smart Pill Dispenser (currently truncated in-source) each reach a shippable spec + prototype. - M11. Enhanced SKU + long-horizon adds. Exit: SKU strategy locked (Standard vs Enhanced — extended-PPG VO2max, advanced sleep, deep HealthKit sync); dual-carrier (OmniSIM) and indoor-location (Wi-Fi/BLE mesh) evaluated for Mark II Plus / V2.5. - M12. Form-factor independence (Track-2 foundation). Exit: algorithm demonstrably runs on a non-wrist sensor path (neck/clothing/ambient), proving the "algorithm-as-moat, not form-factor" thesis the patent team is filing broadly to protect.

Dependencies¶

This workstream NEEDS from others: - Balance Meter algorithm (Fall_Risk workstream): the canonical scoring model must un-freeze (Gene+Matilda sign-off) before M9's 3-band output can ship. Hardware/DSP can proceed ahead of it; the scoring layer cannot. - Med-Intelligence "brain": Layer-1 baseline needs the medication object + FHIR + event schema (from the AI-Foundation Sprint A–B specs) and the drug-class risk mapping. Med-entry now owned by Faraz/Sana (handed off 7/01) — the pharmacist-verified med schedule is what gates whether the band ever nudges (Hard Rule #4). - Pilot: field-battery-decay curves to tune the <5% Reservation threshold; GNSS time-to-first-fix distribution (target ≤2s, real up to 45s) to validate the SOS-timing UX claim; delta-gate calibration numbers (mechanism-locked, numbers pending pilot). - Clinical (Matilda): sign-off on the Mark I gait "Some Change" descriptor and the reduced-confidence Mark I band decision. - Product/exec (Peyman + Elliot): the 24/7 monitoring-center partnership and 911 auto-dispatch decision — these are non-hardware but they shape the Mark II speaker/mic spec (live-agent conversation quality).

OTHERS need from this workstream: - Caregiver app depends on the BLE event-code map (0x02–0x06) as its integration contract — already defined and stable. - Balance Meter algorithm depends on the on-device gait-feature vector (M5) as its raw input; without the DSP the scoring model has nothing to score. - Pilot depends on M1 (flashed pilot firmware) and the ≤10 functional devices. - Product/marketing artifacts depend on this workstream's lexicon corrections propagating: "Iridium" → "NTN," Mark I = manual SOS only, fall detection = Mark II.

Human gates & risks¶

Non-engineering gates that will actually pace this: - Gene + Matilda sign-off on the canonical fall-risk model — the single hardest gate; the scoring layer is frozen until it lands. - Pharmacist sign-off on the time-critical-med flag rule (who marks a med time-critical; the 20-min grace) — blocks a specific firmware default. - Matilda clinical sign-off on the Mark I gait descriptor and reduced-confidence band. - Jamie → Emil BOM lock for Mark II — a product decision, not an engineering one; PPG standard-vs-Enhanced is the contested call. - Peyman/Elliot on the monitoring-center partnership and regulatory posture of any Mark II auto-SOS. - Patent/counsel: the "build broadly toward the north star" mandate shapes BOM breadth; note the non-provisional filing status is UNCONFIRMED per the brief — not a hardware blocker but a background gate. - Hardware feasibility: the 628 mm²/side PCB constraint — every added Mark II sensor competes for area; this is why PPG got pushed to "Enhanced."

Top risks: 1. Wellness-lane discipline on Mark II auto-SOS. Automatic emergency calling on no-response drifts toward monitored-PERS / 510(k) territory. v0.2's "no auto-SOS, helps detect and alerts your circle" is the safe framing; adding auto-dispatch must clear regulatory review or it re-classifies the device (WHOOP warning-letter precedent). 2. Mark I over-promise. Mark I physically cannot run the full Balance Meter (no barometer, no PPG, no true wear-detect). Any pilot/partner deliverable that implies Mark I does automatic fall detection or a calibrated balance score is a factual error — the 6/29 positioning note exists precisely because this line kept getting crossed. 3. The gait DSP is the critical-path unknown. Wrist-worn gait sensing is harder than the foot/waist literature this repo leaned on; if on-device feature extraction under Emil's compute/power budget doesn't hit fidelity, the whole Balance Meter output degrades regardless of the algorithm sign-off.

Rough effort¶

Ballpark, honest, TBD where I can't ground it:

NOW (0–3 mo): Moderate. Mark I firmware freeze + interaction-rule locks are finishing work, not net-new (M1–M3). The Layer-1 calculator (M4) is small pure-software. The gait DSP prototype (M5) is the heavy lift in this phase — embedded/firmware + signal validation; call it the bulk of engineering hours here.
NEXT (3–9 mo): Heavy. A new board (Mark II bring-up, M7) plus firmware v0.3 fall-detection with the voice cascade (M8) is the largest single block of work in the whole roadmap — new sensors, new state-machine branches, and the AI voice classifier. M6 (BOM lock) is decision-latency, not build-latency.
LATER (9+ mo): Large + open-ended. The Mark II ecosystem accessories (M10) are effectively three additional product programs (Base Station, Pill Bottle, Dispenser), one of which isn't even fully scoped in-source.

Single biggest unknown: whether on-device wrist-worn gait-feature extraction hits usable fidelity within Mark II's compute + power + PCB-area budget. Everything downstream — the Balance Meter band, the Mark II value story, the Track-2 algorithm moat — rests on that DSP working on-wrist. Timeline for it is TBD / needs Emil's compute-budget answer.

Source docs: /Users/melts/Desktop/Rx360_Operations/Rx360_Shared_Drive/03_Product_Architecture_and_Strategy/Hardware_Truth_Synthesis_2026-05-04.md · /Users/melts/Desktop/Rx360_Operations/_VP_Priorities/Product_Specs/Wearable_Firmware_v0.2_State_Machine.md · /Users/melts/Desktop/Rx360_Operations/_VP_Priorities/Fall_Risk/Rx360_Wearable_Hardware_Roadmap_2026-05-12.md (the "Jamie North Star" prep doc) · /Users/melts/Desktop/Rx360_Operations/_VP_Priorities/Product_Specs/Balance_Meter_Sensor_DataFlow_Spec_2026-06-08.md

Smart Scheduling (PK/PD-aware reminders)¶

Where it stands now¶

Proposed / spec-and-claim stage — nothing built. This workstream exists today as a patent-scoping and design corpus, not as running software. The anchoring artifacts are all dated 2026-06-04 (Invention Brief, Claim Architecture) and 2026-06-03 (KB synthesis + five KB docs), produced for the 6/04 patent working meeting. No code, no shipped reminder behavior, no deployed engine is described anywhere in these docs.

What actually exists:

Invention Brief + Claim Architecture — DRAFTED, counsel-facing. A six-element claim spine (curated PK/PD tolerance windows · dose-time context payload · cross-engine medication-change event · provenance-tiered scheduling · confirmation-first de-escalation · wellness-lane framing) plus an independent/dependent claim structure. These are explicitly inventor drafts for counsel, not legal claim language ("⚖ THIS IS NOT LEGAL CLAIM LANGUAGE") and not a build spec.
Prior-art read — DONE and honest. The docs correctly refuse to lead on the crowded corridor (Alarm.com US9070267B2 priority-2011 as closest art; Medisafe JITI; cloud-ANN US 12040066; US10255412B2; the RL/JITAI corpus). The claimable white space is narrowed to the integration + un-arted cores. FTO is NOT done — a formal freedom-to-operate search is flagged as a counsel deliverable, not completed (Brief §4, §6).
Clinical KB (the "backbone") — DRAFT v0.1, explicitly pending pharmacist sign-off. KB/02 carries 27 drug-class rows (cadence, t½, qualitative forgiveness tier, missed-dose handling, food/timing) and a high-stakes/NTI table. Every value is flagged [APPROX]/[SIGN-OFF]; the header states plainly it "must be clinically validated by a licensed pharmacist before it informs any production behavior" and today "informs design and architecture discussions only — not production behavior." Tolerance windows are qualitative tiers only — the actual numeric cut-points (minutes/hours per tier) are explicitly deferred to the pharmacist. Several source values came from secondary/consumer sources because primary labels were paywalled — an open cross-check item.
Evidence base — cited, reasonably solid. The five KB docs are fully cited (26/28/~40/26/30 sources); field grounding comes from the anchor-site pre-pilot memos (~43 seniors) plus external RCTs/meta-analyses. This is the strongest-standing piece. (Note: per the citation-integrity rule, before any of these move to a stakeholder/production doc, each stat needs its ≥25-word verbatim quote + locator re-verified — the KB cites sources but I did not re-audit each quote here.)
Architecture — DESIGNED on paper, not built. KB/04 + AI_Learning_Strategy_and_Spec describe the intended stack: RxNorm → DailyMed/SPL + openFDA → curated PK/PD table → RAG retrieval → deterministic safety rail → FHIR Dosage/iCal RRULE → HealthKit/Health Connect + OS notifications → shared med-change event bus to the Balance Meter, with NCPDP SCRIPT feeding the pharmacist-verified provenance tier. This is a target architecture, not an implemented one.

Two hard external anchors this rides on (both unresolved): - The brain is designed, not built — the curated drug KB, RAG layer, and safety rail this feature needs are the same Medication-Intelligence corpus that is spec'd but unbuilt, with the build/med-entry lane handed to the Faraz/Sana team. - The cross-engine medication-change event (the single strongest novelty per both the Brief and D2) depends on the Balance Meter, whose canonical model is FROZEN pending Gene+Matilda sign-off — so the counterpart engine to couple with is itself gated.

(Inferred) Priority order among the deliverables: because de-escalation, dose-context payload, and PRN-exclusion are deterministic and don't need the learning loop or the fall engine, they are the lowest-risk things to build first — consistent with the KB's stated build order (ground → rail → instrument → deterministic → then learn).

Milestones to completion — Now / Next / Later¶

NOW (0–3 mo) — lock the two gates that everything else waits on

Pharmacist sign-off on KB/02 (the 27-class tolerance table + numeric cut-points). Deliverable: a signed-off v1.0 tolerance table with per-tier numeric windows (minutes/hours), a confirmed high-stakes/NTI list (digoxin/phenytoin/lithium resolved), and DailyMed/FDA cross-checks on the paywalled-source values. Exit criterion: every [APPROX]/[SIGN-OFF] cell is either confirmed or corrected, the numeric cut-points exist, and a named pharmacist has signed — the header DRAFT banner comes off.
Counsel go/no-go on scope + the CDS/wellness line + portfolio question. Deliverable: counsel opinion on (a) FTO vs the Alarm.com corridor, (b) where curated-tolerance + miss-prediction crosses from wellness into CDS, (c) file with the Balance Meter or separately. Exit criterion: a written counsel position on claimable scope and a filing decision Gene can act on. (SENT ≠ filed — track to actual disposition.)
Formal FTO search commissioned. Deliverable: counsel-run FTO against the named corridor (US9070267B2, Medisafe JITI, US 12040066, US10255412B2, US8040236B2 + Google meal-reminder filing, RL/JITAI). Exit criterion: FTO report in hand; independent claim's (a)+(b)+(d)+(e) center of gravity confirmed clear or narrowed with counsel guidance.

NEXT (3–9 mo) — build the deterministic core (no learning, no fall coupling yet)

Deterministic scheduler v1 on the signed-off KB. Deliverable: engine that maps each med to cadence + forgiveness tier + timing rules and generates reminders whose window and escalation follow the tolerance tier; PRN drugs excluded from scheduled reminders (tracked by refill/usage instead). Exit criterion: for a test panel of the 27 classes, reminder timing/window matches the signed-off table; PRN meds generate zero scheduled reminders.
Deterministic safety rail + dose-context payload. Deliverable: a rail that blocks any take/skip/double/titrate output to the member and routes high-stakes miss/irregular events to "check with your pharmacist/care team"; dose-time context (with-food, empty-stomach, upright, rinse-mouth) surfaced as neutral reminder copy sourced from SPL. Exit criterion: no member-facing path can emit a dosing instruction (verified by test); high-stakes events always route to escalation, never to logic; pharmacist has signed off on the member-facing copy.
Confirmation-first de-escalation loop. Deliverable: confirmation capture that suppresses further reminders for a confirmed dose and monotonically lowers reminder intensity as a per-dose streak grows (raising only on a detected lapse). Exit criterion: measurable drop in reminders-per-confirmed-dose over a proving-out period, with false-alert/alarm-fatigue rate held as a guardrail (a scheduling "win" that raises fatigue counts as a loss).
Provenance tier wiring. Deliverable: regimen provenance (self-entered / imported / pharmacist-verified via NCPDP SCRIPT) mapped to discrete reminder-precision levels; verified provenance unlocks the most precise tier. Exit criterion: precision tier changes observably with provenance; shares the same provenance model as the Balance Meter and med-matching engine (portfolio coherence verified).

LATER (9+ mo / commercial)

Cross-engine medication-change event (the flagship novelty) — after the Balance Meter unfreezes. Deliverable: a single med-change event that simultaneously opens a scheduling-attention window and a Balance Meter sensitivity watch-window, over a shared event bus. Exit criterion: one fall-risk-relevant med change fires one event consumed by both engines with bounded-duration windows; end-to-end demo across both surfaces.
Learning layer (contextual-bandit timing / learned personal rhythm). Deliverable: the personalization loop from the AI spec, on top of the deterministic base, with clinical sign-off gating any clinical-affecting deploy. Exit criterion: confirmation-rate improvement as the bandit reward, alarm-fatigue rate flat-or-down as guardrail; kept in dependent-claim territory so it never drifts into the independent claim / CDS line. (Positioned as table-stakes, not the differentiator — per the prior-art read.)
RPM/reimbursement optionality (business decision, not a build gate). Deliverable: leverage the Jan-2026 FDA-wellness/CMS-RTM shifts to stage an RPM/SaMD ramp if/when Rx360 chooses. Exit criterion: a Gene/Peyman go/no-go on whether to cross the wellness→reimbursement boundary; TBD / needs Gene.

Dependencies¶

Smart Scheduling NEEDS from others: - Brain (Med-Intelligence, Faraz/Sana lane): the curated drug KB, RxNorm identity/NDC resolution, DailyMed/SPL + openFDA dose-context ingest, the RAG retrieval layer, and the deterministic safety rail. Smart Scheduling is a consumer of the brain — it cannot ship before the brain's KB + rail exist. The clinical KB layers are the same ones flagged preliminary pending Dr. B sign-off. - Balance Meter / Fall-Risk (Fall_Risk lane): the counterpart engine for the cross-engine event, plus the shared provenance model and shared med-change event schema. Blocked on the canonical model being FROZEN pending Gene+Matilda sign-off — milestone 8 cannot start until that lands. - Device (Mark I / Mark II): the reminder-delivery surface (OS notifications, confirmation taps) and HealthKit/Health Connect medication hooks. (Anchor fact: Mark I has no fall detection and no PPG — the fall coupling is a Mark II concern, not Mark I; Smart Scheduling's reminder/confirmation piece can run on the Mark I surface.) - Provenance / pharmacist-verified tier: NCPDP SCRIPT feed; provenance is patient → pharmacist/tech → device (Rx360 rep has zero med-list visibility — respect that data-flow boundary). - Sign-offs: pharmacist (KB), counsel (scope/FTO/filing), Gene+Matilda (indirectly, via the Balance Meter unfreeze).

Others NEED from Smart Scheduling: - Balance Meter / portfolio filing: the shared med-change event schema and shared provenance model originate as much here as there — the two filings should be coordinated (Brief §6, Claim Architecture note 4). Whoever defines the event schema first constrains the other; this is a real cross-workstream handoff to sequence deliberately. - Patent portfolio: this workstream feeds the coordinated-vs-separate filing decision for the whole device-side IP. - Pilot: (inferred) reminder/confirmation UX could inform pilot usability observations, but note the anchor fact — the pilot is usability-primary + a safety line, explicitly NOT a device-efficacy/PDC claim, and adherence/PDC lives in the separate USC-led IRB arm. Smart Scheduling must not be framed as making an adherence-efficacy claim inside the usability pilot.

Human gates & risks¶

Non-engineering gates that will actually pace this: - Pharmacist sign-off (Dr. B) on KB/02 — the single hardest dependency; nothing production-facing moves until the tolerance table + numeric cut-points + NTI list are signed. Explicitly the top open flag in every doc. - Counsel / patent — scope, the CDS/wellness line call ("let counsel draw the line" per Elliot), FTO against the crowded corridor, and the coordinated-vs-separate filing decision. A provisional exists (per the brief's context); non-provisional timing is a counsel call. - Gene+Matilda sign-off on the Balance Meter — gates the cross-engine event (milestone 8), indirectly pacing the flagship novelty. - Gene decisions — portfolio filing choice; whether/when to cross into RPM/reimbursement; disclosure timing (shared question with the Balance Meter filing). - Vendor/BAA — (inferred) any fax/eRx/NCPDP SCRIPT provenance feed that touches a real pharmacy connection will need a signed BAA before go-live; flag at the point that integration is wired. - IRB — not a direct gate for the wellness reminder feature, but relevant to keeping Smart Scheduling out of the USC adherence arm's efficacy framing.

Top risks: 1. FTO collision. The corridor is genuinely crowded (Alarm.com 2011 is close). If counsel finds the independent claim's (a)+(b)+(d)+(e) combination narrower than hoped, the defensible asset shrinks to the dependents (D1 curated/auditable, D2 cross-engine, D4 dose-context, D5 de-escalation). Mitigation is already baked in: lead on the integration, keep prediction/personalization dependent-only. 2. The flagship novelty is double-gated. D2 (cross-engine med-change event) is the strongest single piece and depends on a FROZEN Balance Meter. If that sign-off slips, the most defensible claim is the last thing buildable — a real sequencing risk for both the patent and the product. 3. Clinical accuracy / liability of the tolerance table. These are seniors on high-stakes drugs (insulin, warfarin, DOACs, methotrexate-weekly, denosumab). A wrong forgiveness tier or a member-facing string that reads as dosing advice is both a safety and a wellness-lane-violation risk. The safety rail + pharmacist copy sign-off are the mitigations, and they must land before any member ever sees a reminder.

Rough effort¶

NOW (0–3 mo): low engineering effort, high human-gate effort — the work is pharmacist review cycles + counsel opinions + an FTO commission, not code. Calendar-bound by other people's availability, not by build velocity. Ballpark 1–3 months, dominated by review turnaround.
NEXT (3–9 mo): moderate engineering — a deterministic scheduler + rail + de-escalation + provenance wiring, but only if the brain's KB/RAG/rail substrate exists to build on. If the brain isn't there, this phase inherits the brain's timeline. Ballpark 3–6 months of build once the substrate and signed KB are ready.
LATER (9+ mo): the cross-engine event is small once both engines exist but is gated on the Balance Meter unfreeze; the learning layer is the largest genuinely-new build and the least urgent. Commercial/RPM is a business decision, not an effort estimate.

Single biggest unknown: the brain's real build timeline. Smart Scheduling is architecturally a thin, defensible layer on top of the Medication-Intelligence brain (curated KB + RAG + safety rail). That brain is designed-not-built and owned by another lane (Faraz/Sana), so Smart Scheduling's true schedule is hostage to when that substrate ships — which is TBD / needs Gene. Everything in NEXT assumes it exists; if it doesn't, NEXT slides right by exactly that much.

Source files: /Users/melts/Desktop/Rx360_Operations/_VP_Priorities/Smart_Scheduling/Smart_Scheduling_Invention_Brief_2026-06-04.md · /Users/melts/Desktop/Rx360_Operations/_VP_Priorities/Smart_Scheduling/Smart_Scheduling_Claim_Architecture_2026-06-04.md · /Users/melts/Desktop/Rx360_Operations/_VP_Priorities/Smart_Scheduling/KB/_KB_SYNTHESIS.md · /Users/melts/Desktop/Rx360_Operations/_VP_Priorities/Smart_Scheduling/KB/02_Drug_Forgiveness_Tolerance_Data.md

Pilot, Clinical/IRB, Regulatory & Go-to-Market (getting it into the world + paid)¶

Where it stands now¶

Honest read, grounded in the actual docs. The single most important caveat: the pilot's operational schedule (PP-18 v2.1) is an April-dated plan whose phase dates have already passed (Phase 0 "Apr 20–May 9," Phase 1 "May 18," Phase 2 "June 15," Phase 3 "July 20"), and STATE carries no confirmation that any phase actually launched or completed. So most "planned" items below are planned-but-unverified, not shipped. Where the docs themselves flag staleness, I say so.

Regulatory posture — SETTLED (strategy) / DESIGNED (defenses). - 100% wellness / FDA General Wellness enforcement-discretion lane is locked (Peyman 4/20; DECISIONS.md 🔒). No FDA submission path, no efficacy claims. This is a decision, not a filing — there is nothing to "get approved." - The regulatory research is solid and primary-sourced: the Jan 6 2026 General Wellness guidance update, the WHOOP warning letter (7/14/25), and the SeniorLife Technologies warning letter (8/21/25) — the closest analog to Rx360 — are all documented with the exact banned claim patterns ("proactively identifies fall risk," "detect early signs of [disease]"). This is a claims-discipline framework, not a clearance. Enforced continuously via the Wellness Lexicon. - Not-yet-resolved regulatory items: the FDA CDS Software guidance (final March 2026) still needs a pull if a pharmacist-facing dashboard ships (flagged in the FDA research doc, §06). The gated clinical-CDS surface is where wellness-lane protection gets tested — that's designed, not built.

IRB / Clinical — DRAFT + BLOCKED on a stale determination. - Gene's protocol feedback (v4.1) is a strong, complete section-by-section review handed to Monika + Kristen. But it is feedback on the protocol, not the approved protocol itself. - IRB classification is UNCONFIRMED. Both PP-4 and PP-18 explicitly flag [STALE — 2026-06-29]: the NHSR-vs-exemption-vs-Category 2/3 question was pending "Kristen's 4/23 advisory call," which is now months old and "the live classification is not confirmed in this file." Nothing in STATE resolves it. This is the single biggest open gate in the whole workstream. - Two-arm structure is the anchored framing: the Mark I pilot is usability-primary + a safety line, explicitly NOT a device-efficacy / PDC claim (PP-18 §4.1 adherence-framing callout). Causal adherence/PDC lives in a separate USC-led IRB arm, refill-based, its own IRB. That separation is the defense against the pilot reading as back-door device efficacy. (The USC arm's own IRB/protocol status is not documented here — treat as not-started / TBD needs Gene.) - BAA is blocked. PP-18 §6 lists "BAA executed (anchor-site–Rx360)" as blocked by PP-23 (legal review), and it's a prerequisite for Phase 0 and every subsequent phase. T-014 (PP-84 BAA review) is still open.

Pilot operations — well-planned on paper, launch-status unverified. - The operational deliverables are mature and detailed: PP-4 (site selection, anchor-first), PP-18 (phased schedule), PP-27 (personnel), PP-72 (staffing), PP-85 (onboarding + screening guides, v3.2/v4.1). These are draft-complete deliverables, several with formatted .docx companions. - Anchor-site-first is locked as the operating model (Gene owns the pharmacy → operational control, existing de-identified dataset, RX30 integration path). Expansion Sites 2–5 are directional targets + a 10-candidate pipeline (PP-106), gated on Dr. Baron's gateway and per-site BAA/IRB amendments — not-started. - Hardware is the pacing risk the docs themselves flag: ≤10 potentially-functional Mark I units as of 4/21; PP-18 says Phase 2 (wearable take-home) is "at risk if functional-device count is <10." Mark I is SOS/circle only — NO fall detection (Hard Rule #3, reconfirmed in DECISIONS). - Pharmacist verification is in the onboarding flow — but note the DECISIONS.md correction: it is data-accuracy QA + opt-in service, NEVER a feature gate (April "hard gate" model was rejected 5/18). Reminders work for every member regardless.

Go-to-Market / revenue — RESEARCHED, PRE-COMMERCIAL (nothing sold). - The monetization thesis is thoroughly primary-sourced (R4/R5): Star Ratings (adherence measures = 11.1% combined Part D weight 2026, triple-weight snap-back 2027), RTM (2026 PFS expansion made Rx360's brief-interaction use case newly billable; codes stable on CMS New Tech List through Apr 2030), MTM (99605/99606), and a 6-category B2B model ($30–120M ARR projected at 24-month scale). - Reality check: this is a research memo, not a pipeline. No B2B customer, no signed distribution partner, no revenue. Outcomes/TDS (23M patients, 60K pharmacies) is identified as the natural distribution partner but no outreach has happened (R4/R5 §08 lists it as a "this quarter" next-action; not logged done anywhere). The open questions are unresolved: can Rx360 collect fees as a non-pharmacy vendor or must it route through a pharmacy TIN? (§07). (Inferred: revenue is 12–24+ months out and downstream of a completed pilot + real adherence signal.)

One-line status by pillar: Regulatory strategy = settled; regulatory defenses = designed. IRB = drafted, blocked on stale classification + BAA. Pilot = plan-complete, launch unverified, hardware-gated. GTM = researched, zero commercial motion.

Milestones to completion — Now / Next / Later¶

NOW (0–3 mo) — unblock the pilot's front gate and confirm reality.

Refresh the pilot's live status + re-date PP-18/PP-4. — Deliverable: an updated PP-18 that replaces the passed April→August phase dates with real current status (which phases ran, which slipped) + a corrected critical-path table. Exit: PP-18/PP-4 no longer carry [STALE] flags; every phase row shows an actual state, not an April projection.
Confirm the IRB determination in writing. — Deliverable: documented current classification (NHSR determination vs. exemption Cat 2/3 vs. expedited/full), from Kristen/Advarra, with a date. Exit: the classification is recorded in STATE + DECISIONS as CONFIRMED, and the stale-flag lines in PP-4/PP-18 are resolved. This is the top blocker.
Close the BAA. — Deliverable: executed anchor-site↔Rx360 BAA (PP-84 / unblock PP-23). Exit: T-014 closed with the signed BAA returned; Phase 2+ PHI collection is legally covered.
Land the fall-risk evidence sign-off (Gene + Matilda). — Deliverable: Gene's 3 ⚑ calls on the weight-revision proposal + Matilda's sign-off on the 17-PMID evidence set. Exit: canonical Balance Meter model unfreezes; _Fall_Risk_Evidence_Receipts is folded in. (Gates Mark II, not the Mark I pilot — but it's the longest-pole clinical gate.)
Lock the four soft directions. — Deliverable: /lock-decision on acquisition-exit strategy, caregiver-first messaging, "Stay Healthy Stay Independent" tagline, adherence-demoted-below-fall (T-006/7/8, open 2+ months). Exit: four LOCKED rows in DECISIONS; no thread re-litigates them.

NEXT (3–9 mo) — run the pilot cleanly, stand up the USC arm, open the first commercial door.

Execute the Mark I usability pilot end-to-end (app-only → wearable take-home). — Deliverable: completed cohorts through the wearable phase (target ~20/phase, continuous enrollment). Exit: usability + safety endpoints collected; closing-session data in hand; no efficacy/PDC claim made (adherence data tagged exploratory-UX only).
Stand up the separate USC-led PDC/adherence IRB arm. — Deliverable: its own IRB submission + protocol (refill-based, change-from-baseline). Exit: USC arm has its own IRB approval, distinct from the usability pilot. (Inferred scope — no USC-arm protocol exists in these docs yet; needs Gene + USC.)
Produce the pilot results package. — Deliverable: usability findings + population/feasibility summary (PP-15 post-pilot framework, T-017). Exit: a shareable results doc that supports the acquisition-optionality narrative and the Star-Rating/RTM pitch — without crossing a claims line (scrub against SeniorLife patterns).
First commercial conversation: Outcomes/TDS + one MA-plan Star-Rating pitch. — Deliverable: TDS BD outreach initiated + a Star-Rating one-pager showing the PDC-lift mechanism (R4/R5 §08 next-actions 1 + 5). Exit: at least one partner conversation logged; the non-pharmacy-vendor fee-routing legal question answered (§07 open item).
Pull the FDA CDS Software guidance + validate the gated clinical surface. — Deliverable: a claims/architecture check of the pharmacist-facing dashboard against the March 2026 CDS guidance. Exit: dashboard confirmed to sit on the right side of the wellness/CDS line before any B2B demo.

LATER (9+ mo / commercial) — expansion, evidence, revenue.

Multi-site expansion (Sites 2–5). — Deliverable: 2+ expansion sites live using the anchor-validated playbook (PP-106; per-site BAA + IRB amendment; $30K incentive; 4–6 wk lead each). Exit: ≥2 non-anchor sites running with demographic coverage the anchor can't provide.
Convert a B2B design partner to a paid contract. — Deliverable: first signed deal in one of the 6 categories (most likely MA-plan PMPM or MTM lead-gen via TDS). Exit: first B2B revenue recognized; the non-pharmacy-TIN fee question resolved in a real contract.
RTM/MTM billing live through a partner. — Deliverable: a supervising clinician/pharmacy billing 98975/98977/98980 (RTM) or 99605/99606 (MTM) off Rx360-generated data. Exit: first reimbursed claim traced to an Rx360 member. (Inferred: requires collaborative-practice authority + a partner clinic — several quarters out.)
Peer-reviewed publication + acquisition narrative. — Deliverable: USC-co-authored manuscript from the adherence arm + a valuation/comparables package (R6). Exit: submitted manuscript + a deck that closes the acquisition-optionality loop.

Dependencies¶

This workstream NEEDS from others: - Hardware (Emil/hardware team): ≥10 functional Mark I units to run the wearable take-home phase — the explicitly-flagged pacing risk. Mark II BOM/PPG feasibility is a Later dependency for the fall-detection/Balance-Meter surface, not the Mark I pilot. - The "brain" (Faraz/Sana team): medication entry + autocomplete (OpenFDA + RxNorm) must be functional enough for onboarding's med-list capture and the pharmacist verification step. Faraz owns the med-entry lane (DECISIONS 7/01). The full Med-Intelligence engine is DESIGNED-not-BUILT — the pilot only needs reliable med capture, not the whole KB. - App readiness (Faraz/Jack): participant-usable build for the app-only phase (was targeted for late April/May in PP-18 — status unverified). - Sign-offs: Matilda (fall-risk evidence/model) → gates Mark II & Balance Meter, not Mark I pilot. Kristen/Monika (IRB classification, PI credentialing, CITI) → gates every pilot phase. Counsel (BAA via PP-23; non-pharmacy fee-routing) → gates PHI phases + all revenue. - USC: co-lead on the separate adherence/PDC IRB arm (the entire evidence-generation half depends on this and it's the least-documented piece).

OTHERS need from this workstream: - Med-Intelligence build (Faraz): the pilot's pharmacist-verification workflow + med-list discrepancy data is real-world validation input for the brain's matching/guardrails. - Balance Meter / patent side: the cross-engine medication-change event contract is owned by the BalanceMeter/patent side; the pilot must consume the canonical definition, not re-define it (DECISIONS 6/15). - Peyman / acquisition thesis: the pilot results package + B2B revenue model are the core inputs to the acquisition narrative. GTM feeds the valuation story more than it feeds near-term cash. - Wellness-lane (Path A): every pilot/GTM artifact must clear the Wellness Lexicon + SeniorLife claim-pattern scrub before it leaves the building — this workstream is the biggest generator of claims-risk surface.

Human gates & risks¶

Non-engineering gates that will actually pace this (in rough bite order): 1. IRB classification (Kristen/Monika/Advarra) — unconfirmed and stale-flagged. Nothing runs until this is settled. Top gate. 2. BAA execution (counsel, via PP-23) — blocks all PHI phases; already flagged blocked. 3. Hardware feasibility (Emil) — ≥10 functional Mark I units for the wearable phase; the docs pre-authorize a slip to late-June/early-July if the count is short (already past). 4. Fall-risk sign-off (Gene's 3 ⚑ calls + Matilda) — unfreezes the canonical model; paces Mark II/Balance Meter (not Mark I pilot). 5. Counsel — non-pharmacy fee routing — gates whether Rx360 can bill/collect directly or must route through a pharmacy TIN; blocks real revenue. 6. Gene decisions — lock the four soft directions; confirm USC-arm ownership; approve every outbound (D-009 Drive drop has sat unapproved 14 days; nothing posts without chat approval).

Top risks: - R1 — IRB drift / the plan has quietly slipped. The whole operational schedule is April-dated with passed milestones and an unconfirmed IRB determination. The real risk is that the team is running (or not running) against a plan nobody has re-baselined. Mitigate: the NOW-1/NOW-2 re-date-and-confirm milestones before anything else. - R2 — Claims-line violation in a shared artifact. SeniorLife is the exact-analog enforcement precedent; a single "proactively identifies fall risk" or efficacy phrasing in a pilot results doc, deck, or B2B one-pager invites the same warning letter. The docs-site audit already caught product/market docs still selling "automatic fall detection." Mitigate: mandatory Lexicon + SeniorLife-pattern scrub on every outbound; keep the usability/efficacy wall (separate USC arm) crisp. - R3 — Revenue is a memo, not a pipeline. The B2B numbers are credible but entirely projected; there's no customer, partner, or reimbursed claim, and revenue is downstream of a completed pilot + real adherence signal. Mitigate: treat the Star-Rating one-pager + TDS outreach as a genuine NEXT deliverable, not a Later abstraction; resolve the fee-routing legal question early so the model is buildable.

Rough effort¶

NOW (0–3 mo): Light-to-moderate build effort, gate-dominated. The re-dating (NOW-1), decision locks (NOW-5), and evidence sign-off (NOW-4) are days of work each; the pace is set by other people's calendars — IRB determination and BAA execution are the long poles and are largely out of Gene's direct control (except the anchor-site BAA, which he can push since he owns the pharmacy).
NEXT (3–9 mo): Heaviest execution window — actually running the cohorts, standing up the USC arm (net-new protocol + IRB, likely the biggest undocumented lift), and producing the results package. First commercial conversations are low-effort/high-leverage and can run in parallel.
LATER (9+ mo): Long-cycle, partner-and-counsel-paced — multi-site expansion (4–6 wks/site), first paid B2B contract, first reimbursed claim, publication. Revenue realistically 12–24+ months out (inferred).

Single biggest unknown: the live IRB classification and the true launch status of the pilot. Everything downstream — pilot execution, the USC adherence arm, the results package, and every revenue conversation — is dated off an April plan whose milestones have passed and whose regulatory front-gate is explicitly unconfirmed in the current docs. Until Gene re-baselines "where is the pilot actually, today," the rest of this roadmap is built on an April snapshot. (Secondary unknown: whether the USC-led PDC arm has any IRB/protocol motion at all — it's the load-bearing evidence half and is absent from these docs.)

Key files: /Users/melts/Desktop/Rx360_Operations/03_Pilot_Deliverables/PP18_Testing_Schedule_v2.1.md · /Users/melts/Desktop/Rx360_Operations/03_Pilot_Deliverables/PP4_Site_Selection_v2.1.md · /Users/melts/Desktop/Rx360_Operations/Rx360_Shared_Drive/08_Protocol_and_IRB/Rx360_Protocol_Feedback_GeneLang_v4.1.md · /Users/melts/Desktop/Rx360_Operations/Rx360_Shared_Drive/02_Clinical_Data_and_Risk_Analysis/FDA_2026_Guidance_and_Enforcement_Research_2026-04-15.md · /Users/melts/Desktop/Rx360_Operations/Rx360_Shared_Drive/04_Revenue_and_Billing_Strategy/R4_R5_MTM_RTM_B2B_Economics_Research_2026-04-17.md · /Users/melts/Desktop/Rx360_Operations/.agent_state/DECISIONS.md · /Users/melts/Desktop/Rx360_Operations/_VP_Priorities/_HANDOFF_LOG.md