|
Walt,
Well Said.
I would think that the only reason to reject a transaction for
presence of a Situational field would be if:
1) The Situation does not apply, and
2) The population of the field implies the Situation does
apply, and
3) This can be detected by the content of the
transaction..
Likewise, rejection of a transaction for the absence of a
Situational field would be if
1) The Situation does apply, and
2) This can be detected from the content of the
transaction.
If the rejection condition can't be detected by the content of
the transaction, the rejection would have to be by the adjudication system,
which has access to information outside the individual claim.
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: Thursday, March 27, 2003 08:54
AM
Subject: RE: Situational
segments/elements and payer-specific edits
Jonathan,
I respectfully disagree. The principal
reason for the HIPAA rule is to make
claims transactions more
consistent. Providers have to bill payers based on
the payer's
payment policies (keeping within the HIPAA guidelines), and
these policies
differ. If we require providers to bill each payer
differently when
the service code and other basics are the same but the
situational elements
needed differ between payers, then we have fully
defeated the reason for
HIPAA.
The argument against your approach is further supported when
considering the
need to bill multiple payers for a claim (Coordination of
Benefits or COB).
In these cases, your approach would require the use of
the COB option that
requires the provider to bill each payer individually,
and the option where
payers pass claims on to the next payer could not be
accomplished.
It makes sense to me that providers should develop their
claims submission
systems to support all payer needs and that payers accept
claims regardless
of what data is in elements that they do not need.
Kepa, in an earlier
message, cited a segment from the IGs that providres
should send the data if
the situation applies. This can be
interpreted multiple ways, but if the
situation applies to one payer in the
chain, then I feel it applies to the
claim.
Extending this argument,
rather than requiring providers to determine which
payers are in the chain,
wouldn't it be more practical for payers to ignore
any data that they do
not need so that providers can bill individual
services codes in a way that
all payers who pay for that service code will
accept? Don't confuse
this with Uniform Billing where payers would agree to
accept claims for
services using the same service code and form (transaction
type), because
HIPAA does not yet dictate policy and the payer community is
too involved
in meeting HIPAA compliancy to be able to consider
this.
Walt
-----Original Message-----
From: Jonathan Allen
[mailto:[EMAIL PROTECTED]
Sent: Thursday, March 27, 2003 4:19
AM
To: WEDI SNIP Transactions Workgroup List
Cc: [EMAIL PROTECTED]
Subject:
Re: Situational segments/elements and payer-specific edits
Dave
Sell asked:
> I'd like to know if any receivers will reject claims
that have unneeded
> Situational segments or elements.
They
certainly should. Two principle reasons:
a. the old
chestnut of HIPAA compliance - sending unneeded
situational
data would make a transaction
non-compliant and both the sender and
receiver in
breach of the rules (and so liable for fines if caught)
b.
contractual and liability - if a receiver is not expecting
certain
data items, then they won't have mapped it
to anywhere in their
in-bound database or file
format, which means that the data will
effectively
get dropped. Their application is therefore
unaware
that the unneeded data was sent and may
accept, process, adjudicate
a claim on the basis
of only the data it receives. Subsequently,
the claimant contests the adjudication on the basis of the
unneeded
but silently dropped (thus looking like
accepted) data which they
thought out to have been
taken into
consideration
Jonathan
----------------------------------------------------------------------------
--
Jonathan
Allen
| [EMAIL PROTECTED]
| Voice:
01404-823670
Barum Computer Consultants
|
|
Fax:
01404-823671
----------------------------------------------------------------------------
--
---
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
Please
Note
The information in this E-mail message may contain legally privileged
and
confidential information intended only for the use of the
individual(s)
named above. If you, the reader of this message, are
not the intended
recipient, you are hereby notified that you should not
further disseminate,
distribute, or forward this E-mail message. If
you have received this
E-mail in error, please notify the sender
immediately and delete the
original.
---
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
|
