Six organizations in your market have a published rate for the procedure you are about to negotiate. Two of them are paid more than you are. Before that fact goes into a payer presentation, it needs to survive a harder question: are those rates comparable to yours at all?
A rate that looks similar on the surface can describe a different setting, a different legal entity, a different payer product, or a different way of getting paid. Put those rows in the same chart and you get a precise-looking median that does not describe your market. Remove them and the line moves.
This article walks through the tests I would want a benchmark to pass before any rate is retained, and what the retained rows should carry with them so the payer, finance, and your own team can see why they belong.
Start with the candidate set, not the answer
A comparison usually begins with a lookup: one payer, one billing code, one geography. The result is a candidate set of providers and rates. In Transparency in Coverage data that set can be large, because payers publish a rate for every in-network provider in every market a plan touches, and that includes affiliates, hospital departments, and arrangements that have nothing to do with how your organization is paid (hospital files vs. payer files).
The temptation is to sort the candidate set by rate and lead with the highest number. The discipline is to treat the candidate set as unvalidated and work through it row by row. Think of a funnel: candidates go in at the top, each one is checked against a defined set of criteria, and only the rows that pass come out with a label explaining why.
Eight criteria do most of the work.
Setting: same site of service, or a different product
A procedure performed in a hospital outpatient department, an ambulatory surgery center, and a physician office is reimbursed on different schedules with different cost structures. A surgery center that benchmarks against hospital outpatient rates is not comparing peers; it is comparing payment models.
Payer files make this testable. Each negotiated price carries a billing class of professional, institutional, or both, and professional rates carry a place-of-service code indicating the setting in which the service was provided (CMS in-network rate schema). If the setting does not match the agreement you are negotiating, the row leaves the comparison, however attractive the number.
Geography: a defined market, not a convenient radius
Geography should be declared before the rates are pulled, not adjusted afterward to improve the result. A core-based statistical area, a defined set of counties, or a drive-time boundary are all defensible as long as the choice is stated and held constant. If a high rate from two markets away is included because it helps the argument, the payer will notice, and the benchmark loses credibility for every other row.
Be prepared to explain why the boundary fits the question. A tertiary referral service and a routine procedure do not draw from the same market, and the geography should reflect that.
Identity: who is actually behind the rate
The rate belongs to a contracting entity, not to a name in a file. An individual clinician's NPI can appear under more than one organization, and a tax identification number is the level at which contracts are typically negotiated and payment is received (NPI-to-TIN mapping). An NPI match is a research lead, not proof that a rate applies to the organization you think it does (from payer question to defensible benchmark).
Identity also catches the most common self-inflicted error: your own affiliate. A rate attributed to an entity your system owns, manages, or shares a contract with is not an independent market signal. Excluding affiliates and explaining how you identified them should be a visible step in the method.
Peer profile: the same kind of organization, not just the same billing class
Two hospitals can share a billing class, a market, and a payer and still not be peers. A hospital with a Level I trauma center, a NICU, a transplant program, or a teaching mission carries a cost structure and a negotiating position that a community hospital without those programs does not. The same is true on the ambulatory side: a hospital-owned surgery center often negotiates under the system's agreement and may carry rates that an independent or physician-owned center cannot reference as its own market.
None of those attributes appear in a payer file. A negotiated rate is attached to an NPI, a tax ID, and a billing class; it says nothing about trauma designation, service lines, bed count, ownership, teaching status, or case complexity. That context has to be built from separate research and attached to each candidate before the comparison is run, and the peer profile your organization is claiming should be declared up front. If you are an independent surgery center, say so, and exclude hospital-owned centers on that basis rather than keeping the ones that happen to help.
The payer will make this argument against you if you do not make it first. A benchmark that quietly mixes tertiary referral centers into a community hospital's comparison, or hospital-owned centers into an independent center's, is the easiest kind to dismiss.
Payer and network: the same payer is not enough
A rate published by the payer you are negotiating with may belong to a narrow network, a leased network, or a product you do not participate in. Network-level reporting and clearer product identifiers are arriving in the published files precisely because the same payer can carry several non-interchangeable rate books (price transparency is getting more usable). Retained rows should name the network and product they came from, and that context should match the agreement in scope.
Product: know which products the files actually contain
Plan product is a separate test from payer and network because the economics differ so much, and because the public files are narrower than many teams assume. The Transparency in Coverage rule applies to non-grandfathered group health plans and issuers of group and individual coverage (CMS fact sheet). It does not apply to Medicare Advantage or Medicaid managed care plans, so their rates are not in payer machine-readable files (Mathematica).
That has two consequences. First, every rate in a payer file is a commercial rate. If you are negotiating a Medicare Advantage or Medicaid managed care agreement, a peer rate pulled from a payer file is not evidence about that product, even when the payer name matches. Second, if you need peer evidence for those products, the hospital side of price transparency is where it exists: hospitals are required to publish payer-specific negotiated charges for Medicare Advantage and Medicaid managed care plans (CMS hospital price transparency guidance), with the caveats that come with hospital files (hospital files vs. payer files).
Within commercial coverage, distinguish exchange, HMO, and PPO products where the file identifies them. If product cannot be established for a row, note the gap rather than assuming it matches yours.
Code: the whole code, including the modifier and the component
A billing code match is the easiest criterion to pass and the easiest to pass incorrectly. The professional and technical components of the same code are different services. A modifier can change what the rate represents, and payer files are expected to carry a separate negotiated price when a rate depends on one (CMS in-network rate schema). Bilateral, assistant-at-surgery, and multiple-procedure conventions all belong in this test. Two rows with the same five-digit code and different modifiers are not duplicates to be averaged; they are different comparisons.
Payment method: a dollar is not always a dollar
The last test is the one that most often produces an impressive but meaningless chart. Published rates can be a negotiated dollar amount, a derived amount used for internal accounting, a fee schedule amount, a percentage of charges, or a per diem, and the arrangement itself can be fee-for-service, a bundle, or capitation (CMS in-network rate schema). A case rate that bundles the facility fee, implant, and anesthesia cannot sit next to a fee-for-service facility rate for the same code. The number is higher because it pays for more, not because the payer values that provider more.
Each retained row should state its payment method. Rows with a different method are not wrong; they belong in a different comparison, or in no comparison at all.
What the funnel leaves behind
Consider an illustrative candidate set for one procedure, one payer, one market. The organization doing the analysis is an independent surgery center negotiating a commercial institutional fee-for-service rate, and it has declared independent, non-hospital-owned centers as its peer profile.
Across all six rows the median is $2,800. Across the three retained rows it is $2,650. The affiliate and the case rate were two of the three highest numbers in the set, and neither one survives. That is the point of the exercise: the rows most likely to inflate an argument are often the rows least likely to be comparable.
These figures are illustrative and do not describe an actual customer, payer, or market. The arithmetic is simple on purpose; the judgment is in the criteria. Note what the table does not show: how often each organization actually performs the procedure. The files do not say, and the median above treats every retained row equally.
Label what you keep
The funnel is only half the work. Every rate that remains should carry the evidence of why it remains, so a reviewer can challenge the selection without rebuilding it:
- Matching criteria: the setting, geography, entity, peer profile, payer and network, product, code and modifier, and payment method that each row satisfied, with the source for any attribute that did not come from the payer file.
- Source and date: which file the rate came from, when it was published, and the expiration date the payer attached to it. Published rates change, and a rate that was comparable in one quarter may have been renegotiated by the next (rate change: why a single snapshot is not enough).
- What was excluded and why: the rows that left the comparison, with the test they failed. A payer will ask. Finance should ask first.
A benchmark presented this way is narrower than the raw lookup and far more useful. It can support a request for an increase, and it can also tell you, before you walk into the room, that the below-market case is weaker than the headline suggested.
Three boundaries worth stating plainly
First, a published negotiated rate is not proof of what a provider was paid. Market benchmarking and claims-based underpayment analysis answer different questions (negotiated rate vs. allowed amount). Keep them separate in the brief.
Second, payer files contain rates, not utilization. A published rate does not tell you whether the peer performs the procedure every day or has never billed it; a rate for a code the provider never bills is the familiar ghost-rate problem. That means you cannot volume-weight a peer median from the files alone, and a peer with a high rate and no volume should carry less weight in your argument than its number suggests. Utilization reporting is coming to payer files, but slowly: the October 2026 amendments add a Utilization File that identifies items and services with at least one paid claim by NPI, tax ID, and place of service, without claim counts, with the first posting due July 1, 2028 (Norton Rose Fulbright). Until then, the volume that matters is your own. Weight the retained rates by your utilization when translating a rate gap into dollars, and treat any claim about a peer's volume as an assumption to disclose.
Third, passing all eight tests establishes comparability, not entitlement. The retained rows tell you where the market sits for a defined comparison. Whether the payer should pay you that rate depends on your volume, your service mix, your contract, and the rest of your negotiating position.
Where the investigation should live
Most of this work is investigation rather than calculation: resolving who is behind an NPI, separating billing classes and modifiers, identifying affiliates and ownership, attaching the peer profile the files leave out, checking which network a rate belongs to, and explaining the variation instead of averaging over it (the last mile of price transparency). It is tedious, it is repetitive, and it is exactly where a benchmark earns or loses its credibility.
That is the job we have built Trek's Market Intelligence agents to take on: build the comparison population against declared criteria, show the provider-level detail behind each retained rate, and disclose the scope, assumptions, and gaps alongside the answer (Trek Health's AI agents). The judgment about what belongs in your negotiation stays with your team. The software should make that judgment faster to form and easier to defend.
Pick one procedure and one payer where you suspect the market comparison has been doing more work than it should. Request a working session with Trek Health and we will run the candidate set through the funnel together.
