Hospital Data Interoperability (Nepal)

A 200-bed hospital in Kathmandu probably has six systems holding patient data. The HMS, the LIS, the RIS/PACS, the pharmacy stock app, the billing module, and the spreadsheet the OPD coordinator keeps because the HMS can’t tell her what she needs. None of them talk to each other in any structured way. The data is there. The interoperability isn’t.

That’s the actual problem hospital IT leads in Nepal are solving in 2026 — and the answer isn’t “buy a bigger Hospital Management System.” It’s interoperability done deliberately. Here’s what that looks like in practice.

The three layers of interoperability

Hospital interoperability isn’t one thing. It’s three layers, and most vendor pitches conflate them.

1. Transport — how systems exchange messages

This is the protocol layer. HL7 v2 (the 1990s ASCII pipe-delimited workhorse), HL7 v3, FHIR (the modern REST/JSON standard), or plain old REST APIs. Most Nepali hospital systems support some flavor of HL7 v2 if you ask the vendor; few support FHIR natively yet, though that’s changing.

2. Semantics — what the messages mean

This is the vocabulary layer. SNOMED CT, LOINC, ICD-10/11. A lab result that says “Hb 12.5” only interoperates if both systems agree on what “Hb” is and what units it’s in. Most hospitals in Nepal don’t have a clean code system; what they have is local terminology that grew out of one head doctor’s preferences in 2014.

3. Identity — who the patient is

This is the master patient index layer. If your HMS calls a patient “Ram Kumar Shrestha, DOB 1985-04-12” and your LIS calls the same patient “R.K. Shrestha, DOB 12 Apr 1985,” your interoperability is broken at the most basic level. Identity resolution is unglamorous and load-bearing.

Get all three right and you have interoperable data. Get any one wrong and you have an integration that mostly works until it doesn’t.

The MoHP reporting reality

Nepal’s Ministry of Health and Population requires hospitals to report on a defined set of indicators — disease surveillance, immunization, maternal health, hospital census. Most hospitals do this by exporting data manually from their HMS, hand-reconciling it in Excel, and uploading to MoHP’s portal once a month.

This is exactly the kind of work that should be automated. The pattern that works:

Build a data layer on top of the operational HMS (Postgres or your transactional DB).
Use dbt to encode every MoHP indicator as a SQL model with tests.
Run a nightly Airflow job that materializes the indicators and posts them to MoHP’s API where available (or generates the upload file where it isn’t).
Keep a reconciliation dashboard that shows monthly indicators against the last 24 months so anomalies are caught before submission.

This is Operational Automation in healthcare’s clothing. The hospital didn’t get faster MoHP reporting because someone bought a new HMS. They got it because they treated MoHP reporting as a data engineering problem.

Integrating legacy lab and imaging systems

A typical Nepali hospital has a lab information system that was installed in 2012 and an imaging system that was installed in 2017. Neither is going to be replaced because the cost of replacement is enormous and the existing systems work. Interoperability means making the new HMS or analytics layer talk to what’s already installed.

Three patterns we use:

HL7 v2 over MLLP — the lab system probably already supports this. We stand up a small Mirth Connect or Iris instance that listens for HL7 messages from the lab, translates them into the canonical schema, and writes them to the analytics layer. Lab system stays untouched.

Database-level CDC — for systems with no API but accessible databases, we set up change data capture (Debezium against MySQL/Postgres, or polling for older systems). The downstream warehouse stays in near-real-time sync without any change to the source app.

File-based bridges — some imaging systems only export to a folder. Fine — we watch the folder, parse the DICOM headers, and route metadata into the data layer. The actual images stay in PACS where they belong.

Each pattern adds latency and complexity, so you pick the simplest one that meets the use case. Real-time fraud detection needs sub-second CDC. Monthly MoHP reporting can run nightly off file exports. Match the engineering to the SLA.

FHIR: where it’s worth it, and where it isn’t

FHIR is the modern standard everyone is supposed to adopt. The honest answer for Nepal in 2026:

FHIR is worth it for greenfield builds, new modules in mature systems (especially patient-facing apps, telehealth), and international integration (insurance, research, donor reporting).
FHIR is not worth it if your goal is to integrate three legacy systems that already speak HL7 v2 and are never going to be upgraded. Adopt FHIR at the edge (new apps, new APIs) and let the core run on whatever the legacy system supports. Layered translation is fine; forced migration is expensive.

Where FHIR really shines is the analytics layer. Once your data is normalised into FHIR Resources (Patient, Observation, Encounter, Procedure), every modern healthcare tool — including most AI implementation in healthcare — knows how to consume it.

The pdpspectra pattern

When we build a Hospital Management System in Nepal, interoperability isn’t a phase 2 add-on. The architecture assumes from day one that this hospital has other systems, will have new ones in three years, and needs to talk to MoHP, insurance, and probably an international donor. The HMS we ship is interoperable by default because the underlying data model is event-based and FHIR-translatable. Integrations become questions about adapters, not about ripping out the core.

The boring win: the hospital stops being held hostage by any single vendor — including us.

If your hospital has data trapped in three systems and a manual MoHP report consuming 8 hours a month, that’s an interoperability problem, not a software problem. Talk to us about Hospital Management System builds in Nepal or tell us about your data silos.