Most Indian HMIS products were built years before the National Health Claims Exchange existed. The question their engineering teams now face is not "can we integrate NHCX" — it is "can we integrate NHCX without destabilizing a product that hundreds of hospitals run daily." The answer is yes, if the integration is designed as a self-contained layer rather than threaded through the core.
This guide describes a reference architecture for exactly that: an adapter-layer approach that keeps your existing HMIS untouched, the components the layer needs, the deployment pattern that solves the callback problem for on-premise installations, and the path from sandbox to production.
The design principle: adapt, don't rewrite
NHCX asks your product to do things it has never done: speak FHIR, sign and encrypt messages per receiver, and process asynchronous callbacks from a national gateway. None of that belongs inside your registration, billing, or EMR modules.
The reference architecture puts everything NHCX-specific in one adapter layer between your HMIS core and the exchange:
- Existing HMIS (unchanged): registration, billing, EMR, discharge — they keep working exactly as they do today, exposing the data the adapter needs through an explicit contract interface on your existing internal APIs (prefer this over raw database views — views couple the adapter to your schema and break on core releases).
- NHCX adapter layer (new): everything the exchange requires, in one deployable unit.
- National rails: the NHCX gateway, and behind it every insurer and TPA.
For Indian HMIS stacks the adapter ships as a native component — .NET for ASP.NET products, Java or Node equivalents elsewhere — or as a sidecar service where your team prefers isolation.
The payoff of this shape: your core release cycle and the NHCX integration evolve independently. Certification testing exercises the adapter, not your whole product. And the same adapter can serve every hospital deployment you have.
Inside the adapter layer: six components
1. ABHA identity (ABDM Milestone 1). Every claim on NHCX is anchored to the patient's ABHA. The adapter needs ABHA creation, verification, and linking — and if you have already done ABDM M1, this component exists; the adapter reuses it. If you have not, M1 is the mandatory first phase of the program (NHCX is a separate track from the ABDM milestones, but M1 is its entry condition).
2. Claim bundle builder. Transforms your billing and clinical data into the standardized FHIR claim structures the exchange requires (the national NRCES profile set). This is where a discharge summary, an itemized bill, and a diagnosis list become a valid digital claim. The profiles are strict about structure and required fields — this component is where spec-reading effort concentrates.
3. Code mapping. Your charge master and diagnosis entries are internal vocabulary; the exchange requires standard code sets. This mapping is per-customer work (every hospital's charge master differs), so build it as configuration with a review UI, not as code. It is consistently the most underestimated component.
4. Security envelope. Every message is signed and encrypted for the specific receiving insurer, using keys looked up from the exchange's participant registry. Key material differs between sandbox and production, and rotation must be handled operationally. Isolate all of it here so nothing else in your product touches cryptography.
5. Callback receiver. Insurer responses do not come back on your request — they arrive later as separate incoming messages. The receiver validates, decrypts, and hands them to the correlation store. It must be idempotent: the same callback can arrive more than once, and processing it twice must not create two claim updates.
6. Correlation store. Every outgoing request is recorded with its identifiers; every incoming callback is matched back to its request. Correlation mistakes are the classic silent failure of national-rail integrations — nothing errors, responses simply never arrive. Persist every request, match strictly, and alert on unmatched callbacks and on requests with no callback after a threshold. This store also becomes your claim-status timeline for free: it is what powers the "where is this claim" screen your hospital users will ask for.
The deployment problem: callbacks versus on-premise installations
Cloud-hosted HMIS products can expose a public callback endpoint directly — for them, the adapter layer deploys alongside the product and the story ends there.
On-premise installations — still the majority for Indian hospital software — cannot. The HMIS sits inside the hospital's private network with no public address, so the gateway's callbacks have nowhere to land. Outbound requests work fine; the return path is blocked.
The standard solution is a relay bridge: a small, publicly reachable service (one per vendor, not per hospital) that receives callbacks for all your deployments, queues them durably with retries, and forwards each to the right hospital's HMIS over a secure tunnel your installation already maintains. Three design rules make it dependable:
- The bridge holds no business logic. It receives, queues, routes. All claim processing stays in the adapter at the hospital. This keeps the bridge small, auditable, and rarely changed.
- Queue durably, deliver at-least-once. Hospital networks drop; a callback that arrives while the tunnel is down must survive and deliver later. Combined with an idempotent receiver, at-least-once delivery is safe.
- Route by participant identity. The bridge maps each callback's addressee to the right hospital deployment. Getting this mapping wrong sends one hospital's claim responses to another — treat routing configuration as production-change-controlled.
Data protection at the bridge
Treat the bridge as a data processor and design for the DPDP Act from day one: it should hold only the encrypted envelope — never decryption keys, which stay inside the hospital deployment — purge messages on confirmed delivery, and keep a complete audit log of every receipt and forward. Done this way, the bridge concentrates traffic without concentrating readable health data, and your hospital customers' security reviews have a clean answer before they ask.
If you have deployed ABDM M2/M3 for on-premise hospitals, you have already solved this problem once; the same bridge pattern (and often the same infrastructure) extends to claims callbacks.
The asynchronous flow, end to end
A claim submission on NHCX looks like this in practice:
- The adapter builds the FHIR claim bundle, signs and encrypts it, and posts it to the gateway.
- The gateway acknowledges receipt immediately — this acknowledgement means "accepted for routing," not "approved."
- The gateway forwards the message to the insurer.
- The insurer processes — minutes or hours later.
- The insurer's decision travels back through the gateway and arrives at your callback endpoint (or bridge) as a new incoming message, which the correlation store matches to the original claim.
Design your hospital-facing UI around this reality: claim states are submitted → acknowledged → responded, with timestamps from the correlation store. Never present the gateway acknowledgement as an approval; that mistake surfaces as angry hospital billing teams.
Sandbox to production: the program shape
- Phase 1 — Foundation. ABDM M1 live (or built), HFR IDs for pilot facilities, NHCX participant registration and sandbox credentials.
- Phase 2 — Sandbox build. Implement the five claim flows (eligibility, pre-auth, claim, settlement tracking, communications) against the test gateway. Get one flow working end to end — envelope, submission, callback, correlation — before widening; the plumbing is 80% of the difficulty and it is shared by every flow.
- Phase 3 — Certification. Clear the official test scenarios. Study them before building, not after — teams that build to the spec document alone routinely discover gaps at certification and lose cycles to rework.
- Phase 4 — Production. Production keys and participant identity, then per-facility go-live (each hospital has its own HFR identity), with monitoring on the correlation store's two health signals: unmatched callbacks and unanswered requests.
With M1 already live and the certification scenarios studied up front, phases 2–4 are a matter of months, driven mostly by testing and scheduling rather than code volume. Starting without M1 adds a quarter or more before claims work can begin.
One layer, two rails
The strongest architectural argument for the adapter approach is reuse. ABDM records exchange (M2/M3) and NHCX claims share the same foundations: FHIR profiles from the same national body, registry-based identity, signed/encrypted envelopes, asynchronous callbacks, the same on-premise bridge problem. An adapter layer designed for claims is 60–70% the same machinery as one designed for records. Vendors who treat these as one interoperability investment — rather than two projects — pay for the hard parts once.
Where Nirmitee.io fits
We are a healthcare interoperability company, and this architecture is not theoretical for us: we have built and certified ABDM integrations for HMIS vendors — sandbox through production, including the on-premise bridge pattern running in live hospitals — and we build FHIR foundations across both Indian and international rails. Our NHCX engagement delivers the adapter layer and bridge as maintained components, the code-mapping tooling, and hands-on support through sandbox and certification — so your product gains claims capability while your engineers stay on your product.
On NHCX itself, our position is stated plainly: the payer side is live, and we are taking an existing HMIS client through NHCX onboarding toward go-live now — the architecture above is the one we are running, not a thought experiment. Our ABDM work is public: the open-source ABDM Node SDK, V3 Postman collection, FHIR bundle examples and error catalog.
For the commercial side of this decision, see the NHCX readiness guide for HMIS vendors; for the hospital-side context your customers are reading, the hospital leaders' guide to NHCX.
Planning your NHCX architecture? We'll review your current HMIS architecture and map the shortest certified path. Explore our Healthcare Interoperability Solutions and Healthcare Software Product Development services, or talk to our team.
