Skip to content
The AI-First Web

Data Has a Shelf Life, and Other Things Medicine Knows That AI Keeps Relearning

Machine learning didn't create the bias problem. It industrialized a very old one. Clinical research spent a century wrestling with it — and left notes.

K
Kannan SP
· 6 min read
Share on X LinkedIn
Data Has a Shelf Life, and Other Things Medicine Knows That AI Keeps Relearning

There's a comforting story in which algorithmic bias is a new problem, invented alongside deep learning, waiting for a new generation of tools to solve it. Clinical researchers know better. Randomized trials exist precisely because researchers spent a century wrestling with bias — designing prospective experiments to eliminate it as fully as possible, then reckoning honestly with the biases that flood back in the moment you rely on observational studies and case reports, which limited trials force you to do. Machine learning didn't create the bias problem. It industrialized a very old one.

That perspective — bias as an old, familiar adversary rather than a novel glitch — turns out to be full of practical wisdom that AI teams keep rediscovering the hard way. Here are the pieces of it I find myself repeating most.

The two questions that decide everything

All of the classical discipline compresses into two questions. <strong>Is the sample representative?</strong> — does your data actually contain all the conditions at play for the population you'll serve? And <strong>are you asking the right question?</strong> — because a technically flawless answer to a subtly wrong question is the most dangerous artifact in analytics; it arrives wearing the costume of rigor. Trialists have known forever that a badly posed question yields a beautifully precise, badly biased answer. The powerful new machinery doesn't blunt that truth; it sharpens it, because the machinery now answers <em>any</em> question, wrong ones included, with equal confidence.

Two corollaries deserve more air time than they get.

<strong>Repurposed data is a horror-story genre.</strong> Data collected for one specific use, pressed into service for another, produces bad — and sometimes actively harmful, disparity-widening — results. Billing data moonlighting as clinical ground truth is the classic. The collection context is part of the data, and it doesn't transfer.

<strong>Data has a shelf life.</strong> The dataset that honestly represented your world at training time quietly stops representing it: care practices change, populations shift, new treatments arrive. The model didn't break; the world moved. Which means validation can't be an event — it has to be a standing process of <em>challenging the data</em>, checking that it still delivers what you need. At scale, those checks are beyond any individual clinician's capacity; they're a systems responsibility, and mostly a missing one.

Stress-test with the rare case

Here's the sharpest tactic in the old playbook. Suppose you've built a tool recommending optimal treatment for low back pain, trained conscientiously on data reflecting the patients you serve. Now challenge it with the rare case: the patient whose back pain is caused by an undiagnosed tumor. Does your pathway efficiently usher them toward physical therapy while the tumor goes undetected?

Extreme example? Absolutely — and that's the point. <strong>Rare examples are exactly what you must always be aware of.</strong> Average-case performance is what benchmarks measure; rare-case behavior is where patients are harmed. In medicine — and in any consequential domain — a system is characterized by its exceptions.

The organizational corollary: rare cases are invisible to homogeneous teams. Hand that back-pain tool only to orthopedists and physical therapists to evaluate, and you'll get one set of answers — and an algorithm that can't serve the exceptional cases. It takes an oncologist in the room asking <em>"what about my patient?"</em> to surface the failure mode. Maximum breadth of intellectual input, at design time, isn't inclusion theater. It's how you find the holes before your users fall into them. There's a name for the failure of skipping this: searching under the lamp post — recruiting whoever happens to be standing in the light, and building blind spots into the foundation.

The most valuable person asks the "dumbest" questions

My favorite pattern in all of this concerns how outsiders succeed in a domain. Data science teams that come into medicine cold and thrive don't start by grabbing the biggest dataset and mining it. They sit down with the whole clinical operation — doctors, nurses, the administrators making the phone calls — and ask elementary questions. <em>How do you actually diagnose this disease? Which data elements are essential? What tests do you really run?</em> — working their way to the data from fundamental principles.

Two magical things happen. The outsiders learn what the data actually means — its collection context, its gaps, its politics. And the <em>insiders</em> learn something too: fresh eyes expose the ways clinical thinking has been silently shaped and skewed by how everyone was trained. Again and again, a "naive" question is met with a puzzled stare, then a pause, then: <em>"...what a great question."</em> The askers of tremendous numbers of questions are the mechanism by which a field discovers its own assumptions. If you're a technologist entering someone else's domain: your ignorance, deployed humbly and relentlessly, is a research instrument. Don't skip past it — it's the most valuable thing you'll ever bring, and it only works once.

On de-skilling: we've been here before

The fear that AI will atrophy professionals' skills deserves honest handling, and history is the honest handler. A physician of an earlier era personally ran the microscopy to identify the organism causing a pneumonia. Ask a modern clinician to do that stain by hand and the answer is no — the skill migrated into the lab, and what the clinician retained is the part that matters: knowing what the result means and how to act on it. Nobody calls that de-skilling. It's the ordinary evolution of every technology: skills don't vanish, they <em>migrate up</em> the stack, from performing the measurement to interpreting it. The same migration is coming with AI, and resisting it wholesale is as pointless as mourning the hand-stained slide.

But the history carries a warning along with the comfort: the migration goes well only when the profession <em>shapes the tools it will depend on</em>. Instruments built without the people who must trust them become instruments that don't fit the work — and at today's pace of change, there's no decade of slack to fix them after the fact. Build them together, or they won't do what we need.

Old lessons, every one. The field that spent a hundred years learning them is offering us the notes. We should be humble enough to read them.

Share this insight