An Introduction to Savannah Informatics Engineering Blog

Nobody writes about the referral that went through cleanly, the claim that was processed in seconds or the patient record that followed someone seamlessly from a clinic in Kisumu to a specialist in Nairobi. Most of the time, people say, “That’s just the system doing its job.”

We write about it here because building that invisibility is genuinely hard and the gap between "it worked in staging" and "it works for 20 million people" is where most of the interesting engineering lives.

Who we are

Savannah Informatics builds the infrastructure layer of Kenyan healthcare.

The kind that other systems depend on a National Health Information Exchange, patient referral networks, claims processing pipelines, integrations across providers and insurers who found it hard to talk to each other with ease. We sit at connection points that most people never see: between a rural clinic and a national hospital, between a patient and their insurer, between a lab result generated today and a clinical decision made tomorrow.

When our systems have a bad day, someone somewhere has a worse one. That's not a motivational poster. It's just the shape of the job.

The problems we're actually solving

Healthcare interoperability sounds clean on a slide. In practice, it means negotiating with systems built on different assumptions, different data models and different definitions of what a "patient" even is. It means building on standards like FHIR while absorbing the places where standards meet reality and quietly lose.

It means designing for availability in environments where connectivity is not guaranteed, where a dropped request is not only a UX problem and where data consistency matters in ways that most distributed systems literature doesn't fully prepare you for.

Our constraints are real: latency budgets that affect clinical decisions, integration surfaces that span legacy systems and modern APIs and infrastructure that has to be both affordable and resilient. We don't get to choose between those. We have to build for all of them at once.

This forces a kind of engineering clarity that we've come to value. When the trade-offs are consequential, you stop debating abstractions and start making decisions. What we lose in theoretical purity, we gain in hard-won operational judgment.

What this blog is

We think out loud here.

That means writing about distributed systems and data interoperability but also about the on-call rotations that taught us something, the incident retrospectives that changed how we build and the architectural decisions that didn't survive contact with reality.

We won't always get it right. Some of what we publish will be questions we're still working through. Some will be things we built, used and found gaps and later rebuilt better. We'd rather write that honestly than wait until everything is resolved and polished and safe to say.

Expect systems thinking, how we design for reliability, scale and interoperability across a complex, fragmented healthcare ecosystem and the patterns that hold versus the ones that don't. Expect real trade-offs laid bare: consistency vs. latency, speed vs. correctness, build vs. buy, with the assumptions shown and the second-guessing included. Expect writing about engineering culture how we run on-call, how we think about ownership, what technical debt actually costs in a domain where shortcuts have consequences. And expect the frontier problems Kenya's healthcare system is facing in real time, which means we're not always following a playbook. Sometimes we're writing one.

Who this is for

You'll know this blog is for you if you've ever had to make a system decision where being wrong had a human cost. If you work on complex infrastructure in high-stakes environments, healthcare or otherwise, you'll find things here worth sitting with.

If you're navigating the specific weight of building for the African healthcare context, the infrastructure constraints, the fragmented data ecosystems and the tension between global standards and local reality, you're exactly who we had in mind when we started writing.

And if you're early in your career, trying to understand what serious, consequential engineering actually looks like beneath the surface, this is an honest account of that. Not the highlight reel. The actual work.

Why we do this

We write because the problems we're working on deserve more documentation than they currently have. Healthcare infrastructure in emerging markets is under-discussed in mainstream engineering literature, not because the problems are less interesting, but because the teams solving them are often too busy solving them to write. We want to change that ratio, even slightly.

We also write because clarity of thought is a discipline. Explaining what you built and why to someone who wasn't in the room forces a kind of rigour that internal documentation rarely achieves. This blog makes us better engineers, not just better communicators.

If it's useful to you too, that's the point.

We're building healthcare infrastructure for a country of 55 million people, with a team that moves fast, takes ownership seriously and believes the best engineering is driven by empathy for the people the system ultimately serves.

That's the work. This is where we tell it.

Welcome.