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
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 group's list. Rachel
Re: The use of Supplemental IG's
Just out of curiosity, I went to the CMS web site to see if there were any Program Memos or Transmittals that had stuff about restricting inbound delimiters Sure enough, one of the first I picked out, Transmittal B-01-71 of NOVEMBER 8, 2001, says incoming 837 Professional transactions must utilize delimiters from the following list: , *, ~, ^, |, and: - exactly the situation I was bemoaning! What if another payer wants me to use the group, record and unit separators (hex 0x1D, 0x1E and 0x1F) only? Arbitrary special conditions for every payer! - precisely the problem standard transactions were meant to take care of! To top it off, I see where it also says Currency code (CUR02) must equal 'USA' - I take this to mean that CMS wants all amounts in U.S. Dollars, even if the billing provider is Canadian, for example. But this can't possibly make any sense since the currency code must be one of the internationally recognized codes from ISO 4217. USA is not among them - USD is the symbol for the U.S. Dollar. So would I have to make a special exception in my mapping for just CMS in order to use an invalid currency code - because that's just the way they do it. My data wouldn't even make it past a halfway self-respecting compliance analyzer using CMS' made-up codes. Or perhaps it was a typo? I have no problem with a companion guide that says what the payer is going to use from the particular standard transaction. But to reinvent the X12 and HIPAA IG syntax rules wholesale, as CMS is doing here, is clearly prohibited by the HIPAA TCS rule. I wouldn't be surprised if this kind of stuff becomes epidemic, and we're back to where we started from: one-off payer-specific IGs. For the purposes of our project, let's assume by October 2004 that we'll truly have standard IGs - and payers abiding by them! William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 - Original Message - From: Bruce T LeGrand [EMAIL PROTECTED] To: WEDi/SNIP ID Routing [EMAIL PROTECTED] Sent: Tuesday, 02 July, 2002 01:15 PM Subject: The use of Supplemental IG's SNIP But now individual EDI guidelines dictated by the payer are a thing of the past. As an aside, I do suspect that some payers will try to use companion guides in much the same way, thinking they're just renamed implementation guides. Except now, they will find that most of the (arbitrary) restrictions they place in these companion guides are unenforceable: I've even seen these guides say what particular X12 delimiters to use! A payer (or provider, or clearinghouse for that matter) must take a standard transaction as long as it conforms to the HIPAA IG: if the sender's delimiters are acceptable by the X12 application syntax rules and the HIPAA IG, the recipient should be the one doing the adapting. END Its not that I always want to be arguing against a position Mr. Kammerrer has taken, but I seem to find reasons all of the time. That said, payers are required to accept transactions. They are not required to adjudicate them, they are not required to do more that acknowledge the file with a 997. Thereafter, a status inquiry could be returned with a no record of this claim, and still meet the guidelines. Supplemental IG's are designed to ensure that this does not happen as often as it may otherwise. There are still business issues, not addressed adequately by the consensus process of the X12N group, yet, that require more specific information and usage. One payer that comes to mind immediately and is publishing a substantial supplemental IF is CMS, or more precisely Medicare Part A. If you think providers that file for part A claims are going to ignore this information, or this guide, you are sorely mistaken. I have cut a sample from a source: The Centers for Medicare Medicaid Service has issued updated guidelines for submitting Medicare Part A test claims in the ANSI X12N 837 Institutional format, which is required under the Health Insurance Portability and Accountability Act (HIPAA): The ANSI 837 v4010 Institutional Implementation Guide (IG) does not provide a place to report the start of care date for hospice outpatient claims. CMS has developed the following guidelines for submitting Outpatient Hospice claims via the 837 v4010 format: The 837 2300 loop Admission Date segment must be used to report the start of care date for outpatient hospice claims. Submit 0001 as a default hour and minute (HHMM) part of the admission date data element if the information is not available. To use the CR6 (Home Health Care Information) segment in the HIPAA 837 Institutional IG to report the start of care date for home health claims, all required segments must be used. CMS has developed the following guidelines for submitting Home Health claims via the 837 v4010 format: The 837 2300 loop Admission Date segment must be used to report the admission date/start of care date for home health claims. Submit 0001 as the default valued for the hour and
RE: The use of Supplemental IG's
Have to agree with Rachel. Please move this discussion elsewhere where we can get more folks involved. Perhaps transactions? - Original Message - From: Rachel Foerster [EMAIL PROTECTED] Date: Wed, 3 Jul 2002 11:18:24 -0500 To: 'WEDi/SNIP ID Routing' [EMAIL PROTECTED] Subject: RE: The use of Supplemental IG's Please excuse my confusion here, but I don't see how the use of companion guides is related to the challenges of addressing and routing. Are we getting off on a non-essential tangent to the primary goal of this group? 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: Tuesday, July 02, 2002 3:20 PM To: WEDi/SNIP ID Routing Subject: Re: The use of Supplemental IG's Just out of curiosity, I went to the CMS web site to see if there were any Program Memos or Transmittals that had stuff about restricting inbound delimiters Sure enough, one of the first I picked out, Transmittal B-01-71 of NOVEMBER 8, 2001, says incoming 837 Professional transactions must utilize delimiters from the following list: , *, ~, ^, |, and: - exactly the situation I was bemoaning! What if another payer wants me to use the group, record and unit separators (hex 0x1D, 0x1E and 0x1F) only? Arbitrary special conditions for every payer! - precisely the problem standard transactions were meant to take care of! To top it off, I see where it also says Currency code (CUR02) must equal 'USA' - I take this to mean that CMS wants all amounts in U.S. Dollars, even if the billing provider is Canadian, for example. But this can't possibly make any sense since the currency code must be one of the internationally recognized codes from ISO 4217. USA is not among them - USD is the symbol for the U.S. Dollar. So would I have to make a special exception in my mapping for just CMS in order to use an invalid currency code - because that's just the way they do it. My data wouldn't even make it past a halfway self-respecting compliance analyzer using CMS' made-up codes. Or perhaps it was a typo? I have no problem with a companion guide that says what the payer is going to use from the particular standard transaction. But to reinvent the X12 and HIPAA IG syntax rules wholesale, as CMS is doing here, is clearly prohibited by the HIPAA TCS rule. I wouldn't be surprised if this kind of stuff becomes epidemic, and we're back to where we started from: one-off payer-specific IGs. For the purposes of our project, let's assume by October 2004 that we'll truly have standard IGs - and payers abiding by them! William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 - Original Message - From: Bruce T LeGrand [EMAIL PROTECTED] To: WEDi/SNIP ID Routing [EMAIL PROTECTED] Sent: Tuesday, 02 July, 2002 01:15 PM Subject: The use of Supplemental IG's SNIP But now individual EDI guidelines dictated by the payer are a thing of the past. As an aside, I do suspect that some payers will try to use companion guides in much the same way, thinking they're just renamed implementation guides. Except now, they will find that most of the (arbitrary) restrictions they place in these companion guides are unenforceable: I've even seen these guides say what particular X12 delimiters to use! A payer (or provider, or clearinghouse for that matter) must take a standard transaction as long as it conforms to the HIPAA IG: if the sender's delimiters are acceptable by the X12 application syntax rules and the HIPAA IG, the recipient should be the one doing the adapting. END Its not that I always want to be arguing against a position Mr. Kammerrer has taken, but I seem to find reasons all of the time. That said, payers are required to accept transactions. They are not required to adjudicate them, they are not required to do more that acknowledge the file with a 997. Thereafter, a status inquiry could be returned with a no record of this claim, and still meet the guidelines. Supplemental IG's are designed to ensure that this does not happen as often as it may otherwise. There are still business issues, not addressed adequately by the consensus process of the X12N group, yet, that require more specific information and usage. One payer that comes to mind immediately and is publishing a substantial supplemental IF is CMS, or more precisely Medicare Part A. If you think providers that file for part A claims are going to ignore this information, or this guide, you are sorely mistaken. I have cut a sample from a source: The Centers for Medicare Medicaid Service has issued updated guidelines for submitting Medicare Part A test claims in the ANSI X12N 837 Institutional format, which is required
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 - Original Message - From: Paul Weber [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, 03 July, 2002 01:35 PM Subject: RE: The use of Supplemental IG's Have to agree with Rachel. Please move this discussion elsewhere where we can get more folks involved. Perhaps transactions? - Original Message - From: Rachel Foerster [EMAIL PROTECTED] To: 'WEDi/SNIP ID Routing' [EMAIL PROTECTED] Sent: Wednesday, 03 July, 2002 12:18 PM Subject: RE: The use of Supplemental IG's Please excuse my confusion here, but I don't see how the use of companion guides is related to the challenges of addressing and routing. Are we getting off on a non-essential tangent to the primary goal of this group? 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: Tuesday, July 02, 2002 3:20 PM To: WEDi/SNIP ID Routing Subject: Re: The use of Supplemental IG's Just out of curiosity, I went to the CMS web site to see if there were any Program Memos or Transmittals that had stuff about restricting inbound delimiters Sure enough, one of the first I picked out, Transmittal B-01-71 of NOVEMBER 8, 2001, says incoming 837
