Kepa, Actually, the NAIC coding method does support PlanID capabilities for those that chose to support it. I have my Aetna card which shows "Payor Number: 60054 0106" (PayorID/PlanID). I also have a grp: number and my member number on the card. So, I've never understood why it's so difficult to accept this as the standard criteria on any insurance card. I would prefer the numbers be contained in a Bar Code/magnetic strip readable format with a checksum digit to ensure proper entry, then have it scanned rather than manually entered. The 5+4 does have it's limitations and not all plans have to be registered or obtain a NAIC code (but maybe the National Plan ID will solve this). It seems to be working for the zip code system, you'd think it could work for the Payor/Plan based system. Regards, -RB
>>> Kepa Zubeldia <[EMAIL PROTECTED]> 02/11/02 05:29PM >>> William, As it turns out, it is likely that my local BCBS will have a good number of PlanIDs under HIPAA. Perhaps in the hundreds, as Regence BCBS has a multitude of plans in several states. A provider that sees a HIPAA PlanID and has a connection with a clearinghouse as well as a connection with REgence BCBS will have to determine whether the transaction goes to REgence BCBS or to the clearinghouse that acts as "gateway to the rest of the world". Today we are not yet using PlanIDs, but PayerIDs. With PayerIDs life is a lot easier because Regence BCBS will have only one Payer ID. But, with PlanIDs Regence would have a good number of health plan under administration, each one with its own PlanID, indistinguishable from any other PlanID out there. The same will happen to all other payers. Can you imagine the confusion if we don't have a good way to map from PlanID to Payer? Kepa William J. Kammerer wrote: > Chris: > > I'm just a populist at heart! > > But I'm also a little confused! If you (a provider) have a standard > claim transaction intended for a particular National plan ID, say > 987654321, you would build a single 837 with the payer (or plan?) > indicated in the NM1 within the 2010BB loop. You would not comingle > claims for multiple payers or plans, like a CH might (as Bob Poiesz has > illustrated). > > So, who else's ID - other than the payer's - would be in the ISA > receiver field? There does seem to be a relationship when standard > transactions go from provider to payer, unmolested, via a VAN or EDIINT > software. I suppose if you've been told, via Kepa's "directory," that > claims for PlanID 987654321 go to WebMD, WebMD might demand that their > ID be in the ISA receiver field - but yet, they already know they're the > receiver! In that case, it's almost irrelevant what's in the ISA > receiver field - WebMD sounds like they're going to strip search the 837 > anyway in order to combine your claims with those of other providers > intended for whatever TPA or Payer handles PlanID 987654321. > > William J. Kammerer > Novannet, LLC. > +1 (614) 487-0320 > > > ----- Original Message ----- > From: "Christopher J. Feahr, OD" < [EMAIL PROTECTED] > > To: "William J. Kammerer" < [EMAIL PROTECTED] >; "WEDi/SNIP ID & > Routing" < [EMAIL PROTECTED] > > Sent: Saturday, 09 February, 2002 07:46 PM > Subject: Re: Using a hybrid DNS > > > William, > Thanks for your ongoing concern for us "little people (providers)", but > the more I think about divorcing the payor/plan ID info in the > transactions from the receiverID info in the ISA, the more I like it... > because it embraces the models in use today in which there really is no > relationship between these two addresses. If the industry is willing to > adopt the distributed address directory model that Kepa is proposing, > then the "little people" can either hound their office system vendors to > include that capability... or the smart vendors will see the business > opportunity and sell the address discovery process to the provider as a > value-add...or the small provider can just shovel all of his claims to > one clearinghouse and let the CH worry about routing them. Since the > need to know where to send these interchanges is going to be so acute > for the provider, I can't imagine a situation in which no one was > willing to create a system that would do the address discovery for them. > > -Chris
