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

FHIR Platform

Healthcare interoperability is part of Amakomaya's technology infrastructure, not a side project. Our platform uses HL7 FHIR as the exchange model between the systems we build and the systems we integrate with.

This page describes the FHIR environments Amakomaya operates and how to work with them.

Environments​

FHIR platform​

https://fhir.amakomaya.com

The current FHIR environment. It hosts the resource endpoints and conformance artefacts used by Amakomaya integrations.

FHIR v6 upgrade​

https://fhir.amakomaya.com/v6

Amakomaya is upgrading its healthcare interoperability infrastructure toward FHIR v6, creating a stronger foundation for modern digital health data exchange and integration.

The upgrade environment runs alongside the current platform. Integrations are validated there before they are moved, so production services continue to run on the current FHIR platform until each one has been migrated.

Access

Reading the capability statement of a FHIR server tells you what it supports; reading patient data does not. Access to protected resources requires authorisation issued per integration. No credentials, tokens or private endpoints are published on this website — contact us to start an integration.

Why FHIR​

Health data in Nepal is produced by many systems that were never designed to talk to each other: hospital systems, laboratory systems, programme-specific registries, community health tools and national reporting platforms. FHIR gives those systems a shared vocabulary:

  • Resources — Patient, Encounter, Observation, Immunization, Organization and others model the things clinical systems already record.
  • RESTful APIs — predictable GET/POST/PUT operations over HTTPS, which means integrations can be built by any team with an HTTP client.
  • Profiles and conformance — a server can publish what it supports, so integrators can validate against it instead of guessing.
  • Terminology binding — codes from ICD, SNOMED CT and LOINC travel with the data.

Background reading: HL7 FHIR, FHIR servers and HAPI FHIR in the Awesome Health knowledge base.

What the FHIR v6 upgrade changes​

FHIR releases refine the resource model and tighten conformance rather than replacing it. Planning an upgrade therefore means working through:

  1. Resource and element changes — fields that changed cardinality, type or name between releases.
  2. Terminology and value sets — bindings that moved or were made stricter.
  3. Search parameters — queries an integration depends on may behave differently.
  4. Conformance artefacts — profiles, extensions and capability statements have to be re-published against the new release.
  5. Client migration — every consuming integration is validated on /v6 before it is switched over.

Running both environments in parallel is what makes that sequence safe.

Designing an integration​

Identifiers are where most integrations succeed or fail. The repository's use case notes go through the details:

  • FHIR identifiers — naming systems, identifier scoping and cross-system patient lookup.
  • FHIR, OMOP and openEHR — where each model fits, and why exchange, analytics and clinical modelling are different jobs.
  • Data first — designing around the data before the interface.
Last updated on