Separate out Gene / Disease curation

Relevant for SA Path somatic lab - who want to reuse work for reports.

At the moment we have "copy consensus" to re-use previous work. This works per allele.

A classification contains information about gene / disease, but as this information is attached to a classification (allele based) it is not easily reused for a different variant in the same gene/disease context.

Some options are:

**Separate gene/variant literature Ekeys**

Bare minimum... Not sure how to migrate existing data? Also doesn't explicitly separate gene vs gene/disease

**Schema change**

If we separated out gene/disease into its own first class object, separate from classification we could re-use it more easily, as well as having a central periodic reviews etc. Would be obvious what the latest copy was, and what to use.

**copy consensus**

This could work with or without schema change. Schema change is obvious what to do but we could possibly re-use previous classifications by having "copy consensus" also be aware of gene/disease combinations and search for classifications with them, and present either the latest/consensus/choice of what to copy in

To do at "copy consensus" time - you'd have to enter the disease first at the "create classification from variant" page (where you enter lab/sample etc)

If you wanted to keep disease entry on the classification page, you could perhaps have some kind of method to bring it in then?

It may be worth bringing disease choice up front as a big choice. There are a number of issues about that, eg auto-completes and bringing it in from say tissue, panel., patient phenotypes etc.

I can also imagine you may want to use ontology hierarchy - for instance someone has associated a gene with a term +/- 1 in the hierarchy you may want to know about it

---

## Decision (2026-08-11)

Designed in [`claude/plans/somatic_curation_reuse_issue_1419_plan.md`](https://github.com/SACGF/variantgrid/blob/master/claude/plans/somatic_curation_reuse_issue_1419_plan.md),
which supersedes the options above and is Phase 8 of the TSO 500 plan (SACGF/variantgrid_sapath#431).

**Copy consensus, at gene scope — not the schema change, not yet.** `EvidenceKey.copy_consensus`
becomes `copy_scope` (NONE / ALLELE / GENE). The gene-scope set is the `H` (Gene) category less
`condition`, plus `pubmed_gene_search_count`. `literature` stays at allele scope until it is split into
gene-level and variant-level content (variantgrid_private#1102); `search_terms` stays at allele scope
because it contains variant terms.

**The human picks the gene-level source record; nothing is auto-selected.** AMP tiering and therapy
content are gene *and* tumour type, so copying gene-level content across tumour types is a clinical
error rather than staleness — and the phenotype data available to match on is not good enough to
automate the judgement. The candidates are shown with their condition, clinical significance / tier, lab
and date, defaulting to "none".

This also settles the "enter the disease first" question above: **no**. Condition is a decision on the
per-variant screen, pre-filled from whichever record was picked and always editable, rather than a gate
in front of the flow.

**A first-class gene/disease object stays the eventual answer**, and is the only thing that can express
"reviewed on this date, due for review". It needs the disease axis settled first — condition matching,
ontology hierarchy, whether such a record is per-lab — which is a much larger piece of work. The copy
route does not foreclose it: `copy_scope = GENE` is exactly the key set the object would own.

**Prerequisite — an audit of `copy_consensus`.** 142 of 330 keys carry it, set for germline ACMG work
and never reviewed against somatic. It is currently copying one patient's tumour measurements
(`somatic:tmb_*`, `somatic:msi_*`, `somatic:hrd_status`) and report narrative
(`somatic:summary_interpretation`) onto another patient's record, and it writes keys across the
germline/somatic boundary that the target form will never show. Details and fixes in the plan.