Re: Accept v. Process Standard Transactions

[Jan Root]

Doug, I think I must respectfully disagree with your statement that 'accepting the 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 have the 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 process with 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 receives no 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] 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