How to Use Transparency in Coverage Data to Read Payer Reimbursement at Scale

By Clayton Severson, Principal Consultant · Published August 15, 2026

Most health plans in the United States now publish the rate they negotiated with every in-network provider, for every billing code. Transparency in Coverage machine-readable files are that disclosure. The data is free, enormous, and mostly noise. This is the method for turning it into a reimbursement picture: which files, which fields, which rows to discard.

Something genuinely strange happened in American healthcare in 2022 and most provider organizations still have not used it. The prices that were the most closely guarded numbers in the industry, the ones no hospital would tell you and no payer would confirm, became a public download. Not a summary. Not a percentile band from a survey vendor. The actual contracted rate, code by code, tied to a tax ID.

The reason nobody uses it is not secrecy anymore. It is volume. The files are published in a format built for machines and at a scale that defeats a laptop, so the practical barrier moved from legal to technical. This article is the method for getting past that barrier: how the files are organized, which fields carry the analysis, how to filter and clean at scale, and where the data stops being able to answer your question. The method here was developed against a single-service-line reconstruction, one code and one payer in one metro, then generalized.

What is Transparency in Coverage data?

It is the price disclosure the federal government requires of health plans, as opposed to the one it requires of hospitals. The Departments of Health and Human Services, Labor, and the Treasury issued the Transparency in Coverage final rules on November 12, 2020, and enforcement of the machine-readable file requirements began July 1, 2022. The public-disclosure requirement is codified for issuers at 45 CFR 147.212, with parallel provisions in the ERISA and Internal Revenue Code regulations for group health plans.

Three properties of the rule are what make the data usable at all, and they are worth stating precisely because they are the legal basis for building a pipeline on top of someone else's data:

• Public, free, and unauthenticated. The files must be available without charge, without establishing a user account or password, and without submitting a name, email address, or telephone number. There is no click-through agreement to violate because there is no click-through.
• Open, non-proprietary format. The CMS technical implementation guide permits JSON, XML, and YAML, and explicitly rules out PDF and XLS/XLSX. In practice essentially everyone publishes JSON, usually gzipped.
• Updated monthly, with the date stated. Plans must refresh the files monthly and indicate when they were last updated.

What can payer negotiated rate files actually tell you?

Two things nothing else will tell you: what a specific payer pays other providers for the same code in your market, and how wide the spread is. That is the entire value proposition, and it is a large one, because rate opacity was the structural advantage payers held in every negotiation.

The Congressional Research Service, analyzing the data in a June 2025 report on its technical challenges, put a number on the spread that makes the point better than any argument. For a major knee or hip replacement with complications in Dallas, one insurer's negotiated rates ranged from $19,599 to $102,369 across different hospitals. Inside a single hospital, rates for that same procedure ranged from $14,306 to $56,695 depending on which insurer was paying, a fourfold difference in the same building for the same work.

Those are the numbers that reframe a negotiation. "You pay us badly" is an opinion. "You pay us at the 22nd percentile of what you pay in this metro for this code, and here is the distribution" is a finding, and it is built entirely from the payer's own published disclosure.

What is inside an in-network rate file?

A deeply nested JSON document, and about a dozen fields that matter. The structure is defined by the CMS technical implementation guide, published openly at github.com/CMSgov/price-transparency-guide, whose major schema version was fixed at 1.0.0 for the July 2022 deadline.

At the top level a file carries reporting_entity_name, reporting_entity_type, last_updated_on, version, an in_network array, and a provider_references array. Each in_network element is one billing code, and inside it negotiated_rates pairs a set of providers with a set of prices. Here is what each field is doing to your analysis.

Field	What it carries	Why it matters to the analysis
billing_code + billing_code_type	The code and its code set: CPT, HCPCS, ICD, MS-DRG, APC, APR-DRG, EAPG, NDC, HIPPS, CDT, RC, LOCAL, and others	Your join key. Mixing code sets in one comparison is the fastest way to produce a wrong number
negotiated_rate	A number	The value you came for, but only meaningful once you know the next field
negotiated_type	One of negotiated, derived, fee schedule, percentage, per diem	A percentage row is a percent of billed charges, not dollars. Averaging it with dollar rows silently destroys the analysis
negotiation_arrangement	ffs, bundle, or capitation	Only ffs rows are comparable to a line-item fee schedule
billing_class + setting	professional / institutional / both; inpatient / outpatient / both	The professional and facility components of the same encounter are different rates. Do not pool them
service_code	CMS two-digit place-of-service codes; required when billing_class is professional	Office versus facility changes the rate. The shorthand CSTM-00 means the rate applies to all places of service
billing_code_modifier	Modifiers attached to the rate	Modifier-bearing rows are a different price for the same code. Filter deliberately rather than accidentally
expiration_date	When the rate lapses	Often the sentinel 9999-12-31, which tells you nothing. Trust the file's last_updated_on instead
provider_references	Provider groups keyed by npi array and a tin object typed ein or npi	The only provider identity in the file. No name, no address, no specialty. You supply those

That last row is the one that does the most damage to naive analyses, and it deserves its own section below.

How do you turn machine-readable files into a rate table?

Seven steps. The order matters more than the tooling, because every step exists to make the next one smaller.

1. Start at the index, not the data. Payers publish a table-of-contents file whose required naming convention is <YYYY-MM-DD>_<payer or issuer name>_index.<file extension>. It maps plans to the URLs of their rate files. Individual files follow <YYYY-MM-DD>_<payer or issuer name>_<plan name>_<file type>.<extension>.
2. Select before you download. Index files are not small catalogs. CRS documented one insurer's index listing MRF URLs for over 1,800 plans in a single state, with one of those plans carrying more than 300 distinct negotiated-rate files. Deciding which plans and networks you care about is an analytical decision made at this step, not a filter applied later.
3. Stream; never load. Individual files can approach a terabyte. Parse incrementally with a streaming JSON reader rather than reading a document into memory, and land the survivors in a columnar format so the rest of the work is cheap.
4. Filter on three axes at parse time. Billing codes (your twenty to twenty-five revenue drivers), provider identifiers (the TINs and NPIs in your market), and geography. Applying all three during the parse instead of after it is usually a four-or-five-order-of-magnitude reduction, and it is the difference between an overnight job and a coffee break.
5. Resolve provider identity. The file gives you NPIs and TINs. Join them to NPPES, the free national NPI registry, to recover organization name, practice address, and taxonomy. Without this step you cannot say who a rate belongs to, which means you cannot build a peer group, which means you cannot compute a percentile that means anything.
6. Discard what cannot be a real rate. The cleaning rules, below. This is where most of the rows go.
7. Join to a benchmark and roll up. Attach the Medicare allowable for each code and locality, restate every surviving rate as a percent of Medicare, and compute the distribution per code and market. The mechanics of that denominator are covered in how to benchmark your payer reimbursement rates against Medicare.

Step 4 is the one people skip, and it is the one that decides whether this is feasible. Everything upstream of a filter is I/O you pay for; everything downstream is analysis you enjoy.

Why is most of the data unusable, and what do you do about it?

Because the rule required plans to publish rates for every contracted provider and service combination, not every combination that actually occurs. The result is an enormous population of rows describing care that will never be delivered.

Five cleaning rules do most of the work, and every one of them should be written down and defensible, because a payer network team knows the quality problems in its own published files better than you do:

• Specialty plausibility. Drop rows where the rendering provider's NPPES taxonomy cannot plausibly perform the code. This is the single highest-yield filter and it is why step 5 comes before step 6.
• Non-dollar rows. Segregate negotiated_type values of percentage and per diem, and negotiation_arrangement values of bundle and capitation, into their own analyses. Never average them into a dollar distribution. Under the Departments' April 2022 FAQs Part 53 safe harbor, plans that cannot state a dollar amount in advance may report a percentage or describe the arrangement in an open text field, which is why these rows exist and why they are not directly comparable.
• Degenerate values. Rates of zero, rates of one dollar, and rates orders of magnitude off the Medicare allowable are almost always placeholders. Set the threshold explicitly rather than eyeballing outliers.
• Class and setting hygiene. Compare professional to professional and institutional to institutional. Match place of service. A "spread" that is really a mix of office and facility rates is not a spread.
• Deduplicate on the natural key. The same rate frequently appears across many plan files from one issuer. Deduplicate on code, modifier, class, setting, place of service, provider group, and rate before counting anything, or a single large national plan will dominate a percentile purely by repetition.

Two more traps worth naming. Field naming is inconsistent across issuers in ways that break automated ingestion; CRS found the same concept reported as PLN_NME, plan_nm, and Plan_name across insurers. And URLs expire: files are dated, and once a month rolls over, last month's link frequently stops resolving. If your pipeline stores links rather than data, it will quietly go dark.

Where do you get Transparency in Coverage data without building the pipeline?

You buy an extract. That is a legitimate answer and often the right one, because everything above is engineering labor that produces no competitive advantage. The files are free by law; the cost is storage, egress, compute, and the weeks of work that turn a terabyte of nested JSON into a table with fifty thousand defensible rows in it.

Data source note: the negotiated-rate extracts behind the method described here came from DeductibleData, a self-serve source for Transparency in Coverage negotiated-rate datasets whose configurator scopes a custom pull by payer, geography, and billing code. We buy datasets there; the extraction is theirs, and the cleaning rules, the benchmark joins, and the conclusions are ours.

Whether you build or buy, one scoping decision matters more than any other, and it is easy to get wrong: scope the pull to the market you are actually arguing about. A statewide pull on a regional Blues plan sounds thorough and is frequently the wrong shape, because a large share of the rows will describe out-of-area providers reached through inter-plan arrangements rather than the local network you compete in. Those rows are real, they are just answering a different question, and they will drag a percentile in a direction you cannot explain when someone asks. Pull the metro, the specialty, and the codes. Precision in the scope is worth more than volume in the extract.

How do you turn a clean rate table into a reimbursement picture?

Three joins, in order, each of which converts the data into a different kind of argument.

1. Join to Medicare. Restate each rate as a percent of the Medicare allowable for that code, locality, and year. This makes rates comparable across codes, which raw dollars are not, and it puts your rates on the scale every payer contracting team already speaks.
2. Join to your peer group. Using the resolved provider identities, compute the distribution across comparable providers in your market and locate yourself in it. Percentile is the claim that lands, and it is only as strong as the peer definition behind it, so state that definition out loud before anyone asks.
3. Join to your own volume. A rate gap is only worth what it is multiplied by. Weight each code by twelve months of your units to convert the percentile table into annual dollars, which is what turns an observation into an ask. That modeling is covered in using your claims data to win payer contract negotiations.

Read in that order, the output is a single defensible sentence per payer: this plan pays us at X% of Medicare on the codes that carry our revenue, which is the Nth percentile of what it pays comparable providers in this market, and closing that gap is worth $Y a year at current volume. Every clause in that sentence traces to a specific dataset, and the first two clauses trace to the payer's own disclosure.

What can Transparency in Coverage data not tell you?

Quite a lot, and being honest about it in the room is what keeps the rest of the analysis credible. The single most common failure mode is treating a rate file as if it were a claims file. It is not. It contains prices, not events.

Question	Can the MRFs answer it?	What you need instead
What does this payer pay for this code in this market?	Yes, this is the core use	Nothing else
Where does our rate sit against comparable providers?	Yes, after identity resolution and cleaning	NPPES join and a stated peer definition
How often is that service actually performed here?	No, there is no volume in the files	CMS utilization datasets, or your own claims
What did this payer actually pay us last year?	No, published rates are not adjudicated payments	Your 835 remittance history
Does the contract's payment logic apply here?	No, multiple-procedure and lesser-of rules are invisible	The contract itself
Is this rate in force today?	Partly, via the file's posting date	Monthly refresh; treat expiration_date skeptically
Which self-funded employers pay this?	Sometimes, plan attribution varies by issuer	Plan-level review of the index file

The other honest limit is that a percentile is not leverage. It documents leverage. If a plan controls a third of the covered lives in your market and you cannot credibly leave the network, a beautifully constructed distribution gets you a better outcome than no data and still does not get you to the 75th percentile. What it reliably does is stop you from spending the meeting on the wrong code, and stop you from accepting a counter that sounds generous and is not.

What is changing in the Transparency in Coverage rules?

A significant rewrite is pending, and it is worth tracking rather than acting on. On December 19, 2025, the three Departments jointly issued a proposed rule (CMS-9882-P) that would, among other things, move the update cadence from monthly to quarterly, organize in-network rates at the network level rather than plan by plan, exclude implausible provider-service combinations to shrink the files, add a change-log file so consumers of the data can process deltas instead of full reloads, and lower the claim-count suppression threshold on the out-of-network allowed-amount file from the current twenty claims.

Two caveats, stated plainly. First, it is a proposed rule; as of this writing it has not been finalized, and proposed provisions frequently change or disappear between comment and final. Second, commentary at the time of the proposal suggested that whatever is finalized would take effect roughly a year after publication, which puts real-world impact well out from today. Build against the schema that exists. If the change-log file survives to a final rule, it is the single most useful thing in the package for anyone maintaining a pipeline, because full monthly reloads of terabyte files is the dumbest part of this entire exercise.

Frequently asked questions