cmsgov / price-transparency-guide Goto Github PK
View Code? Open in Web Editor NEWThe technical implementation guide for the tri-departmental price transparency rule.
The technical implementation guide for the tri-departmental price transparency rule.
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
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.
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?
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.
Please feel free to let me know if I am missing something and there is a way to represent this data accurately.
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?
The in-network schema is missing the attribute copayment_amount
.
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.
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?
As a PBM, for the negotiation rate, are you looking for it through a pharmacy breakdown or a general drug NDC breakdown?
“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!
What negotiated price should be reported if there are multiple negotiated rates that apply under a given HIOS ID/EIN, Plan ID, Pharmacy, Drug?
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:
Appreciate it
Satya
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.
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
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'?
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!
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"}]
As a PBM, would the carveout of NDC information be at a client level or a book of business level?
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?
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
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
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>
Will a separate repository be created to further develop and establish similar conventions for the Hospital Price Transparency machine-readable file requirements?
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?
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,
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
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.
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?
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.
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.
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.
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.
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?
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.
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?
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
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).
Can CMS/GitHub include a bundle example on how a JSON display works for a DRG claim?
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?
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.
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?
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?
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.
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?
``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.
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:
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/
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.
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.