AI Attestation: An Issue Worth Discussing in Coding

A health system implements an autonomous coding system for a defined group of encounters. Internal benchmarks indicate strong overall performance, and encounters above a configured confidence threshold move through an auto-acceptance pathway without coder review.

Over the course of a quarter, a denial pattern surfaces. A reviewer traces it to a recurring miscoding issue affecting a substantial number of claims involving the same clinical scenario. Each affected encounter had been categorized as high confidence.

This scenario raises a question at the center of the artificial intelligence (AI) attestation discussion: Does the use of autonomous coding create a separate need for documented human sign-off, or does the longstanding standard—that the coding be supported by the documentation and reported correctly—remain unchanged?

The conversation around AI attestation is partly a response to questions like this. In some discussions, the term is presented as an emerging expectation or requirement. It is often used to describe documented human review and approval of coding completed through an automated workflow before submission. Working definitions vary, and the term is new enough that its precise meaning is still being worked out in practice.

The Centers for Medicare & Medicaid Services (CMS) materials reviewed for this article do not establish a separate AI-specific attestation requirement for providers. For health information (HI) professionals, the value of examining the term may lie less in treating it as an established requirement and more in the practical questions it raises about accountability, review, and auditability in AI-assisted coding workflows.

What CMS Documents Say

CMS audit and integrity documents focus on documentation support and auditability.

The Medicare Advantage Risk Adjustment Data Validation (RADV) program is described in CMS materials as a process by which CMS confirms that diagnosis codes submitted for risk adjustment are supported by the enrollee’s medical records, with unsupported diagnoses potentially leading to overpayment recovery.

The Medicare Program Integrity Manual directs contractors to review medical record documentation when assessing whether billed services are supported, reasonable and necessary, and coded correctly. The manual emphasizes whether the documentation supports what was billed and whether applicable coding requirements were followed. It does not explicitly address how the coding was performed.

CMS has also published guidance on AI use within its own operations. CMS’s public AI materials, including its foundational AI guidance, address human accountability for the outputs of AI-enabled systems.  These materials describe CMS’s internal posture rather than formal requirements directed at providers, but they offer some indication of how the agency discusses AI in operational contexts.

What these documents have in common is an emphasis on outcomes, whether the code is supported, and whether responsibility for the decision is clear, rather than on the process through which the coding was performed.

In the CMS materials, audit and payment determinations focus on whether submitted diagnoses, services, and codes are supported by the medical record and reported correctly. Those materials do not identify a separate attestation requirement based specifically on whether coding was performed by a person or through an automated workflow. The AI attestation conversation is therefore not about applying a different documentation standard to automated coding; it is about how organizations establish accountability, oversight, and auditability when some or all of the coding process is automated.

A Framing from Audit Practice

One way to organize the conversation is by considering the control functions familiar from audit practice. Preventive and detective controls are both relevant, although the distinction between them can depend on the point in the workflow being evaluated.

A preventive control is designed to reduce the likelihood that an error will be introduced or allowed to advance to the next stage. Examples might include standardized coding policies, competency requirements, automated pre-bill edits that block invalid code combinations, and workflow rules that route defined cases for additional review.

A detective control identifies an error or deviation after a coding action has occurred. Second-level coding reviews, retrospective sampling, denial analysis, and ongoing performance monitoring can serve as detective controls.

Some controls perform both functions. A pre-submission review, for example, is detective because it may identify an error after a code has been recommended or assigned. It is also preventive because it can stop that error from reaching claim submission. Clinical documentation integrity processes and automated edits may similarly serve preventive, detective, or combined functions depending on their design and placement in the workflow.

Most coding quality programs use a combination of these controls. The appropriate balance depends on the workflow, the risk profile, the cost and consequences of errors, and the organization’s available resources.

When a coding workflow uses an automated system at scale, the speed and potential correlation of errors warrant attention. A model defect, configuration issue, or poorly calibrated threshold may affect many encounters before monitoring identifies the pattern. Some errors may recur across similar encounters, while others may vary by documentation, service line, code category, patient population, or system version.

The distinctive risk is not that errors arising from automated coding are necessarily more serious than errors arising from other coding processes; it is that a shared issue may propagate rapidly across a concentrated group of encounters before detection, potentially increasing financial or compliance exposure. How much this possibility should change an organization’s control mix will depend on its workflow, volume, clinical context, and observed system performance.

Where Human Review Fits in the Workflow

A second way to organize the conversation is structurally, around where human review occurs within an AI-assisted coding workflow. The diagram below sketches one common pattern.

Figure 1. One common pattern for AI-assisted coding workflows. Implementations vary across organizations and vendors.

In this pattern, the automated coding system recommends or assigns codes with associated confidence scores. Codes above a threshold are routed one way (automatically for submission without pre-submission human review), while codes below the threshold are routed to a credentialed coder for review. The audit trail captures what happened at each stage, including what the system recommended or assigned, the associated confidence score, whether human review occurred, any changes made, and the resulting submitted code.

This is one pattern. Implementations vary considerably. Some organizations route all codes for human review regardless of score. Some only route low-confidence cases. Some use multiple thresholds for different code types. Some structure review differently altogether, with separate sampling processes for high-confidence codes after submission.

The components themselves are where the operational questions concentrate. Three in particular tend to come up in discussions of these workflows:

The confidence threshold is the value at which the routing decision is made. The relevant questions are how it is set, on what basis, who in the organization can adjust it, and what the change-control process looks like when it is adjusted. The threshold is consequential because it helps determine the proportion of codes that receive pre-submission review and the proportion that do not.

The review stage is where human-in-the-loop work occurs. The relevant questions include who performs the review, what qualifications they hold, what information they can access, what actions they are authorized to take, and how their decisions are documented. Organizations should also consider whether reviewers have sufficient time and authority to evaluate the automated output, rather than simply accept it.

A documented attestation can establish that a review occurred and connect the final coding decision to an identifiable person; it does not, by itself, demonstrate that the review was thorough or that the resulting codes were accurate. Automation bias, production expectations, and overreliance on confidence scores can turn human sign-off into a procedural step rather than a meaningful control. Attestation is more likely to add value when it is part of a broader quality program with defined review expectations, appropriate access to supporting documentation, clear pathways for correcting or escalating concerns, and ongoing monitoring of review decisions and coding outcomes.

The audit trail is the record of what happened. The relevant questions are what is captured at each stage, where it is stored, how it is accessed when needed, and how long it is retained. Applicable CMS documentation requirements focus on support for what was submitted, but an automated coding workflow also creates intermediate artifacts, such as system outputs, confidence scores, and reviewer changes, that may or may not be part of the formal documentation set.

These three components are familiar from HI practice in non-AI contexts. What is potentially new is the relationship among them when the upstream coding process is automated.

The vocabulary around AI in coding is still settling, and AI attestation is one of several terms competing for definition. It may persist as professional shorthand, appear in private-sector payer or vendor expectations, or give way to other terminology that captures the same concerns.

The questions underneath the term, however, are not new to HI practice. Documentation support, human review, control types, accountability, and audit trails are well-established concepts. What may be new is how they interact when some or all of the coding process is automated. Regardless of whether AI attestation becomes established terminology, these familiar concepts provide a practical foundation for evaluating and overseeing automated coding workflows.

Robin Tripp, MAS, RHIA, CCS-P, CPC, CRC, is Director of Education for Coding and Revenue Cycle at AHIMA.