PMJAY on NHCX: How Hospitals Raise Ayushman Bharat Claims From Their Own HMIS (2026)

PMJAY on NHCX means a hospital can raise Ayushman Bharat (PMJAY) pre-authorizations and claims from its own hospital software (HMIS) and send them through the National Health Claims Exchange, instead of typing each case again into the TMS 2.0 Provider portal. The payer side does not change: the case still reaches the same TMS 2.0 Payer system and the same insurer or State Health Agency review. What changes is the hospital desk. Data is entered once, in the HMIS, and sent as structured records.

NHA has published the rules for this in its NHCX sandbox portal under "HMIS documents": an integration overview, an integration guide, a hospital migration process, test cases and sample messages. Hospital software teams are testing it in the sandbox now. This guide explains it in plain words: what changes, what PMJAY needs on top of a normal NHCX insurance claim, what one patient's journey looks like, how a hospital moves over from TMS, and the mistakes that slow cases down.

In short: PMJAY on NHCX

If you run an HMIS product and want PMJAY on NHCX built into it, our ABDM and NHCX integration team does this work for hospital software vendors.

Why NHA is moving PMJAY claims into the hospital's own software

Today a PMJAY claim is processed in TMS 2.0, whether or not the hospital has its own HMIS. NHA's NHCX-PMJAY-HMIS Integration Overview names the problems plainly: data is entered twice, in the HMIS and in TMS; hospitals depend on one portal; and portal downtime, access limits and concurrent-user limits hold up the desk. (For how the TMS route works step by step, see our guide to the PMJAY claim process in TMS 2.0.)

In NHA's words, with the new route "hospitals can operate PMJAY workflows entirely within their own HMIS without mandatory portal usage. Claims move directly from hospital systems to payer systems via NHCX." The benefits NHA lists for hospitals are practical ones:

• One system for the desk. PMJAY becomes part of the normal admission and billing workflow, and staff are trained on one system instead of two.
• No portal bottleneck. Portal downtime and concurrent-user limits stop affecting the hospital's PMJAY work.
• Data entered once. PMJAY data captured in the HMIS is reused for the claim, which cuts retyping errors.
• Cleaner books. PMJAY claims flow into the hospital's own billing and accounts, which makes reconciliation and audits simpler.
• Choice of software. Hospitals are no longer tied to one PMJAY system and can use any ABDM-enabled HMIS.

What PMJAY adds on top of a normal NHCX insurance claim

If your HMIS already sends private insurance claims over NHCX, PMJAY needs four extra things. Everything else, from policy lookup to payment notice, works the same way.

1. The insurance plan comes first. PMJAY relies heavily on the InsurancePlan record, which is set up for each hospital. NHA calls it "a key reference for scheme operations" because the rules for pre-authorization and claims come from it. The HMIS should fetch it and keep it up to date.
2. Biometric authentication of the beneficiary. PMJAY "mandates biometric authentication of a beneficiary during registration, treatment and discharge." That means fingerprint, iris or face authentication through an extra API, done before the pre-auth and again at discharge.
3. Structured health data. Supporting information must be sent as ABDM-defined health information types, for example a structured discharge summary, not only as scanned documents.
4. Queries on the same case. The PMJAY payer does not use the NHCX Communication API. It raises a query against the pre-auth or claim, and the hospital answers on that same case with the same message structure.

This is also the short answer to the question hospital teams ask most often: "What extra do we have to do for PMJAY?" Set up the plan, add the biometric step, send structured data, and handle queries inside the case.

One PMJAY patient, start to finish, inside the HMIS

Here is what the hospital desk does for one PMJAY patient, and what the HMIS sends behind each step. Each step is one screen for staff and one NHCX call behind it.

One thing surprises teams used to web portals: NHCX does not answer instantly. The first response only says the request was received. The actual decision (approved, query, rejected) arrives later on the hospital's callback URL. The HMIS has to store each case's status and show staff the decision when it lands. We explain the pattern in NHCX asynchronous callbacks for an HMIS, and the cover check in the NHCX coverage eligibility check.

What PMJAY on NHCX looks like inside an HMIS: five screens

We built PMJAY on NHCX into an existing hospital system (an ASP.NET HMIS already used for private insurance cashless cases). The design choice that mattered most: no new PMJAY module. NHCX calls were attached to the screens the desk already used, the admission screen, the cashless authorization dialog, the IPD bill, the discharge screen and the receipt, plus one operations console. The screens below are redrawn with synthetic data to show each workflow; they are not screenshots of a real patient.

Screen 1: admission, policy search and cover check

The desk selects PMJAY as the insurer. ABHA and mobile fill from registration, the HMIS searches the beneficiary's policies through NHCX, and selecting one starts the cover check and shows the wallet left. The beneficiary's biometric check is recorded here.

Screen 2: the PMJAY pre-auth in the cashless dialog

For PMJAY, the package code replaces the procedure code. The package brings its own standard treatment guideline (STG) questions from the insurance plan, the desk answers them, attaches the declaration and documents, and records any implant as its own item. The biometric check is repeated before the pre-auth is sent.

Screen 3: a payer query answered on the same case

The case history shows every message both ways. When the payer raises a query, the desk replies on the same case, which the HMIS sends as a resubmission with a new correlation ID. Approvals, queries and refusals each have their own colour, so nothing waits unnoticed.

Screen 4: the claim from the IPD bill

The discharge type decides the form, the documents and the shape of the claim. The HMIS names any missing document before sending, so a claim never leaves incomplete.

Screen 5: dialysis cycles and the case worklist

Cyclic procedures need one clinical record and one presence check per cycle. The worklist replaces refreshing a portal: every case shows its stage and latest payer answer.

PMJAY cases an HMIS must handle beyond a clean approval

NHA's PMJAY material covers more than approve and pay. These are the cases we had to build and test, each with its own rule:

To keep ourselves honest we traced every requirement (72 in total across the NHCX and PMJAY flows) to NHA's published material and to the automated tests that exercise it, and wrote a 36-step PMJAY walkthrough of the screens. The same discipline is what an HMIS vendor needs before the PMJAY team demo.

How to test PMJAY on NHCX with NHA's dummy payer

In the sandbox there is no real insurer on the other side. NHA provides a dummy payer that a developer can instruct to answer, so every branch of the flow can be tried end to end. It is NHA's API, called with the same sandbox session token:

# Make the sandbox payer decide on a pre-auth or claim you sent
curl -sS -X POST 'https://apisbx.abdm.gov.in/pmjay/sbxhcx/dummyhcxpayer/process/request' \
  -H "bearer_auth: Bearer $TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{
        "action": "Approve",
        "method": "Preauth",
        "correlationId": "<correlation ID of the request you sent>"
      }'
# action: Approve | Reject | Query      method: Preauth | Claim

# Make it send a payment notice for an approved claim
curl -sS -X POST 'https://apisbx.abdm.gov.in/pmjay/sbxhcx/dummyhcxpayer/paymentNotice/init' \
  -H "bearer_auth: Bearer $TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{ "providerId": "<your participant code>", "claimNumber": "<payer claim number>" }'

The answer does not come back in that HTTP response. It arrives on your registered callback URL, exactly as a real payer's would, which is the point: you are testing your callback handling, not just your request.

Know the dummy payer's limits before you plan your test cases. In our testing it did not answer cancellation or reprocess tasks, never approved a claim in part, sent no cleared-payment status, and published no PMJAY questionnaires, so package questions had to come from NHA's published PMJAY plan. Plan separate evidence for those cases, and expect them to be checked in the PMJAY team demo.

How a hospital moves from TMS to its HMIS: six steps

NHA's document "PMJAY Hospital Migration to HMIS via NHCX" sets out the switch-over. Four steps are API calls confirmed by an OTP, one is done by NHA, and the last is go-live.

1. Create the participant. The HMIS registers the hospital on NHCX with its HFR (Health Facility Registry) ID and the mobile number registered in HFR. The mobile must match exactly, or the request fails.
2. Confirm with an OTP. A passcode goes to that mobile. Once validated, the hospital's NHCX identity (participant ID) becomes active.
3. Add the endpoint and certificate. The HMIS registers a public HTTPS callback URL that NHCX can reach, and the certificate used to encrypt messages.
4. Confirm again with an OTP. A second passcode, valid for 24 hours, activates the endpoint. NHCX can now send to and receive from the HMIS.
5. NHA maps the IDs. The hospital raises a ticket, and NHA's NHCX operations team manually links the hospital's existing PMJAY hospital ID (used in TMS) to its new NHCX participant ID.
6. Go live. The mapping is the switch-over moment. New cases go from the HMIS through NHCX.

The rule that removes most of the fear: nothing already in progress moves. Pre-auths and claims submitted before the mapping continue and close in TMS Provider; those submitted after it go through the HMIS. For hospitals whose HMIS runs on premises, the callback URL is often the hardest part; see callback URL options for on-premise HMIS.

What an HMIS must have before it can offer PMJAY on NHCX

NHA's integrator journey for NHCX-PMJAY-HMIS has three stages. NHA marks it "tentative and not final", so check the portal before you plan dates.

Two details worth knowing. The PMJAY lane asks for ABDM Milestone 1, a lower bar than the general ABDM rules many teams assume; our ABDM compliance guide for PMJAY hospitals covers that side. And NHA's dummy payer lets a team test approvals, rejections and queries without a real insurer, which is how most of the scenarios can be tried end to end in the sandbox. Our NHCX onboarding checklist lists the exit steps in detail.

Six mistakes that slow a PMJAY case on NHCX

These come from taking an existing HMIS client through NHCX-PMJAY testing in NHA's sandbox. Each one is a design rule for the HMIS screens, not a one-off fix.

1. A second pre-auth for the same patient. The payer refuses a new pre-auth while the beneficiary still has an open one at the same hospital. The HMIS should show the open case and offer to cancel it or raise the claim.
2. Reusing the correlation ID. Enhancements and query replies go on the old case reference, but every new message needs a new correlation ID. NHCX treats a repeated one as a duplicate.
3. A diagnosis without a code. Free text such as "abdominal pain" is not enough; each diagnosis needs its ICD-10 code, and each procedure must map to the right PMJAY package. See procedure to insurance package mapping.
4. Waiting on the screen for an answer. The first reply is only an acknowledgement. Build a worklist that shows each case's latest status as callbacks arrive.
5. Retyping what the HMIS already knows. ABHA number, mobile, policy and patient details should fill from the admission. Retyping brings back the very problem PMJAY on NHCX is meant to remove.
6. Messages staff do not notice. Approvals, refusals and queries need clear colours and a place on the worklist, or a query sits unanswered and the case stalls.

The PMJAY on NHCX flow chart, end to end

The chart below puts the whole flow on one page: what the hospital must have before the first case, then registration and cover, pre-authorization with queries, enhancement and cancellation, discharge with the biometric check and forms, the claim including LM100 and reprocess, and payment. Decisions, loops and the lane each step belongs to are drawn as a swimlane flowchart; purple-bordered steps are the ones only PMJAY needs. Tap the image to open it full size.

PMJAY on NHCX claim flowchart. Before the first case the HMIS needs ABDM Milestone 1, an NHCX participant confirmed by OTP, a registered callback URL and certificate, and NHA's mapping of the PMJAY hospital ID. Every message is an encrypted FHIR bundle with a new correlation ID, and one workflow ID covers the whole admission. Solid arrows are requests; dashed arrows are answers that arrive later on the callback URL.

Where PMJAY on NHCX stands today

The documents, APIs, test cases and sample messages are published in the NHCX sandbox portal, and HMIS teams are testing against NHA's dummy payer. NHA's overview says that after the technical changes by the TCS team, it "will kick off Pilot with 5 PHR players and 5 Insurance Companies, to test this functionality in real world." Until a hospital is mapped, its PMJAY cases continue in TMS 2.0 as today.

For hospitals, the practical step now is to ask your HMIS vendor whether PMJAY on NHCX is on its roadmap and when it will clear the sandbox. For HMIS vendors, the work is the four PMJAY additions above on top of a sound NHCX claims module. Our NHCX guide for hospital leaders and which HMIS modules NHCX affects help scope it.

Building PMJAY on NHCX into your HMIS? Our ABDM and NHCX integration engineers take HMIS products through ABDM Milestone 1, NHCX sandbox testing and the PMJAY use cases. Talk to our team for a scoped review of your HMIS against the PMJAY requirements.