Skip to main content
Expert Talk
Amakomaya — Aamako Maya Apps Pvt. Ltd.

HL7 FHIR in Nepal

Technical guideBy , Co-Founder & CHIO, Aamako Maya Apps Pvt. Ltd.Published 15 min read

What exists nationally​

The Nepal HMIS FHIR Implementation Guide is published as part of the Ministry of Health and Population's integrated health information management work for the electronic HMIS. At the time of writing it carries a draft ballot version and is built on FHIR R5 (5.0.0), and it includes terminology artefacts — CodeSystem, ValueSet and ConceptMap — alongside its profiles.1

Two observations for anyone planning work against it.

First, draft status is not a reason to wait. A ballot-stage guide is exactly when implementer feedback changes the outcome. Building against it early and reporting what breaks is more useful to the country than adopting it after it freezes.

Second, check the version you are targeting. A national guide on R5 while much of the global installed base runs R4 is a real planning input: libraries, servers and reference implementations differ in maturity across releases, and resources changed between them.

What a national guide actually changes​

Without a national guide, every integration is a negotiation. System A and System B agree a payload, an identifier convention, and a code list. System C arrives and negotiates again. The estate accumulates bespoke agreements that nobody can validate centrally.

With one, the question becomes: does this system conform? That is answerable by a machine. It is the difference between coordination by meeting and coordination by specification.

The value only materialises with three supporting pieces, and these are worth asking for explicitly:

  1. Published profiles that state cardinality, terminology bindings and required extensions.
  2. A public validator, so conformance can be proven before production.
  3. A test server with synthetic data, so integrators never debug against real patient records.

Planning an implementation​

Step 1 — Decide the identifier strategy first​

Before writing code, answer: which identifier is authoritative for a patient in your context, what naming system does it belong to, and what happens when two records match on some fields and not others?

In FHIR, identifiers are scoped by a naming system rather than being globally unique strings:

{
  "resourceType": "Patient",
  "identifier": [
    {
      "system": "https://api.amakomaya.com/NamingSystem/amk-counselling-id",
      "value": "MRN-98765"
    }
  ]
}

The full treatment — naming systems, cross-system lookup, bundle references — is in FHIR identifiers.

Step 2 — Map your existing data honestly​

Take the real production extract, not the schema documentation. Count how many records have a placeholder date of birth, free-text diagnoses, or facility codes that no longer exist. That count is your phase-one workload, and discovering it early is the point.

Step 3 — Bind terminology​

Map local codes to published systems and version the mapping table as maintained metadata. Start with the highest-volume items; a small number of codes usually accounts for most traffic.

Step 4 — Validate before you connect​

Run the reference validator against your resources with the national profiles loaded. Rejecting bad data at the boundary is far cheaper than discovering malformed resources during analysis a year later. Tooling notes: HAPI FHIR, FHIR servers, CLI tools.

Step 5 — Plan the version migration you will eventually need​

FHIR releases refine the resource model and tighten conformance. Migrating means working through element changes, terminology bindings, search parameter behaviour, and re-publishing conformance artefacts — with every consuming client validated before switchover.

The safe pattern is parallel environments: run the new release alongside the current one, migrate integrations individually, and keep production on the existing platform until each has been validated.

Practical evidence​

Amakomaya operates its FHIR infrastructure publicly, which makes it usable as a worked example rather than an assertion:

The upgrade toward FHIR v6 runs alongside the current platform precisely so that integrations can be validated before they move. Access to protected resources requires authorisation issued per integration; no credentials are published.

The engineering detail is in the HL7 FHIR and healthcare interoperability case study, and the platform documentation is at FHIR platform.

CTO perspective

The question I am asked most often is some version of "should we adopt FHIR?" It is the wrong question, and it wastes a year.

FHIR is not a decision you make once, at the top. It is a target you build towards incrementally, and the first increment costs very little: expose one resource — Patient or Encounter — from one system, validated, with a published capability statement. That single step surfaces your identifier problem, your terminology problem and your data-quality problem, all of which you have whether or not you adopt FHIR.

The better question is: what is the first exchange that someone actually needs? Build that one properly, against the national profiles, and let the second one reuse the identifier work. Estates that try to specify everything before exchanging anything tend to produce documents rather than exchange.

One caution on version choice: aligning to the national guide's release is usually right, but check the tooling maturity for that release in your stack before committing. Being conformant to a specification your libraries handle poorly is its own kind of technical debt — and running two releases in parallel during a transition is a normal cost, not a failure.

Frequently asked questions​

Does Nepal have a national FHIR implementation guide?
Yes — the Nepal HMIS FHIR Implementation Guide, published under the Ministry of Health and Population's integrated HMIS work. At the time of writing it is a draft ballot version built on FHIR R5 and includes CodeSystem, ValueSet and ConceptMap artefacts.
Which FHIR version should an implementation in Nepal target?
Align to the release the national implementation guide targets, currently FHIR R5, while checking that your server and client libraries support it well. Running a second release in parallel during a migration is normal practice.
Is FHIR in production across Nepal's health systems?
Adoption varies by system and should be verified per system. A national guide in draft indicates direction, not universal deployment; claims of national FHIR coverage should not be assumed.
What is the hardest part of a FHIR implementation?
Patient identity. Systems that cannot agree which identifier is authoritative, and how to match records that disagree, cannot exchange patient data reliably regardless of the standard or the tooling used.

Sources

  1. Nepal HMIS FHIR Implementation Guide (draft, v0.0.1-ballot), Ministry of Health and Population, Government of Nepal. fhir.hmis.gov.np
  2. HL7 International. FHIR specification. hl7.org/fhir
  3. HL7 International. FHIR Implementation Guide registry. fhir.org/guides/registry
  4. 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
Last updated on