A case does not stop when the report is signed
The reason many cases stay open is that what was known on the day of the analysis was not enough. Knowledge moves. A gene gets a disease link that it did not have last spring. A variant is reclassified. An ontology term is merged into another. A case that was a dead end in March can have an answer in October, and nobody has to have done anything wrong in between.
Teams know this, and they handle it with a calendar: a reminder to go back to unsolved cases every year or so. Going back to everything is expensive, and most of it turns up nothing. What a team wants is to be told which cases a change could actually touch.
Versions on every result
That is only possible if you know what each result was based on. Every analysis in the product records the case version, the model version and the knowledge version it used. A result is a statement about a case at a point in the knowledge, and it says which point.
It also means a result can be repeated. If someone asks months later why the system said what it said, the answer is not “whatever the model thought that week”. The versions are on the record.
What a release touches
When a new release of the knowledge arrives, the product compares it with the one before. The comparison is about what changed: which genes, variants and diseases were added, changed or removed. It then looks for the open cases that involve any of those.
A change to a gene that is nowhere in a case is not a reason to reopen it. A change to a disease that a case’s leading hypothesis depends on is. Only the second kind of case is selected, and the team is not asked to look at a case because a number somewhere went up. Where the product cannot tell whether a case is touched, because it has no record of what that case depended on, the case is re-checked rather than skipped.
Proposed, then confirmed
A flagged case does not change quietly. People can see what changed and why, in the case, next to what they had before. The proposed update is a proposal. It becomes part of the case when a person accepts it, through the same paths any other change goes through.
We are careful not to describe this as fully automatic or as real time. A comparison is run against the open cases when a release arrives, and a person decides what to do with the result. The point is to make the second look cheap enough to do when it matters, not to remove the person from it.
What this is for
The aim is a modest one. A family waiting for an answer should not have to wait for the next yearly review of unsolved cases to find out that something relevant was published in the meantime. A team should not have to re-read two hundred cases to find the two that deserve it. Doing the comparison with versions and with a clear record of what changed is the part a computer is good at, and the judgement that follows stays with the team.
A worked example
A case was left open last spring. Its leading hypothesis was a gene with a thin link to the patient’s condition, held at a low tier because the evidence was limited. Over the summer a curated source adds new reported cases and upgrades the strength of that link.
When the release containing the upgrade arrives, the product compares it with the previous one, sees that the link changed, and finds that this case depends on it. The case is then flagged, with a plain account of what changed in the knowledge and which parts of the case are affected. A person opens it, reads the change and decides whether the hypothesis now deserves a different place, or a test.
Two hundred other cases that never touched that gene are left alone. Nobody has to remember to go back, and nobody is asked to look at a case for no reason.
What can go wrong, and how we think about it
A comparison can be too narrow and miss a case that was affected indirectly, or too wide and flag cases that did not need it. We lean toward showing a change a person can dismiss over missing one. A dismissed flag costs a minute. A missed one costs a family a year.
Knowledge sources also get things wrong and correct them. A change that removes a link is as important to see as one that adds it. The comparison works in both directions for the same reason.