There are two coverage-eligibility calls in an NHCX claim journey, not one. Teams routinely build the first and skip the second, because the first appears to answer the question. It does not, and the gap between them is where avoidable rejections and awkward billing conversations come from.
The two calls answer different questions
The first call, made around registration, asks is this policy active. That is a validation question, and it is worth asking even when a policy lookup has already returned the patient's cover, because suspension, upgrade or expiry may not have synced in real time.
The second call, made after a specific package has been selected, asks how much is actually left. Only the payer can answer that, because only the payer knows what has already been consumed against annual limits and sub-limits.
Why the second call decides your rejection rate
Consider a package worth ₹30,000 where the patient has already used ₹20,000 of an annual limit earlier in the year. Your system, working from the plan catalogue alone, believes ₹30,000 is available. The payer knows ₹10,000 is.
If you skip the benefits check, one of two things happens. Either the pre-authorization comes back short or rejected — and you find out after the patient has been admitted — or the claim is adjudicated below the amount you quoted, and the shortfall becomes a conversation at discharge with someone who was told a different number on admission.
Neither is a systems failure. Both are the predictable result of not asking the only party who knows.
The purposes, and which one you want
The eligibility request carries a purpose, and the value changes what comes back:
validation— is the policy in force. The registration-time call.benefits— what the policy actually covers and what remains. The call to make after package selection.auth-requirements— what the payer will require in order to authorise. Use this when you want the document and pre-authorization requirements alongside the amounts.discovery— finding cover the patient may not have declared.
One implementation note worth saving you a debugging session: the plural form auth-requirements is the value that validates against the published profiles, even though singular phrasing appears in several places in the documentation and in an example filename. If you built against the singular, that is why your bundle fails terminology binding.
What this means for the product, not just the API
The second call is only useful if the product does something with the answer. That means three things have to exist:
- The call has to be unskippable in the workflow. If a user can reach pre-authorization without it, someone will, on the day it matters most.
- A screen that shows the shortfall. Package amount, amount available, amount payable by the patient — stated before treatment, not derived at discharge.
- A record that the conversation happened. A printed estimate and a consent trail, because the whole point is that the patient was told in advance.
This is the part that makes it a product change rather than an integration task. The message is easy. The screen, the consent flow and the audit record are the work.
Where it sits in the sequence
The full provider sequence runs: discover the policy, fetch the plan, validate the policy is active, do the clinical work, select the package, check benefits, map documents, then submit the pre-authorization. The benefits check sits immediately before submission for a reason — it is the last point at which you can still tell the patient the truth about cost without it being a surprise.
Cache what you can. Plan catalogues are meant to be held for a couple of weeks rather than fetched per claim. But the benefits check is per-patient and per-package, and it is not cacheable — the whole value is that it reflects consumption to date.
If you are scoping NHCX for a hospital information system, our healthcare interoperability team has built the full flow end to end against the sandbox. For the architectural half — the asynchronous layer, the callback path, the claim state model — see our healthcare software product engineering practice. Talk to our team to walk through your product.
