Autonomous coding vendors sell a clean story: install the tool, accuracy climbs, the coder shortage stops mattering. Kelly Pierson, Director of Coding and CDI at MercyHealth, will tell you that's the easy part — and the part that fails first when the documentation foundation isn't there.

For RCM leaders evaluating autonomous coding in the next twelve months, the operator question is not whether the technology works. It's whether your documentation, your governance, and your physician relationships can support it without quietly creating compliance exposure at scale.

Pierson led MercyHealth's autonomous coding rollout after the team concluded that hiring alone could not close the gap. Her playbook is worth reading not because every system should copy it, but because it surfaces what the work actually requires once the contract is signed.

 The Business Case Was Staffing, Not Innovation 

 MercyHealth did not pursue autonomous coding because AI was fashionable. The team pursued it because the math on hiring had stopped working.

“We just couldn’t hire enough experience certified coders to keep pace with our current charge volumes,” said Pierson.

Pierson felt autonomous coding could help with staffing issues because autonomous coding uses artificial intelligence (AI) to read the clinical documentation, apply the proper coding guidelines, and then generate complete, compliant code sets. Pierson's VP of revenue cycle and CEO recognized early that the backlog and future growth could not be absorbed through recruitment. The targets were concrete: pre-AR days, throughput, and a scalable coding model. The technology decision followed the operational problem, not the other way around.

That sequencing matters. Pierson's first piece of advice to peers is blunt: "You have to take a look at what's the problem you're trying to solve for," said Pierson.

Autonomous coding tied to DNFB coding days, pre-AR days, or staffing constraints gives leadership something to measure. Autonomous coding tied to "innovation" gives leadership nothing to defend when denials move the wrong way.

And once the problem is named, the next question is whether the documentation can carry the load.

 AI Readiness Is Documentation Readiness 

 This is the line Pierson kept returning to, and it's the line most vendor decks skip past.

“At the end of the day, the solution’s only as good as the documentation,” said Pierson.

Before go-live, MercyHealth analyzed how the autonomous vendor would interact with existing documentation and ran pre-live testing to confirm consistent logic across providers. Pierson described the failure modes in both directions. Documentation lacking specificity gets downcoded even when the visit clinically supports a higher level. Overly broad or unnecessary documentation creates upcoding risk when it exceeds medical necessity.

The operator implication is uncomfortable. Automation does not forgive weak documentation; it scales it. A template gap that produced occasional manual errors becomes a systemic pattern when an AI applies the same logic to every chart. Pierson framed how thin the margin is: “One or two words can shift that visit in a direction that the clinician was not intending,” said Pierson.

That fragility is why readiness is not a checkbox. It's an assessment of templates, provider specificity, and how the vendor's logic interprets what your clinicians actually write. Without that work upfront, the rollout becomes a compliance project in disguise.

Which leads to the question most implementations underestimate: who owns the decisions once the tool is live.

 The Four-Month Lesson on Coding Logic Traceability 

 About four months into MercyHealth's implementation, Pierson's team needed to revisit a coding logic tweak. The problem wasn't the tweak itself. It was reconstructing the decision trail.

Who made the call? When? Who approved it? The team found itself working backward. That experience produced one of Pierson's clearest lessons: a dedicated coding project manager is not a luxury role. It is the function that keeps logic decisions documented, leadership aligned, and the vendor synchronized with internal operations.

The capability matters more than the org chart. Whether a system staffs this role internally, draws it from a partner, or builds it into a hybrid governance model depends on size, maturity, and existing PMO depth. What does not vary is the requirement. Autonomous coding generates a steady flow of small logic decisions, and each one has downstream revenue and compliance effects. Without disciplined ownership, those decisions are difficult to reconstruct after the fact.

Pierson's team also learned that the coding department cannot run this alone. A successful rollout pulled in coding, compliance, revenue integrity, IT, operational leaders, and physician champions. Each function carries a different risk lens.

That clinician piece is where Pierson said she would push earlier if she did the project again.

Bring Physicians in Before They Need to be Convinced 

 Pierson's advice is to start clinician engagement sooner than feels necessary.

MercyHealth used physician advisors and medical directors to explain the initiative, walk providers through the safeguards, and answer the why behind the change. The advisors they leaned on were clinicians who already understood coding and produced quality documentation — people who could engage with how the tool was reading their notes and where small adjustments would change the AI's interpretation.

Pierson noted that MercyHealth had an advantage: providers there code their own clinic charges, with coders validating afterward. That baseline literacy made the conversations more productive. Systems without that starting point will need to budget more education time, not less.

The point is not that every system needs the same physician advisor structure. The point is that clinician trust is part of implementation risk management. If providers experience autonomous coding as an opaque billing change imposed on their documentation, adoption suffers and documentation quality drifts. If they experience it as a tool with safeguards explained by peers they respect, the feedback loop works.

And once that loop works, the data the tool produces becomes something most coding operations have never had.

Trending Data Turns Coding Into a Physician Education Engine 

 One of the more underappreciated outputs of autonomous coding is what it reveals about provider documentation patterns at scale.

Pierson described provider trending reports that surface outliers. If there are clinicians who consistently shift from a level three to a level four, or who get downcoded the other direction, the coders are able to take specific examples back to the provider. The conversation is concrete: prescription drug management criteria missing from the note, or chronic conditions not documented to the required specificity can impact the bottom line.

This is education that manual auditing rarely produces, because manual auditing just looks at samples. Trending across the full charge volume exposes patterns that sampled reviews cannot see.

The operator requirement here is the workflow to act on the data. Reports that nobody owns produce nothing. Coders trained to translate trend data into specific provider conversations produce compliant charge capture improvements over time. That capability, call it documentation governance, or provider education infrastructure, is what converts the tool's output into durable value.

It also requires that the oversight model be designed for continuous monitoring, not one-time validation.

Layered Audit, Not Set-and-Forget 

 Pierson's experience runs against the assumption that autonomous coding means lighter oversight.

“It was never about removing oversight from a coder perspective,” Pierson said. “But instead creating a scalable process where we had strong governance and continuous monitoring built into the daily workflows.”

At go-live, MercyHealth performed a 100% review of all providers and any new specialties. Coders validated both accuracy and how the tool was interacting with provider templates. Beyond go-live, the team maintained a quality review work queue that sampled charges, engaged backend auditors who reviewed downstream, and compiled monthly provider performance reviews that fed the education loop.

The metrics Pierson watches reflect that layered posture: coding accuracy through quality audits, denial trends, documentation quality, provider trending, DNFB coding days, pre-AR days, and the volume of manual intervention required for exceptions and escalations. That last one matters operationally — rising manual intervention is the early signal that logic needs refinement or documentation has drifted.

For RCM leaders building the business case, this is the line item that often disappears from vendor ROI models. Continuous QA, project management, auditor capacity, and physician education are not optional overhead. They are what makes the accuracy number defensible under audit.

Which raises the question of what the coder role looks like once this infrastructure is in place.

 The Coder Role Becomes Validation, Analytics, and Governance 

 Pierson does not believe autonomous coding eliminates the coding workforce. She believes it reshapes the work.

“The AI can’t do that human decision-making, especially in healthcare coding because it’s so nuanced,” said Pierson. “But it can improve efficiencies.”

In her view, autonomous coding will be most effective in high-volume, low-complexity cases. Complex reviews, provider education, and AI governance still require experienced coders. The role shifts from manual code assignment toward quality validation, data analytics, and clinician education.

For RCM leaders, this is a hiring and upskilling question, not just a technology question. The coders who thrive in the new structure are the ones who can read trend data, hold a substantive conversation with a physician about documentation specificity, and recognize when the tool's logic needs refinement. That's a different competency profile than chart-by-chart production coding.

It also reframes the change management conversation with the existing team. The pitch is not "we're replacing you." The pitch is that the work elevates, and the system needs the experienced judgment more than ever for the cases AI cannot handle.

What Changes Monday, What Changes This Year

The operator takeaway from Pierson's experience is not that every health system should replicate MercyHealth's exact build. Operating models vary by size, geography, and existing maturity. Some systems will develop these capabilities internally. Others will acquire them through partnership or managed services. Many will land on a hybrid.

What does not vary are the underlying requirements. Before signing an autonomous coding contract, the operator work is clear:

• Name the operational problem in concrete terms — pre-AR days, DNFB, staffing constraints — not "AI adoption".
• Assess documentation quality and template design before evaluating vendors, not after go-live.
• Identify who will own coding logic decisions and decision traceability from day one.
• Engage physician advocates earlier than feels necessary.
• Budget for layered, continuous QA, not a one-time go-live validation.
• Plan the coder role redesign toward validation, analytics, and governance.

Pearson's closing advice that these steps are really the foundation of the entire solution is worth taking to the next vendor demo. The AI is the easy part. The documentation, the governance, the physician trust, and the audit discipline are the work.