Payer price files: how often do they actually change?
Federal rules require health plans to update their price files every month. We downloaded 5,753 of those files every day for 28 days. Almost a third never changed at all. More than half changed nearly every single day. Neither pattern looks like a monthly update, and both make shopping hard.
The short version
Health plans have to publish what they pay. The files are real, and they are almost always online. We checked, and 99.40% of our download attempts came back healthy.
The problem is not getting the file. The problem is knowing what you are holding.
We watched 5,753 of these files for 28 days. They split into two groups that behave nothing alike:
| Group | Sources | Share |
|---|---|---|
| Changed zero times in 28 days | 1,670 | 29.3% |
| Changed 2 to 19 times | 933 | 16.3% |
| Changed 20 or more times | 3,104 | 54.4% |
A monthly update should look like one change per file, per month. That is not what either group does.
What these files are
When a health plan negotiates a price with a hospital, that price used to be secret. Since 2022 it has to be posted publicly, in a large machine-readable file.
There are a few kinds. Here is what our register holds:
| File type | Sources tracked |
|---|---|
| Provider rate files | 4,796 |
| Prescription drug files | 552 |
| Plan files | 296 |
| Index files (2026) | 108 |
| Index files (2027) | 1 |
An index file is a table of contents. It points at the other files. The provider rate files are the ones with the actual negotiated prices in them, and they are by far the biggest group.
What the rule actually says
The requirement is short and it is not vague. From 45 CFR § 147.212(b)(3):
A group health plan or health insurance issuer must update the machine-readable files and information required by this paragraph (b) monthly. The group health plan or health insurance issuer must clearly indicate the date that the files were most recently updated.
Two duties. Update every month, and say when you last did it.
What we did
We keep a register of every price file URL we can find, and we try to download each one every day. We store a fingerprint of the bytes we get back, called a hash.
If today's hash matches yesterday's hash, the file is identical. Not similar. Identical.
| Measure | Value |
|---|---|
| Window | 2026-07-31 to 2026-08-27 |
| Source URLs tracked | 5,753 |
| Issuers | 109 |
| States | 28 |
| Download attempts | 143,270 |
| Days the median file was checked | 27 |
The files are almost always there
Before the interesting part, the boring part. Availability is good.
| Response | Attempts | Share |
|---|---|---|
| 200 (file sent) | 125,561 | 87.64% |
| 304 (not modified) | 16,850 | 11.76% |
| 404 (not found) | 284 | 0.20% |
| 202 (accepted) | 193 | 0.13% |
| No response at all | 183 | 0.13% |
| 403 (refused) | 118 | 0.08% |
| 500, 502, 503 (server errors) | 80 | 0.06% |
| 400 (bad request) | 1 | 0.00% |
A 304 is a good outcome, not a bad one. It means the server checked our fingerprint and confirmed nothing changed. So 142,411 of 143,270 attempts, or 99.40%, ended in a healthy answer.
Dead links are rare. Only 20 of 5,724 sources ever returned a 404, and only 16 sources never once returned a working file.
This matters because "the data is not available" is the complaint people expect. It is mostly not true anymore.
Two populations, not one
Here is the finding. We counted how many genuinely different versions of each file we saw across the window.
| Different versions seen | Sources | Share |
|---|---|---|
| 1 (never changed) | 1,670 | 29.3% |
| 2 to 4 | 550 | 9.6% |
| 5 to 9 | 332 | 5.8% |
| 10 to 19 | 51 | 0.9% |
| 20 or more | 3,104 | 54.4% |
The middle is nearly empty. Only 383 sources out of 5,707, about 6.7%, landed in the 5-to-19 band where a real editing rhythm would put them.
Across all 5,707 sources we collected 86,595 distinct file versions. The median file had 24 versions in 28 days.
It splits by company too, not just by file. Of the 108 issuers we saw content from:
| Issuer behaviour | Count |
|---|---|
| Every file static | 30 |
| Every file churning | 1 |
| A mix of both | 22 |
Thirty companies published nothing new, anywhere, for the whole window.
Why "never changed" is the harder finding
An unchanged hash is strong evidence. If the bytes are identical, no price inside them moved. There is no room for argument.
997 sources gave us one single version across 20 or more separate checking days.
But be careful here, because we are not going to overclaim. Our window is 28 days, and a month is a little longer than that. A file that updates on the 30th of each month could sit still for our entire window and still be perfectly compliant.
So this is not a compliance scorecard. We are not saying these plans broke the rule. We are saying that if you downloaded one of these files on any day in August, you got the same prices as everyone else who downloaded it that month, and you had no way to tell how old they were.
Why "changed today" proves less than it looks
Now the other direction, and this is where most people would go wrong.
3,104 sources changed 20 or more times. 2,018 of them produced at least as many versions as the number of days we watched. That is new bytes essentially every single day.
It is tempting to read that as prices moving daily. We cannot support that, and we are not going to say it.
A file's bytes can change without a single price changing. Common reasons:
- The file has a generation timestamp written inside it.
- Records come out in a different order each time the file is built.
- The file is compressed slightly differently on each build.
Any one of those produces a brand new hash on identical prices. So the logic runs one way only:
| What we observe | What it proves |
|---|---|
| Hash is the same | No price changed. Certain. |
| Hash is different | The bytes differ. The prices may or may not have. |
That asymmetry is the honest core of this post. The static files tell us something definite. The churning files tell us we cannot tell.
What this means if you are shopping
Put the two groups together and you get the practical problem.
If a file never changes, you are looking at a snapshot of unknown age. If a file changes every day, you cannot tell a real price update from build noise. In both cases the file itself will not tell you whether the number is current.
| If the file is | You can trust | You cannot tell |
|---|---|---|
| Static for weeks | That nothing moved while you watched | How old the prices already were |
| Changing daily | That something in the bytes moved | Whether any price actually moved |
The fix is not to download the file once. It is to watch it over time, which is what a continuity archive does. A single download of a price file is a photograph. What you usually need is the history.
What we cannot tell you
Being straight about the edges of this.
- We do not cover the whole country. 28 states and 109 issuers, not all of them.
- Our window is 28 days. Shorter than a calendar month, so it cannot settle monthly compliance.
- We did not read the prices. This post is about whether files change, not what is inside them. We compared fingerprints, not rates.
- We did not measure the posted update date. The rule requires plans to display when they last updated. Our download record does not capture that field, so we cannot compare what plans claim against what we observed. We would like to. We have not.
- A 304 is the server's word. When a server says "not modified," we accept it rather than re-downloading. That is how conditional downloads work, and it is a small act of trust.
Data provenance
Source file: Payer machine-readable files published under the Transparency in Coverage rule, tracked in our mrf_sources register and downloaded into our mrf_fetches record. Source URL: CMS Health Plan Price Transparency
Records behind this page: 143,270 download attempts against 5,753 registered source URLs, covering 109 issuers across 28 states, between 2026-07-31 and 2026-08-27. Version counts computed over the 5,707 sources that returned readable content. Queried: 2026-08-27.
Computed here, and nowhere in the source files:
- The count of distinct content versions per source across the window.
- The two-population split, and the near-empty middle band between them.
- The issuer-level static, churning and mixed classification.
- The response-code distribution across all 143,270 attempts.
Regulatory text quoted from 45 CFR § 147.212, retrieved 2026-08-27.
Questions people ask
How often are health plans required to update their price files?
Monthly. 45 CFR § 147.212(b)(3) requires a plan or issuer to update the machine-readable files monthly, and to clearly indicate the date the files were most recently updated.
Does an unchanged file mean the plan broke the rule?
No. Our window was 28 days, which is shorter than a calendar month. A file updated on a fixed day near the end of the month could show no change across our whole window and still meet the requirement.
If a price file changes every day, are prices changing every day?
We cannot say that, and we do not. A file's bytes can change with no price change at all, because of an embedded timestamp, a different record order, or different compression. A changed fingerprint proves the bytes differ, nothing more.
Are these price files actually online and working?
Mostly yes. Of 143,270 download attempts, 99.40% ended in a healthy response. Only 20 of 5,724 sources ever returned a 404, and only 16 never returned a working file at all.
What is the difference between an index file and a rate file?
An index file is a table of contents that points to the other files. The provider rate files hold the actual negotiated prices. Our register tracks 4,796 provider rate files and 109 index files.
Why watch these files over time instead of downloading one?
Because a single download cannot tell you how old the prices are. Watching the same file across many days is the only way to learn whether it moves, when it moves, and whether it stopped moving.