DOCSEARCHbyAlgolia
Submit Docs

CMS Price Transparency Guide

repository·master·Indexed 19 days ago

https://github.com/cmsgov/price-transparency-guide

Technical specifications and documentation for machine-readable files required by the CMS Transparency in Coverage (TiC) rule. Includes schemas and naming conventions for In-Network Negotiated Rates, Out-Of-Network Allowed Amounts, and Table of Contents files, as well as guidance on using the CMS schema validator tool.

Tokens
9.9K
Snippets
13
Records
26
Agent score
66%

What's inside price-transparency-guide

  1. Understand Transparency in Coverage machine-readable file requirements

    master

    The Transparency in Coverage final rules require non-grandfathered group health plans and health insurance issuers to disclose pricing information via machine-readable files.

    Core Requirements:

    • Transport: Files must be available via HTTPS.
    • Format: Must be a non-proprietary, open standard format (e.g., JSON, XML, or YAML). Proprietary formats like PDF or XLS/XLSX are not compliant.
    • Discoverability: Files must be publicly accessible without restrictions. Web crawlers must not be blocked via robots.txt (e.g., no Disallow directive) or <meta name="robots" content="noindex, nofollow"> tags.
    • Data Types: Dates must use the ISO 8601 format (YYYY-MM-DD).
    • Update Frequency: Files must be updated monthly (approximately every 30 days) and must include the last_updated_on attribute.

  2. What is a Table of Contents File?

    master
    A Table of Contents File is used in Schema 2.0 to significantly decrease the file sizes of required machine-readable files. It is mandatory when multiple plans share negotiated rates across In-network files. The file maps associated plans to their specific in-network and allowed amount files, allowing multiple plans to point to a single shared data file instead of duplicating data.

  3. Identify the required and optional machine-readable files

    master

    There are two mandatory machine-readable files and one optional file used for optimization:

    1. In-Network Negotiated Rates (in-network-rates): Discloses in-network provider negotiated rates for all items and services.
    2. Out-Of-Network Allowed Amounts (allowed-amounts): Discloses billed and allowed amounts for out-of-network providers.
    3. Table of Contents (table-of-contents) [Optional]: Used to group multiple plans into a single implementation. It allows breaking out common negotiated rates into separate files to avoid data duplication across multiple In-Network files.

  4. Use Provider References to optimize files

    master

    To avoid repeating provider information, use the provider_references array at the root of the file.

    1. Define a Provider Reference Object in the root provider_references array. This object includes a unique integer provider_group_id, the network_name, and a provider_groups array (containing Providers Object details).
    2. In the In-Network Object -> negotiated_rates -> Negotiated Rate Details Object, reference the provider by including its provider_group_id in the provider_references array.

  5. Configure Tax Identifier (TIN) and NPI

    master

    The Tax Identifier Object identifies the business or provider.

    • type: Either ein or npi.
    • value: The IRS EIN or the 10-digit NPI.
    • business_name: Required only if type is ein.

    Handling NPIs and SSNs: To protect privacy, if a provider's Social Security Number is used as a TIN, substitute the provider's NPI instead. When type is npi, the value must be a valid 10-digit NPI (starting with 1-9).

    Handling missing NPIs: If a contract is only at the TIN level and NPIs are unavailable, report 0 in the npi array field (e.g., "npi": [0]). Do not use 0 as the tin.value.

  6. Schema for Out-Of-Network Allowed Amount Files

    master

    The Out-Of-Network Allowed Amount file schema defines the structure for reporting costs for services provided out-of-network. The file is composed of a root object containing entity metadata, an array of out_of_network objects (representing services), which in turn contain allowed_amounts objects (representing the business/service context), and finally payments objects (representing the actual financial data).

    {
  "reporting_entity_name": "Example Entity",
  "reporting_entity_type": "health insurance issuer",
  "out_of_network": [
    {
      "name": "Service Name",
      "billing_code_type": "CPT",
      "billing_code": "12345",
      "billing_code_type_version": "2024",
      "description": "Service description",
      "allowed_amounts": [
        {
          "tin": { "type": "ein", "value": "12-3456789" },
          "billing_class": "professional",
          "payments": [
            {
              "allowed_amount": 150.00,
              "providers": [
                { "billed_charge": 200.00, "npi": ["1234567890"] }
              ]
            }
          ]
        }
      ]
    }
  ],
  "last_updated_on": "2024-01-01",
  "version": "2.2.1"
}

  7. Follow file naming conventions for single or multiple plans

    master

    File names must use only alphanumeric characters. Spaces in payer or issuer names must be replaced with dashes (-). Other special characters must be removed or replaced with dashes.

    Single Plan Files

    Use the format: <YYYY-MM-DD>_<payer or issuer name>_<plan name>_<file type name>.<file extension>

    Examples:

    • 2020-01-05_cms_medicare_in-network-rates.json
    • 2020-01-05_issuer-abc_healthcare-100_allowed-amounts.json

    Multiple Plans Per File

    If grouping multiple plans, a table-of-contents file is required. The naming standard applies to the table-of-contents file, but the individual in-network and allowed-amounts files do not follow the standard naming convention.

    Use the format for the index file: <YYYY-MM-DD>_<payer or issuer name>_index.<file extension>

    Example:

    • 2020-01-05_cms_index.json
    # Single Plan Example
2020-01-05_issuer-abc_healthcare-100_in-network-rates.json

# Multiple Plans (Index) Example
2020-01-05_cms_index.json

  8. Validate machine-readable files with the Schema Validator Tool

    master

    CMS provides a downloadable schema validator tool to assess compliance with the Transparency in Coverage JSON schema.

    Capabilities:

    • Validates in-network-rates, allowed-amounts, and table-of-contents files.
    • Tests for required attributes (under version 1.0) and syntax errors.
    • Supports files of any size.

    Limitations:

    • Only supports JSON files.
    • It tests for schema compliance and syntax, but does not test the accuracy of the data within the schema.

  9. Example Table of Contents File

    master

    This example demonstrates how multiple plans can share the same in_network_files or allowed_amount_file to reduce redundancy. In this scenario:

    • Plan A, Plan B, and Plan C share in-network-file-1.json.
    • Plan C has a unique negotiated rate file BH-health-shared-0002.json.
    • Plan A and Plan C point to an empty allowed amounts file.
    • Plan B points to a populated allowed amounts file.
    {
  "reporting_entity_name":"...",
  "reporting_entity_type":"...",
  "reporting_structure":[
    {
      "reporting_plans":[{
          "plan_name":"Plan A",
          "plan_id_type":"hios",
          "plan_id":"0000000000",
          "issuer_name": "ACME Payer 1",
          "plan_market_type":"individual"
        },{
          "plan_name":"Plan B",
          "plan_id_type":"hios",
          "plan_id":"11111111111",
          "issuer_name": "ACME Payer 2",
          "plan_market_type":"individual"
        }],
      "in_network_files":[{
        "description":"in-network file",
        "location":"https://www.some_site.com/files/in-network-file-1.json"
      }]
    },{
      "reporting_plans":[{
          "plan_name":"Plan C",
          "plan_id_type":"hios",
          "plan_id":"222222222",
          "issuer_name": "ACME Payer 3",
          "plan_market_type":"individual"
        }],
      "in_network_files":[{
        "description":"in-network file primary",
        "location":"https://www.some_site.com/files/in-network-file-1.json"
      },
      {
        "description":"behavioral health shared file",
        "location":"https://www.some_site.com/files/BH-health-shared-0002.json"
      }],
      "allowed_amount_file":{
        "description": "allowed amount file",
        "location": "https://www.some_site.com/files/allowed-amounts-file-empty.json"
      }
    },{
      "reporting_plans":[
        {
          "plan_name":"Plan A",
          "plan_id_type":"hios",
          "plan_id":"0000000000",
          "issuer_name": "ACME Payer 1",
          "plan_market_type":"individual"
        }],
      "allowed_amount_file":{
        "description": "allowed amount file",
        "location": "https://www.some_site.com/files/allowed-amounts-file-empty.json"
      }
    },{
      "reporting_plans":[
        {
          "plan_name":"Plan B",
          "plan_id_type":"hios",
          "plan_id":"11111111111",
          "issuer_name": "ACME Payer 2",
          "plan_market_type":"individual"
        }],
      "allowed_amount_file":{
        "description": "allowed amount file",
        "location": "https://www.some_site.com/files/allowed-amounts-file-1.json"
      }
    }]
}

  10. Use Custom Billing Codes for Bulk Reporting

    master

    Two special custom values can be used to simplify reporting:

    1. billing_code = CSTM-00: Represents all possible billing_code values for the defined billing_code_type. Use this when a negotiated arrangement applies to all codes under a type.
    2. billing_code_type = CSTM-ALL: Used when you want to apply a negotiated price to all possible coding types defined in the schema. In this case, billing_code should also be set to CSTM-00.
    {
 "negotiation_arrangement": "ffs",
 "name": "All coding types",
 "billing_code_type": "CSTM-ALL",
 "billing_code_type_version": "2022",
 "billing_code": "CSTM-00",
 "description": "All codes possible",
 "negotiated_rates": [{
   "provider_references": [1],
   "negotiated_prices": [{
     "negotiated_type": "negotiated",
     "negotiated_rate": 12.45,
     "expiration_date": "2022-01-01",
     "service_code": ["18", "19", "11"],
     "billing_class": "institutional"
   }]
 }]
}

  11. Reference: Tax Identifier Object Fields

    master

    The tin (Tax Identifier Object) contains tax information on the place of business. When a provider's social security number is used as a TIN, it should be substituted with their NPI to protect privacy.

    | Field | Name | Type | Definition | Required |
| ----- | ---- | ---- | ---------- | -------- |
| **type** | Type | String | Allowed values: "ein" and "npi". | Yes |
| **value** | Value | String | Either the unique identification number issued by the Internal Revenue Service (IRS) for type "ein" or the provider's npi for type "npi". | Yes |

  12. Reference Allowed Billing Code Types

    master

    The following billing_code_type values are supported for reporting negotiated rates:

    Standard NameReporting Value
    Current Procedural TerminologyCPT
    National Drug CodeNDC
    Healthcare Common Procedural Coding SystemHCPCS
    Revenue CodeRC
    International Classification of DiseasesICD
    Medicare Severity Diagnosis Related GroupsMS-DRG
    Refined Diagnosis Related GroupsR-DRG
    Severity Diagnosis Related GroupsS-DRG
    All Patient, Severity-Adjusted Diagnosis Related GroupsAPS-DRG
    All Patient Diagnosis Related GroupsAP-DRG
    All Patient Refined Diagnosis Related GroupsAPR-DRG
    Ambulatory Payment ClassificationsAPC
    Local Code ProcessingLOCAL
    Enhanced Ambulatory Patient GroupingEAPG
    Health Insurance Prospective Payment SystemHIPPS
    Current Dental TerminologyCDT
    Custom Code Type: AllCSTM-ALL