In 2015, a team supporting pediatric care across fourteen Kenyan hospitals published an account of how they built a working clinical data-management framework under conditions that would make most modern data stacks fall over: frequent power cuts, unreliable internet, no IT staff on site, no budget for software licenses, and no electronic health record to build on. The paper — Tuti et al., in JAMIA — is a detailed, honest field report of what it takes to produce trustworthy health data in the real world.
It’s worth revisiting now, because the AI wave has a way of making people forget the fundamentals. A large language model is only as good as the data it reasons over, and the principles that made data trustworthy a decade ago haven’t been superseded by better models — they’ve become the precondition for using those models at all. Four of them stand out.
1. Build inside existing workflows, not parallel to them
The most consequential design decision in that project was refusing to create a separate system. The data came from the same paper records clinicians already used, entered against the same national admission form and clinical guidelines the Ministry of Health already mandated. The framework was explicitly built to satisfy existing reporting requirements rather than bolt a research apparatus on the side.
This is the failure mode that kills most data initiatives, then and now. A shiny new system that runs parallel to how people actually work gets used for a quarter and then abandoned, because it’s extra work serving someone else’s goals. The AI era has made this worse, not better — it’s never been easier to stand up an impressive-looking parallel system that nobody feeds. The lesson holds with full force: if your data layer doesn’t live inside the workflow that already exists, the data will be an afterthought, and afterthought data is untrustworthy data.
2. Automate quality from metadata, not by hand
The technically striking part of the 2015 work was how they handled validation. Rather than hand-writing quality-control scripts and rewriting them every time the data collection tool changed, they pulled the tool’s metadata — the field names, types, structure, and validation rules — and used it to auto-generate the cleaning and reporting code. Change the tool, and the validation logic regenerated to match.
That instinct — the intelligence lives in a governed definition, and the system generates from it rather than improvising — is exactly the design principle that separates trustworthy AI systems from demos today. A modern retrieval system that lets a model compute answers freely is the hand-written-script approach: brittle, drifting out of sync, impossible to audit. A system that routes every question back to governed definitions and verified formulas is the metadata approach, a decade on. The technology changed; the principle didn’t. Generate from a source of truth; don’t improvise around it.
3. Make quality a layered process, not a single check
The framework didn’t trust any one gate. Validation happened as the clerk typed (soft warnings you could override, hard stops you couldn’t). Then a cleaning script ran at the end of each day. Then a second automated check ran centrally once data was collated across sites, producing a daily error report a supervisor used to give feedback. Then, every two months, a sample of records was independently re-entered and checked for agreement.
No single one of those catches everything. Together they make bad data progressively harder to sustain. This is the right mental model for data trust in any era: not a checkpoint you pass, but a series of nets at different grains, each catching what the last missed. Teams reaching for AI to “clean the data” often want a single magic gate. The durable answer is still layers — and AI is best used as one more net in the sequence, not a replacement for the others.
4. Anonymize and aggregate at the edge
Data left each hospital already anonymized, collated centrally only after site-level quality checks. Identifiable detail didn’t travel; the central store held what was needed for analysis and no more.
A decade ago this was a pragmatic response to security and connectivity constraints. Today it’s a design principle with a name and a strong rationale: keep identifiable data out of the systems that don’t need it, push aggregation to the edge, and let the central layer — including any AI layer — reason over findings rather than raw records. What was a constraint-driven workaround has become one of the most defensible ways to build, because the cheapest way to protect sensitive data is to never centralize it in the first place.
Why the old paper reads as prophecy
None of these principles were framed as future-proofing. They were what it took to make a hard problem work under real constraints. But constraints are clarifying — they force you to build only what’s essential and trustworthy, and essential-and-trustworthy ages well.
The AI era hasn’t made these ideas obsolete. It’s raised the stakes on getting them right, because a capable model layered over data that violates them will produce fluent, confident, wrong answers faster than any human ever could. Build inside the workflow. Generate quality from a governed source of truth. Layer your checks. Keep identifiable data at the edge. The tools have changed enormously since 2015. The reasons these principles work have not.
This is a field note from our practice. For the modern counterpart to principle two — how routing a model to verified definitions keeps its answers grounded — see Supervised RAG: grounding that holds up.