|
Jonothan, Walt
That's one reason I like the wording they used in the Addenda
-- Required if the payor needs it, but saying nothing about being Not Used if
the payor doesn't need it.
I also quite agree that if any payor listed in the claim needs
it, then it is needed in the original claim, and must ba passed on by the payor
who does payor-to-payor COB. I like your extension to any payor you know
about, to minimize specialized logic.
The one time that a Situational element should become Not Used
if the situation doesn't apply is if the presence of the element implies an
untruth, i.e., a transaction should be both Complient and True.
I do not believe that a Complience checker should use any
information from outside the claim, the IG, and the designated codesets to
determine if a transaction is Complient. If the checker cannot tell if the
Situation applies or not from the content, it should assume that the sender or
receiver (or both) does know, and should not make decisions based on information
it does not have.
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, April 04, 2003 07:39
AM
Subject: RE: Situational
segments/elements and payer-specific edits
Jonathan,
We probably did talk past each other, and
probably because there are two
types of situational data elements - data
elements that are required when an
another data element indicates that the
value will be there, and data
elements that are required based on
conditions outside of the claim. In the
first case, compliance checks
can (and most do) enforce the existence or
non-existence of the data, but
in the second, compliance checks can not
determine whether the data should
be there. My discussions focused on the
second condition.
NDCs, taxonomy and other data elements were originally required, but
because
of the change control process, they were made situational.
These changes
allow the purists to say that if the situation doesn't apply,
then the
transaction should be rejected due to non-compliance. My
concern is that it
will be too difficult for payers to determine whether
these situations apply
(to do so would require payers to understand other
payers needs), so my
expectation is that they can only ignore anything they
do not need. They
will, however need to be able to pass that
information on to the next payer
(both are required by the rule.)
Because of this, providers should be able
to determine what situational
data elements are required by any of their
payers, and send those elements
on every transaction they produce. Then,
the providers would only
have to change the way they bill when two payers
have different billing
requirements for the same service.
Walt
-----Original
Message-----
From: Jonathan Allen
[mailto:[EMAIL PROTECTED]
Sent: Friday, March 28, 2003 10:51
AM
To: WEDI SNIP Transactions Workgroup List
Cc: [EMAIL PROTECTED]
Subject:
Re: Situational segments/elements and payer-specific
edits
Walt,
I think we just talked past each other. If
you had commented in-line,
then my text would have appeared next to yours
and we would have seen
that we are saying the same thing.
> You
conveniently dropped my comments on Uniform Billing in order to
make
my
> comments support your arguments.
I didn't intend to
create that effect. I agree that Uniform Billing is not
a financially
viable option at this stage.
JA> As you describe it, any receiving
payer has to accept a variety of data
JA> that they do not want in order
to pass it on down the chain. But their
JA> input database or file
layout must have space allocated for that data so
JA> that it can be
replayed later - so it cannot get silently dropped on the
JA> floor. In
other words, the payer has taken a conscious business decision
JA> to
examine, store and ignore-for-themselves the data that they
don't
need
JA> so that they can regurgitate it for a
secondary/tertiary payer. Any
data
JA> that shouldn't be in the
input stream (at all) will cause rejection. So
JA> no-one should
get sued for not seeing/processing any data.
WT> Since payers can
not reject transactions because of the existence of
data
WT> they do
not need to adjudicate the claim, and since payers are
required
to
WT> pass the claim on to other payers without changing
anything on the claim
WT> other than the elements they are supposed to
change, is there any reason
why
WT> providers can not include
situational data elements regardless of the
need
WT> of the payers in
the chain of a single claim? If we accept this
premise,
WT>
then providers aught to be able to minimize changes to elements sent
for
WT> individual service codes by starting with a set of elements that
are
WT> required by any of their payers and bill those elements all the
time.
Those two paragraphs seem to match content fairly well to me
although
written
from different points of persepctive. Providers
send data that each
individual payer may not need so that it can be passed
on to others; payers
have agreed to store and hold data that they don't
need to pass it on to
others thus keeping the system going.
The only
area of concern is that payers have to take a conscious decision
to support
the through-passage of data that they themselves don't actually
require in
their own business model. If they are not aware that this
decision
needs to considered and taken, then data can get lost/dropped and
providers
may have to bill separately.
I had taken Dave's original question to be
talking about the transmission
of situational data for which the situation
didn't apply.
Are we together now
?
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
|
