HIB Swasthya Bima is quietly digitalizing Nepal's hospitals

The most effective health IT policy Nepal never wrote

Ministries write digitalization strategies. Development partners fund pilots. Vendors present roadmaps. Meanwhile, the thing that has actually pushed Nepali hospitals to record their work in structured form is a financing scheme that never described itself as a technology programme at all.

HIB Swasthya Bima, the national health insurance scheme run by the Health Insurance Board, pays a hospital only for care it can describe. Not care it delivered; care it can describe, in an itemised claim, attached to a verified member, submitted through the payer's system, within a time limit.

That is a financing rule. It behaves like an IT mandate, because it is enforced by cash rather than by instruction. A hospital can ignore a circular for years. It cannot ignore a claim that was rejected.

What follows is not a projection. It is the sequence we watch happen inside hospital after hospital, in roughly this order.

The claim goes through an API, so the computer stops being optional

Start with the mechanism that makes everything else inevitable. A claim is not a bundle of paper that somebody carries to an office. It is submitted to the payer's system through an interface, machine to machine. There is no paper path that ends in payment.

Follow what that forces backwards into the hospital. Membership has to be verified online, at the counter, while the patient stands there. Entitlement has to be checked: what remains of the limit, whether the service is covered, whether a referral was needed. The encounter has to exist as data before it can be transmitted. Items have to be priced against the agreed schedule. Services have to carry codes the payer recognises, because free text is not payable. Then the whole thing has to be assembled and sent, and the response has to be recorded, because a rejection that nobody reads is money written off.

None of that can be done from a register. A hospital that wants to be paid must put a working computer, on a working connection, in front of the person doing the work. By hook or by crook, as the phrase goes. This is why insurance succeeded where instruction failed: it did not ask hospitals to digitalize, it made payment impossible without it.

Overload forced hospitals to buy speed, and speed came in digital form

Government hospitals in Nepal run well beyond comfortable capacity. The outpatient queue is the visible symptom, and registration is where it forms.

Insurance makes that queue worse before it makes it better, because an insured registration has more steps than a cash one. Verify the member, check entitlement, capture the details the claim will need. Multiply by the daily load of a busy federal hospital and the counter becomes the constraint on the entire outpatient department.

Hospitals did not respond by hiring more clerks, because they cannot. They responded by buying throughput, and every available form of throughput happened to be digital:

• Self-service kiosks in the outpatient hall, so a patient can register, print a ticket, check an insurance balance or collect a laboratory report without joining the counter queue at all.
• Token and queue systems, so the crowd at the door becomes an ordered list with a display and an announcement, and staff stop refereeing the queue.
• Machine interfacing, so laboratory analysers write results straight into the system instead of a technician copying numbers twice, which removes both a delay and a transcription error.

Not one of these would have survived a budget discussion framed as "digitalization". Each of them was funded as relief for a queue that had become unmanageable. The hospital got digital infrastructure as a side effect of trying to get people through the door before evening.

Compulsory document upload is medical records by another name

The scheme does not accept a claim on its numbers alone. Supporting documents have to be uploaded with it: the discharge summary, the investigation reports, the prescription, whatever substantiates what is being claimed.

Watch what that requirement does inside a hospital over about two years.

At first it is a scanner and a person. Documents are written on paper as they always were, then scanned, named, matched to the right claim and uploaded. It works, and it is miserable. Someone is employed to chase missing pages, and claims sit unsubmitted because one report has not come back from the ward.

Then somebody asks the obvious question: if the document has to exist digitally at the end, why is it being created on paper at the beginning? Generating the discharge summary in the system is less work than producing it on paper and scanning it. So the document starts life digital, and the scanner moves to the corner.

That is how a compliance requirement becomes a medical records programme. Nobody launched it. It arrived one document type at a time, because each was cheaper to generate than to scan.

When four in five patients are insured, the claims system is the hospital system

Here is the fact that changes the weight of everything above. In the government hospitals we work in, insured patients are around four in five of the load.

At that share, insurance is not a payer among several. It is the hospital's business. And that has a consequence people underestimate: the claims pathway stops being a side module bolted onto the hospital system and becomes the main transactional record of the institution. If the claim data is wrong, the hospital's picture of itself is wrong, because there is no larger stream of data to correct it against.

It also settles arguments about priority. When a hospital debates whether to invest in the registration desk, the network or the reporting module, the answer follows from the eighty per cent. Anything that touches the insured pathway touches almost every patient. Anything that does not is a minority concern.

It dragged the network in behind it

This is the least discussed consequence and, over a decade, possibly the most valuable.

Online membership verification at a busy counter does not tolerate an intermittent connection. Neither does uploading documents all day, nor transmitting claims to a deadline. A hospital that loses connectivity for an afternoon does not merely suffer an inconvenience; it stops being able to register insured patients, which is most of them.

So hospitals bought what they needed to stay connected. In federal hospitals it is now close to standard to find a real high-speed line rather than a consumer connection, a second failover link from a different provider so a single cut does not stop registration, a firewall between the hospital and the internet, and at least one person whose job includes keeping that running.

Ten years ago that combination would have been remarkable in a government hospital. It is now ordinary, and it was not bought as a digitalization initiative. It was bought because the claim would not go through.

The result is that the hardest and least fundable layer of hospital IT, the boring physical one, is already in place. Every clinical system, integration or shared national service that anyone proposes from here on arrives at a hospital that already has a network to run it on. That is an enormous head start, delivered by accident.

Prescription upload is pulling clinical data in

The most recent shift is the most consequential, and it is still under way. The scheme increasingly expects prescriptions to come from the electronic medical record rather than from a pad, and that expectation grows a little each year.

The distinction matters more than it looks. Billing data tells you what was charged. Prescription data tells you what a clinician decided, for which patient, on what evidence. It is the first genuinely clinical dataset most Nepali hospitals will hold at scale, and once prescribing happens in the system, the surrounding clinical documentation follows, because a prescription that is not attached to a diagnosis is an awkward thing to defend.

So the direction of travel is clear enough to plan around. Insurance began by digitalizing the hospital's money. It is now, one requirement at a time, digitalizing the hospital's medicine. A hospital that treats its EMR as a claims accessory will keep being surprised by the next requirement. A hospital that recognises where this is going can build the clinical record properly and satisfy the payer as a by-product, rather than the other way round.

The dividend nobody planned

Now the part hospital managers notice late, and it is the more valuable half of the story.

A hospital that can produce an insurance claim has, without intending to, built a hospital that can produce information about itself. The same structured data that satisfies a payer will answer questions the institution has been unable to answer for its entire existence.

• Which departments are actually busy, by hour and by day, rather than by impression.
• What the case mix really is, and how it moves with the season.
• Which services are performed most, and what they cost against what they earn.
• How long a patient waits between registration and consultation.
• Which tests are ordered, by whom, and how often results are never collected.
• What the pharmacy dispenses, and where stock runs out predictably.

None of that requires new data collection. It requires only that someone reads what the claims process already forced the hospital to record. A hospital that has been insured for a few years is sitting on a dataset it built by accident and has never opened.

That is where insurance stops being an administrative burden and becomes the foundation of management. The measurement problem, normally the hardest and most expensive part of hospital improvement, has already been solved as a side effect of getting paid.

Where it goes wrong

This is not a story with only an upward slope, and pretending otherwise would be useless to anyone running a hospital.

You inherit the payer's uptime. When the claims interface is slow or unavailable, registration slows or stops, because membership cannot be verified. The hospital's front door now depends on a system it does not control, which is an argument for a documented fallback procedure rather than an argument against the model.

Coding drifts toward what pays. When a code determines revenue, coding follows revenue. This is universal, not Nepali, and it is the main reason insurance data must be read carefully when it is used for clinical or epidemiological purposes.

Rejection becomes the real bottleneck. A hospital with weak internal reconciliation submits claims that fail, then resubmits, then chases. The work is invisible in the clinical areas and enormous in the accounts section, and hospitals consistently underestimate it until it is already large.

Cash flow risk concentrates. As the insured share rises past half and keeps going, the hospital's finances depend on the payer's processing speed. An institution that used to collect at the counter now manages receivables it never had to think about.

Data quality is decided at the counter. Under pressure, membership numbers get mistyped and patients get registered twice. Everything downstream inherits that error, and by the time it surfaces as a rejection it is weeks old and expensive to unpick.

Upload capacity is a real constraint. Document upload is bandwidth, storage and staff time, and it grows every month. It is usually planned for once, at the beginning, and then quietly outgrown.

What to build, in order

For a hospital manager deciding where to spend next, the sequence follows fairly directly from all of the above.

• Make the network genuinely reliable first. A failover link and a firewall are not glamorous, and everything else fails without them. If registration stops when one cable is cut, nothing further on this list matters.
• Fix registration and membership verification. This is where identity errors enter, and it is the cheapest place to prevent expensive ones. It is also the queue everyone can see.
• Relieve the counter with kiosks, tokens and machine interfacing. These pay back in throughput immediately and are the easiest digital projects to get approved, because the problem is visible to everyone including the patients.
• Generate documents digitally instead of scanning them. Take one document type at a time, beginning with whichever is most often missing at claim time.
• Instrument the claim lifecycle. Track submitted, rejected, resubmitted and paid as states with dates. A hospital that cannot age its receivables is not managing them.
• Read the rejections. They cluster. A handful of causes usually explain most of them, and each is fixable once named. This is the highest-return analysis available to a hospital finance team, and almost nobody does it.
• Build the clinical record deliberately, before you are told to. Prescription upload is already here. Treat the EMR as the record it is, not as a claims attachment.
• Then use the data for management. Once the pipeline is reliable, the same records answer the operational questions. Do this last, because it depends on everything above being solid.

The wider point

Nepal's health digitalization has been discussed for two decades in terms of strategies, standards and platforms. What has moved it is money changing hands on the condition that the work is recorded, transmitted and evidenced.

That is worth remembering when the next programme is designed. Systems get adopted when using them is the easiest route to something the institution already wants. Insurance achieved that without meaning to. Whatever shifts Nepali health data next, whether that is interoperability, a national patient identifier or a shared clinical record, will succeed on the same terms or it will join the strategies on the shelf.