Tag with first time seen

[MattWellie]

Fixes

• Closes #208

Proposed Changes

• Removes (completely) the 'subtract variant from analysis if previously seen' logic, replacing with 'assign first_seen date based on historic data'.
• Removes "YYYY-MM-DD_HH:MM:SS" format in favour of "YYYY-MM-DD" for the first_seen to display better in the report.
• Includes the first seen value in the report table (can filter/sort, but no date-range widget)

Notes:

First_seen is probably the wrong name for this field. The value in here is the most recent date that one of the present categories was first seen. Worked example because otherwise I'll forget the reasoning:

• Fam A has Variant X (Cat. 1)

• A report is generated on Day D, so the 'cumulative data' file is extended to say that in Fam A Var X had a Cat. 1 variant on Day D

  {
  FamA:
  VarX:
      Cat1: D
  }

• Later on Day N the same cohort is re-run, and now the same variant is Cat. 2, so the 'first seen' attribute is set to Day N and the historic data is extended:

  {
  FamA:
  VarX:
      Cat1: D,
      Cat2: N
  }

• On another later date, Z, the same cohort is re-run, and the variant now has only Cat 1 (the same disease-gene association won't be 'new' now) - what do we put as the first seen date? D because it's the first time it was new? N because it's the latest time the variant had a new classification on the report?

I've gone with N here, because it's the last time chronologically that something new was found in this variant - even though the Category at that time is not currently assigned.

The main reason for this choice is that it stops the annotated date flip-flopping in time - the first_seen attribute is supposed to be the last time new information was produced for this variant, and that marker should only move forward in time, not move backwards as it would in this example (on the 3 hypothetical reports it would be D -> N -> D, reflecting only the categories present for those reports).

I've spent too much time thinking about the 'correct' action here, and I just don't think it's that important.

Checklist

• [x] Related Issue created
• [x] Tests covering new change
• [x] Linting checks pass

[MattWellie]

Is there value in storing (not displaying) the per category date added in our history file?

with the current logic here the first date of each individual category being applied is recorded… but with the way the date is presented that’s kind of irrelevant. It could easily be replaced with a single date per variant of ‘latest new thing’, which would move forward if a new category is assigned. That would remove a few loops from the logic for no loss of info in the report.

Recording all category-dates in the historic data could potentially be interesting over longer timeframes, for retrospective checks, e.g. pinpointing the month a clinvar rating became pathogenic. I don’t know that we’re really going to be doing those checks on a regular basis…

I might be misreading your comment though, and barking up the wrong tree

[MattWellie]

Tabling the comment for a F2F discussion