Actually, the ISA receiver ID would generally *not* be the key into the Healthcare CPP (Electronic Trading Partner Profile) Registry, for the simple reason you would not know what to use as the ISA Receiver ID until you had obtained the CPP for the recipient - which in turn tells you which ID to use!
Imagine this scenario: a provider wants to send a claim to Big Insurance Co. She knows *some* payer ID either by (1) serendipity, e.g., she remembers the NAIC for Big Insurance Co., or (2) obtaining it indirectly through the particular National Plan ID (*future* - remember National Plan ID hasn't yet been implemented or funded) which appears on the patient's insurance card, or (3) obtaining the EDI ID (in this case, the NAIC) directly from the insurance card. Either the NAIC company code or the National Plan ID could be used to search the Healthcare CPP Registry (notice I no longer call it the "WEDi/SNIP" Registry!) to obtain Big Insurance Co.'s CPP. The CPP then contains the EDI Addresses to be used (depending on criteria such as Functional Group ID) and the EDI ID to be used in the ISA Receiver field (in this case, Big Insurance Co. prefers - or mandates - the NAIC). The provider must use the Receiver ID specified in the CPP, because the EDI Address to which the interchange is sent could very well be a VAN or Clearinghouse that only knows the payer by the NAIC. Or perhaps the Clearinghouse only knows the payer by some *contrived* (CH-assigned) receiver ID - neither the NAIC nor the HCFA carrier code or any other standard ID. In this case, the selected EDI Address in the CPP would say which qualifier and ID to use in the ISA receiver field (and it could be a ZZ "mutually-defined" ID). I want to emphasize I am not back-peddling on my abhorrence of the ZZ here: the "mutually defined" ID is not being used as a *key* into the Healthcare CPP Registry (it can't be, because the provider wouldn't know it ahead of time). The EDI Address in the CPP is simply saying the provider has to stick in this qualifier (ZZ) and an arbitrary receiver ID into the ISA before sending the interchange. It works the same way when the payer wants to send an application message to the provider. And remember, standard transactions from the payer can be unsolicited: paper claims could result in electronic 835 EOBs! The payer might only have the FEIN (Tax ID) of the provider available. He uses the FEIN to search the Healthcare CPP Registry to locate the provider's CPP. The provider has said she accepts 835 EOBs at a particular EDI Address. Perhaps she is to be identified in the ISA receiver ID with her D-U-N-S, with a specification in the EDI Address that says the transaction set must be encrypted using X12.58 and sent through a VAN (since VANs are not covered entities generally, PHI has to be hidden from them using encryption). This illustrates the situation where a FEIN is used as a key into the Healthcare CPP Registry, but the D-U-N-S is the ISA Receiver ID. Again, the ISA Receiver ID was not used as the key - it wasn't even known until the CPP was obtained! Or maybe the provider uses a Clearinghouse, and her CPP EDI Address has said 835 EOBs (or even all transactions) go to the Clearinghouse, using a CH-assigned ID in the receiver field. In this case, a FEIN was used as the key into the CPP Registry, but the ISA receiver ID is a ZZ-qualified CH-assigned provider ID. Since the provider is a customer of the CH, she knows ahead of time what her proprietary CH-assigned receiver ID is, and can place it in the EDI Address so senders know what to use in the ISA. If it seems I'm softening on the ZZ qualifier, I'm not. Consider the first scenario again, where the provider has "discovered" Big Insurance Co. in the CPP Registry. In this case, the EDI Address for claims says to send the 837 to a clearinghouse. It's perfectly okay for Big Insurance Co. to say in the EDI Address within its own CPP that a ZZ qualified receiver ID be used in the ISA - after all, Big Insurance Co. is a customer of the Clearinghouse and has long known its contrived CH-assigned payer ID. But there is no way to tell the provider she must use a CH-assigned sender ID - she's not even a customer of the Clearinghouse, and this may be the first time she's ever sent anything through that Clearinghouse. It would be mighty presumptuous of the CH to insist that the non-customer provider identify herself by a proprietary CH-assigned provider ID - as if it could even be done technically. William J. Kammerer Novannet, LLC. +1 (614) 487-0320 ----- Original Message ----- From: "dalegibbs" <[EMAIL PROTECTED]> To: "WEDI ID & Routing" <[EMAIL PROTECTED]> Sent: Thursday, 11 April, 2002 02:31 PM Subject: FW: A proposed work plan for this group I have been following this tread for some time and am fascinated over the amount of time being dedicated to the ISA Receiver ID. It really does not matter what the ISA Qualifier and Receiver ID are since they will be used as a key to look up an EDI address and routing information. As long as the information has been set up as a key in the table (or database) so people can find it, who cares what it is? Can we agree that whatever the IG defines as possible entries is fine with us and get on with the process of defining EDI Addresses and routing techniques. Dale Gibbs E-COM Advisor 614.871.2314
