search

CMSgov / price-transparency-guide

The technical implementation guide for the tri-departmental price transparency rule.
362 stars 109 forks source link

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

Closed rakeshkatte closed 3 years ago

rakeshkatte commented 3 years ago

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.

monty3301 commented 3 years ago

Is this a plan with something like a broad and narrow network - same provider contracts with a lower rate in narrow network, more expensive rate in broad network? Are those different benefit options requiring two sets of IN files?

pushpachavan commented 3 years ago

Yes, same plan/provider but different networks, 1 with lower and the other higher. It would still be the one same IN file because the file naming convention only contains the Plan name (and not network).

rakeshkatte commented 3 years ago

@monty3301 that could be one of the scenarios, but the size of the network may not be the only driving force there. The benefits (cost share) may not be different at all. Also, if we need to break this into two IN files, we will need to map a bunch of different dynamic "Plan names" to this single plan we have in the system else we will end up with the same name for both the files. So, this might not be a feasible option.

hhCambia commented 3 years ago

We have the same concern. @rakeshkatte Option 2 that you outlined eliminates redundancy and seems less disruptive than option 1.

BobSyracuse commented 3 years ago

@rakeshkatte @hhCambia What percentage of your data to you see this scenario occurring? Wondering because we have not seen the scenario in our data.