About every 10 years, a new technology arrives in the healthcare revenue cycle that promises to solve everything. Sometimes it does. More often, it improves some things while introducing new complications or shifts work to a different workflow or problem area.
The difference between those outcomes typically depends on whether the right subject matter experts were involved in vetting and defining the scope of the solution before going live.
Autonomous coding is one of those technologies. The market attention is real. The vendor landscape is growing. And the pressure on health information (HI) and revenue cycle leaders to evaluate, pilot, and implement is intensifying. Workforce shortages are not improving. Coding backlogs are not shrinking on their own.
The need for teams to become more proactive and less reactive is growing in this payer-driven environment. Staying status quo with manual operations and reactivity is no longer an option in today's revenue cycle.
What I have seen repeatedly when working directly with health systems navigating this space is that the organizations struggling with autonomous coding do not fail solely because the technology is inaccurate. They fail because the organization with their vendor partner never clearly defined what success looked like, who owned the operational decisions and outcomes, or what tradeoffs were acceptable before they went live.
The Reality Neither Side Tells You
Autonomous coding vendors will show you accuracy rates that claim 95 percent or higher. What they don’t always show you is the denominator and methodology behind the number, which cases were included and excluded, and if weighted scoring was applied across code sets (i.e., ICD-10-CM, CPT, modifiers).
Autonomous coding engines perform well in defined, high-volume encounter types where the provider's clinical documentation content is consistent and complete. Outpatient facility coding, professional coding, certain procedural and surgical categories, and high-volume emergency department (ED) encounters are areas where performance tends to be strongest.
Inpatient stays are different. The volume of documentation an engine must parse through on a single inpatient encounter is significant, and achieving the level of diagnosis specificity required and building in the inpatient coding rules takes time and technology development to get it right. The engines are not there yet for that use case, just as a newly credentialed coder is not placed on inpatient encounters on their first day. Research shows the shift is from repetitive task execution toward higher level processing including case review, audit, and documentation integrity, with the engine handling volume and experienced coders providing judgment.
Neither humans nor machines are perfectly accurate. Human coding carries subjectivity and differing interpretations of coding guidelines. The question is not whether automation is better than a perfect coder. The question is whether your organization can partner with your autonomous coding vendor effectively enough to communicate your internal coding philosophies and organization-specific guidelines, so that the engine codes the way you would train a new hire to code.
A Readiness Framework
Before any conversation about vendors, contracts, or go-live timelines, HI leaders need to work through five foundational questions. They require honest and collaborative answers from revenue integrity, coding operations, compliance, and IT stakeholders.
1. What problem are you trying to solve?
This sounds obvious. But it rarely gets answered with enough specificity.
Some autonomous coding systems are built for accuracy and specificity, the right fit if inconsistent primary diagnosis coding is driving your denials. Others are optimized for volume and coverage, the right fit if throughput and automation rate are your primary goals. Those are the extremes, but the point is the same—you need to know your priorities before you can pick the right tool. Knowing which problem you’re trying to resolve determines which engine belongs in your environment, which metrics you track, and what a realistic outcome looks like.
2. How will you define and measure accuracy in your environment?
Vendor-reported accuracy rates are a starting point and should be built into your contract as a Service Level Agreement (SLA) along with how those rates are calculated. But before you can hold a vendor to a standard, you should be honest about how your teams perform on coding accuracy and quality. That means looking at internal coders, external contracted coders, and outsourced partners. Human coding is subjective, guidelines change constantly, interpretations vary, and there are tens of thousands of diagnosis code options. We all want to say our teams are the best, but accuracy is difficult to sustain at a consistent level across every encounter type.
My recommendation is to define your baseline with your vendor. That honest number matters for two reasons. First, it sets a fair and defensible threshold for what accuracy from the engine needs to look like by code set and the methodology for measuring it. Second, it gives your vendor partner something actionable. They need to know where your human performance has been inconsistent, so they know where there is opportunity for improvement. If you go in with an inflated benchmark, you will spend the first six months arguing about numbers instead of improving them.
3. Do you have a compliance oversight structure built for automation?
Autonomous coding carries compliance implications that must be addressed explicitly. With a human coder, an error is an error—one encounter, one claim, one correction. With an engine, a misconfiguration or a misapplied coding logic does not make one mistake. It makes the same mistake hundreds or thousands of times before anyone catches it.
That’s not a reason to avoid automation; it’s a reason to build your audit methodology before you go live. Define how the automated population will be audited, at what frequency, by whom, and what the escalation path looks like when a systematic issue surfaces. The compliance risk in autonomous coding is not random. It is repeatable, and repeatable risk requires a fundamentally different oversight structure than the one you built around individual human coders.
4. Which use cases are suited for automation?
Not all coding is equal, and not all coding should be automated on the same timeline. Current evidence shows that autonomous coding is most prevalent and mature in radiology and ED environments, with most health systems working to broaden use cases. Start with your highest-volume, lowest-complexity encounter types and build both performance data and trust before expanding scope. You can always upskill your staff coders. Resist pressure from vendors or internal stakeholders to go broad before you have validated performance.
5. Who owns the outcomes?
Autonomous coding implementations fail in the governance gap. Vendors own the engine. HI owns the coding. Revenue integrity owns the charges. Revenue cycle owns the financial performance. Compliance owns the risk. And as obvious as that sounds, it needs to go deeper: who owns the audits and the decision to automate a specific charge or not? Designate that ownership from the time of evaluation to implementation, not at the time of go-live.
A Partnership Model That Works
The health systems that see the best results from autonomous coding share a common approach—they treat it as an ongoing operational partnership with the technology deployment. That means regular performance reviews with the vendor, transparent data sharing, escalation protocols for performance degradation (either automation rates or accuracy), and a contractual structure that aligns vendor incentives with your operational outcomes.
Evidence from early-adopter health systems points to a consistent pattern: organizations that benefit most from autonomous coding report strong vendor support and implementation engagement. Those that struggle most often cite functionality gaps and a lack of transparency around product direction. That gap is navigable, but only if your organization is asking the right questions during contracting, holding vendors accountable through structured performance reviews, trusting your vendor is being honest about its strengths and weaknesses, and then mapping those back to your organization's needs.
It also means internal leadership that stays engaged. Autonomous coding requires sustained attention from HI leadership, revenue integrity, and compliance. Organizations that deprioritize that attention after go-live end up back at the table trying to explain to their CFO why automation did not deliver what was promised.
The engine is not the strategy. Like any artificial intelligence tool, automated coding is only as good as the inputs, context, and oversight provided by the humans working with it. The strategy is the governance structure, the measurement discipline, the human expertise, and the organizational clarity you build around it.
Is Your Organization Prepared?
Just as computer-assisted coding and encoders before it, autonomous coding is not going away. For most health systems, the question is no longer whether autonomous coding has a role. It is whether your organization is prepared to implement it in a way that delivers sustainable results.
The effectiveness of autonomous coding lies in the algorithm itself, but just as importantly in thoughtful integration, human oversight, and continuous review and refinement. It is not designed to replace human coders, but to empower them.
Autonomous coding is not the hero of your revenue cycle story. It is also not the villain. It is a capable tool with a defined operating range, and the results you get from it will reflect, more than anything else, the quality of the framework you build around it.
Kacie Geretz, RHIA, CPMA, CCA, CPC, is Director of Growth Enablement at Nym Health in New York.
By Kacie Geretz, RHIA, CPMA, CCA, CPC