I would add the following examples to the mix...
Just because a payer accepts an 837 containing 200 data elements does not mean it has to adjudicate (process) it using all 200 data elements. In a similar vain, if a payer has been processing a certain transaction for the past 100 years that requires using data element A, and now a provider has the option of sending elemement A, B, C, or D (as long as those data elements are part of the HIPAA transaction) the payer now has to accept the transaction containing elements B, C, and D. But that does not mean that the payer has to process the transaction using data elements B, C, or D. In this case, the payer should be able to "ask" its provider trading partners to only send element A - because that is the only data element that can be used to process that particular transaction. In order to process the transaction using B, C, or D, the payer would have to change its core business processes - which, as we all agree (I think), is not mandated by HIPAA. Paul ----- Original Message ----- From: Jan Root <[EMAIL PROTECTED]> Date: Monday, March 10, 2003 11:24 am Subject: Re: Accept v. Process Standard Transactions > Doug, > > I think I must respectfully disagree with your statement that > 'acceptingthe claim means entering it into the adjudication > system.' Let me know > if you disagree, but here is my logic: > > A payer's "business system" usually begins long before a claim > hits the > adjudication system, ergo, their front-end edits processes. Payers > havethe right to apply business decisions in front-end edits. For > example,a payer who does not process dental benefits, might > receive a perfectly > HIPAA compliant dental claim. It is my understanding that payers has > the option of rejecting the claim through their front-end edits > processwith the message of 'we don't do these benefits'. The > payer would also > have the option to accept the dental claim into their adjudication > system and then to deny it on the back side through an 835 'we > don't do > dental'. In both cases, the outcome is the same (the provider > receivesno dollars) but the reason is within the HIPAA model: the > claim is > rejected/denied for business reasons, not for format reasons. > > More Examples: Payers can reject if a provider submits a claim in an > incorrect format meaning the payer wants their home health claims > in an > institutional format and the provider submits a HIPAA compliant > professional format. HIPAA does not dictate WHICH claim format payers > must use for specific services. Payers can reject/deny for things > like'subscriber not found', 'provider not found' and a host of > this-claim-does-not-make-sense, > this-claim-does-not-comply-with-our-contract (assuming the > contract is > HIPAA compliant: e.g. the payer is not requesting local codes) or > we-don't-do-that-business issues > > The long and short of it is accepting a HIPAA compliant > transaction does > not defacto mean that it gets into a payers adjudication system. It > does mean the payer can't reject/deny it for format reasons. Assuming > the format is correct, the payer must reject/deny for business > reasons. > Paul's question is very critical from an operations/legal perspective. > It is a new way of thinking about how to handle transactions. The > challenge to the operational folks is how to maintain their business > needs and not cross the HIPAA line. Everyone is working this out for > themselves. While the outcome might be the same (the claim is > rejected/denied), the WAY its handled can make all the difference > from a > legal perspective. Here at UHIN in our Standards Committee we've had > many discussions about the fine line between 'accepting' a transaction > because it is HIPAA compliants, and 'rejecting/denying' a transaction > because it is bunk, from a business perspective. People are getting > more comfortable with where this line is but it takes time and a > lot of > thought. > > Jan Root > UHIN > > Doug Webb wrote: > > > Paul, Accepting the claim means entering it into the adjudication > > system. What the adjudication system does with it is determined by > > your business rules. HIPAA does not mandate what codes you pay for, > > and the completeness necessary to determine the proper payment. > > Improper coding is probably the most frequent cause of claim > > rejection, and it will continue to be so. In the same manner, > > accepting a query means doing the search requested and forming some > > type of response. "Not Found" is quite acceptable if the > information> given does not allow the query to succeed. The > opinions expressed here > > are my own and not necessarily the opinion of LCMH. Douglas M. Webb > > Computer System Engineer > > Little Company of Mary Hospital & Health Care Centers > > [EMAIL PROTECTED] "This electronic message may contain information that > > is confidential and/or legally privileged. It is intended only > for the > > use of the individual(s) and entity(s) named as recipients in the > > message. If you are not an intended recipient of the message, please > > notify the sender immediately, delete the material from any > computer,> do not deliver, distribute, or copy this message, and > do not disclose > > its contents or take action in reliance on the information it > > contains. Thank you." > > > > ----- Original Message ----- > > From:Paul Costello > > To: WEDI SNIP Transactions Workgroup List > > Sent: Friday, March 07, 2003 11:13 AM > > Subject: Accept v. Process Standard Transactions > > Group, > > > > I have a question regarding "accepting" and standard > > transaction and > > "processing" a standard transaction. > > > > I was under the impression that in order to meet the HIPAA > > guidelines, a > > covered entity only had to be able to accept a standard > > transaction, but not > > necessarily process with all the data elements that come > > in. Also, my > > understanding was that from a payer's perspective, HIPAA > > does not mandate > > that payers completely change their core business processes > > in order to > > process a standard transaction. Am I off-base? > > > > For example, if a payer only processes claims that come in > > at the line-level > > and it receives claims at the claim-level, is the payer > > still obligated to > > pay the claim-level claims, or can it just accept the > > claim-level claim > > (meeting HIPAA requirements) but not pay? > > > > Another example would be when anesthesia charges are billed > > on a claim, > > certain health plans currently require the surgical CPT code > > rather than the > > anesthesia CPT code. If a provider, post October 16, 2003, > > sends an > > anesthesia CPT code, payers have to accept the claim with > > the anesthesia > > codes (understood), but do they have to pay? Can they say > > that their > > systems only process using surgical CPT codes, so in order > > to get paid, > > providers must send anesthesia charges using surgical CPT > > codes? > > > > Wouldn't these two examples be instances where "companion > > guides" might be > > used? > > > > Any insight is appreciated. > > > > Thanks, > > Paul > > > > > > > > --- > > The WEDI SNIP listserv to which you are subscribed is not > > moderated. The 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/. These listservs should > > not be used for commercial marketing purposes or discussion > > of specific vendor products and services. They also are not > > intended to be used as a forum for personal disagreements or > > unprofessional communication at any time. > > > > You are currently subscribed to wedi-transactions as: > > [EMAIL PROTECTED] > > To unsubscribe from this list, go to the > > Subscribe/Unsubscribe form at http://subscribe.wedi.org or > > send a blank email to > > [EMAIL PROTECTED] > > If you need to unsubscribe but your current email address is > > not the same as the address subscribed to the list, please > > use the Subscribe/Unsubscribe form at > > http://subscribe.wedi.org > > > > --- > > The WEDI SNIP listserv to which you are subscribed is not moderated. > > The 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/. These listservs > should not be used > > for commercial marketing purposes or discussion of specific vendor > > products and services. They also are not intended to be used as a > > forum for personal disagreements or unprofessional communication at > > any time. > > > > You are currently subscribed to wedi-transactions as: > [EMAIL PROTECTED]> > > To unsubscribe from this list, go to the Subscribe/Unsubscribe > form at > > http://subscribe.wedi.org or send a blank email to > > [EMAIL PROTECTED] > > If you need to unsubscribe but your current email address is not the > > same as the address subscribed to the list, please use the > > Subscribe/Unsubscribe form at http://subscribe.wedi.org > > > --- > The WEDI SNIP listserv to which you are subscribed is not > moderated. The 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/. > These listservs should not be used for commercial marketing > purposes or discussion of specific vendor products and services. > They also are not intended to be used as a forum for personal > disagreements or unprofessional communication at any time. > > You are currently subscribed to wedi-transactions as: > [EMAIL PROTECTED] unsubscribe from this list, go to the > Subscribe/Unsubscribe form at http://subscribe.wedi.org or send a > blank email to [EMAIL PROTECTED] > If you need to unsubscribe but your current email address is not > the same as the address subscribed to the list, please use the > Subscribe/Unsubscribe form at http://subscribe.wedi.org > --- The WEDI SNIP listserv to which you are subscribed is not moderated. The 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/. These listservs should not be used for commercial marketing purposes or discussion of specific vendor products and services. They also are not intended to be used as a forum for personal disagreements or unprofessional communication at any time. You are currently subscribed to wedi-transactions as: [EMAIL PROTECTED] To unsubscribe from this list, go to the Subscribe/Unsubscribe form at http://subscribe.wedi.org or send a blank email to [EMAIL PROTECTED] If you need to unsubscribe but your current email address is not the same as the address subscribed to the list, please use the Subscribe/Unsubscribe form at http://subscribe.wedi.org
