Pilume: an AI that explains a medication schedule but never decides it

A pharmacist builds an individualized medication schedule with AI support, validates it, and the patient follows it on the web and on mobile with reminders and interaction checks. The AI is decision support only; a licensed pharmacist validates every schedule before a patient can see it.

Flow

Patient and medications. The pharmacist records the patient, the prescriptions (drug, dosage, frequency, form, route) and the day shape: wake time, meals, sleep.
Deterministic scheduling. A unit-tested scheduler assigns intake times from the timing and interaction constraints in the curated drug-interaction knowledge base (drug-drug, drug-food, minimum separation).
Clinical rationale. Claude Haiku receives a de-identified clinical picture (age band, sex, conditions, allergies, medications, known interactions as facts) and writes the plain-language rationale for each medication. It never sets a time.
Verification. Every proposed slot is checked again against the constraints before it reaches the pharmacist; an unsatisfiable set is surfaced, not silently resolved.
Validation gate. The schedule stays in draft until a pharmacist explicitly validates it. Publication requires the validated status; the check lives in the API service and route layer, not in the interface.
Patient channels. Web (WCAG 2.1 AA, large text, high contrast) and mobile (Expo, offline schedule, on-device reminders). Over-the-counter interaction queries and side-effect information, always framed as pharmacist-validated decision support.
Alerts and audit. Missed-intake and resumption reminders, pharmacist follow-up alerts, and an append-only audit entry for every access or mutation of patient data.

Human gates

The pharmacist validation gate is enforced server-side and covered by a non-negotiable integration test. No validated status, no patient visibility.

Pharmacists sign in with MFA (TOTP); patients with e-mail and password, plus optional biometrics on mobile; healthcare session timeouts apply to both.

What never reaches the LLM

Names, identifiers, dates of birth, drug identification numbers. The model sees an age band and a clinical picture; two patients with the same picture produce byte-identical requests.

Timing decisions. The scheduler decides; the model explains.

Anything without an audit entry: every read and write of patient data is logged in an immutable, append-only table.

Decisions and why

Why a hybrid engine. Testability and clinical accountability. A rule-based scheduler can be proven; a language model can only be reviewed. So the model gets the part that benefits from language and none of the part that needs proof.

Why de-identification at the source. Law 25 and PIPEDA. Sending a clinical situation rather than a person is what makes the pilot defensible, and it costs nothing in quality.

Why the gate lives in the API. A hidden button protects nothing. The service that publishes a schedule refuses to publish an unvalidated one, whatever the client.

Why a small model. The rationale is short and bounded; Haiku is fast and inexpensive, and the deterministic layer carries the risk.

Numbers

5 applications: API, pharmacist portal, patient web, patient mobile, pharmacist desktop; 2 shared packages.

66 test files across the workspace; 15 architecture decision records.

Pilot targets: 99% availability during pilot hours, single-pharmacy pilot with tens of users.

Built in 10 weeks (142 commits) through the AI Product Factory.

Stack

TypeScript monorepo (pnpm, Turborepo) · NestJS · Prisma on PostgreSQL · Next.js with next-intl (French default) · Expo / React Native · Electron with encrypted local store · Anthropic SDK (Claude Haiku) · Zod at every API boundary