CMS Transparency in Coverage: A Developer's Guide to Machine-Readable Files

The Transparency in Coverage (TiC) rule — 45 CFR Part 180 — requires every health insurer in the US commercial market to publish complete machine-readable files (MRFs) containing their negotiated rates for every in-network provider and every covered item or service. The data went live in July 2022, and it fundamentally changed what's possible in healthcare pricing analytics.

This guide explains what payers actually publish, what the data looks like, the practical problems with parsing it directly, and how to access it via API instead.

What Payers Are Required to Publish

Under 45 CFR § 180.50, health insurers must publish three categories of MRFs:

• In-network rates files — All negotiated rates with in-network providers, for every covered item or service. This is the primary rate dataset.
• Allowed amounts files (OON) — Historical allowed amounts for claims paid to out-of-network providers.
• Prescription drug files — Negotiated rates and historical net prices for covered prescription drugs (phased implementation).

The rule applies to all group health plans and health insurance issuers in the individual and group market — including self-insured employer plans administered by TPAs. Large payers like Cigna, Aetna, UHC, BCBS, and Humana each publish thousands of MRF files monthly across their networks.

The MRF File Format

TiC MRFs are published as JSON, following a schema defined by CMS. The top-level structure of an in-network file looks like this:

{
  "reporting_entity_name": "Cigna Health and Life Insurance",
  "reporting_entity_type": "health insurance issuer",
  "plan_name": "Cigna OAP",
  "plan_market_type": "group",
  "last_updated_on": "2025-01-01",
  "version": "1.0.0",
  "in_network": [...]
}

The in_network array contains one entry per billing code. Each entry lists the code, a description, and an array of negotiated_rates — one per provider group, with nested negotiated_prices objects containing the actual rate, rate type, and effective dates.

Why Parsing MRFs Directly Is Not Practical

The in-network files are technically valid JSON — but they are not designed for casual consumption. Several characteristics make direct parsing extremely challenging:

• File sizes. A single Cigna network MRF regularly exceeds 200 GB. UHC publishes files that reach into the terabytes. Standard JSON parsers fail on files of this size.
• Streaming-only parsing. Files must be read as streams, not loaded into memory. This requires custom streaming JSON parsers (e.g. ijson in Python, JsonStreamingReader in .NET).
• Index discovery. Payers publish a table-of-contents index file, not a single monolithic file. You must fetch the index, discover file URLs, and then fetch and parse each file — often hundreds of files per payer.
• Provider reference deduplication. Many MRFs use a provider_references section containing separate JSON files for provider data. You must dereference these to get NPI-level detail.
• Schema variation. Despite the published CMS schema, payer implementations vary significantly. Field names, nesting depth, and coding conventions differ across Cigna, Aetna, UHC, BCBS, and Humana. Robust parsers require payer-specific normalization logic.

MRF Index Files and How to Discover Rate Files

Every payer is required to publish an index file at a well-known URL listing all their MRF files. CMS maintains a public lookup table of these index URLs. For the major payers:

• Cigna: https://www.cigna.com/toc.json
• Aetna: https://health1.aetna.com/app/public/.../toc.json
• UnitedHealth: Multiple index files by reporting entity
• BCBS: Published per state plan, with a federated index
• Humana: https://developers.humana.com/Resource/DownloadFile/...

The index file contains an array of reporting_structure entries, each containing in_network_files and allowed_amount_files with URLs and descriptions. A single payer index commonly lists 2,000–10,000 individual files.

Rate Type Definitions

The CMS schema defines five rate types that can appear in negotiated_type:

• negotiated — Traditional contracted rate (most common)
• derived — Rate derived from another rate (e.g. percentage of a base rate)
• fee schedule — Rate is a reference to an external fee schedule
• per diem — Daily rate for facility services
• case rate — Bundled episode-of-care payment

For CPT-level benchmarking, filter on negotiated and fee schedule rate types. Case rates and per diem rates are not comparable to line-item CPT rates.

Accessing TiC Data via API

PayerBenchmark ingests, normalizes, and indexes all major payer MRFs monthly, then exposes the data via a structured REST API. This eliminates the infrastructure and parsing burden entirely.

GET https://api.payerbenchmark.com/v1/rates
  ?payer=Cigna
  &network_key=OAP
  &procedure_code=99213
  &npi=1234567890
  &rate_type=fee_for_service

The API returns normalized rate rows — one per NPI, per network, per billing code — regardless of how the underlying MRF structured the data. No streaming parsers required. No provider reference dereferencing. No payer-specific normalization logic.

OON Allowed Amount Files

The out-of-network allowed amount files contain a different data structure: historical claims data showing what the payer actually paid for OON services, rather than negotiated rates. Fields include:

• billed_charge — What the OON provider billed
• allowed_amount — What the payer allowed (typically lower)
• service_code — CPT or billing code
• place_of_service_code — Setting (office, outpatient, inpatient)
• npi — Provider NPI (when present)

OON allowed amounts are useful for benchmarking out-of-network reimbursement — particularly relevant for providers who see both in-network and OON patients, and for balance billing analysis.

Monthly Refresh Cycle and Data Staleness

CMS requires payers to publish updated MRFs on the first of each month. However, "updated" varies by payer: some publish a complete replacement file monthly, others publish incremental files, and some miss the deadline and publish mid-month.

PayerBenchmark monitors all payer index files continuously and triggers ingestion when new files appear. Rate rows in the API include expiration_date and last_updated fields so callers can identify the currency of each rate.