Making the Provider TIN an Array

[Nio-1]

At present in the schema, the Provider Tax Identifier Object Value field is a string. Would anyone find benefit from making that Provider TIN an array instead?

Here is the thought process behind that:

If an issuer does not contract different rates for the same service over different TINs, but rather has one rate for a service (like in a fee for service model), regardless of TIN, then allowing multiple TINs would eliminate having to report one TIN over every service. Instead we could submit an array of TINs for each service.

I do understand that this causes a bit of a problem for the Provider Tax Identifier Object Type field where the EIN or NPI field is specified to define the Value field.

Would love to hear some thoughts regarding this. Thanks so much ahead of time!

[rajkumarsowmy]

I would agree, even in case where that TIN is SSN# , we have to repeat tax identifier object with # of NPI on the provider object.
if we have the Value as ARRAY then we can avoid this situation too. this will help in the file size and that's advantage of this change. otherwise it wouldnt server the purpose.
I raised this questions when this change introduced but then no one upvoted and didnt get traction.

[rajkumarsowmy]

@shaselton @shaselton-usds @tdfow

if we are not making the tin.value as array, we are not getting an advantage of reducing the file size.
we are in a position to repeat this TIN block.
Example:
CMS example:
"provider_groups": [{
"npi": [1111111111, 2222222222, 3333333333, 4444444444, 5555555555],
"tin":{
"type": "ein",
"value": "11-1111111"
}]

we dont have an option to say if the TIN is SSN or not , so we have to populate the NPI in the TIN block.
this is how we have to represent it and no other way out, and it increases file size.

"provider_references":[{"provider_group_id":26,
"provider_groups":[{"npi":[1111111111],"tin":{"type":"npi","value":1111111111}},
{"npi":[2222222222],"tin":{"type":"npi","value":2222222222}},
{"npi":[3333333333],"tin":{"type":"npi","value":3333333333}},
{"npi":[4444444444],"tin":{"type":"npi","value":4444444444}},
{"npi":[5555555555],"tin":{"type":"npi","value":5555555555}}]

if we make the tin.value as array.
we can represent the data in this way.

"provider_references":[{"provider_group_id":26,
"provider_groups": [{
"npi": [1111111111, 2222222222, 3333333333, 4444444444, 5555555555],
"tin":{
"type": "npi",
"value": [1111111111, 2222222222, 3333333333, 4444444444, 5555555555]
}]

Need some attention and help here. Thank you so much.!!

[rajkumarsowmy]

@tdfow

[ysinghsardar]

It will help the plan if they dont have option to identify the TIN is SSN or not

[dolinsky]

@rajkumarsowmy the way that you have represented the tin.value as an array, there is no way for someone ingesting this json to know that the position of an element in the npi array is meant to correlate to the same position in an entirely separate array (tin.value in this case). What this json is communicating is that all of the elements present in the tin.value array are applicable to all of the values in the npi array, which is not what you're intending to communicate.

[rajkumarsowmy]

@dolinsky My bad, It was a typo error: I updated the type:npi(correctly).

the intention to the consumer is if the tin.type is npi, they don't have to consume the value array. because im not supplying the TIN number.
Since I don't have a way to identify the TIN is an SSN or not. I'm left with supplying only NPI option for that rate.
do you see any other way out?

"provider_references":[{"provider_group_id":26,
"provider_groups": [{
"npi": [1111111111, 2222222222, 3333333333, 4444444444, 5555555555],
"tin":{
"type": "npi",
"value": [1111111111, 2222222222, 3333333333, 4444444444, 5555555555]
}]

[dolinsky]

Given that a Provider Object represents the combination of an array of Type 1 provider NPIs and the TIN they report under, if the tin.value element is changed to an array, then every single TIN value would have to be applicable to every single NPI in that Provider object. Is that the desired affect being sought here?

[Nio-1]

No, it's not a desired affect. The correlation between NPIs and Tax IDs would be muddied.