DHIS2 implementation: what health programmes should plan for before go-live

DHIS2 is a capable, open-source platform used by health programmes around the world. That is also why it is easy to underestimate: the software installs in an afternoon, and the project still takes months. The difficult parts are not technical. They are the decisions about what to collect, who collects it, under what conditions, and who keeps it running after launch.

We are an independent team with no HISP affiliation. Our team includes people who worked on Pakistan's National Electronic Immunization Registry and Sindh's Zindagi Mehfooz at IRD Pakistan, which is where most of the lessons below come from.

Start from the decisions, not the forms

Every data element should exist because someone will make a decision with it. Ask the programme managers what they need to decide each month — which areas are falling behind, which children are overdue, which facilities are out of stock — and work backwards to the indicators, then the data elements, then the forms. Programmes that start from existing paper forms tend to digitise their problems.

Aggregate or tracker?

Aggregate reporting counts things: doses given this month, cases seen. Tracker follows individuals over time: this child, these doses, this follow-up. Tracker is far more powerful — it is what lets an immunization programme move from counting doses to following children — and far more demanding on data entry, identification, privacy and hardware. Choose deliberately, and pilot before scaling.

Design for the field, not the office

• Connectivity. Assume the vaccinator or health worker will be offline. Plan Android capture that syncs later, and test sync conflicts.
• Time. Ask how long the shift is and how many people are seen. A form that adds two minutes per patient may be unworkable at scale.
• Identification. Decide how a person is found again: an ID, a QR card, a phone number, a combination. Then decide what happens when the card is lost.
• Devices. Battery life, screen size in sunlight, theft, replacement and who pays for data.

Accountability for the outputs

A defaulter list is only useful if someone is responsible for acting on it. For each dashboard and list, name who looks at it, how often, and what they are expected to do. Without that, a well-built system becomes an expensive report.

Training and supervision

Train with the real forms on the real devices in conditions close to the field. Train supervisors separately: they need to read dashboards, spot data-quality problems and support their teams. Plan refresher training and a route for questions after go-live, because staff turnover will undo the launch training within a year.

Hosting, security and backups

Health data needs a deliberate hosting decision: where the server lives, who administers it, how it is backed up and restored, how access is reviewed, and what happens during upgrades. Many programmes underestimate the operational load of running a production DHIS2 instance. See cloud hosting and IT infrastructure for the side of this we handle.

Integration

DHIS2 rarely works alone. Laboratory systems, logistics, national ID, SMS reminders and other registries all need to exchange data. Agree the identifiers and standards first, document every interface, and build monitoring so a broken integration is noticed in hours rather than months.

After go-live

1. A support model with named people and response times.
2. A data-quality routine: completeness, timeliness and outlier checks, reviewed monthly.
3. An upgrade plan, tested on a copy before production.
4. A budget line for all of the above beyond the launch year.

If you are planning, rescuing or extending an implementation, see our DHIS2 work and healthcare, or tell us about the programme.