Cross-system credit at the CALCULATION level — 'if they are compliant anywhere, they are compliant everywhere'

[Taleef7]

The gap

Doug's 2026-06-24 ask, verbatim from the meeting notes: "You can do calculations and attribute patient even if they came from two different EHR systems… If they are compliant anywhere, are they compliant everywhere? When doing quality calculations, give everybody credit regardless of who did it." (The cardiologist-gives-the-flu-shot example.)

Today this is display-only. E15 (#187, ADR-022) resolves a person across systems and shows a merged, system-tagged compliance timeline — but by design it never re-aggregates: quality snapshots, the hierarchy rollup, and the roster all count each tenant's record independently. A person vaccinated in system A still reads non-compliant in system B's numbers. Surfaced during the 2026-07-13 gap analysis (docs/INTEGRATION_RESEARCH_2026-07-13.md §5).

Proposed shape (design, not committed)

An additive, descriptive person-resolved quality view alongside the per-tenant one — never a mutation of stored outcomes:

• A read model that, for each resolved Person (E15 resolvePeople), takes the best outcome across their linked records per measure ("credit anywhere") — the union of each record's evidence, CQL buckets untouched.
• Surfaced as an opt-in scope (e.g. ?resolution=person on quality/history + roster, or a person-level panel on /people/[personId]), clearly labeled, with the per-tenant view remaining the default.
• Invariants preserved: ADR-008 (CQL is the sole Outcome Status authority — this view selects among CQL-decided outcomes, never re-derives), ADR-019 (All = Σ tenants holds in the default view; the person-resolved view is a separate lens, not a re-count), ADR-022 (match-don't-auto-merge — credit only flows across human-confirmed or match-key-grouped records).

Open design questions

1. Does "credit anywhere" apply only to PERMANENT (series-completion) measures, or also RECURRING ones (a recent audiogram in system A satisfying system B's window)? Doug's example (flu shot) is RECURRING — suggests both.
2. Which surfaces get the person-resolved lens first — quality snapshots, roster, or the /people view?
3. Interaction with the E16 snapshot store: a person-resolved snapshot scope level, or read-time only?

Depends on: E15 (shipped), and gains real data via E12 PR-2c + #187 PR-3 (WebChart identity sources). Buildable against the synthetic directory now.

🤖 Filed by Claude Code on Taleef's behalf (2026-07-13 gap analysis)

[Taleef7]

Design doc is up — PR #290

docs/superpowers/specs/2026-07-13-e287-cross-system-credit-design.md. It answers all three open questions in this issue and surfaces two things the issue text didn't separate:

1. Two different lenses hide behind one sentence.

• (A) record-scoped, credit-shared — denominators unchanged, a record is COMPLIANT if any linked record is. Answers "what is system B's quality rate, giving credit for care delivered in system A?"
• (B) person-scoped, deduplicated — each human counted once.

Doug asked for (A) ("give everybody credit regardless of who did it" — it's about not penalizing a system for care delivered elsewhere), and only (A) preserves All = Σ tenants (each record still belongs to exactly one tenant; only the numerator moves). (B) breaks that invariant by construction and needs its own root, not a re-count. Recommend: build A; ship B later, separately labeled.

2. Credit may only combine outcomes sharing (measure, evaluation_period).
A bucket is a function of the evaluation date, not a durable fact. An audiogram that was COMPLIANT in last year's period would, if credited forward, mark an overdue employee compliant. Period-matching is what makes RECURRING credit safe — which matters, because Doug's own example (a flu shot) is a recurring measure. So the answer to open question 1 is both, not PERMANENT-only.

Also settled: precedence is COMPLIANT > EXCLUDED > DUE_SOON > OVERDUE > MISSING_DATA (selects among CQL-decided outcomes, never re-derives one — ADR-008 by construction); surfaces in order roster → programs/quality → /people (Q2); read-time only, no quality_snapshots scope for now (Q3); opt-in ?resolution=person so today's numbers never silently change.

The safety property that matters most: credit is only as trustworthy as the identity match beneath it. Today a bad match mis-groups a timeline (embarrassing); with credit it mis-states compliance (dangerous). So credit flows only across E15's match-key groups and human-confirmed links, never a BROKEN one (ADR-022 preserved).

And the real payoff is a write path: not chasing someone who already got the shot — i.e. closing the other system's open case. That is scoped as an audited, opt-in Phase 2 with its own sign-off (it closes real work items). Phase 1 is read-only.