NHCX Eligibility and Coverage

Overview

Before treatment, you verify that a patient's policy actually covers the planned procedure. NHCX answers this with two kinds of request — an Insurance Plan request for the plan itself, and a Coverage Eligibility request whose purpose decides which question it answers.

There are two ways to start a policy lookup:

• Get Policies — look up the patient's policies automatically using their ABHA number, mobile number, or member ID.
• Discover Policies — manually enter subscriber/beneficiary/policy details and run a Discover request.

The four coverage purposes

Each purpose answers a different question, and each has its own screen. They are not interchangeable.

A request may carry two purposes at once. validation is the only purpose that returns a wallet; benefits and auth-requirements need at least one item.

All of these are run from the patient's NHCX page or the case form — there is no separate coverage page to open.

Where to find it

Open the patient's NHCX page and choose Get Policies. If the lookup returns no policies, a Discover Policies fallback appears inside the same popup.

Step 1 — Get Policies

Use Get Policies when you want the system to pull the patient's existing policies.

1. Choose the Identifier Type: AbhaNumber, MobileNo, or MemberId.
2. Enter the Identifier Value (pre-filled from the patient record where possible).
3. Click Get Polices.

The results list each policy with its AbhaNumber, Member Id, Product Id, Payer, and Processor. The Insurance Plan action on a row sends an InsurancePlan request for that policy and records the plan against a case.

Every plan and coverage request names the hospital by its HFR ID — the facility ID on the organization's record. The request is taken from your signed-in organization, so it is always the hospital the payer sees. If the organization has no HFR ID, the request stops before it is sent.

This popup is used before the case exists — it looks up policies for the patient, not for a particular case. Every action taken from it therefore starts its own case: Get Plan opens a case carrying the plan request, and Discover opens a case carrying a coverage-eligibility request. If you did not intend to start a new case, leave the popup and request the plan from the case's row on the patient's NHCX page instead — that path attaches to the case you are looking at.

Plans stay fresh automatically: a plan is re-downloaded from the payer only when its last successful download is more than 15 days old. Loading a plan that was downloaded within the last 15 days is served instantly from the stored copy, and a nightly background refresh keeps every plan within that 15-day window without any manual action.

Requesting a plan (Get Plan) attaches the request to that case's workflow, so the case itself records that the plan was requested. On the patient's NHCX page the plan is requested from the workflow's Discovered Policies dialog, where each policy row offers one action at a time: Validate until a validation has been submitted for the case, then Get Plan. Validate submits the check on the case straight from the dialog — the fields are already filled from the discovery, so there is no form to re-confirm and no separate page — and it carries the Relationship recorded when the case's own coverage check was raised. The case records the validation first, then the plan. (This is a process rule, not a technical one: the plan request does not need the validation's result.) Once a plan request has been sent for a case, Get Plan is no longer offered for it and the Get wallet action becomes available instead. The payer returns the InsurancePlan asynchronously — or immediately from the stored copy when a recent plan already exists.

Validate is only offered once the payer has answered the discovery — the dialog shows Awaiting the payer's policy list until then, and the button is disabled. A validation has to name a policy code the payer recognises, and before the response arrives the only details on the case are the ones typed into the request form (often the member ID, not a policy), which the payer refuses. The dialog reads the policy code from the payer's own response, so once a validation has been posted the row keeps offering the code the payer named rather than the one the request used.

Whichever Get Plan you use — the one in the Insurance Plan column of this popup, or the one in the workflow's Discovered Policies dialog — the page refreshes automatically once the plan has been requested, so the workflow table reflects the request without a manual browser reload. A plan served from the stored copy is confirmed by the message Returned stored insurance plan.

Running Validate on a discovered policy posts the eligibility check against that case's workflow immediately — from the workflow's Discovered Policies dialog the check goes straight out, with no separate page — so the discovery, the validation and the plan request all land in one flow rather than each starting a new one.

Step 2 — Discover Policies

Use Discover Policies when you already have the policy details.

1. Set Service Start / Service End and the Relationship.
2. Fill Subscriber ID, Beneficiary ID, and Policy Number.
3. Choose the Payer from the searchable dropdown — type to filter by payer name or participant code (lists both government and private payers). Tick Government payers only to narrow the list to government payers; government payers also carry a GOV badge.
4. Click Discover to find policies.

Once the discovery is sent, the page refreshes automatically — the popup closes and the workflow table reloads to show the new in-progress row. You do not need to reload the browser by hand. The earlier "No policies found for this identifier" fallback clears with it, because the discovery has now been raised; the payer's answer arrives asynchronously, so give the workflow table a moment before re-running Get Policies.

Discover is the only action here — it is the request that finds the policies and records them against a case. To validate a policy, work from the case itself: the workflow's Discovered Policies dialog offers Validate on the discovered policy (see Step 1).

Step 3 — Wallet (validation)

A validation response can carry the policy wallet — whether the policy is in force, the coverage period, and the available balance. On the patient's NHCX page use Get wallet to run the validation against the patient's workflow; the wallet summary then appears on the workflow accordion and Kanban card, and in the read-only Policy validity & wallet strip in the top-right corner of the pre-authorization and claim forms.

The wallet is optional. It is offered once a plan request has been sent for the workflow, and it never gates the case: Pre-authorization, Search, and the rest of the case actions appear as soon as the plan request is recorded, whether or not the payer reports a wallet. Some payers (unlike PMJAY) do not send a wallet balance at all — a case from such a payer still proceeds normally.

If the payer refuses the validation, Get wallet shows the payer's own error code and message instead of a wallet. Once the wallet is known, a claim whose total exceeds the balance opens a Copayment panel in the claim form — see NHCX Claim.

The strip also names the Scheme (the plan's product name) and the Benefit limit (the amount the payer last reported through Get wallet), and carries a status chip: Active, Inactive, Expired, Admission after expiry, Not yet active, Expires soon, Check dates, or Status unknown. The chip reports Unknown when the payer has never said whether the policy is in force — "nothing reported" is never shown as an explicit Inactive.

Step 4 — Benefits and auth requirements

The benefits and auth-requirements purposes are run from the Coverage Eligibility Check panel on the pre-authorization form, after the items are entered — there is no separate page. Check Coverage sends the request with the selected purpose, then fills each item's allowed amount and collects the payer's mandatory document codes and questionnaires. The panel, the purpose selector, and the item table are documented in NHCX Claim.

When the policy stops the run (TC-03)

An ineligible policy blocks the pre-authorization and claim outright — the form is hidden and a red message names the reason, and on the patient's NHCX page the case row withholds Preauthorization, Enhancement, Resubmit, and Claim and shows the same reason where those buttons were. The policy is treated as ineligible when:

• the policy's validity end date has passed;
• the policy's validity start date is in the future;
• the payer reported the policy as not in force; or
• the encounter's admission date (DOA) is after the policy end date — the stay is not covered.

A near-ending policy warns instead of blocking, and the form stays submittable: an amber message appears when the policy ends within the next 30 days, or when the encounter's discharge date (DOD) falls after the policy end. Both matter because a DOA or DOD that overruns the end date can derail the claim — confirm coverage with the payer before relying on it. The DOA and DOD are the encounter's admission and discharge dates on the pre-authorization/claim form.

An unvalidated policy (Status unknown) never blocks, and the wallet is not required to proceed — run Get wallet only when you want the status resolved.

Common Issues

• "At least one item is required" — only benefits and auth-requirements need items. discovery and validation do not; if you see this on a validation, no items were sent with a non-validation purpose.
• "Item N: Quantity cannot exceed the X cycles allowed for this procedure" — raised from the pre-authorization form's coverage check: the item is a cyclical procedure and its Quantity is above the cycle count the plan allows. Lower the Quantity (or pick a different procedure). A procedure the plan does not mark cyclical is never capped.
• Get Plan is missing from the row — the row offers Validate until a validation has been submitted for this case, then offers Get Plan instead. Click Validate in the dialog; the request is posted on the case immediately, the page reloads, and the row offers Get Plan.
• Validate is disabled ("Awaiting the payer's policy list") — the payer has not answered the discovery yet. The dialog needs the payer's own policy code to validate; wait for the discovery response, then reopen the dialog.
• The payer answers a validation with HBP016 — No policies available for the selected policy code — the payer does not recognise the policy code the validation named. This is the payer's own refusal of the posted request, not a submission error: the validation is still recorded, so Get Plan still unlocks and the dialog carries on with the policy code the payer named in its discovery response.
• "Organization has no ABDM HFR ID — enter the facility ID in Admin → Organization → Edit" — the organization record has no facility (HFR) ID, so Get Plan and Get wallet stop before sending anything to the payer. Enter the facility ID under Admin → Organization → Edit, then retry. Nothing is recorded against the case by the stopped request.
• The case shows "Insurance plan request refused by the payer: …" — the payer declined the plan request, usually because the hospital is not empanelled for this HFR. The refusal is recorded on the case with the payer's own code and message, and the failed step still opens its FHIR. Confirm the HFR is empanelled with that payer, then request the plan again — each attempt is a new exchange.
• Get wallet is not shown — the case has no plan request yet. In the workflow's Discovered Policies dialog, submit Validate, then Get Plan; once the plan request is recorded against the case, Get wallet appears and Get Plan disappears. The wallet is optional — the case actions do not wait for it.
• The preauthorization/claim form is missing and a red message says the policy is expired or inactive — this is TC-03: the beneficiary is not eligible, so the run is stopped. The message names the reason (expired, not yet active, reported not in force, or an admission date after the policy end). Renew the policy or correct the dates, then reload — the form returns once the policy is valid.
• The case row shows no Preauthorization / Claim button, only a red reason — the same ineligible-policy block, applied on the patient's NHCX page. Cancel Preauth and the query-response actions stay available so an open case can still be closed or answered.
• An amber "expires soon" or "discharge after policy end" message appears but I can still submit — this is a warning, not a block. The policy ends within 30 days, or the encounter's DOD is after the policy end. You can proceed, but the payer may not cover a stay or discharge past the end date — confirm with the payer.
• The status chip reads "Status unknown" — the payer has not reported whether the policy is in force. This never blocks; running Get wallet resolves it, and some payers never report a wallet at all.
• "Subscriber ID / Beneficiary ID / Policy Number is required" — these fields are mandatory on the Discover Policies form; fill them or run Get Policies to populate them.
• No procedures listed after choosing a benefit category — the plan may have no mapped benefits; check the insurance plan data. The benefit-category selector is on the pre-authorization form's item table.

FAQ

Q: What is the difference between Discover and Validate? A: Discover asks the payer what policies exist for the given subscriber details, and is raised from the Get Policies popup. Validate confirms whether a specific policy number is valid for that beneficiary, and is raised from the workflow's Discovered Policies dialog against the case.

Q: When should I use Get Policies vs Discover Policies? A: Use Get Policies when you only have the patient's ABHA/mobile and want the system to find their policies. Use Discover Policies when you already know the policy number and payer.

Q: Do I have to enter items? A: Only for benefits and auth-requirements. Those two are raised from the pre-authorization form's Coverage Eligibility Check panel, where the items already exist. discovery and validation are sent with an empty item list.

Q: Must I fetch the wallet before I can start a pre-authorization? A: No. The case actions appear as soon as the insurance plan is requested. The wallet is optional information — some payers do not send one. When a wallet is available it is shown on the case and drives the copayment panel in the claim form.