Doug,
Yes, your logic is good with your expanded definition. Here in
Utah we have to distinquish between the 'front-end' portion of a system
and the adjudication portion for legal reasons so they end up being discussed
as different systems. It's also been an important point of distinction
at X12 in discussing how claims and other transactions are handled.
However, from a business perspective, you are correct.
Jan
Doug Webb wrote:
Jan,I agree
with your logic. We differ in how an "adjutication system" is defined. To
my mind, an "adjudication system" is what applies business logic to a transaction
(i.e, the whole back end -- everything past the syntax checkers).
The result of that logic will be a business response of some nature.
This could be a chain of filters, rejecting those that don't pass muster,
and passing on the survivers to the next level of detail. This
is a good justification for keeping the syntax and IG compliance checkers
separate from the business logic -- to keep a "non-complient" rejection
totally separate from a "bunk" rejection. For that reason, I would
tend to want to keep the "we don't do ..." responses on the business side
rather than the syntax side. 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 -----
Sent: Monday, March 10, 2003 01:24
PM
Subject: Re: Accept v. Process Standard
Transactions
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 -----
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
---
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
|
