--- title: "NHCX Claim" description: "How to submit a claim for reimbursement after treatment, including enhancement of a pre-authorization and discharge details." date: 2026-08-21 lastModified: 2026-10-04 category: "nhcx" author: "Dr. Umesh Bilagi" beta: true --- ## Overview A **claim** is the formal request for reimbursement sent to the payer after treatment. The NHCX claim form collects the items, diagnoses, and discharge details, builds a FHIR `Claim` bundle, and submits it to the payer. Claims build on the earlier steps in the workflow: the eligibility check and pre-authorization provide the policy identity and approved items, which the claim references. ## Where to find it Open the patient's NHCX page, find the relevant workflow, and choose **Claim**. The form is pre-populated from the pre-authorization and eligibility data already recorded for that workflow. ## What the claim form captures The claim form includes: - **Policy validity & wallet** — a compact, read-only strip in the top-right corner of the form shows what the payer has told us about the policy: the **Scheme** (the plan's product name), its **validity window** (`Policy valid start – end`), and — once the wallet has been fetched — the **Benefit limit** in ₹ with the currency and a status chip (**Active** / **Inactive** / **Expired** / **Admission after expiry** / **Not yet active** / **Expires soon** / **Check dates** / **Status unknown**). The balance and the in-force status are returned only by the payer's coverage-eligibility *validation*, which the **Get wallet** action on the patient's NHCX page runs; until then the strip reads **Wallet not fetched** (hover it for the reason) and the chip reads **Unknown** rather than **Inactive** — a payer that reported nothing is never shown as an explicit "not in force". The strip is absent entirely when neither the validity window nor a wallet is known. Nothing here is editable — it is displayed so you can see the cover at a glance while choosing items, rather than only in the printed PDF. An **expired**, **not-yet-active**, or **reported-inactive** policy — or an admission date after the policy end — hides the form and shows a red reason; a policy ending within **30 days**, or a discharge date after the policy end, shows an amber warning but leaves the form submittable. Once the wallet is known, a claim whose items total is more than the available balance opens a **Copayment** panel below **Total** (see [Copayment](#copayment)) — the claim stays submittable, the amount sent to the payer is unchanged, but the beneficiary's share is captured and their consent is required. See [NHCX Check Eligibility Coverage](/docs/nhcx-eligibility-check) for the full eligibility rules. - **Claim items** — the procedures/services performed, with their codes, quantities, and amounts. Each item shows its **procedure type** (Surgical / Medical / Conservative), and claims accept an optional per-item **start/end date** (the service period for that procedure). Implants are emitted as their own claim item (category **Implant**), each with its own price, alongside the parent procedure. For a row whose category is not one the plan offers as a coverage — an **Implant** row, for instance — the **Benefit Category** is shown read-only instead of as a selector, so it cannot be re-categorised. - **Diagnosis** — the diagnoses tied to the claim, referenced by the items. - **Admission and discharge date/time** — the claim's billable period (Start Date / End Date), captured as a date and time and sent to the payer in IST. - **Discharge disposition** and **discharge status** — how the patient left (relevant for IPD claims). - **Questionnaire answers** — payer-specific discharge/plan questions. Attachment answers accept either an uploaded file or a **Choose from records** selection, which attaches a document already stored against the patient. - **Biometric verification** — for admission and discharge capture (see [NHCX Biometric](/docs/nhcx-biometric)). For a newborn claim, the parent relation and proof-of-birth documents are carried in automatically. See [NHCX Newborn Claim](/docs/nhcx-newborn-claim). These sections appear as collapsible accordions. A **Focus on Cost Components** checkbox sits above them. On a **claim** it is ticked by default — the **Items** and **Patient Demography** accordions are open and the other headers do not expand, so the items being billed stay front and centre; untick it to open and edit the remaining sections (Diagnosis, Care Team, Coverage, Attachments, and any questionnaires). Patient Demography stays open because a claim's **Discharge Disposition**, **Discharge Status** and **Start Date** / **End Date** — all required for a claim — live inside it. On a **pre-authorization** — including its enhancement, resubmission and query-response variants — the checkbox starts unticked, so every section is open and reachable from the outset. ### Required fields Fields marked with an asterisk (`*`) are validated on submit. If any required field is empty, submission is blocked with a `Please fill required fields: …` message that lists what is missing. For both pre-authorization and claim, the form checks: - **Required questionnaire answers** — every `*`-marked item in the loaded questionnaires must be answered. - **Care Team** — at least one doctor must be selected. - **Start Date** and **End Date** — both required, with Start Date on or before End Date (same-day discharge is allowed). For **claims only**, **Discharge Disposition** and **Discharge Status** are also required, and each item's optional **Start Date** / **End Date** is checked: an item's Start Date must be on or before its End Date, and a treatment date must not fall after the claim's **End Date** (the discharge date). ### LM-100 procedure (LAMA/DAMA discharge) For a **LAMA** or **DAMA** discharge disposition with a **Before surgery** or **During surgery** discharge status, the payer accepts only the **LM-100** procedure. The form auto-adds an LM-100 item (reusing the category of the existing items) and shows a warning that other items will be disqualified. Submitting without an LM-100 item is blocked; removing the auto-added item re-blocks submission. Changing the disposition/status away from the LAMA/DAMA trigger removes the auto-added item. When a **valid biometric token** is present, the payer's **Authentication Consent** questionnaire (including the Medical Superintendent declaration) is waived — biometric capture satisfies that requirement instead. The reverse does not hold: uploading a **Proof of identity** document does **not** waive the questionnaire. The payer accepts only biometric capture *or* the questionnaire itself, so if biometric has not been captured the questionnaire must still be filled in. ### Copayment When the claim's items total is more than the wallet balance the payer last reported (the **Get wallet** validation), the claim is **still submittable** — the payer accepts it and pays up to the available balance. What changes is that the beneficiary's share of the cost must be captured. A **Copayment** panel appears below **Total**: - it shows the **Total**, the **Wallet balance**, and the **Payable by payer** (the balance) read-only; - an editable **Copay amount** (₹) is defaulted to the shortfall — the amount above the balance — and is recorded against the hospital bill for your own reference; - a mandatory acknowledgement confirms the beneficiary was informed and consented to paying that amount beyond the wallet cover; - the beneficiary's **consent document** must be uploaded under **Attachments**. The payer's own **Patient Payment Consent** questionnaire (when the plan provides one) is force-required at claim while the panel is open; if the plan provides no such questionnaire, a **Beneficiary copayment consent form** attachment slot is added instead. A wallet the payer reported as **zero** counts the same way — the whole total becomes the default copay. The amount **sent to the payer is unchanged** — the full items total, exactly as entered. The payer decides whether the shortfall may be shifted to the beneficiary; if it declines, it refuses the claim with its own reason code (PAYR-1202 / PAYR-1233 / PAYR-1332). The panel appears only once a wallet is known; a workflow that has never run **Get wallet** shows no panel and no block. When the payer adjudicates a claim it may return its own patient-share figure, which is shown in the workflow table as **Patient share: ₹…**. ## Enhancement If the treatment requires more than what was pre-authorized, the claim can be submitted as an **enhancement**. This adds new items on top of the existing pre-authorization, numbered continuously after the pre-authorized items, so only the additional work is charged. For a pre-authorization or enhancement, the form's **Coverage Eligibility Check** panel runs the coverage check in-line: click **Check Coverage** and the system polls the payer, then populates the items, questionnaire, and allowed amounts. The button stays live while it waits — a spinner with a **Waiting for the payer… (Ns)** line counting the seconds up — so a slow payer is visibly in progress rather than looking stuck. Until the coverage check completes, the pre-authorization form (and its **Submit** button) stays hidden — only the **Check Coverage** panel is shown. Each item's **Unit Price** is filled with the amount the payer allowed for it. When the payer sends no amount for an item — or sends **0** — the price comes from your insurance plan's own rate for that procedure or implant instead. If the plan declares no rate either, the **Unit Price** stays **0** and you type the amount yourself; the field is editable on every item. An enhancement (and a resubmission) carries forward what was entered on the earlier pre-authorization — the questionnaire answers (admission details, approver checklists and similar) and the documents already uploaded or picked from records — so you only change what is different rather than re-entering every required field and re-uploading every file. ## Responding to a query The payer can answer a submission with a **query** rather than a decision — asking for something before it will go further. The patient's NHCX page shows the query on the workflow table: the row's **Status** reads **queried**, and the payer's reason is printed underneath it, so you can see what is being asked without opening anything. The same text appears on the **Respond to query** form, where a read-only **Payer query** panel sits above it, showing what was asked in the payer's own words. On the **NHCX Kanban** page the workflow's card carries it too, under the status — that card shows the reason only while the case is still queried, so a case whose query has been answered and has moved on does not keep displaying an old reason: - **Remark** — the payer's general note on the submission. - **Item N** — the payer's question about item N, when the query names a particular item. That text is the payer's free text: the reason it gave against each queried item, plus the response's overall remark. The payer sends no questionnaire and no figures along with a query, so the panel is the whole of what it asked. Answer it in the form below — add a **Response / Justification** on each item, and attach only the documents the payer additionally asks for: everything uploaded on the earlier submission is carried forward into the form and shown with an **Uploaded** badge, so already-attached files are not re-uploaded. If the payer marks an item queried but sends no reason text — its remark and questions are blank or just status words such as "ok" or "Queried" — all three surfaces say **No reason given by payer** in place of the reason. That means the reason is missing on the payer's side, not hidden by the system. You can still respond: open the form and provide whatever justification the case needs, or check the payer's own portal for the reason. ## Documents Use **Choose from records** to attach supporting documents to the claim — a discharge summary, prescription, report, or the patient's **case sheet**. For an inpatient admission, the system assembles a fresh case sheet per encounter (folding in the daily doctor and nurse notes), so you attach one up-to-date case-sheet document rather than many individual notes. ## Common Issues - **Serialization error when loading the claim** — this is typically a malformed value in the pre-authorization data; re-check the workflow for any failed/partial rows before retrying. - **Items not showing** — the claim reads from the pre-authorization; ensure the pre-auth was submitted successfully first. - **"Please fill required fields: …"** — one or more `*`-marked fields are empty; the message names them. Fill each listed field (including a care-team doctor and Start/End Date) and resubmit. - **"Item N: treatment date cannot be after the discharge date"** — that item's Start/End Date falls after the claim's End Date. Correct the item's dates (or the claim's End Date) and resubmit. - **"Item N: Start Date must be on or before End Date"** — the item's own two dates are the wrong way round. - **Over-balance claim — the Copayment panel** — the items total is more than the cover the payer last reported (the **Get wallet** validation). The claim is still submittable; a **Copayment** panel appears below **Total** to capture the beneficiary's share and consent (see [Copayment](#copayment)). The amount sent to the payer is unchanged — the full items total — and the payer pays only up to the available balance. The panel appears only once a wallet is known (including a wallet the payer reported as zero); a workflow that has never run **Get wallet** shows no panel and no block. - **"Enter the copayment amount for the amount above the wallet balance."** — the Copayment panel is open and the **Copay amount** is zero. Enter the amount the beneficiary will pay beyond the cover. - **"The beneficiary's copayment consent must be acknowledged."** — tick the acknowledgement in the Copayment panel confirming the beneficiary was informed and consented. - **"Upload the beneficiary's copayment consent form."** — the plan provides no Patient Payment Consent questionnaire, so attach the consent document to the **Beneficiary copayment consent form** slot under **Attachments** (or, when the plan provides one, answer its attachment item). - **"An earlier pre-auth on this case is not closed yet … (PAYR-1372)"** — the payer accepts only **one open event per case**, so a claim is refused while an earlier submission (a pre-authorization, resubmission, enhancement, reprocess or claim) is still awaiting its decision. The form shows a red banner naming the pending event and when it was sent. Wait for the payer's decision before claiming. **Cancelling** the pending event does not clear the block on its own — the case becomes claimable again once a later submission has been **approved**, because an approval proves the earlier event closed. Note the items on the form are those from the last **approved** pre-authorization, so they do not include the pending change. ## FAQ **Q: What is the difference between a pre-auth and a claim?** A: A pre-auth is approval sought *before* treatment. A claim is the request for payment submitted *after* treatment. **Q: What is an enhancement?** A: An enhancement adds extra procedures/items to an already-approved pre-authorization, so the claim reflects the full treatment while only charging for the additional work. **Q: When is a claim for a newborn filed under the parent?** A: When the eligibility check linked a parent UHID, the claim automatically uses the parent's policy identity. See [NHCX Newborn Claim](/docs/nhcx-newborn-claim). **Q: I submitted a resubmission and now the claim form is blocked. Why?** A: The payer processes one event at a time. Until it decides on the resubmission, the case has an open event and any new claim is refused (PAYR-1372). The form names the pending event in a red banner. Wait for the payer's decision, then submit the claim — the approved items from the resubmission will then load. Cancelling the resubmission alone does not lift the block; the case clears once a later submission is approved. **Q: The claim is more than the wallet balance — do I have to reduce it?** A: No. The claim is still submittable and the amount sent to the payer is unchanged. The Copayment panel captures the beneficiary's share of the shortfall and their consent, which the hospital records; the payer decides whether that shortfall may be shifted to the beneficiary and pays only up to the available balance.