NHCX Check Eligibility Coverage

Overview

Before treatment, you verify that a patient's policy actually covers the planned procedure. This is the Check Eligibility Coverage step. The system sends a CoverageEligibilityRequest to the payer and records the payer's response against the patient's workflow.

There are two ways to start:

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.

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.

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

The results list each policy with its AbhaNumber, Member Id, Product Id, Payer, and Processor. Use the Insurance Plan action on a row to load that plan's benefits into the eligibility form.

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.

Set Service Start / Service End and the Relationship.
Fill Subscriber ID, Beneficiary ID, and Policy Number.
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.
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 — Eligibility form

The Eligibility section captures the request:

Service Start / Service End — the treatment period.
Priority — request priority (default Normal).

The Coverage section has:

Purpose — fixed to validation. The other purposes (benefits, auth-requirements, discovery) are listed but disabled — this page validates a policy against the patient's ABHA / member ID. auth-requirements coverage runs inside the preauthorization form instead.

A validation response can also 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. Get wallet is offered only after a plan request has been sent for that workflow (see Step 1). 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.

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 — run Get wallet to resolve the status.

The Coverage Details (Optional) panel is collapsed by default — expand it to fill in the policy details:

Doctor — the attending practitioner (optional).
Subscriber Id (Policy Holder ID) — the policy holder.
Beneficiary ID — the person being treated.
Policy Number.
Relationship — how the beneficiary relates to the subscriber (default Self). A validation raised from the workflow's Discovered Policies dialog uses the relationship recorded on that case's own coverage check instead of the Self default, so a spouse or dependent discovery is validated as such.

Step 4 — Items

Items are entered through a table. The row at the top is the only editable one; rows appended below it are read-only apart from Quantity.

Fill the top row, then click + Add to append it to the table:

Benefit Category — loads the applicable product/service options from the insurance plan.
Product/Service — the specific procedure.
Stratification and Implant codes — appear only when the selected procedure requires them. A procedure the plan allows more than one of gets one dropdown per slot the plan permits, and the implant list is limited to that procedure's own implants. Leaving one unselected does not block the check or the submission. Only the plan's own count limits are enforced: more stratifications/implants than the plan allows — across items, not just within one — is refused, and the message names the limit.
Quantity — how many of the procedure are requested. For a cyclical procedure (e.g. chronic haemodialysis) this is the number of treatment cycles, so it cannot exceed the cycle count the insurance plan allows for that procedure — the field caps itself at that number and the check is repeated on submit, naming the item if it is over. A cyclical row shows its cap (max N cycles) under the Quantity box.

Once added, a row can only be changed through its Quantity box, or removed with Remove and added again. The count of items sits next to the Items to check heading. A row whose product is priced by the payer at adjudication carries a Rate TBD badge.

The top row keeps what you entered after an item is added, so you can click + Add again straight away to add another. Change the category or the product in the row first when the next item differs.

No items are needed here — a validation request can be sent with an empty item list.

Common Issues

"At least one item is required" — this page sends validation, so items are optional; the message comes from a non-validation purpose (e.g. auth-requirements), which now runs in the preauthorization form.
"Item N: Quantity cannot exceed the X cycles allowed for this procedure" — 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.
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 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; run Get wallet to resolve it.
"Subscriber ID / Beneficiary ID / Policy Number is required" — these fields are mandatory; 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.

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: No — this page runs a validation request, which can be sent with an empty item list. Items are required only for benefits / auth-requirements requests, which are raised from the preauthorization form.