Beyond the Defaults: Rethinking Health Information System design in Africa
Across much of Africa, DHIS2 has become the de facto standard for health data management, used
for everything from
routine monthly reporting of health information system data to national disease surveillance.
Its ubiquity is no accident;
it offers an open-source solution, backed by global support, with a low barrier to adoption.
But ubiquity is not always synonymous with fitness. In the field, time and again it has been
observed how reliance on DHIS2 comes with trade-offs,
especially in limited real-time capabilities and rigidity in adapting to the
nuances of different health systems.
Ironically, the very countries deploying DHIS2 at scale are also home to bright, capable
developers, who, with the right investment and vision,
could craft bespoke, modern
platforms tailored to local needs.
Why aren't we building more? Why aren't we iterating on what we have learned? Perhaps
it's time we start.
The Dominance of DHIS2
Over the past two decades, DHIS2 has steadily become the go-to platform for health information
management across Africa.
From monthly facility reports and logistics data to aggregated disease statistics, ministries of
health in dozens of
countries rely on it as their national data backbone.
Its appeal lies in practicality; it is open-source, backed by global development partners, and
adaptable to many use
cases. For countries working with constrained budgets and complex health systems, it becomes the logical
choice. In many ways,
it has brought structure where there was once fragmentation.
But with widespread adoption comes inertia. As DHIS2 becomes synonymous with “health system
digitalization”, it often
eclipses more tailored or innovative approaches. The default becomes the standard, not because it is
the best fit in
every case, but because it offers the most familiarity.
Illusion of Free
Part of DHIS2’s appeal is its cost, or rather, the absence of one. As an open-source platform, it presents no licensing fees, and many countries already have teams trained in its administration through donor-supported workshops and regional hubs. On the surface, this is the fiscally responsible choice. Why build a new system when DHIS2 can be extended or reconfigured? Why hire a developer when your district health officers already know how to enter data into DHIS2 forms? But this calculation often overlooks deeper trade-offs. “Free” software isn't free if it limits responsiveness or requires constant workarounds. The cost of patching, customizing, and supplementing the platform, especially during emergencies (see Go.Data and ODK) can quickly rival the investment needed for bespoke systems. And the opportunity cost of not investing in local software innovation is rarely factored in.
An Untapped Resource: Local Talent
In nearly every country where DHIS2 has taken root, there exists a capable pool of local
developers, many
with degrees in computer science, informatics, or software engineering. These professionals are
often underutilized when
it comes to national-scale systems. Instead of being asked to architect, optimize, or rethink health
information flows,
they're often limited to DHIS2 configuration or user support roles.
This is not due to a lack of skill, but a lack of vision.
While DHIS2 has played a foundational role in standardizing data reporting across health systems,
its widespread
adoption has also led to creative stagnation. In many countries, the question is not “what
system fits our
needs best?” but rather “how do we fit our needs into DHIS2?” That reversal of logic can be
dangerous, especially when
the platform’s limitations begin to shape, rather than reflect, the country’s health priorities and technical
workflows.
Creativity in these contexts is often sidelined by the perception that building something new is
more costly, more complex, and harder to
justify than simply expanding DHIS2’s existing use. Ironically, this pursuit of cost-effectiveness
may end up increasing
technical debt, as stopgap solutions, parallel systems, and workaround scripts pile up in an
attempt to bend DHIS2 to
every use case.
A shift in mindset is needed: from defaulting to what is already in place, to exploring what
could be built with
the talent already on the ground. Whether modular tools for outbreak response, mobile-first
systems for frontline
workers, or dashboards that update in real-time rather than in 24-hour sync cycles, there is room
for solutions that
are not only possible, but necessary.
We don’t lack talent. We lack the confidence to imagine better systems.
Investing in these developers is not just about technology, it is about sovereignty, sustainability,
and
systems that
evolve alongside local realities.
A call to Rethink
The dominance of DHIS2 in the African health information ecosystem speaks to the continent’s desire for
cohesion and
cost-efficiency. But if we are to build systems that truly serve the dynamic and urgent needs of
public health, we must
be willing to expand the conversation.
This is not a call to discard what works, it is a call to complement it with homegrown innovation. To
trust the
developers, designers, and analysts within our borders. To build local solutions for local problems
that reflect
real-time realities and evolving needs.
Health information systems should not be rigid tools that dictate workflow. They should be living
ecosystems that are
adaptable, contextual, and human-centered. The future lies in hybrid systems that are nimble, interoperable
platforms, which can
respond faster, integrate better, and scale smarter.