Pilume: the model proposes, the system verifies, the pharmacist decides

The model reads the patient's clinical picture and proposes the day: each dose at an hour, the sentence the patient will read, and the observations a pharmacist would want to see. A tested verifier checks that proposal without ever repairing it, and a licensed pharmacist validates before any 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.
The model proposes. A de-identified clinical picture goes to a small, fast model, which returns the day: each dose at an hour, as a structured output.
Patient sentence and observations. The model also writes the short reason the patient reads as written, and separate observations meant for the pharmacist.
Verified, never repaired. A pure, unit-tested function checks the proposal against the constraints and turns every deviation into a finding shown beside the plan. Nothing is silently corrected, or the pharmacist would validate something nobody proposed.
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.

The verifier's findings and the observations for the pharmacist: those are professional working notes, stripped from every patient channel. A patient reading "possible therapeutic duplication" is reading a conversation about them.

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

Decisions and why

Why the model proposes rather than a rule-based scheduler. The first version computed the times with a deterministic solver. It knew separations and frequencies and nothing about the person: not that an evening diuretic is a fall risk for someone with reduced mobility, not that two drugs do the same job. It arranged hours; a pharmacist wanted a colleague's second look.

Why verify rather than repair. A pure, unit-tested verifier says what is wrong and leaves the proposal intact. Silently correcting it would have the pharmacist validate a plan nobody proposed and nothing recorded, and would rebuild the solver it replaced.

Why no fallback. If the model is unavailable, generation fails and says so. Substituting a rule-based plan would hand the pharmacist a different thing under the same name, with no way to tell.

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 task is bounded and the output is a strict schema, so a small, fast model is enough; it is the verifier and the pharmacist that carry the safety.

Numbers

5 applications: API, pharmacist portal, patient web, patient mobile, pharmacist desktop.

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

In pilot with a Quebec community pharmacy.

Built in 10 weeks 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 · schema validation at every API boundary