AI can help turn clinical records into a claim draft, but the harder question comes before submission: do the codes, authorization, payer policy and documentation actually support the service being billed, and can the person approving it see why?
A claim can pass every front-end edit and still reach the payer with a problem that the scrubber was never designed to catch. The patient and provider details may be complete, the transaction correctly formatted and the procedure codes valid in isolation, yet the payer can still deny payment because the plan excludes the service, the authorization covers something different from what was performed or the clinical record does not support the billed service.
By the time that denial reaches the billing team, the service has already been delivered and the original claim has moved through the system. Someone now has to reopen the record, work out which policy applied, determine whether the claim can be corrected or needs an appeal, and then wait through another payment cycle. What looked like a small gap in the pre-submission process has become avoidable work and a delay in reimbursement.
In that situation, the claim scrubber may have done exactly what it was built to do: check the fields, formats and edits in its rule set. What it may not have established is whether the payer policy applied to this patient's plan or whether the clinical note supported the code, a distinction that becomes even more important as AI enters medical billing. A model can read an operative note, identify relevant details and assemble a structured draft in far less time than a person working through the same documents, but a fluent draft is not yet a validated claim. Before submission, the system must be able to show which rules it applied, where the important facts came from and who reviewed and approved the result.
The denial problem is not just a data problem
Experian Health's 2026 State of Claims survey offers a useful view of the pressure facing revenue-cycle teams: among 204 people involved in healthcare finance, billing, registration or claims, three-quarters said denials were increasing and 40% said at least one in ten claims at their organization was denied. Of particular relevance here, 53% selected “services not covered” among their top three reasons for denials.
That finding points to a problem that a conventional front-end edit cannot resolve on its own. A missing field or malformed identifier can usually be identified from the claim data, whereas coverage depends on the patient's benefits, the specific plan, the provider, the service delivered and the payer's policy. A claim may therefore be complete and correctly formatted while still failing the coverage requirements that determine whether it will be paid.
The survey represents the views of 204 industry professionals rather than a census of US claims, so its figures should be treated as directional, not universal. Even with that qualification, it reinforces an important point for anyone building or operating billing systems: preventing avoidable denials requires more than confirming that a claim file is complete.
What claim scrubbing can catch, and what it cannot
Claim scrubbing remains an essential first line of validation because it can catch missing information, invalid values, inconsistent data and coding conflicts that have already been translated into explicit rules. The difficulty begins when a clean result is treated as a verdict on the entire claim, rather than as confirmation that the claim passed the particular checks the system was configured to perform.
Medicare's National Correct Coding Initiative (NCCI) illustrates both the value and the limits of rule-based validation. Its Procedure-to-Procedure (PTP) edits identify code pairs that generally should not be reported together; for Medicare, the edits apply when the same beneficiary receives services from the same provider or supplier on the same date of service. When such a pair appears on a claim, the Column Two code is generally denied unless the applicable edit permits an NCCI-associated modifier and the circumstances, supported by the documentation, justify its use.
These edits address coding relationships; they do not determine whether a service is covered, whether it is medically necessary or whether prior authorization was obtained. CMS updates its NCCI PTP and Medically Unlikely Edit files at least quarterly, and the effective and deletion dates determine which version applies to a particular date of service. A validator therefore needs to select the correct historical file for the claim it is checking, not simply apply whichever version happens to be the newest. Commercial plans may adopt NCCI edits, use different edits or add their own requirements, which is why Medicare's files should not be treated as a universal payer rulebook. See the CMS Medicare NCCI PTP edits and the NCCI FAQ library for the scope and use of these edits.
| Check | What it can identify | What it does not establish |
|---|---|---|
| Claim data and format | Missing fields, invalid values, inconsistent identifiers and transaction errors | That the service is covered or payable |
| Coding edits | Known code-pair conflicts, unit limits and configured coding rules | That the medical record supports every code or unit |
| Payer and authorization rules | Configured benefit requirements, policy conditions and authorization mismatches | That the service delivered matches the approval or that the claim will be paid |
| Clinical documentation | Missing facts, conflicting details and source evidence relevant to a code | A final medical-necessity or coverage decision |
A useful validation result should make the boundary visible: it tells the biller what the system checked, what it found and which questions remain outside its view.
Prior authorization information is also becoming more structured under CMS's Interoperability and Prior Authorization Final Rule (CMS-0057-F): affected payers must provide specific reasons when they deny non-drug prior authorization requests beginning in 2026, while the API requirements generally follow from 2027, with implementation dates varying by payer type. Better data exchange should make it easier to retrieve authorization requirements and reconcile decisions, but an authorization is still not a guarantee of payment; the claim must match the service that was actually delivered and satisfy the plan's billing requirements. CMS explains the rule and its implementation dates.
Give AI the reading work. Give rules the checks.
A sound design does not expect one model to read a clinical record, interpret every payer policy, decide whether the claim is compliant and approve it for submission. Those responsibilities call for different kinds of reasoning and different controls, so the workflow should give each one to the component best suited to perform it.
AI is particularly useful when the work involves reading and organizing large volumes of material. It can process a dictated operative note, referral letter or scanned clinical record, extract candidate facts, map them into a structured draft and direct the reviewer to the passage that supports each value. That can spare a biller from searching through pages of documentation, although the model can still miss context, confuse similar terms or infer a detail the source never stated. For that reason, an extracted value should travel with its source rather than arrive in the claim as an unsupported field. If an operative note describes a procedure on the left side but the draft carries right-sided coding, the reviewer should be able to see both the extracted value and the source passage; the system should flag the conflict for resolution instead of quietly choosing one.
Explicit checks belong in a separate validation layer, where the same claim context and the same approved version of a rule should produce the same result, whether the system is checking code combinations, unit edits, documentation requirements, payer-specific conditions or configured authorization details. The layer should identify the rule that fired and explain why it applies. Where context is missing, the rule is not configured or the question requires clinical judgment, the system should stop short of manufacturing certainty and send the case for review.
The biller therefore needs more than a green checkmark. The interface should let them open an extracted fact, inspect the source passage, understand which policy or edit was applied and see what remains unresolved, so they can approve the draft, correct it or return it for further work. Submission should follow that review, not be treated as the automatic consequence of a successful validation run.
A payer rule needs a source, a version and an owner
This is where a technically impressive workflow can become unreliable in production. A payer policy is not simply a document for an AI system to summarize; it is the source from which operational rules are derived, and each rule has a scope, an effective period and consequences if it is interpreted incorrectly.
While working with payer policies, we encountered a document whose AI-generated summaries described the same timing requirement in three different ways: six weeks, twelve weeks and three months. It was the source policy, rather than the most confident-sounding summary, that resolved the discrepancy; had we treated one of those summaries as authoritative, a disagreement between model outputs could have become an incorrect billing rule and then been repeated throughout the workflow.
A rule derived from a policy should therefore remain a proposal until an authorized person has checked it against the source and approved its interpretation. Its record should identify the payer, plan, provider type and other relevant scope; retain the source document and the passage supporting the interpretation; capture publication and effective dates, the approver and the approved rule version; and preserve which version was used for each claim. When a policy changes, the replacement rule should be reviewed and tested before it becomes active, while earlier claims must remain reproducible against the rules that applied on their dates of service.
It is equally important to distinguish between a rule that has passed and a rule that never ran: the fact that no edit matched does not establish that the claim is clear. A validation engine can only assess the rules it knows about, so it should report which checks were completed, which could not run and which areas remain outside its coverage. That gives the biller a meaningful result instead of a reassuring but potentially misleading “passed” status.
Automation can multiply a bad assumption
A rule can behave consistently and still encode a bad assumption; in a high-volume billing operation, a weak proxy can become part of the production workflow and be applied to thousands of claims before anyone recognizes what the rule is actually measuring.
In November 2024, UCHealth agreed to pay $23 million to resolve allegations involving emergency-department billing. According to the US Department of Justice, certain claims were automatically assigned CPT 99285, the highest-level emergency-department facility evaluation and management code, when vital signs had been checked more often than the number of hours a patient spent in the department, subject to an exception for stays under 60 minutes. The government alleged that this rule did not reflect the patient's condition or the facility resources used. The matter was resolved by settlement, so these remain allegations rather than findings made at trial; the DOJ described an automatic coding rule, not an AI system.
UCHealth's case did not involve generative AI, but it demonstrates that the underlying risk is not new: once a weak signal is converted into a rule, automation can apply the same flawed assumption over and over again, and deterministic execution does not make the resulting decision clinically or operationally sound.
HHS OIG's February 2026 Medicare Advantage compliance guidance raises a related concern about AI-generated prompts in electronic medical records. It identifies prompts that may encourage physicians to add risk-adjustment diagnoses that patients did not have, or that did not affect their care, treatment or management, as a potential compliance risk. The guidance is voluntary and nonbinding, and applies specifically to Medicare Advantage; it does not suggest that every AI-generated prompt is improper. Its broader relevance to system design is that a diagnosis suggestion must be supported by the record and the patient's care, rather than accepted simply because software produced it. The OIG guidance explains the agency's position in more detail.
Human review must be part of the workflow
Human review matters only when the person reviewing the claim has enough information and authority to change the outcome. A qualified reviewer must be able to challenge an extraction, question a rule result, resolve an exception and stop submission; when the interface presents only a green status and an AI-generated summary, approval can quickly become a rubber stamp instead of a meaningful control.
Indiana's 2026 health-claims law makes this practical requirement especially clear. Enrolled as HB 1271 and effective July 1, 2026, it prohibits a provider from using an automated process, system or tool to submit a health benefits claim without review by a provider or another person involved in developing the claim for submission. The provider-side provision is not limited to generative AI, so a deterministic validation gate does not replace the required human review. The law also contains separate provisions addressing insurers' use of automated tools in certain downcoding decisions. The enrolled text of Indiana HB 1271 is the primary source.
The specific legal requirements vary by jurisdiction and payer program, and organizations should obtain legal advice on their own obligations. From an engineering perspective, however, the practical requirement is clear: make the approval step visible, record who completed it and ensure the system cannot mistake its own successful checks for a person's approval.
Keep the evidence with the decision
When a payer questions a claim or an auditor reviews it later, the final code is only the beginning of the explanation. The organization may need to reconstruct which clinical document supported that code, which policy and coding-edit versions applied on the date of service, what the system flagged, what the biller changed and who approved the submission.
That requires retaining more than the final claim: references to the source documents, the extracted values, the model and extraction version where available, the rule and policy versions, validation results, unresolved exceptions, reviewer edits, approval and the exact claim version that was submitted. Someone reviewing the record months later should be able to follow the decision from its source evidence through to the final transaction without depending on the memory of the person who handled it.
A dashboard full of green indicators may show that the system completed its checks, but only a traceable decision record can explain why the claim took the form it did, what evidence supported it and who accepted the remaining uncertainty. That record also gives the organization a way to investigate recurring problems, from document types that produce unreliable extraction to payer rules that generate repeated holds or suggestions that reviewers routinely correct.
Build around the workflow you already have
Most RCM companies and healthcare software vendors do not need another platform claiming to replace the entire revenue cycle. They may already rely on an EHR, a practice-management system, a billing application and a clearinghouse. In many cases, the more valuable opportunity is to solve a specific weakness in that existing workflow: extracting information from a difficult document type, maintaining payer rules more reliably, validating claims before they enter the submission queue or connecting systems that do not exchange information cleanly.
These are engineering problems that call for document intelligence, structured data, payer and coding-rule management, integration with existing systems, reviewer workflows and an evidence record that can be reconstructed later. The right combination depends on the specialty, payer mix and actual billing process, which is why a generic rule set or a one-size-fits-all automation layer is unlikely to be enough.
At Tech4Biz, we have built a workflow that takes a surgeon's dictated operative note through document extraction and claim preparation, then runs configured coding and payer checks before a biller reviews the draft. The purpose is not to remove the biller from the process, but to give that person a better-prepared claim with the supporting evidence and validation results available at the point where a decision has to be made.
Our work on regulated quality-management platforms and safety-critical hardware and firmware has reinforced the same engineering discipline: preserve the source, control changes, record approvals and make decisions explainable after the fact. Healthcare claims deserve that level of care, particularly when automated systems are helping prepare information that will ultimately support a financial and clinical decision.
AI should do the work it is good at: reading documents and preparing a structured claim. Approved rules should verify the checks that can be expressed explicitly, while a qualified person examines the source evidence, resolves anything that remains uncertain and makes the decision to submit.
For RCM companies and healthcare software vendors, the best starting point is rarely a broad automation program. It is one recurring source of rework where better evidence, reliable rules or a clearer review step could make a meaningful difference.
Improving a healthcare claims workflow?
Start with the part that causes recurring rework: document extraction, payer rules, claim validation or the handoffs between systems.
Discuss your claims workflow ↗Primary references: Experian Health, State of Claims Report 2026 · Experian Health, 2026 survey analysis · CMS, Medicare NCCI PTP Edits · CMS, Medicare NCCI FAQ Library · US Department of Justice, UCHealth settlement, November 12, 2024 · HHS OIG, Medicare Advantage Compliance Program Guidance, February 2026 · CMS, Interoperability and Prior Authorization Final Rule · Indiana General Assembly, Enrolled House Bill 1271.
