Skip to main content
Expert Talk
Amakomaya — Aamako Maya Apps Pvt. Ltd.

Healthcare Interoperability in Nepal

Deep analysisBy , Co-Founder & CHIO, Aamako Maya Apps Pvt. Ltd.Published 13 min read

The four levels, and where Nepal sits​

The standard model of interoperability has four levels, and naming them makes the gap visible:

Foundational — two systems can exchange bytes. A connection exists.

Structural — the payload has agreed structure. A Patient is recognisably a patient, with fields in known places. This is what adopting FHIR mostly buys you.

Semantic — the receiver understands what the data means. A diagnosis code resolves to the same concept on both sides. This requires terminology, not formats.

Organisational — the exchange is governed: there is agreement on who may send what, under what legal basis, with what obligations, and someone is accountable when it breaks.

Most integration work in Nepal that I have seen reaches structural, sometimes partially semantic, and rarely organisational. A national implementation guide moves the whole estate up the structural rung at once, which is exactly why it matters. It does not by itself deliver the third and fourth.

The three questions that decide everything​

Every failed health integration I have worked on reduces to one of three questions that nobody answered early enough.

1. Who is this patient?​

Two systems holding records for the same person, keyed on different identifiers, cannot merge those records reliably later. Nepal's national identity programme helps for records created after linkage, but leaves the historical tail and people without documents.

The practical consequences are unglamorous and permanent: probabilistic matching, a duplicate-resolution queue, and a policy for who adjudicates conflicts. The identifier design questions are laid out concretely in FHIR identifiers, including naming systems and cross-system lookup.

2. Which facility is this?​

Facility identifiers that encode geography break when geography is re-administered — as it was under federal restructuring. Any indicator series crossing that boundary needs a documented break, and any system that inferred province from a facility code needs remediation.

A facility registry with stable, meaningless identifiers and an explicit history of merges and renames is the fix. It is also the easiest registry to build, which is why it should be first.

3. What does this code mean?​

Free-text diagnosis fields are the enemy of exchange. Codes must come from published systems — ICD for classification and reporting, SNOMED CT for clinical meaning, LOINC for laboratory observations — and the mapping from local codes must be versioned and maintained, not performed once during a migration.

Implementation reality

Here is the pattern I have watched repeat.

A project decides to "make the systems interoperable". It selects FHIR, which is the right choice. Six weeks of work produces a working Patient exchange against a test server, and a demonstration.

Then it meets production. The sending system's patient identifiers are unique within one facility, not nationally. Diagnoses are free text with local abbreviations. Half the records have a date of birth of 1 January because the registration form made it mandatory and the clerk needed to move on. Facility codes changed in a restructuring three years ago and the historical rows were never migrated.

None of these are FHIR problems. All of them are discovered by the FHIR work, which is the honest value of doing it: the standard does not fix your data, it tells you the truth about it.

The teams that succeed treat that discovery as the deliverable of phase one, and plan a data remediation phase they did not originally budget for. The teams that fail treat it as scope creep.

What a working exchange needs​

Beyond the standard itself:

  • Registries — client, facility, health worker. See the reference architecture.
  • Terminology services — hosted code systems and value sets, versioned, with an expansion API.
  • An interoperability layer that authenticates, routes, transforms, audits, and rejects non-conformant payloads. See integration engines.
  • Conformance tooling — published profiles, a public validator, a test server with synthetic data so nobody debugs against real patients.
  • A legal basis for each exchange, with retention and access rules. See ISO 27799 for health-specific controls.

The cheapest intervention available​

Government buys most health software in Nepal. That gives it a lever it rarely pulls: contract conditions.

Three clauses would change vendor behaviour permanently, at essentially zero cost:

  1. Systems must export their data against the national FHIR profiles.
  2. Systems must publish a capability statement describing what they support.
  3. The purchasing body owns the data and its schema documentation, irrespective of who operates the system.

No procurement clause has ever been as expensive as an unplanned migration off a system that could not export its own data.

Where to go next​

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 FHIR Implementation Guide (draft, v0.0.1-ballot), Ministry of Health and Population, Government of Nepal. fhir.hmis.gov.np
  3. OpenHIE Community. OpenHIE Architecture Specification. ohie.org
  4. HL7 International. FHIR specification. hl7.org/fhir
Last updated on