The Transparency in Coverage (TiC) final rule, issued by CMS, requires most group health plans and health insurers to publicly disclose pricing data through Machine-Readable Files (MRFs). These files provide a structured and standardized way to publish negotiated rates and out-of-network reimbursement data.

OmniRate handles this data at scale, so that you don't have to deal with MRFs at all. However, if you still want to learn about MRFs, this article explains what they are, how they’re structured according to the CMS schema, how they’re published, and what practical challenges exist for developers and analysts working with them.

What Are MRFs?

MRFs are machine-readable files, typically formatted in JSON, published by health insurers and third-party administrators on a monthly basis. They are required under the CMS Transparency in Coverage Final Rule¹.

There are five types of MRFs:

In-Network Rate Files: Negotiated prices for all covered services between payers and in-network providers².
Allowed Amount Files: Historical out-of-network reimbursements, including billed charges².
Prescription Drug Files: Required under the Consolidated Appropriations Act (CAA), not TiC. CMS has not finalized enforcement for this provision³.
Provider Reference Files: Optional components within in-network files that define provider groups separately to reduce duplication. These are included using the provider_references array in the CMS schema and must be self-contained⁴.
Table of Contents (TOC) Files: Informal, non-standard files created by some issuers to organize or group large data files. These are not defined or required by CMS and should not be confused with the mandatory index file⁵.

File Type	Schema Exists	Required
in-network-rates	Yes	Yes
allowed-amounts	Yes	Yes
prescription-drugs	Yes	No
provider-reference	Yes	No
table-of-contents	Yes	No
index	No	Yes

Hosting and Index Files

Insurers must publish these files at publicly accessible HTTPS URLs, with no login or paywall⁶. Alongside the data files, they must publish a JSON index file, which provides metadata about the files and links to download them⁷.

Example structure of an index file:

{
  "reporting_entity_name": "Example Health Plan",
  "reporting_entity_type": "health insurance issuer",
  "in_network_files": [
    {
      "description": "Negotiated rates for covered services",
      "location": "https://example.com/mrf/in-network-rates_2024-05-01.json.gz"
    }
  ]
}

CMS Schema and File Structure

CMS publishes a detailed schema and implementation guide on GitHub⁴. The structure of an in-network MRF is nested and consistent across payers. A simplified example looks like this:

{
  "billing_code": "99213",
  "billing_code_type": "CPT",
  "negotiated_rates": [
    {
      "provider_groups": [
        {
          "tin": { "type": "ein", "value": "123456789" },
          "npi": ["1234567890", "0987654321"]
        }
      ],
      "negotiated_prices": [
        {
          "negotiated_type": "negotiated",
          "negotiated_rate": 85.0
        }
      ]
    }
  ]
}

Key elements

billing_code / billing_code_type: Identifies the service using CPT, HCPCS, DRG, etc.⁸
provider_groups: Each includes a TIN and a list of NPIs⁹
negotiated_prices: Includes the rate, type, and optional expiration date

All of this is self-contained in the same file. There is no referencing of external entities or joins¹⁰.

File Publishing and Formats

Files are commonly published using .json.gz compression, though CMS does not require this—it is simply recommended for efficiency¹¹. Most major insurers follow this practice due to the size of in-network files, which can exceed 100 GB.

Files may also be split by issuers across multiple documents (e.g., part1, part2, etc.) to manage size. CMS does not enforce a naming convention or splitting policy⁵.

Technical Considerations

Working with MRFs at scale involves several engineering challenges:

Large file handling: Files often exceed tens of gigabytes
Deeply nested JSON: Parsing and flattening must follow CMS schemas exactly⁴
Optional fields: Variability between issuers is allowed within schema bounds
Schema validation: Required to confirm format, but downstream processing still requires robust error handling

CMS provides a validation tool on GitHub to support this process¹².

Conclusion

Machine-Readable Files are a cornerstone of U.S. healthcare price transparency policy. CMS provides a defined schema and implementation path, but in practice, working with these files requires thoughtful engineering and infrastructure.

Luckily, OmniRate can ingest, normalize, and validate these files across hundreds of insurers—enabling analytics and applications that depend on accurate pricing data.

Footnotes

45 CFR § 147.212 — Regulation mandating public disclosure of MRFs. ↩
Ibid. — Defines both in-network and allowed amount requirements. ↩ ↩²
CMS FAQ (2021) — Indicates delay in enforcement of CAA-related prescription drug file publication. ↩
Ibid. — JSON schema and README detail file structure and validation rules. ↩ ↩² ↩³
Real-world observation — CMS allows arbitrary file naming; there is no standard. ↩ ↩²
Federal Register: TiC Final Rule — Requires that files be public and unrestricted. ↩
CMSgov/price-transparency-guide — Schema includes required index.json structure. ↩
In-Network Schema — Defines billing_code and billing_code_type. ↩
Ibid. — provider_groups must include tin and npi. ↩
Ibid. — No external references or joins defined or allowed by schema. ↩
CMS Technical Clarification Q&A — Notes GZIP is allowed, not required. ↩
CMSgov/price-transparency-guide-validator — Tool for validating file compliance. ↩