Bruce, I realize this might be slightly off-topic, but it seems that what is missing is a way to direct an individual provider's claim to a particular insurance PLAN. Hard-wiring the plan's identification into the provider's ID (common today) is one way... hardwiring it into the payor's ID using the proposed national "planID" system is another way. But both of these seem "wrong" to me. Identification of the covered entity (and discovery of the various ways of getting EDI messages to him/her) is ONE problem that should be addressed with a system that is ONLY about entity identification. identification of various plans/lines of business within an entity and making sure that a particular claim is adjudicated under the appropriate plan-rules would seem to be a completely different issue from identification of the CE.
EXAMPLE: At X12, I talked with several payors about a popular new variant of "standard" vision coverage called "Video Display Terminal" or "VDT" coverage. The idea is that being parked in front of a "VDT" all day could produce an ocular version of "carpal tunnel synd." and expose employers to liability, etc. So to be "proactive", and reduce exposure, companies are purchasing VDT coverage, typically for "high risk" employees to have in addition to the standard vision benefit. The doc does some special testing... perhaps simulating actual working conditions... recommends special lenses designed for "VDT" viewing distances, etc. In most cases, the covered employee gets one pair of glasses under his regular plan and a second one under the VDT plan. The problems faced by payors is that the services and eyewear on the VDT claims may be identical to those billed to the regular plan. DX codes are rarely even looked at by vision adjudication systems because they are either "refractive" (myopia, astigmatism, etc.) or symptomatic (eye strain, headache, diplopia, etc.)... and these would not be sufficient to distinguish between a claim for a "regular" plan and one for a "VDT" plan. It seems to me that "which plan?" or "which line of business?" should be answered in a separate field in the 837 and not combined with the entity-ID field. -Chris At 02:11 PM 2/18/02 -0500, [EMAIL PROTECTED] wrote: >Jim does bring up a valid concern from the payer perspective. It is true >that many/most health plans identify providers uniquely for each provider >contract relationship to price and pay claims faster and more accurately, >and many providers have multiple contracts in place at any given time. >However it would seem that the NPI (National Provider Identifier) will >obsolete that process and accordingly some payers are now looking at >alternative logic to ensure each claim is priced according to the terms and >conditions that apply to that patient and that provider. These changes >would include a more definitive review of member's benefits coupled to the >individual provider, if the services were rendered by an individual covered >entity and the organizational provider (usually the organizational >affiliation of the individual, e.g., group practice or clinic name/number). >If the provider is not an actual individual, the organizational NPI would >be used. However the individual NPI is critical because many provider >contracts are executed between individual providers -- not provider groups. >This information along with other information currently existing in the >transaction is presumably enough to properly process these transactions. > >Bruce > > > > > > > "Rachel > > Foerster" To: <[EMAIL PROTECTED]> > > <[EMAIL PROTECTED] cc: > > etcom.com> Subject: RE: Using a hybrid > DNS > > > 02/13/2002 > > 03:28 > PM > Please > > respond > to > rachelf > > > > > > > > > >Kepa, > >At the Seattle ad hoc discussion Jim Moynihan also brought up an issue re >identifiers - and that is that for many payers a provider may be associated >to many different plans (planID) and today, such a payer assigns the >provider a different provider ID for each plan. Thus, the provider must not >only know the payer ID, but also the plan ID and the provider ID assigned >to >it by the payer for a specific plan. > >It's for this reason that I'm asserting that the issue of identifiers is >not >solely at the Interchange domain, but also in the transaction content >domain >as well, since we know that clearinghouses and other service entities today >aggregate claims from many different providers into a single transaction >which is forwarded to the payer. > >I hope that Jim will seize this opportunity to provide us with other >scenarios around which requirements can be developed. > >Rachel > >-----Original Message----- >From: Kepa Zubeldia [mailto:[EMAIL PROTECTED]] >Sent: Monday, February 11, 2002 5:29 PM >To: [EMAIL PROTECTED] >Cc: WEDi/SNIP ID & Routing >Subject: Re: Using a hybrid DNS > > >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 Christopher J. Feahr, OD http://visiondatastandard.org [EMAIL PROTECTED] Cell/Pager: 707-529-2268
