When a zero count has a median

A hospital price file contains a count of zero allowed amounts. On the same row, it publishes a median allowed amount of $19,075.94. A note says there were zero instances of the item or service in the 15 months before posting.

The dollar amount looks precise. The problem is not whether it looks reasonable. The problem is what it claims to measure.

A negotiated price is not the same as a historical median

CMS's 2026 rules distinguish a payer-specific negotiated charge from allowed-amount statistics based on historical remittance data. For applicable percentage- or algorithm-based charges, the median, 10th percentile, 90th percentile and count must come from EDI 835 electronic remittance advice or an equivalent source.

When there are no claims in the applicable 12-to-15-month lookback, CMS's FAQ says to encode a count of zero, leave the three allowed-amount statistics blank, and explain the insufficient remittance history. Zero is a count, not a substitute median.

There is an important exception: when a negotiated charge can be fully calculated and encoded as a dollar amount, with no further percentage or algorithm changing it, the allowed-amount fields are not required. A percentage mentioned in a contract does not by itself prove a reporting gap. Start by checking how the published charge is encoded and what it represents.

What we found in one file

We downloaded a public CSV again on October 12 and checked every coded row carrying a negotiated percentage or algorithm. In that file, 1,692 of 2,197 such rows paired a zero count with at least one populated allowed-amount statistic. These are file-specific encoded-field findings, not a national prevalence estimate or a count of hospitals.

One row published a gross charge of $20,079.94, a negotiated percentage of 95%, a negotiated dollar amount of $19,075.94, and the same $19,075.94 as its median. The count was zero; both percentiles were blank. Its note reported zero service instances in the preceding 15 months.

The repeated dollar amount is a useful clue for a source-data check. It does not prove how the exporter produced it. The public file alone cannot tell us whether the count is stale, the median was copied from a contractual calculation, or another mapping issue exists. It also cannot establish whether the hospital actually received payments.

Check the relationship, not just the field

A useful test keeps the charge method, count, all three statistics, and notes together. First identify the rows subject to allowed-amount reporting. Then review zero-count rows with populated statistics. Keep the original row and its payer/plan context so the data owner can trace it to the source.

Do not fix the issue by changing the count to one or deleting a statistic simply to clear a warning. Reconcile the fields with the remittance history and applicable contract. If there are qualifying remittances, calculate the statistics and count from that history. If there are none, apply CMS's zero-count treatment and explanation. If the charge is fully calculable as a dollar amount, verify that the encoding reflects that case.

The lesson is small but useful: a precise number is not evidence that a historical statistic was measured. A price-file review needs to test whether related fields tell the same story.

Sources: CMS Hospital Price Transparency FAQ, current as of June 26, 2026; CMS JSON technical documentation. The example is from our public-file review; hospital and payer identifiers are withheld in this article.