Sign in
Request the sample
Every major health plan is required by federal rule to publish the rate it negotiated with every provider. What it publishes is multi-gigabyte compressed JSON, at inconsistent grain, with placeholder values mixed in among real prices. We read those filings continuously and turn them into one dollar rate per provider NPI, billing code, payer and period, with the local peer median and the local 90th percentile attached to every row.
The sample is a real slice of the production corpus with the full production schema and the full data dictionary. No card, no trial clock, no sales call required to look at it.
These are the live serving figures, read from this site's public stats endpoint when the page loads. They describe what is queryable today. If the endpoint does not answer, the label stays and no number appears.
The Transparency in Coverage rule made American healthcare pricing public in principle. In practice it produced files almost nobody can use. Six things have to happen between the payer's filing and a number you can put in front of a contracting committee.
Payers publish an index and then rate files, on their own schedules, at their own URLs. Published filenames are not reliable, so every file is checked against the reporting entity named inside the file itself before anything is ingested.
A rate in a machine-readable file is attached to a provider group key, not to a person or a practice. Until that key is resolved to the NPI level, the rate cannot be compared to anything. This is the step most consumers of these files skip.
Rates arrive as negotiated dollar amounts, fee-schedule references, per diems, case rates and percentages of charge. They are reduced to a single comparable dollar figure per NPI, billing code, payer and period, with the original rate type preserved on the row.
Payer files contain filler values that look exactly like rates. Left in, they move a median. Two bounds catch the ones that can be caught by rule, and both are published below as the actual predicate rather than described in the abstract. The rows that no rule should catch, because a nominal amount may be what the payer really filed, are published with their observation count so you can judge them yourself.
The useful question is never "what is this code worth nationally." It is "what does this payer pay other providers of this specialty, for this code, in this market." Percentiles are computed across providers inside the same code, payer and market, and a cell with too few providers is published empty rather than filled.
Every row carries the NPPES-registered provider attributes and the period the rate was observed, so a refresh adds a new period rather than overwriting history.
Every tier is built from the same corpus, with the same filters and the same method. What changes is whether you get provider-level rows, and how much of the country you get them for.
One payer, one state, the highest-volume billing codes. The full production schema, not a cut-down preview schema.
For a data team that wants to test joins against its own provider and claims tables before it talks to anybody.
Request the samplePercentile distributions of negotiated rates by payer, by billing code, by market and by specialty. Refreshed monthly.
For payer contracting, network strategy, revenue-cycle benchmarking, actuarial work and analytics products that need a defensible local median rather than a national average.
Scope a subscriptionThe corpus at NPI grain: one normalized dollar rate per provider, billing code, payer and period, with the peer comparison and RateScore attached.
For analytics and RCM vendors embedding rate intelligence, payers and systems running competitive rate analysis, and investors doing rate diligence on provider assets.
Talk about a licencePricing for the benchmark subscription and the enterprise licence is set against scope, term and delivery, so it is agreed on a call rather than listed here. Multi-entity and portfolio scope is never gated and never priced inline.
The data does not need to move to be useful. On Snowflake and Databricks you query it inside your own account, with your own compute, and access can be revoked at the end of a term. Where you would rather hold the files, you get Parquet.
A secure data share. Nothing is copied into your account and nothing is exported. You query the shared objects directly.
Delta Sharing. The open protocol means the data is also readable from Spark, pandas and BI tools without a Databricks account.
Dated revisions of Parquet objects in S3, so each monthly refresh is an addition rather than a rewrite.
Compressed Parquet by direct delivery or SFTP, partitioned by payer, state and period. For teams that want the bytes.
We are preparing listings on the four storefronts below. None of them is live yet, and this page will say so until each one is. Every product above is available directly today, which is faster than any storefront review in any case.
A free sample listing, a subscription-priced benchmark listing, and the provider-grain corpus by private offer only. The enterprise share stays off the public catalogue by design.
A free sample product and a subscription benchmark product with subscription verification enabled, so every subscriber is a known organization. Enterprise scope by private offer.
An instant-access sample and a request-access enterprise listing, both delivered over Delta Sharing.
Catalogue presence for buyers who start their search in a data marketplace rather than on a vendor site.
Snowflake share, Delta share, Parquet or SFTP, under a licence signed with us. This is how every buyer gets the data today.
A rate benchmark whose method you cannot inspect is not evidence. The columns below are the real production columns. The complete data dictionary, including the exact provenance of every derived field and the known limits of each one, comes with the sample.
| Column | Type | Meaning |
|---|---|---|
| npi | string(10) | The public federal provider identifier. Never a patient identifier. |
| billing_code | string | CPT, HCPCS, DRG or revenue code. |
| code_type | string | Which code system the code belongs to. |
| payer | string | The plan family that published the rate. |
| negotiated_rate_usd | decimal(12,2) | The rate, normalized to one dollar figure. |
| negotiated_type | string | How the payer expressed it before normalization. |
| billing_class | string | Professional or institutional. |
| specialty | string | From the provider registry. Null where the NPI is unmapped, never guessed. |
| state | string(2) | The provider's registered location. |
| cbsa | string | The provider's market. |
| period | string | The period the rate was observed, as YYYY-MM. |
| Column | Type | Meaning |
|---|---|---|
| payer | string | The plan family. |
| cpt | string | The billing code. |
| cbsa / state | string | The market, or the state, depending on the table. |
| specialty | string | The peer group's specialty. |
| n_npi | integer | How many distinct providers are in the cell. |
| n_rate_rows | integer | How many underlying rate rows sit behind them. |
| p25 · p50 · p75 · p90 | float | Percentiles across providers, of each provider's own median rate. |
| period | string | As YYYY-MM. |
The percentiles are taken across providers, over each provider's own median rate. A P90 therefore means "the rate at the 90th percentile of providers in this payer, code and market." That is the correct basis for benchmarking one practice against its local peers, and it is the wrong basis for a claim about the spread of individual contracts. Both readings appear in this market. Only one of them is what this column is.
This is the single largest source of wrong numbers in price-transparency data, and it is invisible to anyone reading a headline figure. We publish the rule rather than describe it, because a filter you cannot inspect is a filter you cannot trust.
The most common family is a ceiling value multiplied by clean plan percentages, which is why the resulting numbers are not round. A second family sits at the floor, at one cent or one dollar. A floor placeholder is the more dangerous of the two, because it drags the median and the lower percentiles downward where a reader is least likely to question it.
The signature is spread, not magnitude. One value appearing across hundreds of unrelated billing codes is a placeholder. A high value confined to a single code is a real price for an expensive procedure, and filtering it out would be its own kind of error. So we bound, and we deliberately do not lower the magnitude bound to catch more, because that starts deleting real prices.
Which leaves a judgement we will not make quietly on your behalf. A small number of rows carry a nominal value, a cent or a dollar, on codes where that may genuinely be what the payer filed: a non-covered item, or a service bundled into another. Deleting a payer's actual filing is not cleaning, it is editing. So those rows are published with their observation count attached, and you can find every one of them in the sample in a single query. We would rather hand you a row you can interrogate than a table we have quietly tidied.
A cell that fails the provider floor is published with nulls. It is never published with a value computed over four providers, and it is never filled in from a wider geography or a national figure to make the table look complete. Both rules above are checkable against the sample rather than taken on trust, which is the only reason printing them is worth anything.
Every coverage gap below will surface within an hour of a technical evaluation. Naming them here costs us nothing and saves you the hour. If a payer, a state or a code family matters to your work, ask and we will tell you exactly what is in the corpus for it before you commit to anything.
Kaiser and Humana do not appear in the corpus at provider grain. This has been verified in both of our stores rather than assumed. If your work depends on either, this dataset is not the right one for that part of it, and we will say so on the call.
We make no claim that any payer's file set is complete for any state or any month. That is why the provider count and the underlying row count are carried on every benchmark row: so you can judge each cell on its own evidence instead of trusting a headline.
Depth is concentrated in recent periods. It is the right asset for "what is being paid now and what should we be asking for." It is not yet the right asset for a multi-year rate trend, and we will not present it as one.
Where a provider is not mapped to a taxonomy, the specialty field is null. It is left null rather than filled with a specialty average or a best guess, because a guessed specialty silently corrupts every peer group it lands in.
At least one specialty bucket currently merges two distinct professions whose distributions diverge materially at the upper percentiles. It is excluded from what we sell until it is split on full taxonomy. You will not find it quietly included.
Geography comes from the provider's registered practice location in the federal registry. That is not necessarily where a given service was rendered, and for a multi-site organization it is the attribute to check first.
The National Provider Identifier is a public federal identifier for a provider or an organization. There is no member, claim, encounter, diagnosis or demographic field in any table we publish, and the schema is checked for their absence before a partition ships. No PHI is required or stored for any product on this page. That is a statement about the contents of the data. It is not a claim of HIPAA certification and it is not an offer of a business associate agreement.
Rates are derived from the machine-readable files health plans are required to publish under the federal Transparency in Coverage rule, and from the public NPI registry. The filings are ours to read because they are published for everyone to read. What we add is the parsing, the provider resolution, the normalization, the placeholder detection and the peer statistics.
Nothing in any tier is modeled, imputed, interpolated or filled from an average. Where we do not have enough evidence for a value, the value is absent and the row says so. An honest empty cell is worth more to a buyer than a plausible one.
Monthly refresh, adding a period rather than rewriting one. Support at david@reddenda.com with a one business day first response. Any breaking schema change is announced to active subscribers at least thirty days ahead, and the prior schema stays queryable for that period.
Only the email is required. Everything else just makes the sample more useful, because we cut it to the payers and states you actually care about rather than sending a generic extract.
Tell us the payers and states you care about and what you are building. You get a real slice of the production corpus with the full schema and the full data dictionary, and a straight answer about what the corpus does and does not hold for your use case.
Enterprise and data-room access: email david@reddenda.com with the payers, states and use case. You get the full data dictionary, the schema, measured row counts, known defects and the price sheet, not a slide deck.
Reddenda, operated by TwinFlame. Support and licensing: david@reddenda.com.