Digital Health Architecture for Nepal
A reference architecture
A reference architecture for Nepal's digital health ecosystem. The layer that most implementations skip is the pink one.
Layer 1 — Point of service
Where data is created: hospital EMR/EHR systems, community and mobile tools used by frontline workers, laboratory systems, insurance and claims platforms.
The architectural requirement on this layer is modest but non-negotiable: each system must be able to export its data against a published profile and declare what it supports. A point-of-service system that can only render its data on its own screen is a data silo regardless of how good the clinical software is.
Layer 2 — The interoperability layer
One door into the exchange. It authenticates callers, routes messages, mediates between formats, transforms payloads, records an audit trail, and — the part most often omitted — enforces conformance by rejecting non-conformant data.
The alternative is bilateral integration, where ten systems imply up to forty-five interfaces, each with its own authentication, mapping and failure behaviour. Adding the eleventh system means ten more. This is not a theoretical concern; it is the observed cost curve of every health estate that grew without a mediating layer.
Layer 3 — Foundational registries and terminology
The layer that decides whether any of the above can work:
- Client registry — can the estate decide whether two records describe the same person?
- Facility registry — are facility codes stable across administrative reorganisation?
- Health worker registry — who provided the care, and are they who they say?
- Terminology services — do codes carry meaning across systems? ICD for classification, SNOMED CT for clinical meaning, LOINC for observations.
Layer 4 — Data and analytics
Two distinct products that are frequently conflated:
A shared health record is longitudinal and individual-level. It answers "what has happened to this person?"
HMIS reporting is aggregate and periodic. It answers "how many, where, this month?" In Nepal this is DHIS2, and it works.
Both are legitimate. Neither substitutes for the other. Building aggregate reporting and calling it an EHR strategy is the single most common architectural error in low- and middle-income health systems, and it is expensive to unwind because the metadata design bakes the assumption in.
Layer 5 — Governance
Not a technical layer, but it constrains every other one: decision rights over metadata and definitions, access control, audit, retention, and the change process that stops a well-meant mid-year correction from invalidating a national time series.
Federal architecture for a federal state
Nepal's federal structure is an architectural input, not a political footnote. Local levels operate services; provinces supervise; the centre sets standards. Architecture that ignores this produces one of two failures: a centralised system nobody at local level will maintain, or local systems that cannot roll up.
The workable pattern is federated: standards and registries defined nationally, operation devolved, exchange mandatory. Concretely —
- National: identifiers, code systems, FHIR profiles, conformance testing, registry authority.
- Provincial: supervision, data quality follow-up, analysis.
- Local and facility: operation, service delivery, data capture.
The OpenHIE architecture is the closest published pattern, and it maps onto this structure without much adaptation.
Architecture perspective
The decision that determines a decade of downstream cost is the patient identifier strategy, and it is usually made implicitly, by whoever ships first.
Once several systems hold patient records keyed on locally-assigned numbers, adding a national identifier later does not merge them. You inherit a matching problem — probabilistic, permanent, and requiring human adjudication for the long tail. Every subsequent integration pays that cost.
The corollary is uncomfortable for project planning: identity work has no visible deliverable. Nobody demonstrates a client registry at a launch event. But it is the difference between an estate that can exchange data in five years and one that cannot.
If a single architectural rule were adopted nationally, I would choose this: no system holding individual health records is procured without a documented identifier strategy that says which identifier is authoritative, how matching is performed, and how conflicts are resolved.
Build order
Sequencing beats architecture diagrams. What works:
- Facility registry. Least contested, immediately useful, unblocks reporting and exchange alike.
- Terminology service. Even a modest one — hosted code systems and value sets with versioning.
- Health worker registry.
- Client registry, with an explicit and documented matching strategy.
- Conformance tooling — published profiles, a validator, a test server with synthetic data.
- Interoperability layer, once there are at least two consumers with a real exchange need.
- Shared health record, assembled from systems that are already exchanging.
Steps 5 and 6 are commonly reversed, and it is a costly reversal: an exchange layer with nothing to validate against becomes a message pipe, and a message pipe with no conformance enforcement propagates bad data faster than paper did.
Architectural decisions worth making explicitly
Push or pull? Does the exchange push documents to a repository, or do consumers query at the point of care? Connectivity realities in Nepal argue for tolerating both, with store-and-forward as a first-class case rather than an exception.
Offline-first, or online-assumed? For community-level tools this is settled: offline-first. It changes the data model — you need conflict resolution and client-generated identifiers.
Where does transformation happen? In the mediator, not in the point-of-service system. Otherwise every system carries knowledge of every other system.
What is the failure behaviour? A message that cannot be delivered must dead-letter and alert. Silent loss is the failure mode nobody notices until reconciliation, months later.
Who may change a code list? If the answer is "anyone with database access", there is no architecture, only a diagram.
Where to go next
- Healthcare interoperability in Nepal — the exchange layer in practice.
- HL7 FHIR in Nepal — the national implementation guide and what conformance means for implementers.
- Health information systems in Nepal — the estate this architecture has to accommodate.
- Building an interoperable maternal health platform — these decisions applied to a real system.
Sources
- Paudel S, Paudel D, Boucher F. Digital Health in Nepal: A Perspective on Overcoming Challenges and Leveraging Opportunities. Kathmandu University Medical Journal. 2025; 91(3): 386–91. PDF
- Nepal HMIS FHIR Implementation Guide (draft, v0.0.1-ballot), Ministry of Health and Population, Government of Nepal. fhir.hmis.gov.np
- OpenHIE Community. OpenHIE Architecture Specification. ohie.org
- WHO. Digital Implementation Investment Guide. Geneva: World Health Organization; 2020. who.int