* docs: three feature proposals for owner review (encounter-close check, recency view, next-due estimate) Three product-shaped ideas from the 2026-08 feedback, written up as one-page proposals rather than built. Each maps onto verified existing machinery, names what would actually have to be built, and leaves its open questions open. Nothing here is approved or scheduled. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * docs: proposals JOURNAL entry + issue links Fills the tracking issue for each proposal (#458 P1, #459 P2, #460 P3) and records the day's entry, including the live-WebChart-demo follow-up (#461). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * docs: review fixes — subject-id namespace, citations, phrasing Nine fixes from the #462 review, each verified against the tree first: - P1: a WebChart patient id is NOT a WorkWell subject id — the live directory namespaces subjects as `wc|<patientId>` (live-directory.ts:91, run-pipeline.ts:433) and the compliance API looks up that exact string, so a bare id 404s. The original wording would have misled an integrator. - P1: a WebChart-side change is MIE's to make, not jointly ours. - P3: `next_action` is the Postgres column (schema-pg.ts:80); case-store.ts holds the TS field `nextAction`. - P3: cite measure-bindings.ts:46/:49 for the 365/820 values rather than the interface field at :33. - P3: `daysUntilDue` is an inline object-literal expression, not a function — which sharpens the consolidation point rather than softening it. - Header: name PR #457 so the referent survives any merge order. - JOURNAL: drop the appeal to an uncommitted design spec; state the reasoning. - JOURNAL: employee-profile.ts computes a day count, not a date. - CLAUDE.md: list the proposals doc under docs-on-demand, marked not-a-queue. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * docs: why_flagged is derived at read time, not persisted — correct P2/P3 data path Both proposals described `why_flagged.last_exam_date` and `compliance_window_days` as persisted per outcome. They are not: the engine persists `expressionResults` only, and `deriveWhyFlagged` (case-detail-read-model.ts:90, applied at :175) builds the block at read time — its own docblock says so at :4-6, and case-outreach.ts:164-167 documents the same from the other side, which is why `renderContext` builds a whole `CaseDetail` before it can compute a due date. Folded into P3's existing drift argument rather than appended to it. The two duplicated due-date expressions both sit on a third duplicated thing — `deriveWhyFlagged`, reached via `toCaseDetail` in one caller and called directly in the other (employee-profile.ts:18,:153), from a module named for the case detail page rather than for the derivation it owns. So consolidating that derivation is part of the work, not a nicety, and "computed at read time" is now a per-row cost to size rather than a free alternative. The misleading source is DATA_MODEL_CONTRACTS.md §5, tracked as #463 and left untouched here — it is an always-loaded contract extract and changing it changes what every session believes. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> --------- Co-authored-by: Taleef <taleef@gmail.com> Co-authored-by: Claude Fable 5 <noreply@anthropic.com>

Proposal: deterministic next-action date per patient/measure #460

Description

Activity

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions