Dave: I took a look at my insurance card for Anthem Community Choice, and besides my ID no. and group name, the BC/BS plan code of 332/834 (Inst. vs. Professional) appears on the front. There're also the usual phone numbers, and the claim submission mailing address. So how does a provider (today) know how to go from the respective Blue Cross/Blue Shield plan no. to an EDI Identifier?
But I certainly hope *NOT* that "the best identifier of all for discovering the CPP is that contact address or phone number..." I want the payer or plan EDI identifier to appear directly on the insurance card - in order that things can be automated (without phone calls and paper). Speaking of Plans, Peter Barry presented a paper on Identifiers at the HIPAA Summit West in San Francisco last month. Maybe he can be persuaded to share the paper with the group. But anyway, the impression I came away with is that the National Plan ID will appear on the patient's Health Identification Card - and by using the National Plan ID as a key, you can access the National Plan ID database whence you're cross linked to the entities processing those plans (e.g., payers, employers, Third party administrators). If those cross links were to CPPs, then the National Plan ID database itself would supplant any need for a separate CPP Registry for payers. However, I wouldn't bet the farm on the possibility there would be any government sponsored databases available and running in time for H-day! - even though the HIPAA Funding proposal in the Bush Budget includes "$34.5 million to implement a system to assign unique identifiers for providers and health plans." William J. Kammerer Novannet, LLC. +1 (614) 487-0320 ----- Original Message ----- From: "Dave Minch" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, 02 April, 2002 09:36 PM Subject: RE: Are only 15 characters in the ISA receiver ID enough? If I can sum up the last few days of discussion that I have just waded through: as a transaction sender I should be able to follow the workflow below, starting with the responsible party's insurance card: 1) Copy the payer's identifier information from the card into a query transaction (note there are usually 3 key pieces of information on this card -- Group ID, Plan ID, Group/Plan Name -- and we need to understand which or what combination is "copied into the query" as well as what the query looks like); 2) Bounce the query transaction off of a DNS to get an electronic address of where the receiver's ebXML-CPP is stored (and, perhaps, learn a little more about the payer like data in Kepa's XML tag example); 3) Create a specifically formatted transaction to query for the ebXML-CPP (I'm still not clear on where the CPP itself is stored - is it in the payer's server, or an independent registry like the ebXML registry, or is Kepa suggesting the entire CPP could be contained in the tag? Clearly, wherever it is, it needs to be kept current, and would certainly be in the best interest of the receiver to keep it so - even without Federal penalties); 4) Take the "EDI Address" information for the transaction desired and populate the various trading partner fields in my transaction generation software. 5) Generate the transaction. The ISA08 would contain the ultimate interchange receiver's EDI identifier (if I'm the provider and the transaction is a claim, then the address is the payer's), and the other EDI Address information from the CPP would tell me where to route the transaction (payer itself, a third party administrator, CH, etc.) along with the communication details of the actual receiver. It is then up to my transaction generator software to be smart enough to group transactions together into 1 envelop (ISA) when there are multiple claims for the same payer. Following this logic, I would therefor be required to send multiple transactions (multiple ISA/IEAs) for different payers using the same third party admin or CH since ISA08 is the payer's, not that of the initial transaction destination. I must admit that this is a new way of looking at the X12-837 message for me - I was assuming that 1 ISA/IEA going to 1 place (like a CH) would contain all claims going to that location, irrespective of the ultimate destination. I like it - it gives me the added advantage of getting 997 acknowledgements back by payer since they are in separate envelopes, but it requires that I deliver many envelops to the same destination (I don't think this is any great amount of added effort, is it??)... As a transaction receiver, it would be 1 step simpler in that the identifier provided to me in ISA06 would be a unique ID, under which the sender would have listed their CPP. So the steps would be exactly the same for the receiver to respond to a sender, but the "identifier" used in step 2 would be that found in ISA06. This tells me that there needs to be at least 2, and possibly more identifiers that can be listed in a DNS that all point to the same CPP. If that is the case, then the question of DUNS vs TIN vs NAIC vs the National Provider ID can be addressed later, because in fact, if a trading partner wants to be found, they'll list themselves under all that apply. In fact, I have just started a spot review of insurance card examples we have on file here, and there is more commonality than I would have thought, but not where I would have expected it. The only 2 pieces of data that are always present are: 1) Send claims to: <address> (or) if "out of area" admission is needed, call: <phone number> 2) For eligibility/benefit information contact: <phone number or web address> For all of you 198 members of this listserv: please take 30 seconds to look at your insurance card, and send me a note if this information isn't on your card in some form. Perhaps the best identifier of all for discovering the CPP is that contact address or phone number... Dave Minch T&CS Project Manager John Muir / Mt. Diablo Health System Walnut Creek, CA (925) 941-2240
