Data Quality for Clinical AI: Why the Model Is Only as Good as Its Data

A clinical AI is only as good as the data it learned from, and most of the data we feed these systems was never collected to teach a machine anything. It was collected to bill, to document a visit, to satisfy a form. Good clinical data for a model means the labels are true, the inputs are measured the same way they will be at the point of use, and the dataset looks like the patients the tool will actually meet. When any of those is wrong, the model can still post a beautiful score in the lab and fail quietly at the bedside, because the flaw lives in the data and the metrics were computed on that same data.

This piece is educational and not medical advice. Anyone making decisions about their own care should talk with their own clinician.

What does good clinical data actually look like?

Good clinical data is data whose meaning is stable: a value means the same thing every time it appears, the outcome it is paired with is correct, and the way it was captured matches the way it will be captured when the model runs for real. That is a short definition, and each clause hides a great deal of work.

A hospital record is one of the messiest data sources in any field, for good reasons. It is written under time pressure, by many hands, for human readers who fill the gaps with judgment, which is the difference between a record built for care and a dataset built for learning. The first move, then, is not to grab the biggest table and start training. It is to ask what each field was recorded for, by whom, and whether that purpose survives being turned into a feature.

Why is the label the most dangerous part of the dataset?

The label is the answer the model is trying to learn, and if the label is wrong, everything downstream is confidently wrong. A model trained to predict a diagnosis really learns to predict whatever the dataset called that diagnosis. A billing code is entered to get a visit paid, not to mark biological truth, so it can be present when the condition is mild and absent when it is obvious but coded elsewhere. A diagnosis from one visit may be a hypothesis the next visit overturned. Pull these as ground truth and you teach the model to imitate the coding process, shortcuts and all. There is a subtler trap too: if the outcome depends on who got tested, the model learns the habits of testing rather than the prevalence of disease, and looks most confident where clinicians already suspected something.

The repair is essential and unglamorous. Define the outcome carefully, check a sample of labels against a fuller source such as a chart review, and write down how often the label and the truth disagree. That disagreement rate is one of the most honest numbers a project can produce, and it is almost never in the paper.

How does data leakage make a model look better than it is?

Data leakage is when information that would not be available at the moment of the real decision sneaks into the training data, inflating performance in a way that vanishes on deployment. The classic form is a feature that is a consequence of the outcome rather than a predictor of it. A medication started only once a diagnosis is suspected becomes a near-perfect "predictor" of that diagnosis, because in the training data it appears almost only when the answer is already known. The model has not learned to anticipate the disease; it learned to read the treatment, which it will not have in advance when it matters.

Leakage is dangerous because it does not feel like an error. The pipeline runs, the held-out score is high, the demo is impressive. The only defense is to reconstruct, for every feature, the exact moment it becomes available in real care and forbid anything from later. I treat a suspiciously strong result as a reason to hunt for leakage, and most of the time the hunt finds something.

Why do quality problems stay hidden until deployment?

They hide because development and deployment draw from different worlds, and the metrics you compute during development cannot see the difference. Your test set is a slice of your training data, so it shares that data's flaws. A model and its evaluation can agree perfectly and both be wrong about the clinic.

A few mechanisms do most of the hiding. Training data is cleaned and curated, while live data arrives half-formed, with labs pending and fields blank, so a model that leaned on an archived variable meets a world where it is often missing. Measurement drifts between sites, as an assay calibrated one way reads differently elsewhere and the model treats that offset as signal. And the population shifts: a dataset built at a research-heavy center skews toward patients sick enough to be referred and well documented, while the community clinic where it deploys is healthier, earlier, and recorded more sparsely. Some of my own research has looked at how a physiological relationship can differ across groups rather than holding as one universal curve, and the lesson carries. Each of these is invisible on a held-out test set and obvious on day one of use.

Missingness is information, not just a gap to fill

In medicine, the fact that a value is missing often carries meaning, and that meaning rarely transfers. A test gets ordered because a clinician was already worried, so the presence of a result is itself a clue about the patient. A model can lean on that pattern, which works fine until it is deployed somewhere with different ordering habits, where the same blank means something else. Filling those gaps with a tidy average hides the problem rather than solving it. The honest path is to ask why a value is missing and whether that reason will hold at the point of use.

What does this look like when you build the thing?

It looks like spending more time on the data than on the model, which surprises people every time. When I co-developed EASY Diabetes, the decision-support system we put through the EASY-1 randomized controlled trial (NCT03258268), the algorithm was never the hard part. The hard part was making sure a value meant the same thing across sites that documented care differently, and that the inputs the system needed were in hand the moment a clinician needed an answer. The trial compared the system against standard of care, and the foundation under it was data work nobody sees in a results table. My medical device regulations training at KTH Royal Institute of Technology kept landing on the same point: define the data your tool depends on and show it will be there, measured the same way, in the setting where it is used.

One practical habit helps more than any tool. Before training anything, write a short data sheet for the dataset: where each variable comes from, when it becomes available, how the outcome was defined, and which patients are over or under-represented. Writing it surfaces half the problems, and the rest you find by looking, on purpose, where a good score would rather you did not.

None of this is a knock on the teams doing the work. Clinical data is hard because medicine is hard, and the people building these systems are mostly fighting the same messy records the rest of us are. Treating data quality as the real project, rather than a chore to clear before the interesting part, is what separates a model that demos well from one that helps a patient. The model is the easy half.