--- title: "NHCX Check Eligibility Coverage" description: "How to check a patient's policy coverage and eligibility before starting treatment, including Get Policies and Discover Policies." date: 2026-08-21 lastModified: 2026-10-04 category: "nhcx" author: "Dr. Umesh Bilagi" beta: true --- ## 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. 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. 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. 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-1--get-policies)). ## 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](#step-1--get-policies)). 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](/docs/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.