Dale: Didn't I say the ZZ-qualified proprietary ID would not be a problem? i.e., once the CPP was found, the EDI Address would inform the sender that the ISA receiver was to be a ZZ-qualified proprietary ID. I just wanted to make sure we all understand that the sender would have no way, a priori, of knowing what proprietary ID to use in the ISA receiver field until he accessed the receiver's CPP.
In your process step 2, you say "a manual process [would be] totally unacceptable." I don't agree. Until translators are CPP enabled - i.e, they can update their trading partner tables with information from the CPP which has been automatically "discovered" - the sender can manually lookup the CPP and update his own trading partner files. I don't think that's particularly onerous, and he can do it all by himself. Having it automatically done by the translator is just icing on the cake. What we definitely wish to avoid, I believe, are onerous EDI enrollment procedures, negotiated TPAs, and other sundry hurdles and hoops placed in the way of providers who merely want to use the standard transaction sets. Not only are these processes exceedingly manual, but they may take months to consummate (per Marcallee Jackson) - surely an impediment to frictionless e-commerce if there ever was one! Doug Renshaw, of Highmark, said yesterday "We welcome providers or their billing agents to submit claims to us direct. We assign them an EDI Trading Partner number (proprietary number) and give them instructions on how to dial in to our EDI interface. This is how we connect today." Fortunately, he adds: "I am not advocating our process as the best mechanism for the industry moving forward." A common case will involve claims coming in from one of a payer's participating providers who has never used EDI before. Remember, HIPAA says you have to take their claim if presented in a standard electronic format - and that presumably means without placing any onerous hoops to jump through, such as TPAs, EDI enrollment, or waiting around for payer-assigned IDs, logon IDs and passwords. Less common would be a claim from a non-par provider, who wants to send a claim to be paid to the patient (who does have a contract with the payer) - one with whom the payer has absolutely no leverage and to whom the payer *must* provide a means of submitting standard transactions electronically. I have not been too concerned with CPAs heretofore. CPAs, or Collaboration Protocol Agreements, are in the realm of science fiction. Theoretically, a provider would introduce himself to the payer with his CPP, saying he wanted to send claims electronically. Software at either end would electronically negotiate terms, resulting in a CPA which binds the provider and payer in a bi-lateral trading relationship. I suppose this is where Doug Renshaw could vet the provider, and give the provider a user ID, password and proprietary provider ID - all automatically in a matter of seconds. I'm not holding my breath waiting for this to happen, though! Wouldn't it be much simpler for Doug to describe, in his own CPP, an open portal for sending standard transactions to Highmark? William J. Kammerer Novannet, LLC. +1 (614) 487-0320 ----- Original Message ----- From: "dalegibbs" <[EMAIL PROTECTED]> To: "WEDi/SNIP ID & Routing" <[EMAIL PROTECTED]> Sent: Friday, 12 April, 2002 12:14 PM Subject: RE: Why do we flap our lips so much about the ISA Receiver ID? William, I agree with you about using the ZZ in the ISA Receiver ID Qualifier, but from a technical point of view, you could. If you use the NAIC from an insurance card as a key to the CPP to get ISA Receiver ID and Qualifier (among other information), then a ZZ would not be a problem. In fact the ISA Receiver could contain DUNNS, DUNNS+4, FEIN, NAIC, etc. The only requirement should be that the content of the ISA Receiver ID correspond to the code placed in the ISA Receiver ID Qualifier and that both values be consistent with HIPAA IG requirements. Process (assuming everyone is in agreement on CPP/CPA) would be very straight for a provider. 1. Obtain NAIC code from Insurance card 2. Is insurance NAIC already on your system? If no, search CPP directory and extract information (requires providers system to store insurance information and be able to extract it when they create ASC X12 claims document. This will require either a significant update to their current system or new software. The other option would be a manual process which is totally unacceptable) 3. Do we need to create a CPA before submitting any kind of document? How would this work? What is the process? 4. Once CPA created (how long will this take?) Create ISA claim document using ISA Receiver ID and Qualifier extracted from CPP. 5. Send document based on CPP EDI Address requirements Is this the general process we are talking about. Please help me fill in the gaps noted above. Dale Gibbs E-COM Advisor 614.871.2314
