NHCX explained: the claims flows, the FHIR bundles, and where AI fits

The short answer

The National Health Claims Exchange (NHCX) is the gateway NHA built under ABDM for health insurance claims. Its first version focuses on cashless claims: eligibility checks, pre-authorisation, claims and payment notices, each sent as a FHIR R4 Bundle of type collection defined in the ABDM FHIR implementation guide.¹ If an AI tool drafts any of these bundles, a person should approve it before sending, and the exact bundle sent should be kept so it can be checked later.

What NHCX is

NHA describes NHCX as a digital highway for claims information among payers, providers, beneficiaries, regulators and observers.² It is one of ABDM’s three gateways, beside the consent manager and the Unified Health Interface; our ABDM building blocks post places it in the wider network.

Adoption has been gradual. In a Lok Sabha reply published on 26 July 2024, the government said 34 insurers and TPAs were live on NHCX and about 300 hospitals were ramping up to send claims through it, with support from IRDAI and the General Insurance Council.³ The ABDM guide’s NHCX profiles are part of NRCeS’s FHIR guide version 6.5.0.¹

The flows

The guide lists the information flows NHCX’s initial version supports:¹

1. Get provider or payer details
2. Eligibility check
3. Pre-auth request
4. Claims request
5. Payment notification
6. Payment acknowledgement
7. Search or fetch claims data, for status checks and regulatory needs

For a hospital’s TPA desk, steps 2 to 4 are where most of the work, and most of the automation, sits. The hospital checks eligibility when the patient is admitted, sends a pre-auth request with the expected treatment and cost, may send updates or enhancement requests during the stay, and sends the final claim with the bill and discharge documents. The insurer or TPA answers each with a response bundle. Every one of those messages is a point where a wrong value can enter, and where a record of what was sent is worth keeping.

The FHIR bundles

Each exchange travels as a Bundle with type: collection, meaning a set of resources packaged together, not a transaction the server applies.¹ The main ones:

The use element on the Claim says whether a ClaimBundle is a preauthorization, a predetermination or a claim.¹ The guide’s NHCX profiles include claim, claim response, coverage eligibility and task bundles.¹

Because these are collections, not transactions, nothing in the format makes every entry succeed or fail together. That matters on the receiving side: check each entry, and keep the bundle as sent. Our transaction vs batch post explains the difference between Bundle types.

The time pressure

IRDAI’s health insurance master circular of 29 May 2024 asks insurers to decide on cashless requests “immediately but not more than one hour” after the request, and to give final discharge authorisation within three hours.⁴ Those deadlines push both sides towards automation. Medi Assist, a TPA, says its platforms enabled more than 186,000 pre-authorisations in under five minutes, in figures as on 30 June 2026.⁵

Fast is good for patients waiting at discharge. It also means a wrongly built bundle can be approved, or refused, before anyone looks at it.

Where AI builds claims, and what to check

AI is being applied at several points: extracting details from discharge summaries, suggesting codes, assembling documents. This table maps each step to a check that doesn’t depend on the AI being right. None of the checks are clinical; they are about data and process.

Two failure types deserve special attention. First, wrong-patient attachments: a document from the wrong record leaks one patient’s data to an insurer and is also a privacy breach. Second, codes: research on general-purpose models shows they assign billing codes inconsistently, covered in our post on LLM medical coding accuracy.

Records to keep

The ABDM FHIR guide has no AuditEvent or Provenance profile of its own⁶, so the record of who built and sent each bundle is yours to design. For every pre-auth and claim, keep:

1. The bundle exactly as sent, with a hash, so you can show later what left your system.
2. Who approved it, and when.
3. Which parts a tool drafted, and which version of the tool.
4. The response received, linked to the request.
5. Any later correction, as a new version, never an overwrite.

That record answers the questions a dispute raises: what was sent, who approved it, and what changed afterwards. The US has a parallel FHIR prior authorisation programme; our CMS-0057-F post compares the requirements. For what Deedglass does around AI agent writes in hospitals, see /healthcare; the FHIR write benchmark shows where its checks miss.

To try the checks on synthetic data, open the playground in your browser. To see what an AI agent on your machine can change, run npx deedglass scan (what the grade means) or paste its MCP config into /check; neither uploads your data. Our AI agent permissions report shows what public agent setups commonly leave open.

Written with AI assistance and checked against our claims register.