Common TPA denial codes in India: the list your hospital probably does not have

Why TPA rejection reasons never reach your finance report, and a reason-code taxonomy an Indian hospital can build this month without new software.

If you search for common TPA denial codes in India, what you are usually looking for is a list you can hand to your billing team so that every rejection gets a label. The honest answer is that your hospital will have to write that list itself, and that this is less of a setback than it sounds. Here is the direct version: there is no code set you can simply adopt that every TPA and insurer in your payer mix already uses, so the useful work is building a small internal taxonomy, mapping each payer's wording onto it, and making the code mandatory before a claim can be closed.

Before accepting that, test it on your own data. Pull the last fifty rejections from your three largest TPAs and lay the stated reasons side by side. Count how many distinct phrasings describe the same underlying failure — a missing discharge summary, a pre-authorisation that covered a different procedure, a tariff line that does not exist in the agreed schedule. If the phrasings outnumber the failures by a wide margin, you have found the problem, and it is not a clinical one.

Why rejection reasons never reach the finance report

The mechanism is structural, not a matter of effort.

First, the reason originates outside your system. It is written by a reviewer at the TPA, in that TPA's vocabulary, and arrives by email, portal note or a remark on a settlement advice. Your billing software never receives it as a field. It receives it as prose, if it receives it at all.

Second, the person who handles the rejection is the person who can argue it, not the person who can count it. A good billing executive reads the remark, finds the missing document, resubmits and moves on. That is the correct response to one rejection and a disaster across a thousand, because nothing durable is written down.

Third, the feedback arrives late. By the time a denial is understood, the admission that caused it is weeks old, the consultant has done forty more cases the same way, and the fix would have had to happen at registration or at pre-authorisation — long before anyone knew there was a problem.

Fourth, the regulatory layer does not solve this for you. Health insurance circulars and directions are published by the regulator — the IRDAI health department circulars page is worth tracking, and policy changes there do move claim behaviour. But a circular tells you what the industry must do. It does not give your billing floor a dropdown.

So the rejection amount reaches the P&L and the rejection reason does not. The number is visible; the cause is not. That is why the quarterly review always ends with agreement that rejections are too high and no agreement on which three things to fix.

A taxonomy you can build this month

None of what follows needs new software. It needs a decision and about two weeks.

• Write between twelve and twenty reason codes, not more. A workable starting set groups failures by where they can be prevented: eligibility and policy status, pre-authorisation missing or mismatched, documentation incomplete, tariff or package mismatch, non-payable items and exclusions, submission or resubmission timeliness, administrative or data error, and insufficient clinical justification. Few enough that a billing executive picks one without thinking. Specific enough that each code has exactly one owner.
• Map each payer's wording onto your codes, not the other way round. One mapping sheet per TPA. When a new phrasing appears, it gets mapped — it does not get a new code. The list only grows when a genuinely new failure mode appears.
• Make the code mandatory to close the claim. This is the step most hospitals skip, and it is the only one that makes the data real. A claim cannot move to settled, written off or under appeal without a code attached.
• Give every code a named owner upstream. Eligibility sits with front office. Pre-authorisation mismatch sits with the insurance desk. Documentation sits with the ward and the medical records department. Tariff mismatch sits with finance. A code with no owner is a code nobody closes.
• Review the top three codes weekly, for twenty minutes. Not all twenty. The top three by value, with the owner present, and a decision each week about what changes upstream.
• Report first-pass acceptance by payer, not just rejection value. Rejection value tells you the size of the wound. First-pass rate per TPA tells you whether the process is improving, and it is the number worth putting in front of your board.

A hospital cannot reduce what it has not classified. The classification is the intervention; the software is only how you keep it from decaying.

Where this decays, and where Ospia fits

Manual taxonomies decay in a predictable way. The mapping sheet lives on one person's laptop. The mandatory field gets a "other — see notes" escape hatch. The weekly review survives two months. And because registration, clinical documentation and claims sit in different systems, the code can never be traced back to the admission that caused it without someone reconciling three exports by hand.

Ospia HOS is an AI-native hospital operating system rather than another hospital management system, and it is running hospitals in production today. The relevant difference here is structural: one patient record across 31 domains, so the registration field, the consultant's note, the pharmacy issue and the claim are the same record rather than four systems to join. Every event is retained permanently — the event log is the hospital's history — so a reason code is queryable as a trend three years later instead of being a remark in an inbox. The claims agent in the AI workforce works rejections within a defined scope, permissions and escalation path, governed the way you would govern a new hire, and classifies each one against the reason set the hospital defined rather than one we imposed.

Autonomy is a dial from L0 to L4, set per task and held by the hospital. At L0 a person does the work and the system records it. Anything above L2 executes under a named human, and L4 runs only inside a policy the hospital approved. Raising or lowering an agent's level is itself an audited decision with a name on it. We also plan a prediction service covering claim-rejection probability among other signals, each explainable — that is a stated target, not something we are claiming as delivered.

What we will not do is publish a percentage reduction in denials. We publish measured outcomes only when a hospital has completed hypercare and agreed to be named, and until then the number does not exist.

If you want to size the problem before you talk to anyone, the revenue leakage calculator is published ungated — no email address, no form. Put your own admission volume, payer mix and rejection figures in and see what the classification gap is worth in a year.