If special handling requirements can be expressed in a machine readable manner, then the CPP electronic partner profile (or a "Legacy EDI" extension thereof) does indeed seem to be the natural place for carrying the information. Otherwise, if only English text can describe the handling requirements (e.g., functional group processing), then free text in either the CPP or the companion guide seems okay by me - I have no strong preference.
Let's take Highmark's GS03 requirements: "V" (vision claims), "W" (if an institution is in its Western Region), or "C" (if in its Central Region) is appended to its NAIC in the GS Application Receiver Code. I don't see how you could described this mechanically. How would a provider know whether she's in the "Western" region as opposed to "Central" (let alone, "Eastern")? Wouldn't she have to be told that by Highmark? Either she has to "introduce" herself at EDI enrollment time with her demographics so the payer can return the appropriate suffix for her to use, or the companion guide (or other free text in the CPP) has to be sufficiently unambiguous so she can determine her region on her own (e.g., these states are "Western," and these are "Central"). In cases like these, where instructions can't be mechanically shared ahead of time in the CPP, I don't see how any but manual effort can resolve these issues. Now, Rachel has brought up the topic of ebXML CPAs, or Collaboration Protocol Agreements. It might be simplest to think of CPAs as XML files resulting after a string of "electronic" negotiations between partners - the customized "Trading Partner Agreement." I described the CPA earlier as being "... in the realm of science fiction. Theoretically, a provider would introduce himself to the payer with his CPP...Software at either end would electronically negotiate terms, resulting in a CPA which binds the provider and payer in a bi-lateral trading relationship." So, in order to eliminate manual intervention in forming the "contract," the provider's ebXML software would send a message to the payer saying something like "Yoo hoo, Big Payer! I wanna send claims to you. This is my name, address, Tax Id and National Provider ID." And somehow the payer will respond with "It's okay to send me claims; I see you're in one o' them big rectangular states out West - make sure you use '76378W' in the GS03 Application Receiver Code so I know you're in the 'Western Region" and I can properly route claims within my own organization. Everything else you need is in my CPP and companion guide." Don't ask me how that dialog would be represented in XML. Needless to say, software (at either end, mind you) like this sounds hideously complex and expensive. Wouldn't it be a good deal simpler for the payer to just be prepared to split incoming transactions itself, as it sees fit? Isn't it enough of a miracle that the provider manages to get well-formed and compliant HIPAA transactions to the payer's front door-step? William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 ----- Original Message ----- From: "Rachel Foerster" <[EMAIL PROTECTED]> To: "'WEDi/SNIP ID & Routing'" <[EMAIL PROTECTED]> Sent: Thursday, 08 August, 2002 12:31 PM Subject: RE: 276 routing question, esp. interested in Clearinghouse guru's opinion Chris, I don't think so. A companion guide should be the specifications of that company's implementation of a given transaction set. Identifying which identifiers to use where/when/for what purpose is a logical and natural use of the CPP. The CPA is then the result of the negotiation between two enterprises of their published capabilities in the CPP. Rachel -----Original Message----- From: Christopher J. Feahr, OD [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 06, 2002 9:41 PM To: William J. Kammerer; WEDi/SNIP ID & Routing Subject: Re: 276 routing question, esp. interested in Clearinghouse guru's opinion William, Am I correct that any of these special handling requirements would be in the Companion Guide... and NOT in the CPP? -Chris ----- Original Message ----- From: "William J. Kammerer" <[EMAIL PROTECTED]> To: "WEDi/SNIP ID & Routing" <[EMAIL PROTECTED]> Sent: Tuesday, 06 August, 2002 10:12 PM Subject: Re: 276 routing question, esp. interested in Clearinghouse guru's opinion Though I'm sympathetic to Michael's subtle hint that ISA receiver IDs not be used to route interchanges among different internal application systems, I think we can accommodate Rachel's suggestion. Once the CPP for the receiver has been located (using some unique ID from one of any number of domains), it will be possible to specify what is to appear in the ISA (or GS) receiver IDs depending on the particular Delivery Channel selected. The receiver has every right to specify what goes in the GS receiver ID. And with no more effort on our part, we can likewise give her the capability to demand a particular ISA receiver ID (and qualifier). The converse is neither possible nor desirable: the receiver has no business - nor means within the CPP - to tell the sender what to use as his ISA or GS sender codes. William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 discussions on this listserv therefore represent the views of the individual participants, and do not necessarily represent the views of the WEDI Board of Directors nor WEDI SNIP. If you wish to receive an official opinion, post your question to the WEDI SNIP Issues Database at http://snip.wedi.org/tracking/. Posting of advertisements or other commercial use of this listserv is specifically prohibited.
