A deployed clinical algorithm becomes a standing liability the moment it goes live, and most health systems still watch it with nothing. Validation happens once, before go-live; the model then runs for years while the patients, coding conventions, and upstream data pipelines beneath it shift. Algorithmovigilance is the discipline of watching for that decay. This page is a build sequence — the operating model to adopt, the signals to instrument, the people to name, the cadence to run, and the escalation path to wire — with each step tied to a primary source. It is orientation and general guidance; confirm any monitoring obligation that carries regulatory or contractual weight with your compliance function before you rely on it. As of July 2026.
What algorithmovigilance is, in one paragraph
Algorithmovigilance is the set of scientific methods and activities for evaluating, monitoring, understanding, and preventing adverse effects of algorithms used in healthcare. Peter Embi proposed the term in 2021, framing it deliberately on the model of pharmacovigilance and aiming it at two things at once — effectiveness and equity 1. A 2024 analysis carried the analogy into working machinery, showing how the pharmacovigilance toolkit adapts to deployed AI: "Drawing inspiration from pharmacovigilance methods, we discuss concepts that can be adapted for monitoring AI systems in healthcare" 2. That is the operating model this guide builds on: drug safety spent decades assembling infrastructure for spontaneous adverse-event reporting, cross-institution signal detection, and graded responses from label changes to withdrawal — and each has a plausible analogue for a deployed model.
Why a program: the two failures that define the field
A build guide earns its cadence from the failures it is designed to catch. Two published cases anchor the discipline, and between them they name the signals a program must instrument.
The first is a monitoring failure. When a widely implemented proprietary sepsis model was externally validated at one academic health system, it "predicted the onset of sepsis with an area under the curve of 0.63" and, at its live alerting threshold, "did not identify 1709 patients with sepsis (67%)" while generating alerts on roughly 18% of all hospitalized patients 3. The model had passed its developer's internal checks. Only surveillance at the deploying site surfaced the gap between the summary figure and the bedside miss rate.
The second is an equity failure. A 2019 study of a care-management algorithm applied to millions of patients found that, at a given risk score, "Black patients are considerably sicker than White patients, as evidenced by signs of uncontrolled illnesses" — because the model used healthcare cost as its proxy for need 4. Overall accuracy looked fine. The harm lived entirely in a subgroup, invisible to any aggregate metric.
Read together, these are the brief: watch the operating point, not the summary number, and watch every subgroup, rather than the mean alone.
The build, step by step
Six steps take a health system from nothing to a running program. Each is tied to the source that grounds it.
| # | Step | What it means in practice | Source |
|---|---|---|---|
| 1 | Adopt the operating model | Treat every deployed model as something to be surveilled for its whole life, on the pharmacovigilance pattern | 12 |
| 2 | Baseline before go-live | Record external-validation performance as the reference every later measurement is compared against | 3 |
| 3 | Instrument the four signals | Discrimination and calibration, subgroup performance, alert burden, and drift — on a dashboard | 345 |
| 4 | Set a risk-tiered cadence | Check tools close to clinical decisions more often; check administrative tools periodically | 6 |
| 5 | Name owners and a reporting route | A designated owner per model, plus a channel for clinicians to report suspected harm | 26 |
| 6 | Wire escalation to action | Pre-agree the thresholds that trigger retraining, restriction, or retirement | 78 |
1. Adopt the operating model
Start by settling what the program is: a standing process, never a one-time event. Embi's framing gives it purpose — effectiveness and equity — and the pharmacovigilance mapping gives it structure: signal detection, causality assessment, and incident reporting, each transposed from drugs to algorithms 12. Adopting this model up front decides everything downstream, because it reframes a deployed model as a supervised intervention rather than a finished purchase.
2. Baseline every model before go-live
You cannot detect decay without a reference. Before a model touches care, record its performance under external validation — tested on data from a different site, scanner, or era than it was built on — and store that as the baseline. The sepsis case is the warning: a model can arrive with a strong in-house number and post an AUC of 0.63 the first time it meets a new population 3. The baseline is the line every later measurement is read against. For the wider set of questions to ask of that pre-deployment evidence, see our guide on how to read an AI validation study.
3. Instrument the four signals
This is the core of the build. A dashboard should carry four families of metric, refreshed on a schedule:
- Discrimination and calibration. Discrimination (whether the model still ranks sicker patients above healthier ones) degrades quietly; calibration — whether a predicted 20% risk still matches a 20% observed rate — degrades faster and is the property that most directly drives over- or under-treatment.
- Subgroup performance. Break every headline metric down by the groups the model touches. The 2019 bias case is the reason: a model can hold its overall performance while failing a subgroup outright 4.
- Alert burden. Track how often the model fires and what share of true cases it catches at its live threshold. The sepsis model's 18% firing rate against a 67% miss rate is exactly the pairing a dashboard makes visible 3.
- Drift. Watch for model drift — shifts in the input data, the case mix, or upstream systems that move performance away from baseline over time.
Vanderbilt's published platform confirms the shape: it is organized around a performance-monitoring dashboard, model-specific pages, and snapshot views built for governance review 5.
4. Set a risk-tiered cadence
Not every model deserves the same watch. The Joint Commission and CHAI put the sorting rule plainly: scale monitoring to how close a tool sits to patient care. Their guidance tells organizations that "tools that inform or drive clinical decisions should be checked more often; tools that simply help with administrative or documentation tasks can be checked periodically," and it names the artifact — "developing an AI dashboard" — that carries the checks 6. Tier your models on that axis and set review frequency per tier.
5. Name owners and a reporting route
Surveillance with no owner is theater. Assign a designated individual accountable for each deployed model's performance, and stand up a channel for clinicians to report suspected algorithm-related harm — the incident-reporting limb of the pharmacovigilance analogy 2. The Joint Commission and CHAI reinforce both halves, calling for feedback channels to vendors on model changes and a route for reporting adverse events to leadership 6. This is where the program stops being a dashboard and becomes an accountable function.
6. Wire escalation to action
A signal that triggers nothing is noise. Pre-agree the thresholds that move a model from "watch" to "act" — retraining, restricting to a narrower population, or retirement. When the monitored model is a regulated device with a predetermined change control plan, those monitoring results feed the pre-authorized criteria that govern retraining, so escalation and the device's update pathway are the same wire. The HTI-1 rule adds a standing duty here for certified predictive tools: developers must "adhere to certain ongoing maintenance requirements to keep their DSI source attribute information complete and up-to-date as well as implement risk management practices for Predictive DSIs they supply" 7. And the Health AI Partnership's decision framework makes the end of the path explicit, treating "monitor the AI solution" and "update or decommission the AI solution" as distinct lifecycle stages with their own guides 8. Retirement is a planned move rather than a failure.
A reference blueprint: VAMOS
Health systems no longer have to design from scratch. Vanderbilt University Medical Center built the Vanderbilt Algorithmovigilance Monitoring and Operations System (VAMOS) through participatory design sessions and published the work in 2025, noting that few systems yet support systematic monitoring and governance of AI across a health system 5. The value for a team standing up its own program is the distilled interface set — a performance-monitoring dashboard, model-specific pages, and governance snapshots — which maps almost one-to-one onto steps 3 through 6 above. Treat it as a blueprint for what "instrumented" looks like in production.
How to read this build
Four cautions travel with the sequence.
First, a program is a standing process, never a project with an end date. Its whole premise is that validation is an event and vigilance is the process that outlasts it 1. Budget it as an ongoing function.
Second, responsibility is shared, and locally inescapable. Device manufacturers carry post-market obligations, but local performance depends on local data, workflows, and populations — which is why deploying systems build their own capacity rather than waiting on the vendor 5. Contract for vendor cooperation; own the local watch regardless.
Third, the mandate is hardening. What reads today as good practice is becoming an expectation: the HTI-1 maintenance duty is live for certified predictive tools 7, and accreditor guidance now names ongoing monitoring as an element of responsible use 6. The moving global picture is tracked in our global AI in health regulation tracker.
Fourth, monitoring lives inside governance. A dashboard without a committee to read it and act changes nothing; the escalation path in step 6 assumes a body with the authority to restrict or retire a model. That structure is the subject of our companion hospital AI governance committee playbook. Because some monitoring obligations are contractual or regulatory, confirm the specific duties for any deployed tool with your compliance or regulatory function before relying on this outline.
Sources and method
This guide is built from primary material. The operating model comes from the two papers that define the field — Embi's 2021 framing of algorithmovigilance 1 and the 2024 pharmacovigilance-mapping analysis 2. The signals to instrument come from two documented failures used as worked examples: a sepsis-model external validation 3 and a care-management bias study 4. The platform blueprint is Vanderbilt's published VAMOS design 5. The cadence, ownership, and mandate come from three governance instruments: the Joint Commission and CHAI's 2025 responsible-use guidance 6, the HTI-1 Final Rule's ongoing-maintenance duty 7, and the Health AI Partnership's eight-decision-point framework 8. Every figure is drawn from the source cited beside it. We revisit this page every ninety days and whenever a tracked instrument changes. Statuses are current as of July 2026.