Associating negotiated rates with providers

[animalshapes]

Thanks for all the hard work bringing Transparency in Coverage to life!

tldr; In the In-Network files, is there a way to associate a negotiated rate with a provider?

More detail: This seems achievable for the Allowed Amounts file, since the Allowed Amounts file has a 1:1 between TIN and allowed_amounts, and then a child object for NPIs and billed_charge (example in repo). However, in the In-Network files, both provider_groups and negotiated_prices are sibling arrays, and from what I've seen they are often different lengths. Is there a way for me to deduce that provider X has negotiated_rate Y, or am I only able to work with these generalized groupings (providers [A, B, C, D...] have negotiated_rates [1, 2, 3...])?

[escoses100]

In the files I have reviewed so far (in-network) the best you are going to be able to do is associate rates with provider groups. As you mention, if the provider group only has one provider it works, but there are a lot of large arrays in provider groups and it is very clear that the provider grouping is not based on services they actually provide (try looking up air ambulance in some of the larger files). This breaks the ability to create shoppable service lists from the data - one of the key intents of the law. My thought is that future versions probably need to get away from the idea that place of service codes and the vague institutional/professional designations identify enough about the rates to attach them to a provider. I see a lot of rates labeled "institutional" when they are clearly not high enough to be billed by a facility (on a UB) and some say "professional" when they probably don't belong on a HCFA (I assume the designation origin comes from 837Institutional and 837Professional, but that isn't how it was interpreted). Your best bet at this point is to look at how you can take providers out of the list because there is no way they would provide that service and bill that rate. So - if it is an "institutional" rate, you should be able to scrape any professional service providers out of the provider ID group. This is a lot of work and definitely keeps the data at a level that is less accurate than other versions of the same data in original form. For instance, most network contracts would clearly delineate facility rates in the same manner as Medicare (Hospital IPH, Hospital OPH, ASC) and then clearly delineate the associated provider lists (facility vs professional). The present schema has allowed the networks to mix those together a little at this point (especially in the provider group arrays), so there will be a little more variance in your results using these files as you connect them to providers. That said, I think use cases like the one you identify (how to build a provider-to-rate fee schedule from this data) may help future versions become more useful.

[nmayle]

@escoses100 thank you for describing these issues.
If I understand you, you seem to be saying two things:

• the definition is missing or unclear as when institutional vs. professional should be used as the billing_class. I couldn't find anything in the discussions or document describing how to use this field. Perhaps it was in one of the webinars
• people are creating provider groups with providers that have a mixture of providers that are actually billable for a billing_code (and billing_class) and ones that aren't or they are creating arrays of provider groups that include both and again associating them with a negotiated_price object that doesn't match some of the providers. So, expanded out you see providers that don't make sense for a given billing_code.

It would seem that the first issue can be solved by guidance and clarification of the intent of the billing_class field. It should be clear enough how to use that field that it is used to consistently to represent the different types of rates.

@shaselton: please provide clarification as to the use of billing_class since in the wild it is being used in different and inconsistent ways.

This second issue seems to be either in the underlying data that the insurers are using to create these files -- their database may have rates for providers for codes that don't actually ever bill for that code. Or it could be that they are creating broad provider groups and are using them when they could be creating more smaller groups or providers and only associating the correct set of providers (and billing_class) with the bundled code via negotiated_rate_details objects. When necessary two separate negotiated_rate_details objects should be created so the professional charges are separate from the institutional charges.

So, this second issue be solved within the current schema even if it may not be the ideal way to compactly represent the various rates. Is this correct?

[escoses100]

@nmayle is on point. I would add that I think the "professional" and "institutional" labels might work if they represent 1) can be billed/paid using a UB or 837I or CMS1450 claim [institutional] or 2) can be billed/paid using a HCFA or 837P or CMS1500 claim [professional]. This could be updated to be [Institutional Inpatient] - [institutional outpatient] [institutional ASC] because "service code" is not being used to indicate all the bill types, and it would probably make sense for somebody official to make a list of the bill types associated with the Institutional categories and payment methodologies - its not like there is any rate associated with bill type 111 other than inpatient institutional, and 131 is always going to be outpatient institutional. (everybody has one for institutional claims or they would be manually paying every claim).

[hw-monkey]

I think the answer to your question is in the example file. Having looked at the Blue Cross file, I see that the link between providers and plans does not exist. The file is prepared according to the spec about multiple plans:

##### Additional Notes Concerning `plan_name`, `plan_id_type`, `plan_id`, `plan_market_type`
These attributes ARE NOT REQUIRED for files that will be reporting multiple plans per file but ARE REQUIRED for single plans that are being reported that do not wish to create a table-of-content file. For payers/issuers that will be reporting multiple plans per file, these attributes will be required in a table-of-contents file.

This results in the plans being listed separately from the rates, as you mentioned. So plans A,B,C,D are somehow associated with in network rates R1,R2,R3,R4,R5,R6,R7,...R140 and providers P1,P2,P3...P5000 are associated with provider group 20. As such, I do not see how it would be possible to correlate P123 with R29.

[hw-monkey]

I could be wrong about this. See:
https://github.com/CMSgov/price-transparency-guide/blob/master/schemas/in-network-rates/in-network-rates.json#L197-L200