Kepa, Thanks for this perspective. Given that this work group is supposed to focus on both identifiers and EDI addresses - and it's not outside the realm of reality that a different EDI address must be used for the same payer by the same provider but using different provider ID's - this scenario must be taken into consideration as the specifications are developed.
Rachel -----Original Message----- From: Kepa Zubeldia [mailto:[EMAIL PROTECTED]] Sent: Saturday, February 16, 2002 1:02 PM To: [EMAIL PROTECTED] Subject: Re: Number of IDs assigned to a provider Rachel, You can post it any time. There are a couple of reasons for the multiple identifiers. The first reason is that each payer has no way of discovering what the provider IDs are. You can't just go to a central location (IRS or HHS or something else) and ask for the ID for Dr. Jones. So, as a path of least resistance the payer issues its own identifier to Dr. Jones. The second common reason is to distinguish the multiple contracts that Dr. Jones has with the same plan. If Dr. Jones has a rural clinic and a downtown clinic, with different contracted rates, the health plan wants Dr. Jones to use a different ID to indicate which contract applies in each case. And they don't need to have two physical locations. Some times the same doctor in the same location has different contracts. This second problem is not solved with a centralized registry, but could be solved by indicating the contract in the 837. This is already contemplated in the HIPAA implementation guides. There is no reason why the contract must be "encoded" into the provider identifier itself. At least not under HIPAA. I hope this helps. Kepa Rachel Foerster wrote: > Kepa, > > Given this fact, then I believe it's even more essential that the issue of > identifiers (use/role/determining - linking to the correct EDI address) be > an integral part of the whole effort to develop specifications for an EDI > Addressing system. Furthermore, I'm beginning to believe that the issue of > identifiers should **not** be decoupled from EDI Addresses. > > I don't think this will be a trivial effort. Right now the discussion on the > routing list seems more focused on the technical aspects of a domain name > server rather than focusing first on what the overall requirements should > be, including this challenge of how the provider can link one of the many > identifiers assigned to him/her to the appropriate EDI address for a given > payer/plan. It seems to me that we have a many-to-many situation, which can > become quite complex....especially if this address discovery plus linkage > needs to be done dynamically at run time. > > With your permission, I'd like to post this message exchange to the list. > > Rachel > > -----Original Message----- > From: Kepa Zubeldia [mailto:[EMAIL PROTECTED]] > Sent: Thursday, February 14, 2002 9:53 PM > To: [EMAIL PROTECTED] > Subject: Re: Number of IDs assigned to a provider > > > Rachel, > > The average provider deals with 6-20 identifiers. > > Kepa > > > Rachel Foerster wrote: > > >> I'm forwarding the message below to this list since it contains what I >> believe is extremely relevant information regarding identifiers, the > > number > >> of identifiers a given provider may have with a given payer, and thus the >> implications for requirements/solutions for identifiers. >> >> I've deleted the non-relevant portions of the message. >> >> My question to this group: is the assignment of several identifiers to a >> given provider common business practice? >> >> Rachel >> Rachel Foerster >> Rachel Foerster & Associates, Ltd. >> Phone: 847-872-8070 >> >> >> -----Original Message----- >> From: Hooser, Larry [mailto:[EMAIL PROTECTED]] >> Sent: Wednesday, February 13, 2002 1:24 PM >> To: [EMAIL PROTECTED] >> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] >> Subject: RE: Web authentication for HIPAA >> >> >> Thanks for the thoughtful response. Pretty much the same principles I > > have. > >> >> Further comment: >> >> We have possibly 25,000-40,000 providers needing access with an average of >> 4-6 ids each; that's 200,000+ users right off the bat. Requiring tokens, >> readers, cards, etc. in that fluid (staff coming and going, moving, etc.) >> environment would be costly, cumbersome, overhead intensive (as any > > "client" > >> solution is), and very challenging - in my view; and I don't believe the >> software-only certificates add much or any value beyond strong, enforced >> passwords.
