Subscribe | Advertise | PRO Member Hub

TOGETHER WITH CANDID HEALTH

Perspectives from the people building the future of health AI…

We sat down with Nick Perry, CEO and Co-Founder of Candid Health, to unpack how the company is rebuilding the infrastructure behind RCM.

Nick came to the problem from Palantir, where he worked across healthcare projects in pharma and insurance and got exposure to the payer side of claims adjudication. That experience shaped an early thesis behind Candid: automation is only the visible layer. Underneath it sit the harder problems of data integration, modeling, orchestration, and turning messy operational knowledge into something software can reliably act on.

Candid started building around that thesis in 2019. Rather than add automation around an existing billing system, the company rebuilt the practice management system itself. Today, the core platform can serve as the financial system of record across patient registration, eligibility, claims, remittance, denials, accounts receivable, and reporting. Candid is also building an agentic RCM platform that can sit on top of Candid or legacy billing systems to automate work that still lands in billing queues.

The company now serves 200+ healthcare organizations across dozens of specialties and says it will process roughly $12B in claim volume this year. Candid recently raised a $120M Series D led by Sixth Street Growth after reporting 190% year-over-year annual contracted run-rate revenue growth and 180% net dollar retention in 2025.

Nick shared how Candid thinks about autonomous RCM, why so much of the hard work sits in the data and orchestration underneath the agents, where humans still need to stay involved, how the company is increasingly partnering with EHRs, and why the same infrastructure could eventually support a different model for healthcare payments.

Let’s start from the top. What led you to start Candid Health, and why was RCM the problem you wanted to spend years solving?
I was pre-med in college, then took a computer science class and realized I liked that a lot better. I decided not to become a doctor, but I kept my interest in healthcare. At Palantir, I worked on some of the early pharmaceutical and insurance projects, which gave me exposure to the payer side and how claims get adjudicated.

When I was leaving Palantir, I wanted to work on a problem that was both enormous and worth solving. RCM checked both boxes. Depending on the estimate, it is roughly a $280B industry, and it touches basically everybody. Healthcare organizations spend an incredible amount of organizational brainpower simply trying to get paid. That is time and energy they are not spending on care.

It affects patients too. Billing is complicated enough that tiny mistakes can create meaningful financial consequences. You can put an address in slightly wrong, get treated as out of network, and suddenly a patient has a very different bill. It is not because someone is trying to do something wrong. The system is just extraordinarily easy to get wrong.

Longer term, I also think the payment infrastructure is part of what makes healthcare difficult to change. It is hard to make preventive or long-term investments when the underlying system for paying for care is this fragmented. My view is that some company eventually needs enough gravity to pull the system forward. If policy alone were going to fix it, I think we probably would have done that already.

For readers hearing about Candid for the first time, what does the company do today?
We built a modern practice management system from the ground up, purpose-built for the AI and automation world.

A provider organization really has two major systems of record. The EHR holds the clinical information: notes, labs, orders, and the medical side of the organization. Then you have the billing or practice management system, which holds claims, registration, eligibility, remits, and the financial side. Candid is that second system.

Generally speaking, the entire revenue cycle can run through Candid. That includes patient registration and check-in, claim creation and submission, posting remits, handling rejections and denials, accounts receivable, reporting, and month-end close.

In addition to the platform, we’re building out our agentic RCM platform, which sits on top of Candid and other legacy billing systems to drive further RCM automation. The easiest way to think about it is to imagine the agents going into work queues and working alongside the billing team to resolve claims automatically.

You started building Candid well before the current generative AI wave. What did you believe about RCM early on, and what have agents now made possible?
One of the big lessons I took from Palantir is that automation is the tip of a very deep iceberg. Underneath it is data engineering: integrations, data modeling, pipelines, and getting all the context into a form where software can reliably act on it.

From day one, our North Star was to automate RCM, but we were never dogmatic about how. Before LLMs, that meant deterministic rules, traditional machine learning, and a lot of infrastructure. When LLMs and agents became good enough, they fit naturally into the orchestration system we had already built. They expanded the set of things we could automate rather than forcing us to rebuild the architecture around them.

Eligibility is a good example. Real-time eligibility responses contain a lot of unstructured information, and some of the useful information may only exist inside payer portals. Agents are really good at navigating that. They can interpret the response, go into the portal when necessary, and pull additional information.

We also use agents in claim work queues and to help curate the knowledge base around how claims should be submitted. A lot of payer rules are not published cleanly anywhere. Some are buried in PDFs, but many have to be learned through actual submissions, payer portals, phone calls, and adjudication data. Agents have been a meaningful unlock for helping us manage that information at scale.

When you say “autonomous RCM,” what does that actually mean today? How do you measure it?
I am a big believer that if you cannot measure something, you cannot fix it. RCM has tons of metrics: clean claim rate, first-pass resolution, net collection rate, cost to collect. But none of them really measures automation.

So we created one called touchless claim rate.

A touchless claim is submitted correctly to the payer, adjudicated correctly the first time, posted back into Candid, checked against the fee schedule, and completely finished without a person touching it anywhere along the way.

That is how we think about autonomy. For our top-performing customers, that number is around 97% or 98%. These are not tiny practices either. Some are very large organizations doing hundreds of millions or low billions in revenue. Not every customer is at that level because specialties and workflows differ, but in general, most of our customers have the majority of their claims being fully managed without manual intervention.

You called RCM a “death by a thousand paper cuts” problem. What does the technology stack need to do differently because of that?
The hard part about RCM is that pretty good is not good enough. It is closer to a math problem than an essay. An essay that is 99% good can still be a great essay. A claim is either correct or it is not.

That is why orchestration matters so much. I think a lot of people entering RCM are a hammer looking for nails, and their hammer is an LLM. They want everything to be an agent problem. Our view is that not everything should be solved with an agent.

Take denials. You can build an agent that appeals denials, and that may be better than having a person do it manually. But if you own the full billing system, the better outcome is usually to figure out why the denial happened and fix the submission upstream so it does not happen again. Sometimes an agent is the right tool. Sometimes a deterministic rule is cheaper, faster, and more reliable.

A single claim might touch deterministic rules, machine learning models, and agents at different points. We can even use voice models for payer calls when that is needed for the last mile. The hard part is deciding which tool handles which step.

We are fairly model-agnostic too. Right now we are using more Gemini models under the hood, but we are constantly testing the latest Anthropic and OpenAI models as well. We have not leaned as heavily into open source because we can already get a lot of cost efficiency simply by not using a model when one is unnecessary. Cost-effective automation matters more than maximizing how many agents you use.

RCM has become one of the hottest categories in healthcare AI. Where do you think Candid’s durable moat gets built?
A big part of it is the data for how to submit claims correctly. We call them rules, although “rules” probably undersells it because it is really the context the automation and agents need.

For any claim state, you need to know what should happen next. If I am submitting a claim to this payer, for this provider, in this state, what exactly needs to happen for it to get paid correctly the first time? If it gets denied, what happened and what should we do next?

A lot of that information is not published. You build it through integrations, claim adjudication data, payer policies, portals, user behavior, and years of seeing what works. Then you need a way to model that context, version it, test it, and safely add a new rule when thousands are already in production.

My guess is that a lot of this complexity is structural. Different payers cover different things, employers have different benefit designs, and the rules keep changing. So there are really two important pieces: the orchestration layer that decides which form of automation should act, and the data asset that tells it what should happen.

I think that broader data question is going to matter more across AI too. LLMs are trained on data, but in a lot of industries the most valuable knowledge is not publicly available. It has to be built over time. One of the questions I keep coming back to is: what data asset are you building, and can someone else build it?

What does implementation look like, and what kind of impact do customers see once Candid goes live?
Our go-lives are generally around three months on the shorter end and six months on the longer end before we begin submitting claims. For RCM, that is fairly fast. Large incumbent integrations can easily take a year or more.

We built the platform API-first because enterprise providers have data across lots of systems. The main integration is usually the EHR, but we may also need fee schedules, provider credentialing data, and other information from elsewhere in the stack.

Once claims start flowing, the feedback loop begins immediately. We see what gets denied, what adjudicates differently than expected, what payer rules changed, and then update the automation upstream. We have had customers come onto Candid with effectively a 0% touchless claim rate and move to around 75% shortly after going live, then improve from there.

Talkiatry is one public example. We reduced their manual work by 40%, and they didn’t have to grow headcount even as the organization continued to grow quickly. Nourish is another. The last number we published was a 97% touchless claim rate, so the vast majority of their claims are happening automatically.

As more of the revenue cycle becomes autonomous, where do humans still need to stay in the loop?
A lot of what we are doing under the hood is making the rules machine-readable so the automation knows what it should do.

Until those rules are perfectly encoded and agents stop making mistakes, people still need to be involved in the review step. You could have an agent look at payer policies, adjudication data, and what users are doing manually based on audit log data and suggest that we create a new rule. That is incredibly useful. But I still want a person reviewing why that change should happen.

The consequences are real. An agent might decide adding a modifier will get a claim paid, but adding it incorrectly can create a compliance problem. A single incorrectly built rule could mess up hundreds of thousands of claims.

The out-of-the-box agents are not there yet. They require a lot of context, tuning, and review. Right now, humans are ultimately the curators of what gets promoted into the automation layer, based on suggestions generated by agents scouring data in real-time.

How does Candid make money, and how does automation change the economics of RCM?
We broadly sell three things.

First is the modern RCM platform itself, where we charge a flat rate per claim submission. Second is our RCM services business, where pricing is a percentage of collections.

The services business is useful beyond the revenue model because our own teams are working directly in the workflows we are trying to automate. It gives us a way to test agents in real operating environments, see where they work and where they break, and identify repetitive work that should ultimately become product.

In general, those offerings can be around 30% to 40% cheaper than incumbent competitors because we are so automated under the hood that we can operate at a different cost structure.

Then we have the agent platform. We have unbundled the automation, orchestration, and configuration layer so it can sit on top of other billing systems. That tends to use more outcome-based pricing depending on the workflow.

You started with digital health companies and now work with larger and more traditional provider organizations. How has the product and go-to-market evolved?
We started in digital health because it simplified the product landscape. Many of those companies did not have traditional front desks or all the workflows you would see inside a large outpatient organization, so it let us focus very intensely on the core problem of billing insurance correctly.

That experience with digital health gave us the knowledge and capabilities we needed to become a feature-complete billing platform for traditional providers. That meant owning more workflows in a first-class way. Patient registration is a good example. If you do not capture the right information at check-in, that eventually becomes a billing problem downstream.

One thing we learned is that scale and complexity expose the limitations of legacy billing systems pretty quickly. Because we built Candid from the ground up, we can support a broad range of specialties and reimbursement models without hard-coding the platform around one narrow workflow. That flexibility becomes more important as organizations add services, markets, and payment models over time. You cannot take software built decades ago, sprinkle LLMs on top, and expect it to become modern. The APIs often are not there. The data layer is not there. The orchestration layer is not there.

We also originally assumed EHR companies would see us as competitors because many of them participate in billing revenue. That has not universally been true. Some simply do not want to build and maintain RCM because it’s complicated to get right and not their core focus. We now partner with some EHR companies that white-label Candid as their billing experience. In those cases, their customers may not even know Candid is running underneath it.

A lot of our expansion has also come from the underlying growth of our customers. We work with some of the fastest-growing provider organizations in the country, and as they grow, Candid grows with them. We try to be very customer-led and stay focused on the specific outcomes those organizations are trying to achieve. I would like to think part of why they can grow so quickly is that they do not have to build an equally large billing operation alongside the care business.

Five years from now, what does Candid look like if you execute the way you hope?
At a high level, I think the company will look more like Stripe than Microsoft or Salesforce.

We are going to stay very focused on RCM and payments because there is an enormous amount left to build. Stripe went incredibly deep on payments infrastructure for the internet. I think we can continue going very deep on the financial infrastructure of healthcare.

The data asset we have built around how claims should be submitted correctly also unlocks other things. One that I am especially excited about is real-time payments.

We are very good at getting claims adjudicated correctly the first time. That means we know when claims historically get paid, when they suddenly stop getting paid correctly, and how to respond quickly when something changes such that you can’t pay out the claim in real-time. One way of thinking about it is that we’re effectively pre-adjudicating the claim.

That could let us pay providers much faster while still managing the risk that something changes downstream. Cash flow is extremely important for providers, and the patient experience could improve too. Waiting six months to get a statement is insane.

Whether we ultimately enable that ourselves or with partners, I think there is a much better financial infrastructure for healthcare on the other side of this.

What stood out, what’s tricky, and why it matters…

Candid takes an infrastructure-heavy view of RCM. That traces back in part to Nick Perry and co-founder Doug Proctor’s time at Palantir, where one of the lessons was that automation sits on top of a much deeper data engineering problem. Candid spent years building that underlying layer before LLMs became a meaningful part of the product.

That approach fits the problem. Nick describes RCM as “death by a thousand paper cuts.” A claim can move through deterministic rules, machine learning models, agents, voice models, and human review, and Candid has to decide which tool should handle each step. Sometimes the right answer is an agent. Sometimes it is a deterministic rule that is cheaper and more reliable.

The underlying data turns out to be the more durable asset. Candid has spent years building the rules and context for how claims actually get paid, much of which is not available in a clean public dataset. Every adjudication, payer policy, portal workflow, and recurring exception adds to that knowledge base. Nick’s question, “what data asset are you building, and can someone else build it?” gets at an important part of the overall thesis.

The stronger proof is evident in the operating metrics. Candid says its top-performing customers reach roughly 97% to 98% touchless claim rates, meaning nearly the entire claim lifecycle can run without manual intervention. At Talkiatry, manual billing work fell 40% while the organization continued to grow without adding billing headcount; Nourish has reported a 97% touchless claim rate. The common thread is that billing operations do not have to scale linearly with patient and claim volume.

There is a clear line from Nick and Doug’s Palantir background to how Candid has been built. The agents matter, but the foundation matters more and is the result of years of work around data, rules, integrations, and orchestration. Better models expand what can be automated without changing that underlying requirement.

Candid also has an interesting commercial flywheel. Some of its earliest customers are among the fastest-growing digital health and provider companies, so Candid expands as those businesses add patients and claim volume. The agentic platform and EHR partnerships create additional ways to participate without requiring a full system replacement every time.

The Stripe comparison is where the longer-term story gets interesting. If Candid can understand how claims should adjudicate with enough confidence, the platform starts to know when revenue should arrive and when something has changed. That could eventually support much faster payments to providers. Getting there requires maintaining accuracy and control as Candid moves into more complex environments, but the infrastructure it is building today gives that ambition a great foundation.