Every few months someone asks me a version of the same question: our savings rate has flattened, is it time to look at a different bill review platform?
Almost never. In SmartAdvisor, savings performance is largely a function of how well the Capstone rules engine is configured. The platform is capable of more than most programs are getting out of it. Before anyone starts pricing a migration — a project that will consume a year and produce no savings while it runs — it’s worth auditing what the rules are actually doing.
Here’s the order I look in.
Start with what isn’t automating
The number to pull first is straight-through processing rate. Most SmartAdvisor programs land somewhere in the 50–70% range. If you’re at the bottom of that band, or below it, the gap is telling you that bills are stopping for human review that didn’t need to stop.
Every one of those stops is a two-part cost: the examiner time spent on a bill that a rule could have handled, and the delay that pushes the whole claim further out. Pull the pend reasons, rank them by volume, and you’ll usually find that a handful of conditions account for most of the manual touches. Those are your candidates.
The mistake here is treating a low STP rate as a staffing problem. It’s a configuration problem wearing a staffing problem’s clothes.
Check whether the right fee schedule is being applied
Jurisdiction-specific fee schedules drift. States update, rules don’t get revised, and a schedule that was correct at implementation quietly becomes the wrong one — still applying, still producing a reduction, just not the reduction it should.
This failure mode is dangerous precisely because nothing looks broken. The bill gets priced. An EOR gets generated. Savings get reported. Nobody sees the delta between the reduction you took and the reduction you were entitled to.
Cross-check a sample of bills per jurisdiction against the current schedule by hand. It’s tedious, and it’s where I find real money more often than anywhere else.
Look at the coding edits you’re not running
CPT, HCPCS, and ICD-10 edits are where a rule set shows its age. Programs tend to implement a solid set of edits at go-live and then add to them only when something goes visibly wrong. Meanwhile coding practices change, and the gap between what you’re catching and what’s catchable widens.
Modifier logic deserves specific attention. Modifiers are how a provider explains why a normal rule shouldn’t apply — and if your rules take modifiers at face value without validating them against the procedure and the jurisdiction, you’re accepting an argument without checking it.
Then look at how contracts get chosen
This is the one that surprises people, because it’s not really a fee schedule question at all.
Most network configurations use stacking: the engine walks a priority list of contracts, applies the first one that matches, and stops. It’s simple, it’s predictable, and on any given bill it’s frequently not the best available rate. The contract that happens to sit highest in your priority order is not necessarily the contract that reduces that particular bill the most.
The alternative is to evaluate every applicable contracted rate at once and apply the single deepest reduction. I’ve implemented this on a program spanning more than 50 contracted PPO networks. The results were better savings, no stacking conflicts, and — the part the compliance team cared about — one clean, defensible network rate on every EOR instead of a layered reduction that’s hard to explain.
Capstone can be configured to do this. Most installations aren’t.
Write down what the rules do
The least glamorous item on this list and the one that pays off longest.
Rules libraries accumulate. Someone writes a rule to solve a specific problem in a specific month, and three years later nobody remembers why the rule exists or whether the condition it was handling still occurs. When the person who wrote it leaves, the rule becomes untouchable — nobody will delete something they don’t understand, so it stays, and the library gets heavier.
A documented rules library is what makes the next optimization possible. It’s also what you hand a regulator when they ask why a bill was reduced the way it was.
The actual point
None of this requires a new platform. It requires knowing what the rules are doing, which is a smaller and cheaper question than it sounds — and a much smaller question than a migration.
The fastest way to cut claim costs isn’t fighting bills. It’s accelerating the right decisions, with the right data, at the right time.