EMR, EHR and Interoperability in Nepal: What Hospitals Should Build For
An EMR is what one hospital knows about a patient. An EHR is the longitudinal record designed to follow that patient across organizations. The distinction matters in Nepal because a hospital can buy an EMR, but an EHR emerges only when identity, consent, terminology and exchange standards work across many institutions.
The practical buying question is therefore not “does this vendor sell an EHR?” It is “will the record we create today be structured, governed and open enough to participate in Nepal’s evolving digital-health ecosystem tomorrow?”
What is the difference between EMR and EHR?
An EMR supports care inside a facility or group; an EHR supports continuity across facilities.
The EMR contains consultations, diagnoses, allergies, medicines, orders, results, procedures, nursing records and discharge summaries. It needs roles, audit trails, clinical safety and usable workflows. Cross-organization exchange adds patient and facility identity, consent, standardized meaning, discovery and trust between systems.
A PDF discharge summary is useful to a person but limited for computation. Structured allergies, medicines and results can be searched, checked and exchanged while still producing a readable document.
What direction is Nepal taking?
Toward a connected platform, standards and national identity building blocks, while implementation continues to evolve.
The Ministry’s Digital Health platform plan describes a national platform linked to HMIS, EHR systems and the Health Facility Registry. SIL-Nepal focuses on standards-based design and testing. In 2025 the Ministry also announced work on a National Health ID Development Committee to support interoperability between health institutions.
These initiatives are reasons to preserve flexibility, not reasons for vendors to claim completed compliance with a future architecture. Hospitals should ask for current evidence and contractual support for change.
Which standards should hospital software support?
Support the standard appropriate to each exchange and keep the data clean underneath it.
HL7 v2 remains common for admissions, orders and results. FHIR provides modern web resources and APIs. DICOM is the foundation for medical imaging. Standard clinical codes and units reduce ambiguity. The Ministry’s HL7 guidance explicitly discusses HL7 v2, FHIR and CDA, and its interoperability resources also identify DICOM.
“FHIR-ready” should mean more than a logo. Ask the vendor to expose a patient, encounter, observation and diagnostic report in a test environment, show authentication and document which profile and version it implements.
How should consent and access be designed?
As enforceable data and events, not a paper form scanned into a folder.
Every user should have an individual account and role-based access. Sensitive access should be logged. Consent should record purpose, scope, source, time, status and withdrawal where applicable. Emergency access needs a clear break-glass path with review.
Before exchanging data externally, the hospital must know which identifier is used, what is sent, who requested it, under what authority, and how the event is audited. Legal and policy requirements should be confirmed from current Nepal authorities and counsel; software should make the agreed rule enforceable.
What should a hospital test before buying?
Test portability and a real exchange, not only the EMR screen.
Create an allergy, diagnosis, lab result, prescription and discharge summary. Export them in structured form. Correct the result and show both versions. Give a second authorized role access and show the audit trail. Then ask for the complete patient export and the contract’s exit timeline.
The hospital should own usable data, not merely database files that require the former vendor to interpret.
How does Kōami prepare for interoperability?
Kōami uses one patient identity across hospital operations, inventory and PACS imaging, with open APIs and webhooks at the platform boundary. That reduces internal fragmentation before external exchange begins.
Nepal’s eventual national profiles, identifiers, consent rules and certification expectations must be implemented against authoritative specifications as they mature. A technical discovery session should separate existing APIs from future interface work and put both in writing.
