NHCX Claim

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) — 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 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. Choosing a Discharge Disposition auto-loads the plan's matching questionnaire: the plan's questionnaire names are matched against the disposition's code or its protocol label, so a Death (DTM) discharge loads the plan's Death questionnaire and a LAMA/DAMA discharge loads its leaving/against-medical-advice questionnaire. A plan that defines no questionnaire for a disposition simply loads none — any of the plan's questionnaires can still be added by hand under Plan Questions. A DTM (Death) discharge additionally sends the Death Date captured on the plan's death questionnaire to the payer as supporting info (category ONS, code DTM); a death claim arriving without it is rejected with PAYR-1096.
Biometric verification — for admission and discharge capture (see NHCX Biometric).

For a newborn claim, the parent relation and proof-of-birth documents are carried in automatically. See 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). The claim's own End Date (the discharge date and time) must also not be in the future — a claim is filed after treatment, so a future discharge date is rejected.

Unspecified procedure

Some plans offer an Unspecified package (for example, Unspecified Surgical Package) for a procedure that is not otherwise listed. Selecting one changes the item:

A Procedure Name field appears under Product Or Service — type the exact procedure performed. It is required: submitting it blank is blocked with Procedure name is mandatory.
Unit Price is yours to enter and must be non-zero. The plan's limit for an unspecified package is a placeholder, not a price, so the amount is deliberately not filled in from the payer or the plan; the form blocks with Procedure amount is mandatory. until you enter one.
An unspecified procedure cannot be combined with any other procedure. While one is on the form, adding another procedure — or adding an unspecified item beside an existing procedure — is refused with Unspecified procedure cannot be clubbed with other procedure.
At least one procedure must be selected to submit; an item left without a procedure is blocked with At least one procedure must be selected.

Adding the same procedure code more than once shows a warning (This procedure is already added.) but does not block — cyclic procedures and stratified items legitimately repeat a code.

LM-100 procedure (LAMA/DAMA discharge)

For a LAMA or DAMA discharge disposition with a Before surgery or During surgery stage, the payer accepts only the LM-100 procedure and disqualifies every approved preauthorization item. The form auto-adds an LM-100 item and submits the claim with the LM-100 procedure as its only item — any other items on the claim are shown but not sent. Submitting without an LM-100 item is blocked; removing the auto-added item re-blocks submission. Changing the disposition/stage away from the LAMA/DAMA trigger removes the auto-added item and restores the full item list to the submission.

The stage is taken from the plan's own Stage answer — the LAMA/DAMA questionnaire the plan supplies asks for it (Before Surgery/Treatment, After Surgery/Treatment, Patient Not Covered), and the form uses that answer. A plan that supplies no such questionnaire falls back to the Discharge Status dropdown.

LM-100 is priced from its stratification. The plan carries LM-100's amount on the stratification rows (Routine Ward, HDU, …) rather than on the procedure itself — its base limit is ₹0 — so the LM-100 row offers the plan's stratification selector and picking one fills in Unit Price with that stratification's plan rate. The field stays editable. The LM-100 row sits under the claim's own benefit category (the category the other procedures on the claim use — Cardiology for a PTCA case, say); the plan files LM-100 once under every specialty, so it is never placed in an unrelated one. Each stratification gets its own LM-100 item with its own start/end period; add further rows with the normal Add item flow (select LM-100 under the claim's own benefit category and choose a different stratification).

An after-surgery LAMA/DAMA claim is submitted at the full amount. The payer applies its own reduction to the approved amount; the form does not compute a client-side figure.

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.

Resubmission

A resubmission re-sends the pre-authorization with corrected or additional information when the payer rejected it — or the case otherwise needs re-submitting. It stays tied to the same case: the case number is reused, and when the payer has issued a pre-authorization reference for that case it is carried onto the resubmitted pre-authorization so the payer can link the two. A case with no such reference (nothing approved yet) still resubmits — the shared case number provides the continuity, so the resubmission is never blocked for want of a reference.

Like an enhancement, a resubmission starts from an empty item list and carries forward the earlier submission's questionnaire answers and documents, so you re-enter only what changed. It is available from an approved or a rejected pre-authorization. See NHCX Cancel Pre-authorization for the related action.

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.

Each document the payer requires for the selected procedure is marked with an asterisk (*). On a pre-authorization a *-marked document must be attached before the submission is accepted — the form refuses with Document <name> is mandatory. Please upload before submitting. if one is missing, and names them one at a time. Attaching the document either by uploading a file or by Choose from records both satisfy the requirement. Claims do not block on these documents; there they are informational.

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.
"End Date cannot be in the future" — the claim's End Date (the discharge date and time) is later than today. A claim is filed after discharge, so correct the discharge date and resubmit. (Pre-authorizations are exempt — a planned admission may legitimately be in the future.)
"Item N: Start Date must be on or before End Date" — the item's own two dates are the wrong way round.
"At least one procedure must be selected." — an item row has no procedure (or the list is empty). Select a product/service on every row.
"Procedure name is mandatory." — an Unspecified procedure was selected with the Procedure Name field left blank. Enter the exact procedure name.
"Procedure amount is mandatory." — an Unspecified procedure has a blank or zero Unit Price. Enter the amount (the plan's unspecified-package limit is a placeholder, not a price).
"Unspecified procedure cannot be clubbed with other procedure" — an Unspecified item is on the form alongside another procedure. Remove one of them.
"This procedure is already added." — a non-blocking warning that the same procedure code appears on another row. Cyclic and stratified items legitimately repeat a code and are not warned.
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). 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).
"Invalid death date received for claim request … (PAYR-1096)" — a DTM (Death) claim must carry the death date in Claim.supportingInfo (category ONS, code DTM). The app takes that date from the Death Date answer on the plan's death questionnaire, so the claim is refused only when that questionnaire — and its Death Date field — was never captured. Select DTM as the discharge disposition so the death questionnaire loads, fill in Death Date, and resubmit.
"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.

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.