Interoperability

How HIB and SSF are pushing Nepal towards interoperability

Two payers hold patient records across every facility, issue national identifiers, collect clinical documents with every claim and let history be retrieved by identifier. That is a client registry and a shared health record, built by health financing rather than by health information policy.

By Pramuib Ghimire, eTech Solution · 11 September 2026 · 10 min read

Nepal's health exchange is being built by two organisations that were not asked to build one

Interoperability in Nepal is usually discussed as something the health sector must one day design: a national architecture, a patient identifier, a shared record, a governance framework. A committee, a strategy, a funded programme.

Meanwhile two payers have quietly built most of the components already, for entirely unrelated reasons.

HIB Swasthya Bima is Nepal's national health insurance scheme, run by the Health Insurance Board. The Social Security Fund (SSF) runs contributory schemes for enrolled workers and their dependants, including medical benefit. Neither is a health information agency. Neither set out to create national health infrastructure. Both simply needed to pay providers correctly, and to be able to prove afterwards that they had.

That requirement, pursued honestly at national scale, produces almost exactly the components an exchange needs.

What follows is the mechanism rather than the motive. Four things happen when claims are paid at national scale, and each one quietly builds a component the health sector has been planning to commission: patient records that span facilities, an identifier that behaves like a master patient index, an archive of clinical documents, and retrieval of a person's history by that identifier. Taken in order, they are how two payers are moving Nepal towards interoperability without calling it that.

They hold patient records, and unlike a hospital they hold them across facilities

Start with what these organisations actually accumulate.

A hospital's record stops at its own door. It knows what happened inside its own building, and nothing about the same patient's admission last year in another district. That is the central limitation of hospital-based records everywhere, and it is why longitudinal care is so hard to support from them.

A payer has the opposite shape. It is thin on any single episode compared with the treating hospital, but it follows the patient everywhere they went, because the patient carried the same entitlement into every facility. Over years, both HIB and SSF have therefore assembled something no individual hospital in Nepal can assemble: a record of care across institutions, districts and levels of the system, for millions of people.

That is not a by-product to be dismissed. Longitudinal, cross-facility coverage is the single hardest property to obtain in health data, and two organisations have it.

The membership number is a master patient index that nobody called one

The technical term for the thing Nepal is said to lack is a master patient index, or MPI. It is the service that decides that the person registered at one hospital and the person registered at another are the same human being, and gives that human being one identifier that other systems can hang information from.

Both payers already operate one, and both call it something else.

An insurance membership number is issued once, to a specific person, verified at enrolment, and used at every facility that person attends. So is a Social Security Fund member identifier. The moment a hospital records that number against an episode of care, the episode has been indexed to a national identity rather than to a local registration number that means nothing outside that building.

This is worth stating plainly, because it inverts the usual complaint. Nepal is not waiting for a national patient identifier. Nepal has two of them, in production, at scale, used daily at hospital counters across the country. What Nepal does not have is a way to reconcile them, or to relate either to the hospital registration numbers that already exist in their millions.

That is a smaller and much more tractable problem than building an MPI from nothing, and it is a different piece of work: matching, not issuing.

Claim verification turned both of them into holders of clinical records

Neither payer accepts a claim on its numbers alone. Each treatment has to be substantiated with documents: the discharge summary, the investigation reports, the prescription, whatever evidences that the care being billed actually happened.

Follow that through and the consequence is unavoidable. An organisation that requires clinical documentation for every episode it pays for is, after a few years, holding clinical documentation for every episode it has paid for. Not as a policy choice about health records, but as the residue of financial control.

So both bodies now sit on a national archive of discharge summaries, laboratory and imaging reports and prescriptions, indexed to an identity, spanning facilities. In the OpenHIE vocabulary that is a shared health record occupying the same conceptual slot, arrived at from a completely different direction. It is not structured, it is not clinically curated, and it was assembled to settle invoices. It is nevertheless the largest cross-facility clinical archive the country has.

History is already retrievable by identifier

The final piece is the one that turns an archive into infrastructure. Because everything is indexed to a member identifier, a person's history can be searched by that identifier. Enter the number and the episodes come back: where the person was treated, when, for what, with the supporting documents attached.

That capability was built for adjudication. A claims officer needs to see whether the same procedure was billed twice, whether a condition was pre-existing, whether the documentation supports the amount. But the capability itself is exactly what a clinician wants at the point of care, and exactly what a shared health record is supposed to provide: give me this person's history, by identifier, across facilities.

The retrieval function exists. It is pointed at the finance office rather than at the ward.

What this means, taken together

Set the pieces beside the architecture the sector says it wants. A client registry, in the form of two national identity schemes already used at hospital counters. A shared health record, in the form of a document archive indexed to those identities. A facility directory, because a payer must know precisely which institutions it has contracted and at what rates. Retrieval by identifier, already in production. And connected hospitals, because as we have written elsewhere, the claim interface is what put reliable networks into government hospitals in the first place.

The uncomfortable conclusion is that Nepal's health information exchange is already being assembled, at national scale, by two organisations whose mandate is health financing. The question is no longer whether the country will build these components. It is whether the country will acknowledge what has been built, and shape it deliberately, or leave it as two payer silos that happen to contain the nation's health history.

Where the push stops short

The pressure is real and it is already changing hospital behaviour. Hospitals integrate with payer systems because they must be paid. Every one of those integrations is an interoperability project, negotiated hospital by hospital, and it is teaching a generation of hospital IT staff to think in terms of identifiers, structured submissions and audit trails.

But four problems follow directly from the fact that this was never designed.

One person, several identities. A patient may hold an insurance membership number, a Social Security Fund identifier, a national identity number and a different registration number at every hospital they have attended. Two national identifiers are better than none, but two are also a fragmentation problem, and only a matching service resolves it. This is a client registry that reconciles identifiers rather than a decree that replaces them.

Documents are not data. A scanned or generated discharge summary can be read by a person and not by a system. You cannot compute on a national archive of documents: no cohort, no surveillance, no decision support, no quality measurement. Extracting structure later is far more expensive than capturing it at source, which is the argument for structured clinical data alongside the document, in a shared format such as FHIR, before the archive grows another five years.

Access is granted for adjudication, not for care. A claims officer can see a patient's history. The clinician treating that patient at two in the morning generally cannot. That is precisely backwards from a clinical point of view, and correcting it is not a technical problem. It is a question of mandate, consent and law, and it should be settled before the technical work rather than after.

Hospitals integrate twice, then three times. Every payer that builds its own portal and its own interface adds another integration to every hospital in the country. That is the point-to-point arithmetic that an interoperability layer exists to prevent. If HIB and SSF each connect to a shared layer instead, the next scheme is a configuration change rather than another project in three hundred hospitals.

What should follow

Nothing here requires starting from nothing, and that is the opportunity.

  • Build the matching service, not another identifier. A client registry whose job is to link an insurance number, a Social Security Fund number, a national identity number and hospital registration numbers to one person. Matching is achievable now; universal reissue is not.
  • Ask for structure alongside the document. Where a payer already requires a prescription or a discharge summary, require the coded essentials with it. The marginal cost at submission is small; the retrospective cost is enormous.
  • Agree one facility list. Both payers maintain facility directories for contracting. They should be the same list, with the same codes, as should everyone else's.
  • Put both payers behind one exchange layer. So that hospitals build one integration, and the transaction log that shows what was sent and what came back belongs to the sector rather than to each vendor.
  • Settle consent and clinical access explicitly. Decide, in law and in policy, whether a treating clinician may retrieve a patient's payer-held history, under what consent, with what audit. This is the decision that turns a claims archive into a care record, and no amount of engineering substitutes for it.

The pattern is familiar by now

Nepal's health digitalization has repeatedly advanced through financing rather than through strategy. Insurance put computers and networks into hospitals because claims would not travel any other way. The same financing pressure is now assembling identity, clinical documents and retrieval at national scale.

That is not an argument for leaving it to the payers. It is an argument for recognising where the momentum actually is, and for the health sector to place its architecture on top of that momentum rather than beside it. The components are being built either way. Whether they end up as national infrastructure or as two well-run silos is a decision, and it is being made now by default.

HIBSSFInteroperabilityMaster patient indexOpenHIEFHIRNepal

Planning a digitalization or an IT upgrade?

Tell us where you are - still on paper, half digital, or stuck with systems that will not talk. We will say honestly what it takes, in what order, and roughly what it costs.