Self-Service Rate Lookup Without SQL for Clinical Diagnostics

At a glance

Brainy Neurals built a self-service rate lookup that gives a US clinical diagnostics pricing team negotiated commercial rates in seconds.

Why couldn’t the team query the rates themselves?

The Value & Access team at a large US clinical diagnostics organization had no self-service rate lookup for negotiated commercial rates.

The team prices lab tests against what the market already pays, so it needs rates by billing code, payer, state & provider. Nothing in that request called for a new model, & honest AI consulting says so on the first day.

Those rates sat in a commercial rate dataset with billions of rows, & reading any of them took SQL.

• Each rate question became a ticket, & the data team’s queue set the pace.
• A badly scoped query over billions of rows ran for minutes & burned credits.
• An analyst who half remembered a provider name couldn’t search for the rest.
• Two people with one question wrote two queries & defended two different numbers.
• Nobody could say later who had viewed which rate, because nothing recorded it.

A 2024 study of published US price transparency files found inconsistent formats & data that was unusable as published.^[1]

What do teams usually try first?

Teams that need rate answers usually try one of four routes, & each is reasonable on its own terms.

A 2024 benchmark of enterprise text-to-SQL, a model writing queries from plain questions, put the best agent near a fifth of real tasks. Academic benchmarks of the same task score above ninety percent.^[2]

How we designed the rate lookup

Brainy Neurals built the whole rate lookup around one rule for the warehouse. Every question the tool answers is shaped in the warehouse before anyone thinks to ask it.

Every question the tool answers is shaped in the warehouse before anyone thinks to ask it.

We roll rate tables up per billing code, payer, state & region. A search then reads one small table instead of scanning raw rows. A prefix index, a list sorted by the first letters of each name, holds provider names & identifiers, so matches appear while you type.

Our first decision was whether a language model should sit between the analyst & the data. We ruled that out in the first week of the build.

A contract rate has to survive a negotiation, so the same inputs must return the same number every time. Generative AI development earns its place where a question is open ended, & this one never is.

Our second decision was about where authorization lives. Identity comes from the client’s enterprise single sign-on, & the group check runs on every request. A session that outlives someone’s access is a hole, & rate data is the wrong place for one.

Rushabh Shah built the lookup from the pre-aggregation through to the per-request group check. Mitesh Patel set the access model & signed off the rate logic before anyone saw it.

The technology stack we used

Each layer of the technology stack had to pass one test before it stayed in. Could a business user get a defensible number without asking for help? The same retrieval discipline runs through our RAG development work.

Access & identity

Data & calculation

Application & delivery

How does one search actually run?

One rate search runs through six steps, from the first keystroke to the exported table.

1. An analyst picks a billing code, a payer, a US state & a sales region from the form.
2. Typing part of a provider name returns matching organizations & identifiers before the word is finished.
3. The app checks the signed-in session, then the group that session belongs to, & stops if either check fails.
4. The service reads the pre-computed rate tables for that combination & never touches the raw transaction rows.
5. Weighting logic returns the provider rate, the payer-weighted rate, the state rate & the outside-payer benchmark.
6. The screen shows each figure with its range, the analyst exports a table & the audit log records it.

The six steps run in order, & the analyst writes none of the query.

What went wrong during the build?

Four things went wrong on the rate lookup build, roughly in the order below.

The first working version queried the raw rows on every search. It answered correctly, yet it cost more per lookup than the ticket it replaced.

Provider search behaved worse than the cost problem did. Matching a partial name across a long list put the wrong organizations first, & analysts stopped trusting the search box.

The first build also checked authorization once, at login. A session could then outlive the access behind it, which is a governance hole in commercial rate data.

Then the weighted rates disagreed with spreadsheets the team already trusted. Both numbers were defensible, & neither could go out until somebody picked one.

Federal guidance on attribute based access control makes the same point, since an access decision can change between requests.^[3] These are the weeks when a team brings in specialist engineers.

How we fixed each build problem

Each fix to the rate lookup reads as obvious in hindsight, though none of them felt obvious at the time.

Rate weighting, incidentally, is the same arithmetic a grocery chain uses for an average shelf price.

An AI proof of concept exists to surface this kind of argument before anyone promises a date.

What changed after go-live?

After go-live, a rate request starts in a browser form instead of a ticket to the data team.

We haven’t published a turnaround time or a cost per query. The client reports that both improved, & a number we haven’t measured is a number we won’t print.

A pricing question that used to wait on somebody else now gets answered in the meeting. The same tool serves every region, so two analysts in different states quote the same benchmark.

Adding a new billing code now takes a table definition rather than a whole project.

What runs in production today?

The self-service rate lookup runs in production for the Value & Access team across its US sales regions. Analysts search commercial rates by billing code, payer, state & provider, & nobody opens the warehouse.

Since handover, the client has pointed the same screens at more rate tables. Each addition took a table definition rather than a rebuild.

Every login, search & export still lands in the audit record, which is what made the tool acceptable in healthcare. The data team now hears from the Value & Access team far less often.

What would we do differently?

Four lessons from the rate lookup build would change how we start the next one.

The first thing an analyst does with a number is put it in a deck.

Where else does self-service rate lookup fit?

A governed rate lookup returns pre-computed benchmark rates for a chosen code, payer & place, without anyone writing a query. It belongs wherever a priced decision depends on a dataset too large to read by hand.

Porting it needs an agreed rule, a clean entity list, an access group & someone who owns the definitions.

Services behind this case study

The services behind this case study cover the consulting, build & staffing work a rate lookup needs.

Our engagement models set how a team like this one runs. An AI readiness assessment tells you whether your data can carry the tool at all. The industries hub shows where this pattern already runs, & our AI development services cover the rest.

Similar case studies

Three more Brainy Neurals builds shipped into working environments rather than demos.