Four asks from the 2026-09-03 sandbox critique §8C that have no issue, no roadmap line and no code. They came from the person who will judge whether the pilot is usable, and they are the only cluster from that document that is invisible in every tracked system. Filed together because they are one surface, not four features.
A repo-wide grep for scorecard returns the critique itself and two dated audit documents. Nothing else.
1. Provider and clinic scorecards, with targets
Per-PCP and per-site performance against a target, not just a filter that narrows the list. The panel model shipped (#555, ADR-080) and PCP is a first-class filter, so the data is there — what is missing is the view that ranks and compares, and the target to compare against.
Note the targets themselves are an ACO input we do not have: the PY2027 measure sheet "confirms the set and nothing else" (ROADMAP §7.7) — no targets, no benchmarks, no thresholds. So this has a real dependency, and that is worth stating rather than discovering during the build.
2. A monthly report she can paste into Word
Distinct from everything that exists. The six CSV exports are data extracts; #574's package is the ACO's attributed-list report for a measurement year. Neither is "the thing I send my administrator every month."
3. Last visit on the row
The work list shows the gap and not the encounter history. "When did we last see this person" changes whether you call them or wait. Next appointment is the other half and is already tracked as #564 (blocked on MIE's appointment data); last visit is not blocked on anything — it is history we may already hold — and is tracked nowhere.
4. Collection type, benchmarks, and a data-completeness view
Which reporting mechanism each measure uses, how the rate compares to a benchmark, and whether the data is complete enough to report — the critique names a 75% completeness threshold. Partly answered by the ACO on 2026-09-09 (mechanism is chosen per measure and both participants must agree — ROADMAP §7.5), which makes it a product requirement rather than an open question.
Why one issue
These are four cuts of one absent surface: reporting for the person who runs the practice's quality programme, as opposed to working an individual gap. Splitting them invites four half-answers. The first decision is whether this surface exists at all — and that is an owner call, not an engineering one.
Related: #564 (next appointment), #574 (the ACO report, a different artifact), ROADMAP §7.5, §7.7.
Four asks from the 2026-09-03 sandbox critique §8C that have no issue, no roadmap line and no code. They came from the person who will judge whether the pilot is usable, and they are the only cluster from that document that is invisible in every tracked system. Filed together because they are one surface, not four features.
A repo-wide grep for
scorecardreturns the critique itself and two dated audit documents. Nothing else.1. Provider and clinic scorecards, with targets
Per-PCP and per-site performance against a target, not just a filter that narrows the list. The panel model shipped (#555, ADR-080) and PCP is a first-class filter, so the data is there — what is missing is the view that ranks and compares, and the target to compare against.
Note the targets themselves are an ACO input we do not have: the PY2027 measure sheet "confirms the set and nothing else" (ROADMAP §7.7) — no targets, no benchmarks, no thresholds. So this has a real dependency, and that is worth stating rather than discovering during the build.
2. A monthly report she can paste into Word
Distinct from everything that exists. The six CSV exports are data extracts; #574's package is the ACO's attributed-list report for a measurement year. Neither is "the thing I send my administrator every month."
3. Last visit on the row
The work list shows the gap and not the encounter history. "When did we last see this person" changes whether you call them or wait. Next appointment is the other half and is already tracked as #564 (blocked on MIE's appointment data); last visit is not blocked on anything — it is history we may already hold — and is tracked nowhere.
4. Collection type, benchmarks, and a data-completeness view
Which reporting mechanism each measure uses, how the rate compares to a benchmark, and whether the data is complete enough to report — the critique names a 75% completeness threshold. Partly answered by the ACO on 2026-09-09 (mechanism is chosen per measure and both participants must agree — ROADMAP §7.5), which makes it a product requirement rather than an open question.
Why one issue
These are four cuts of one absent surface: reporting for the person who runs the practice's quality programme, as opposed to working an individual gap. Splitting them invites four half-answers. The first decision is whether this surface exists at all — and that is an owner call, not an engineering one.
Related: #564 (next appointment), #574 (the ACO report, a different artifact), ROADMAP §7.5, §7.7.