In 2016, Michael Laukaitis, Director of Revenue Cycle Analytics, Accounting, and Quality Assurance at UT Southwestern, sat in a presentation in Austin and heard a Microsoft speaker say payers were already using AI. His reaction now is blunt: providers are still behind. If your denials team is hand-building appeals against claims that were scrubbed through payer algorithms with little or no human review, this is not an abstract innovation gap. It is an operating gap with reimbursement consequences.
UT Southwestern's response was not to buy an AI tool first. It built the stack in sequence: analytics, workflow redesign, robotic process automation (RPA), artificial intelligence (AI), then agents — and generated about $4.5 million in FTE savings over six years along the way, with about $1.5 million in the last year alone. The roadmap is worth studying. So is what Laukaitis built before the bots.
Laukaitis attended that 2016 Austin presentation and walked out with a clear takeaway: payers were already automating, and healthcare organizations were far behind.
When asked if he thought that a majority of first-pass denials are AI generated, Laukaitis said that it was a fair statement that a human likely has not looked at them. He said they are scrubbed and scraped through algorithms the payer built using AI tools. He typically does not see human touch on a claim until the first or second appeal.
That changes the math on denial management. If your appeals workflow assumes a person on the other side considered the claim, you are designing for a counterparty that often does not exist at the first-pass stage. The implication is operational, not philosophical: providers need faster analytics, AI-assisted appeals, and agents that have ingested payer policies. Laukaitis' team has already loaded payer policies into an agent and is running an AI appeals engine to draft appeals, identify trends, flag anomalies, and surface DRG downgrades.
The temptation is to license a tool. Laukaitis' progression makes the case for a different order of operations. Eight years ago, his team focused on analytics: gathering data, building reports, getting visibility. About six years ago, they moved into workflow analysis — looking at gaps, finding leakage, identifying high-volume, low-complexity work that should be automated. Then came RPA. About three years ago, AI for content creation. Agents came roughly a year after that.
When you skip a step you automate broken work.
"We call these emotional support bots and it's just to tell the uppers, hey, we've actually, we've got an RPA division, we have bots running,” said Laukaitis. “But what they've done is they've taken a workflow that was broken and just put a bot on top of it.”
The discipline that prevents emotional support bots is not glamorous. Laukaitis' team sits with end users, records sessions, times the work, and runs the five whys in the background while a Lean Six Sigma project removes waste from the workflow. Only then do they decide whether the workflow is a bot candidate. If it isn't, they don't automate it.
This is also where Laukaitis' most undervalued operator advice lives: it is okay to say no. Loud requests from leadership for visible automation often target workflows that do not have the volume to justify the build. "There are bigger fish to go for in the ocean, so," he said. Operators who cannot say no spend cycles on the wrong work.
Before any of UT Southwestern's automation scaled, Laukaitis' team did the unglamorous work that most programs defer: they built an SOP library. End users and SMEs documented their workflows on a standardized template. The team centralized the documents in a shared repository. The stated reason at the time was training and quality assurance. The strategic payoff arrived later.
That SOP library is now the substrate for an AI agent named Sophie. Staff can ask Sophie workflow questions. Sophie returns step-by-step diagrams, points to the relevant SOP, and surfaces the document itself. The team also loads Epic upgrade documentation into Sophie. When an upgrade changes a workflow, Sophie compares the upgrade against the existing SOP and flags the mismatch for review.
"We always say, if it's not documented, it didn't happen,” said Laukaitis. “Or if it's not documented, we can't test it.”
The implication for RCM leaders is uncomfortable. The SOP library you have been treating as a training artifact or a compliance checkbox is, in an agentic environment, the differentiator. Agents need clean, current, machine-readable procedure to act inside guardrails. If your SOPs are stale, inconsistent, or maintained by whoever has time, your AI ceiling is set before you license a single tool.
Laukaitis tracks which SOPs are being viewed, which are stale, and examines which leaders have a review routine — including whether they use a quarterly review. He uses that data to encourage cross-team communication so leaders who aren't keeping their SOPs current can learn from those who are. The discipline is recursive: analytics on the documentation that feeds the automation that the analytics measures.
The discipline pays. About $4.5 million in FTE savings over six years. Roughly $1.5 million last year alone. Those FTEs were redeployed to other parts of the revenue cycle, not eliminated.
The number that should matter more to a CFO is throughput. Laukaitis described a Medicaid coverage retrieval bot that took over work previously handled by four staff members who, working manually, could process about 16,000 accounts roughly once every three months. The bot now processes the same volume once every 16 days. Those four staff were moved to other areas of the revenue cycle.
That is not labor substitution. That is cycle-time compression on a workflow where speed directly affects reimbursement, patient billing accuracy, and bad debt. A patient whose Medicaid coverage is found in 16 days instead of three months gets a different bill, a different financial experience, and avoids a self-pay statement that should never have gone out. That is the patient financial experience side of the same automation decision — and it is one of the clearest examples of why coverage discovery cycle time is a clinical-adjacent outcome, not a back-office metric.
Accuracy compounds the gain. A bot does not make typos. It does not skip a step on a Friday afternoon. On high-volume, low-complexity workflows like Medicaid coverage retrieval, deterministic execution beats human attention degrading under volume.
None of this scales if analytics live in the wrong place. Laukaitis is careful here. UT Southwestern has a capable IT-based analytics team. The problem was not skill, it was speed and revenue cycle fluency. Report writers serving multiple departments and software systems were not RCM-centric. There was a communication breakdown — leaders asked for one thing and got another, then iterated.
His operational analytics team closed that gap by speaking the same language as the directors and VPs requesting the work, and by starting every conversation with the actual end goal rather than the column-by-column spec.
"Because sometimes what the ask is, isn't really what the end goal should be,” Laukaitis said.
Speed matters because lag is revenue loss. Every day a problem is not analyzed or fixed is reimbursement at risk. Laukaitis' early goal was to have the report done before the meeting ended — he was in the room, he understood the data, he had built it. That is the standard operations-embedded analytics is built to meet.
The objection is predictable: this sounds like RCM going rogue around IT but Laukaitis pre-empted it. His team lives outside IT but follows all IT governance, all access policies, all security procedures. They request access through proper channels. They work in tandem with the IT analytics group. The autonomy is operational; the rules are not optional. Operators considering this org design need to understand that the trade only works if the governance discipline is real. Skip it and you create the kind of shadow analytics that gets shut down the first time security audits the environment.
Adoption resistance from staff and access constraints from security teams are the next obstacles.
Laukaitis' approach to laggards is not strategy slogans. He sits the person down and asks what their biggest weekly frustrations are. Then he inserts AI into one of them. Building a PowerPoint that used to take hours now takes seconds with Gamma — he cited 30 seconds for a usable deck. Drafting a denial appeal. The point is to solve a real pain in front of the person, once, with one tool.
For the staff anxiety question, his framing is blunt and useful: AI will only replace you if you let it. He pointed back to the EMR conversion era. People who feared change and disengaged got left behind. People who embraced it moved into roles like EMR engineering, screen building, and medical record transfer work. His own team's mentorship program — teaching SQL, Python, and UiPath development to staff with imagination or technical aptitude — is how UT Southwestern built most of its analytics bench.
For the security objection, Laukaitis offered a workaround that does not violate policy. When his enterprise access was limited, he used a personal GPT — he calls it Carl — to load public payer policies, pose hypotheticals, and pressure-test his thinking. No PHI. No proprietary data. Just public information used to build literacy and stress-test ideas. He treats Carl like a colleague who asks clarifying questions back, which reduces hallucinations and forces sharper inputs.
Operators know the security argument is not always about security. Sometimes it is about a security team that has not been given a workable framework. Personal experimentation on public data is a legitimate way to build the capability inside the organization while the governance conversation matures.
Payers industrialized denial automation years ago. Provider RCM organizations that have not sequenced analytics, process redesign, RPA, and AI in that order risk slower recovery, more write-offs, and more revenue leakage as the gap compounds. The fix is not a tool purchase. It is a sequence, and the unsexy steps are the ones that determine whether the sexy ones work.
Three things a VP of Revenue Cycle can do this week:
"The goal isn't just to automate tasks or to put agents in,” said Laukaitis. “It would be to build a smarter operating system for a revenue cycle and to make sure, again, workflows are working for you and working for the patient and are as efficient as possible.”
The providers who treat that as the work — not the tools — will close the gap. The ones who keep buying bots to prove they have a bot program will keep losing claims to algorithms they never see, written by counterparties who started this work years before they did.