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

Case Study: HL7 FHIR & Healthcare Interoperability in Nepal

Case studyBy , Co-Founder & CHIO, Aamako Maya Apps Pvt. Ltd.Published 13 min read

The problem​

Health data in Nepal is produced by systems that were never designed to talk to each other: hospital systems, laboratory systems, programme registries, community health tools and national reporting platforms. Each is defensible on its own terms. The difficulty is at the seams.

Nepal now has a national FHIR implementation guide in draft — the Nepal HMIS FHIR Implementation Guide, published under the Ministry of Health and Population's integrated HMIS work and built on FHIR R5. That changes integration from a bilateral negotiation into conformance against a published target, which is the single most useful development for implementers in this space.

But a guide is not an exchange. Between them sit the questions this case study is about.

Architecture​

The FHIR platform​

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

The platform hosts the resource endpoints and conformance artefacts used by our integrations. Access to protected resources requires authorisation issued per integration; no credentials are published, and the capability statement is the thing integrators should read first.

Identifiers, which decide everything​

Before writing integration code the question that has to be answered is: which identifier is authoritative for a patient here, 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. This is the part of the work that keeps paying: application code is replaceable, but the naming systems, the matching rules and the decision about what is authoritative are the reusable asset.

Terminology​

Codes have to travel with meaning, which means mapping local codes to published systems — ICD for classification, SNOMED CT for clinical meaning, LOINC for observations — and maintaining that mapping as versioned metadata rather than performing it once during a migration.

Related work here includes terminology and concept management for HMIS, keeping data definitions consistent across systems rather than per-project.

Middleware, not point-to-point​

Ten systems connected directly to each other imply up to forty-five interfaces, each with its own authentication, mapping and failure behaviour. The eleventh system means ten more.

Middleware as a Service is the answer to that curve: a cloud-based integration layer where each system integrates once — authentication, routing, transformation, audit, and rejection of non-conformant payloads in one place instead of n places. The pattern is the interoperability layer described in the reference architecture and in OpenHIE.

Crucially, transformation belongs in the mediator. Put it in the point-of-service system and every system ends up carrying knowledge of every other system.

Implementation: the FHIR v6 upgrade​

The interoperability infrastructure is being upgraded toward FHIR v6, with the upgrade environment running alongside the current platform rather than replacing it.

The pattern matters more than the version number. A FHIR version migration means working through:

  1. Element changes — fields that changed cardinality, type or name.
  2. Terminology bindings — bindings that moved or were tightened.
  3. Search parameter behaviour — queries an integration depends on may behave differently.
  4. Conformance artefacts — profiles, extensions and capability statements re-published against the new release.
  5. Client migration — every consuming integration validated on the new release before it is switched.

Running both releases in parallel converts that from one large irreversible migration into a sequence of small reversible ones. Production stays on the current platform until each integration has been validated on the new one.

There is a national dimension worth stating plainly: the draft national guide targets R5, and our upgrade path runs to v6. Version alignment between a national implementation guide and implementer platforms is now an architectural decision with national implications rather than a private one — and it is a question worth raising while the guide is still at ballot stage, when implementer feedback still changes the outcome.

Lessons​

1. Adopting FHIR is a data diagnosis. Exposing resources forces answers to what a patient identifier means, which code system a diagnosis belongs to, and which facility a record belongs to. Those answers were implicit before, and inconsistent where implicit. The teams that succeed treat that discovery as the deliverable of phase one and plan a remediation phase they did not originally budget for. The teams that fail call it scope creep.

2. Validate at the boundary. Rejecting a malformed resource on write costs minutes. Discovering it during analysis a year later costs a reconciliation project.

3. A public endpoint changes behaviour. When a capability statement is visible, conformance stops being an internal aspiration and becomes something external parties can check — uncomfortable and useful in roughly equal measure.

4. Aggregate reporting is not exchange. DHIS2 aggregate data elements do not map cleanly onto FHIR resources; forcing them produces resources that are technically valid and semantically confusing. The useful mapping is at tracker level, mediated by an integration engine rather than performed inside either system.

5. Mapping is a maintained product, not a migration task. It needs versions, tests and an owner, or it drifts within about eighteen months.

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 made once at the top. It is a target you build toward 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 reuse the identifier work.

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 first. 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 operating cost, not a failure.

Frequently asked questions​

What is healthcare interoperability in Nepal?
It is the ability of Nepal's health systems — hospital systems, laboratories, registries, community tools and national reporting platforms — to exchange health data in a structured, meaningful way. In practice it depends less on choosing a standard than on patient identity, facility registries, terminology and enforced conformance.
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 it includes terminology artefacts alongside its profiles.
How do you upgrade a FHIR platform without breaking integrations?
Run the new release in parallel with the current one. Migrate integrations individually, validating each on the new environment before switching it, and keep production on the existing platform until each has passed. This turns one irreversible migration into a sequence of reversible ones.
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 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. Amakomaya FHIR platform — fhir.amakomaya.com — and the FHIR v6 upgrade environment — fhir.amakomaya.com/v6
  4. OpenHIE Community. OpenHIE Architecture Specification. ohie.org
Last updated on