We’ve been connecting POC HIV diagnostic devices across seven sub-Saharan African countries — more than 2,000 devices in production, results delivered daily into segregated national health information systems.

A few of those lessons keep showing up. Here are the ones we think generalize beyond a single program.

1. Store-and-forward over GSM is the foundation, not an afterthought

The instinct in most connectivity projects is to design for the happy path — the network is up, the result transmits, the dashboard updates. Then you handle exceptions. In a national-scale POC program, the unhappy path is the path. Mobile networks drop. Cellular coverage flickers across rural districts. Devices sit in clinics that lose power for hours. If your system depends on a live network connection to function, you’ve already lost.

We learned to design for offline-first transmission with reliable store-and-forward, where the device captures the result locally, holds it through whatever happens next, and pushes it to the cloud when the network reappears. From the program manager’s perspective, results show up reliably. From the device’s perspective, connectivity is opportunistic, not assumed. The architecture has to work that way from the start — bolting it on later breaks more than it fixes.

2. Segregated national instances aren’t a workaround. They’re correct architecture.

There’s a temptation, when you’re building a multi-country platform, to centralize everything. One database. One dashboard. One source of truth across all programs. It’s cleaner. It scales better. It’s also wrong for this domain.

Health data has to live where it has to live. National data sovereignty isn’t a procurement concern that can be argued away — it’s a legal and political reality. Segregated national instances — each governed by that country’s data rules, with shared operational learning across instances at the platform level — is the right architecture for this work. Programs trust it because their data isn’t moving across borders. And when a country needs its instance deployed in-country, the architecture supports that from the start.

3. One remote firmware update is worth ten on-site visits

When a national program runs hundreds of devices across remote facilities, every on-site visit is expensive — flights, drivers, time, cost of the engineer. The math on that gets ugly fast. A single firmware update that has to be pushed by hand to 200 devices across seven countries is a small project unto itself.

Building remote configuration and firmware push into the connectivity layer — not as an option, as table stakes — is the difference between a manageable platform and one that can’t keep up with itself. By the time we’d connected our second country, we couldn’t imagine doing this work without it. By the seventh, it had quietly saved an enormous amount of money no one would ever line-item.

4. Consumables visibility changes program economics more than results visibility does

Every connectivity vendor we’ve seen leads with results — “your test results, in your dashboard, in real time.” That’s important. But it’s not where the program manager loses the most sleep.

What changes the operational picture is knowing, three weeks ahead, that a clinic in a particular district will run out of test cartridges. Or that a particular site has been running tests at half its capacity for two weeks because supply got delayed. Or that a region’s consumption patterns have shifted in a way that supply chain hasn’t adapted to. Consumables visibility — captured device-side, transmitted alongside results — turns supply chain from a reactive scramble into a forecastable system. Result data is the headline. Consumables data is the program economics.

5. The whole-stack matters

The single biggest lesson, threading through all four above, is that diagnostic connectivity at scale isn’t a software problem. It isn’t a hardware problem either. It’s an integration of hardware, cellular networking, cloud platform, and operational discipline — and each of those parts is where most projects fail because the project owner thought they only had to handle one of them.

When we started, we thought of ourselves as building a digital health platform. Three years in, we’d ended up running a connectivity hardware program, a SIM operations operation, a cloud data platform, and an integration practice — all at once, all for the same set of devices. That’s the actual shape of the work. We’ve stopped pretending otherwise.

Why this matters for what comes next

The standardized ConneX platform is built on these lessons, not despite them. Store-and-forward, consumables tracking, remote firmware management, segregated multi-tenant deployments, the integration of hardware and software as a single system — all of it traces back to what 2,000 devices across seven countries taught us about what diagnostic connectivity actually is.

If you’re building, buying, or running anything similar, we’d rather have the conversation now than two years in.

Working through the same problems? Talk to us