CPP and COB, was The use of Supplemental IG's
The text from the preamble reads the same way as the 837 IG; I see absolutely no requirement for a "prior trading partner agreement," which would imply paper and human intervention. Anyway, Kepa Zubeldia seems to have already covered this in Myth #233: COB claims, on HIPAAlive (16 Nov 2001), lifted here without any permission whatsoever: I think there is an HHS FAQ response from 11/2/2001 that is being misunderstood. Read the response very carefully: As a health plan we currently only conduct coordination of benefits (COB) with Medicare. Does the transaction and code set regulation require health plans to conduct COB with all health plans and health care providers even though they may not currently conduct COB with those entities? No. It is the health plan's decision as to whether they coordinate benefits electronically with another health plan or a health care provider. If a health plan decides to coordinate benefits electronically with another health plan or a health care provider, they must use the standard transaction for COB. It does NOT say that the plan decides whether to accept a COB claim or not. The plan MUST accept a claim that contains COB information, just as they must accept any other 837 claim. Then, once the plan has accepted a claim with COB information, the plan is not required to actually coordinate the benefits with another plan, unless they have agreed to do so. If the plan does not want to coordinate benefits, that is their choice. But, if they make that choice, they would have to pay the claim as primary. Probably not a good business practice. :-) The reason behind this is that an 837 is a claim. With or without COB information in it, it is still a claim. The plan does not need to support the COB business functionality, but they must accept the claim and adjudicate it. And, if they desire to coordinate benefits, they cannot ask for a paper version (photocopy of original EOB/RA) of the COB information that was already present in the electronic claim. I hope this helps clear up the confusion in this area. Actually, it seems Kepa has long ago solved the problem for us, and it appears there's no need for trading partner agreements (between payers) if I've read him correctly. That's all I want to know. If so, we don't have to do anything at all within the CPP to support (i.e., "announce") COB capability: it's automatic and implicit. One problem down, 2654 left to go. 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: Friday, 05 July, 2002 02:14 PM Subject: RE: The use of Supplemental IG's 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 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.
RE: The use of Supplemental IG's
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 gro
Re: Open-edi, Health Care, ebXML and CPP/A
The "use of process analysis resulting in business scenarios" may be "a critical and essential concept to Open-edi, ebXML and CPP/A," but I doubt we're going to be doing much of that stuff here in ID & Routing. All we have to work with are the existing HIPAA standard transactions - that much is not going to change. We are not redesigning healthcare e-commerce from the ground up, and I doubt many of us would have signed up for this project if that were required. Dick Brooks, our liaison to the OASIS ebXML CPP/A Technical Committee, has already suggested we make do with the simple default 'file transfer' business process for exchanging HIPAA transactions. There is no need to scare folks into thinking we'll require elaborate business processes. See "RE: CPP Data elements draft for comment" (05-10) at http://www.mail-archive.com/routing%40wedi.org/msg00558.html. The deepest we'll have to get into "business analysis" is to analyze what the HIPAA IG business models already say - like what we'll have to do in order to design the CPP so COB support can be "announced," as I illustrated just a while ago. "Open-edi" is indeed the correct term for describing scenarios of trading that don't involve prior agreement and human intervention between parties; supposedly parties are to agree to conform to certain implementations of "FSV related standards." In effect, this has already been provided for by the HIPAA TCS Reg, which incidentally also supplies the "competent legal environment." I don't mean anything else by the term "Open-edi," and it seems to be consistent with what's said in the Open-Edi Reference Model. I can't imagine - for the purposes of our project - any need for us to get further into the mind-numbing details of FSVs and BOVs and stuff like that. 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 08:02 PM Subject: RE: Open-edi, Health Care, ebXML and CPP/A Since the term Open-edi has been used on numerous occasions I felt it important that it be put into the appropriate context of the ISO model and ebXML. Use of the term Open-edi when you actually mean something else can only serve to confuse rather than clarify. Whether one chooses to review the earlier version of the Open-edi Reference Model or the current one being ballotted is irrelevant to having a conceptual understanding of what Open-edi is and how it fits into an overall electronic business framework, including ebXML, from which the CPP/A is drawn. It's also important to know that the CPP/A as presently spec's expects that specific business process scenarios, etc. that each of the trading partner's support be identified. The use of process analysis resulting in business scenarios is a critical and essential concept to Open-edi, ebXML and CPP/A. 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 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.
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 longe
