The ebXML Message Service Specification does have a Multi-hop concept,
where not only the sender and receiver are identified in the message
header, but each of the intermediaries through which the message
traverses.

Unfortunately, we can't (always or ever) assume that we're going to have
ebXML Messaging Services available - it will probably be only one of the
many packaging techniques described in our recommendations.  The lowest
common denominator for specifying a receiver will be the X12 ISA
Interchange Header - and all of our recommendations will have to assume
this minimum capability.  This means that when handed an interchange and
told to send it on its way, all you (say,  a clearinghouse, or VAN or
EDIINT software) can assume is what's available in the interchange
itself (usually the ISA, but maybe the GS) *and* whatever information is
available in our electronic Trading Partner Agreement (like Peter's EDI
addresses).

So, if some description of multi-hop routing is believed to be needed,
it's going to have to be external to the ISA. There are no changes we
can make to the ISA - it's impractical that any requests (other than
qualifier code changes) could move through the glacially slow X12
process in time for it to be useful to us.

We're probably safest in assuming we (WEDi/SNIP ID & Routing) are not
going to be developing any recommendations requiring X12 DM requests nor
other than the most minimal changes to the HIPAA implementation guides.

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

----- Original Message -----
From: "Christopher J. Feahr, OD" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Friday, 01 March, 2002 04:51 PM
Subject: Re: Submitter/receiver


Ron,
This does sound useful, but I don't think there is anything like a 1000
loop in all transactions that might benefit from such a strategy.  Your
suggestion, however, does make me think that we should have a "smarter"
ISA segment... one that could hold the "next stop" and the "final"
destination (?).
-Chris


Reply via email to