|
Martin,
The providers wouldn't necessarily need to know the arcane
requirements of all payors, just the ones they deal with on a regular basis
(that brings the 5000 or so payors down to a few hunderd).
Since the providers like being paid, they will keep on doing
what they're doing -- making exceptions for the oddballs. The trick is how
to pressure them to get off the oddball list. We
have observed that the only pressure that works on payors in general is pressure
from the ones who pay them -- the Subscribers. Until either official
pressure from CMS or $$ pressure from Subscribers is applied, nothing is likely
to happen.
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 09:34
AM
Subject: RE: Situational
segments/elements and payer-specific edits
What, no gravy for the goose?
Walt, I follow your logic
and agree with most of it, in principle, but
I think the implications of
your assertions illustrate exactly why the
coming transition needs to be
approached with a more liberal
interpretation of the standards.
On the one hand, you assert: "it will be too difficult for payers
to
determine whether these situations apply (to do so would
require
payers to understand other payers needs);" on the other, you
say,
"providers would only have to change the way they bill when two
payers
have different billing requirements."
So you're saying that
it's too much to expect 5,000 payers to know
what each of them is expecting
in the situational data elements, but
it's NOT too much to expect 500,000
providers to know that same arcane
knowledge?
And situational data
elements, though seen by some as the "terrain of
flexibility" that will get
us through the coming storm, is really just
an outlying province.
Those of us who are trying to please the 5,000
are finding that no two
agree on what "HIPAA compliant" really
means....
I applaud your
perception of the need for flexibility, but the problem
is one we all face,
not just the payer whose zeal for defining
"nonstandard" transactions
exceeds its knowledge of its
competitors'
requirements....
-----Original Message-----
From:
Troidl, Walt [mailto:[EMAIL PROTECTED]
Sent: Friday, April 04,
2003 07:39
To: WEDI SNIP Transactions Workgroup List
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
JA> data that they do not want in
order to pass it on down the chain.
JA> But their input database or
file layout must have space allocated
JA> for that data so that it can
be replayed later - so it cannot get
JA> silently dropped on the floor.
In other words, the payer has taken
a
JA> conscious business
decision to examine, store and
JA> 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.
JA> So 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
WT>
required
to
WT> pass the claim on to other payers without changing
anything on the
WT> claim other than the elements they are supposed
to change, is
there
WT> any reason
why
WT> providers can
not include situational data elements regardless of
WT>
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
WT> for individual service codes
by starting with a set of elements
that
WT> are required by any of
their payers and bill those elements all
the
WT> 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
[snip]
IMPORTANT NOTICE:
This
message is intended only for the use of the individual or entity
to which
it is addressed and may contain information that is
privileged,
confidential and exempt from disclosure under applicable
law. If you
have received this message in error, you are hereby
notified that we do not
consent to any reading, dissemination,
distribution or copying of this
message. If you have received this
communication in error, please
notify the sender immediately and
destroy the transmitted
information.
---
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
|
