Transparency in Coverage MRFs Explained

The federal Transparency in Coverage (TiC) rules require most non-grandfathered group health plans and health insurance issuers to publish pricing information in machine-readable files (MRFs). These disclosures make negotiated rates available for public analysis, but the files are designed for computers, not for someone opening a spreadsheet.¹

This guide covers payer and health-plan TiC files. Hospital Price Transparency files are a related but separate disclosure system with a different technical specification.

This article reflects schema version 2.0, which CMS says should be used for MRFs published in March 2026 and later.²

Which TiC files are required?

The current CMS implementation guide identifies two required public data files and one official organizational file:³

File	Status	What it contains
In-network rates	Required	Negotiated rates for covered items and services, associated provider groups, billing codes, and rate context
Out-of-network allowed amounts	Required	Historical billed charges and allowed amounts for out-of-network services, subject to the rule's reporting conditions
Table of contents	Optional in general; required for certain multi-plan file arrangements	Plan metadata and HTTPS locations for shared in-network or allowed-amount files

The TiC final rule also contemplated a prescription-drug file. Enforcement of that requirement remains deferred, and the Departments have not issued final guidance for its form and manner. It should not be presented as a currently published TiC file alongside the two enforced files.⁴

How the files are published

TiC files must be available over HTTPS in a non-proprietary, open format and without restrictions that impede reuse. Plans and issuers update them monthly and identify when the data was last updated.³

Single-plan files follow CMS naming conventions. When one publication arrangement covers multiple plans, an official table-of-contents file—often recognizable as an index file—maps those plans to the applicable data files. The table of contents is part of the CMS specification, not an informal payer convention.⁵

JSON is the format analysts encounter most often. Compression such as GZIP is common because the underlying files can be extremely large, but the disclosure still has to be usable as an open machine-readable format.

What changed with schema 2.0?

Starting February 2, 2026, the Departments began assessing compliance against schema 2.0. CMS says all March 2026 and later monthly publications should use version 2.0 until further notice.²

One important structural detail is how provider groups connect to rates:

1. The in-network file defines provider groups in a root-level provider_references array.
2. Each provider group receives a provider_group_id and contains its associated NPIs, TIN information, network name, and—when an EIN is disclosed—the business name required by schema 2.0.
3. Each negotiated-rate object points to one or more of those IDs through its own provider_references array.

That design avoids repeating the same provider group beside every rate. The current schema uses these references inside the in-network file; the older external provider-reference-file pattern is not the schema 2.0 structure.⁶

Simplified in-network example

The real schema supports more arrangements and fields, but this abbreviated example shows the relationship between a provider group and a negotiated rate. Code names, descriptions, and code-type fields are omitted:

{
  "reporting_entity_name": "Example Health Plan",
  "reporting_entity_type": "health insurance issuer",
  "last_updated_on": "2026-08-01",
  "version": "2.0.0",
  "provider_references": [
    {
      "provider_group_id": 1,
      "network_name": ["Example Network"],
      "provider_groups": [
        {
          "npi": [1234567890],
          "tin": {
            "type": "ein",
            "value": "12-3456789",
            "business_name": "Example Medical Group"
          }
        }
      ]
    }
  ],
  "in_network": [
    {
      "negotiation_arrangement": "ffs",
      "billing_code": "99213",
      "negotiated_rates": [
        {
          "provider_references": [1],
          "negotiated_prices": [
            {
              "negotiated_type": "negotiated",
              "negotiated_rate": 85.0,
              "expiration_date": "2026-12-31",
              "service_code": ["11"],
              "billing_class": "professional",
              "setting": "outpatient"
            }
          ]
        }
      ]
    }
  ]
}

The important relationship is the ID: the rate points to provider group 1, while the provider details are defined once near the root of the file.

What an in-network rate does—and does not—show

An in-network MRF can show a payer-published negotiated amount and the context supplied with it, such as:

• billing code and code type;
• negotiated-rate type;
• billing class and care setting;
• provider-group identifiers;
• network name; and
• expiration date or additional rate information when applicable.

A published negotiated-rate row is not a claim or remittance. By itself, it does not prove:

• what a payer actually paid for a particular patient encounter;
• whether the service was performed by the listed provider;
• whether every contract adjustment, bonus, carve-out, or billing rule is represented;
• whether a surprising value is commercially meaningful rather than a data-quality artifact; or
• whether a payment complied with a provider's contract.

Those questions require additional context, and some require claims or contract data that is not contained in an in-network MRF.

Why the data remains difficult to use

Publication solved access, not usability. Real-world processing still requires teams to handle:

• Large and fragmented files. One payer publication can point to many data files, each large enough to require streaming rather than loading into memory.
• Nested relationships. Rate records must be resolved against provider-reference IDs without losing payer, plan, network, code, and rate context.
• Monthly replacement. Each publication cycle has to be discovered, downloaded, validated, and tracked against its source.
• Schema changes. Pipelines built for version 1.0 need to understand version 2.0 fields and validation rules.
• Provider identity. NPIs and TINs identify entities, but useful organization names, affiliations, specialties, and locations often require careful enrichment.
• Messy source values. Public files can contain duplicates, implausible amounts, broad fee schedules, or rates tied to services a provider may never perform.

CMS provides a validator for checking schema conformance. The validator can identify structural problems, but CMS notes that it does not establish whether the disclosed data itself is accurate.⁷

Where OmniRate fits

OmniRate processes payer-published in-network disclosures, resolves their provider references, adds provider and billing-organization context, and makes the resulting rates searchable by code, payer, provider, plan, and market.

The goal is not to turn a disclosure into a claim. It is to preserve the source and its limitations while making the published rate evidence practical to inspect, compare, and export.

---

Sources

Footnotes

1. Transparency in Coverage final rule — Federal requirements for public in-network and out-of-network pricing disclosures. ↩

2. CMS Technical Clarifications, questions 38–40 — Schema 2.0 timing and current implementation clarifications. ↩ ↩²

3. CMS Transparency in Coverage technical implementation guide — Current file categories, publication requirements, update timing, and schemas. ↩ ↩²

4. FAQs about ACA and CAA Implementation Part 55 — Prescription-drug-file enforcement deferral. ↩

5. CMS table-of-contents schema — Official structure for multi-plan file arrangements. ↩

6. CMS in-network-rates schema — Schema 2.0 provider references and negotiated-rate structure. ↩

7. CMS schema validator — Validation tooling and its scope. ↩