kert e9c3a5251f fix(pfs): CPT family edges never bridge two headed families; since/until from all ingested editions (refs #687) ...

Ruling C11: a use-with/parent edge, and the slice-1 addon-of relation
element, now union two codes only when at least one endpoint has no
qualifying CPT heading (cpt_groups) — when both already resolve to
different headings, the edge crosses families by design and is
skipped. Live-corpus review found 12 keys blending >= 2 headings this
way (PLA 600 = PLA 378 + Tier 1 Molecular Pathology 212 + Tier 2 10,
via 0133U's use-with; a Category III blob mixing a pacemaker heading
and a device-evaluation heading via 33224 -> 0695T; among others). The
guard lives in a new _cpt_edges() helper so it's testable in isolation
from the rest of derive_families' union-find wiring.

Ruling C12: derive_families gains cpt_presence (code -> sorted edition
years present, across every ingested edition, not just the newest);
when given, since/until come from it instead of being clamped to
whichever single edition cpt_codes carries. The CLI builds it from one
extra SELECT code, edition_year FROM pfs.cpt_code pass. Grouping/naming
stay newest-edition-scoped (cpt_codes unchanged).

Verified on the replica: no non-hand key has >= 2 distinct `note`
values; 99490 now reads since 2019 (its earliest ingested edition)
instead of 2024.

2026-09-09 19:53:34 -04:00

42 KiB

Raw Blame History

View Raw