A working playbook for claim denials in Indian hospitals

Why do claims get denied in the first place?

Almost always because of something that happened before the claim was filed — a missing authorization, an eligibility mismatch, a bundled procedure billed separately, a document nobody scanned. The payer is describing an upstream defect, which is why a denial desk that only appeals is a treadmill.

That reframes the work. The biller's job is to recover this claim; the hospital's job is to stop the same denial arriving next week. Both need the same thing — a reason you can count, rather than free text in a spreadsheet column.

How do we read a CARC or RARC code?

A CARC (Claim Adjustment Reason Code) says why the amount paid differs from the amount billed; a RARC (Remittance Advice Remark Code) adds the detail. The pair is what tells you whether to appeal, rebill or write off. The code lists are public and maintained under X12.

An example makes it concrete. CO-97 says the service is already included in another service that has been adjudicated — a bundling call. Appealing it with the same documentation is wasted effort; the fix is a corrected claim with the right modifier, or a coding change upstream.

One honest caveat for India: not every payer speaks these codes. Many TPAs still send free-text reasons or their own internal lists, so part of the work is mapping what your payers send onto a bucket your team can count. Do that mapping once, inside the system.

Which root-cause buckets actually matter?

Five buckets cover most of the volume, and each has a different owner. Sorting into them is the highest-return habit in this playbook, because it converts a pile of rejections into five conversations with five departments.

• Eligibility and scheme mismatch — the patient was not covered for this, on this date. Owner: registration.
• Authorization — the procedure needed prior approval that never arrived or had expired. Owner: the TPA desk.
• Documentation — the claim is fine, the evidence is missing. Owner: the department that generated it.
• Coding and bundling — the service was billed in a way this payer will not pay. Owner: coding and billing.
• Timeliness — the claim or the appeal missed the payer's window. Owner: whoever holds the clock.

Only one of the five is a billing problem. That is what most hospitals find the first time they sort honestly, and it is why the denial review belongs on the operations agenda — the billing executive's day improves fastest when the other four owners show up.

What changes in the NHCX era?

The National Health Claims Exchange pushes Indian claims toward structured, standards-based exchange instead of portals and emailed PDFs. For a denial workflow the important part is the coded, machine-readable reason: that is what makes bucketing, counting and any automation possible at all.

Treat it the way you treat ABDM — ready architecture in your software, a per-deployment question for your payers. The near-term win is consistency, not automation: the same reason in the same field every time, so the queue routes it unread. The ABDM-ready explainer applies the same test.

Where does AI belong in a denial workflow?

In the drafting seat, never the filing seat. Decoding a reason code, proposing a root cause and writing a first-draft appeal that cites the policy clause is exactly what a model does well and a biller does slowly. Deciding to file it is a human judgement with money and a payer relationship attached.

That is how Denial Guard is built: it classifies the denial, drafts the appeal, and stops. A biller approves every draft before it goes out, high-value claims add a senior reviewer, and the agent ships switched off until your tenant arms it.

How do we know the playbook is working?

Watch the mix, not only the recovery. Recovered rupees tell you the queue is being worked; a shrinking share of denials in the eligibility and authorization buckets tells you the upstream fix landed. The second signal is the one that compounds.

Put the review on a fixed cadence with those five owners in the room, and bring the same report every time. A denial meeting that redefines its own categories each month cannot demonstrate progress, however well the queue is worked.

If you want to see a denial workqueue with decoded reasons, root-cause analytics and a human approval gate on every appeal, book a 30-minute demo and bring one month of rejections with you.