Chris,

This issue of defining who the "real" sender and receiver are was brought up
early in this list's history. At that time I strongly recommended that a
project glossary be developed so that, at least for discussion purposes
here, we would have clear definitions of terms. Alas....

On the other hand, at that time I also did a rather thorough search of all
of the HIPAA IGs and throughout all of them there is the consistent intent
and use of the sender being either the provider or payer and the receiver
being either the payer or provider. Nowhere in any of the HIPAA guides is
there a explicit or implicit statement that the sender is just the next hop
for the interchange. In other words, the provider and payer are the real
trading partners for purposes of the HIPAA transactions, and intermediaries,
whether clearinghouses or something else, are just that - an intermediary
between the true end-point business partners.

Perhaps it's useful to think about the U.S. Postal Service as a metaphor.
The address on the envelope is always the end-point receiver, and not the
next Post Office facility that the envelope may pass through. This is the
model that the X12 interchange envelopes follow as well.

Rachel
Rachel Foerster
Principal
Rachel Foerster & Associates, Ltd.
Professionals in EDI & Electronic Commerce
39432 North Avenue
Beach Park, IL 60099
Phone: 847-872-8070
Fax: 847-872-6860
http:/www.rfa-edi.com


-----Original Message-----
From: Christopher J. Feahr, OD [mailto:[EMAIL PROTECTED]]
Sent: Thursday, April 04, 2002 8:48 PM
To: Dave Minch; '[EMAIL PROTECTED]'
Subject: RE: Are only 15 characters in the ISA receiver ID enough?


Dave,
Thanks for your detailed summary posts... very helpful!  But I was under
the impression that the ISA08 is always intended to be the ID of the "next
destination" for the interchange, rather than the ID of the payor or "plan"
(in the case of a claim), as you seem to be suggesting here.  Am I
misunderstanding you?

Regards,
Chris


At 06:36 PM 4/2/02 -0800, Dave Minch wrote:
>5) Generate the transaction.  The ISA08 would contain the ultimate
>interchange receiver's EDI identifier (if I'm the provider and the
>transaction is a claim, then the address is the payer's), and the other EDI
>Address information from the CPP would tell me where to route the
>transaction (payer itself, a third party administrator, CH, etc.) along
with
>the communication details of the actual receiver.  It is then up to my
>transaction generator software to be smart enough to group transactions
>together into 1 envelop (ISA) when there are multiple claims for the same
>payer. Following this logic, I would therefor be required to send multiple
>transactions (multiple ISA/IEAs) for different payers using the same third
>party admin or CH since ISA08 is the payer's, not that of the initial
>transaction destination.
>
>I must admit that this is a new way of looking at the X12-837 message for
me
>- I was assuming that 1 ISA/IEA going to 1 place (like a CH) would contain
>all claims going to that location, irrespective of the ultimate
destination.
>I like it - it gives me the added advantage of getting 997 acknowledgements
>back by payer since they are in separate envelopes, but it requires that I
>deliver many envelops to the same destination (I don't think this is any
>great amount of added effort, is it??)...
>
>As a transaction receiver, it would be 1 step simpler in that the
identifier
>provided to me in ISA06 would be a unique ID, under which the sender would
>have listed their CPP.  So the steps would be exactly the same for the
>receiver to respond to a sender, but the "identifier" used in step 2 would
>be that found in ISA06. This tells me that there needs to be at least 2,
and
>possibly more identifiers that can be listed in a DNS that all point to the
>same CPP.  If that is the case, then the question of DUNS vs TIN vs NAIC vs
>the National Provider ID can be addressed later, because in fact, if a
>trading partner wants to be found, they'll list themselves under all that
>apply.

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

Reply via email to