Technical Clarification

Technical Clarification Questions and Answers

Answer #37: Under the Transparency in Coverage final rules at § 54.9815-2715A3(b)(3), § 2590.715-2715A3(b)(3), and § 147.212(b)(3), group health plans and health insurance issuers are required to update the machine-readable files monthly and must clearly indicate the date that the files were most recently updated. The Departments consider “monthly” to refer to reasonably consistent periods of approximately 30 days, but are not specifying a particular day of the month.

The Transparency in Coverage final rules do not include a retention requirement for the machine-readable files. However, the Departments recommend that group health plans and health insurance issuers maintain prior months’ machine-readable files to demonstrate compliance. The Departments also remind plans and issuers of their duty to comply with requirements under other applicable Federal laws, including requirements governing the accessibility, privacy, or security of information, or those governing the ability of properly authorized representatives to access participant, beneficiary, or enrollee information held by plans and issuers. States may have their own requirements related to record keeping and retention that would apply to certain health insurance plans and issuers, and plans and issuers subject to these state laws should consult state's requirements to ensure compliance.

Answer #36: If a group health plan does not have a public website, the plan may satisfy the requirements for posting the Allowed Amount file and the In-Network file by entering into a written agreement under which a service provider (such as a TPA) posts the Allowed Amount file and the In-network Rate file on its public website on behalf of the plan. However, if a plan enters into an agreement under which a service provider agrees to post the Allowed Amount file and the In-network Rate file on its public website on behalf of the plan, and the service provider fails to do so, the plan violates these disclosure requirements. The Departments intend to follow up with the issuance of formal guidance soon.

Answer #35: 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.

Answer #34: To allow for reporting of percentage-of-billed-charges arrangements, we have added "percentage" as an available negotiated type. For such arrangements, in the Negotiated Price Object, "percentage" should be entered as the negotiated_type, and the negotiated percentage value should be entered as the negotiated_rate (this value reflects the negotiated percentage value associated with a covered item or service from a particular in-network provider under a percentage-of-billed-charges arrangement). The percentage value entered as the negotiated_rate must be a whole number (for example, if a plan pays for a service at 37.5% of billed charges, it should enter 37.5 as the negotiated_rate, rather than .375).

We note that these reporting procedures only apply to percentage-of-billed-charges arrangements. If payment for an item or service is based on a percentage of a different rate that is known or determinable by the parties (e.g., a percentage of the Medicare reimbursement rate, see 85 FR 72228), the plan should enter the calculated dollar amount of the negotiated rate in the negotiated_rate field.

Further information regarding how to reflect percentage-of-billed-charges arrangements in the In-Network rate file can be found on GitHub here. You can find FAQs on this issue here.

Answer #33: To allow for reporting of per diem arrangements, we have added "per diem" as an available negotiated type. For such arrangements, in the Negotiated Price Object, "per diem" should be entered as the negotiated_type, and the negotiated per diem rate should be entered as the negotiated_rate (the per diem rate should be reflected as the dollar amount that the plan or issuer has contractually agreed to pay an in-network provider for each covered item or service under the plan or coverage). Further information regarding how to reflect per diem arrangements in the In-Network rate file can be found on GitHub here.

Answer #32: To accommodate these situations and help reduce file size, we have introduced two new custom code values that may be used – CSTM-ALL and CSTM-00. The value CSTM-ALL is a custom billing_code_type that can be used to represent all possible billing code types under the contractual arrangement. The value CSTM-00 is a custom billing_code that can be used to represent all possible billing codes for the defined billing_code_type. Typically, CSTM-00 can be used when a negotiated arrangement applies to all codes under a billing_code_type. For example, if the same payment rate or arrangement applies to all possible billing codes under a contract, a plan may enter CSTM-ALL as the billing_code_type and CSTM-00 as the billing_code. If the same payment rate or arrangement applies to all possible billing codes under a specific billing code type, such as HCPCS, then a plan may enter HCPCS as the billing_code_type and CSTM-00 as the billing_code. Note that the billing_code_type_version would be the current plan year. Further information regarding use of these custom codes can be found on the GitHub pull request as well as an example in the documentation.

Answer #31: Yes. CMS has added a new "additional_information" string (text) attribute to the Negotiated Price Object, which can be used to more fully describe the negotiated arrangement. The additional_information text field must be used to describe negotiated arrangements that are not supported by the current schema. This field has no character limitations. You may open a GitHub discussion to ask a question about your situation if you plan to use this attribute. The discussion may help CMS get a better idea of what scenarios require this attribute to fully communicate the applicable payment arrangement and may help inform future schema iterations. Further information regarding use of the additional_information text field can be found on GitHub here. You can find FAQs on this issue here.

Answer #30: 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 here. The tool can be used to validate In-Network rate 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 time, the validator tool can only be used to validate JSON files.

Answer #29: Yes. 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.

Answer #28: FHIR is a set of industry standards that allows for greater interoperability of data between systems. It also lowers the barrier of entry for new developers to get started leveraging data. At this time, the file is not FHIR compliant, but that may be considered for a future iteration of the schema.

Answer #27: Rather than include provider information directly in the in-network rate file itself, you may refer within the in-network rate file to provider networks defined in an external file to be associated with negotiated rates for items/services. The in-network rate file must include a URL linking to the external provider network file. This is an optional approach that allows plans to manage file size associated with incorporating large provider groups or networks, including large national networks that are managed by other companies.

In order to implement this optional approach, there are three required steps to keep in mind. First, you will need to define the location of the external provider file. Note that the schema documentation requires these external files to be served over https. Second, you will need to create a valid external provider file that that can be referenced. There is a new schema established for these external files, which can be found on the GitHub here with an example found here. Finally, a unique integer identifier needs to be assigned to each provider group or network referenced in the external file by the producers of the files. This reference ID must be used in the negotiated rate object of the in-network rate file and must be unique to the provider references array.

Documentation addressing external provider network reference files can be found here.

Answer #26: Yes. Multiple in-network rate files may be combined within a Table of Contents file. If you choose to use this approach, you will need to create a Table of Contents file that combines the in-network rate files and references the locations (URLs) from which the appropriate files can be downloaded. The external in-network rate files that are referenced in the Table of Contents file must be valid in-network rate files – meaning that they must comply with the in-network rate file schema. Documentation regarding the required schema can be found here. Documentation regarding the development of the Table of Contents file can be found here.

The naming standard for the Table of Contents file is [YYYY-MM-DD]_[payer or issuer name]_index.[file extension]. The individual in-network rate files linked to the Table of Contents file need not follow a defined naming convention. Additional file naming information can be found here.

Answer #25: Yes. If applicable, billing code modifiers may be included as an array within each file. In the out-of-network allowed amount file, billing code modifiers should be included in the allowed amounts object. In the in-network rate file, billing code modifiers should be included in the negotiated price object. Note that this is not a required field. However, if the inclusion of billing code modifiers helps with reporting your negotiated rates, you have the option of reporting such modifiers. Information and documentation regarding the use and reporting of billing code modifiers can be found here with an example implementation found here.

Answer #24: Yes. Large machine-readable files will benefit greatly from being compressed. This will not only help with storage considerations but also with network bandwidth. There are several common compression formats available, including .7z, .zip, .tar.gz, and .rar. No specific compression format is required. Additional information regarding file compression can be found here.

Answer #23: After you identify all unique out-of-network allowed amounts and associated billed charges for the relevant historical period, to address privacy concerns, you must then omit data related to a particular item or service (identified by billing code) where there are fewer than 20 different claims for payment associated with such item or service’s billing code. Note that if a claim includes a billing code modifier, the 20-claim threshold should be applied at the base billing code level, without taking into account the modifier.

Answer #22: You may report multiple plans together in a single file if the negotiated rates for all the items and service are exactly the same for all the providers across the different products. If you choose to report multiple plans in a single file, you must create a Table of Contents file (also known as an "index") that combines the plans and references the locations from which the appropriate files for the plans can be downloaded. The naming standard for the Table of Contents file is [YYYY-MM-DD]_[payer or issuer name]_index.[file extension]. The individual in-network rate and out-of-network allowed amount files linked to the Table of Contents file need not follow a defined naming convention. More information regarding the changes related to the Table of Contents file can be found here. Additional file naming documentation can be found here.

Note that for files that only represent a single plan, the naming standard will continue to be following: [YYYY-MM-DD]_[payer or issuer name]_[plan name]_[file type name].[file extension].

Answer #21: Yes. As an option, you may define the provider groups on the root object, assign each provider group an ID number, and reference the groups by ID number in the in-network rate file. This has the potential to reduce file size significantly. Additional information regarding the implementation of this option can be found here.

Answer #20: All machine-readable files must conform to a non-proprietary, open-standards format that is platform independent and made available to the public without restrictions that would impede the re-use of the information. Please refer to 85 FR 72242. Currently, the schemas on the GitHub are xml and json files, which are acceptable file formats. Microsoft Word, Microsoft Excel, and PDF files are proprietary and are not acceptable. Producers of the machine-readable files should consider the strengths and weaknesses of different file formats that meet the CMS requirements and select the appropriate one for their organization.

Answer #19: No. The Departments decline to require in regulation a more specific file format for the machine- readable files. Please refer to 85 FR 72242. CMS is providing schemas to support compliance with both. Producers of machine-readable files will need to discuss this with their developer teams and organization to decide which is optimal.

Answer #18: Schema 1.0 will be locked down by March 1, 2022. If discussions on GitHub are still active until March 1, 2022, CMS plans to move to schema 1.0 while allowing for continuation of development. This means there is a possibility for the schema to have a version 1.1, 1.2, etc. These would be the latest iterations developers can use to produce files, but files conforming to schema 1.0 would be considered compliant.

Answer #17: Version 1.0 will be set by March 1, 2022. The pace of version changes depends on the types of introductions and changes made to the schema based on discussions in GitHub. There have been active discussions on GitHub and CMS expects that to continue. Once major discussion points are addressed, it is expected that iteration on the schema will slow down.

Answer #16: CMS recognizes that negotiated rates may be unique depending on the company. Negotiated rates for professional claims have a service code associated with them. The service code attribute in the schema allows for the reporting of different negotiated rates based on that attribute’s value.

Negotiated rates for institutional claims may not have a CMS service code immediately associated with the service. The UB-04 claim form for institutional claims instead leverages a "type of bill" modifier. While this modifier is different than CMS service codes, much of the "type of bill" modifiers can be mapped to a service code. For example, a "type of bill" modifier of "111" can be mapped to a service code of "21". They both represent "Inpatient Hospital". There may be negotiated rates for services that are solely determined by institutional claims and "type of bill" modifiers would not be needed.

To allow for reporting of diverse negotiated rates, CMS added a contextual attribute called "billing_class" to the in-network schema to flag whether a negotiated rate is based on a professional or institutional claim. While professional claims will still use the "service_code" field, negotiated rates for institutional claims will not. This means that if negotiated rates for institutional claims are being reporting, the "service_code" attribute will be optional. If institutional "type of bill" modifiers can be mapped to service codes, then the "service_code" attribution should be used to distinguish various rates.

A Github discussion on including this flag can be found here.

Answer #15: While a plan or issuer with fewer than 20 claims for any of its allowed amounts is not required to report payment of OON allowed amounts, the file must still be produced.  Please refer to 45 C.F.R. § 147.212(b)(1)(ii)(C).  An example of what that would look like is here.  The information in the allowed amounts file will be minimal due to the lack of information to report.  However, the file needs to be created so that consumers of the file know that the plan does not have any claims that meet the 20- claim threshold.  If plans continue to not meet this threshold, the maintenance of these files will be minimal.

Answer #14: The defined schemas on GitHub are required. As noted above, machine-readable files must conform to a non-proprietary, open-standards format that is platform independent and made available to the public without restrictions that would impede the re-use of the information. Please refer to 85 FR 72242. The Departments decline to require in regulation a more specific file format for the machine-readable files and have indicated that technical implementation guidance will be provided through GitHub. Please refer to 85 FR 72241-72242. If a format other than json or xml is selected, that format must still adhere to the defined schema. The json schema can be used as a reference.

Answer #13: An SSN is considered protected personally identifiable information (PII). This information should not be reported in the machine-readable files. For situations where a provider uses their SSN as their TIN for both negotiated rates and claims adjudication, the provider’s national provider identifier (NPI) should be reported as the TIN in place of their SSN. CMS would also encourage providers using their SSN as their TIN to register for an employer ID number (EIN) from the IRS as soon as possible to avoid using protected PII in general.Implementation background and details can be found here on this Github discussion (#73).

Answer #12: CMS is leveraging GitHub to provide the required schema as well as implementation examples for all the machine-readable files.

File schema specifications can be found here: https://github.com/CMSgov/price-transparency-guide/tree/master/schemas. The user can click on either the allowed-amounts or in-network-rates to view the file's schema.

Examples for both the in-network and allowed-amounts can be found here: https://github.com/CMSgov/price-transparency-guide/tree/master/examples

Answer #11: Tracking the current version of the schema will be done through a process called "tagging". When changes are made and updates implemented to any schema, a new tag will be created and attached to the GitHub commit containing the new version number of the schema. You should be able to follow the current version here: https://github.com/CMSgov/price-transparency-guide/releases, and there is also a version.md file that tracks the current version. You can see all past tags and what updates they include here: https://github.com/CMSgov/price-transparency-guide/tags

Answer #10: We understand that payers may use a variety of billing code types to identify covered items and services for purposes of billing, adjudicating, and paying claims, and the regulations provide flexibility regarding the billing codes that may be reported. As specified in the regulations, a "billing code" could include the CPT code, HCPCS code, DRG code, NDC, "or other common payer identifier." Please refer to 45 CFR § 147.210. In addition, we note that when a covered item or service does not have a corresponding code, a plan or issuer is permitted to choose its “own indicator” or other method to communicate to the public that there is no corresponding code. Please refer to 85 FR 72223. The current list of possible allowed values for the billing code type is set forth in the table here. For billing code types that are not in this table, you may open a discussion on the GitHub to potentially add a new standard to the table. An update can be found on this commit: 55c96d0.

Answer #9: Yes. A plain language description of each billing code must be included in both the in-network rate and the out-of-network allowed amount files. An update on the GitHub can be found here.

Answer #8: If a negotiated rate is in effect at any time during the monthly reporting period, it needs to be reported in that month. For example, if the expiration date for a negotiated rate is 3/15 and the reporting period ends on 3/31, the negotiated rate must be included in the March file. The GitHub discussion can be found here.

Answer #7: The time zone is not required to be included in either file. In addition, the current date-only format (YYYY-MM-DD) used in each file does not accommodate this data. Because the data is refreshed monthly, we do not believe including a time zone is necessary for purposes of reporting the information required under the regulations.

Answer #6: If there is no defined expiration date for a negotiated rate, please enter 9999-12-31. Documentation can be found here. The updated commit can be found on the GitHub at: 3ca6650.

Answer #5: The reporting_entity_name field identifies the entity that created the file, not the entity hosting the file (which would most likely be the plan/issuer). Here are some examples below:

1. An insurance carrier, ABC Health, creates an in-network rate file and publishes it on the public website, ABCHealth.com. In this case, the reporting_entity_name should contain "ABC Health".
2. ABC Health has its claims processed by an external vendor, Claims R Us, and the vendor creates the in-network rate file for ABC Health to publish on its website, ABCHealth.com. The reporting_entity_name should contain "Claims R Us".
3. ABC Health is providing a self-funded group, ACME Manufacturing, an in-network rate file for the self-funded group to publish on its website, ACMEManufact.com. The reporting_entity_name should contain "ABC Health".

Answer #4: Plans may report together in a single file if the negotiated rates for all the items and service are exactly the same for all the providers across the different products. Full GitHub updates can be tracked here. An example of reporting multiple plans per file can be found here.

Answer #3: Yes. To address the issue you describe above, we have turned the service_code attribute into an array and moved it into the negotiated price object. You can find that implementation here ad66fa1. This should allow for the combining of negotiated rates across multiple locations. Documentation for the service_code can be found here.

Answer #2: Yes. The regulations require that the in-network rate file include all applicable rates associated with the National Provider Identifier (NPI), TIN, and Place of Service Code for each in-network provider. Please refer to 45 CFR 147.212(b)(1)(i)(C)(2). Similarly, the regulations require that the out-of-network allowed amount file include unique out-of-network allowed amounts associated with the NPI, TIN, and Place of Service Code for each out-of-network provider. Please refer to 45 CFR 147.212(b)(1)(ii)(C)(2).

Answer #1: Yes, this is possible. A full discussion can be found on GitHub with a specific implementation here.