CMS's proposed payer price-transparency rule reshapes how rate data is modeled, and the engineering it demands doesn't wait on a final date CMS hasn't set.
On December 19, 2025, CMS, the Department of Labor, and the Department of the Treasury proposed a set of changes to the payer price-transparency rules, published in the Federal Register as CMS-9882-P four days later. As of late September 2026, the comment period has closed, the final rule has not published, and no compliance date exists for the machine-readable file (MRF) changes: the Departments propose that the MRF provisions would apply twelve months after the final rule appears in the Federal Register, whenever that turns out to be.
It would be easy to read “proposed, not final, no date” as permission to wait. That reading is a trap. Most of what these changes require is data-modeling work, and almost none of it depends on the exact wording CMS lands on. The payers who start now will implement calmly inside whatever window the final rule sets. The payers who wait will do the same work under a production deadline instead, and that compression, not the rule itself, is where the delays come from.
The through line: this is an engineering program, and the clock that matters started before the rule did.
In practice, most of the payer MRF pipelines we see still prepare a separate In-network Rate File for every plan or policy, even when dozens of policies ride on the same network with the same negotiated rates, and many are still built on the original 2022 file format. CMS has already started pushing the other way: Schema 2.0, the technical format CMS has used to assess compliance since February 2026, expects plans that share rates to share files and names the network inside the file. The proposed rule finishes that move, replacing plan-level files with one file per provider network. Payers rebuilding their pipelines now are right to design for both at once. On paper it is deduplication. In practice it only works if “network” already exists in your data as its own entity, with its own rates and its own providers attached to it.
For many payers it does not. The network is assembled at export time from plan configuration rather than modeled directly as a first-class object. That gap, not the file format, is the actual long pole. The first practical step is not touching the export pipeline; it is inventorying where network-level data already exists as its own object and where it is being inferred, because everything downstream depends on the answer.
The taxonomy requirement compounds it. To shrink files, the rule would have payers exclude provider-rate combinations for services a provider would be unlikely to furnish or be reimbursed for (its own example is a rate for a podiatrist to perform heart surgery), and it would have them make that determination using the internal provider-taxonomy mappings they already use in claims adjudication. Payers have that logic; it is how a dermatologist does not get reimbursed for an appendectomy. What they have never had to do is post it publicly and apply it consistently to a rate file. That is adjudication logic becoming compliance infrastructure, and logic that is now externally visible has to be defensible in a way internal logic never did.
The proposed Utilization File lists every provider who submitted and was reimbursed for at least one claim for a covered item or service over the 12-month period ending six months before the file is posted. Read that as a data requirement rather than a filing one and the implication is immediate: it takes a full year of reliable claims-to-provider matching, and that year has to already be clean when the rule finalizes if a payer wants to be ready when it does.
This is the sharpest example of why “wait and see” costs more than it saves. The window is retrospective. A payer that waits for the final text before it starts caring about claims-to-provider data quality cannot buy back the twelve months the file will ask for. Building and validating that matching now is worth doing regardless of the final wording, because no wording change alters what a 12-month lookback needs.
While the in-network changes are mostly about shrinking files, the Allowed Amount File moves the other way. The proposal lowers the claims threshold for inclusion from 20 to 11, extends the reporting period from 90 days to six months, extends the lookback from 180 days to nine months, and requires the data to be aggregated by insurance market type: large group, small group, individual, and self-insured.
Every one of those changes produces more data, refreshed over longer windows, segmented more ways, and the Departments expect the result to be more out-of-network data disclosed than today. Notice the direction: in the same rule, the in-network files are being made smaller and more navigable while the out-of-network file is being made larger and more granular. A team that plans only for “smaller files” will be caught flat by the half of the rule that goes the other way.
CMS is candid about why it is doing this. It names three barriers: the files are too large, they lack the context to be interpreted, and they do not line up with the Hospital Price Transparency data. The second half of the proposal addresses the middle barrier, and it is worth seeing clearly who it serves.
New required context fields, product type, a numerical enrollment count, and the common network name, make the raw rates interpretable. A new Change-log File lets a downstream user see what moved between postings instead of diffing entire files. A plain-text locator file in the website root and a labeled “Price Transparency” or “Transparency in Coverage” link in the site footer make the files findable by machines and people alike. None of that is for the payer’s own benefit. It is for the researchers, tool vendors, and oversight bodies who have struggled to use these files, and the payer is the party that has to build for that audience. Reframing the work that way helps size it honestly: this is productizing a public data feed, not filling out a form.
Not everything here adds burden. The proposal moves in-network and allowed-amount reporting from monthly to quarterly, on the reasoning that networks and rates do not shift enough month to month to justify the pace, and it floats standardizing on a single file format instead of today’s open choice of format. Both are genuine simplifications, and both are mechanical.
That is exactly the risk. It is easy to read the proposal as “less often, one format” and let those two comfortable headlines absorb the planning attention that network-level modeling, taxonomy publication, and the utilization lookback actually need. The mechanical changes are the ones you can safely do last. The data-modeling changes are the ones that determine whether “last” arrives in time.
The instinct to wait usually rests on the idea that there is a deadline to back-plan from. Here, there is not one yet, and that will not stay true for long: final rules commonly follow their proposals by six to eighteen months, and this proposal is now nine months old, so the missing date could appear at any point. The MRF provisions are proposed to apply twelve months after the final rule publishes, and the final rule has not published. There is one fixed date in the proposal, plan or policy years beginning on or after January 1, 2027, but it attaches specifically to the consumer cost-sharing disclosure provisions (the phone and price-comparison tool changes), not to the MRF changes discussed here, and with no final rule three months before it arrives, even that date can hold only if the rule is finalized soon. Those are two separate tracks with two separate clocks, and reading them as a single deadline is a way to get the planning wrong in both directions.
So “wait and see” does not reduce the work. None of the hard parts, modeling the network as a first-class object, publishing the taxonomy mapping, standing up a clean 12-month claims-to-provider history, absorbing a larger Allowed Amount File, depends on CMS’s final wording. Waiting removes none of it. It only moves all of it inside whatever is left of the twelve-month window after a date exists, turning a project that could be paced across several quarters into one run against a clock.
The proposed rule reads like a filing change and behaves like a data-modeling program. The payers who treat it that way, starting with an honest inventory of where network-level data and claims-to-provider history already live, will be adjusting a model they have already built when the final rule lands. The ones who wait will be building that model and meeting the deadline at the same time.
If you are working out what this means for your own MRF pipeline, we should talk. More on how we approach this kind of work: Data & AI Foundations.
case study
perspective
case study
Tell us what you're trying to do. A senior practitioner will read it.
Talk to us