How HIM leaders can set autonomous coding targets that hold up under scrutiny

Autonomous medical coding has moved from a future concept to a present reality for many health information management (HIM) departments. But as adoption grows, so does a familiar question: what percentage of coding should actually be automated? 

It's a fair question. It's also the wrong place to start. 

Starting with a target automation number and then designing a program to reach it can unintentionally pressure teams to meet a goal before the work has proven it is ready. Successful autonomous coding programs take the opposite path: they allow the work itself to establish the target. That means evaluating the types of encounters first, putting governance in place to protect accuracy, and measuring performance with enough precision to support and defend every decision. 

Here's how HIM leaders can approach that work in a way that builds trust, satisfies auditors, and scales responsibly over time. 
 

How should HIM leaders select candidates for autonomous coding? 

Before setting any target, look at the work itself. Not every encounter is a good fit for automation, and treating them as if they are is where many programs run into trouble. 

The best candidates for autonomous coding share five characteristics:

• High volume: Encounter types that occur frequently give you enough data to validate performance and catch issues early. 
• Repeatable: Cases with consistent documentation patterns and coding logic are easier to automate reliably. 
• Low complexity: Straightforward encounters with minimal variation reduce the risk of misclassification.
• Complete documentation: Cases with the documentation required for autonomous coding consistently captured in the technology are more likely to support successful automation.
• Common patterns: Routine visits, common diagnostic procedures, and well-documented recurring service lines often fit this profile well. Complex cases with ambiguous documentation, or encounters tied to high-dollar reimbursement typically don't, at least not at first. 

Starting here does two things. It protects coding accuracy from day one, and it gives your team a concrete, defensible reason for every encounter type included in the program. That matters more than any percentage. 
 

What governance rules should qualify an encounter for automation? 

Once you've identified strong candidate categories, the next step is building the governance layer that decides which type of encounters actually qualify. 

Qualification rules act as gatekeepers. They should account for documentation completeness, coding confidence thresholds, and any red flags that should trigger human review, such as missing clinical detail or conflicting information in the record.  

This governance layer is what separates a mature autonomous coding program from a risky one. Without clear qualification rules, "autonomous" can quietly become "unchecked." With them, every automated encounter has a documented reason for bypassing manual review, and every excluded chart has a documented reason too. That paper trail is exactly what compliance teams and auditors want to see. 
 

How do you measure the success of an autonomous coding program? 

Percentage of charts automated is a popular metric, but on its own, it tells an incomplete story. A more accurate picture comes from tracking three distinct rates. 

• Eligible — Is the encounter eligible for autonomous coding? Are all required documents for complete coding available? Is all necessary metadata complete and valid?
• Qualified — Is the encounter qualified for autonomous coding based on the AI model confidence scores? Did the encounter trigger any edits, such as medical necessity or bundling edits?
• Quality assurance — What percentage of qualified encounters will be automated versus reviewed through quality assurance? This should be determined based on internal risk tolerance and governance requirements. 

It is important to evaluate not only the level of agreement between the AI model and human coders, but also the highest-volume discrepancies to identify the causes of lower-than-expected agreement. Common causes include coders adding or removing codes based on personal preferences rather than established coding guidelines, as well as poor or ambiguous documentation. 

Tracking all three separately matters because a low no-touch rate could mean very different things depending on the context. It might mean your qualification rules are too strict, your documentation practices need improvement, or the technology itself needs tuning. Collapsing these into a single number hides which lever you actually need to pull.
 

How should HIM leaders expand automation over time? 

With candidate selection, governance, and measurement in place, expansion should follow the evidence, not a preset calendar. 

A phased rollout typically starts with a small, well-defined set of encounter types, running in parallel with existing manual coding for a defined validation period. During this phase, compare automated results against human-coded outcomes to confirm accuracy holds up. 

Once a category proves reliable, expand to the next set of encounter types. Each phase should include its own validation window, its own performance review, and its own decision point about whether to move forward, pause, or refine the rules. 

This approach produces a program that can survive an audit, a leadership change, or a compliance review with real performance data. 
 

Targeting what you can defend 

There's no universal number that represents the "right" amount of autonomous coding for every organization. The right target is the one supported by your documentation quality, your governance rules, and the performance data. It's a target you can explain to anyone who asks how you got there. 

HIM leaders who build their programs this way aren't just hitting a percentage. They're building a system that earns trust over time, protects patients through accurate coding, and gives their teams the confidence to keep expanding responsibly. 

MeChelle Walker, global product owner for autonomous coding, Solventum