Executive Summary
The Departments of Treasury, Labor and Health and Human Services (“HHS”) (jointly “the Departments”) released final rules for Transparency in Coverage (“TiC”) (85 FR 72158) in October 2020 (officially published in November 2020), adding dramatic new disclosure requirements on health plans, insurers and hospitals.
Why Now? Originally effective January 1, 2022, regulators postponed enforcement for plan years between January and July 2022 until July 1, 2022. For plans years following July 2022, the effective date is the first day of the plan year.
What is Required? Specific to this article’s audience, TiC requires non-grandfathered group health plans and insurers in the individual and group plan markets to disclose certain coverage and pricing information:
- In-network negotiated rates, and
- Billed and out-of-network rates.
- Prescription in-network and historical net prices disclosure has been delayed awaiting further guidance.
How? Such disclosures must be made by posting Machine-Readable Files (“MRF”) on a public-facing internet website, free of charge and easy to locate. It must be furnished in “plain language” intended for the plans’ specific demographics, including literacy (provide in language of speaker). The language used must be concise and well-organized. The plan must update the information monthly, indicating the date of the update.
Deadlines: Various components of the TiC rule will become effective at different dates. See below for details.
Plans beginning on/after 1/1/2022 – In-network, out-of-network and prescription drug (“Rx”) rates must be available to the public through posting on website three files. Enforcement was delayed until July 1, 2022 for plan years January 1, 2022 – July 1, 2022.
First file: In-network provider negotiated rates for covered items and services (the “In-network Rate File”).
Second file: Historical payments to and billed charges from out-of-network providers (the “Allowed Amount File”).
Third file: In-network negotiated rates and historical net prices for covered prescription drugs (the “Prescription Drug File”)—this particular MRF requirement is delayed until further notice.
- Reporting to HHS for prescription coverage is mandated starting June 1, 2022 reporting deadline after the December 27, 2021 initial deadline saw deferred enforcement (interim final rule).
- Other reporting is due December 27, 2022. Each December 27th & June 1st require Rx reporting.
Plans beginning on/after 1/1/2023 – Provide personalized cost-sharing estimates for in & out of network services to plan participants (Advanced Explanation Of Benefits or “AEOB”) within 1 day for unscheduled procedures and three days prior to a procedure scheduled at least 10 days prior.
Plans beginning on/after 1/1/2023 – A list of 500 shoppable services must be available via the internet-based self-service tool for plan years beginning on or after Jan. 1, 2023.
Plans beginning on/after 1/1/2024 – list of the remainder of all items and services is required for plan years beginning on or after Jan. 1, 2024.
Who Must Comply?
The TiC disclosure requirements are applicable to group health plans and insurers that are required to comply with PHSA § 2715A, as added by the Affordable Care Act (“ACA”). Accordingly, these disclosure requirements apply to most traditional group health plans, including both insured and self-insured plans. However, the disclosure requirements do not apply to grandfathered plans, account-based plans (including separate Health Reimbursement Arrangements and health FSAs), excepted benefits, or short-term, limited-duration insurance, although they do apply to “grand-mothered” plans (plans in effect March 23, 2010 to 2014 but is not grandfathered are grand-mothered plans for the transitional period and are not fully ACA- compliant). What is considered grand-mothered may vary by state.
* Note that, the Consolidated Appropriations Act of 2021 (“CAA”), transparency provisions do not exclude grandfathered plans. CAA includes several key rules, including and ERISA fiduciary requirement to obtain service provider disclosures prior to the plan year (obtain from the service provider) and prescription drug reporting to the Departments (on hold awaiting additional guidance).
Can Another Party Post the Disclosure on Behalf of the Employer?
Employer plan sponsors may contract with their insurer or Third-Party Administrator (“TPA”) or other third party to provide the disclosure on their behalf. It is common that insurers create the files and either publish them on the plan’s behalf or minimally provide the files for the employer plan sponsor to post the files on their own public-facing website. Employers who do not have a public-facing website should talk to their insurers or TPA’s about posting on the insurer’s site.
Timing
Starting for plan years January 1 – July 1, 2022, the MRF must be posted on plan public facing websites, free of charge, Subsequent plan years will comply by the first day of their 2022 plan year. Plans and issuers must update the information required to be included in each Machine Readable Format (“MRF”) on a monthly basis to ensure it remains accurate and must clearly indicate the date the files were most recently updated.
Safe Harbors
On April 19, 2022, the Departments issued FAQs providing an enforcement safe harbor for in-network rates that are not expressed as a dollar amount:
- For contractual arrangements under which a plan or issuer agrees to pay an in-network provider a percentage of billed charges and is not able to assign a dollar amount to an item or service prior to a bill being generated, plans and issuers may report a percentage number in lieu of a dollar amount. Documentation specific to the format requirements for percentage-of-billed-charges arrangements can be found below and here.
- For situations in which alternative reimbursement arrangements are not supported by the schema, or in instances where the contractual arrangement requires the submission of additional information to describe the nature of the negotiated rate, plans and issuers may disclose in an open text field a description of the formula, variables, methodology or other information necessary to understand the arrangement. Documentation specific to the use of the open text field can be found below and here.
Content Elements for All MRFs
The following content elements are required to be included in the three MRFs:
- Name and identifier for each coverage option: Plans and issuers must include their Health Insurance Oversight System (HIOS) ID at the 14-digit product level. If the plan or issuer does not have a HIOS ID at the plan or product level, the plan or issuer must use the HIOS ID at the five-digit issuer level. If a plan or issuer does not have a HIOS ID, it must use its EIN.
- Billing codes: This includes a Current Procedural Terminology (CPT) code, a Healthcare Common Procedure Coding System (HCPCS) code, a Diagnosis Related Group (DRG), a National Drug Code (NDC) or another common payer identifier used by a plan or issuer (for example, a hospital revenue code). In the case of prescription drugs, plans may only use the NDC as the billing code type. Plain language descriptions of the billing codes must also be provided.
- In-network applicable amounts, out-of-network allowed amounts, or negotiated rates and historical net prices for prescription drugs: This will depend on the type of file (in-network amounts for the In-Network Rate File, allowed amounts and historical billed charges for the Allowed Amount File, or negotiated rates and historical net prices for the Prescription Drug File). For all MRFs, the specific pricing information within each file must be associated with the provider’s national provider identifier, tax identification number and a Place of Service Code, although the provider’s name is not required to be included. Historical payments must have a minimum of 20 entries to protect consumer privacy.
Schematics for the data format are illustrated in detail below. GitHub is the Departments’ house for technical implementation guidance.
How to Structure the Disclosures to the Public
The Departments, and Trump Administration who originally wrote into existence the new rules, intended the new disclosures to help to drive down healthcare costs and reduce disparities in healthcare by making public the costs for services and coverage available to others. The information that is required to be disclosed is discussed in detail below, including the specifics around how that data must be displayed.
Information Required to Be Disclosed
The TiC requirement mandates plans to make “accurate and timely disclosure” of the following information:
- Claims payment policies and practices;
- Periodic financial disclosures;
- Data on enrollment and disenrollment;
- Data on the number of claims denied;
- Data on rating practices;
- Information on cost-sharing and payments regarding any out-of-network coverage;
- Information on enrollee and participant rights under Title I of ACA; and
- Other information as determined appropriate by HHS.
Public disclosures must provide three machine readable files:
- Negotiated rates for all items and services with in-network providers;
- Payments to and billed charges from out-of-network providers; and
- Negotiated rates for prescription drugs furnished by in-network providers (currently on hold awaiting further rulemaking).
What if the Schema (see below) Does not Work with our billing practices and contracts with providers? Payers that have contracts with providers on a “percentage of billed charges” basis, the Departments will permit the payer to report the applicable percentage of billed charges as outlined in the contractual arrangement rather than an actual dollar amount. Payment arrangements based on a percentage of billed charges require the ultimate negotiated dollar payment amounts to be based on the specific gross charges (or charge master amounts) for each item or service rendered.
For payers that have other “alternative reimbursement arrangements” that are not supported by the schema provided in the Departments’ technical implementation guidance, there is an opportunity to describe the “formula, variables, methodology, or other information necessary to understand the arrangement” in an open text field in the file, in lieu of providing the actual dollar amounts.
The Final Rules outlined specific formatting requirements files must include. Those details are illustrated in detail below.
Where Should the MRF be Posted?
These files must be available on the plan sponsors/plans/insurers (or other third party pursuant to a written contract) website, free of charge and searchable. The files may not be buried in the public website posting for the plan/plan sponsors. Rather, easily located.
Duplication Elimination Rule
Where multiple plans have the exact same negotiated rates with the same group of providers for the same items and services, producers (typically, insurers, although it may be a TPA or self-funded plan) of the file have the option to group multiple plans together with the same negotiated rates or allowed amounts. Where plans are grouped together, a table of contents file is required in order to capture all the different plan data along with the URL location on where to download the appropriate files. Plans/insurers are permitted to build both in-network and allowed amount files for a single plan too.
Disclosure Format
The Final Rules require each MRF to use a nonproprietary, open format that will be identified in technical implementation guidance—for example, JavaScript Object Notation (JSON), Extensible Markup Language (XML) or Comma Separate Value(s) (CSV). A PDF file would not meet this definition due to its proprietary nature. (See below for full details on formatting).
A plan or issuer’s file will be acceptable so long as it:
- Includes all required data elements mandatory for the respective file (that is, all applicable rates in the In-network Rate File, allowed amounts and billed charges in the Allowed Amounts File, and negotiated rates and historical net process in the Prescription Drug File); and
- Is formatted in a manner consistent with technical implementation guidance.
File Specifications
Files disclosing the required information must follow specific formats.
- Only alphanumeric characters are allowed in the file name.
- No special characters.
- Use a dash (-) to replace special characters and spaces.
Conclusion
Plans with plan years January – July must comply by July 1st with the disclosure of two of the three MRF. Insured plan largely can rely on their insurers to provide the MRF and often the carrier will post it on their website for those plans. Self-funded plans may often be left to post the MRF even if they receive it from their insurer. In this case, the TPA may be available to post the MRF on the plans’ behalf. When relying on other entities to post these files on your behalf, it important that it is in writing. Otherwise, the insured plan is still liable for the posting and any non-compliance related to the posting. Self-funded plans, however, are never immune from liability, even if contracting with the TPA to post on their behalf.
These rules are complex and still developing. It is important you work with a consultant, like Leavitt Group, who can help guide you through the rules to ensure compliance.
Be sure you are subscribed to the Leavitt Group news alerts to stay on top of the latest news that may apply to your employee benefits plans.
Additional Guidance
Below you will find schematics for posting the MRF. See below if interested in the detailed schematics. You should be able to rely on what the insurer provides, but self-funded plans in particular may want to know if the MRF is set up accurately due to remaining liability even if the TPA will agree to post on their behalf.
Schematics
Single Plan Files
The following is the required naming standard for each file: <YYYY-MM-DD>_<payer or issuer name>_<plan name>_<file type name>.<file extension>
For example, the following would be the required naming for CMS building a JSON file:
2020-01-05_cms_medicare_in-network-rates.json
2020-01-05_cms_medicare_allowed-amounts.json
An example of a plan named healthcare 100
with an issuer’s name issuer abc
producing a JSON file, the following would be the naming output:
2020-01-05_issuer-abc_healthcare-100_in-network-rates.json
2020-01-05_issuer-abc_healthcare-100_allowed-amounts.json
Multiple Plans Per File
If multiple plans are to be included in a single file, a table-of-contents
file will be required. The naming standard will be applied to the table-of-contents
file and both the in-network
and allowed-amounts
files will not have any naming standards.
The following is the required naming standard for the table-of-contents
file: <YYYY-MM-DD>_<payer or issuer name>_index.<file extension>
For example, the following would be the required naming for the entity building a JSON file that includes Medicare and Medicaid plans:
2020-01-05_cms_index.json
Schema Validator Tool
The Centers for Medicare and Medicaid Services (“CMS”) developed a downloadable schema validator tool that plans and developers can use to assess whether their machine readable files are compliant with the Transparency in Coverage JSON schema. The validator tool and instructions can be accessed there. The tool can be used to validate in-network and allowed amount files, as well as provider references and table of contents files. Note that the tool tests for attributes required under version 1.0 of the JSON schema and for syntax errors but does not test the accuracy of the data in the schema. It is designed to run on local computers and can be used to validate files of any size (there is no file size limit). At this point in time, the validator tool can only be used to validate JSON files.
In-Network File Schematics
Field | Name | Type | Definition | Required |
---|---|---|---|---|
reporting_entity_name | Entity Name | String | The legal name of the entity publishing the machine-readable file. | Yes |
reporting_entity_type | Entity Type | String | The type of entity that is publishing the machine-readable file (a group health plan, health insurance issuer, or a third party with which the plan or issuer has contracted to provide the required information, such as a third-party administrator, a health care claims clearinghouse, or a health insurance issuer that has contracted with a group health plan sponsor). | Yes |
plan_name | Plan Name | String | The plan name and name of plan sponsor and/or insurance company. | No |
plan_id_type | Plan Id Type | String | Allowed values: “EIN” and “HIOS” | No |
plan_id | Plan ID | String | The 10-digit Health Insurance Oversight System (HIOS) identifier, or, if the 10-digit HIOS identifier is not available, the 5-digit HIOS identifier, or if no HIOS identifier is available, the Employer Identification Number (EIN)for each plan or coverage offered by a plan or issuer. | No |
plan_market_type | Market Type | String | Allowed values: “group” and “individual” | No |
in_network | In-Network Negotiated Rates | Array | An array of in-network object types | Yes |
provider_references | Provider References | Array | An array of provider reference object types. | No |
last_updated_on | Last Updated On | String | The date in which the file was last updated. Date must be in an ISO 8601 format (i.e. YYYY-MM-DD) | Yes |
version | Version | String | The version of the schema for the produced information | Yes |
plan_name
, plan_id_type
, plan_id
, plan_market_type
Additional Notes Concerning These attributes are not required for files that will be reporting multiple plans per file but ARE REQUIRED for single plans that are being reported that do not wish to create a table-of-content file. For payers/issuers that will be reporting multiple plans per file, these attributes will be required in a table-of-contents file.
In-Network Object
This type defines an in-network object.
Field | Name | Type | Definition | Required |
---|---|---|---|---|
negotiation_arrangement | Negotiation Arrangement | String | An indication as to whether a reimbursement arrangement other than a standard fee-for-service model applies. Allowed values: “ffs”, “bundle”, or “capitation” | Yes |
name | Name | String | This is name of the item/service that is offered | Yes |
billing_code_type | Billing Code Type | String | Common billing code types. Please see a list of the currently allowed codes at the bottom of this document. | Yes |
billing_code_type_version | Billing Code Type Version | String | There might be versions associated with the billing_code_type . For example, Medicare’s current (as of 5/24/21) MS-DRG version is 37.2 | Yes |
billing_code | Billing Code | String | The code used by a plan or issuer or its in-network providers to identify health care items or services for purposes of billing, adjudicating, and paying claims for a covered item or service. If a custom code is used for billing_code_type , please refer to custom billing code values | Yes |
description | Description | String | Brief description of the item/service | Yes |
negotiated_rates | Negotiated Rates | Array | This is an array of negotiated rate details object types | Yes |
bundled_codes | Bundled Codes | Array | This is an array of bundle code objects. This array contains all the different codes in a bundle if bundle is selected for negotiation_arrangement | No |
covered_services | Covered Service | Array | This is an array of covered services objects. This array contains all the different codes in a capitation arrangement if capitation is selected for negotiation_arrangement | No |
Bundle Code Object
Field | Name | Type | Definition | Required |
---|---|---|---|---|
billing_code_type | Billing Code Type | String | Common billing code types. Please see a list of the currently allowed codes at the bottom of this document. | Yes |
billing_code_type_version | Billing Code Type Version | String | There might be versions associated with the billing_code_type . For example, Medicare’s current (as of 5/24/21) MS-DRG version is 37.2 | Yes |
billing_code | Billing Code | String | The code used by a plan or issuer or its in-network providers to identify health care items or services for purposes of billing, adjudicating, and paying claims for a covered item or service. If a custom code is used for billing_code_type , please refer to custom billing code values | Yes |
description | Description | String | Brief description of the item/service | Yes |
Covered Services Object
Field | Name | Type | Definition | Required |
---|---|---|---|---|
billing_code_type | Billing Code Type | String | Common billing code types. Please see a list of the currently allowed codes at the bottom of this document. | Yes |
billing_code_type_version | Billing Code Type Version | String | There might be versions associated with the billing_code_type . For example, Medicare’s current (as of 5/24/21) MS-DRG version is 37.2 | Yes |
billing_code | Billing Code | String | The code used by a plan or issuer or its in-network providers to identify health care items or services for purposes of billing, adjudicating, and paying claims for a covered item or service. If a custom code is used for billing_code_type , please refer to custom billing code values | Yes |
description | Description | String | Brief description of the item/service | Yes |
Negotiated Rate Details Object
This type defines a negotiated rate object.
Field | Name | Type | Definition | Required |
---|---|---|---|---|
negotiated_prices | Negotiated Prices | Array | An array of negotiated price objects defines information about the type of negotiated rate as well as the dollar amount of the negotiated rate | Yes |
provider_groups | Provider Groups | Array | The providers object defines information about the provider and their associated TIN related to the negotiated price. | No |
provider_references | Provider References | Array | An array of provider_group_id s defined in the provider reference Object. | No |
provider_groups
, provider_references
Additional Notes Concerning Either a provider_groups
or provider_references
attribute will be required in the Negotiated Rate Object to map the provider network to the item/service that is being documented. The schema requirements can be found here.
Providers Object
Field | Name | Type | Definition | Required |
---|---|---|---|---|
npi | NPI | Array | An array of National Provider Identifiers (NPIs). The NPI array attribute can contain a mix of Type 1 and Type 2 NPIs, both of which must be provided, if available. In contractual arrangements with Type 2 NPIs where Type 1 NPIs are unknown or otherwise unavailable, only the Type 2 NPIs must be reported. | Yes |
tin | Tax Identification Number | Object | The tax identifier object contains tax information on the place of business | Yes |
Tax Identifier Object
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 |
Additional Notes
For most businesses reporting cases, a Tax Identification Number (“TIN”) is used to represent a business. There are situations where a provider’s social security number is still used as a TIN. In order to keep private personally identifiable information out of these files, substitute the provider’s National Provider Identifiers (“NPI”) number for the social security number. When a npi number is used, it is assumed that the provider would otherwise be reporting by their social security number.
In contractual arrangements that are only made at the TIN level, where NPIs are unknown or otherwise unavailable, the value “0” should be reported for the NPI field. In contractual arrangements where both the NPI and TIN are available, both are required to be disclosed.
Provider Reference Object
This type defines a provider reference object. This object is used in the provider_references
array found on the root object of the in-network schema. The Provider Group Id is a unique interger ID that is defined by the user to be referenced in the Negotiated Rate Details Object in the provider_references
array. An example of using provider references can be found in the definition of provider reference objects and then the usages of the provider_group_id
s in the negotiated rate object.
Field | Name | Type | Definition | Required |
---|---|---|---|---|
provider_group_id | Provider Group Id | Number | The unique, primary key for the associated provider_group object | Yes |
provider_groups | Provider Groups | Array | The providers object defines information about the provider and their associated TIN related to the negotiated price. | No |
location | Location | String | A fully qualified domain name on where the provider group data can be downloaded. The file must validate against the requirements found in the provider reference. Examples can be found here that would link to a valid provider reference file such as one found here. | No |
provider_group
, location
Additional Notes Concerning Either a provider_group
or location
attribute will be required in the Provider Reference Object.
Negotiated Price Object
The negotiated price object contains negotiated pricing information that the type of negotiation for the covered item or service.
Field | Name | Type | Definition | Required |
---|---|---|---|---|
negotiated_type | Negotiated Type | String | There are a few ways in which negotiated rates can happen. Allowed values: “negotiated”, “derived”, “fee schedule”, “percentage”, and “per diem”. See additional notes. | Yes |
negotiated_rate | Negotiated Rate | Number | The dollar or percentage amount based on the negotiation_type | Yes |
expiration_date | Expiration Date | String | The date in which the agreement for the negotiated_price based on the negotiated_type ends. Date must be in an ISO 8601 format (i.e. YYYY-MM-DD). See additional notes. | Yes |
service_code | Place of Service Code | An array of two-digit strings | The CMS-maintained two-digit code that is placed on a professional claim to indicate the setting in which a service was provided. When attribute of billing_class has the value of “professional”, service_code is required. | No |
billing_class | Billing Class | String | Allowed values: “professional”, “institutional” | Yes |
billing_code_modifier | Billing Code Modifier | Array | An array of strings. There are certain billing code types that allow for modifiers (e.g. The CPT coding type allows for modifiers). If a negotiated rate for a billing code type is dependent on a modifier for the reported item or service, then an additional negotiated price object should be included to represent the difference. | No |
additional_information | Additional Information | String | The additional information text field can be used to provide context for negotiated arrangements that do not fit the existing schema format. Please open a Github discussion to ask a question about your situation if you plan to use this attribute. | No |
Additional Notes
For negotiated_type
there are five allowable values: “negotiated”, “derived”, “fee schedule”, “percentage”, and “per diem”. The value are defined as:
negotiated
: If applicable, the negotiated rate, reflected as a dollar amount, for each covered item or service under the plan or coverage that the plan or issuer has contractually agreed to pay an in-network provider, except for prescription drugs that are subject to a fee-for-service reimbursement arrangement, which must be reported in the prescription drug machine-readable file. If the negotiated rate is subject to change based upon participant, beneficiary, or enrollee-specific characteristics, these dollar amounts should be reflected as the base negotiated rate applicable to the item or service prior to adjustments for participant, beneficiary, or enrollee-specific characteristics.derived
: If applicable, the price that a plan or issuer assigns to an item or service for the purpose of internal accounting, reconciliation with providers or submitting data in accordance with the requirements of 45 CFR 153.710(c).fee schedule
: If applicable, the rate for a covered item or service from a particular in-network provider, or providers that a group health plan or health insurance issuer uses to determine a participant’s, beneficiary’s, or enrollee’s cost-sharing liability for the item or service, when that rate is different from the negotiated rate.percentage
: If applicable, the negotiated percentage value for a covered item or service from a particular in-network provider for a percentage of billed charges arrangement. Note: percentage values entered into thenegotiated_rate
attribute are to be a whole number percentage of the negotiated arrangement (i.e., 40.5% should be entered as 40.5 and not .405).per diem
: If applicable, the per diem daily rate, reflected as a dollar amount, for each covered item or service under the plan or coverage that the plan or issuer has contractually agreed to pay an in-network provider.
For expiration_date
, there may be a situation when a contract arrangement is “evergreen“. For evergreen contracts that automatically renew on a date provided in the contract, the expiration date you include should be the day immediately before the day of the automatic renewal.
In situation where there is not an expiration date, the value 9999-12-31
would be entered.
For service_code
, if a negotiated rate for either “professional” or “institutional” billing_class
is the same for all service_code
s, the custom value of CSTM-00
can be used to avoid listing all possible service codes.
billing_code_type
Additional Notes Concerning Negotiated rates for items and services can come from a variety of billing code standards. The list of possible allowed values is in the following table with the name of the standard and the values representing that standard that would be expected if being reported on.
There are custom billing_code_type
s defined for the Transparency in Coverage rule. These coding types are prefixed with CTSM-
. These coding types are meant to help with generic reporting. The complete list can be found the in following table.
Standard Name | Reporting Value | Additional Information |
---|---|---|
Current Procedural Terminology | CPT | American Medical Association |
National Drug Code | NDC | FDA NDC Background |
Healthcare Common Procedural Coding System | HCPCS | CMS HCPCS |
Revenue Code | RC | What is a revenue code |
International Classification of Diseases | ICD | ICD background |
Medicare Severity Diagnosis Related Groups | MS-DRG | CMS DRGs |
Refined Diagnosis Related Groups | R-DRG | |
Severity Diagnosis Related Groups | S-DRG | |
All Patient, Severity-Adjusted Diagnosis Related Groups | APS-DRG | |
All Patient Diagnosis Related Groups | AP-DRG | |
All Patient Refined Diagnosis Related Groups | APR-DRG | AHRQ documentation |
Ambulatory Payment Classifications | APC | APC background information |
Local Code Processing | LOCAL | |
Enhanced Ambulatory Patient Grouping | EAPG | EAPG |
Health Insurance Prospective Payment System | HIPPS | HIPPS |
Current Dental Terminology | CDT | CDT |
Custom Code Type: All | CSTM-ALL | This is a custom coding type defined for the Transparency in Coverage rule. This value represents all possible coding types under the contractual arrangement |
billing_code
Additional Notes Concerning The following are custom defined billing codes that can be applied to any billing_code_type
s:
Reporting Value | Additional Information |
---|---|
CSTM-00 | Represents all possible billing_code values for the defined billing_code_type . Typically this can be used when a negotiated arrangement applies to all codes under a billing_code_type |
Out-Of-Network Allowed Amount File
Field | Name | Type | Definition | Required |
---|---|---|---|---|
reporting_entity_name | Entity Name | String | The legal name of the entity publishing the machine-readable file. | Yes |
reporting_entity_type | Entity Type | String | The type of entity that is publishing the machine-readable file (a group health plan, health insurance issuer, or a third party with which the plan or issuer has contracted to provide the required information, such as a third-party administrator, a health care claims clearinghouse, or a health insurance issuer that has contracted with a group health plan sponsor). | Yes |
plan_name | Plan Name | String | The plan name and name of plan sponsor and/or insurance company. | No |
plan_id_type | Plan Id Type | String | Allowed values: “EIN” and “HIOS” | No |
plan_id | Plan ID | String | The 10-digit Health Insurance Oversight System (HIOS) identifier, or, if the 10-digit HIOS identifier is not available, the 5-digit HIOS identifier, or if no HIOS identifier is available, the Employer Identification Number (EIN)for each plan or coverage offered by a plan or issuer. | No |
plan_market_type | Market Type | String | Allowed values: “group” and “individual” | No |
out_of_network | Out Of Network | Array | An array of out-of-network object types | Yes |
last_updated_on | Last Updated On | String | The date in which the file was last updated. Date must be in an ISO 8601 format (i.e. YYYY-MM-DD) | Yes |
version | Version | String | The version of the schema for the produced information | Yes |
plan_name
, plan_id_type
, plan_id
, plan_market_type
Additional Notes Concerning These attributes are not required for files that will be reporting multiple plans per file but ARE REQUIRED for single plans that are being reported that do not wish to create a table-of-content file. For payers/issuers that will be reporting multiple plans per file, these attributes will be required in a table-of-contents file.
Out-Of-Network Object
The out-of-network object contains information related to the service that was provided out-of-network.
Field | Name | Type | Definition | Required |
---|---|---|---|---|
name | Name | String | The name of each item or service for which the costs are payable, in whole or in part, under the terms of the plan or coverage. | Yes |
billing_code_type | Billing Code Type | String | Common billing code types. Please see a list of the currently allowed codes at the bottom of this document. | Yes |
billing_code | Billing Code | String | The billing_code_type code for the item/service | Yes |
billing_code_type_version | Billing Code Type Version | String | There might be versions associated with the billing_code_type . For example, Medicare’s current (as of 5/24/21) MS-DRG version is 37.2 | Yes |
description | Description | String | Brief description of the item or service. In the case of items and services that are associated with common billing codes (such as the HCPCS codes), the codes’ associated short text description may be provided. In the case of NDCs for prescription drugs, the plain language description must be the proprietary and nonproprietary names assigned to the NDC by the FDA | Yes |
allowed_amounts | Rates | Array | An array of allowed amounts objects | Yes |
Allowed Amounts Object
The allowed amounts object documents the entity or business and service code in where the service was provided out-of-network.
Field | Name | Type | Definition | Required |
---|---|---|---|---|
tin | Tax Identification Number | Object | The tax identifier object contains tax information on the place of business | Yes |
service_code | Place of Service Code | An array of two-digit strings | The CMS-maintained two-digit code that is placed on a professional claim to indicate the setting in which a service was provided. When attribute of billing_class has the value of “professional”, service_code is required. | No |
billing_class | Billing Class | String | Allowed values: “professional”, “institutional” | Yes |
payments | Payments | Array | An array of out-of-network payments objects | Yes |
Tax Identifier Object
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 |
Out-Of-Network Payment Object
The payment object documents the allowed amounts the plan has paid for the service that was provided out-of-network.
Field | Name | Type | Definition | Required |
---|---|---|---|---|
allowed_amount | Allowed Amount | Number | The allowed amount must be reported as the actual dollar amount the plan or issuer paid to the out-of-network provider for a particular covered item or service, plus the participant’s, beneficiary’s, or enrollee’s share of the cost. See additional notes. | Yes |
billing_code_modifier | Billing Code Modifier | Array | An array of strings. There are certain billing code types that allow for modifiers (e.g. The CPT coding type allows for modifiers). If a negotiated rate for a billing code type is dependent on a modifier for the reported item or service, then an additional negotiated price object should be included to represent the difference. | No |
providers | Providers | Array | An array of provider objects | Yes |
Additional Notes
The allowed_amount
is each unique allowed amount, reflected as a dollar amount, that a plan or issuer paid for a covered item or service furnished by an out-of-network provider during the 90-day time period that begins 180 days prior to the publication date of the machine-readable file. To protect patient privacy, a plan or issuer must not provide out-of-network allowed amount data for a particular provider and a particular item or service when compliance would require the plan or issuer to report out-of-network allowed amounts paid to a particular provider in connection with fewer than 20 different claims for payment. Issuers, service providers, or other parties with which the plan or issuer has contracted may aggregate out-of-network allowed amounts for more than one plan or insurance policy or contract. If information is aggregated, the 20 minimum claims threshold applies at the plan or issuer level.
Provider Object
The provider object defines the list of NPIs and their billed charges for the service provided out-of-network.
Field | Name | Type | Definition | Required |
---|---|---|---|---|
billed_charge | Billed Charge | Number | The total dollar amount charges for an item or service billed to a plan or issuer by an out-of-network provider. | Yes |
npi | National Provider Identifier | Array | An array of provider identification numbers (NPI) | Yes |
billing_code_type
Additional Notes Concerning Negotiated rates for items and services can come from a variety of billing code standards. The list of possible allowed values is in the following table with the name of the standard and the values representing that standard that would be expected if being reported on.
Standard Name | Reporting Value | Additional Information |
---|---|---|
Current Procedural Terminology | CPT | American Medical Association |
National Drug Code | NDC | FDA NDC Background |
Healthcare Common Procedural Coding System | HCPCS | CMS HCPCS |
Revenue Code | RC | What is a revenue code |
International Classification of Diseases | ICD | ICD background |
Medicare Severity Diagnosis Related Groups | MS-DRG | CMS DRGs |
Refined Diagnosis Related Groups | R-DRG | |
Severity Diagnosis Related Groups | S-DRG | |
All Patient, Severity-Adjusted Diagnosis Related Groups | APS-DRG | |
All Patient Diagnosis Related Groups | AP-DRG | |
All Patient Refined Diagnosis Related Groups | APR-DRG | AHRQ documentation |
Ambulatory Payment Classifications | APC | APC background information |
Local Processing | LOCAL | |
Enhanced Ambulatory Patient Grouping | EAPG | EAPG |
Health Insurance Prospective Payment System | HIPPS | HIPPS |
Current Dental Terminology | CDT | CDT |