Employee Benefits Compliance

Transparency in Coverage Rule Enforcement Started July 1, 2022 ~ Have You Posted Your Plan Network Rates on Your Public-facing Website?

ACA Reporting Forms

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:

  1. Negotiated rates for all items and services with in-network providers;
  2. Payments to and billed charges from out-of-network providers; and
  3. 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

FieldNameTypeDefinitionRequired
reporting_entity_nameEntity NameStringThe legal name of the entity publishing the machine-readable file.Yes
reporting_entity_typeEntity TypeStringThe 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_namePlan NameStringThe plan name and name of plan sponsor and/or insurance company.No
plan_id_typePlan Id TypeStringAllowed values: “EIN” and “HIOS”No
plan_idPlan IDStringThe 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_typeMarket TypeStringAllowed values: “group” and “individual”No
in_networkIn-Network Negotiated RatesArrayAn array of in-network object typesYes
provider_referencesProvider ReferencesArrayAn array of provider reference object types.No
last_updated_onLast Updated OnStringThe date in which the file was last updated. Date must be in an ISO 8601 format (i.e. YYYY-MM-DD)Yes
versionVersionStringThe version of the schema for the produced informationYes
Additional Notes Concerning plan_nameplan_id_typeplan_idplan_market_type

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.

FieldNameTypeDefinitionRequired
negotiation_arrangementNegotiation ArrangementStringAn indication as to whether a reimbursement arrangement other than a standard fee-for-service model applies. Allowed values: “ffs”, “bundle”, or “capitation”Yes
nameNameStringThis is name of the item/service that is offeredYes
billing_code_typeBilling Code TypeStringCommon billing code types. Please see a list of the currently allowed codes at the bottom of this document.Yes
billing_code_type_versionBilling Code Type VersionStringThere might be versions associated with the billing_code_type. For example, Medicare’s current (as of 5/24/21) MS-DRG version is 37.2Yes
billing_codeBilling CodeStringThe 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 valuesYes
descriptionDescriptionStringBrief description of the item/serviceYes
negotiated_ratesNegotiated RatesArrayThis is an array of negotiated rate details object typesYes
bundled_codesBundled CodesArrayThis is an array of bundle code objects. This array contains all the different codes in a bundle if bundle is selected for negotiation_arrangementNo
covered_servicesCovered ServiceArrayThis is an array of covered services objects. This array contains all the different codes in a capitation arrangement if capitation is selected for negotiation_arrangementNo

Bundle Code Object

FieldNameTypeDefinitionRequired
billing_code_typeBilling Code TypeStringCommon billing code types. Please see a list of the currently allowed codes at the bottom of this document.Yes
billing_code_type_versionBilling Code Type VersionStringThere might be versions associated with the billing_code_type. For example, Medicare’s current (as of 5/24/21) MS-DRG version is 37.2Yes
billing_codeBilling CodeStringThe 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 valuesYes
descriptionDescriptionStringBrief description of the item/serviceYes

Covered Services Object

FieldNameTypeDefinitionRequired
billing_code_typeBilling Code TypeStringCommon billing code types. Please see a list of the currently allowed codes at the bottom of this document.Yes
billing_code_type_versionBilling Code Type VersionStringThere might be versions associated with the billing_code_type. For example, Medicare’s current (as of 5/24/21) MS-DRG version is 37.2Yes
billing_codeBilling CodeStringThe 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 valuesYes
descriptionDescriptionStringBrief description of the item/serviceYes

Negotiated Rate Details Object

This type defines a negotiated rate object.

FieldNameTypeDefinitionRequired
negotiated_pricesNegotiated PricesArrayAn array of negotiated price objects defines information about the type of negotiated rate as well as the dollar amount of the negotiated rateYes
provider_groupsProvider GroupsArrayThe providers object defines information about the provider and their associated TIN related to the negotiated price.No
provider_referencesProvider ReferencesArrayAn array of provider_group_ids defined in the provider reference Object.No
Additional Notes Concerning provider_groupsprovider_references

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

FieldNameTypeDefinitionRequired
npiNPIArrayAn 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
tinTax Identification NumberObjectThe tax identifier object contains tax information on the place of businessYes

Tax Identifier Object

FieldNameTypeDefinitionRequired
typeTypeStringAllowed values: “ein” and “npi”.Yes
valueValueStringEither 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_ids in the negotiated rate object.

FieldNameTypeDefinitionRequired
provider_group_idProvider Group IdNumberThe unique, primary key for the associated provider_group objectYes
provider_groupsProvider GroupsArrayThe providers object defines information about the provider and their associated TIN related to the negotiated price.No
locationLocationStringA 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
Additional Notes Concerning provider_grouplocation

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.

FieldNameTypeDefinitionRequired
negotiated_typeNegotiated TypeStringThere 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_rateNegotiated RateNumberThe dollar or percentage amount based on the negotiation_typeYes
expiration_dateExpiration DateStringThe 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_codePlace of Service CodeAn array of two-digit stringsThe 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_classBilling ClassStringAllowed values: “professional”, “institutional”Yes
billing_code_modifierBilling Code ModifierArrayAn 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_informationAdditional InformationStringThe 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 the negotiated_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_codes, the custom value of CSTM-00 can be used to avoid listing all possible service codes.

Additional Notes Concerning billing_code_type

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_types 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 NameReporting ValueAdditional Information
Current Procedural TerminologyCPTAmerican Medical Association
National Drug CodeNDCFDA NDC Background
Healthcare Common Procedural Coding SystemHCPCSCMS HCPCS
Revenue CodeRCWhat is a revenue code
International Classification of DiseasesICDICD background
Medicare Severity Diagnosis Related GroupsMS-DRGCMS DRGs
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-DRGAHRQ documentation
Ambulatory Payment ClassificationsAPCAPC background information
Local Code ProcessingLOCAL
Enhanced Ambulatory Patient GroupingEAPGEAPG
Health Insurance Prospective Payment SystemHIPPSHIPPS
Current Dental TerminologyCDTCDT
Custom Code Type: AllCSTM-ALLThis is a custom coding type defined for the Transparency in Coverage rule. This value represents all possible coding types under the contractual arrangement
Additional Notes Concerning billing_code

The following are custom defined billing codes that can be applied to any billing_code_types:

Reporting ValueAdditional Information
CSTM-00Represents 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

FieldNameTypeDefinitionRequired
reporting_entity_nameEntity NameStringThe legal name of the entity publishing the machine-readable file.Yes
reporting_entity_typeEntity TypeStringThe 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_namePlan NameStringThe plan name and name of plan sponsor and/or insurance company.No
plan_id_typePlan Id TypeStringAllowed values: “EIN” and “HIOS”No
plan_idPlan IDStringThe 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_typeMarket TypeStringAllowed values: “group” and “individual”No
out_of_networkOut Of NetworkArrayAn array of out-of-network object typesYes
last_updated_onLast Updated OnStringThe date in which the file was last updated. Date must be in an ISO 8601 format (i.e. YYYY-MM-DD)Yes
versionVersionStringThe version of the schema for the produced informationYes
Additional Notes Concerning plan_nameplan_id_typeplan_idplan_market_type

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.

FieldNameTypeDefinitionRequired
nameNameStringThe 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_typeBilling Code TypeStringCommon billing code types. Please see a list of the currently allowed codes at the bottom of this document.Yes
billing_codeBilling CodeStringThe billing_code_type code for the item/serviceYes
billing_code_type_versionBilling Code Type VersionStringThere might be versions associated with the billing_code_type. For example, Medicare’s current (as of 5/24/21) MS-DRG version is 37.2Yes
descriptionDescriptionStringBrief 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 FDAYes
allowed_amountsRatesArrayAn array of allowed amounts objectsYes

Allowed Amounts Object

The allowed amounts object documents the entity or business and service code in where the service was provided out-of-network.

FieldNameTypeDefinitionRequired
tinTax Identification NumberObjectThe tax identifier object contains tax information on the place of businessYes
service_codePlace of Service CodeAn array of two-digit stringsThe 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_classBilling ClassStringAllowed values: “professional”, “institutional”Yes
paymentsPaymentsArrayAn array of out-of-network payments objectsYes

Tax Identifier Object

FieldNameTypeDefinitionRequired
typeTypeStringAllowed values: “ein” and “npi”.Yes
valueValueStringEither 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.

FieldNameTypeDefinitionRequired
allowed_amountAllowed AmountNumberThe 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_modifierBilling Code ModifierArrayAn 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
providersProvidersArrayAn array of provider objectsYes
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.

FieldNameTypeDefinitionRequired
billed_chargeBilled ChargeNumberThe total dollar amount charges for an item or service billed to a plan or issuer by an out-of-network provider.Yes
npiNational Provider IdentifierArrayAn array of provider identification numbers (NPI)Yes
Additional Notes Concerning billing_code_type

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 NameReporting ValueAdditional Information
Current Procedural TerminologyCPTAmerican Medical Association
National Drug CodeNDCFDA NDC Background
Healthcare Common Procedural Coding SystemHCPCSCMS HCPCS
Revenue CodeRCWhat is a revenue code
International Classification of DiseasesICDICD background
Medicare Severity Diagnosis Related GroupsMS-DRGCMS DRGs
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-DRGAHRQ documentation
Ambulatory Payment ClassificationsAPCAPC background information
Local ProcessingLOCAL
Enhanced Ambulatory Patient GroupingEAPGEAPG
Health Insurance Prospective Payment SystemHIPPSHIPPS
Current Dental TerminologyCDTCDT