A post-market surveillance programme for an AI/ML medical device running across several hospitals does not wait for confirmed outcomes. It compares each site’s input data, acquisition metadata and model outputs against a validated reference, because ground truth in clinical imaging is seldom available in real time. The thresholds that trigger action are set in a post-market surveillance plan before launch, which EU medical device rules already require of the manufacturer. In the US, FDA’s AI/ML action plan describes a predetermined change control plan with an expectation of real-world performance monitoring, and Good Machine Learning Practice asks that deployed models are monitored and their retraining risks managed.

That makes post-launch safety a production reliability problem, distinct from the accuracy validated before launch. A model validated before launch can still regress at one site after an equipment or software change. What catches that regression is a set of engineering artefacts (drift detectors, written triggers, regression checks, site validation packs), not a dashboard someone opens once a quarter.

A review cited in a 2025 paper on statistically valid post-deployment monitoring found that only 9% of FDA-registered AI-based healthcare tools include a post-deployment surveillance plan.

What the surveillance plan has to pin down before go-live

The written plan that replaces a vague intention to monitor for drift defines the monitored indicators and thresholds, the trend methods, and the criteria for corrective action, from a documented nonconformance to threshold adjustment, retraining or retirement.

RAISE, a radiology AI safety lifecycle framework, expects operating thresholds for these checks to be set from model specifics and risk tolerance. Thresholds are adjusted in consultation with medical leaders, and a committee-owned decision still names one accountable individual.

EU guidance on post-market surveillance under MDR and IVDR lists what the plan contains. The last row of the table below is a per-metric discipline from Censinet’s published framework for clinical AI risk management, not from the regulation.

Plan element	What it fixes in advance
Monitored aspects and frequency	What is monitored, how often, and which methods, chosen to fit the device’s risk profile with a stated rationale
Indicators and threshold values	Limits beyond which action is taken, set in the pre-market phase and re-evaluated with surveillance data
Trend method and observation period	How a statistically significant increase in the frequency or severity of incidents is established
Corrective-action criteria	When a finding becomes a documented nonconformance, a CAPA or a field safety corrective action
Communication	How surveillance output reaches competent authorities, notified bodies, economic operators and users
Per-metric definition	Owner, threshold, numerator, denominator, data source, review window and minimum sample size for each metric

One hospital goes out of tolerance: suspend that site or the whole network?

How far a suspension reaches should follow the evidence: contain a problem within a narrower workflow where that is possible, and stop use where evidence supports a risk of patient harm. TechnoLynx’s AI Governance and Trust work helps a manufacturer or health system decide that escalation logic in advance.

Censinet’s framework gives a three-level response ladder, and notes that a single severe event can justify suspension even when average metrics remain acceptable.

Action level	Trigger	Required response
Investigate	Performance decline, a subgroup gap beyond approved tolerance, increasing overrides, or missing-input failures	Clinical and technical owners review affected cases and identify the cause
Restrict	The problem can be contained within a narrower workflow	Limit use to validated settings, require clinician review, or remove automation
Suspend	Evidence of patient-harm risk, unsafe recommendations, serious compromise, or an unverified model version or configuration	Stop use and switch to the approved non-AI workflow

Two drift-monitoring papers point the same way. The CheXstray authors (2022) describe pausing a significantly drifted model for confirmatory auditing and root-cause analysis before choosing between a new model, retraining or reworking DICOM study routing. At network level, Feng and colleagues (npj Digital Medicine, 2022) argue that if substantial performance drift is detected across multiple sites, the regulator should be able to put the algorithm’s licence on hold.

When a model goes live at a new hospital, can we rely on the original validation?

No. Each new hospital needs local validation on its own patients, equipment and integration before clinicians rely on the score there, because models are often developed on limited datasets that do not represent real-world diversity. Youssef and colleagues (Nature Medicine, 2023) point out that external validation does not guarantee generalisability and that clinical models have proved unreliable when tested across multiple sites.

One practical form is a noninterventional, silent deployment. In the 2026 Nature Cancer study of Google’s mammography AI, a noninterventional deployment at 12 NHS screening sites scored live cases without influencing assessments or recall rates. That deployment confirmed technical feasibility but revealed a distribution shift that required threshold recalibration. After about two weeks, at the two screening services reviewed, AI recall stood at 11.3% and 12.3% against human first-reader rates of 3.8% and 5.3%, so the operating point was adjusted using the prospectively collected data.

In these studies, performance shifted with equipment, software version and acquisition parameters. In the same Nature Cancer study, cases from newer Hologic Selenia Dimensions units had a recall rate of 10.9% against 6.3% on the older Lorad Selenia. A 2025 UK study of the Mia breast-screening AI, which had not previously been evaluated on Selenia Dimensions equipment, had the vendor generate a site-specific threshold from a 16,204-screen local validation set. A software upgrade on those units roughly tripled recall, and local calibration with per-software-version thresholds brought the recall rate down from 47.7% to 13.0%. In CT, a post-deployment CT validation framework testing one public model (MONAI RetinaNet) on the LIDC-IDRI dataset found that 5 mm slice thickness cost 19 percentage points of sensitivity, against about 4 points for dose reduction.

How many local cases are enough is a context-specific question. Kore and colleagues name the criticality of the application, how often it is used and the population it serves among the factors. They also found drift-detection sensitivity strongly correlated with sample size, and noted that gathering 4,000 chest X-rays takes a large provider days and a smaller one months. In the 12-site study, even two months of data across two services gave too small a sample for a conclusive fairness analysis.

Recalibration at a new site can mean moving the operating point without retraining: that study chose a service-specific operating point from chronologically separate local tuning data without changing the model’s weights. The Mia authors note that many centres would struggle to recalibrate a user-definable threshold themselves, for lack of data or technical expertise.

Censinet’s framework lists material changes in lab methods among those requiring a recorded choice between targeted testing, full revalidation, new approval or suspension. Where a site’s assay differs, we would recalibrate the input mapping for the affected analytes or withhold the score there until the assays are harmonised.

A clean local evaluation is not the end either: the Mia authors pair local retrospective evaluation with ongoing quality assurance.

If we tighten the alert threshold, can the triage team absorb the extra cases?

Only if the recalibration projects the extra weekly volume a tighter threshold would create and checks it against the team’s sustained throughput first. A threshold nobody can work is not a safer threshold. TechnoLynx’s Production AI Reliability work covers this operating side of recalibration, putting the projected queue volume at a proposed threshold into the same change review as the sensitivity gain.

We would project it by replaying the candidate threshold over recent scored cases, applying the historical alert-to-case conversion rate, and comparing the weekly total with what the team clears in an ordinary week.

The 12-site mammography study calls threshold setting a task with technical, clinical workflow and capacity considerations. It targeted an AI recall rate no more than 2 absolute percentage points above the first human reader, with a predicted arbitration rate under 2.5 times the human-only rate. Kore and colleagues make a related point: institutions may have to trade how often they run drift detection against how sensitive it is, and that decision belongs with all relevant stakeholders.

The quantified surge-throughput figure we draw on comes from security operations, not pharmacovigilance. One security-operations source describes an analyst who handles 30 alerts an hour under normal conditions dropping to 18 or 20 during a surge. We treat the transfer to a pharmacovigilance or clinical triage queue as our inference, not a measured result. What carries over is that capacity has to be measured as sustained throughput under realistic load, never as the peak rate in a quiet week.

When the recalibration the data supports exceeds what the team can staff, we would write a fallback into the plan instead of deferring silently. The options are to request temporary capacity, phase the change in site by site, or adopt the most sensitive threshold that fits current capacity and record the residual risk. The projection assumes alert-to-case conversion stays stable, which a population or reporting change can break. A capacity check is also an operational safeguard, not a substitute for the clinical judgement on how sensitive the alert must be.

Who, by job title, is on the hook when a site breaches its threshold?

The accountable party is a named individual, not a team: even where a committee owns a decision, Censinet’s framework asks for one person who answers for it. TechnoLynx’s AI Governance and Trust work provides assurance over that accountability chain for a deployment.

We would give the role a title such as Clinical AI Safety Officer and keep it separate from the teams that build and monitor the model. The title is an organisational choice; what the governance framework asks for is a named accountable individual. Independence matters beyond the hospital too: Feng and colleagues argue that while the vendor designs the monitoring pipeline, the monitoring itself should be run by an independent entity to avoid conflicts of interest.

That person needs authority to stop use without waiting for a committee. Censinet’s guidance says emergency suspension of unsafe use should not wait for a committee meeting, and that use should switch to a validated non-AI workflow. The authority also has to be technically real. A framework on meaningful human oversight of medical AI warns that without reversible architecture, auditable control points and feedback loops, oversight remains theoretical. In practice that means a switch that withholds the score at one site and a rollback to the last approved version, both tested before go-live.

The same oversight framework gives quality and safety offices the job of reviewing post-deployment signals and recommending restriction, suspension or withdrawal. It also warns against making frontline clinicians the default guarantors of safety for systems they cannot meaningfully control.

For the compliance committee, the separation lives in a governance charter that states when an issue escalates and who has authority to resolve it. Each decision then goes into a version-linked record naming its owner, the affected setting, the decision and the next review date. Making those records tamper-evident is the subject of our piece on governance, audit trails and infrastructure assurance for AI/ML SaMD validation.

Once the model informs live decisions, how often is it reviewed and who approves the next site?

Review frequency should match clinical risk and reliance on the tool, and each additional site is a new approval decision, not an automatic extension of the first. TechnoLynx’s Production AI Reliability and AI Governance and Trust work cover the two halves: running the scheduled monitoring so the cadence actually happens, and assuring the approval record a committee signs before the next site comes on.

Moving from retrospective analysis to live use

For a clinical decision support tool, Censinet’s tiering calls for continuous or monthly dashboard review and quarterly reassessment, with drift listed among the escalation triggers. For high-risk uses it says governance may approve daily operational checks, weekly exception reviews and monthly clinical-performance reviews, using immediate proxy signals while outcomes are pending and then comparing confirmed outcomes with the validated baseline. A cadence that suited a retrospective study will rarely hold once outputs affect patients, so we would re-tier the model at the move to live use.

What the compliance committee wants before onboarding more sites

An approval process that holds up starts narrow: one workflow, location, user group and population, with the pilot period, baseline measures, acceptance thresholds and review dates set before launch, and expansion only once clinical and operational owners show the controls stay effective at the proposed scale. Aligning the process with FDA’s Good Machine Learning Practice helps it read as accepted practice to a committee, but alignment gives the case a structure without guaranteeing approval.

Reusing the existing evidence for each new site

We would use a risk-delta checklist: a new site matching the validated sites on equipment, software version, population profile and workflow is classed as covered by the existing evidence and goes through a shadow run, while any mismatch triggers fresh analysis. Software version belongs on that list, as the tripled recall after a mammography software upgrade shows. The checklist is only as good as its criteria, and criteria that are too loose will wave through a site that needed full analysis. The same covered-or-new test is one way to approach an autonomous system extending to new sites.

What sensitivity drop, over what window, should trigger a retraining review?

A defensible trigger is derived from the deployed model’s own baseline variability, per site where baselines differ, and written into the surveillance plan. In the breast-screening sources, thresholds were set on local data, not carried over: the 2026 breast-screening threshold-recalibration study set its external operating point on the target dataset, and the Mia authors call for independent verification before vendor-reported thresholds are trusted elsewhere. TechnoLynx’s Production AI Monitoring Harness builds that derivation into the monitoring pipeline (per-site reference windows, control limits computed from the validated baseline, alerts that carry their window and uncertainty), starting with framing which metrics and which site-level granularity the plan needs.

Worked example: deriving a drift threshold before any drift has happened

Setting a drift threshold empirically is hard, because the reference window is the no-drift baseline by definition and contains no drift-positive examples to calibrate against. The MMC+ drift monitor, validated on Massachusetts General Hospital chest radiographs, sets its threshold prospectively:

1. Fix a reference window as the no-drift baseline, with known characteristics and model performance.
2. Normalise the drift score against the reference set itself, using leave-one-out distances among reference windows, so values within the unit range look like an ordinary reference window.
3. Choose a target per-window false-alarm probability p and apply Cantelli’s inequality, T_p = √((1 − p)/p).
4. At p = 0.01, T_p = √99 ≈ 9.95, which the authors round to an operating threshold of 10.
5. Set the window and stride; MMC+ used 30-day windows with a 1-day stride to balance detection lag against small-sample noise.

The authors say deployments may choose a different p to reflect local audit capacity and risk tolerance. On their data spanning the onset of COVID-19, the threshold of 10 produced no false-positive windows for three of the four onset definitions tested. While the score stayed below 10, normalised AUROC stayed within 3 standard deviations of the reference mean.

Raw p-values make a worse trigger. The same authors found p-values volatile, regularly crossing the threshold when no substantial shift had occurred. A paper on an ML model monitoring framework found all the Kolmogorov-Smirnov tests it reported highly significant while none was operationally meaningful.

A drift score says the model is running on data where its performance is not well characterised. We would pair the drift score with a sensitivity floor. Control charts are a standard tool in statistical process control: they plot a statistic against control limits, and well-designed charts keep false alarms below a prespecified rate while minimising detection delay. CUSUM charts accumulate deviations to catch persistent small shifts, and EWMA charts give smoother detection of slow drift. The limit should reflect what counts as a clinically meaningful drop for the application. We would not treat a bare percentage as a trigger. It only becomes one when the metric, denominator, confidence interval and window are fixed with it.

In screening, the outcomes include interval cancers, which are not detected during routine screening but identified between rounds. A window long enough to capture them delays detection, so we would pair the sensitivity floor with faster signals. Feng and colleagues suggest monitoring a surrogate endpoint as a canary, such as 5-day survival for a model that predicts 30-day survival. The 12-site mammography study used recall rate as its proxy while follow-up outcomes were pending.

Is it drift, or just a different patient mix at that site?

Quality-improvement practice already has the vocabulary. Common-cause variation is the predictable variability a model’s specification allows, while special-cause variation is an unexpected change, such as a shift in the joint distribution of inputs and outcomes after new clinical guidelines.

Performance metrics are also a weak drift signal: Kore and colleagues found that monitoring model performance is not a good proxy for detecting data drift. When the shift is in disease prevalence, it can be handled without full retraining, by adjusting output probabilities to the new base rate or recalibrating the decision threshold. The 12-site study expected moderate drift to be compensated by operating-point adjustment, while substantial changes in image acquisition may require retraining.

MMC+ measures drift on the actual data and model behaviour, which its authors say isolates true data drift from human-layer changes such as new radiologists or reporting templates. Its authors leave the judgement of what counts as actionable drift to each site’s operators. That division fits the plan structure: the manufacturer fixes indicators and thresholds before launch, and site governance decides which local drift warrants action.

One threshold for every site, or one per site?

Monitoring should be per site, while the numeric threshold needs to be set per site only where baselines differ. Different points of care experience drift differently because they serve distinct populations, protocols and workflows. At Massachusetts General Hospital, the emergency room’s drift score rose and stayed high when the pandemic shifted its patient population, while an ambulatory operating room showed a widening uncertainty band and a 50-day gap as elective imaging dropped off, a pattern the aggregate score could mask. Sites with fewer scans need longer detection windows to keep uncertainty down. Granularity matters for metrics too: Kore and colleagues found per-class performance measures far more sensitive to drift than aggregated ones, and the CT validation framework found that aggregate sensitivity can hide clinically meaningful variation in how a model fails.

If sites have statistically similar case mix and baseline sensitivity, we would accept one threshold tuned on pooled baseline data. Where prevalence, demographics or equipment differ materially, each site gets control limits from its own baseline window, and what is harmonised across the network is the review and escalation process, not the number. Low-volume sites make site-specific limits statistically unstable, and pooling or Bayesian shrinkage toward the network estimate is the remedy we would reach for. The same problem outside medical devices is covered in our piece on designing segment-aware drift monitoring and retraining triggers.

What cadence and report content do regulators expect from post-market surveillance of an AI SaMD?

They expect a pre-specified, documented plan: indicators and thresholds for reassessing benefit-risk, trend methods and tools for corrective action, with the plan itself part of the technical documentation.

TechnoLynx frames and builds the monitoring behind such a policy. That means deciding which metrics, which site-level and network-wide granularity and which data flows the plan needs, implementing and validating the pipeline through the Production AI Monitoring Harness, and shaping its outputs into reports a compliance committee can use, with AI Governance and Trust covering the assurance side.

Not every line in such a policy is a regulatory requirement, and it is worth checking which ones are. The PMS system and plan are the manufacturer’s obligation under MDR and IVDR, and the EU AI Act requires providers of high-risk AI systems to establish and document a post-market monitoring system.

Mapping the plan to FDA and EU frameworks

Framework	What it asks of the surveillance plan
FDA predetermined change control plan	Anticipated modifications (SaMD Pre-Specifications) and the method for making them safely (Algorithm Change Protocol), with real-world performance monitoring, which FDA’s action plan expects
FDA Good Machine Learning Practice	Deployed models monitored in real-world use, with controls on retraining risks such as dataset drift
FDA draft guidance on AI-enabled devices, January 2025	How and when marketing submissions should describe postmarket performance monitoring and management
MDR and IVDR PMS plan	Indicators and thresholds, trend methods, complaint investigation tools and tools to trace devices for corrective action
EU AI Act Article 72	A post-market monitoring plan in the technical documentation, which may be integrated into an existing medical-device plan

Change control constrains the response. The CheXstray authors note that FDA’s approval process may discourage continuous model changes because they can trigger resubmission, which in turn discourages monitoring and reporting of flaws. We would put the expected drift responses (operating-point recalibration, reference-window refresh, retraining on defined data) into the change control plan’s pre-specifications, so a response stays inside what was cleared. MMC+ is designed for refreshing the reference: it swaps in a new validated reference once a drift has stabilised and been audited. Scoping those pre-specifications is covered in our piece on navigating predicate pathways and predetermined change control plans for AI/ML medical software.

What goes in the report, and how often

A surveillance report carries any statistically significant increase in the frequency or severity of incidents, the resulting changes to the benefit-risk profile, and whether corrective or preventive action is needed. Alongside that, we would show per-site and network metrics against their thresholds and every trigger that fired with the decision taken on it. The incident log behind the report records model provenance, data hashes, hardware configuration and integration tooling for each issue.

Where no cleared change control plan sets the cadence, review frequency should match clinical risk and reliance on the tool. Davis and colleagues (Journal of Biomedical Informatics, 2020) argue that updating models as calibration deteriorates, not on predetermined schedules, minimises interim periods of insufficient accuracy. We would re-measure sensitivity per site wherever volume supports a reliable estimate and network-wide in addition, because a systemic shift can be too small to see at any single site.

A policy document on its own does not validate the model. It only works when it is paired with monitoring infrastructure and data collection that actually run.

Who can build and run drift monitoring for a cleared device across our hospitals?

TechnoLynx builds the engineering that turns a surveillance plan into working monitoring: per-site reference windows and drift detectors. TechnoLynx’s engagement is the Production AI Monitoring Harness, starting with framing the metrics, site-level granularity and data flows the plan needs, as part of TechnoLynx’s AI engineering for life sciences and healthcare. Whether to build in-house comes down to whether the organisation can run the monitoring for the device’s whole lifetime (statistics, imaging pipelines, on-call response), not just stand it up. When choosing a partner, we would ask to see how a candidate derives a threshold from your baseline and what happens operationally when it fires.

The work is scoped for a model deployed across several sites, at site-level and network-wide granularity. A single site with one low-risk tool and a vendor dashboard that already meets its plan probably does not need it. There are other realistic routes: Feng and colleagues propose that hospitals create their own AI quality-improvement units for this work. Current proposals have the vendor lead performance monitoring, though Feng and colleagues argue an independent entity should run it.

FAQ

Does the FDA require post-market surveillance for AI medical devices?

FDA’s SaMD guidelines emphasise ongoing model evaluation, including prospective, statistically valid real-world performance monitoring. Its guidance on AI-enabled device software functions also stresses post-market strategies covering continuous performance tracking, early detection of data and feature drift, and recalibration protocols.

What are the main types of drift in a clinical AI model?

Covariate shift changes the inputs while the input-label relationship stays fixed. Label shift changes the outcome distribution, as with seasonal flu prevalence. Concept drift changes the relationship itself, for example through new guidelines or clinical practice. Radiology adds phenotype drift, which is a change over time in how a disease looks and presents.