Unreasonably Deep

Edited transcript. Lightly cleaned for readability, preserving the speakers' meaning and voice.

Introduction

Host: Welcome back to the Unreasonably Deep podcast. I'm joined again by Ayo Omojola, co-founder and CEO of Substrate. Today we're going deep on denials: all the different reasons payers say no, what it costs providers, and how AI agents are starting to change the fight. If you want the fuller picture on Ayo's background and how Substrate came to be, go back and listen to Episode 1, where we cover his and the company's origin story. For now, let's get right into it. Ayo, welcome back.

Ayo: Thank you for having me. Appreciate it. Let's go.

The revenue cycle, mapped

Host: Before we get to denials, give people the map. If you break the whole revenue cycle into different jobs, what is actually trying to get done? What has to happen in revenue cycle management?

Ayo: Holistically, revenue cycle is a lot of things. The way most of the world thinks about it, and the way we describe it, is that there's a first step called financial clearance, which is: what are these patients' benefits, and what services do they have access to based on their insurance? Second is first-pass payment. You submit a claim, and something happens. The third bucket is AR follow-up and denials. And the last is reconciliation. Reconciliation you can think of as: a claim has been adjudicated, decided, paid or denied, and that has to be written back to the clinical system of record, which is the EMR and PM.

Why denials

Host: Substrate puts a huge focus on denials, that one job of the four. Why is it this one that gets such a huge focus and so much of your effort?

Ayo: It is the primary surface where the friction in RCM manifests. The friction shows up in a bunch of places, but denials are where you've already done the work as a practice. The doctor has seen the patient, care has been delivered. It's the surface between care being delivered and the payment being rendered, and we think of it as one of the hardest problems in healthcare reimbursement. We focused on it because I lived through having subpar tools for it, and it's the most unfair thing. If you don't do the work, if you don't see the patient, you don't get paid, and who cares? That doesn't really matter. But if you see the patient, you care for them, you help them heal and make them better, and then you don't get paid on top of that, I find that very offensive.

Host: There's a chain of steps that takes place for a denial to get paid. It's not just one task to get the whole job done. What are those different tasks, and what tools are involved in getting a denial actually paid?

Ayo: Good question. At a high level, number one is awareness: knowing the denial happened. The second is comprehension, understanding why it happened. I think of that as research. You're going out to find information about the claim, the payer, the care that was delivered, and trying to synthesize all of that to understand exactly why it was done. After you understand why, there's remediation: converting that reason into the discrete steps you have to take to rectify it. That can look like appealing the claim, submitting a reconsideration, rebuilding the claim with changes, sending a corrected claim, or sending the claim to another payer. And the last piece is post-appeal follow-up: we came up with a hypothesis for why this claim wasn't paid, we acted on it, and now we track whether that resulted in the claim being paid, all the way to the end.

Host: Where is the pain most acute, and where is the money being lost most? There are both operational and financial implications. Where do you start, how do you prioritize?

Ayo: It really depends on the systems and sophistication the practice has. For practices that have experienced a lot of change, a lot of team turnover, maybe they've been acquired, merged, or divested, you'll often find the systems are built in a way that reduces awareness of what's happening. As a practice, you make a choice about your EMR, and that's usually a clinically driven choice. You can think of the EMR as the clinical system of record, the practice management system as the financial system of record, and the clearinghouse as the communication channel with the payers. Often you make the best clinical choice, but it comes bundled with a practice management system that isn't best in class, and then some clearinghouse you're attached to, and the way those things talk to each other just isn't standard. We've encountered cases where your practice management system does not receive rejected claims from the payer. So you might think a claim is denied, but what actually happened is the payer said, "You sent me a claim with the wrong member ID, please fix it." Because your PM didn't know, you just don't know there's a thing you can fix, turn around, and rebuild. So practices that have experienced a lot of change probably feel the most pain around awareness.

Then, for large-scale practices, denials can mean many things. Every encounter is different. Every payer is different. The same payer in two different states might operate differently. Down to the patient, who might have a health plan that operates in a certain way. So even if you're aware a claim is denied, figuring out why is very complex and sometimes requires a lot of expertise. Most veteran billers, once they know why a claim was denied, can very quickly reason about how to fix it. But actually getting that knowledge can be quite difficult. Those two, awareness and comprehension, tend to be the biggest in my opinion.

Dimensionalizing the financial loss

Host: From a financial perspective, can you dimensionalize the big buckets, where the money goes and how much it's costing? It ends up being big money, but people accept it as a baseline of "we're never going to get everything."

Ayo: The short answer is it depends on the practice, hospital billing versus physician billing are different things. The slightly longer answer: probably 20 to 30% is lost to cost, you're spending too much on people and software. There's probably another 15 to 20% that's working capital, because every day you don't get paid costs you money on average, and you have to borrow to finance that. Then the last 50% or so is bad debt you're writing off because you don't collect it, or underpayments where you do get paid but not enough relative to the care you provided. Things like down-coding, where you get paid but not enough, and it's not implicit. It's the payer explicitly saying, "We don't believe the level of service provided was a level 5, we think it was a level 3, and that's what we're going to pay you for."

Host: Why are some of those small claim denials worth chasing one by one? They look like they're not worth the effort.

Ayo: A lot of that is due to what's possible today, and this is one of the problems we solve. In the old world, you had humans looking at these claims, and you knew you couldn't touch all of them before they aged out past timely filing. And even within what you could reach, it's logical to prioritize large-ticket claims over smaller ones. The difference today is you really can touch every claim. Even if you didn't have confidence in an agent taking the right action on a claim, agents can dramatically reduce the amount of research a biller has to do to figure out what to do, then hand that to your team for the synthesis and the actions. Before, there was a timing thing, a size thing, and a prioritization thing. Today, almost all of those can be collapsed enough that you can touch 100% of your claims volume, no matter how small.

What is an agent?

Host: You mentioned the word "agent." Can you clarify for folks who may not be familiar with what you mean by it?

Ayo: I think of an agent as a large-language-model-assisted concept, for lack of a better way to describe it, that can take probabilistic actions on your claims the same way a human can. Very tactically, I'll use our claim status agent as an example. A biller investigating a claim might check the clearinghouse, the payer portal, the practice management system, call a payer, check the lockbox. It's a very diverse set of actions across a bunch of systems that your veteran billers might do, and a lot of that is guided by years of experience and instinct: "For this particular payer, here's where I'd go check." An agent is basically a machine that can do all those things. It can't replicate the instinct the veteran biller has, but it can do all the actions, touch everything in the course of research, bring it together, and synthesize it into a proposed response.

Host: So why can't people do this today, and why is it now possible? How much is that money really worth?

Ayo: The way the friction in RCM works is designed to force you to prioritize. A claim can be automatically denied, and historically that required a human to reason about it and research it. So imagine you have a setting wrong in your claim submission. For example, it's a claim that includes labs and you don't include a CLIA license number on the claims form, so the insurance company's system just rejects it. Now imagine you have a team staffed to look at a thousand denials a month, and because of that wrong setting your lab-related denial rate jumps from, say, 10% to 20%. All of a sudden, to touch every claim, you'd need to double your team. In reality, you'd just end up with a bigger backlog, and because of that backlog your team is forced to prioritize the claims that are early enough to be inside timely filing, plus the largest ones. You can't double your team in a week. But if you have agents in your RCM infrastructure, you can quickly adapt them to handle the spike and touch all those claims. If it's a simple change, like "add a CLIA license number and resubmit," you can just do that.

Putting it in the CFO's language

Host: Let's put this in the CFO's language. What does recovering close to 100% of claims actually do to cost-to-collect and to EBITDA or revenue? Be specific.

Ayo: I don't actually think you can recover 100% of all claims, because some denials should exist. Practices do make mistakes, that's real. But for a CFO: EBITDA is the output, on the right side of the equal sign. On the left side, there's how much you pay to collect, how much you expect to collect, how much you're actually able to collect, and how quickly. What agents let you do is dramatically reduce the cost to collect. At Substrate, in almost every workflow we've touched, we've driven at least a 70% reduction in cost to collect in those specific workflows. That's true today, and I know we're not the only ones doing it.

The other thing is your responses are now instant. Instead of queues that build over days and get worked down over days, the moment something hits a queue we touch, it gets resolved that day, about 8 times out of 10. That reduces your days sales outstanding, because whatever downstream action needed to happen just had two days removed from it. And those two dynamics mean your team now has way more time to touch more complex claims. So it's also possible for your team to get to 100% of claims. Don't assume agents will do 100% of claims and handle every case, because cases can be complex. But they buy your team time. A category of denials with a straightforward, common problem, you can have agents do that. Something really complicated, like calling your contracting rep to figure out why thousands of claims are being underpaid, that requires a human, because the Cigna contracting rep isn't going to answer your agent. Now your team actually has the bandwidth to go investigate those things.

Host: From a CFO perspective, what percent of the bad debt is now recoverable using agents to enhance the denial process?

Ayo: Of recoverable bad debt, you really can cut it by 75 to 80%. The unrecoverable things, where you needed a prior auth and didn't get one, that's always going to be bad debt, and it's an operational problem, not a denials-process problem. But if it really is recoverable, if it's a mistake, a policy-based denial where the payer doesn't believe the encounter was documented correctly, or an eligibility-based denial where you entered the wrong member ID, at any amount, down to the tens or hundreds of dollars on a specific claim, that's all recoverable now. The stuff you really have to worry about is upstream problems, where something before billing wasn't done correctly, and the payer is just never going to pay that claim.

Host: How much do companies normally have in bad debt for denials, and overall?

Ayo: We see everything. Really good is if bad debt is about 2% of your net revenue. We've seen cases up to 6, 7, 8%, or even higher.

Host: And you believe you can get two-thirds to three-quarters of that back?

Ayo: Yes, correct.

Host: That's a pretty big amount if you're a reasonably sized company. That's millions and millions of dollars, nothing to sneeze at.

The payer perspective and the friction

Host: Let's move to the payer perspective and the friction they add. First, how does it even happen? What's the difference between a rejection and a denial?

Ayo: I think of a payer rejection as: you submit a claim to the clearinghouse, and the payer has an instant, usually format- or formula-based reason, not related to anything clinical, to reject the claim. That could be "we don't know this patient," either because you literally sent the claim to the wrong payer, or you got something wrong on the member ID. In a rejection, the payer isn't reviewing anything about the substance of the claim. There's an upstream problem, and rejections are usually instant, within a day of submitting. A denial is when the payer has taken the claim through their claims process and accepted it. They've said, "This was formatted correctly, we know this patient," and then for some reason, usually clinical, financial, or contractual, they're effectively saying, "We know this claim, but we're not going to pay it."

Host: There's a whole set of coded language implemented to not pay: coding, medical necessity, records requests. Give us the tour of the different reasons. How many ways are there not to pay, and how much of it is a feature versus a bug?

Ayo: I don't think there's any malice to it. The results of the system are the proof of its design. I think of the big buckets the way we see them. There are eligibility-based denials, where something is wrong with the financial clearance process. As a provider, you might not be in-network with that payer, or the patient's name was spelled wrong, or the member ID was wrong, any number of things. That's one of the biggest and most frequent buckets. The second I'd call medical necessity denials, and I'm using that more broadly than the industry usually does. It's when the payer looks at the details on the claim and, relative to what they believe they're responsible for reimbursing, the details just aren't sufficient. For example, a mammogram was done bilaterally, on both sides, but the claim only outlined one side, and that's not standard of care. Or the patient needs to have tried a bunch of treatments first, physical therapy before a total knee replacement, and there's no evidence in the insurer's record that it was done. That second category covers medical necessity and sometimes coding-related denials. The third bucket I'd call administrative: bundling, where you're billing for a procedure the payer believes is reimbursed as part of another procedure done that day, or duplicates, where the payer believes they've already received or adjudicated a claim of the same type. Those aren't really about the care delivered or whether the patient was financially cleared. They're about how the payer believes the thing should be billed, that certain rules weren't followed. There's a long tail beyond that, but those are the big three we see in ambulatory.

Host: I've heard you talk about denials that may not be completely legitimate, what I'd call delay tactics. What do some payers do that mostly just adds friction and bets the provider gives up on resubmitting?

Ayo: So many examples. You submit a claim, you don't hear back in any electronic channel, you log into the payer portal, and the claim status says, "We sent you a document." You're thinking, "I'm right here, why don't I see it?" What they actually did is send a physical letter. Now you have to go into your lockbox, assuming you have a digital one, and search for a scanned PDF for this patient and this specific date of service to figure out what was done. There aren't that many fixes you can do to a claim, but you have to know the right one, because doing the wrong one means you don't get paid again and have to repeat the work. Another example: you submit a prior auth, the payer approves the total knee replacement, and you have a document that says so. Then you submit the claim and it gets rejected saying you need a prior auth. You're thinking, "I asked for one and got it." What's happening is there's a field on the CMS 1500 form for the prior auth number, and you'd think the payer has that number in their system attached to this date of service and procedure, but they're just not matching it up. A charitable way to describe it is they have two systems that don't talk to each other. Nevertheless, these are very sophisticated organizations, so having them deny paying you for delivering care over a procedural reason is pretty brutal.

Host: You haven't talked about records requests, the RFI. It looks like a denial that never says no. How does that tactic work, and why is it growing?

Ayo: You submit a claim and get a response that says, "We need something from you." That something depends on the care delivered, the payer policy, and so on. Most of the time, when you submit the document they asked for, you get paid, probably 70 to 80% of the time. But mechanically, you submit on day one, you don't hear anything until around day 21, so now you've gone three weeks without getting reimbursed. Then you look and it says, "Submit medical records." So you go into your EMR, download the PDF, write a cover letter, go into the payer portal, upload it, and now the claim is in an appeals queue and someone has to watch it to make sure you actually get paid. For an encounter where you did everything right, saw the patient and delivered care to the standard, you still go through this intense rigmarole just to get paid. Is it happening, charitably, to reduce fraud? Probably. Uncharitably, it means better economics for the payer.

Host: So it's a way to improve their cash flow?

Ayo: Better cash flow, better margins, you name it.

The operating reality: labor, tools, and knowledge

Host: Let's move to the operating side. If you're a director of RCM or a billing manager dealing with a growing backlog, how much of this is a labor problem, how much a tools problem, and how much a knowledge problem, given turnover and rising complexity?

Ayo: It depends on your organization. If you experience a lot of turnover, it shows up more as labor. If you've gone through a lot of acquisitions, it's partly a tools problem, because you have all these systems that are difficult to make talk to each other and use different formats for the same data. Whether it's a knowledge problem depends. Assuming you have good tools and enough labor, sometimes it's emergent. The big example in the news over the last year is down-coding. You submit a claim with an evaluation and management code that implies a certain amount of clinical complexity, say a level 5, a 99205 or 99215. The payer says, "We don't agree, we're going to code this as a 99203, deny the 99205, and pay you on the 99203."

Host: Sticking with the backlog, what's the impact on a team and on cash? And why can't you just hire more people to fix it?

Ayo: You can, it's just that hiring is not free, not cheap, and not fast. Your backlog can grow much more quickly and more impactfully than you can hire against it. And a backlog really represents money you're owed for services you provided and costs you already incurred but haven't collected on. You spent to earn that revenue, the provider time, the materials, the syringes, but you're not getting the offsetting revenue attached to it. So throwing more bodies at it doesn't scale the way you need. For a long time it was the only option. It's just hard.

How Substrate solves it: more, faster, cheaper

Host: We haven't talked much about Substrate and how you solve this. From a denials perspective, what can Substrate now do that wasn't possible before?

Ayo: We have this more, better, faster, cheaper framework. It can do more: it can check every channel, every payer portal, your clinical document base, read your SOPs, and do that on every single claim, tirelessly. It can condense and synthesize all that information into a format your team can easily validate, introspect on, and reason about. It can do that very quickly. Machines can run multiple threads in parallel, more than humans can, and it's often a cheaper way to do it. Think of the distance between having a person wait 45 minutes on the phone for a Cigna rep versus a machine doing it. It's much cheaper, and very often the machine doesn't need to wait on the phone at all, it can go through the clearinghouse or directly in the payer portal. All of this was possible a decade ago, but not at all cost-effective. Today it's extremely cost-effective.

Host: Let's touch on doing more. Can you dimensionalize how much more, with metrics or examples from a client that used Substrate?

Ayo: We have run through 4,000 to 5,000 claim statuses in a couple of hours in a single day. To do that with a team, you might need dozens and dozens of people just on claim status. And there are many other things a client has to do in RCM, so you might have dozens of people focused on this one task, and even after that there's a bunch of denials work they'd still have to do. Now we have a machine that I'm pretty sure can scale up to tens of thousands or even hundreds of thousands of claims in a day. Today we have clients doing thousands per day.

Host: How does that translate into a lower cost per claim? Can you dimensionalize the improved cost structure?

Ayo: There are varying estimates of what a claim status call costs. We have a client that was paying something like 75 cents for a claim status, averaged over the people and outsourcing they hired and how long those people waited on the phone. We helped them cut that to under 15 cents, across everything you need to check to do that for a single claim.

Host: What was it before?

Ayo: North of 75 cents.

Host: So you're talking about a 70 to 80% cost reduction per claim.

Ayo: Correct. And that's just on a single task. Imagine the compound effect: a claim can go through many tasks, so there's really significant savings you can create.

Host: One last thing on benefits. You use the word "easy," and the website says things like "no integration project" and "just give us a login." What does that mean, and how are you able to do it so quickly compared to the old way?

Ayo: Two things. One part of our value prop: if you're a revenue cycle leader, for a long time it was really hard to get good technical bandwidth to work on your problems. You knew there was a smarter way, but the only reliable tool that gave predictable results was humans, "we're going to outsource this to a BPO." When you think about ROI with any vendor, return has to be high and the investment has to be below the return. The thing we do, aided by AI agents, is take on the implementation and integration burden. We say, "Just give us a login and we'll go get the data we need," or if you have a data feed we'll plug into that, or an API, we have that too. Part two: we use agents to do a bunch of this work, so you don't have to do a huge project cleaning your data before you give it to us. Give us the data your real employees really use, and the logins your real employees really use, and we'll start there and interact with those. If you reduce the investment a practice has to make to start seeing return, you really speed things up. The practice doesn't have to trade off, "our IT or product team has to move off this project onto that one to make progress." That team can keep doing what they're doing, and the RCM leaders can get the results they want.

Host: So other than security and technical clearance, you basically don't need anyone from IT involved?

Ayo: That is correct.

The boundary: what Substrate does and does not do

Host: In the first episode you talked about transparency, so let's be straight about what Substrate can and cannot do. Where do you still need humans, and where does Substrate hand off to the client?

Ayo: For RCM, there are many things we don't do. We don't do prior auth, and we're not going to for a very long time. We do eligibility, but a lot of financial clearance is beyond just checking a patient's insurance, so that's one constraint. In the denials world, we focus very heavily on claim status, denials caused by front-end errors, and denials caused by policy errors. Those are three big ones. There are others we plan to do, like bundling and duplicate detection, we just don't do those yet.

Host: Last question. One thing I've heard is that once Substrate starts working with a client, the system gets smarter with every claim it works. How does that work, and why does it change the dynamics for the client over time?

Ayo: Healthcare is an incredibly regional concept. In every region there are a couple of big hospital groups that dominate, and health plans are regulated at the state level, so a lot of the mechanics of how health plans work are regional too. Generally, when you hire a biller, you're often hiring someone who knows your geo. What's different for us is that if there are specifics about your practice you can teach us, we'll take that, why not learn. But beyond that, we already have millions and millions of claims running through the system, so our system is learning specifics, like these third-party administrators under Cigna have this specific requirement for how the member ID must be presented to get a successful response. That's just one example of many. So when we sign on and implement a new client, they might say, "Here's some information about how our system works," and we very much want that, but they're not starting from a blank slate. We've now seen many specialties and millions of claims, so we usually have prior art that acts as a foundation, and then we add that practice's customization on top.

Close

Host: That's a great place to wrap it up. Thank you so much, Ayo, for going through the entire denial process, the who, what, where, when, why, and a lot of the how, and for spending time explaining how Substrate is using technology to solve this in a way that's never been done before. Thank you for the time.

Ayo: Awesome, thank you so much.

End of Episode 2.

Edited transcript. Lightly cleaned for readability, preserving the speakers' meaning and voice.

Introduction

Host: I'm excited to welcome Substrate co-founder Ayo Omojola to the premiere episode of the Unreasonably Deep podcast. Originally from Nigeria, Ayo attended the Wharton School in Philadelphia for both his undergraduate degree and his MBA. Before founding Substrate, Ayo's career was spent in finance and healthcare, at both large companies and startups. In 2024 he started Substrate, an AI-first autonomous revenue cycle company for the healthcare industry. Current customers include NextGen, Compass Health, and Fitting Health. Welcome to the podcast, Ayo.

Ayo: Thank you for having me.

Before Substrate: Carbon Health and the collections problem

Host: Take us back to before Substrate. What were you doing that led you to start the company, and what skills did you develop in healthcare and finance before founding it?

Ayo: Before Substrate, I ran product at a company called Carbon Health. Carbon is a large, multi-state, full-stack primary care and urgent care company. We built a lot and grew very fast over the course of the pandemic. When we started and as we grew, we just didn't have a mature collections organization. Our metrics weren't amazing, and our revenue recognition wasn't amazing.

Host: What is collections? Just so folks understand, what do you mean by that?

Ayo: In the US, if you go see a doctor and you have insurance, whether it's United or Cigna or Aetna, there's a process that has to happen between the end of your visit and that doctor getting paid by your insurance company. The claim has to be submitted, denials have to be worked, and so on. That is called, broadly speaking, the revenue cycle, and it's a process we weren't mature at during that time.

Host: So what was the problem you were seeing?

Ayo: I think it was three broad things. First, we didn't measure well, so we didn't have good visibility into what was actually happening. Second, we didn't collect well, meaning the literal tasks and actions you need to do to ensure a payment happens, either between the payer and you or the patient and you. And third, transparently, we were a little naive about how the world worked. We had a value we called "assume karma exists," where we said, "We're going to see these patients no matter what, and we'll figure out the business on the back end." It turns out that most entities in healthcare responsible for reimbursement are very happy for the provider that delivers the care to not get paid. And so we didn't get paid.

Host: We're going to dive a lot more into that later. But you actually knew a lot about payments already, because you were at Square before. I'm surprised to hear you say you didn't focus on getting paid when you'd worked at a payments company. Help me bridge that gap.

Ayo: I spent a lot of time in payments. It's a market I know well and I'm very familiar with, and healthcare is just a different thing. In most payments environments, both consumer and B2B, by the time you deliver a service, both parties basically agree on what's been delivered and what's going to get paid. In healthcare, a lot changes between when you show up at a doctor's office and when the claim is submitted. There are things that can happen in the middle of your visit that dramatically change the services being delivered. That's part one. Part two is that the way payments are organized is so specific to healthcare: for the exact same problem, depending on the patient's parameters, how old they are, what other conditions they have, a visit might become more complex, and that can change how much a payer will pay for that encounter.

So, honestly, I didn't focus on it at the start. I literally remember the room I was in when I learned what healthcare revenue cycle was, at 555 California. And I was actually afraid of it.

Why revenue cycle is so intimidating

Host: So why is it so intimidating? What was the light bulb that went on, where you realized this is way more complex and non-trivial and requires a lot more effort?

Ayo: At the time, even the terminology is impenetrable. It's RCM and net revenue and net collections and days sales outstanding and cash collection waterfall. In most other businesses, you just don't deal with this. I've run several businesses and several P&Ls over my career, and in the rest of them you never hear about any of it. Maybe you care about whether you're net 30 or net 60, but for the most part you're not worried you won't get paid. It's just a matter of when.

In this world, if you take a sick day and happen to miss a letter or a denial that came in, or you get the denial wrong, you might just never see that money, and you won't know for months. At some point you're nine months in and you realize, "We've touched this claim 12 times and we're just never going to collect it. It's not worth it anymore."

Host: Before we tie up what you did at Carbon Health, when did you realize how broken it was, and why it was so broken? This is so different from what you were used to: you buy something, you pay for it, and you're done. But here, there's every reason under the sun that you might not get paid.

Ayo: I think in 2023, a bunch of us at the company really started to focus on it. There had been problems for a long time, but the management team started to look hard at it. Every organization has some system of record that says, "Here's what you think you're going to get paid for the work you did." We had that. And then you have the bank account. Just looking at the delta between those two, we realized it wasn't stacking up. That was the signal.

Founding Substrate: from margin engineering to agents

Host: Do you remember the specific moment you decided you had to go do something about this? You went through the Y Combinator process. When did you decide to start Substrate, because you felt this was a big enough problem that you could help solve it?

Ayo: I spent my last year and a half at Carbon doing what I call margin engineering, focused on using software and code to optimize the business. A big part of that was revenue cycle. The overall effort across software and operations took us, first on patient collections, from 55 percent of patient estimates collected to 99.8 percent over the course of nine months. And then we went from 77 percent overall collections, including insurance, to 97.8 percent over the course of a year.

At the end of that, I realized the only leverage left was agents, because we'd exhausted the set of tools available in RCM. So I decided to go build that. I'd made the assumption that everybody in the world needed what Carbon needed, because Carbon had just caught up with the rest of the world.

The pivot: from browser automation to selling results

Host: Correct me if I'm wrong, but you thought you were building browser automation at first. What made you believe that, and what broke that thesis?

Ayo: My observation, which is still true today, is that in every fee-for-service healthcare provider in the United States, somebody is logging into United or Availity, copy-pasting patient data. Many workflows follow that pattern: you have your system of record open, your EMR or PM system, you have United open, maybe a spreadsheet open too, and you're moving information across tabs and reasoning about it. So our initial hypothesis was that somebody needs to build a thing that collapses all those workflows into one, so a human isn't spending time switching between tabs and copying data. They're just making the decision they need to make. That's what we love to build.

Over the course of our first year, it became obvious that if you run a practice, or you're the head of finance or head of RCM at a practice, you actually don't care about any of that. You just want results. So what we pivoted to sell now is results. One of the building blocks is browser agent automation, some of which we do in-house and some we do with partners. And we have many other building blocks. The realization we had was that, given the option of an IKEA box or having the furniture delivered into your living room, people would rather just have the furniture, already assembled, doing what they want. You can just sit on it.

Building trust while touching real money

Host: Now you're touching real money, which requires a lot of trust from clients. How do you build that trust? Why would they go with a third party instead of doing it internally, where they control everything?

Ayo: There are really two questions there. On trust, it's true at any startup that the founder is selling, and that's me. The company roughly reflects my ethos, which is transparency, speed, and actual expertise.

On transparency: when we talk to clients, if they have problems that aren't shaped like things we can solve, we just tell them. And if their problem is something where we know who's good at it, we refer them to that person. A classic example is prior authorization. A lot of clients ask if we can build prior auth tooling. It's not a domain I know well, and there are companies that do it well, that have raised a lot of money and built sophisticated things. So we just point clients to them. That transparency matters, because healthcare leaders have grown up being burned by vendors making promises they can't keep. We really focus on keeping the promises we make, and only making promises we know we can keep.

On speed: there's a general slowness people experience when they interact with healthcare, from the vendor side and sometimes even internally. We try to be super fast. For example, if a client reaches out, we want them to hear from us in five minutes. Ideally we can give them an answer in five minutes, by email, text, Teams, Slack, whatever. If not, we at least make sure they know they're heard, and we kick off a process internally to resolve their problem. That comes from my time at Carbon. A lot of problems in RCM have a crisis feel to them. The last thing we want to be is another bottleneck they have to go through to get their problem solved. We want clients to feel that, for the things we do, we're the fastest response they're going to get.

On expertise: this podcast is called Unreasonably Deep, and that comes from one of my beliefs, which is that you really have to have as close to a bare-metal understanding of what you're doing as possible. I work claims all the time. I post payments all the time. I've been doing it for three or four years, since I was at Carbon. One of the ways I learned at Carbon was by shadowing the billing team for four months and getting trained as a biller. I'd work claims, create appeals, submit them, rebuild claims. Systems are different and not everything translates, but it translates enough that when we talk to clients, they understand that we speak their language.

Why RCM is such a mess

Host: So why is RCM such a mess? I understand that insurance companies don't want to pay practices. I get that as a starting point, but it can't just be that. It doesn't create a lot of work for them to deny something and say, "We need more information." There's a whole bunch of other stuff that keeps it messy on the practice side too. Why is it such a mess?

Ayo: Oh, man. Do you have four hours?

Host: We can save some for future episodes, but give us the elevator pitch on why it happens.

Ayo: One very obvious thing is that there's insufficient standardization every time data is exchanged. If anyone listening walks into a Target and puts down a credit card, the person at the front of the store doesn't need to know anything about the card. They tap a machine and either it goes through or it doesn't, which has downstream impacts on whether I get my coffee. In healthcare, not everybody drinks coffee and not everybody goes to Starbucks, but 100 percent of humans consume healthcare as a product. It's a 100 percent TAM product.

In the US, if you walk into a doctor's office and put your insurance card down, about 40 percent of the time the authorization path is incorrect. Either the eligibility verification goes to the wrong payer, or it has the wrong patient name, John versus Jonathan, or the wrong date of birth. There are a thousand things that can go wrong. And that's just one of a half-dozen exchange points where data gets transferred from one system to another. That's probably the biggest operational reason.

The biggest macro reason is different, and this isn't a comment that insurance companies are bad people. If you talk to people who work at the big insurance companies, they got into healthcare because they want to help people. They're very mission-aligned. It's more that the system as designed has friction, and the party with the most power to solve that friction isn't incentivized to. These are all friction. We could just have a magstripe on an insurance card that you swipe and it goes exactly to the right place, but we don't. You could have standard clearinghouse transactions that every insurance company adopts, but they don't. They'd have to spend money to make the friction go away, and after making it go away, their margins would be lower.

Host: I know Mark Cuban has been pounding the drum on this for many years.

Ayo: I think he's right. The system performs as designed.

Host: The system performs as designed. That's a good way to say it.

Why AI is a game changer

Host: So why is AI a game changer here?

Ayo: Tying it back to those points of data exchange, the current generation of large language models, reasoning models, and vision models let you do a thing that previously fell to humans and was mostly extremely tedious work. Today, in most healthcare companies in the United States, the literal system that converts your insurance card into the practice's EMR or PM is a human reading a card and typing it in.

Host: What's an EMR, for folks who don't know? And what's a PM?

Ayo: EMR is electronic medical record. Think of it as the clinical system of record. If you're at a doctor's office and the doctor is typing, they're typing into the EMR. PM is the practice management system, the financial system of record for healthcare, where all the financial data about a claim is recorded and exchanged with the outside world.

Host: So what can AI do with regard to RCM?

Ayo: In the old world, the entity responsible for making sure data moved between systems was a human, copy-pasting, reading to make sure it's John and not Jonathan, selecting the right payer, and hitting send. In the new world, if you think about what large language models are really good at and have been good at the longest, it's the transition of data from unstructured to structured and back. It turns out that a lot of the problems in RCM are about exactly that transition at large scale. An insurance card being entered into the system, all the way up to an entire clinical summary being compared to a claim, are versions of the same thing. The CMS 1500 claim form is a structured representation of the visit notes. Now AI can help do that transition.

Host: So the implication is a lot fewer mistakes and much better transcription between unstructured and structured data.

Ayo: Yes. You can have audit trails for almost everything. You can have much more consistency. It can happen faster. In many cases, this is really tedious work that people don't actually do. Roughly speaking, RCM has a lot of very tedious tasks that previously could only be done by humans, and today they can be done by machines in large part. It's not true of everything, but the 80 of the 80/20, machines can actually do for most RCM tasks.

Where the biggest benefits are

Host: Where do you think the biggest benefits are? Is it speed? Accuracy? Volume, because you can do a lot more than before? Where are the real benefits being seen, and how does that translate at the end of the day?

Ayo: It's all of the above. It's speed, because you're no longer gated by the eight hours a day a person is in the office. These machines can run around the clock. Second, they can process many things in parallel, which improves both speed and volume. Third, the volume point is really important, because many healthcare organizations have to make a trade-off: if a claim is below a certain dollar amount, they can't touch it. They have other denials to focus on. Hospitals are a famous example. For a lot of hospitals, if they have outstanding accounts receivable under about $1,000, they just can't touch it. Their people have to focus on the denial for the three-week hospital stay, which is much more important. AI now makes it possible for hospitals not to have to make that trade-off, and that's one of the valuable things.

The 5 to 8 percent back-office tax

Host: Let's transition to the operating cost of doing all this RCM work. You've called the back office a 5 to 8 percent tax on every patient. What is that? Where does the money go, and why has nobody fixed it?

Ayo: RCM in the big picture has a very broad remit, and it starts long before the visit. The very first thing is that the provider has to get contracted with the payer. That payer contract governs the scope of service they can do, what they'll actually get paid for, and how much for each of those things. And it extends all the way to the end. Even long after a payment has been issued, a check sent to the provider and cashed, payers very often come back after the fact and take money back, for many reasons we can get into later.

Effectively, zero organizations on Earth have built a way to make that entire pipeline electronic, and there are some parts you probably can't make electronic anyway. If you run a large retailer, your payments infrastructure, including people and technology, can be a few people, maybe a few hundred if you're doing billions of dollars of transactions. I'd guess Target, which probably does hundreds of billions in revenue a year, has maybe a couple hundred people on its payments team. I know several health systems and physician groups whose revenue might be in the hundreds of millions to low single-digit billions that have hundreds of people working on RCM. Historically, the way that friction has been handled is by throwing bodies at it. So that's the tax.

Host: It's a hidden tax in healthcare.

Ayo: It's not that hidden. It's just hidden to patients. Most people don't know it, but it's there.

How much of the tax can AI solve

Host: So we've talked about AI and the problem. How much of that 5 to 8 percent tax can AI solve? How big is the prize? And where is the biggest bang for the buck in savings from using autonomous AI in the revenue cycle?

Ayo: Heuristically, let's say the tax is 6 percent. I'd bet that four and a half to 5 percent can be solved by the existing stack of AI and software tools that exist today. That's already true. It's not evenly distributed, but it's true today.

Host: Just to be clear, which number are you referring to? The total cost of revenue cycle management as a budget, or as a percentage of revenue?

Ayo: I mean the total cost. Let's say, on average across the US, for every hundred dollars of net collections, about 6 flows in some way to a revenue cycle function. I'd argue that 5 of that can actually be solved by software today.

Host: Wow. So you're saying the significant majority can be solved, taking out most of that cost. What has changed that makes that possible? Is it what you were saying before, removing the human labor so you get speed and volume and cost comes out?

Ayo: It's all of the above. Your staff just have things they don't have to do anymore. There are buttons they don't need to click. That's one dimension. There's another dimension where, for a lot of organizations, you can actually drive net revenue higher as a consequence. They can collect more of what they're owed, which reduces the percentage. And one hidden part of the cost of how healthcare is paid for today is net working capital. The other side of accounts receivable is net working capital: the longer you have to wait to get paid for a service, the more working capital you need. As you bring that in, you reduce the working capital burden of the practice. The cost of running the practice actually shrinks as well, which is another pocket of savings.

Host: So in layman's terms, from a cash flow perspective, you're getting paid faster, and getting paid faster really helps your business. Is that right?

Ayo: Correct.

What AI can do autonomously versus what still needs humans

Host: So what can be done today autonomously using AI, versus what still needs humans driving the process?

Ayo: Let me start with what needs humans, because some parts of this I don't think will ever go away. For example, a rheumatology group in Kansas negotiating with United is always going to be human. There are so many dynamics in there that aren't related to anything a machine can do: how many providers do you have, how senior are they, how successful are they at the procedures they do, what's the readmission rate when one of your providers does a surgery. An interaction between a provider and an insurance company is an intensely clinical thing that impacts the economics of the insurance company, the economics of the provider group, and most importantly how care is delivered and who can receive it. That's always going to be a human thing.

The other human piece goes back to my theme that data jumps from system to system, and every time it jumps there's some fidelity loss. For care that is complex, care is inherently subjective and comes down to the judgment of the clinician. A really good example is a "peer to peer," where a clinician on the provider side and a clinician on the payer side have to discuss whether a specific problem is medically necessary, or exchange clinical data. That's always going to be human, and it's part of getting paid. There's no getting around that.

On the other side, whenever there's data that is legible to a machine, meaning the data can be viewed on a computer, I think machines can do that work now. Between computer use, APIs, browser agents, desktop agents, vision-language models, and OCR, most of what can be done on a machine is legible to machines now and can be done automatically. The bigger constraint is whether you've documented how decisions should be made well enough that you can trust the machine is doing what you want.

The Substrate graph and the data network effect

Host: We haven't touched much on Substrate itself yet. You have several clients, whom I mentioned in the introduction, and you've been deep at this for a couple of years. Can you explain, in plain terms, what "the graph" is and why it compounds with every claim? When you work with a client, you actually get smarter as you learn the specifics of how each client works. Talk about that graph.

Ayo: I'll use our claim status and denials product as an example. Its objective is to help practices very quickly get to the bottom of exactly where a claim is in its cycle, why it's denied, and exactly the right decisions to make to get paid on it. Most of the best billers in the industry today have built that up through tribal knowledge, seeing thousands and thousands of claims over the years and developing a sense of, "When United gives you this code, it kind of means this, versus when Cigna gives you this code, it means another thing." I've been doing billing for years now and have very strong opinions about it.

What we've been able to do is give new clients, when we onboard them, the benefit of all the millions of claims we've seen before they showed up. And when we help them process their claims, the decisions and learnings our system gets out of that process also enrich and make the overall system smarter. There truly is a data network effect: the more claims we see, the better we get at figuring out the right action, and at understanding the nuances of how payers behave in a specific state and specialty versus another state and specialty.

Why outsourcers and RPA vendors can't just do this

Host: Help me understand something. There have been big outsourcers doing this for years using lower-cost labor, and there are robotic process automation, RPA, vendors who've been doing this for decades. Why can't they just do this?

Ayo: There are a bunch of reasons, but at a high level they're solving a different problem. The outsourced or offshore folks are solving this mostly as a service, and that service is designed to deliver exactly what the client asks for. This is a subtle distinction. What we're iterating toward is delivering exactly what a client wants, which sometimes is not exactly what they ask for.

The example I'll use: very often we're in the middle of a deployment with a client. We have their SOPs, their standard operating procedures. We execute on the SOPs, and when they look at the results, the results aren't exactly what they want. There's all this tribal knowledge that isn't captured in the SOPs, which we have to tease out of them. So one part is being really focused on the actual outcome that matters for the business, rather than just what they say they want. Revealed preference versus stated preference.

For the RPA folks, they're mostly selling tools. That requires the practice to have a certain amount of resource commitment and basic infrastructure to integrate with those tools. What we say is that we try to enter your workflow the same way a biller would: give us a login and give us access, and we'll handle the stitching of the integration, the actual intelligence and business logic, encoding it and putting it in a format where you can make changes, see exactly what's happening, and have an audit trail. Then we give you reporting on the outcome. In large part, we're just focusing on different things. They could choose to focus on what we focus on, and we welcome them, but that's the biggest reason.

The outlook: two years out and the long-term North Star

Host: Last question, in two parts. Play it forward. In the near term, what does revenue cycle look like two years out if Substrate works?

Ayo: If what we do works, providers who work with us will get paid fairly for the care they provided. That's the North Star of the company, and it's why we started it. There's something deeply unfair about it. Most clinicians got into this industry to help people, and they're dying the death of a thousand cuts. They deliver the care they need to deliver, then look over and find they're not being compensated fairly. What I want to create is an AI that fights for the provider and helps the provider get paid. That's number one.

In the long arc, there's an industry problem that can't only be solved by technology; it's more of a policy thing. The dollars available to go into care delivery are kind of zero-sum. It grows every year, but providers and payers treat it as a zero-sum game. In the fullness of time, what I'd like the company to build is a network that actually frees up more dollars. Right now, a biller hits submit on a claim, and on the payer side somebody hits "deny." It's kind of crazy that both providers and payers are spending cycles on this. In an ideal world, we'd build something that lets providers know with absolute certainty that they're going to get paid when they submit a claim, and something that enables payers to free up bandwidth and dollars that can go back into care. That's the North Star.

Host: How soon is that coming, and how will payers react to it?

Ayo: I think a lot of payers already see the writing on the wall. There's more receptiveness than I expected to this "make more of the pie available" approach. In the short term, and this is what I was saying, some problems are policy problems. As the more sophisticated providers get better, it is going to impact payer operations. That's just true. I don't think there's any way around that.

Close

Host: Well, I want to thank you so much for taking the time, for giving us some of your background, how it led to starting Substrate, and for really going deep on revenue cycle management and how what Substrate is doing is hopefully going to change the industry and have some real benefits in making the entire process more efficient.

Ayo: Awesome. Thank you for having me.

End of Episode 1.