Multiple TINs

[mh-wogan]

We are dealing with a situation where we have multiple TINs. Based on the current layout we could just have multiple objects for each time we have more than one TIN, but it seems that it would make more sense to allow TIN to be an array. This would avoid a considerable amount of redundancy similar to some of the other discussions going on.

[BobSyracuse]

@mh-wogan This has been called out in In-Network file size and data redundancy concerns #99 and glad you are calling it out also. There are many data redundancy issues with the schema and this is one.

[taylorpatriciab]

@shaselton-usds Currently the only way to report a situation where Providers who share the same Fee Schedule but not the same Tax ID is to duplicate all the data in the Fee Schedule for every single provider. Would you consider addressing this redundancy? A structure could be added to the schema such that each Provider would be an entry in the array and would have both the NPI and Tax ID. This would be functionally equivalent to the current schema.

[shaselton-usds]

@mh-wogan @BobSyracuse @taylorpatriciab

Understood that the hope is to reduce the Negotiated Price Objects produced.

To articulate this specifically, are you looking to move from the current implementation:

{
     "providers": [1111111111, 2222222222, 3333333333, 4444444444, 5555555555],
     "tin": "11-1111111",
     "negotiated_price": {
       "negotiated_type": "negotiated",
       "negotiated_rate": 123.45,
       "expiration_date": "2022-01-01",
       "service_code": ["01", "02", "03", "04"]
     }
},
{
     "providers": [1111111111, 2222222222, 3333333333, 4444444444, 5555555555],
     "tin": "22-2222222",
     "negotiated_price": {
       "negotiated_type": "negotiated",
       "negotiated_rate": 123.45,
       "expiration_date": "2022-01-01",
       "service_code": ["01", "02", "03", "04"]
     }
}

to this:

{
     "providers": [{
        "npi": [1111111111, 2222222222, 3333333333, 4444444444, 5555555555],
        "tin": "11-1111111"
     },{
        "npi": [1111111111, 2222222222, 3333333333, 4444444444, 5555555555],
        "tin": "22-222222"
     }],
     "negotiated_price": {
       "negotiated_type": "negotiated",
       "negotiated_rate": 123.45,
       "expiration_date": "2022-01-01",
       "service_code": ["01", "02", "03", "04"]
     }
}

In this case, the negotiated rate for the item/service is the same across the provider/tin/service_code relationship, but the combination of the provider and tin are different, correct or was the scenario something different?

[taylorpatriciab]

@shaselton-usds Yes, we see situations where where the exact same group of NPIs map to multiple TINs and yes, it could be for the same negotiated price
@BobSyracuse @mh-wogan

[shaselton-usds]

@taylorpatriciab I wonder how frequent the situation is. We can make the above change and observe whether the same group of NPIs mapping to multiple TINs situation is common to warrant changes for to cut down the file size.

[taylorpatriciab]

@shaselton-usds thinking about this a little more, may be slightly different.. we're trying to solve for the situation where one fee schedule applies to multiple TINs. Could the TINs be defined as an array. @BobSyracuse @mh-wogan

[shaselton-usds]

@taylorpatriciab Great suggestion -- updates can be found here: c189c5c

[taylorpatriciab]

@shaselton-usds thanks so much!! @BobSyracuse @mh-wogan