Proposed backwards compatible fix for the File Size Issue : 1. New "Code Description" object 2. NPI+Tax ID

[clovis517]

The following will substantially reduce file sizes and could co-exist with the current specification.

1. Add an optional Code Description object and allow payers submitting it to omit the Code Description fields defined elsewhere in the model. The new Billing Code Description must contain a single entry for each billing_code_type, billing_code_type_version, billing_code referenced elsewhere in the model.

2. Address the Tax ID problem: allow payers to submit a single "Negotiated Rate Details Object" per code per network rather than one per Tax ID.
   Option a. Allow payers to submit a new "NPI tin" object and omit "tin" from the "Negotiated Rate Details Object". Unfortunately this is only possible if NPIs can only have a single Tax ID, and I am not sure this is the case.
   Option b. Allow payers to add an optional second dimension to the "Providers" array, submitting NPI and tin pairs instead of populating the existing tin field.

Thoughts?

@shaselton-usds @shaselton

[Devyandu]

Hi @clovis517
For your (1.) you can achieve similar results if you use the YAML format. It has inbuilt support for anchors..
With anchors, you can have some data once in the file, give it an anchor name and then not repeat it in the file.

YAML is already one of the recommended formats as per this link

[clovis517]

1. Add an optional Code Description object

No change needed for this since the Code Description is defined as not required. Yay! A similar size reduction could be achieved by making the In-Network Object "name of the item/service" optional or spinning it into a separate lookup object, basing the lookup on the code, in situations where the "name of item/serivce" is an attribute of the code.

[rgouldkc]

Regarding your #2a, there is no relationship between NPIs and Tax Ids. Type 1 NPIs are assigned to individual providers, Type 2 NPIs are assigned to non individual providers, i.e. Hospitals. For any given facility Tax Id, there can be one to many NPIs associated with it, both Type 1 NPIs for the individual providers that work there, plus Type 2 NPIs if the facility decides to get separate Type 2 NPIs for it's various departments. For individual providers working at multiple locations you will have situations where a single Type 1 NPI is associated with multiple Tax Ids.

Your option 2b appears workable to me. In our situation a pricing "contract" is assigned to one or more tax ids. These contracts define for example what fee schedules are use and tend to relate to the types of services provided. If a contract is associated to 2 tax ids, there could be a situation where there are 10 individual NPIs associated with one of the tax ids and 1 NPI associated to the other tax id. In the current schema for each billing code (In Network Object), we need 2 Negotiated Rate Details objects (one for each tax id) for each service code (48 service codes for physician claims), for a total of 96, for a single rate. Changing providers to an array of NPI-TaxId objects cuts that in half. Coming up with a better strategy for service code such as an indicator that service code doesn't matter along with being able to provide service codes as an array when they do matter ( for us it's usually 3 codes when it matters) makes another significant reduction in the size of the data.