Stream: united states
Topic: identifier system for TAX identifiers
Lee Surprenant (Mar 19 2020 at 17:41):
NPI must be supported as the identifier system in the US, Tax id is allowed, Local id is allowed in addition to an another identifier supplied by a jurisdictional authority such as a practitioner's Drug Enforcement Administration (DEA) number.
Is there any guidance provided for which system URIs to use for the non-NPI, non-local ids (i.e. TAX id and DEA numbers)?
Vassil Peytchev (Mar 19 2020 at 17:55):
The DEA number has an OID in the HL7 Registry
Tax ID may be the person's SSN (unusual), the organization's EIN (couldn't find any reference for that system identifier), or, theoretically, a personal TIN, but I can't think of a case where that might be applicable (Canadian providers working cross-border in the US?)
Eric Haas (Mar 19 2020 at 17:56):
TIN is urn:oid:2.16.840.1.113883.4.2
Vassil Peytchev (Mar 19 2020 at 17:59):
And EIN is 2.16.840.1.113883.4.4
Eric Haas (Mar 19 2020 at 18:00):
I'm not sure if we intended to retain that guidance which stems from the provider directory since it is buried in the comments we could have easily missed it. and if we do we should provide the systems... @Brett Marquard thoughts?
Eric Haas (Mar 19 2020 at 18:01):
I remember researching the difference between EIN and TIN and for Da Vinci we landed on the TIN but not remembering why.
Eric Haas (Mar 19 2020 at 18:02):
but that is more appropriate for organizations than people...
Brett Marquard (Mar 19 2020 at 18:04):
I only remember discussions during directory use case. Some additional guidance here seems appropriate.
Vassil Peytchev (Mar 19 2020 at 18:11):
TIN is for non-us persons. It is very unlikely a provider will have a TIN. Patients - yes, SSN and TIN need to be handled similarly. But between EIN and TIN for providers - EIN is way more likely to exist.
Eric Haas (Mar 19 2020 at 22:07):
@Vassil Peytchev you are referring to an ITIN
Eric Haas (Mar 19 2020 at 22:07):
TIN is 'an “umbrella term” for housing the SSN, EIN, and ITIN.'
Eric Haas (Mar 19 2020 at 22:11):
and the oid I referenced looks like an ITIN.... guess I need to submit a tracker for DEQM... sigh....
Eric Haas (Mar 19 2020 at 22:12):
EIN is what you want ideally
Vassil Peytchev (Mar 19 2020 at 22:13):
Correct. I think it is not useful in this case to have an umbrella "system" when the constituents are well defined. Apparently there is also Adoption TIN (ATIN?)...
Lee Surprenant (Mar 20 2020 at 15:09):
thanks Eric and Vassil. so, if i understand correctly, the recommendation is to determine which TIN we have (EIN most likely, SSN and maybe ITIN possible) and then use the corresponding OID.
For example, for in EIN:
<identifier>
<type>
<coding>
<system value="http://terminology.hl7.org/CodeSystem/v2-0203"/>
<code value="TAX"/>
</coding>
</type>
<system value="urn:oid:2.16.840.1.113883.4.4" />
<value value="VALUE" />
</identifier>
Eric Haas (Mar 20 2020 at 21:49):
We discussed this on a call today and there are a lot of implementations in the Quality reporting space using the OID for the the ITIN so this issue is not so cut and dry. We elected not to change it for DEQM right now. I would recommend practically speaking validating to either one, but using the EIN.
Vassil Peytchev (Mar 20 2020 at 22:11):
I hope this is to handle the intermediate situation until the proper system is used by everyone (as specified in the IG)...
Lee Surprenant (May 22 2020 at 17:34):
@Saul Kravitz have you guys discussed this one at all from a PDEX PlanNet perspective? Do TAX identifiers matter in that scenario?
Saul Kravitz (May 22 2020 at 18:28):
PlanNet doesn't relate to billing, so I think TINs are a non-issue.
The closest we get are NPIs....
Lloyd McKenzie (Feb 07 2022 at 21:19):
In case anyone is seeing this, the fact an OID exists does NOT mean that it's ok to just take that and use it as the FHIR Identifier.system value. All Identifier.system values that are going to be referenced in or relied on in HL7-published specifications MUST go through the HTA process. (Which will generally try to assign a URI that's not an OID...)
Eric Haas (Feb 08 2022 at 04:47):
Really? These OIDS come from the HL7 OID registry and FHIR says you can still use them.
Eric Haas (Feb 08 2022 at 04:47):
What is the value of spinning our wheels replacing perfectly good OIDs?
Lloyd McKenzie (Feb 08 2022 at 05:39):
Going through the proper process isn't spinning your wheels. And our objective is very much to avoid OIDs - they're not implementer friendly.
John Moehrke (Feb 08 2022 at 13:28):
When it is common to use a system value that is an OID in other kinds of communication, it seems really UNFRIENDLY to force conversion to a alpha based URI. I think this campaign against OIDS needs to have some practical reality check,.
Lloyd McKenzie (Feb 08 2022 at 15:09):
Conversion is absolutely what we want to happen. Our driver is not to minimize the gap between CDA and FHIR. Our driver is to make instances friendly to humans. If our objective had been the former, we never would have switched from OIDs to URIs in the first place.
Lloyd McKenzie (Feb 08 2022 at 15:09):
Translation is already necessary in numerous places, so the translation infrastructure has to exist. And NamingSystem makes it easy to share the necessary translations in fully computable form.
Lloyd McKenzie (Feb 08 2022 at 15:10):
As much as possible, we want to use human-readable URIs (and ideally resolvable ones) even when there were standard OIDs in use in v3.
Michele Mottini (Feb 08 2022 at 16:03):
We have been in production using that system URI for at least a couple of years so that ship has sailed for us
Lloyd McKenzie (Feb 08 2022 at 18:01):
I understand - which is why this is problematic. IGs don't have the authority to do this because we end up with sub-optimal (or worse multiple) solutions.
Lloyd McKenzie (Feb 08 2022 at 20:59):
https://jira.hl7.org/browse/HTA-74
Last updated: Apr 12 2022 at 19:14 UTC
