Reclassification analytics: count by classification grouping
- Dominant language
- Python
- Stars
- 30
- Forks
- 3
- Avg merge
- 9h 28m
- Merged PRs (30d)
- 42
Description
🤖 Written by Claude
Follow up to #1523. Every count on the reclassification analytics page is per classification, so a lab that curated the same allele for several patients is counted several times. `ClassificationGrouping` already collapses those, so the page could offer a "count by grouping" toggle alongside "count by classification".
### Plumbing
`ClassificationGroupingEntry` is a plain `classification` → `grouping` join with a unique constraint, so `ReclassificationEvent` can reach a grouping either by joining that table or by a denormalised `grouping_id` alongside the existing `lab` / `gene_symbol` columns. The counts on the page are already `Count('classification_id', distinct=True)`, so the toggle is largely a swap of that field.
Scale on a dev database: 1,434 classifications → 1,088 groupings, 123 of them multi-member, so roughly a quarter of the records collapse.
### Decisions to make first
- **`share_level` is part of the grouping key** (`allele_origin_grouping`, `lab`, `allele_origin_bucket`, `share_level`), so one lab's records on one allele at two share levels are two groupings - grouping mode sometimes splits rather than collapses.
- **Groupings are rebuilt as records change** (`dirty` flags, `_desired_grouping_for_classification`), so a denormalised `grouping_id` goes stale when a record's share level or allele resolution changes. Joining through the entry table each time is always correct, at a cost on every chart.
- **Withdrawn records leave their grouping entirely.** The survival curve censors on the withdrawal flag date; in grouping mode a withdrawal removes cohort membership instead, so the censoring needs its own handling.
- **Event level charts need a rule.** A grouping has one current call, but its members reclassify on their own dates and can move in opposite directions. Counting groupings that reclassified works (distinct grouping ids); the sankey, the from/to matrix, points travelled and evidence movement are per event and per modification.
### Suggested shape
Apply the toggle to the count based charts - records held, re-evaluation and reclassification rates, the lab league table, VUS burden by gene, and the survival cohort - and keep the transition and evidence charts per classification in both modes, saying so in the page help. Much smaller than making the whole page grouping aware.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start with the reclassification analytics page and trace how ReclassificationEvent joins ClassificationGroupingEntry and how the existing distinct classification counts feed each chart. Resolve the grouping, withdrawal, and event-level rules before implementation. Done means a count-by-grouping toggle covers the specified count charts, while transition and evidence charts remain per classification with that behavior documented in page help.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- analytics, backend
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100