Eighteen months after go-live, a deterioration score at a large academic hospital was quietly missing patients it used to catch. Nothing broke. No dashboard turned red. The vendor's national numbers were unchanged, the model still ran on schedule, and the alerts still fired at roughly the usual rate. What had changed was invisible from the clinical floor: the lab had switched creatinine assays, and a single input the model leaned on had shifted its distribution. Sensitivity at the operating threshold had decayed for months before anyone noticed, and the way they finally noticed was a near-miss on a patient who should have triggered an alert and did not. This lesson is about the discipline that would have caught it in weeks instead of months: the monitoring program you stand up so that a degrading model announces itself to you, on purpose, before it announces itself through a harmed patient.

Drift Never Sounds Its Own Alarm

The central danger of a deployed clinical model is not that it fails loudly. It is that it fails silently. A model that passed local validation at go-live, that earned its place in your workflow by proving it worked on your patients, can degrade over the following months without a single visible symptom. The predictions still arrive. The alerts still fire. The interface looks identical. The only thing that has changed is that the model is now wrong more often than it was, and the error is diffuse enough that no individual clinician can feel it. This is why monitoring is not optional polish on a deployment. It is the mechanism by which a governance program keeps its promise that the tool still works.

The phrase to hold onto is drift: the gradual divergence between the conditions under which a model was validated and the conditions under which it now operates. Drift is not a bug in the model. The model is doing exactly what it was built to do. The world around it moved. Because the model cannot know that the world moved, it keeps producing confident outputs from stale assumptions, and those outputs look no different from correct ones. You cannot see drift by looking at any single prediction. You can only see it by watching the aggregate behavior of the model over time against a fixed expectation you defined in advance. If no one is watching that aggregate, the degradation is real and the silence is total.

Drift never sounds its own alarm. If no one is watching, the model degrades in silence, and the first alert you get is a harmed patient.

Understand what this means for accountability. When a model harms a patient through silent drift, the failure is not the model's and it is not the vendor's alone. It is the health system's, because the health system deployed a tool and then stopped verifying that the tool still did what it claimed. Monitoring is the standing evidence that you kept verifying. Without it, your answer to the question "how do you know this model still works?" is a shrug, and a shrug is not an answer a governance committee, an accreditor, or a plaintiff's attorney will accept.

Validation is a snapshot, monitoring is a movie

It helps to separate two things that clinicians and executives routinely conflate. Validation is the work you do before go-live and at defined intervals: you take the model, run it against a labeled sample of your own patients, and confirm it discriminates and calibrates well enough to earn a place in the workflow. Validation is a photograph. It tells you the model worked at one moment, on one population, under one set of conditions. Monitoring is the continuous film that runs after the photograph is taken. It answers a different and harder question: is the model still the thing you validated, right now, on the patients in front of you today? A hospital that validates carefully and then never monitors has confused a snapshot for a movie. It knows the model was good the day it was born and knows nothing about the model it is actually using this afternoon.

This distinction is exactly why the accreditation frameworks now name post-deployment monitoring as a separate obligation from pre-deployment validation. The Coalition for Health AI (CHAI) and the Joint Commission guidance on the responsible use of AI in health care, released September 17, 2025, sets out seven foundational elements, and it deliberately requires evaluation for risk and bias both before and after deployment. Read that carefully: the framework does not treat a strong go-live validation as sufficient. It treats validation as the opening chapter and ongoing monitoring as the obligation that keeps the promise honest for the life of the tool. When a surveyor eventually asks to see how you satisfy that element, the go-live slide deck will not answer the question. The monitoring record will.

The regulatory context reinforces the same point from a different angle. The FDA regulates clinical AI as a medical device, and by early 2026 more than 1,350 AI and machine-learning enabled devices had been authorized, roughly double the count from 2022. That is a large and growing installed base, and every one of those authorizations is a statement about intended use under defined conditions, not a guarantee that the device performs in your workflow, on your population, in perpetuity. A clearance is the beginning of your responsibility, not the end of it. Treat 1,350 not as reassurance but as a number to verify against your own local experience: authorized for what intended use, validated on whose data, and monitored by whom once it reaches your floor.

The Types of Drift You Are Hunting

You cannot monitor for a threat you cannot name. Drift is not one phenomenon. It comes in distinct forms with distinct signatures, and a monitoring program has to be built to catch each of them, because the signal that flags one is often blind to another.

Data drift: the inputs change

Data drift, also called dataset shift, is a change in the distribution of the inputs the model consumes. The relationship between inputs and outcome may be perfectly intact, but the inputs themselves no longer look like what the model was trained and validated on, so it operates outside the range where it was proven. The causes are mundane and constant. A lab swaps to a new assay and the numeric scale of a key value shifts. Someone redesigns an EHR template and a field that used to be populated is now empty or captured differently. A coding practice changes and a diagnosis that used to appear now maps to a different code. A new patient population arrives because your system opened a clinic or absorbed a merger. A seasonal shift changes the case mix. A documentation habit changes because a new dictation tool rephrases how clinicians describe the same finding. Any of these can move an input distribution enough to degrade a model, and none of them involve touching the model at all.

Data drift is the drift you can most often catch early, because you can measure it without waiting for outcomes. You can compare this month's input distribution against the validation-era distribution today, before a single patient outcome is known. That property makes input monitoring your earliest warning system.

Consider what data drift looks like on the floor, not on a slide. A deterioration score that leaned heavily on a creatinine value does not throw an error when the lab swaps assays. It simply reads the new numbers as if they were the old numbers, because to the model a number is a number. If the new assay runs half a tenth lower on average across the range that matters, the score's internal notion of "this kidney is stressed" quietly slips, and every patient the model scores that day is scored against a scale that no longer means what it meant at validation. No clinician sees a broken chart. They see a score, and the score looks entirely normal, which is exactly the problem. The degradation is not in any one reading. It is in the relationship between the reading and the truth, and that relationship is invisible to anyone looking at a single patient.

Concept drift: the meaning changes

Concept drift is subtler and more dangerous. Here the relationship between the inputs and the outcome itself changes. The inputs may look identical to what the model always saw, but what they predict has moved. A new treatment enters practice and changes the trajectory of a disease, so the same early signs no longer lead to the same outcome. A new care pathway means patients who once deteriorated are now intercepted earlier, breaking the correlation the model learned. A pandemic redefines what a fever or a cough means for a given diagnosis. Concept drift cannot be detected by input monitoring, because the inputs look fine. It only shows up in the outcome metrics, which is precisely why you cannot rely on input monitoring alone.

The feedback loop: the model distorts its own evidence

There is a third, self-inflicted form of drift that governance committees consistently underestimate. When a model recommends an action and clinicians act on it, the model has changed the very behavior that generates its future training and evaluation data. A sepsis model that prompts earlier antibiotics will, if it works, prevent some of the sepsis cases it was built to predict. Those prevented cases now look like false positives in the data, because the patient was flagged and then did not deteriorate. The model's measured precision appears to fall, not because the model got worse, but because it succeeded. This is the feedback loop, and it means naive performance metrics on post-deployment data can be systematically distorted. You have to account for it in how you interpret your numbers, or you will retire a model for working.

Vendor-side change: the model moves under you

The last category is not drift in the world but drift in the tool. A vendor updates or retrains the model and changes its behavior, sometimes without clearly disclosing it. The version you validated is not the version running today. From your side this is indistinguishable from concept drift unless you are watching for it: performance shifts, the input-output relationship changes, and nothing in your own environment moved. This is why you must treat vendor change as a monitored event and demand contractual notification of model updates. The FDA mechanism that formalizes this is the predefined change control plan (PCCP), which lets a device maker update a model within pre-authorized bounds without a new submission. A PCCP is a reasonable regulatory instrument, but from a monitoring standpoint it is exactly why you cannot assume the model is frozen. It is authorized to move, so you must watch for movement.

Sit with the implication, because it inverts an assumption most clinicians carry into a deployment. The intuitive mental model is that software is fixed: you install a version, and it stays that version until someone deliberately upgrades it and tells you. A PCCP breaks that assumption on purpose. It is the FDA's answer to the fact that machine-learning models improve when retrained on new data, and it lets a manufacturer ship those improvements within a pre-authorized envelope without returning for a fresh clearance each time. That is efficient for the manufacturer and often good for patients in the aggregate. But it means the model behind your interface can be a moving target, and the movement can be entirely legal and entirely invisible to you. The number to hold in mind is that with 1,350-plus authorized devices and a regulatory pathway that explicitly permits in-bounds change, "the version we validated" is a claim with a shelf life. You do not get to assume permanence. You have to instrument for change and write the vendor's duty to notify you into the contract, so that a PCCP-permitted update becomes a scheduled, verified event rather than a silent shift you reconstruct after a patient is harmed.

The Monitoring Program You Must Build

Naming the threats is the easy part. The hard part is standing up a program that will actually catch them, staffed and funded and owned, not a slide that says "we will monitor." A durable program has four parts, and the order matters.

1. Define metrics tied to the clinical decision

Monitor what the decision depends on, not what is easy to graph. The panel should span both the model's statistical behavior and its behavior in the workflow. On the statistical side: discrimination (the model's ability to separate patients who will have the outcome from those who will not, usually reported as AUROC, the area under the receiver operating characteristic curve); calibration (whether a predicted risk of thirty percent actually corresponds to thirty percent of such patients having the event, because a model can discriminate well and still be miscalibrated); and the operating-point metrics that govern what actually happens to patients: sensitivity, specificity, positive predictive value (PPV) and negative predictive value (NPV) at the operating threshold you deployed, not at some abstract optimum. On the workflow side: alert volume and fire rate, and the override or dismissal rate, which is often your fastest human signal that something has changed because clinicians feel a model going wrong before the statistics confirm it. And running through all of it, subgroup performance, because drift is rarely uniform and a model can hold steady in aggregate while decaying badly for one population.

Crucially, include data-quality and input-distribution monitors that watch the inputs directly. These are your leading indicators. They can flag drift before a single outcome is available, which matters enormously because in medicine the ground truth is usually delayed.

What to track, and how often

A monitoring program is only as real as its cadence. A metric that is technically defined but reviewed "when we get around to it" is not being monitored. Different signals need different rhythms, and the right rhythm is set by two things: how fast that signal can move, and how long you can tolerate not knowing it has moved. Input-distribution and data-quality monitors can and should run continuously and be reviewed at least weekly, because they are your tripwires and they cost you nothing to check often. Outcome-based metrics arrive slowly and are expensive to compute, so they are reviewed monthly or quarterly depending on how long ground truth takes to resolve. Subgroup performance deserves its own scheduled review so it is never quietly folded into an aggregate that hides it. Override and dismissal rates, being a live human signal, belong on a standing dashboard that a person actually looks at, not a report filed in a shared drive. And the whole panel needs a formal control-limit review on a fixed calendar, so that thresholds are revisited deliberately rather than eroded by habituation. The table below is a starting cadence, not a ceiling; a higher-risk or more autonomous tool earns tighter intervals.

Notice the shape of it. The signals you can watch cheaply and immediately, you watch cheaply and immediately. The signals that are slow and definitive, you accept on their own timeline but never skip. And the act of reviewing the thresholds themselves is scheduled, because a control limit that is never revisited becomes either a nuisance everyone ignores or a wall so high that real decay walks under it. Every interval in that table is a number you should be able to defend to a governance committee: not "we monitor continuously" as a slogan, but "input drift continuous and reviewed weekly, outcome metrics monthly, subgroup quarterly, thresholds annually," each with the reason it is set where it is.

2. Set thresholds before you look

A metric with no threshold is a decoration. For every metric that matters you must define a control limit: the level of change that triggers a formal review. And you must define it before you look at the running data, for the same reason a clinical trial defines its endpoints before unblinding. If you set the threshold after seeing the numbers, you will rationalize whatever you see, and a slow decay will always look like acceptable noise in the moment. The threshold is a promise made by your past self to your future self that a specified amount of degradation will not be explained away. It converts a graph anyone can stare at indefinitely into a trigger that forces a decision.

3. Assign a named owner

The single most common failure in clinical AI monitoring is diffusion of responsibility. "The committee monitors it" means no one monitors it, because a committee is not awake at 2 a.m. and does not get a page. Every high-risk tool needs a named accountable owner: a specific person whose job includes watching that model's metrics, who receives the threshold-breach notification, and who is answerable when it drifts unnoticed. The committee governs the portfolio and sets policy. A person watches the model. If you cannot name the person for a given tool, that tool is not being monitored, no matter what your policy document says.

4. Write the response plan

A tripped threshold with no predefined response is an alarm no one is authorized to act on. Before go-live, write down what happens when a control limit is breached and who decides. The escalation ladder generally runs: investigate (confirm the signal is real and find the cause, distinguishing data drift from concept drift from a data-pipeline bug); then, depending on findings, recalibrate or retrain the model, restrict its use (narrow the population, lower its autonomy, or revert to human-only workflow) while you fix it, or retire it if it can no longer be trusted. Each rung needs a named decision authority. The point of writing this before you need it is that the moment you need it is the worst possible moment to be inventing it, because a patient may be exposed while you deliberate about who is allowed to pull the model.

Leading Versus Lagging, and the Ground-Truth Problem

The practical crux of clinical monitoring is that the truth arrives late. To know whether a sepsis prediction was correct, you need the confirmed diagnosis, which may take days. To know whether a readmission model was right, you wait thirty days. To know whether a cancer-risk model was right, you may wait years. If you only monitor outcome metrics, you are always looking at how the model performed in the past, and a model can drift for a full outcome cycle before your lagging metric even registers it.

This is why the distinction between leading and lagging indicators is not academic. Lagging indicators are the outcome-based metrics: AUROC, calibration, sensitivity, PPV, all computed once ground truth exists. They are the most trustworthy signals and the slowest. Leading indicators are the signals available immediately: input-distribution drift, data-quality flags, alert fire rate, override rate. They are noisier and less definitive, but they move first. A mature program watches both. When a leading indicator moves, you do not yet know the model got worse, but you know something changed, and you investigate before the harm accumulates. The input-drift monitor is the tripwire; the outcome metrics are the confirmation.

None of this is discretionary from an accreditation standpoint. The Coalition for Health AI (CHAI) and the Joint Commission framework of seven foundational elements for the responsible use of AI in health care, published September 17, 2025, require evaluation for risk and bias after deployment and ongoing monitoring, not a one-time validation at go-live. Those seven elements span AI policy and governance, patient safety and quality, a designated governance structure, risk and bias evaluation both before and after deployment, vendor disclosure of known risks and limits, validation on representative data, and workforce training. The monitoring discipline in this lesson is how you actually satisfy the post-deployment half of that risk-and-bias element and the ongoing-safety element, rather than gesturing at them in a policy. The guidance is currently voluntary and expected to inform future accreditation, which means the smart posture is to build the monitoring record now, on your own timeline, rather than reconstruct it under a surveyor's gaze later. Monitoring is a governance obligation, and treating it as an IT afterthought is precisely the posture that leaves a model unwatched.

A Worked Example: A Tale of Two Hospitals

Consider the same tool, a deterioration score built into the EHR, deployed at two hospitals with the same vendor, the same version, and the same lab-assay change hitting both at the same time.

Hospital A, unmonitored. At go-live the model validated well locally. The team celebrated, closed the project, and moved on. There was no defined metric panel, no threshold, no owner, and no response plan. Eleven months later the lab switched creatinine assays. Creatinine was one of the model's most influential inputs, and the new assay shifted the numeric distribution enough that the model's risk estimates skewed low. This was textbook data drift: the input-output relationship was intact, but the inputs no longer matched the validation era. Sensitivity at the operating threshold fell quarter over quarter. Alerts that should have fired did not. Because no one held a control limit and no one owned the tool, the decay was invisible for months. It surfaced only when a rapid-response nurse noticed that several deteriorating patients had never triggered the score and raised it informally. By then the model had been quietly under-alerting across the medical-surgical floors for the better part of a year, and the remediation began with an apology and a root-cause investigation instead of a routine recalibration.

Hospital B, monitored. Same tool, same assay change. But at go-live this team had defined a metric panel that included input-distribution monitors on every high-influence feature, set a control limit on distribution shift, named a clinical informaticist as the accountable owner, and written a response plan. When the assay changed, the creatinine input-drift monitor tripped within the first weeks, long before any outcome data could have revealed the problem. The owner received the breach notification and investigated. They confirmed the shift was a real input change, traced it to the lab, and, per the response plan, restricted the model to advisory-only while the vendor recalibrated it against the new assay. No patient went unmonitored on the strength of a silently degraded score. The difference between the two hospitals was not the model, the vendor, the data, or the event. It was that one of them was watching a leading indicator and the other was watching nothing.

The lesson generalizes to the vendor-side case. Suppose instead of a lab change, the vendor had pushed a retrained model under a PCCP. Hospital A would have experienced an unexplained shift in behavior and, lacking any monitoring, would have absorbed it blindly. Hospital B's metrics would have moved, the owner would have investigated, found no local cause, and correctly concluded the model itself had changed, triggering the contractual review of the vendor's update. Monitoring does not distinguish the cause for you. It guarantees that a change of any origin becomes visible and owned.

Key Takeaways

• Drift never sounds its own alarm. A model that passed local validation can degrade silently after go-live, and the first sign of failure will be a harmed patient unless you are actively watching. Monitoring is a governance obligation, not an IT afterthought.
• Learn the forms of drift. Data drift changes the inputs (a new assay, template, code, or population), concept drift changes the input-to-outcome relationship (a new treatment or pathway), the feedback loop distorts your own metrics when the model changes clinician behavior, and vendor-side change moves the model under you.
• Build the four-part program: define metrics tied to the clinical decision, set control-limit thresholds before you look, assign a named accountable owner for each high-risk tool, and write the response plan in advance.
• Monitor the full panel: discrimination (AUROC), calibration, sensitivity, specificity, PPV and NPV at the operating threshold, alert and override rates, subgroup performance for equity, and input-distribution monitors.
• Ground truth is delayed, so pair lagging outcome metrics with leading indicators. Input-drift and override-rate monitors move first and can flag trouble before any outcome is even known.
• A control limit must be defined before you view the running data, or you will rationalize any decay as noise. The threshold is a promise your past self makes to your future self.
• Name a person, not a committee. If you cannot name who watches a given tool, that tool is not being monitored regardless of what the policy says.
• Treat vendor updates as monitored events. A PCCP authorizes the model to change within bounds, which is exactly why you cannot assume it is frozen and must demand notification and watch for movement. The CHAI and Joint Commission seven elements require risk-and-bias evaluation and ongoing monitoring after deployment, not just at go-live.