Rachel,
You are preaching to the choir.
But, when the fact is that it is an uphill battle to get people to consider
implementing the 835 and actually eliminating the use of a paper remittance
advice to the provider, how can we expect to get the industry look at the
big picture? This is a step by step process, and they are baby steps at
this stage. To most people, HIPAA is an obligation to fulfill or be fined,
not an opportunity.
That has to change, and it will, but not today. We need to acknowledge
that HIPAA and true administrative simplification is a paradigm shift.
People don't give up the old easilly. My fear is that they will stop
listening if we make the job too hard to start off. Look at how long it
has taken us already - HIPAA was passed in August of 1996! People still
think that HIPAA doesn't apply to them. We still don't have everybody even
at the water, let alone starting to drink
Bob
.
"Rachel
Foerster" To: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED] cc:
tcom.com> Subject: RE: Transactions with mult.
senders and mult. receivers
01/26/2002
11:04 AM
Please respond
to rachelf
Bob,
I understand today's situation as you describe it below. On the other hand,
if the industry is to truly achieve **administrative simplification** it
must recognize that merely implementing EDI does not achieve the goal of
taking cost out of the process and that administrative simplification is
not
a byproduct of achieving HIPAA compliance.
The reality is - and other industries have learned this over the years -
that the real benefits of EDI lie not in the mere exchange of electronic
information, but in truly improving (redesigning) the underlying business
processes. Most critical to be addressed are not the interfaces where an
organzation's business process is exposed to an external business entity,
but the internal business processes that enable and support the
organization's business goals. However, this is where the real pain and
effort is rather than just slapping an integration engine (EDI translator)
in front of an application system.
Without making this hard, long and arduous effort to truly address the
inefficient and ineffective internal business processes, it's all cost and
and window dressing. EDI, whether one uses the X12 or UN/EDIFACT standards,
or the new kid on the block, XML, is just an enabler, it's not the
solution.
The willingness to change business processes is where the big win will be.
Rachel Foerster
Rachel Foerster & Associates, Ltd.
Phone: 847-872-8070
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 25, 2002 3:25 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; Joe Fuchs; Michael Smith; Ross Hallberg;
[EMAIL PROTECTED]
Subject: Re: Transactions with mult. senders and mult. receivers
Chris,
Right - I was not talking about secondary claims.
What I was saying was - if you define sender and receiver as original
sender and ultimate receiver then you loose the one to one relationship.
A clearinghouse can receive 10 837s from 10 providers. Each provider can
be sending claims to 10 different payers in their 837. When the
clearinghouse resorts and organizes the claims they produce 10 837s for
each of the 10 payers that contain claims from each of the 10 providers.
Each 837 from the CH to a payer contains claims from multiple original
senders. Each 837 from a provider contains claims for multiple ultimate
receivers.
We can't standardize an ISA identifier on an end to end basis without first
adding a restriction to the existing process that would establish a one to
one relationship that does not exist today. That is why I have tried to
focus on the point to point concept for addressing, where original sender
and ultimate receiver are not identified within the ISA at all.
Bob
"Christopher
J. Feahr, OD" To:
[EMAIL PROTECTED],
[EMAIL PROTECTED]
<chris@optiser cc: Joe Fuchs
<[EMAIL PROTECTED]>, Michael Smith
v.com> <[EMAIL PROTECTED]>, Ross
Hallberg <[EMAIL PROTECTED]>,
[EMAIL PROTECTED],
[EMAIL PROTECTED]
01/25/2002 Subject: Transactions with
mult. senders and mult. receivers
02:06 PM
Now I'm really stumped. Can someone explain the business use-case for a
single 837 transaction set needing to have multiple "senders" and/or
multiple "receivers"? I assume that Bob was not referring here to
secondary payors, but to real, honest-to-god, multiple addressees for a
single transaction set?
I understand that a single interchange envelope can have many claim
transactions in it, but I always though of that as "many 837s". And I also
understand that a single interchange can even contain a "functional group"
of many 837s, a "functional group" of 271s, etc.
But if a single provider wants to send 2 PRIMARY claims, one to payor A and
the other to payor B, why wouldn't he sent 2 separate 837 transactions
sets?
And if Doctor A has a claim for Payor X and Doctor B also has a claim for
Payor X, why wouldn't this also [always] be two separate 837 transactions?
Even if the IG allowed the combining either of the last two scenarios into
a single 837, I cannot imagine why anyone would ever want to do something
that difficult to route. Cant' we strongly advise against such a practice
even if it is permitted in the standard?
-Chris
At 08:14 AM 1/25/02 -0500, [EMAIL PROTECTED] wrote:
>Also, note that loop 2000A occurs >1 times, allowing for the
identification
>of multiple billing providers, or "submitters", in each 837.
>
>While most of X12 defined transactions as single business 'documents'
(i.e.
>one invoice in a transaction), health care in its wisdom defined a
>transaction that contained MULTIPLE business documents. That is causing us
>problems now. It adds levels of complexity that do not exist in other
parts
>of the EDI community.
Christopher J. Feahr, OD
http://visiondatastandard.org
[EMAIL PROTECTED]
Cell/Pager: 707-529-2268
