Chris:

I wasn't aware that there was an impasse or bottleneck preventing anyone
from writing their working papers:  I thought the reason we haven't seen
anything yet is simply writer's "block."  If you're referring to the
"problem" of end-points being only payers or providers (or TPAs), I've
already given out my opinion that I don't think that is much of a
problem.  Addressing Clearinghouses can easily be accommodated in our
recommendations.

I'd go a step further, and say that supporting aggregation can be made a
first-class feature of our CPP EDI Address function.  Take an example: a
sophisticated provider, like Dave Minch, wants to send standard claim
transactions to 20 payers.  He looks these payers up in the Healthcare
CPP Registry, and finds that 10 of the payers are supported by the same
clearinghouse, and that claims for any of the 10 are to be directed to
the same "portal" resident at the clearinghouse.

Normally, Dave could choose to build 10 interchanges, one for each of
the payers, shunting them off to the designated CH portal seriatim. The
CPP for an individual payer might even specify an alternate EDI ID to be
used in the ISA receiver field - i.e., the proprietary CH-assigned payer
ID.

Now imagine this:  the CPP for the Clearinghouse (which has been
referred to by the payers' CPPs) says somehow in the Delivery Channel
for claims that claims can be "aggregated," with a special Receiver ID
to be used.  This could be of benefit to both Dave and the
Clearinghouse:  Dave now can "aggregate," or combine, the claims for all
10 payers (as described previously by Bob Poiesz) into one standard 837.
Maybe there's some obscure advantage to Dave in doing this - as if he'd
run out of incremented transaction set control numbers otherwise;  I
don't know - but it's Dave's option to do this as no one is forcing the
provider to perform aggregation.

The CH receives Dave's aggregated 837, and assuming it's
HIPAA-compliant, can then proceed to split and merge, combining other
providers' claims (for the same payer) into consolidated 837s for each
of the payers.  Apparently, some payers find this to be a big advantage
in having multiple providers' claims all munged together in the same
837.  In any event, there's nothing that keeps our recommendations from
elegantly supporting such "requirements."

I'm very "patient" with your "rambling" and "protracted" discussions, as
I hope others are: sometimes after reading a ramble, ideas - sometimes
unrelated to the original rant - start to jell, leading to
breakthroughs.

William J. Kammerer
Novannet, LLC.
+1 (614) 487-0320

----- Original Message -----
From: "Christopher J. Feahr, OD" <[EMAIL PROTECTED]>
To: "William J. Kammerer" <[EMAIL PROTECTED]>; "WEDi/SNIP ID &
Routing" <[EMAIL PROTECTED]>
Sent: Monday, 15 April, 2002 12:37 PM
Subject: Re: A proposed work plan for this group


William (and group)

I certainly do not want our group to "exclude" anyone's business needs.
I agree with other commentors that CHs and VANS will not only be major
players for the foreseeable future, but given the nearly non-existent
EDI capability of small providers, our CHs and VANs would seem to
represent the only way we will even get HIPAA airborne.

NEVERTHELESS... HIPAA is a regulation primarily about providers
exchanging information with payors. HIPAA addresses the middleman
facilitators because they are THERE. Few doctors and insurance
companies, however, really want to be in the "EDI business"... most
payors and providers appear to want to offload this headache to an AGENT
and/or Special Software. Until CPA negotiation and EDI become
trivial/transparent, we are going to need a robust layer of "EDI
facilitator" businesses to make it all work.

Twenty years from now, we will still see massive doctor disinterest in
how this "EDI crap" works! Once solid standards are implemented, it's
reasonable to expect the big, sophisticated communicators (payors...
with actual IT departments) to begin managing their own EDI. Doctors,
however, will (we hope) still be primarily interested in medicine... and
will always need massive support for B-B communication. The way I see
it... far from being on the verge of extinction, the "middleman"
industry is likely to swell up over the next decade and SWALLOW up the
IT needs of every little player in health care... even providers'
"internal" IT needs.

This discussion has shown that many communication and addressing models
are in actual use today and some of them seem to conflict with "common
sense" when applied to a theoretical "point to point"
direct-communication model... something that needs to be defined, but is
generally individual providers conversing with individual health plans.
I think we all can agree that the "CH" or "VAN" industry will be
seriously MUTATED over the next 2 or 3 years, and that dozens of
variants of the "middleman" business model are likely to emerge in
healthcare... mainly around newly-acknowledged PROVIDER needs. So my
suggestion to focus our committee's recommendations and proposals on the
"point to point" model was intended to give us a clear, common target to
fire our recommendations at. I agree that these recommendations should
and likely will be useful to CHs and VANs in the near term... ditto for
anything resembling a central player-ID and address registry.

Once we have agreed on the definition of the COMMUNICATION MODEL that we
want our recommendations to support, I believe we will get past this
bottleneck and be able to get to work on the papers. Please be patient
with this "rambling" discussion. We seem to be close to consensus, but
you cannot make something this big "simple"... no matter how much we all
wish that it were. I'm actually impressed with this group's patience and
willingness to tolerate this useful [if protracted] dialog.

Thanks,
-Chris

Christopher J. Feahr, OD
http://visiondatastandard.org
[EMAIL PROTECTED]
Cell/Pager: 707-529-2268


Reply via email to