Evidence explainer

Digital health and AI

Does a Clinical Algorithm Work for Every Patient Group? Three Ways to Check

A single accuracy figure can hide a group the tool serves poorly. Three checks, done in order, keep a clinical algorithm honest across the people it will actually see.

Fully reviewed by Jasaman (Jasmin) Tojjar, MD, PhD

On this page
  1. Key points
  2. "Accurate" and "fair" are not the same claim
  3. Where uneven performance comes from
  4. Check one: does the training data match your patients?
  5. Check two: read the metrics group by group
  6. Check three: keep watching after launch

To check that a clinical algorithm works for every patient group it will be used on, run three checks in order: confirm the data it learned from resembles the patients it will meet, measure how it performs inside each group rather than on average alone, and keep watching those per-group numbers after it goes live. A tool can post an impressive overall score and still serve a subset of patients poorly, because one headline figure blends the strong cases and the weak cases into a single reassuring number. Fairness work is the habit of refusing to trust that blended number on its own.

None of this comes from anyone deciding to build a worse tool for older adults, for women, or for patients whose records are thin. Uneven performance arrives through ordinary, fixable mechanisms. Naming those mechanisms is the first step to catching them.

Key points#

"Accurate" and "fair" are not the same claim#

An accurate model gets most predictions right across everyone it sees. A fair model does something narrower and harder: it delivers comparable performance and comparable benefit across the groups it is meant to help, so that belonging to a group does not silently change the care a person gets. Those are separate promises, and the first does not guarantee the second.

A model can reach a high overall score by excelling on the largest group while being merely adequate on smaller ones. The math rewards volume, so the biggest group dominates the summary statistic. The only way to see the smaller group clearly is to pull the numbers apart and look at each one on its own terms.

Where uneven performance comes from#

The most common root cause sits in the training data. A model can only become fluent in the kinds of patients it has seen many times. When a condition presents differently in a group that is thinly represented, the model's confidence there rests on less evidence. There is nothing malicious in this. The tool is simply better rehearsed on the patients who filled most of its examples.

A second cause hides in the labels. Many algorithms do not predict the thing clinicians actually care about, because that thing is hard to measure. They predict a stand-in for it. A well documented example, described in a 2019 Science study by Obermeyer and colleagues, is using prior healthcare spending as a proxy for how sick a patient is. Spending tracks access to care as much as illness, so a group that historically received less care can look healthier to the model than it truly is, and get flagged for help less often.

A third cause is measurement itself. Many reference ranges and cutoffs in medicine were established in narrow historical populations, and the relationship between two physiological signals does not always sit in the same place across groups. A threshold tuned mostly in one population may not transfer cleanly to another. When such a feature feeds an algorithm without adjustment, the unevenness is baked in before a single line of code runs. Each of these three causes is a property of the build, not of the people.

Check one: does the training data match your patients?#

Describe the training population before trusting the model. Lay out the distribution of age, sex, and any other axis along which care can plausibly differ, and set it beside the patients the tool will actually serve. The gaps between those two pictures are where trouble tends to live.

Representation is more than a headcount. A group can be present in the data yet sparse in the cases that matter most, such as rarer or more severe presentations, so read the data with the clinical question in hand. Where a group is genuinely thin, the honest move is to say so and to define the boundaries within which the tool has earned trust. A tool that is precise about who it was validated for is safer than one that claims, without evidence, to cover everyone.

Check two: read the metrics group by group#

Report the metrics that matter for each group, not only for the whole. For a model that flags disease, that means the miss rate and the false-alarm rate inside each group, placed side by side rather than collapsed into one figure. You are hunting for a group where the tool misses more, or alarms more, than the population overall, a pattern that the average is built to hide.

Two things keep this reading honest. First, statistics: small subgroups produce noisy estimates, so an alarming difference can be sampling noise, and a real gap can hide inside wide uncertainty. Show the uncertainty and resist firm conclusions drawn from a handful of cases. Second, definitions: several reasonable notions of "equal performance" exist, and they cannot all hold at once when a disease is more common in one group than another. Decide with your clinicians which notion matters most for the decision at hand.

Check three: keep watching after launch#

A model is fair on the day you validate it, and then the world keeps moving. Patient populations shift, referral patterns change, lab analyzers get replaced, and the data flowing into a deployed tool slowly stops matching the data it was built on. The subgroup metrics measured before launch are a baseline, not a certificate. Monitoring means recomputing those per-group numbers on live data and triggering a human review whenever a group drifts. A clear feedback channel helps too, because clinicians often sense a poor fit before the dashboards do.

None of this asks for heroics. It asks a team to break down what it already measures, to be candid about who the evidence covers, and to keep looking after go-live. Done in good faith, fairness work is just what careful engineering looks like when every group in the data is treated as real patients.

Sources and further reading

  1. Obermeyer et al. 2019 Science, racial bias in a widely used health algorithm

Questions and answers

Can a very accurate algorithm still be unfair?

Yes. High overall accuracy can be driven almost entirely by the largest group while a smaller group is served poorly. Overall accuracy and per-group performance are different measurements, and only the second reveals the gap.

What is a proxy label, and why does it cause bias?

A proxy label is a measurable stand-in for the thing you actually care about, used because the real target is hard to capture. If the proxy reflects something other than the clinical need, such as prior spending standing in for illness, the model can systematically under-serve groups that the proxy misrepresents.

Is a one-time validation enough?

No. Populations and data sources drift over time, so a tool that was fair at validation can degrade. Per-group metrics should be recomputed on live data, with a human review when any group moves out of range.