What Healthcare Investors See in Risk Adjustment Due Diligence That Buyers Often Miss

By Chetan Parikh, Founder and CEO, RAAPID

I recently watched our technology go through one of the most rigorous due diligence processes I've experienced. UPMC Enterprises spent months evaluating our platform across clinical, technical, and regulatory dimensions before deciding to invest.

What struck me wasn't the depth of their review. It was how different their questions were from what we typically hear in sales cycles with health plans.

Same technology. Same use case. But they were asking questions most buyers never think to ask. That gap is worth examining.

The Questions That Surprised Me

Early in the process, their team asked to see our deletion logic. Not our ADD rate. Not our accuracy metrics. They wanted to understand, technically, how our system decides a code should come off.

I've been in hundreds of health plan meetings. I can count on one hand how many times a buyer has asked that question.

They also asked how our system handles ambiguity. What happens when clinical documentation could support a diagnosis but doesn't definitively confirm it? Do we surface it anyway and let the coder decide? Do we suppress it? What's the threshold, and who set it?

These aren't questions about features. They're questions about judgment. About how the technology was designed to behave when no one is watching.

Health plans buying risk adjustment technology rarely go this deep. They evaluate outputs: accuracy, throughput, and integrations. They demo the interface. They check references. But they almost never interrogate the decision-making architecture underneath.

Sophisticated investors do. And what they find shapes their confidence in whether the technology will hold up under regulatory scrutiny three years from now.

Why Investor Diligence Differs From Buyer Diligence

Health plans evaluate vendors against current requirements. Can this system do what we need today? Does it integrate with our workflow? What's the ROI?

Investors evaluate against future risk. Will this technology create liability as regulations tighten? Is the architecture defensible if enforcement accelerates? What happens when the market shifts?

Those are different questions with different implications.

During our process, their team walked through audit scenarios. They asked what our system leaves behind in the documentation when a code is submitted. They wanted to see the evidence trail. Not described in a deck. Demonstrated in the product.

They asked about our training data. How do we prevent the system from learning patterns that optimize for volume instead of accuracy? What governance exists around model updates?

Health plans should be asking these questions. Most don't have the technical depth to know they should, or the time to go this deep during a procurement cycle.

That's the gap. And it's a dangerous one.

What This Revealed About Market Direction

This process clarified something I'd sensed but couldn't articulate precisely: the market is splitting into two technology categories.

There's technology built to find codes. These platforms optimize for capture. They measure success by ADD volume and RAF impact. Five years ago, they were the right tools.

Then there's technology built to defend codes. These platforms optimize for explainability. They measure success by audit survivability and evidence quality. That's where the market is heading.

The regulatory environment has turned capture-first architecture into a liability. But most health plans haven't updated their evaluation criteria. They're still buying based on metrics that made sense in 2020.

Sophisticated investors have already moved on. Their diligence now filters for defensibility, explainability, and architectural integrity. They're placing bets on where the market will be, not where it is.

What Health Plans Should Take From This

I'm not suggesting every health plan runs investor-level diligence. That's not realistic. But there are questions worth borrowing, and one test worth running.

Ask how the system handles deletions. If the vendor stumbles or pivots to talking about ADDs, that tells you something about their architecture. Ask what happens with ambiguous documentation. The answer reveals whether the system was built for accuracy or volume. Ask to see the evidence trail. Not a screenshot in a deck. The actual output. If it doesn't exist until someone asks for it, that's a problem.

And here's the real filter: every vendor pitch sounds the same. Everyone claims AI. Everyone claims 98% accuracy. So give them 50 charts and your coding guidelines. Let them fine-tune for two weeks. Then send 2,000 charts, 150 of which your team has already coded, buried in the batch. Ask for results in 8 hours. You pull out your 150 charts, compare, and now you have real accuracy under real conditions. That test alone will tell you more than any RFP.

The vendors who welcome that challenge have built for the regulatory environment taking shape. The ones who can't are selling tools designed for a market that no longer exists.