DHIS2 in monitoring and evaluation

What DHIS2 is — and what it is not

DHIS2 (District Health Information Software 2) is an open-source platform for collecting, managing, analysing and presenting routine data, developed and maintained by the Health Information Systems Programme (HISP) at the University of Oslo and released as a global public good [1]. Its anchor deployments are national: ministries of health run it as the backbone of their health management information systems (HMIS), Kenya’s among them, and its reach has extended beyond health into education, logistics and emergency response [1].

The distinction that matters for an M&E practitioner is between the platform and the system. DHIS2 ships as configurable software; what a country actually operates is a configuration — a specific hierarchy of reporting units, a dictionary of data elements, a calendar of data sets, a library of indicators. Two countries running the same DHIS2 version can have entirely different systems, and the quality of a national instance is mostly the quality of its configuration governance, not of its code. This is the general lesson of M&E information systems made concrete: the metadata is the system.

The data model in one pass

Five concepts carry almost everything:

Core DHIS2 concepts and their M&E meaning

Concept	What it is	What it means for M&E
Organisation unit	A node in the reporting hierarchy (facility, ward, county, nation)	The geographic and administrative frame for every number; your programme sites must map onto it
Data element	The atomic thing counted (e.g. confirmed malaria cases treated)	The definitional layer — read its description before trusting any figure built on it
Data set	A group of data elements reported together on one schedule by one org-unit level	The unit of reporting discipline; completeness and timeliness are measured per data set
Indicator	A calculated value — numerator and denominator drawn from data elements	Definitions live here; a renamed or re-based indicator silently breaks trend analysis
Tracker	Individual-level records of persons or cases followed over time	Longitudinal analysis becomes possible — and so do privacy obligations aggregate data never carried

The platform’s heritage is the first four rows: aggregate counts, reported monthly or quarterly, climbing an administrative pyramid from facility to district to nation. Tracker — individual-level, event-based data — is a later addition, and treating tracker data with aggregate habits (or the reverse) is a recurring source of analytic error. Aggregate data answer “how many, where, when”; they cannot answer “who returned, who was lost to follow-up” — questions that need individual records and correspondingly stronger data protection.

Where programme M&E meets the national instance

A programme operating in a DHIS2 country has three legitimate relationships with the national system, and one illegitimate temptation.

Read from it. National HMIS data supply baselines, denominators, comparison series and context that no programme survey can match for length and coverage. Before commissioning primary collection, check whether the indicator — or a defensible proxy — already flows monthly through the national instance. Long routine series from an HMIS are also the raw material for interrupted time series analysis when a programme or policy starts at a known date.

Report into it. Where a programme delivers services that the national data sets already count, the defensible posture is to strengthen facility reporting into the national system and draw programme figures out of it, rather than extracting a private copy at the point of care.

Exchange with it. Where a programme genuinely needs its own system — different indicators, different cadence, non-health content — the requirement is an interface, not a wall: import and export against the national organisation-unit list, and exchange through the platform’s web API. In the OpenHIE architecture this is the general pattern: shared registries hold the master lists, point systems exchange through documented interfaces rather than accumulating incompatible copies [3].

The temptation is the fourth pattern: the standalone project system that neither reads, reports nor exchanges. It is usually born of a donor deadline and it strands its data the day the project closes — while doubling the reporting burden on the same facility staff who feed the national system.

Data quality in DHIS2 practice

DHIS2 makes two quality metrics visible by construction: reporting completeness (what share of expected reports for a data set actually arrived) and timeliness (what share arrived by the deadline). Any analysis built on a DHIS2 series should state both, for the period and units analysed — a rising indicator over a period of rising completeness is often measuring reporting, not epidemiology.

Beyond those built-in metrics, the assessment machinery is the same as for any routine system, and the tools were designed with platforms like DHIS2 in view. The WHO Data Quality Review framework structures the desk review — completeness, timeliness, internal consistency (outliers, consistency over time, consistency between related indicators) and external consistency against surveys [2]. The RDQA tool supplies the complementary field discipline: tracing a sample of reported figures back through the register and tally sheets that generated them [4]. The general method, and when to deploy which instrument, is covered in data quality assessment.

Two DHIS2-specific failure patterns deserve their own flags:

• Denominator drift. Facility-level coverage indicators divide by catchment-population estimates that are themselves projections. A coverage figure above 100% is not a data-entry joke; it is the denominator telling you it is wrong.
• Metadata churn. When a data element is redefined, split or re-mapped mid-series, the stored history does not announce it. Trend analysis across a configuration change needs the configuration’s change history, not just the numbers.

Integration patterns that work

In rough order of increasing engineering effort:

1. Manual export–import on a fixed calendar — adequate for quarterly aggregate exchange, fragile for anything faster.
2. Scheduled API exchange — the platform exposes its data and metadata through a web API; the recurring work is not the plumbing but the mapping, keeping the external system’s site list and indicator definitions aligned with the national instance [1].
3. Architected exchange through an interoperability layer, with shared facility and terminology registries as the sources of truth — the OpenHIE pattern, appropriate at the scale where several systems must agree [3].

Whichever pattern applies, the master-list rule from M&E information systems is the load-bearing wall: if two systems disagree on what a facility is called or which ward it sits in, no interface can join their data honestly.

Honest limits

DHIS2 rewards realism about three things. First, its aggregate-first heritage: the platform is exceptional at routine aggregate flows, and correspondingly awkward when pushed to be a survey engine, a case-management system or an evaluation database — jobs its data model was not shaped for. Second, configuration governance: because anyone with the right role can add data elements, unmanaged instances accumulate thousands of overlapping, half-abandoned elements, and the cleanup is institutional work, not technical work. Third, capacity dependence: a national instance is sustained by the people who administer, configure and use it, which is why the HISP model pairs the software with regional capacity-building networks rather than shipping code alone [1]. An organisation deciding whether to lean on DHIS2, exchange with it, or run something of its own is making the build-adopt-configure decision — and should make it with the total-cost honesty that decision demands.