My opinion is that the recent discussion on this thread points out that the
scope of this SNIP effort must be managed to address a reasonable
objective. My view of the group's original direction was to address the ID
codes used for the entities that can be considered submitters and
receivers. As the recent notes have indicated, there are many scenarios
that exist, and many of the current edi players have their own needs and
policies that will not change overnight. Therefore, I suggest that the
co-leaders of this group attempt to define the scope of the discussion, and
attempt to focus discussion in that direction. Other important topics can
be identified for future efforts, but it seems to me that the immediate
need is to address a common ID coding scheme. Without that, we are all
left to our own devices. For example, to satisfy our needs as a payer, we
will be requiring that submitters identify themselves with a edi source
number that we assign internally, and that they identify the receiver and
destination payer with a NAIC based number, with some modification per our
definition. I agree that it would be nice for submitters if there were
national numbers that a submitter could use, but there are not. Maybe the
best that can come out of this effort is to identify the current state of
affairs (i.e. what the HIPAA IG's leave to be specified in TPA's) and to
make recommendations for the coming national provider and health plan
identifiers that will improve the situation.
Doug Renshaw
Highmark
----- Forwarded by Doug Renshaw/OPERATIONS/CORP/Highmark on 01/25/02 08:41
AM -----
robert.poiesz@hi
ghmark.com To: [EMAIL PROTECTED]
cc: Joe Fuchs <[EMAIL PROTECTED]>,
Michael Smith
01/25/02 08:14 <[EMAIL PROTECTED]>, Ross Hallberg
<[EMAIL PROTECTED]>,
AM [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: RE: Time-out for terminology
question(s)
Dave,
The section about loop 1000 in the 837 states that it is difficult to
define and describe. From my perspective, loop 1000B is effectively
useless.
If you are using a VAN, then the 1000B contains the receiver of the
interchange as defined in figure 5 of the 837P guide. If not, then the
submitter does not know who the receiver really is. Figure 5 shows the
receiver sending the claims to multiple payers. That is correct in theory.
What is missing is that some of those claims could continue on to other
clearinghouses, payers not supported directly by this receiver. So, this
receiver concept in the 837 is not viable in reality. It assumes a VAN type
of situation, and not a clearinghouse process, with the possibility of
multiple clearinghouses in the path to the payer.
The operative concept in the 837 is the reality of loop 2000B. You do not
determine the receiver of the unit of work - the claim - in loop 1000. It
is defined within the Subscriber Hierarchical level (2000B). Specifically,
each claim individually identifies the payer in loop 2010BB. One 837 can
have a different payer on EACH claim within the 837. Who is the 837
receiver in that case???? The interchange does not have integrity from
provider to payer. Submitter and receiver can only be identified in terms
of the point to point leg of the communications process where the
interchange and transaction exist as a coherent entity. That is not the
case from provider to payer, most of the time.
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.
And, the 837 is not alone. The 270/271 and the 276/277 allow for multiple
Information Sources and Information Receivers. There is no concept here of
routing an ISA from Provider (or direct agent) to Payer (or direct agent).
One interchange (or transaction) can be for multiple final receivers and
from multiple original submitters. There is NOT a guaranteed one to one
relationship beyond the point to point of any specific leg of the ulimate
path. And, loop 1000 and the ISA can only reflect the realities of that
point to point communication as well.
These are facts that we can not (MUST NOT) ignore. They dictate the
realities of the business and routing. While future HIPAA versions may
change the implementation of these transactions to allow (or force) for a
different business scenario, today we are stuck with a system that can not
be looked at except in terms of the more demanding point to point scenario,
where routing is inherently an internal issue for the receiver of the
interchange. Each interchange must be opened, each transaction opened, and
the individual business units of work routed based upon the business
information, not the ISA or loop 1000. A global routing philosophy may
help a few that happen to fall into a VAN type of scenario, but it can not
come close to being the rule.
So, your assumption that you must get the transaction to the first hop is
correct. How the data moves from there is totally beyond your control and
knowledge. Individual transactions may very well cease to exist at that
first stop, and be integrated with other business units from other
providers as they move down the path to the final destination - the payer.
Bob
(Sorry to be so long winded, As Doug Renshaw would say, I tend to get
passionate about this.)
Dave Minch
<dave.minch@jm To:
"'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
mdhs.com> cc: [EMAIL PROTECTED], Joe
Fuchs <[EMAIL PROTECTED]>, Michael Smith
<[EMAIL PROTECTED]>, Ross
Hallberg <[EMAIL PROTECTED]>
01/24/2002 Subject: RE: Time-out for
terminology question(s)
06:21 PM
Bob,
If I can generalize what you are saying, the ISA is truly the envelop to be
delivered, with the name of the interchange addressee on the front (which
certainly fits with the Transmission Control Schematic shown in figure A1
in
appendix A of the 837 IG -- actually, I think its in all IGs in appendix
A).
As to the routing address & method, I need to have that information stored
in my internal trading partner table (e.g. that is what determines that
for:
>addressee A I push the batch to location X on server Y through transport
Z;
>addressee B I push to location Q through VAN C;
>addressee C I post the batch to my DMZ server H directory J so the
addressee can pick it up, and so on.
What I put into loop 1000A is my provider information (lets me identify
which of our 15 providers the CLM is from). What I put into loop 1000B is
the endpoint destination (the IG calls it the "Receiver" -- and there are a
couple of diagrams & some pretty good text on pages 41-42 of the 837p IG
which illustrate some different scenarios).
What I'm then assuming is that for routing purposes, I've done my job if I
can get the payload to the first hop in the chain, and then its the
responsibility of the entity at that first hop to repackage the transaction
(or set of transactions) with a new ISA/IEA envelop to pass on to the next
hop. That entity must then have all of the destination hop, routing,
method, security, etc. information in its internal trading partner table to
properly relate the "receiver" in 1000B to the next hop in the chain. This
continues until the receiver identified in 1000B eventually receives the
payload. The key point that I believe someone made earlier is that one only
needs to know how to relate the NM1 (08-09) to what that trading partner
has
told you to do if you want to send them something - they are the ones who
tell you what the first hop is.
It would be helpful to me to know what CHs actually keep in their existing
trading partner tables since they seem to be pretty competent at doing this
routing today.
Last question: is NM108 the same set of values that are shown for ISA07?
Dave Minch
T&CS Project Manager
John Muir / Mt. Diablo Health System
Walnut Creek, CA
(925) 941-2240
