OpenHIE and OpenHIM: the missing middle of Nepal's health data

The problem is not a shortage of systems

Nepal has plenty of health information systems. Aggregate reporting runs through DHIS2. Hospitals run electronic medical records and hospital management systems from a dozen different suppliers. Health insurance runs through its own claims platform, and patients carry an IMIS membership number. Logistics has a supply chain system. Laboratories have analysers with their own middleware. Civil registration records births and deaths. Immunisation, tuberculosis, HIV and nutrition each have a programme system, usually funded by a different partner on a different timeline.

Every one of these works. The problem is what happens between them, which is mostly nothing, and where something does happen it is a point-to-point connection built for one purpose by one vendor.

Point-to-point integration has a well known arithmetic problem. Connecting five systems to each other takes ten connections. Ten systems takes forty-five. Each connection is a separate contract, a separate credential, a separate transformation, and a separate thing that breaks silently when one side upgrades. In practice institutions stop at two or three integrations and do the rest by exporting spreadsheets, which is how a country ends up with excellent systems and poor information.

What OpenHIE actually is

OpenHIE, the Open Health Information Exchange, is an architecture rather than a product. It is a community-maintained blueprint that says: stop connecting applications to each other, and connect them all to a small set of shared services instead.

The blueprint names the shared services, and the names matter because they map onto real gaps:

Facility registry. One authoritative list of health facilities, with a code for each, so that every system means the same building when it says the same name.
Client registry. A master patient index that resolves the several identifiers a person accumulates into one, so a laboratory result and an insurance claim can be recognised as belonging to the same patient.
Health worker registry. One list of health workers, their qualifications, and where they are posted.
Terminology service. Shared code systems and the mappings between them, so that a diagnosis or a laboratory test means one thing across the estate.
Shared health record. The longitudinal clinical record assembled from what the point-of-service systems contribute.
Interoperability layer. The traffic controller in the middle that every system talks to, instead of talking to each other.

Point-of-service applications, the hospital systems and EMRs and laboratory systems where work actually happens, sit outside this and connect inward. OpenHIE does not ask them to be replaced. That is the single most important property of the architecture, and the reason it survives contact with a real country.

What OpenHIM is

OpenHIM, the Open Health Information Mediator, is the reference implementation of the interoperability layer. It is open source, it is the piece you can actually install, and it does a small number of unglamorous things extremely well.

It is the single front door. Applications send transactions to OpenHIM rather than to each other. One address, one credential, one place to configure.
It routes. Channels decide where a given transaction goes, based on its path and content.
It mediates. Mediators are small services that transform a message on the way through: a legacy XML payload becomes a FHIR resource, a local facility code becomes the national one, a date is converted between calendars.
It authenticates and authorises. Each connected application is a known client with its own credentials and its own permitted channels. A laboratory system cannot quietly start reading insurance data.
It logs every transaction. This is the feature that changes daily life. Every request and response is recorded and visible in a console, with the payload, the status and the timing.
It retries and queues. When a downstream registry is unavailable, transactions are held rather than lost, and can be replayed.

The transaction log deserves emphasis. In a multi-vendor environment, the most expensive hours are spent arguing about whose system failed. When every message passes through one mediator that recorded exactly what was sent and exactly what came back, that argument ends in minutes, with evidence. For an institution managing several suppliers, that alone justifies the layer.

Why this matters specifically in Nepal

The architecture is generic. The reasons it fits Nepal are not.

Facilities are the first thing to fix

Nepal has federal, provincial and local government all commissioning health systems, and hospitals ranging from a district facility to a medical college. Every system carries its own facility list, entered by hand, at a different time. The same hospital appears under three spellings and two codes. Any attempt to compare or combine data fails at this first step, long before anyone gets to clinical content.

A facility registry is unglamorous, achievable, and unblocks everything downstream. It is the right first project, and it is the one most often skipped in favour of a dashboard.

Patient identity is the second

A patient in Nepal may be identified by a hospital registration number, an insurance membership number, a citizenship number, and increasingly a national identity number. None of these is present in every system. Without a client registry, the same person is several people, and any longitudinal view of care is impossible.

As the national identity system extends its reach, the temptation will be to declare it the health identifier and move on. That will not work on its own, because it does not solve the millions of existing records that carry no such number. A client registry that matches identifiers rather than replacing them is what bridges the gap between the records that exist and the records we wish existed.

Terminology decides whether the data is worth having

A hospital that records "fever" as free text has produced a note. A hospital that records a coded diagnosis has produced data. Between ICD-11 for diagnoses, LOINC for laboratory tests and SNOMED CT for clinical terms, the standards exist; what is missing is the shared service that holds Nepal's chosen subsets and the mappings from what each hospital already uses. That service belongs in the middle, not in each hospital.

Federalism makes the layer necessary rather than optional

Because health responsibility is genuinely distributed across three tiers of government, no single authority can dictate one application for everyone, and attempting it would fail. What can be agreed is the interface. An interoperability layer lets a province choose its own hospital system while still exchanging with national services on defined terms. It is the governance model that federalism actually permits, which is why the architecture and the constitution point in the same direction.

It reduces vendor lock-in, which is a procurement problem, not a technical one

When integration is point-to-point, the vendor who built the connection owns it, and replacing any one system means renegotiating with everyone. When integration runs through a layer the institution controls, a system can be replaced without touching the others, because the interface is public and the mediator absorbs the difference. Institutions that have been through one painful migration understand immediately why this matters.

Connectivity is imperfect, and the layer helps

Facilities lose power and connectivity. A point-to-point integration in that situation simply fails and drops data. A queueing mediator holds transactions and replays them when the link returns. The design assumption of intermittent connectivity is not an afterthought in this architecture; it is the reason the queue exists.

A staged path that has a chance of working

The failure mode of interoperability programmes is attempting everything at once and delivering a diagram. A sequence that has worked elsewhere, and that suits Nepal:

Stand up the layer and one registry. OpenHIM plus a facility registry. Connect two systems that already need to agree on facilities. Prove the plumbing with something whose value is obvious.
Add terminology. Publish the code sets and the mappings. Make the mappings a service rather than a spreadsheet that circulates by email.
Add the client registry. Begin matching identifiers on the systems that already exchange, before attempting national coverage.
Only then consider a shared health record. It is the most visible component and the least useful without the three below it.
Write the interface into procurement. Every new system must connect through the layer. This is the step that determines whether the previous four survive.

Notice that the first four are infrastructure and none of them produces a screenshot for a launch event. That is exactly why they get skipped, and exactly why the exchange fails when they are.

What this does not solve

OpenHIM will not improve data that is wrong when it is entered. A mediator moves a bad record faster. If a hospital's registration desk mistypes a name, the client registry will faithfully fail to match it.

The architecture also demands operational capacity that has to exist somewhere. Someone must run the layer, monitor the queues, maintain the mediators when a vendor changes a payload, and hold the authority to say no to a system that wants a private connection. That capacity is a staffing and governance decision, not a software one, and it is the reason interoperability programmes succeed or fail.

Finally, the standards work is not free. FHIR gives a common shape for the data, but choosing profiles, agreeing on required fields and settling extensions is a deliberate exercise that requires clinical people in the room, not only engineers.

None of this argues against the approach. It argues for entering it with clear eyes. The alternative, which is what most institutions are doing now, is to keep building one-off connections until the arithmetic defeats them, and to keep answering national questions by asking hospitals to fill in a spreadsheet.