DHIS2 in Nepal
Why DHIS2 fits Nepal
The 2011 migration was a good decision and remains one.1 DHIS2 was designed for exactly Nepal's constraints: an administrative hierarchy that maps onto organisation units, periodic reporting from facilities with uneven connectivity, and a need for analysis at multiple levels of government from a single dataset.
It also brought something less visible but more valuable: a metadata discipline. Data elements, category combinations, data sets and validation rules are defined centrally and versioned. That is the beginning of data governance whether or not anyone calls it that.
Aggregate and tracker are different jobs
This distinction causes more implementation pain than any other, so it is worth stating plainly.
Aggregate data is counts for a period and an organisation unit — "BCG doses given, this health post, this month". It is what routine HMIS reporting needs. It is cheap to transmit, robust to poor connectivity, and cannot answer any question about an individual.
Tracker data is individual-level: a person enrolled in a programme, moving through stages over time. It supports continuity of care, follow-up and cohort analysis. It costs more — in bandwidth, in training, in data quality effort, and in the discipline required at the point of entry.
Both models can coexist in one instance, and tracker data can aggregate into the same analytics tables. What does not work is treating tracker as a cheap EHR, or building aggregate reporting and describing it as individual-level capability.
The operational reality of tracker work — enrolment, master register, recording order, and why the order matters for monthly counts — is documented in the eRecord user operations manual.
Where implementations actually go wrong
Metadata design. Data elements and category combinations are extremely expensive to change once data exists. The cost of a rushed design is paid every month afterwards. See metadata design principles.
Organisation unit hierarchy. It must match how the health system is actually administered. After federal restructuring, hierarchies that encoded the previous arrangement required careful migration, and analyses spanning the change need documented breaks.
Analytics scheduling. Analytics tables are generated by a scheduled job. Data entered after the last run does not appear in dashboards until it runs again. A large share of "the system is wrong" reports are this.
Validation without follow-up. Validation rules that nobody acts on are decoration. The rule needs an owner and a response process.
Training treated as an event. Tracker especially rewards ongoing support over a one-off workshop, because the failure modes appear weeks later.
DHIS2 and interoperability
DHIS2 exposes a comprehensive REST API, and that is how most integration in Nepal is built today. Two cautions.
First, an API is not an architecture. Point-to-point integrations against the DHIS2 API grow the same n² problem as any other bilateral integration. The interoperability layer exists to stop that.
Second, DHIS2's data model is not FHIR's. Aggregate data elements do not map
cleanly onto FHIR resources, and forcing them to produces resources that are
technically valid and semantically confusing. The useful mapping is usually at
the tracker level — a tracked entity to a Patient, a programme stage event to
an Encounter or Observation — mediated by an integration engine rather than
performed inside either system.
In an OpenHIE-shaped architecture, DHIS2 sits in the HMIS and analytics role, consuming registry data rather than owning identity. That is the right place for it.
What Nepal should do next
DHIS2 in Nepal does not need replacing. It needs three things around it.
A facility registry it resolves against, rather than owning. Today the organisation unit hierarchy is, in practice, the facility list. That works until another system needs the same list, at which point the hierarchy — designed for reporting rollup — is asked to be a registry, which it is not.
A clear boundary with clinical systems. Publish, nationally, what belongs in DHIS2 and what belongs in an EMR. Without that line, every province solves it differently and the estate diverges.
Mapping maintained as a product. DHIS2-to-FHIR mapping is not a migration task that finishes. It is a maintained artefact with versions, tests and an owner. Projects that treat it as one-off work discover the drift about eighteen months later.
Where to go next
- Health information systems in Nepal
- HL7 FHIR in Nepal
- A reference architecture
- Case study: DHIS2 and health information systems in Nepal — the localisation, calendar and register work in practice
- Background: DHIS2 in the knowledge base
Sources
- Paudel S, Paudel D, Boucher F. Digital Health in Nepal: A Perspective on Overcoming Challenges and Leveraging Opportunities. Kathmandu University Medical Journal. 2025; 91(3): 386–91. PDF
- DHIS2. Documentation. docs.dhis2.org
- Nepal HMIS — hmis.gov.np
- Government of Nepal, Department of Health Services, Management Division. DHIS2 Software Operational Guideline, Nepal.