What are TISS denial codes?
TISS denial codes are the standard messages in table 38 of TUSS (Unified Terminology for Supplementary Health), Brazil's national code set for private health care. A health plan (operadora) uses them to tell the hospital why it refused to pay all or part of an item or a claim form. In Brazil this refusal is called denial (claim denial).
Table 38 is part of the TISS standard (Exchange of Information in Supplementary Health), the mandatory electronic data standard set by the National Supplementary Health Agency (ANS, Agência Nacional de Saúde Suplementar). According to the standard's Organizational Component, the messages came out of discussions at COPISS, the committee that standardizes health information in the sector. They are used in health plan responses during authorization and billing [3]. That is why the same table carries authorization denials and claim denials.
The closest US equivalent is the pair of X12 code sets CARC and RARC, which explain line-level adjustments on the remittance advice. The comparison is approximate: in Brazil there is one regulator and one mandatory standard for every plan. The bigger picture is in the guide Hospital denial.
Where the code shows up: the claim analysis statement
The code shows up in the claim analysis statement (demonstrativo de análise de conta), the health plan's response to the claim batch the hospital sent. Return statements, both claim analysis and payment, must be exchanged electronically under TISS [3].
The path is always the same [3]:
- Batch sent. The hospital sends its billing claim forms (guias) in a batch, in XML.
- Protocol number. The health plan issues a protocol number that proves the batch was received.
- Statement request. The hospital requests the statement using that protocol number. The plan sends the statement or says it is not yet available.
- Reading. The claim analysis statement lists every claim form in the batch. For forms already analyzed, it lists only the denied items; for those still under review, it shows their status.
- Action. For each denied item, the hospital reads the table 38 message and decides: fix and rebill, appeal, or negotiate.
The claim analysis statement shows what was denied and why; the payment statement shows what was paid. How to reconcile the two is in the guide Claim review and payment statements. The exact fields of each statement are defined in the standard's Content and Structure Component (version 202511) [4].
Not every table 38 message is a denial. Codes such as 5001 (message outside the standard), 5002 (the XML file could not be validated), 5014 (invalid hash) and 5028 (invalid standard version) are batch rejections: they point to a problem with the file, not with the claim content, and are fixed by correcting and resending, not by appealing [1]. These rejections are covered in the guide TISS XML batches: submission errors.
Two practical points:
- A form under review is not a paid form. No denial to appeal yet, but the contract clock may be running.
- An item missing from the statement is not a denied item. For analyzed forms, the statement lists only denied items [3]. What does not appear was accepted.
What are the message groups, and what should you do with each?
The most useful way to work with table 38 is to group messages by the action they require. These groups are an editorial organization of this guide, not an official ANS classification. Every code below was checked in TUSS version 202607 (official ANS spreadsheet), with a start date and no end date [1].
| Group | Checked codes [1] | What the plan claims | Recommended action | Typical evidence |
|---|---|---|---|---|
| Member and registration | 1001 — Invalid member card number | Member identification does not match | Check registration and eligibility proof; if the hospital erred, fix and rebill | Eligibility check result on the date of service |
| Authorization | 1414 — Authorization number expired · 3292 — Quantity above authorized | Service outside what was authorized (date or quantity) | Compare dates and quantities with the authorization response; appeal if the authorization was valid; attach any extension | Authorization response, dated authorization number, extension request |
| Quantity | 3190 — Quantity incompatible with the procedure · 3191 — Incorrect quantity · 3293 — Quantity above coverage | Units billed do not match the procedure, the record or the coverage | Check against orders, nursing administration records and usage; correct posting errors; appeal with clinical records if justified | Physician orders, nursing records, OR sheet, usage report |
| Duplicate | 3209 — Duplicate procedure or item · 3232 — Duplicate claim for a period already billed in another interim claim | The same item or period was billed twice | Cross-check earlier claims and interim bills; accept if truly duplicate; appeal with dates and times if the events were distinct | Billing history, time-stamped record of each event |
| Amount | 1705 — Amount billed above · 1706 — Amount billed below · 3310 — Invoice amount does not match · 3311 — Invalid amount | Price does not follow the contract, the reference table or the invoice | Check the contract price list in force on the date and the invoice; fix the item master if the error was internal; appeal citing the clause if the price was right | Contract, negotiated price table, item invoice |
| Clinical (medical necessity) | 3040 — Clinical denial (to be specified) · 3217 — No justification or insufficient justification | The plan's auditor questions clinical need or documentation | Send to the hospital's physician or nurse auditors; appeal with excerpts from the medical record, never generic text | Progress notes, orders, physician report, operative note |
Code names above are summarized English renderings; the full official wording, in Portuguese, is on the TUSS lookup platform [1]. Code 3040's own description asks the plan to specify the reason. If it arrives without explanation, the first step is to request the justification.
In market terms, the first four groups are usually administrative denials and the last one is a clinical denial. The distinction is covered in the guide Types of denials.
Old codes still circulate but are not current
Part of the denial code lists circulating online is outdated. Codes 1702, 1714, 1739, 1813 and 1820 are not in TUSS version 202607, the official ANS spreadsheet; in the online lookup on 10/17/2026, they showed no validity dates [1]. The most common example is 1702, used for years for duplicate billing; the current message for that case is 3209.
What this changes:
- In the hospital system. The internal mapping that links each code to a cause and an owner must be updated with the current series.
- When reading statements. If a plan still sends a code with no validity, log it and ask for the correct message. The standard bars plans from altering it or keeping their own table after the adoption deadline [3].
- In reporting. Denial-by-reason reports that mix old and new codes need a crosswalk, or the time series breaks.
TUSS is updated often; the version in force in September 2026 is 202609 [5]. Check validity on the official platform before using a code in an appeal or in training. The guide TUSS table explains how.
How do you look up a code at the official source?
The official lookup is public and free. ANS keeps a “TUSS codes” page with the terminology on an online platform that supports search, Excel, CSV and JSON downloads and API access [2]. In table 38, each term carries a code, a description, start and end dates and an adoption deadline [3].
For each code on the statement:
- Search for the code in table 38 on the platform.
- Check that it was in force on the date of service, not just today.
- Read the full description, not only the short label in the billing system.
- Record the group, the owner and the evidence needed in the denial log.
From code to appeal: what the standard and the contract guarantee
The denial appeal (recurso de glosa) is also a mandatory electronic exchange under TISS. The Organizational Component provides four messages: the appeal, the receipt protocol, the status request and the plan's response, which accepts, rejects or reports a new review [3]. The protocol number proves receipt [3].
The appeal deadline does not come from table 38 or from TISS: it comes from the contract. ANS Normative Resolution (RN) 503/2022 requires the contract to list the grounds for denial and the deadlines for appeal and response, which must be equal. It also bars plans from blocking access to denial justifications and to appeals, when billing follows the current TISS version [7]. Step by step in the guide Denial appeal.
| Situation on the statement | What to do | Basis |
|---|---|---|
| Clear code, valid denial | Fix the cause and rebill, if the contract allows | Contract |
| Clear code, improper denial | Appeal within the contract deadline, with the group's evidence | RN 503/2022 [7]; TISS [3] |
| Generic or unexplained code | Ask for item-level justification before or with the appeal | RN 503/2022, art. 5, V [7] |
| Code with no validity | Log it, ask for the current message, appeal if the denial is improper | TISS [3] |
| Same code repeats across many claims | Fix the root cause; if it is the plan's pattern, take it to contract talks | Contract |
The code is the data point ANS does not receive
The reason for each denial is data that only the hospital and the plan hold. ANS tracks denial volume by plan in its Denial Indicators Dashboard but does not receive the reason for each denial [8]. That makes tracking by code an internal advantage.
The stakes are high. At Anahp member hospitals (Brazil's National Association of Private Hospitals), initial denial was 15.93% of amounts receivable from health plans in 2025. Accepted denial, the final loss, was 1.72% of gross revenue from health plans [6]. The two figures use different bases and should not be divided by each other. The difference between them is explained in the guide Initial and final denials; the series is in Industry data.
What we see in operations
At Accrua, the table 38 code is where every decision on a denial starts, not where the analysis ends. Reconciliation of the claim review statement runs form by form in Accrua OS: each denied item is linked to its code, to the contract and to that health plan's history for that item.
We group denials by the action each code calls for: correct and rebill, appeal with a document, appeal with the medical record, or take it to the contract. For each group, we measure the denied amount and the appeal outcome in the hospital's own history. When a health plan sends an expired code or a generic message, that is logged too, because it becomes an item for the contract conversation.
The draft appeal goes out with the evidence the health plan asks for under that code. Accepting the denial or dropping the appeal is always a person's decision, made with everything gathered and sourced. What we learn in each appeal feeds the review of the next claim.
Where to start
- Update the denial-reason mapping in the billing system with current table 38 codes.
- Classify the last 12 months of denials by message group, health plan and amount.
- Assign an owner and the evidence for each group, as in the table above.
- Check each code's validity on the official platform before using it.
- Take recurring codes to contract talks with each plan, with the accumulated amount.