MM-2 PR 3: import the ACO's attributed patient list and report num/den/exclusions with patient-level evidence

[Taleef7]

The next MM-2 slice, and the thing the ACO actually asked for: take their attributed Medicare patient list, run the routed measures over that subset, and hand back numerator / denominator / exclusions per measure plus patient-level evidence carrying the result and the date. They keep that detail because CMS can audit it for ten years.

Approved shape (plan of 2026-09-11, ADR-081 to be written):

Immutable lists. subject_lists (id, name, source, note, revision, created_by, created_at) and subject_list_members (list_id FK CASCADE, raw_identifier, subject_id NULL, resolution 'MATCHED'|'NOT_FOUND'|'AMBIGUOUS', PK (list_id, raw_identifier)). A re-import creates a new list or revision and never mutates members, so a report stays reproducible. Owner-written DDL — this is blocked until that lands.

Import. POST /api/subject-lists, JSON or single-column CSV, trimmed exact match on externalId through the profile-scoped directory, cap 50,000. Audited with counts, never with raw identifiers. Unmatched rows are paged from GET /api/subject-lists/:id/members?resolution=NOT_FOUND rather than silently dropped — the ACO said plainly that a small share will not match.

Filter. listId on roster, cases, worklist, exports and MCP, intersecting with the existing filters through the one predicate.

The report package. GET /api/subject-lists/:id/report over the latest completed whole-population run per routed measure, plus ?format=csv patient-level rows from each outcome's evidence_json.official. Provenance in the header: list id and revision, member counts, run ids, measurement period, generated-at. Refuses (409) on a compacted or non-population run, and counts a member with no row in the run as missingFromRun rather than quietly shrinking the denominator.

Sandbox only. A real attributed list is PHI and waits for the PRODUCTION_READINESS gate; this is built and verified against a generated subset of the corpus.

Three inputs nobody has given us yet

Worth asking before building the importer, because each changes it:

1. Identifier format. Never specified. MRN, name plus date of birth, and Medicare Beneficiary Identifier are all different matchers with different failure modes.
2. Cadence. Never proposed by either side. SFTP is the established channel for the payer files they already receive.
3. What to do with non-matches. The expectation stated was only that a small percentage will not match. The precedent inside the practice is that externally supplied data lands in a review queue and is never auto-applied, which is the behaviour this should follow.

Also unsettled: whether Medicare Advantage is in or out of the attributed population. MSSP attribution is traditional Medicare, so it should exclude Advantage, but nobody said so and the two are separate codes in the payer typology (1 and 11).