When I started building a machine learning framework to predict neonatal mortality risk in Nigerian hospitals, I assumed the hardest part would be the model, choosing the right algorithm, tuning the parameters, improving accuracy.
It wasn’t. The hardest part was the data. Specifically, what wasn’t there.

The problem nobody talks about
Nigeria has one of the highest neonatal mortality rates in the world. The 2023–24 National Demographic and Health Survey places it at 41 deaths per 1,000 live births, a figure that has barely moved since 2018. Newborns die in their first 28 days of life at rates that would be considered a crisis anywhere in the Global North. The tools to predict and prevent those deaths exist, machine learning models can identify at-risk infants early, flag resource needs, support overburdened clinicians. The technology isn’t the bottleneck.
The data is.
Global health AI is built, overwhelmingly, on datasets from high-income countries. The models that get cited, replicated, and deployed were trained on patient populations that look nothing like a newborn in a Nigerian district hospital. The clinical features recorded, the risk factors captured, the very structure of the data, all of it reflects a different context.
When you try to apply those models in Nigeria, they don’t just underperform. They fail in ways that are hard to see unless you’re looking.

What I found
I used the 2023–24 Nigeria Demographic and Health Survey, the most current national health dataset available, because routine clinical records in Nigerian hospitals are too inconsistent to build a model on. That itself is the first data gap: the infrastructure for collecting structured patient data at the point of care largely doesn’t exist.
Working with that data, I compared five classification algorithms. Random Forest performed best, with an AUC-ROC of 0.89. The three strongest predictors of neonatal mortality weren’t complex clinical biomarkers — they were whether a skilled health worker attended the birth, the spacing between pregnancies, and the number of antenatal visits. Structural factors. Things shaped by the health system, not just the individual.
The process forced decisions that no model card would ever document: what to do when variables that matter clinically simply weren’t recorded. How to handle missingness that isn’t random, it’s systematic. How to build something useful when the infrastructure that generated the data was itself under-resourced.

The argument
This isn’t a technical problem with a technical solution. It’s a structural one.
The reason African health data is sparse, inconsistent, and underrepresented in global AI benchmarks isn’t because the data is hard to collect. It’s because for decades, the people building the infrastructure, the standards, the systems, the incentives, weren’t building it with African health systems in mind.
AI doesn’t fail Africa by accident. It fails because the people who built it never had to account for it.
That changes when African researchers stop waiting for the data to get better and start building frameworks that work with what exists, missing values, inconsistencies, and all. It also changes when the global AI community stops treating African datasets as edge cases and starts treating them as a test of whether their models actually generalise.

Why this matters beyond Nigeria
Neonatal mortality is one data point. The same dynamic plays out across maternal care, mental health, infectious disease, chronic conditions. Wherever global health AI has been deployed in African contexts, the same question applies: was this model ever tested on people who look like the patients it’s meant to serve?
Usually, the answer is no.
I built one framework for one context. It’s not a solution, it’s a proof of concept and a provocation. The question it raises is bigger than any single model: what would global health AI look like if African populations were at the centre of it from the start, not retrofitted in at the end?
I don’t have a complete answer. But I know where to start: with the data, and with the people closest to it.

Why structure, not tools, determines whether data creates insight

Operational data is often described as abundant. In practice, it is frequently unusable. Many organisations collect large amounts of operational information: requests, timestamps, updates, and records of activity. Yet when simple questions such as where delays occur or how long tasks typically take are asked, the data fails to provide clear answers.

This is not because the data is missing. It is because it was never designed to be used.

Operational data is usually generated as a by-product of work, not as a deliberate input into decision-making. Messages arrive, spreadsheets grow, and records accumulate without shared rules for how information should be captured or updated. Without consistency, analysis becomes unreliable. Two entries that describe the same event may use different formats, labels, or timelines, making comparison difficult or meaningless.

For operational data to support analysis, it must be predictable. This requires:

• defined fields captured every time
• clear status stages that reflect real progress
• timestamps tied to specific transitions

These elements do not require advanced tooling. They require agreement and discipline in how work is recorded.

Rather than analysing data retrospectively, it is often more effective to design workflows that generate usable data by default. Structured intake forms replace free-text requests. Status changes replace informal updates. Centralised records replace scattered messages. When workflows are designed this way, data quality improves naturally, without adding reporting overhead.

Once operational data is consistent, even simple analysis becomes valuable. Trends around volume, turnaround time, and bottlenecks emerge quickly. Teams can prioritise work more effectively and identify where processes need adjustment.

At this stage, the data begins to serve its purpose: supporting decisions rather than documenting activity.

Operational data becomes useful when it is intentional. Without structure, data remains noise. With structure, everyday activity becomes insight.

Many small businesses start the same way: messages on WhatsApp, emails going back and forth, notes written in different places. At first, it works. As requests increase, things get missed, follow-ups slip, and tracking becomes stressful. This is usually the point where people assume they need a complex tool or a full software rebuild. In reality, most early problems come from a lack of structure, not a lack of technology.

The real issue: unstructured workflows

When requests arrive through multiple channels, there’s no single source of truth. You can’t easily see:

• what has been received
• what is pending
• who is responsible
• what has been completed

The result is manual checking, repeated questions, and avoidable delays.

A simpler approach

Instead of building something heavy, I focused on designing a clear workflow:

1. Capture requests through a structured form
2. Centralise entries in a single sheet
3. Use status fields to track progress
4. Assign responsibility explicitly
5. Keep the system easy to adjust as needs change

This approach keeps the process transparent and reduces the mental load of “remembering” what to do next.

Why lightweight systems work

Simple tools have advantages:

• they are quick to set up
• teams understand them immediately
• changes don’t require redevelopment
• data stays visible and auditable

Most importantly, they create clarity. Once the workflow is clear, automation becomes optional rather than urgent.

Finally, digital transformation doesn’t have to start with complex software. In many cases, it starts with asking one question: “What information do we need at each step, and where should it live?”

Designing around that question often delivers more impact than adding new tools.

One of the easiest ways to improve a tool or process is to start by organising the data behind it. A clean table with consistent fields can reduce errors and make it easier to automate small steps. This is true for booking systems, dashboards, tracking tools and even basic customer records.

Good structure also makes information easier to understand. When data is clean, you can spot trends, compare results and make decisions faster. It doesn’t require complex algorithms — just a clear layout and a reliable way to collect information.

Many teams overlook how important simple data practices are. Before building something new, it often helps to focus on how information enters the system, how it’s stored and how it flows from one step to another. Small improvements at this level usually lead to smoother tools and better outcomes.

Digital systems don’t need to be complicated to be effective. With organised data at the core, even basic tools can become more dependable and easier to use for both teams and clients.

Healthcare systems can sometimes feel complicated, but many improvements come from simple digital tools rather than large, advanced solutions. Over time, I’ve seen how basic organisation and workflow systems make everyday tasks easier for staff and more reliable for patients.

One helpful change is the use of clear dashboards. They don’t need to be complex. A single place that displays appointments, tasks or follow-ups reduces confusion and saves time for the people managing daily activities.

Simple automations also make a big difference. Many healthcare teams still rely on notes, scattered spreadsheets or manual tracking. Small tools like structured forms, reminders or organised data entry can reduce repeated work and improve communication.

When information is organised properly, patterns become easier to notice. Teams can understand delays, plan better and make more informed decisions without spending hours reviewing different files.

Digital change in healthcare doesn’t always require big systems. Sometimes the most effective improvements come from small, practical tools that bring clarity, reduce workload and support better decision-making for both staff and patients.