Written By: Victor Nwaolise
When Data Meets Reality: What Building an AI Health Tool Taught Me
December taught me that building AI for healthcare is less about algorithms and more about people.
My team set out this month to develop a cardiovascular risk prediction model. The plan seemed straightforward: identify the data points we need, find datasets, train the model. Simple, right?
Reality arrived quickly.
The data wall
Our first lesson came within days. I assumed health datasets would be readily available, perhaps with a simple download or quick approval process. After all, this is the age of big data and open science. I was wrong.
Getting real-world health data isn’t just slow. It’s expensive, restricted, and wrapped in layers of approval processes. DHS registration took a week. WHO STEPS data requests are still pending. Teaching hospitals want formal partnerships before sharing anonymized records.
My initial frustration turned to understanding. These barriers exist for good reason. Every row in a health dataset represents a real person who trusted a health system with their most personal information. Data privacy isn’t bureaucracy. It’s respect.
This forced us to rethink our timeline and approach. We couldn’t wait weeks for perfect African datasets while learning nothing. So we started with publicly available data, built our pipeline, and prepared to adapt when better data arrived. Sometimes progress means working with what you have while pursuing what you need.
The clinical reality check
We drafted our initial list of data points: age, sex, blood pressure, glucose, cholesterol, smoking status, diabetes history, hypertension status, and medication use. Eleven variables that major cardiovascular risk models use. We felt confident.
Then we shared our list with a practicing physician.
His feedback was immediate and specific: You need the lipid profile breakdown. LDL, HDL, triglycerides. Total cholesterol alone isn’t enough for accurate risk stratification.
He was right. We’d relied on what was easiest to find in datasets, not what was clinically optimal. The distinction matters enormously.
But his contribution went beyond adding three variables. It shifted how we thought about the entire project. We weren’t just training a model to match benchmark accuracy scores. We were building a tool that real healthcare workers would use to make decisions about real patients.
Why collaboration isn’t optional
This experience crystallized something: As data scientists and health researchers, we can build technically impressive models. We can optimize algorithms and achieve high accuracy scores. But if we design in isolation, we’ll build the wrong thing beautifully.
The physician brought clinical judgment we didn’t have. He knew which biomarkers actually drive treatment decisions. He understood what’s feasible to measure in low-resource settings versus what only works in well-equipped labs. He asked questions about edge cases we hadn’t considered.
This is what design thinking demands. Not perfection from one expert, but integration of multiple perspectives. The technical expert, the clinical expert, the implementation expert, and ultimately the end user must all have voice in the process.
The path forward
We’re now pursuing a dual-model approach. A standard model using widely available datapoints, and an enhanced model incorporating the full lipid profile when available. This wasn’t our original plan. It emerged from honest conversation about constraints and possibilities.
December reminded me that innovation in global health isn’t about having the best individual idea. It’s about creating space where different forms of expertise can challenge and strengthen each other.
The data will eventually arrive. The model will eventually train. But the real foundation we built this month was learning to design with people, not just for them.