Monitoring, drift, and change

Deployment is not the end of validation. A model is assessed against a snapshot of data, practice, and surrounding software, while the service continues to encounter a moving world. Scanners are upgraded, protocols are revised, populations change, and clinical definitions or reference practices can change. The model may produce the same score for the same numerical input while the meaning of that score in the workflow has changed. Monitoring is how the lifecycle makes that possibility visible.

The world the model was trained on does not hold still

Several forms of change can be distinguished. Data drift is a change in the input distribution. Protocol or scanner drift can arise when acquisition or reconstruction changes the image evidence presented to the model. Population drift can alter the case mix, prevalence, or comorbidity pattern. Label or practice drift occurs when reporting criteria, reference procedures, or clinical definitions change. These sources can overlap. A downstream change in discrimination, calibration, sensitivity, specificity, or workload is performance drift, but performance drift is an effect to investigate rather than a complete explanation of its cause.

The distinctions matter operationally. An input-distribution warning may appear before enough cases have an adjudicated reference to estimate performance. A stable AUROC can coexist with a changed threshold consequence or alert workload. Conversely, an apparent performance change can arise from a change in reference construction rather than from the model’s representation of the image. A monitoring plan should therefore connect signals to plausible failure mechanisms instead of waiting for one headline metric.

What monitoring must do

Monitoring begins with the data contract: which inputs are expected, which studies are accepted, what preprocessing and routing occurred, and what missing or malformed inputs mean. It can track changes in scanner, protocol, population, and score distributions, as well as service availability, latency, queue load, alert volume, and the rate at which readers accept, edit, or override outputs when those measures are part of the intended use. These signals do not all prove a clinical performance change, but they can identify where an investigation should start.

Where an appropriate reference becomes available, sampled or audited outcomes can be used to assess performance and calibration over time. The sampling process and delay to reference must be documented; a label arriving later is not the same as an immediate monitoring signal. Alerts should have a defined owner and response path, with a rule for distinguishing an investigation trigger from an automatic decision to withdraw the system. Thresholds for monitoring are themselves part of governance and need context rather than universal values.

Every result also needs provenance. The record should identify the model and relevant configuration version, the input and processing context, the site, and the time at which the result was produced. That makes a later incident traceable and prevents a historical result from being silently reinterpreted as though a newer model produced it. A rollback path provides a controlled response when a change degrades the service, but rollback is useful only if versions, dependencies, data contracts, and decision ownership are preserved together.

Standards work such as IHE AIRA can provide a vocabulary and workflow context for assessing and feeding back AI results. Exact profile scope, revision, maturity, and implementation details are volatile and belong in maintained companion reference material. The evergreen point is the separation of result assessment, feedback, monitoring, and accountability from the model’s original validation score.

This scope is consistent with the official IHE AIRA profile and the current FUTURE-AI consensus guidance; neither is a complete operational monitoring program.

Model updates restart validation

Changing the model after deployment creates a new validation and governance question. The scale of the required work depends on what changed and on the risk of the intended role, but a new version must be identifiable and its relevant behaviour rechecked before it replaces the previous version. The staged evaluation path may be reused at a smaller or targeted scale; it should not disappear merely because the software update was called a maintenance release. Preprocessing, thresholds, calibration maps, and external services can change the effective system even when the weights do not.

Online or continuous learning adds another boundary problem. If live cases update the model, the training stream and the evaluation stream can become entangled. The update protocol must state how data are separated, how labels arrive, which version made each decision, and how a regression is detected. A historical result must remain attributable to the version and configuration that produced it; otherwise monitoring cannot explain which system was actually observed.

Consider a constructed example in which a lung-CT triage service shows a sensitivity drop of 8% in a later month even though no model code changed. A scanner or reconstruction upgrade, a changed case mix, a prevalence shift, a changed reference practice, or a workflow/threshold change could each motivate a different investigation. Earlier monitoring of scanner mix, input distributions, calibration, alert volume, and sampled reference outcomes might have revealed a leading signal. The number alone does not identify the cause, and stable monthly AUROC would not prove that the rest of the system was stable.

The lifecycle record therefore joins monitoring signals to versions, owners, and actions. It also makes visible the point at which a research pipeline is no longer just being evaluated, but is being offered for a purpose in a real service. That is the boundary considered next.