Health Information Systems in Nepal

ExplainerBy RC Poudel, Co-Founder & CHIO, Aamako Maya Apps Pvt. Ltd.·Published 22 August 2026·11 min read

Quick answer

Nepal's health information estate is built around DHIS2-based HMIS reporting, which has carried national routine data since 2011. Around it sit logistics (eLMIS), civil registration, hospital EMR/EHR deployments piloted from 2014, disease surveillance and health insurance systems. Each works within its own boundary. The difficulty is at the seams — where a patient, a facility or a code has to mean the same thing in two systems.

Key takeaways

• The estate is not empty. Nepal has more than a decade of national platform operation.
• Aggregate reporting is mature; individual-level continuity across systems is not.
• Every system is defensible on its own terms; the gaps are between them.
• EMR/EHR variation is the largest source of integration cost.
• Data quality is produced at entry, and is a workflow problem before it is a technology problem.

The estate

HMIS on DHIS2

Routine health reporting migrated to DHIS2 in 2011.¹ It is the backbone: data sets, indicators, organisation unit hierarchy, validation rules, analytics tables, dashboards. It covers federal, provincial, local and facility levels.

What it does well: aggregate reporting at national scale, with a governance model for metadata and a mature analysis layer.

What it is not: an EHR. Tracker programmes support individual-level records, but a national aggregate reporting platform is not a substitute for clinical systems, and configuring it as one produces metadata that is painful to unwind.

Detail: DHIS2 in Nepal.

Logistics (eLMIS)

Supply chain and commodity management — among the earliest digitised functions, with the Logistics Management Information System modernised in 1997.¹ Logistics data is often the most reliable in a health estate, because stock is physically counted and reconciled.

Civil registration and vital statistics

Births and deaths. Structurally important to health because it is where identity originates, and a recurring source of mismatch when a health record and a civil record disagree.

EMR / EHR

An electronic health record system was piloted in 2014.¹ Hospital deployments since then vary by vendor, data model and export capability. That variation — not the count of deployments — is what determines integration cost. Two hospitals with different EMRs and no export profile represent two bespoke integration projects.

Disease surveillance

Event-based and indicator-based reporting, with a timeliness requirement that routine monthly reporting does not have. Surveillance is where the cost of latency is measured in outbreaks rather than in late dashboards, which is why it usually justifies its own pipeline.

Health insurance

Claims and beneficiary management. Insurance systems force identity and facility registry problems into the open faster than clinical systems do, because payments depend on resolving them.

Where the seams are

The systems above are individually reasonable. The problems live between them:

Patient identity across systems. A person attending a health post, a hospital and an insurance desk may exist as three unrelated records.

Facility codes across time. Federal restructuring changed administrative boundaries; identifiers that encoded geography inherited a migration problem, and time series across that boundary need documented breaks.

Definitions across systems. The same indicator name computed from different denominators produces two "official" numbers and a meeting to reconcile them. This is a data governance problem.

Aggregate versus individual. Routine reporting answers "how many"; care continuity needs "who". Bridging them requires individual-level data with identity, which returns to the first seam.

Lessons from the field

The most useful diagnostic I know for a health information system is to sit with the person entering the data for one shift.

You learn things no architecture review surfaces: that the mandatory field everyone complains about gets a placeholder value, that a workaround has become standard practice across a district, that the register on the desk is the real system of record and the software is a monthly transcription exercise.

Every one of those has a downstream data consequence that will later be described as a "data quality issue", as though it appeared spontaneously in the database. It did not. It was designed in, usually by someone optimising a form for reporting completeness rather than for the person filling it.

The single highest-return intervention in Nepali health information systems is not a new platform. It is making the recording workflow useful to the recorder — so that the person entering data gets something back for it, whether that is a working patient list, a follow-up reminder, or simply not having to write the same thing twice.

What good looks like next

• One facility registry that all systems resolve against.
• An identifier strategy documented before the next EMR procurement.
• Export conformance required in contracts, against the national FHIR profiles.
• Metadata change control with published release notes, so indicator series survive corrections.
• Continued strength in aggregate reporting — it works, and it should not be disrupted while individual-level capability is built alongside it.

Where to go next

• DHIS2 in Nepal
• Case study: DHIS2 and health information systems in Nepal
• Healthcare interoperability in Nepal
• A reference architecture
• Reference documentation: HMIS platform and the eRecord implementation guide

Sources

1. 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
2. Nepal HMIS — hmis.gov.np
3. Department of Health Services, Government of Nepal — dohs.gov.np
4. DHIS2. Documentation. docs.dhis2.org