While the 837 IG may not require a prior trading partner agreement for the payer-to-payer COB model, the final transaction rule on page 50336 of the preamble certainly does.
Response: Coordination of Benefits can be accomplished in two ways, either between health plans and other payers (for example, an auto insurance company), or from a health care provider to a health plan or other payer. The choice of model is up to the health plan. Under this rule health plans are only required to accept COB transactions from other entities, including those that are not covered entities, with which they have trading partner agreements to conduct COB. Once such an agreement is in place, a health plan may not refuse to accept and process a COB transaction on the basis that it is a standard transaction." Rachel Foerster Principal Rachel Foerster & Associates, Ltd. Professionals in EDI & Electronic Commerce 39432 North Avenue Beach Park, IL 60099 Phone: 847-872-8070 Fax: 847-872-6860 http://www.rfa-edi.com -----Original Message----- From: William J. Kammerer [mailto:[EMAIL PROTECTED]] Sent: Friday, July 05, 2002 10:26 AM To: 'WEDi/SNIP ID & Routing' Subject: Re: The use of Supplemental IG's The CPP Electronic Partner Profile will be much more attractive for payers to advertise their capabilities if it allows them to avoid as much up-front agreement with partners as possible. And if payers are prone to use CPPs (whether distributed privately by e-mail, or via the Healthcare CPP Registry), then every other player in Healthcare is likely to jump on board. The HIPAA 837 IG certainly does not mandate a prior agreement between the respective payers in the payer-to-payer COB (Coordination of Benefits) model: at the time the guide was written, the authors may not have imagined there was any other way for payers to communicate their willingness to perform COB. But now that we will have the CPP (legacy EDI extension) to advertise one's capabilities, there may not be any further need for messy bi-lateral contracts and agreements! For example, if a payer is willing to conduct the 269 Benefit Coordination Verification transaction with any other payer - perhaps assuming that payer has been "certified" - we can make the CPP capable of "announcing" this quite adequately. If a payer has advertised its ability to handle the 269 by enumerating the 269's Version / Release / Industry Identifier Code (e.g., 004040X122) as one of its supported transactions, and maybe included the relevant certification credentials, would that be enough to supplant the need for an explicit agreement between payers to do COB? Would it be enough to let providers know that the payer does COB? I'm assuming here that being able to "do" the 269 (with other payers) sufficiently implies the payer can do both COB models using the 837 as a COB request. Obviously, for any particular set of exchanges (between any one provider and the primary and secondary - or even tertiary - payers), there are a number of requirements that all have to be satisfied, including whether the provider itself can handle 835s. Even if the 269 isn't supported (by both payers), can we come up with some other alternate and elegant technique within the CPP to advertise COB capabilities? Further, is the mere ability to perform COB (which, through a little bit of work, I can't imagine the CPP couldn't handle) the same as saying one will do it with all comers? As an aside, companion guides are certainly relevant to our work in automating the linkages between providers and payers. Surely, objections to our specifications and recommendations will come from some payers who will say automation is impossible because they have "special" requirements that they must ensure the provider abides by. If these "special" requirements are illusory - and in contravention of the HIPAA regs - then we are better prepared to defend the CPP's lack of support for them. As an example, I don't want us to have to spend any time devising junk within the CPP for specifying the EDI delimiters that will accepted at a particular portal (i.e., EDI Address). 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: Wednesday, 03 July, 2002 07:56 PM Subject: RE: The use of Supplemental IG's Irrespective of the points you raise below, the use, and/or proliferation of companion guides is not an issue that this work group can resolve. We've already identified that any CPP/A for health care just needs to be able to point to any companion guide(s). Endlessly debating the pros and cons of companion guides doesn't further the objectives of this group. Furthermore, your reference to the payer-to-payer COB model requires a prior agreement between the respective payers per the HIPAA 837 IG. I agree with Paul Weber that this discussion be moved to another WEDi SNIP work group's list. Rachel Foerster Principal Rachel Foerster & Associates, Ltd. Professionals in EDI & Electronic Commerce 39432 North Avenue Beach Park, IL 60099 Phone: 847-872-8070 Fax: 847-872-6860 http://www.rfa-edi.com -----Original Message----- From: William J. Kammerer [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 03, 2002 2:13 PM To: 'WEDi/SNIP ID & Routing' Subject: Re: The use of Supplemental IG's A number of friction points have to be eliminated if we are to automatically "hook up" players in healthcare EDI. Unsolicited transactions from providers to payers (or even Payer-to-Payer, in the COB Model) would have to be supported without onerous up-front enrollment and coordination if our dreams of frictionless HIPAA e-commerce are to be realized. The discussion of companion guides arose out of the original thread entitled "Non-participating/out of network providers." Heretofore, the lack of standard transactions may have been one of the primary reasons providers did not electronically engage infrequently encountered payers - as opposed to vague and unspecified "financial reasons." Now that standard transactions are available, one-off implementation guides are no longer an impediment to the free exchange of healthcare administrative transactions - that is, unless these "companion" guides get out of hand. As I've amply demonstrated, this is starting to happen: if each payer insists on arbitrarily changing the syntax and meaning of the HIPAA standard transactions through their "companion" guides (as CMS has done), there may be less point in removing the other barriers to exchanging transactions (e.g., paper enrollment). Companion guides were meant to assist partners so they could understand what pieces of information you are going to extract from the standard transactions and how they would be used in adjudication. I don't even think there's a "fine line" between "we will use the tax ID in preference to the DUNS for identifying providers" or "all amounts are expected to be in U.S. Dollars" - (carefully phrased semantic usages) - and wholesale rewrites of the HIPAA IG syntax rules. The former can probably be handled quite elegantly, for example, by the sender always including the Tax ID and DUNS, if available - as recipients can't demand that information they don't need be excluded. Unfortunately, changing the syntax usages requires separate maps or similar gymnastics for each partner. There's no need to bring this issue up on the Transactions listserve unless Paul Weber or others here fear that the purpose of companion guides is widely misunderstood. Our CPP electronic partner profile can support companion guides; left to determine is just how automated we can make that support. Since (well thought out and HIPAA compliant) companion guides are part of the process of setting up new partners, discussion of them is obviously relevant to our goal of using the CPP to automatically configure partner profile information. 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. 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.
