cmsgov / price-transparency-guide

The technical implementation guide for the tri-departmental price transparency rule.

Transparency in Coverage

This is the technical implementation guide for the machine readable files as required by the Transparency in Coverage final rules (85 FR 72158).

If you are looking for the technical implementation guide for the machine readable files required by the Hospital Price Transparency final rules (45 CFR 180), please go to https://github.com/CMSgov/hospital-price-transparency.

Overview

This repository contains a set of schemas describing a data format (example implementations are encoded as JSON and XML) for the Transparency in Coverage final rule. 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 that information.

Consistent with the Departments’ August 20, 2021 guidance (see below “Guidance” section), the Departments have not promulgated any final guidance with respect to the form and manner for the Prescription Drug File.

Any material currently or previously published on this site with respect to the form and manner of the Prescription Drug File has been superseded and is not guidance of the Departments.

Background

The Departments of the Treasury, Labor, and Health and Human Services (the Departments) have issued the Transparency in Coverage final rules (85 FR 72158) on November 12, 2020. The final rules require non-grandfathered group health plans and health insurance issuers in the individual and group markets (plans and issuers) to disclose certain pricing information. Under the final rules a plan or issuer must disclose in-network negotiated rates, and billed and out-of-network allowed through two machine-readable files posted on an internet website.

Plans and issuers are required to make these files public for plan or policy years beginning on or after July 1, 2022.

Keeping Up To Date

Github allows for people to track and keep up-to-date with any changes for any repository. If you wish to follow and track the changes that happen on this repo, please leverage the "Watch" feature found at the top of the repository and select "All activity". This will email the user that has "watched" the specific repository.

Guidance

Transparency in Coverage rule guidance is released on CMS' website. You can find recently released guidance here:

• https://www.cms.gov/CCIIO/Resources/Fact-Sheets-and-FAQs#Affordable_Care_Act
• https://www.cms.gov/CCIIO/Resources/Fact-Sheets-and-FAQs/Downloads/FAQs-Part-49.pdf
• https://www.cms.gov/sites/default/files/2022-04/FAQ-Affordable-Care-Act-Implementation-Part-53.pdf
• https://www.cms.gov/files/document/faqs-about-affordable-care-act-implementation-part-61.pdf

Developer Documentation

Transport mechanism - HTTPS

All machine-readable files must be made available via HTTPS.

Content type - Non-Proprietary, Open Format

There are plenty of great formats to work with that will meet the needs for Transparency in Coverage:

• JSON
• XML
• YAML

Examples of proprietary formats that do not meet this definition would be:

• PDF
• XLS/XLSX

Public Discoverability

These machine-readable files must be made available to the public without restrictions that would impede the re-use of that information.

The location of the these URLs must be provided over HTTPS to ensure the integrity of the data.

Robots.txt

To allow for search engine discoverability, neither a robots.txt file nor meta tag on the page where the files are hosted will have rules such that give instructions to web crawlers to not index the page.

This is typically follows the format of <meta name="robots" content="noindex, nofollow"> or for a robots.txt file using the Disallow directive.

Special Data Types

Dates should be strings in ISO 8601 format (i.e. YYYY-MM-DD).

Different Machine-Readable Files

There are two required machine-readable files associated with Transparency in Coverage:

• In-Network Negotiated Rates
• Out-Of-Network Allowed Amounts

In-Network Negotiated Rates File Under the finalized rules, a plan or issuer must disclose in-network provider negotiated rates for all items and services through a machine-readable file.

Out-Of-Network Allowed Amounts File Under the finalized rules, a plan or issuer must disclose certain data elements to the public, including the billed and allowed amounts for out-of-network providers, through a machine-readable file.

The associated names for those files are:

• in-network-rates
• allowed-amounts

There are also two optional machine-readable files that can be leveraged to significantly decrease file sizes of the required machine-readable files:

• Table of Contents
• Provider Reference

Table of Contents File The Table of Contents file can be leveraged to combine common negotiated rates across multiple in-network files. By breaking out common negotiated rates into separate files to use in multiple In-Network files, plans can avoid having to duplicate data.

Provider Reference Defining provider networks outside of the In-Network file can have significant benefits in the overall file size that is produced. The provider reference file allows the user to define common provider networks externally to the In-Network file that can be referenced from within the In-Network file. This allows large provider networks to be defined once and be used in multiple locations.

Timing Updates For Machine-Readable Files

According to the TiC Final Rules and the schema requirements, plans and issuers are required to update the machine-readable files monthly and populate the attribute last_updated_on. The Departments consider “monthly” to refer to reasonably consistent periods of approximately 30 days, but are not specifying a particular day of the month.

File Naming Convention

There are scenarios where multiple plans have exactly the same negotiated rates with the same group of providers for the same items and services. This would lead to a large duplication of reporting. Also, there are plans that will be unique in their negotiated rates that would require a separate file.

The producers of the files have the option to group multiple plans together with the same negotiated data (or allowed amounts). If plans are to be grouped together, a table-of-contents file will be required to capture all the different plan data along with a URL location on where to download the appropriate files.

Payer/Issuers are still allowed to build both in-network and allowed-amount files for a single plan. The naming conventions will be different for each.

For payer or issuer's names that have spaces, those spaces would be replaced with dashes -

Only alphanumeric characters are allowed in the file name. No special characters such as ' are allowed. Special characters are either to be removed completely or replaced with -.

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 CMS building a JSON file that includes Medicare and Medicaid plans:

• 2020-01-05_cms_index.json

Schema Validator Tool

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 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.

Schemas

• In-Network Rates
• Allowed Amounts
• Table of Contents
• Provider Reference

Examples

• Implementation Examples

Getting Involved

The healthcare ecosystem is complex with what seems like an infinite amount of plan and issuer implementations. There are no doubt going to be questions for these various situations and the requirements found in the Transparency in Coverage rule. Currently, there are two ways in which the community can get involved:

• Github Issues - Where people discuss issues related to the project.
• Github Discussions - Use these channels for conversational topics (for example, "How do I…" or "What do you think about…" instead of bug reports or feature requests).

Before posting a comment, issue, or question, please search through existing discussions and issues. There is a good chance that the topic in questions is already being discussed.

Versioning

With any type software development, progression happens through bug fixes, new content, or changing requirements. The technical development of this schema is no different. CMS will be following the standard versioning found in many software development projects with including a major, minor, and patch number to represent the current version of the schema. The following is the guiding principles for version updates:

MAJOR version when incompatible changes are introduced, MINOR version when attributes/values are introduced or removed in a backwards compatible manner, and PATCH version when backwards compatible bug fixes are introduced.

The major version will be finalized to 1.0.0 for the schema to adhere to the July 2022 implementation date. Versioning of the schema can be tracked in the VERSION.md file.

price-transparency-guide's Issues

OON allowed amounts example does not match schema definition

Schema for OON Allowed Amounts says tin is a string: "tin": { "type": "string" },
But in your examples, you have a number (integer) value:
"allowed_amounts": [
{
"tin": 1234567890,

Use of ISO8601

You use the date-only format for ISO8601.

When not paired with a timezone, this is explicitly GMT, and is likely to lead to a lot of off-by-one errors, where some hospitals use the 1/3 day shift in date, and others do not.

It would be best to include a timezone.

Sample format for pharmacy claims information

Can you please provide an example JSON format for the in-network schema that is for pharmacy claims information? We are a PBM, and the JSON samples provided so far seem to apply more for medical procedures and not for prescription drug claims.

negotiated_rates -> service_code should not be a required field

In-network file: As the place of service code is a required field only for the professional claim type, this field should be considered a conditionally required field instead of a required field. OR please specify a default value that needs to be used for the institutional claims (ex: 99?).

Allowed_Amounts file: Same applies here too.

Question about Employer as a Payer

Hello - Does a self-funded Employer need to provide this information if all their health plans are meeting this requirement?

For example: does Employer A need to make the machine readable files if their administrator Health Plan A makes the files?

Perhaps this can be clarified within the README.
Thank you

What reimbursement information should be provided in the in-network rate file when capitated payments are made to medical groups?

To elaborate- when a plan makes capitated (PMPM) payments to a medical group, who then distributes these payments to their contracted individual providers based on the medical group's internal methodology, what information should be reported in the in-network rate file?

The final rule does state the following with respect to the self-service tool:
"...one commenter stated that issuers do not always have access to the negotiated rates or internal payment methodologies utilized by capitated medical groups or other providers and would not be able to reliably provide cost transparency based on a negotiated rate at the service level. "

The Final Rule goes on to say in the next paragraph:
"The Departments acknowledge that it is possible that some plans and issuers using alternative reimbursement models may not have negotiated rates or underlying fee schedule rates to disclose in the internet-based self-service tool. However, the numbers of plans and issuers without negotiated rates or underlying fee schedule rates is limited and the Departments are of
the view that an exemption for such arrangements is not necessary. Additionally, the Departments are of the view that providing an exemption for such arrangements will result in incomplete data sets. As stated in the final rules, the in-network rate must be disclosed, as applicable to the plan’s or issuer’s payment model. If the plan or issuer does not have negotiated
rates or underlying fee schedule rates, the third content element does not apply."

However, nothing specific is ever stated about capitated medical group reimbursement arrangements with respect to the in-network rate file. Does all this mean that providers paid via a capitated medical group are not considered to have a "negotiated rate", and that the plan would need to instead report a derived amount, if applicable?

Additionally, when a provider has multiple contracts with an issuer through multiple medical groups, how should this be handled?

Using Custom Billing Code for all codes not listed (all remaining codes = CTSM-RM)

Discussed in #419

^{Originally posted by kgosserand March 24, 2022}
We have contractual arrangements where a handful of codes will price with a certain percentage of charge, while other types of codes will price with different percentages of charge. We would like to use the CSTM-00 reporting type to report the remaining sets of code types outside of this handful of codes. For Example: Provider A has X% of charges for 10 J-codes and Y% of charges for all other CPT/HCPCS codes. We would like to individually report the rate (X%) for the 10 J-codes and report Y% for “all other” CPT/HCPCS codes using the CSTM billing code.
When using the CSTM-00 reporting type, can we set the text of the negotiated_price object's "description" attribute to further clarify that the set of codes the percentage of charge applies to is the all possible codes for the specified code type not already listed in the file?

{
"negotiation_arrangement": "ffs",
"name": "CPT Codes",
"billing_code_type": "CPT",
"billing_code": "CSTM-00",
"description": "All CPT codes not otherwise specified in this file",
"negotiated_rates": [{
"provider_groups": [{
"npi": [6666666666],
"tin":{
"type": "npi",
"value": "6666666666"}
}],
"negotiated_prices": [{
"negotiated_type": "percentage",
"negotiated_rate": Y,
"expiration_date": "2022-01-01",
"service_code": ["18", "19", "11"],
"billing_class": "institutional"}]

SSNs

Plans are having trouble determining how to proceed with the requirement to disclose providers TINs in the machine-readable files, given that so many providers use their personal social security numbers as TINs. Guidance from CMS on how to handle this issue would be welcome.

20 different claims?

I would like to know for the Allowed Amts schema the guidance is for 20 or more Claims to "protect patient privacy", there is a situation that there could be Multiple Claims for the same person for the 90 day period.

How will that protect privacy!

In-Network Object Fields: Billing Code Elements

Is it correct to interpret that, if the 4 fields below are populated (appearing under the "In-Network" object), then the same set of these fields appearing under the 'Bundle Code object' and 'Covered Services Object" can be left 'blank'?

If interpretation above is not true/correct, can CMS/GitHub provide guidance/illustration on what cases can co-exist.

If interpretation above is true/correct, can Plans further interpret that for every 'Provider rate record', only 1 out of the 3 sets (of these 4 fields) would be populated while the other 2 would be 'blank'?

"Description" Data Element for In-Network Negotiated Rates

For information being reported on the in-network negotiated rates for all items and services, specifically the “Description” data element located under the In-Network Object, please confirm whether this field is indeed 'Optional' as currently defined in the technical guidance or does CMS expect it to be populated whenever information is available in IT systems/database?

Similarly, is it correct to interpret that the 'Billing Code’ under the In-Network Object is intended to mean the Billing Code Description' for this field?

Bundle Example for JSON Display for DRG Claim

Can CMS/GitHub include a bundle example on how a JSON display works for a DRG claim?

Introducing FROM and THRU range ( When applicable ) for billing_codes in-network-rates

Discussed in #405

^{Originally posted by iGokul-G March 1, 2022}
Introducing a "FROM" and "THRU" range for billing_code might help reduce the record count only when applicable. Payers do use code ranges to represent services

Provide examples of xml formats

In Network Object Billing Code Schema Issue

The in-network file schema for the in_network object indicates the billing_code_type & billing_code_type_version are required (billing_code is missing as a required element which appears inconsistent). The covered_services object also indicates the billing_code_type, billing_code_type_version and billing_code are required. However, the capitation example provided did not include the billing_code_type, billing_code_type_version or billing_code fields in the in_network object. The billing_code_type, billing_code_type_version and biling_code were included in the covered_services object.

The billing_code_type, billing_code_type_version and billing_code appear to be optional fields on the in-network object and required in the covered_services object when the negotiation_arrangement is capitation.

The schema needs to be updated to reflect where the billing_code_type, billing_code_type_version and billing_code are required for the capitation negotiation_arrangement?

Machine Readable Prescription Drug File Negotiated Price Question

What negotiated price should be reported if there are multiple negotiated rates that apply under a given HIOS ID/EIN, Plan ID, Pharmacy, Drug?

Allowed Amounts File different allowed amounts different services and POS types

We have been reviewing our outputs for the allowed amounts file and ran into a scenario of where we have the same service code that pays different allowed amounts depending on the place of service code. IE V2103 for POS 11 allowed amount is $0 and $60 for POS type 12. Would it be correct to list two separate allowed amount objects with POS type 11 in allowed amount object one and POS type 12 in allowed amounts object two.

Or can we list multiple POS types in the same allowed amount object to correlate to multiple payment objects like in this example below?

8 Digit NDC Issue

The prescription drug schema indicates that NDC reporting for prescription drugs should be done at the 8 digit level as the last two digits of an NDC are for package size/quantity. In looking into this further, for example, NDC 000740124 for Humira. The first 8 digits of the NDC are the same for Humira Pen Peds, Humira Pen Kit, Humira Pen 80/0.8ml, Humira Pen Kit CD/UC/HS. While each product has the same first 8 digits, the prices differ between the products. How do we determine which drug to select when each NDC is slightly different in price at the 10 digit level?

Another example is Cosentyx. The NDC 000780639 is used for both the 300 dose pen, 150 mg/ml pen, the 150 mg/ml pen, and the 300 dose. The price differs significantly depending on which full 10 digit NDC is used.

How do we convert an 10 or 11 digit NDC to 8 digits? When an NDC is in the 5-4-2 format (ID Format Code 6 on the Medispan File), we would be dropping the last digit of the product code. Moreover, how do we convert an 11 digit NDC to 8 digits where the ID Type Code is 1 and the ID Format Code is 1, 2, 3, or 6?

Error in copy under “Public Discoverability”

“These machine-readable files post made available to the public without restrictions that would impede the re-use of that information.”

“Post” should be “must.” Thank you for issuing such precise instructions for disclosure!

site discoverability/web crawlers/bots

The Git page provides the following info:
_Public Discoverability
These machine-readable files must be made available to the public without restrictions that would impede the re-use of that information.

The location of the these URLs must be provided over HTTPS to ensure the integrity of the data.

Robots.txt
To allow for search engine discoverability, neither a robots.txt file nor meta tag on the page where the files are hosted will have rules such that give instructions to web crawlers to not index the page.

This is typically follows the format of or for a robots.txt file using the Disallow directive._

Question/Clarification:

The above information relates specifically to search engine discoverability, but does this mean that "all" web crawlers, bots, etc. should be allowed to access the site & its relevant data without any impediments? Are there any cases where such external agents should not be allowed>

Formatting "Plan Name" Naming Convention for Multiple Plan Names

Is ‘Plan Name’ required as part of the MRF naming convention given the recent change allowing a MRF submission for multiple plan names? Could CMS/Github provide an example of how multiple plan names would be formatted?

Different rates by location such as State or Zip Code

We are a regional PPO network located in the Kansas City metro. Some of our provider contracts have different rates for a given Tax Id based on where services are performed usually separated by State (KS or MO) or Zip Code. The zip code grouping uses regex to denote the zip codes such as:
66006-66025-6604[45679]-66050-6640[29]-66420-6653[39]-6654[26]-6660[13456789]-6661[012456789]-6662[012456]-66636-66647-66667-66675-66683-66699
I don't see anything in the in-network-rates schema that would allow us to denote that a specific rate was for a State or a Zip code and identify what the state(s) or zip code(s) are the rate applies to.
Anyone have any ideas other than putting something in the In-Network Object description or adding fields to the Negotiated Rate Details object.

Use of the Extensible Business Reporting Language (XBRL) For Machine Readable formats

While the guide proposes non-proprietary, open formats for the required machine readable file, CMS has not mandated specifically what syntax should be used or the specific semantics of what is actually provided. At present, this appears to result in over 6000 hospitals posting files without a mandatory syntactic or semantic framework. It recommend that CMS adopt a semantic, financial reporting model and mandate the use of XBRL.

XBRL is the international standard for digital reporting of financial, performance, risk and compliance information, although it is also used for many other types of reporting. The open XBRL specifications are freely licensed to anyone seeking to use the standard. XBRL provides a way to:

• define unambiguous, reusable definitions
• report individual facts against those definitions
• where necessary (and permitted) extend those definitions to take account of unique reporting ideas or aggregations
• test the resulting report against the constraints set out in the definitions
• file or publish the finished report
• consume entire reports or individual facts as needed

Worldwide, data standards are gaining traction for reporting by public and private companies, as well as government entities. As noted by XBRL International, , more than 150 digital reporting mandates exist across more than 70 countries, requiring digital reporting using XBRL by more than 10 million entities, including private and public companies, and governments. In the U.S.,
entities reporting to the Securities and Exchange Commission (SEC), the Federal Deposit Insurance Corporation (FDIC), and the Federal Energy Regulatory Commission (FERC) are all required to submit data in XBRL format.

A preliminary working prototype is available for review here: http://xbrlsite.azurewebsites.net/2021/cma/

Price Transparency Guidance Question

Will a separate repository be created to further develop and establish similar conventions for the Hospital Price Transparency machine-readable file requirements?

Mixed Bundles

Discussed in #458

^{Originally posted by narenlulla May 1, 2022}
The bundled code spec seems to assume only a single type of code will be bundled. We have rates where DRGs and Revenue codes are part of a bundle, and other rates where Revenue Codes and CPT codes are part of a bundle.

These bundles have a price a price when any of listed DRGs are billed with any of listed Revenue Codes for first example. and any listed Revenue Codes bill with any CPT codes in the second example

The Billing Code Type, Version and Billing Code are mandatory fields in the in-network object and the bundled code object, the in-network object values should be allowed to be null if there is a bundled arrangement, so it should be conditional not mandatory.

Medically Benefitted Drugs

Are Medically Benefitted Drugs to be included in our IN Network rate file or Prescription Drug file? We do not pay by or store NDC for these drugs, we utilize CPT/HCPC on a fee schedule.

Schema is missing newly added billing code types

How to differentiate capitated amounts for services based on factors like age, geo location, and other factors?

Hello,
On the capitated in network file there

capitation id (or description): Office services
Provider 1: $40
provider 2: $60

What happens if the office services are more like:

capitation id (or description): Office services for < 18 years old for Jacksonville
Provider 1: $40
provider 2: $60

capitation id (or description): Office services for < 18 years old for NY
Provider 1: $400
provider 2: $600

Questions:

1. is this acceptable?
2. is the amount per member per month of capitation?

Appreciate it
Satya

If negotiated rate is based on percentage of charge--then how would this be reported in the in-network file?

Discussed in #23

^{Originally posted by tdfow March 23, 2021}
Since the rate must be published in a dollar amount, how should items/services be represented in the in-network file if based on the percentage of charge? Would the negotiation type be 'derived'? How would you report the negotiated rate in the file, since it varies on charge for the item/service? Or do these items/services get reported?

Incorrect required fields on in-network-rates.json and in-network-rates.xml

Couple of small corrections required.

On the Json schema it should be:
"required": ["negotiation_arrangement", "name", "billing_code_type", "billing_code_type_version", "negotiated_rates" ]
instead of
"required": ["payment_type", "name" ]

On the XML schema it should be:
negotiation_arrangement
instead of
payment_type

Negotiated Rate based on CMS Inpatient Psychiatric Facility PPS : Per-Diem + DRG + Comorbidities + Age + Length of Stay Adjustment

The In-Network Schema does not support (an upcoming commercial adaptation of) the CMS Inpatient Psychiatric Facility PPS.

For reference see this document
A hybrid DRG/Per-Diem rate is multiplied by a "DRG Adjustment", a length of stay based "Variable Per Diem Adjustment", an adjustment for "Facility With a Qualifying Emergency Department", a patient "Age Adjustment", and by 17 different "Comorbidity Adjustments".

Walking it through:
"Negotated Type" : "Derived"
"Additional Information" "Revised CMS Inpatient Psychiatric Facility PPS"
"Billing Code Type" : "DRG"
But how to break out the comorbidities, age, and length of stay? Only think I can think of is re-purposing the Negotiated Price Object's "billing_code_modifier" to contain a new code set representing every permutation of Length of Stay Range + Age Range + Comorbidity, but things are complicated by the fact that a Commercial adaptation will deviate from the CMS specification, e.g. proving a separate pediatric age range and adding or changing comorbidity definitions.

@shaselton

In-Network File README.md Inaccurate Compared to Example in-network-rates-capitation-sample.json

In the example, there is "capitation_id": "12345", but in the file layout for the In-Network object there is not a Field/Field Name listed for capitation_id or Capitation ID. This question was previously asked by another individual. Is the example incorrect or is the README.md for In-Network File incorrect?

Which is correct to allow the file to be correctly used?

Different pricing determinates for the same service

Discussed in #242

^{Originally posted by jltang-kp October 26, 2021}
Edited post:

We have certain pricing determinates that would also the negotiated rate of a service. These include CPT modifiers, Patient Age, Rendering Provider's Specialty, Type of Service, Provider Organization, Medication, Provider Type, DRGs/percentage of DRGs

For example we have a contract where MDs and mid-level provider receives a different rate for an office visit 99212, however in the current CMS schema there is no way to represent the difference in price for the same service.
Yes, in this example the description field may be leveraged however if some sort of software were to read the MRF I don't believe the description field would be valid and a new pricing determinate field maybe needed.

I know there have been other similar pricing determinate discussions as well and really think that this needs to be addressed for the 7/1 schema in order to display our contracts along with many other payers contracts correctly in the MRF1 format.

#201
#23 (comment)
#9 (comment)
#12 (comment)

CMS Schema Files Will Not Import and Compile in Informatica – Return as Invalid/Corrupt

``None of the schema files provided by CMS will import and compile using Informatica, including the most recent dated 12/17/2021. Attempts error out indicating that the file format is “Invalid,” see the screenshot, below. This issue was escalated to Informatica Support, who confirmed that the files are “corrupt” and cannot be imported and compiled.

Have any other organizations been able to import and compile the CMS-provided schema files using Informatica or any other tool?
We currently have to reverse-engineer schema files from CMS-provided sample data files.

In-Network File Requirements for Local/Regional Plans

Many local/regional plans contract with national plans to offer secured rates for covered services nationwide.

Is a local/regional plan required to merge the national plan’s MRF into their In-Network MRF, which would create size, merging and updating challenges?

Or instead, could a local plan meet the In-network MRF requirements by linking to the applicable national plan’s MRF URL in the location where the local/regional plan’s In-Network MRF is published?

PBM further explanation of field billing_code_type_version

Can you provide further explanation as to what the billing_code_type_version is in reference to for pharmacy claims data? Would it be something similar to NCPDP?

Questions related to pharmacy data

We have a few questions relating to pharmacy data as there not been much discussion or examples provided for pharmacies. Can you please provide an example format for the in-network schema that is for pharmacy claims information? As a PBM, would the carveout of NDC information be at a client level or a book of business level? For the negotiation rate, are you looking for it through a pharmacy breakdown or a general drug NDC breakdown? Can you provide further explanation as to what the billing_code_type_version is in reference to for pharmacy claims data? Would it be something similar to NCPDP?

Further Guidance on Negotiated Rate Values

For the negotiated_type, there are a few ways in which negotiated rates can happen. Allowed values: "negotiated", "derived", and "fee schedule". See additional notes.

***“For negotiated_type, what is the difference between “negotiated” and “fee schedule”?_

Additional Comments;
We have review the notes and still have some question regarding the difference between NEGOTIATED & FEE SCHEDULE

• First for fee Schedule, when computing the enrollees cost liability, what costs to consider, (Co-Pay, Co INS, deductible, what costs are to be considered?
• for Negotiated, we see that this would be the contractually agreed amount for a service, prior to the adjustments. So why wouldn't Both be required
  OR
  What is the difference how do we determine which one to publish?

Provider reference at header level of In-Network file

Can the provider-reference at the header level of the In-Network MRF be used in lieu of the provider-reference field within the Negotiated Rates Detail object? It states within the Negotiated rates detail object that either provider-group or provider-reference is required but this defeats the purpose of saving space by not having to repeat multiple provider data per rate.

In-network-rates schema doesn't allow for plan -> billing code -> provider -> Different negotiated rate per network affiliation

There are scenarios where a provider could be affiliated to multiple provider networks, and each network could have negotiated a different rate for a particular service (Billing code). And the plan could have contracted with these networks too. In the current schema, we will end up having two negotiated_rate objects having duplicate information except for the amounts. This could cause confusion to the consumers of the MRF.
There could be a couple of approaches to take, each having it's own pros & cons.

1. Adding a "negotiation_entity_name" under the in-network object would allow us to report the rates by a provider network name. However, the problem here would be - if the provider has been negotiating the same rate regardless of the network affiliations, then we will have more redundancy in the data.
2. Make the "negotiated_price" object an array and allow for multiple prices along with an identifier for the negotiation_entity_name for each of the prices.
3. There might be other solutions, where the overall structure could lead with a network entity, but that would require a major change to the schema.

Please feel free to let me know if I am missing something and there is a way to represent this data accurately.

PBM negotiated rates

As a PBM, for the negotiation rate, are you looking for it through a pharmacy breakdown or a general drug NDC breakdown?

PBM NDC information level

As a PBM, would the carveout of NDC information be at a client level or a book of business level?

For "standard" group plans from a Payer, what should go into the Plan id, plan id type, and plant name in the json file?

Looking at the JSON

say I have a standard plan called "5060", a PPO plan, offered by "Payer1" (EIN: 444444) and it is offered to 1000 groups.

plan-id = (444444) EIN??? of the payer? if so xxxxxx (because no HIOS number)
plan-id-type = EIN (One of EIN or HIOS)
Plann-name= 5060
{ other data}

#another plan
plan-id = (444444) (same EIN)
plan-id-type = EIN (One of EIN or HIOS)
Plann-name= 5061 (assuming another standard plan)

Is it ok that plan ids are the same (because of EIN) for different plan names???

on the other hand if EIN is to represent the groups, then why am I repeating it 1000 times the same data?

Appreciate you looking into this.

Thanks
Satya

Allowed-Amount files per EIN

At BCBSSC, we are planning to use EIN within a table-of-contents file since we do not always have HIOS code. Concerning Allowed-Amount files, are we allowed to group multiple EINs to one allowed-amount file containing cumulative charged amounts for all these EINs, or do we need to build a separate Allowed-amount file for each EIN.? This would literally mean creating thousands of Allowed-Amount files every month.

Self-funded plans

Different self-funded coverage options may utilize the same EIN (because they are part of the same ERISA plan) and of course don't have the identifiers that an insured plan has. Is there another way to identify these coverage options or should each set of files just use that same EIN?

Technical Guidance on Capitation for In-Network File

Can CMS/GitHub provide additional guidance and clarifications about technical specifications on how a Plan should handle capitation for purposes of the In-Network Machine Readable File?

Specifically, is the required reportable information the financial arrangement of per member/per month/quarter between the provider and insurer?

Is the plan instructed to provide this capitation rate in lieu of fee for service for associated procedure codes? Or, can capitated services be reported as “encounter” services (the amount the encounter for service would be paid if FFS).

In-Network Schema list 'description' as required, README says it is optional

Ran a file through the validator and got a notice that 'description' was required.
Output from Validator:

Input JSON is invalid.
Error Name: required
Message: Object is missing the following members required by the schema: 'description'.
Instance: #/in_network/0
Schema: #/definitions/in_network

https://github.com/CMSgov/price-transparency-guide/tree/master/schemas/in-network-rates#in-network-object

mint-thompson replied:

This appears to be a discrepancy between the schema definition, which lists this field as required, and the schema's README file, which lists this field as optional

in-network schema missing information

The in-network schema is missing the attribute copayment_amount.

Capitation Arrangement With Underlying Fee Schedule

How exactly should the JSON file be laid out when the provider is capitated and we need to also display the underlying fee schedule per procedure. In the capitation example, the layout flow is plan/network arrangement (Capitation)/negotiated price/covered services. How do we apply both the capitated agreement and the underlying fee schedule under the In-Network Object for a capitated negotiated agreement? Would we we have 2 In-Network Objects for the same providers - one listed as Capitation negotiation agreement and the same provider under a FFS negotiation agreement for the underlying fee schedule for the same procedures listed in the Covered Services Object in the Capitation agreement?

Blurb from white papers = The “Underlying Fee-Schedule Rate,” which is the rate a Plan or Issuer uses to determine a Member’s cost-sharing liability for an Item or Service, if the rate is different from the Negotiated Rate or Derived Amount. 45 C.F.R. § 147.210(a)(2)(xxii). Thus, for example, a Plan or Issuer that pays an InNetwork Provider a capitated rate might use a fee schedule to determine the amount on which Member coinsurance should be based. A fee schedule for a Member’s 30% coinsurance might value an office visit at $100, in which case the Member pays $30 coinsurance. In this example, the Plan or Issuer would report the capitated rate as the Negotiated Rate and the Underlying Fee Schedule Rate as $100.

Typo in the About text on this repo

This should say tri-departmental instead of tri-deparmental (missing a t).