Rachel Foerster fears that I might "get too wedded to determining BCBS plan codes and then modeling a solution to them."
The solution has already been modeled: I'm suggesting - not the first time, certainly - that a requirement of our specifications include the ability to search the Healthcare Registry by any number and type of identifiers. The illustration showed one possible means of how, in this case, the Blue Cross Blue Shield Plan Code could be described and used to locate the CPP (electronic Partner Profile) for the a particular Blue entity (Anthem). The BC/BS Plan code(s), along with any number of Tax IDs, D-U-N-S, NAIC Company Codes, etc., etc., seem to be all perfectly acceptable keys to use for arriving at (or "discovering") the same CPP - part of a general requirement that has nothing to do with being "wedded" to any particular type of identifier. We have not yet discussed how identifiers would be qualified as search keys, and I was suggesting one possible means based on X12 coded element qualifiers - in order to avoid re-inventing the wheel. Other methods might involve the use of URNs (IETF Uniform Resource Names), but that's getting a little afield for the time being. To allay Ken Fody's concerns that "not all Plans want to use [the BCBS plan code] on the standard transactions," let me emphasize that the example showed "discovery" of Anthem's CPP based on any one of its plan codes. Once the CPP is found, the junk inside the CPP would say where to deliver transactions (the Delivery Channel) and the ISA receiver qualifier and code to use. If Anthem were to prefer to have its NAIC company code used as the Receiver ID, that's perfectly possible with the requirements I've previously suggested in "Why do we flap our lips so much about the ISA Receiver ID?," from 12 April, at http://www.mail-archive.com/routing%40wedi.org/msg00438.html. I have a tendency to write in prose, as if describing a system that already works - when in fact we all know we haven't written the specs yet! But I fancy that I'm setting forth the "Grand Vision," and (preferably) someone else is busy compiling my musings as a set of requirements within the respective Working Paper groups. Is it working? I'm not trying to shove anything down anyone's throat, but y'know: searching on various identifiers to "discover" CPPs does seem to be something people can use - and the ebXML Registry already supports this. William J. Kammerer Novannet, LLC. +1 (614) 487-0320 ----- Original Message ----- From: "Fody, Kenneth W." <[EMAIL PROTECTED]> To: "'William J. Kammerer'" <[EMAIL PROTECTED]>; "'WEDi/SNIP ID & Routing'" <[EMAIL PROTECTED]> Sent: Tuesday, 30 April, 2002 05:47 PM Subject: RE: Searching on Blue Cross Blue Shield Association Plan Code That "mumbo-jumbo" is a fairly accurate, albeit abbreviated description of the process. :-) The Local Plan, where the provider is located, accepts a transaction and contacts the Plan where the member is from to determine if the person is eligible for coverage, whether the coverage includes the service provided, and what copays or coinsurance should be applied. Upon receiving this response, the Local Plan processes the claim and responds to the provider. The choice for the provider is whether they want to connect to one local Plan or 50 some odd Plans all around the country. As for using the Blue Plan identifier, not all Plans want to use that identifier on the standard transactions. The ones I am familiar with are using the NAIC code. Furthermore, with HHS slated to issue a Payer ID regulation, I think you will find it difficult to influence Plans to change their processes prior to the HHS regulation being issued. Ken Fody Independence Blue Cross -----Original Message----- From: William J. Kammerer [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 30, 2002 11:44 AM To: 'WEDi/SNIP ID & Routing' Subject: Searching on Blue Cross Blue Shield Association Plan Code A correspondent has confirmed that the most powerful ID for identifying BC/BS entities is the Plan Code. He said it was used in several inter-plan claims exchange systems and is universally used by all Blue plans on membership cards. Which is true enough, considering my own Anthem card shows plan codes of 332/834 (Institutional vs. Professional) on the front. Now it seems reasonable that my doctor ("shorthand" for saying his staff, software, billing agent or Clearinghouse - let's not get pedantic here) could take the "834" and look up Anthem's electronic Partner Profile (CPP) in the Healthcare Registry to see where to send claims or eligibility inquiries. Obviously, "834" by itself doesn't mean much - it has to be qualified by some code to say that it is a Blue Cross Blue Shield Association Plan Code (in both the CPP and the Registry search key). The first place to look for such qualifiers would be the X12 ISA Interchange ID Qualifier - even though the BC/BS Plan Code is obviously not a HIPAA compliant ISA receiver ID. Such an animal doesn't appear there, but D.E. 66 - Identification Code Qualifier - used in the NM1 does have code value AD meaning "Blue Cross Blue Shield Association Plan Code." So the Registry search key could be shown (stylized) as something like 66:AD:834 (meaning D.E. 66 code value AD qualifies value 834) which could be used to locate Anthem's CPP (assuming Anthem placed a list of all their associated plan codes in their CPP: 160 and 660 for Kentucky, 130 and 630 for Indiana, and 332 and 834 for Ohio). There's no reason the Healthcare CPP parts which specify Delivery Channels could not account for all plans using the same or different EDI portals, depending on Anthem's preferences. I'll leave the details for defining this stuff in the CPP to the volunteers who are authoring the "Elements of the Healthcare CPP" working paper (Marcelee Jackson, Dave Minch, Dick Brooks and Chris Feahr). Other persons familiar with BC/BS have mentioned in the past some mumbo-jumbo about how claims are submitted to the BC/BS home office where the provider is located, which in turn forwards the claims to the BC/BS of the patient. Was that done merely as a convenience to providers? And would it still be advantageous now that EDI portals of the particular patient's BC/BS could easily be located for direct submission? William J. Kammerer Novannet, LLC. +1 (614) 487-0320
