Hospital Price Transparency File Requirements: The Complete 2026 Guide

Published October 2, 2026

If your hospital publishes a machine-readable price file (and since 2021, every hospital operating in the US is required to), 2026 changed what has to be in it. CMS finalized new data elements, started enforcing them on April 1, 2026, and the files are now expected to contain claims-derived statistics, not estimates.

This guide covers what the file must contain, which formats CMS accepts, what changed in 2026, the mistakes that most commonly break files, and how to check yours before it goes public.

The two things CMS requires

The hospital price transparency rule has two deliverables. They are often confused; they are not interchangeable.

1. A comprehensive machine-readable file (MRF) containing standard charges for all items and services the hospital provides. This is the technical file, and the subject of this guide.
2. A consumer-friendly display of shoppable services: a human-readable web page showing prices for common shoppable services.

This guide covers the MRF only. If you're responsible for the shoppable display, CMS publishes a separate "10 steps" document for it. But most of the enforcement attention, and most of the file-format pain, lives in the MRF.

File formats: JSON, tall CSV, or wide CSV

Since July 1, 2024, hospitals have been required to use a CMS template layout and data specifications, not a homegrown format. CMS publishes the current template as v3.0, in three layouts:

• JSON (v3.0 schema): the structured option; best for hospitals with many payers and plans, and the format most downstream consumers prefer to parse.
• Tall CSV: one row per item or service, payer and plan combination. Long files, simple structure.
• Wide CSV: one row per item or service, with payer and plan charges spread across columns. Shorter files, wider rows, easier to break.

All three are legal. Pick the one your data pipeline can generate correctly and consistently: a correct tall CSV beats a broken JSON file every time. Whichever you choose, the file must conform to the CMS data dictionary for that layout. Field names, value formats, and required elements are specified, not suggested.

CMS also publishes an MRF file naming wizard that generates compliant file names under the required naming convention. Use it. Non-conforming file names are one of the most avoidable failure modes.

What's inside the file

At a high level, the MRF must contain each type of standard charge for every item and service the hospital provides:

• Gross charges: the chargemaster rate.
• Discounted cash prices: what a self-pay patient pays.
• Payer-specific negotiated charges: the rates negotiated with each payer and plan, identified by payer name and plan name.
• De-identified minimum and maximum negotiated charges: the floor and ceiling across payers.

Each charge must be tied to the item or service it describes, with relevant billing codes (CPT, HCPCS, MS-DRG, NDC, and others as applicable), descriptions, and, where the rule requires it, the contracting method and other modifiers. The file also carries hospital identity metadata and must reflect current standard charge information, updated at least annually.

What changed in 2026

The Calendar Year 2026 Outpatient Prospective Payment System final rule replaced estimates with actuals and added statistical reporting. The requirements took effect January 1, 2026, with enforcement beginning April 1, 2026. The changes:

Allowed amounts are now actual dollar amounts, not estimates. For payer-specific negotiated charges based on a percentage or algorithm, hospitals must encode the median allowed amount, replacing the old estimated allowed amount, plus the 10th and 90th percentile allowed amounts, all in dollars.

You must also encode the count. Alongside the three allowed-amount figures, the file must include the count of allowed amounts used to calculate them.

The lookback period is specified. Hospitals must calculate these figures from electronic remittance data (EDI 835 electronic remittance advice, or an equivalent source) using a lookback period of no less than 12 months and no longer than 15 months prior to posting the MRF.

Organizational NPI is required. The MRF must report any Type 2 (organizational) National Provider Identifiers associated with the hospital's primary taxonomy code, active as of the most recent update to the standard charge information.

A senior official must attest. Hospitals must include an attestation from a senior official confirming the information is accurate and complete. The MRF affirmation statement was also modified under the 2026 rule.

In plain terms: CMS moved from "publish your best estimate of the format" to "publish claims-derived statistics computed a specified way, and have someone senior sign off on them." Files generated under the old assumptions, especially anything still encoding estimated allowed amounts, need to be rebuilt, not patched. (Our validator checks that these fields are present and well-formed; see what it covers.)

The cms-hpt.txt discovery file

CMS requires each hospital to serve a small text file at the root of the public site hosting the MRF: https://<your-domain>/cms-hpt.txt. It tells CMS (and everyone else) where your files live. The format uses five fields per hospital location, repeatable for multiple locations:

• location-name
• source-page-url
• mrf-url
• contact-name
• contact-email

CMS publishes a TXT file generator to produce it correctly. Common mistakes: hosting it on the corporate domain while the MRF lives on a vendor's domain (the rule allows the hosting site to be a health-system or vendor origin, but the txt file must point at the real file), letting the contact email go stale, and forgetting to update the mrf-url when the file moves. CMS expressly permits the txt URL itself to redirect, so use that rather than serving a stale file.

Common failure modes

Across the industry, the same categories of defects recur. One independent open-source analysis estimated that while roughly 90% of hospitals had posted an MRF by early 2026, only about one in five files was fully compliant on data quality. Treat that as directional, but the gap between "posted" and "correct" is the entire game here.

Schema and layout errors. Fields that don't match the v3.0 data dictionary: wrong names, wrong types, extra undeclared fields in strict contexts. This is what validators catch first and fastest.

Missing required data elements. The 2026 additions are the current trap: files that still encode estimated allowed amounts, or omit the median, percentile and count trio, or lack the organizational NPI. Every rule change creates a cohort of files that were compliant last year and aren't this year.

Stale data. Standard charge information must be current, updated at least annually. A file generated eighteen months ago and never refreshed is a compliance problem regardless of its format.

Broken discovery. A perfect MRF that cms-hpt.txt doesn't point to, or points to with a dead URL, fails the practical test. CMS's enforcement process starts from discovery.

Encoding and size problems. CSVs with encoding corruption, truncated rows from interrupted exports, JSON files that no parser can finish reading. These are pipeline bugs, not policy disagreements, and they're embarrassing to discover via a CMS warning notice.

Inconsistent payer and plan structures. Payer names and plan names that vary row to row ("Blue Cross" vs "BCBS" vs "BlueCross BlueShield"): the file parses, but it's unusable, and it signals the underlying data was never normalized.

How to check your file before posting

Step 1: run CMS's own validator. CMS publishes a free Hospital Price Transparency Validator, online and as a downloadable command-line tool, that tests MRFs against the required template layouts and data specifications, alongside the naming wizard and TXT generator. Run your file through it before anything else. If it fails there, fix it there.

Step 2: check discovery end to end. Fetch https://<your-domain>/cms-hpt.txt from a clean browser, follow the mrf-url, and confirm you land on the current file, not last quarter's. Do this after every posting cycle, not just the first one.

Step 3: automate the check in your pipeline. Manual validation works once; posting cycles repeat. This is the gap SpreadRun's MRF validator fills: a hosted API that checks JSON v3.0, tall CSV, and wide CSV against the CMS v3.0.0 schema and templates, including the 2026 data elements, and returns a deterministic, itemized report your pipeline can gate on. Upload the file and get each finding with its rule and location. No installation, no Docker, $0.25 per completed validation. It inspects a bounded part of each file (metadata, template structure and up to 1,000 records), and the report says how much it read.

The honest version: CMS's free tool is fine for a person checking one file, and it reads the whole file. If files move through a system (vendor onboarding, quarterly reposting, multi-hospital health systems), the check belongs in the pipeline, not in someone's browser.

Enforcement: what happens if the file is wrong

CMS audits a sample of hospitals, investigates complaints, and its enforcement toolkit escalates: warning notices, required corrective action plans, and civil monetary penalties that may be publicly reported. The 2026 rule's shift toward claims-derived, statistically specified data elements makes files more mechanically auditable than before, which cuts both ways. It's easier to verify a correct file, and easier to spot a wrong one.

The cheapest compliance strategy hasn't changed: generate the file from real data, validate it against the spec before posting, keep discovery working, and re-verify on every cycle. The hospitals that get warning notices are rarely the ones with exotic legal theories. They're the ones with stale files, broken links, and missing data elements.

Official source: CMS hospital price transparency resources. This guide is general information, not legal advice.