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 -----Original Message----- From: Kepa Zubeldia [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 02, 2002 1:27 PM To: Christopher J. Feahr, OD; William J. Kammerer; WEDi/SNIP ID & Routing Subject: Re: Are only 15 characters in the ISA receiver ID enough? Isn't the small size of these identifiers the main reason why we have to "map" the identifiers into an address? It is still trivial and reliable and cheap to do this using the currently existing DNS, using a small XML tag in the TXT component of the DNS directory, just like William has his setup. The XML code can point to a URL or a phone number or any other sort of "address" and specify additional parameters like hours of operation, transactions supported, etc. If we could just agree on one way to do this... It does not have to be perfect. It does not have to be complete. Maybe it does not even need to cover all the possibilities. But it needs to be useful/usable TODAY. Just a thought... Kepa
