Skip to content

Medication Intelligence — The "Brain" (Build Brief)

Orientation for a new AI architect: what we want to build for the medication-intelligence layer, distilled to buildable intent. Product/engineering framing — not legal/claim language. Go deep via the specs named in §3.

1 · What we're building

We're building the medication-intelligence layer — the "brain" — that sits under every Rx360 product engine. It identifies a member's medications (typed, scanned from a printed Rx summary, imported, or pharmacist-entered), enriches each one with drug-class / risk / interaction / forgiveness knowledge, and then powers the downstream engines: Smart Scheduling (forgiveness-aware reminders), the Fall Barometer's medication-risk input (FRID load), med-input intelligence, and a member-facing companion experience. All of it reasons over one curated, pharmacist-owned knowledge layer, and every member-facing output passes through a deterministic clinical safety rail before a single token reaches a member. The brain is probabilistic; the boundary is deterministic and pharmacist-gated. We stay in the wellness lane — the system informs and times, it never diagnoses or instructs dosing.

2 · The inventive concepts, as buildable bullets

These are the things that make our brain ours. Build each as a real capability — what it does and why it's distinct to us.

  • Provenance-tiered med identity (propose, don't override). Every med carries a source tier — self-entered → scanned/imported → pharmacist-verified — and that tier sets the confidence and precision of everything downstream. The engine pre-fills the most likely product/strength/route/frequency and asks the member to confirm; it never silently commits a low-confidence guess. Distinct to us: one provenance model shared across med-input, scheduling, and the Fall Barometer.
  • PK/PD "drug-forgiveness / tolerance-window" timing. Reminder behavior is governed by each drug's clinical tolerance window — derived from half-life (PK) and duration of effect (PD), not naive half-life — so a long-tolerance daily drug gets a gentle multi-day window and a narrow-window drug gets precise, escalating reminders. Distinct to us: drug-forgiveness is published science, but no one has built it as curated, per-class reminder behavior in a wellness app.
  • Cross-engine medication-change event. A single fall-risk-relevant med change (a FRID add/remove/dose change) emits one event consumed by both the scheduler (opens a heightened-attention period) and the Fall Barometer (opens a bounded sensitivity watch-window). Distinct to us: pairing a scheduling engine to a fall-risk engine through one shared event is the strongest single novelty in the portfolio.
  • Wrong-drug / duplicate-therapy detection at entry. As meds are added, the graph flags "you already have a drug in this class" and look-alike/sound-alike (LASA) risks. Distinct to us: a real-but-unseeded drug routes to manual entry — it is never silently swapped for the nearest seeded look-alike; fuzzy matches are confirm-required suggestions, never auto-accepts.
  • Confirmation-first scheduling with adaptive de-escalation. The engine optimizes for a confirmed dose and removes nags as a routine proves out — the inverse of everyone else's escalation ladder. Distinct to us: it answers the real field failure mode (alarm fatigue, not forgetting) instead of nagging harder.
  • Missed-dose policy + anti-double-dose guard. Per-drug missed-dose handling and a guard against double-dosing are encoded as curated KB facts the engine consults — surfaced as timing, never as dosing instruction.
  • Schedule-optimization from the med list. Given the whole confirmed list, the engine reasons about cadence, food/timing rules, and time-separation across meds to propose a coherent daily rhythm — built from the medication set, not a pile of independent alarms.
  • Care-circle / consent. Lapse notifications to an opt-in care circle, governed by member consent, so a caregiver-absence gap doesn't become a multi-week adherence gap.

Every clinical fact above is served from a curated, pharmacist-signed-off KB entry with a kb_entry_id behind the deterministic rail — never free-LLM output. Preliminary content is gated status: preliminary and cannot drive member-facing behavior until a pharmacist sign-off flips it to validated (a data change, not a code release).

3 · The architecture to build

Go deep in AI_Foundation_Architecture_Spec_for_Faraz_2026-06-04 (layer stack, build-vs-buy, interface contracts) and Drug_KG_Phased_Build_Plan_2026-06-29 (the staged graph build). The load-bearing decisions are distilled in AI_Foundation/KB/_KB_SYNTHESIS.

  • Knowledge layer. A curated KB (knowledge-as-data: versioned rows, author≠approver, effective-dated, clinical_line-flagged) plus a property-graph knowledge graph anchored to RxNorm/RXCUI · RxClass · SNOMED CT + ICD-10-CM · OpenFDA/DailyMed. Node/edge model + per-fact tagging schema in Curated_Drug_KB_and_Tagging_Schema_2026-06-04 and the phased-build plan. The lakehouse is the source of truth; the graph and vector index are projections synced via the event stream — never hand-maintained second copies.
  • Retrieval: structured-first → vector → GraphRAG, in a fixed trust order. Deterministic graph/table lookups serve identity, class, FRID, interaction, forgiveness first; vector is semantic fallback; GraphRAG handles multi-hop polypharmacy. Don't let the LLM "fill gaps" for clinical content.
  • The deterministic clinical rail — the blast door. Non-ML lexicon/pattern + an allow-listed output schema (reminder | confirmation | insight). Fail-closed: dosing/diagnosis/clinical-management claim, schema violation, low-confidence, or timeout → block + route to the pharmacist queue. Default state = "do not emit." Built before any model can emit to a member. Same posture as the existing Medication_Matching_Guardrails, enforced at the retrieval layer. Target: clinical-line leakage = 0.
  • Access contract. One MCP server is the single door (kb.lookup, kb.graph_query, kb.semantic_search, tolerance(rxcui|class)), each returning a provenance envelope {value, source, kb_entry_id, version, clinical_line_flag}. Shared medication object = FHIR MedicationRequest + Provenance. Engines plug in here; no bespoke per-engine DB access.
  • Scale tiers. Three tiers by time-criticality × data-sensitivity: on-device (offline scheduling, on-device Rx OCR) → BAA private-cloud (escalations) → cloud (training, RAG/KB, batch). Caching is a cost requirement, not an optimization.
  • Governance / learning loop. Event log + schema registry; a de-identification gateway splitting operational-PHI from the learning plane (Safe Harbor default); a non-skippable, event-logged pharmacist sign-off gate on any new clinical fact; eval-driven, with a path from wellness → SaMD that needs no re-architecture.

4 · Where Mike comes in

Open build decisions an AI architect should own and drive to a recommendation:

  • Graph DB choice. Neo4j AuraDB (mature Cypher, GraphRAG tooling, velocity) vs Amazon Neptune (AWS-native, fits a BAA/private-cloud posture). Current lean: Neo4j for velocity unless the AWS-BAA constraint dominates. (SNOMED/UMLS licensing is a Phase-0 blocker — flag the lead time early.)
  • Retrieval stack. Lock the hybrid retriever (BM25 + vector + RRF + rerank), the vector-store graduation path (pgvector → Qdrant/Milvus), the GraphRAG variant, and the agentic-loop bounds (max hops, latency). Define self-RAG/CRAG grounding so ungrounded clinical answers are refused.
  • The rail's enforcement. Own the deterministic clinical-line rail: the lexicon/pattern set, the allow-listed schema, the fail-closed paths (incl. timeout/error), buffer-before-gate (no streaming clinical-adjacent output), and pharmacist-queue routing. Load-bearing safety — not de-scoped to ship faster.
  • Eval / observability. Stand up a clinician gold set as the contract, the eval suite (retrieval metrics + groundedness/citation-coverage + rail escape-rate + clinical correctness), drift monitoring, a vaulted holdout, and decision-context logging (KB version + rail verdict per decision).
  • Consult on the Fall Barometer ↔ fall-detection seam. Advise on the medication-change event feeding the Barometer's bounded sensitivity window, and the boundary between graph-supplied inputs (FRID load, med-change events) and the Barometer's own scoring (the scoring stays in the Barometer; the graph supplies inputs). Constraint to internalize: Mark I is SOS/circle-alert only — no fall detection; fall detection is a later device generation. Keep the medication-risk input cleanly separable from any detection logic.