Bruce, I think my take-home message from these many posts is that to correctly address an interchange, the sender is going to have to put a receiver ID in the ISA that unambiguously specifies the next destination. The discovery of that Next Destination ISA address, however, may require the sender to consider information that he's putting down inside the transactions... information about his collection of usual receivers that his system will have to maintain in a table.
Regarding what to do with the incoming interchange, it appears that payors can distinguish between plans for the various transactions in 3 ways: 1. by assigning plan-specific (home-grown) IDs to providers (in the transaction and possibly also in ISA sender field) 2. by having plan-specific IDs assigned to them by the govt.... as many as they have plans (in the transaction and possibly also in ISA receiver field) 3. by using an all-purpose payor ID (assigned by govt.) and then looking in the SBR inside the claim for the plan# For transactions aimed back to the provider (assuming Kepa's conjecture in myth #49 pans out) the provider with "multiple business lines" and a need to have certain transactions directed to certain receiving systems, may be able to create a provider version of #2 above by getting a unique "provider ID" assigned to each distinct business entity. (see experpt below from Kepa's article). Bruce, are you thinking that payor option #3 above might be what companies will naturally move toward? This seems a lot easier to maintain than a massive/shifting linkage between payors and planID's... with payors inventing new plan variants almost daily for competitive reasons? In any case, the ID and addressing options available for the payor should also exist for the provider. -Chris Here's the clip from Myth#49: As I understand it, each "warm body" provider will get one and only one NPI. So far we are in sync. Also each "brick and mortar" provider will get one and only one NPI. And each "entity" provider will get one and only one NPI. But, what is an "entity" provider? As I understand it, it is a legal entity that has a distinct legal personality. Or maybe it does not have to be "legally" unique? I am not a lawyer, so I won't elaborate. But it seems to me that "Phil Good, MD" is different from "Main Street Cardiology" and different from "Suburbia Cardiology" and different from "Big HMO Cardiology Services" and different from "Cardiology Specialists", even though all of them are different expressions of the services rendered by Dr. Good. So, each one of those entities, under the law (and the IRS?) is a different provider that is entitled to a different NPI. So, how many "entity NPIs" can Dr. Good have? As many as he needs. As long as each one is a different "entity." And Dr. Good has control of how many "entities" he creates. At 03:56 PM 2/19/02 -0500, [EMAIL PROTECTED] wrote: >I believe we are reaching the same conclusion, and agree that we should not >add more data elements to our transaction suite simply to provide more >detailed routing information regardless of whether we are talking about >routing between covered entities or within covered entities (e.g., a >provider setting or a payer/health plan setting). > >I think many payers will improve the receiving application system logic to >correlate specific information within the transactions sooner (in the >process) -- including patient/member information, individual and/or >organizational provider information, and service information. This >approach should obsolete our existing use of multiple provider identifiers >to facilitate contract relationship differences and/or internal routing >within a payer. > >However, I don't know whether providers or provider vendors have explored >equivalent solutions. An example could be a scenario where the same >individual provider (remember 1 number for life per individual), using the >same organizational provider number has more than one office, and has >separate AR systems at each location. Under HIPAA, payers would return all >transactions (remittance, eligibility and claim responses, etc) to "the" >electronic address associated with that individual and/or organizational >identifier. That would require the providers to correlate transaction >specific information analogous to the above payer process to facilitate >contract compliance edits and internal routing. (An alternative would be >to secure multiple organizational provider numbers, but that may not be >realistic depending on the NPI approach.) > >Unique Health Plan Identifiers which are required by HIPAA, could be >associated with specific payer identifiers (including TPAs, self >administered Health Plans, and others providing administration services for >Health Plans) at the transaction level. This concept could become the >foundation of health care EDI addressing and routing. I believe somebody >suggested there are more than a 100,000 health plans (gulp!!), but if we >could link each transaction and Health Plan to the appropriate payer, TPA, >or self administered Health Plan, our addressing and routing problems would >be significantly reduced (not cured). > >The next step, although I don't profess to understand Kepa's proposal, >would be to establish DSN addresses for each payer, TPA, and self >administered Health Plan, and a table that ties the transaction, Health >Plan, and payer (including TPAs and self administered Health Plans) >together. I would further expect this kind of approach would be automated >-- and fully integrated in each trading partner's system (whether it would >be an HIS, PMS, VAN, Clearinghouse, Employer HR system, or any other valid >trading partner). > >My opinion and $0.25 will buy a cheap cup of coffee. > >Bruce > > > > > > > > > "Christopher > > J. Feahr, OD" To: [EMAIL PROTECTED], > [EMAIL PROTECTED] > <chris@optise cc: > > rv.com> Subject: RE: Using a hybrid > DNS > > > 02/18/2002 > > 05:01 > PM > > > > > > > > >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 Christopher J. Feahr, OD http://visiondatastandard.org [EMAIL PROTECTED] Cell/Pager: 707-529-2268
