Proposal: encounter-close quality check

[Taleef7]

One-page proposal in docs/PROPOSALS_2026-08.md (P1). Not scheduled; awaiting owner/MIE review of integration surface, latency budget, and measure set.

Note: the compliance API's mode=preview deliberately returns 501 on a WebChart-configured stack, so a point-of-care check needs a new live-composition path, not a flag flip.

[Taleef7]

Partially delivered by #469 (merged 2026-08-17, ADR-067) — recording which of this proposal's open questions are now answered, and which one is not.

Answered.

• Integration surface. A published standard rather than a bespoke endpoint or an embedded panel: WorkWell serves a CDS Hooks 2.0.1 service (GET /cds-services, POST /cds-services/{id}). Cards are structured for the client to render in its own UI, so the presentation stays MIE's. Contract: docs/CDS_HOOKS.md.
• Measure set. All applicable measures with an open gap, not only the officially-routed ones — with the honesty field carried per card (the detail names the run and states the answer was computed by CQL).
• Who acts on the answer. A card suggestion carrying a draft ServiceRequest (intent=proposal, status=draft) that the clinician accepts or ignores — write-back without WorkWell holding write credentials into a certified EHR. Gated to order codes with an APPROVED terminology mapping, which today excludes cms122/cms125.
• Latency budget. Sidestepped rather than solved: cards read the most recent finalized run, so no live composition happens on the request path. The cost is freshness, stated in the contract.

Not answered — and it is item 3 of "What would have to be built", unchanged. Evaluating data supplied on the request. CDS Hooks has the slot for it (prefetch), and WorkWell deliberately declares none, because it evaluates none — advertising a prefetch template we ignore would make a client fetch and transmit for nothing. So a card still reflects the last run, not what was typed five minutes ago. That remains a new capability with its own failure modes, exactly as this proposal said.

Item 1 also stands: nothing in WebChart fires the hook, and there is no public evidence either way that WebChart acts as a CDS Hooks client. That is now a precise question rather than an open one — if it does, the two things needed are its iss and its JWKS URL, since our bearer token is not the spec's signed-JWT profile.

Also relevant: guide S7 is rewritten against the built contract, and #470 tracks the outcome-scan latency on this path.