Model version change
The day a model is updated, every result it has already issued becomes a historical artefact — and every decision made from those results has to stay reconstructable. This is a lifecycle problem, and it is the one part of algorithmic provenance that no amount of labelling at display time can solve.
Overview
Confidence disclosure already requires the model version and training recency to travel with a finding. That is a display rule and it is not what this page is about. This page is about the update event: the moment a new version goes live and nine thousand issued results, several hundred open surveillance loops and an unknown number of past decisions are all suddenly attributable to software that is no longer running.
The question that makes it concrete: a clinician discharged a patient from surveillance eighteen months ago on the strength of a v4.2 output. Version 4.3 would have flagged it. What does the interface owe that patient, that clinician, and the next person to open the record?
A past result is never rewritten by a new model version. If a backlog is re-analysed, the output arrives as a new, dated finding with the reason for re-analysis attached, and the original remains visible with the version that produced it. Silently re-scoring history destroys the only record of why a decision looked reasonable when it was made — and it makes the clinician who made it appear to have ignored evidence that did not exist.
Answers are dated
Every output belongs to a version and a moment. Neither is inferable later unless it was recorded at the time.
Never re-score in place
Re-analysis creates a new finding beside the old one. Nothing overwrites, nothing disappears.
The record shows what was seen
Anyone reconstructing a decision must be able to see exactly what the decision-maker saw, not what the current software would say.
Anatomy
-
14 Aug 2026 · 04:12Re-analysed under v4.3 — nodule margin now classified as spiculated (was smooth). New finding; the 2023 result is unchanged.Automated backlog re-analysis · reason: v4.3 margin model revised · reviewed by no one yet
-
18 Jan 2024 · 10:31Discharged from surveillanceDr S. Iyer · on the basis of the v4.2 result below
-
12 Jul 2023 · 16:20Nodule 6.0 mm, margin smooth — low suspicionAcuteLine-family analysis v4.2 · training data to Mar 2022
Read bottom-up, the record explains the 2024 discharge as reasonable on what was known. Read top-down, it shows a new finding that now needs an owner. Both readings have to remain available.
| Part | Rule |
|---|---|
| Version on every output | Recorded at production time, never derived later from "whatever is deployed now". |
| Original preserved | Immutable. A re-analysis never edits it, never supersedes it in place, and never hides it behind a "show history" control. |
| Re-analysis marked | Visibly distinct from a fresh reading of new data. It is an old study seen again. |
| Reason for re-analysis | Required. "v4.3 margin model revised" tells a reviewer what to weigh; "re-analysed" tells them nothing. |
| Disposition | A new finding produced by re-analysis is unreviewed until someone reviews it. It does not silently join the record as agreed. |
| Decision linkage | Where a past decision cited a superseded output, the decision names the version it relied on — see Clinician override. |
Under MDR Annex VI Part C, a modification that changes performance, safety, intended use or the interpretation of data normally requires a new UDI-DI — a new algorithm usually qualifies. So the question on this page, "what happens to results issued by the previous version", often sits alongside a second one: whether users are still operating the device they were assessed against. See Regulatory labelling & UDI. The two version numbers are separate fields and neither substitutes for the other.
What happens to the backlog
Whether to re-analyse at all is a clinical and regulatory decision, not a deployment convenience. The interface's job is to make each option's consequences visible, and to refuse the one that quietly rewrites history.
| Option | Consequence the interface must show |
|---|---|
| Do not re-analyse | Legitimate and common. Existing results stand under their original version, and the record says so. The open question — whether anything would have been found — remains open and should be stated rather than left implicit. |
| Re-analyse open loops only | Usually the proportionate choice: the population where an action is still possible. The scope of what was re-analysed is stated, so nobody assumes it covered everything. |
| Re-analyse everything | Produces a wave of new unreviewed findings, including on discharged and deceased patients. The count is shown before the run, with an owner assigned for the output. |
| Re-score in place | Not offered. There is no interface for this. It destroys the record of what was known when. |
Re-analysing forty thousand studies produces some number of new findings, each of which needs an owner, a due date and a route to closure — see Pending work & closing the loop. Running the analysis is the easy half. A backlog run with no plan for its output creates a list of unreviewed algorithmic findings about real patients that nobody has been made responsible for, which is worse than not having run it.
Telling people it changed
A version change alters what the software's outputs mean. The people relying on those outputs are entitled to know, and in most products they find out from a release note they never read.
Advisory priority, in clinical terms, naming the scope of re-analysis and where the output will land. Not a version number in a footer.
- In terms of what changed clinically, not what changed technically. "The margin classification model was revised" is usable; "updated dependencies and retrained on an expanded dataset" is not.
- State the scope of re-analysis explicitly — and if nothing was re-analysed, say that too. Silence is read as "everything is current".
- Name a clinical approver. A model change is a change to a risk control; the same reasoning as Safety configuration.
- Persist it. The announcement remains findable, because the question "what version was running in March" is asked long after any banner is dismissed.
- Never mid-encounter. A version must not change under a clinician who is part-way through reading a study.
States
| State | Rendering |
|---|---|
| Current version output | Version shown with the finding, as Confidence disclosure requires. |
| Superseded version output | Still shown, still legible, marked with its version. Never greyed into illegibility — it is the evidence a past decision rested on. |
| Re-analysed, agrees | Recorded, low prominence. Agreement between versions is reassuring and is not news. |
| Re-analysed, differs | A new finding, unreviewed, with an owner and a due date. This is the whole reason to re-analyse. |
| Not re-analysed | Stated on the finding — "produced by v4.2, not re-analysed under v4.3" — so nobody assumes currency. |
| Version unknown | Said plainly. A result whose provenance was not captured is a limitation of the record and must not be presented as current. |
Do's and don'ts
2023 · v4.2: margin smooth, low
suspicion
2026 · v4.3: margin spiculated —
new finding, unreviewed
Both results, both versions, both dates. The 2024 discharge decision still reads as reasonable, and the new finding still gets acted on.
2023: margin spiculated — high suspicion
History re-scored in place. The record now shows a clinician discharging a patient despite a high-suspicion finding that did not exist at the time.
312 open findings re-analysed under v4.3 · 9 differ · each assigned an owner and a 14-day due date
The run has a plan for its output. Nine new findings became nine pieces of owned work, not nine rows nobody is responsible for.
Backlog re-analysis complete · 40,112 studies processed
A throughput statistic. Nobody knows what it found, whether anything differed, or who is looking at it.
Produced by v4.2 · not re-analysed under v4.3
States that this finding is not current under the running version. Absence of re-analysis is information.
Margin smooth — low suspicion
No version, no date. Reads as the current software's opinion, and it is three years and one model revision old.
Analysis updated to v4.3. The margin classification model was revised. Results before 14 Aug were produced by v4.2 and have not been changed.
Clinical language, explicit scope, and a clear statement about what did not change.
v4.3.0 — retrained on expanded dataset; dependency updates; perf improvements
A release note. It does not say what changed clinically, what happened to existing findings, or whether anything needs looking at.
Accessibility
- Version and date are text next to the finding, never only a hover or an info icon — the same rule as Confidence disclosure.
- Superseded outputs stay legible. Dimming history to indicate age routinely pushes it below 4.5:1; age is conveyed by the date, which is text.
- Re-analysed findings announce that status in their accessible name, so a screen-reader user does not have to infer it from position in a timeline.
- Chronology is a real list with its order stated — see List & tree.
- The version announcement is advisory and dismissible, announced politely. It is important and it is not an alarm.
- Never colour alone to distinguish current from superseded outputs.
- Targets ≥ 24 px, readable at 320 px (SC 2.5.8, SC 1.4.10).
Outcomes of use
What this contributes to, in the terms of Usability & context of use. These are attributes believed to contribute to an outcome; the outcome itself is settled by observing real use in a specified context, not by this page.
- Effectiveness — a past decision can be reconstructed from what was actually available at the time, and a genuinely new finding still reaches somebody. The two pull in opposite directions and both have to hold.
- Efficiency — re-analysis output arrives as owned, dated work rather than as a list somebody must triage from scratch.
- Satisfaction — this is largely a satisfaction and trust pattern for clinicians. A record that can make you look negligent for a decision that was correct on the evidence is a record people defend themselves against, and defensive documentation is worse documentation.
Clinical safety notes
Trace these in your risk file (ISO 14971) and usability engineering file (IEC 62366-1).
- Results are never re-scored in place. Mitigates: destruction of the record of what was known when a decision was made.
- Version captured at production time. Mitigates: provenance inferred later from whatever happens to be deployed.
- Re-analysis creates a new, dated, unreviewed finding. Mitigates: an algorithmic output joining the record as though a human had accepted it.
- Reason for re-analysis required. Mitigates: a reviewer unable to weigh why two versions disagree.
- Re-analysis output is assigned owners and due dates. Mitigates: a wave of new findings about real patients that nobody is responsible for.
- Scope of re-analysis stated, including when it is none. Mitigates: an un-re-analysed finding assumed to be current.
- Superseded outputs remain visible and legible. Mitigates: a past decision appearing unjustifiable against evidence that did not then exist.
- Version change announced in clinical terms with an approver. Mitigates: a change in what outputs mean reaching users only through a release note.
- No version change mid-encounter. Mitigates: a study whose analysis changes while it is being read.
- Unknown provenance stated. Mitigates: an unattributable result presented as a current one.
Related
- Confidence disclosure — displaying version and training recency with a finding; this page covers the update event instead.
- Pending work & closing the loop — where re-analysis output has to land to become real work.
- Trend & change over time — what a version change does to a series of points.
- Safety configuration — the same approval and announcement discipline for a different kind of change.
- Clinician override — the surveillance loop a version change is often a response to.
- CarryForward — the reference application.