William,
At IBC, we will be performing all front-end X12 processing (compliance, formatting, enveloping, etc.) for one of our subsidiaries. Submissions will then be routed to them based on GS03, which submitters will be required to populate with the correct NAIC. I would be very interested in hearing what the consensus is on GS03 usage, since, like Highmark, we plan to use that element for internal routing. As we are discovering in many small ways as we begin to test with external entities, the "sound conclusions" we have drawn about the use of each element may not always fit with the conclusions others have drawn from the same IGs. Michael Lachenmayer Independence Blue Cross Ph: (215) 241-9453 Fx: (215) 241-4134 -----Original Message----- From: William J. Kammerer [mailto:[EMAIL PROTECTED]] Sent: Friday, August 09, 2002 11:12 AM To: WEDi/SNIP ID & Routing Subject: Of course, we could go on speculating forever about how GS03 is used... Of course, we could go on speculating forever about how GS03 (the Application Receiver Code) is used today in the "real" world (as opposed to the rarefied "future" world I inhabit!). But other than Highmark, no one has yet contributed information on how they go about using the GS for internal routing. As you'll recall, Highmark splits functional groups off to different EDI "gateways" depending on whether "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. If we had a couple more examples, then perhaps manageable use cases might fall out of them. I apologize if others, aside from Highmark, have contributed valuable concrete insight regarding functional group processing - it's not unusual for me to misplace stuff; just re-send the information to the list, or to me privately if you prefer. 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:35 PM Subject: RE: 276 routing question, esp. interested in Clearinghouse guru's opinion Kepa, Your comments indicate why it's critical that these processes be modeled with appropriate use cases so that requirements for any modifications to the CPP specification can be accurately identified and then requested of the OASIS CPP/A TC. Rachel -----Original Message----- From: Kepa Zubeldia [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 07, 2002 9:45 AM To: William J. Kammerer; WEDi/SNIP ID & Routing Subject: Re: 276 routing question, esp. interested in Clearinghouse guru's opinion William, If the CPP cannot accommodate multiple GS03 values, then the CPP needs to be fixed. This is a common practice. Here is where we need to start separating the "payer ID" from the EDI ID. It will be very likely that multiple payer IDs will be funneled through a single EDI ID, like a clearinghouse. In those cases each of the payer IDs would have a CPP that indicates what are the values usable in GS03 for that payer. And what are the EDI ID(s) that that payer can use, in case the payer uses more than one clearinghouse. Then the CPP for the clearinghouse should not specify the GS03 if it is going to conflict with the payer's GS03 request, or, alternatively, the clearinghouse could ignore the incoming GS03s and populate the outgoing GS03s out of the Clearinghouse's own algorithms. But, it will be common for a clearinghouse to send different GS03s to the same payer. For example, a payer that has multiple offices may want to get their files "sorted" that way. Or they may want the claims and the encounters separated into different functional groups. This is the sort of things that Clearinghouses do all the time. And for the providers, they can probably ignore it, they just send all their claims to the clearinghouse under one functional group, and let the clearinghouse deal with the messy part of splitting and distribution. But for those providers that do not use a clearinghouse, the payer will need to specify these (and many other) values in the CPP. If it has to be in a human readable part of the CPP, so be it. But it better be there. Just a thought. Kepa 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. CONFIDENTIALITY NOTICE: This E-Mail is intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you have received this communication in error, please do not distribute and delete the original message. Please notify the sender by E-Mail at the address shown. Thank you for your compliance. 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.
