What is AI for denial prevention?
AI for denial prevention is the use of automated rules and statistical models to estimate, before submission, the chance that each claim or line item will be denied. The system also points to the likely reason. The output is a review queue ordered by risk, not an automatic decision to bill or not to bill.
The guide AI in hospital billing shows where AI fits in the revenue cycle and its legal limits; this one opens the box on one of those uses, pre-submission claim review. Whether to build this capability in-house, buy a tool or outsource the step is covered in the guide Hospital billing outsourcing.
Rules engines and machine learning models do different jobs
A rules engine applies what is already known; a machine learning model finds patterns nobody wrote down. A good tool uses both, each in its own role.
A rule is an explicit condition: “if the billed quantity exceeds the authorized quantity, block.” A model learns from claims already reviewed by health plans which combinations of health plan, procedure, item, amount and documentation tend to end in a denial.
| Aspect | Rules engine | Machine learning model |
|---|---|---|
| Where the knowledge comes from | Contract, TUSS, TISS, health plan manual, team experience | The hospital's history of claims, review statements and appeals |
| Output | Yes or no (block, alert or release) | Probability of denial (risk score) and likely reason |
| Best for | Deterministic errors: quantity above authorization, duplicates, expired authorization number, contract deadline | Diffuse patterns: combinations of health plan, item and documentation that tend to be denied |
| Explanation | Immediate: the rule that fired | Needs an explanation feature (which variables drove the score) |
| Weak spot | Misses what nobody anticipated; goes stale if not updated | Inherits the flaws of the history; does not know about a contract or TUSS change until it sees new data |
In practice, rules come first. They cover the most objective reasons in table 38, such as 3292 (quantity above the authorized amount), 3209 (duplicate procedure or item), 1414 (authorization number expired) and 3214 (billed outside the contract deadline) [2]. The model comes next, on claims that passed the rules, to order human review. Each code is explained in the guide TISS denial codes.
What data does the AI need?
AI for denial prevention needs three linked things: what the hospital billed, what the health plan answered and what happened after the appeal. Without that link, claim by claim and item by item, the model learns little.
The TISS standard makes these exchanges uniform. Billing, review statements and denial appeals must be exchanged electronically, and the claim review statement (demonstrativo de análise de conta) lists, for reviewed claims, only the denied items [1]. TUSS table 38 codes the health plan's responses to both claims and authorization requests [1]. Table 38 plays a role similar to CARC and RARC codes in US remittances.
| Data source | What it gives the model | Watch out before using it |
|---|---|---|
| Submitted claims (TISS forms) | Health plan, product, procedure, items with TUSS codes, quantities, amounts, dates, unit, physician | Link each item to its response; keep the TUSS version in force on the submission date |
| Claim review statements | Denied item, denied amount and table 38 reason code | Denials with no code or a generic code, such as 3040 (clinical denial, specify) [2], teach little |
| Appeal history | Outcome of each appeal: appeal upheld (code 3095) [2], partially upheld or denial maintained | This is where the right label comes from (see below) |
| Authorizations | Authorized items and quantities, authorization number and validity | Without the authorization, the model cannot tell a quantity denial from a coverage denial |
| Contract rules by health plan | Price tables, bundles, included items, billing and appeal deadlines | These become written rules, not loose variables; they need start and end dates |
| Clinical documentation (when used) | Presence of required progress notes, justification and reports, as in reasons 2511 and 3217 [2] | Sensitive data: only what is necessary, with a legal basis and controlled access |
The label is the most delicate point. A denial received is not the same as a hospital error. If the model learns that “every denied claim was wrong,” it will start flagging correct claims that the health plan denied improperly. The most useful label separates denials maintained after appeal (likely avoidable errors) from denials overturned (likely improper denials). The second group belongs in the denial appeal workflow and in negotiation with the health plan, not in prevention. The difference between initial and final denials is explained in Initial and final denials.
That is also why the history has to be the hospital's own. ANS measures denials by health plan on its dashboard, but does not receive the denial reason [3]. The reason, item by item, exists only in the statements the hospital receives.
The pre-submission flow in seven steps
The pre-submission flow has seven steps, and the last one feeds the model. Technology acts in two of them (rules and risk score); decisions about the claim belong to staff.
See the steps as a table
| Step | Who | What happens |
|---|---|---|
| 1. Claim closed | Billing | TISS forms, TUSS items, quantities and amounts |
| 2. Rules engine | Automated | Contract, TUSS and TISS rules; objective errors are blocked |
| 3. Risk score | AI model | Probability of denial and likely reason |
| 4. Prioritized queue | Automated | Ordered by risk × amount at stake |
| 5. Human review | Staff | Fix, justify or release with a record |
| 6. Batch submission | Billing | Current TISS version |
| 7. Response and appeal | Billing and appeals team | Review statement with table 38 code and appeal outcome, which go back to the training history |
- Claim closed. The claim leaves clinical documentation and coding with TISS forms, TUSS items, quantities and amounts.
- Rules engine. Applies contract, TUSS and TISS rules. An objective error becomes a block with the reason shown.
- Risk score. The model calculates the probability of denial for each claim or item and shows the likely reason and the variables that weighed most.
- Prioritized queue. Claims are ordered by risk multiplied by the amount at stake. Low-risk claims go straight through, if hospital policy allows.
- Human review. The analyst fixes the claim, attaches the justification or releases it with the reason recorded. Disagreements with the model are recorded too.
- Batch submission. The claim goes out in the current TISS version.
- Statement and appeal. The health plan's response and the appeal outcome go into the history and are used to measure and retrain the model.
Review must not become a bottleneck: claims on hold increase discharged-not-final-billed inventory and days to payment. The guide Discharged not final billed (DNFB) shows how to measure that inventory, and Pre-audit of every claim, how to size the review.
How do you know whether the model works?
A model works when it catches avoidable denials without flooding staff with false alarms. To see that, managers need two model measures and a few business measures.
Precision answers: of the alerts the model raised, how many were real denials? Low precision means staff reviewing good claims. Recall (or sensitivity) answers: of the denials that would have happened, how many did the model flag? Low recall means denials slipping through unseen.
Illustrative example (hypothetical numbers). In a month with 1,000 claims, 100 would be denied for avoidable errors. The model flags 150 claims, of which 60 would in fact be denied. Precision is 40% (60 of 150) and recall is 60% (60 of 100). If the hospital lowers the risk cutoff, the model flags more claims: recall goes up and precision goes down. The cutoff is a management decision, tied to team capacity and claim value.
The same example shows why a single “accuracy rate” misleads. A model that said “no claim will be denied” would be right on 900 of 1,000 claims, or 90%, and would catch no denials at all. Before accepting any accuracy figure from a tool, ask which measure it is, on what data it was calculated and what share of that data was denied.
| Type | Metric | Question it answers |
|---|---|---|
| Model | Precision | Of the alerts, how many were denials? |
| Model | Recall | Of the denials, how many were flagged? |
| Model | Performance by health plan and by reason | Is the model good for all health plans, or only those with more history? |
| Business | Initial denials by avoidable reason | Did the reasons the model covers fall against the baseline? |
| Business | Final denials | Did the permanent loss fall, or did denials just change reason? |
| Business | Hold time before submission | Is review delaying billing? |
| Business | Alerts dismissed by staff | Do analysts trust the alerts or ignore them? |
The comparison needs a baseline measured before rollout, with the same formulas and the same health plans. Denials also change because of health plan decisions, new contracts or a new TUSS version. So a drop in one metric does not prove the model's effect on its own. Denial formulas are in Denial rate, and industry figures in Industry data.
Governance decides whether AI helps or hurts
Without an owner, rules go stale and the model degrades without anyone noticing; staff then learn to ignore the alerts. Governance fits in a few rules.
- Rule owner. One person or area is accountable for the rule set by health plan, with version, start and end dates and the supporting document (contract, amendment, manual).
- Update on every external change. A new TISS or TUSS version, a contract amendment or a new health plan manual triggers a rule review and a model test. In October 2026, the current TISS version was the September 2026 release [1].
- Monthly model monitoring. Precision and recall by health plan and by reason. A persistent drop means the pattern has changed and it is time to retrain.
- Log every decision. Score, reason shown, analyst decision and final outcome, so decisions can be audited and explained.
- Review forum. The denials committee, where one exists, periodically reviews the most-dismissed alerts and the denials that slipped through. The guide Denial management covers roles and routine.
What the LGPD and CFM Resolution 2,454/2026 change
AI for denial prevention processes patient data, so the LGPD applies from training onward. Health data is sensitive personal data (art. 5, II) and may be processed only on the grounds in art. 11, such as compliance with a legal or regulatory obligation and the regular exercise of rights, including under a contract [5].
Three points are specific to this use:
- Necessity and purpose (art. 6, I and III). The model should use only the variables needed to predict denials [5]. Patient name and ID number rarely help predict a denial and can be left out of the training data.
- Anonymized data (art. 12). Data anonymized irreversibly, using reasonable means, is no longer personal data under the LGPD [5]. Pseudonymization is not enough: if re-identification is possible, the law still applies.
- Review of automated decisions (art. 20). The data subject may ask for review of decisions made solely by automated processing that affect their interests. The controller must disclose the criteria used, subject to trade and industrial secrets [5]. A score that only orders human review of a claim between hospital and health plan is different from an automated decision that affects the patient, such as a patient bill. Human review and a record of the criteria fit this article better.
CFM Resolution 2,454/2026 lists support for health management among the uses of AI. It requires a preliminary risk assessment and human oversight, and also applies to systems already in use [6]. The text does not mention billing or denials [6]. Its practical effect is on governance: if the model reads medical records, it belongs in the inventory and risk assessment of the hospital's AI committee, where there is one. The full table of rules is in the guide AI in hospital billing; data sharing with health plans is covered in the guide LGPD in hospital billing.
Preventing denials does not remove the hospital's right to contest them. ANS Normative Resolution 503/2022 (RN 503/2022) forbids health plans from blocking access to denial justifications or from preventing appeals [7].
What we see in operations
Accrua provides revenue cycle services and applies the split described in this guide in its own operation. Pre-submission review reads every health plan claim, not a sample: medical record, prescriptions, items, OPME (implants and devices) and bundles, checked against the contract, the current price table, the authorization rule and that health plan's denial history for that item.
What has a defined rule runs automatically, within the limit set in the contract. What changes the value of the claim, such as changing an item, accepting a denial or dropping an appeal, goes to a biller or auditor, with the source of each alert in view. The person decides; the system prepares the case and logs who decided, on what basis and when. This rule is in the contract with the hospital, and hospital and patient data do not train models from Accrua or third parties.
Where to start
- Link the history: tie every billed item to its statement, table 38 code and appeal outcome, by health plan, for the last 12 months.
- Write the rules first: turn each health plan's contract, TUSS and manual into rules with an owner, version and effective dates.
- Measure the baseline: initial denials by reason, final denials, claims reviewed, hours per claim and hold time before submission.
- Run the model in parallel: for one or two cycles, compare scores with health plans' actual responses. Only then change the review queue, with the cutoff set by precision and recall.
- Formalize governance: data protection officer, AI committee where one exists, monthly monitoring, and data and exit clauses in the contract.