I am working with a BCBS plan and Medicare Contractor that uses different
Reciever IDs in the ISA and GS to distingush states and receiver
applications. They are not the same at both levels so I agree with Bob
Gale
----- Original Message -----
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, May 29, 2002 1:34 PM
Subject: RE: Trading Partner ID
Rachel,
I think that what has happened is that many people have not needed to use
the GS for the original purpose. As a result, they have defaulted its
function to being a restatement of the ISA values. That is different than
morphing. Its fine to retain that default content when no other need
exists. But it would be detrimental to assume that you could eliminate the
other (original and primary) use and only leave the default. The fact is
that these are not the sender and receiver ID. They are something
different. I assume that by your "...but..." you are not in favor of
retaining that original functionality (I apologize if I have misread that
point). I believe that eliminating the "Application" capability from the GS
would be a mistake.
Bob
"Rachel
Foerster" To: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED] cc:
tcom.com> Subject: RE: Trading Partner ID
05/29/2002
02:09 PM
Please respond
to rachelf
Bob,
You are correct in your description and conclusion about the GS
sender/receiver codes. In their first incarnation in the first X12
standard,
they were envisioned to be identifiers for the two party's application
systems....but their use has morphed, as one would expect over time.
Rachel
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, May 29, 2002 12:53 PM
To: [EMAIL PROTECTED]
Cc: WEDi/SNIP ID & Routing
Subject: Re: Trading Partner ID
Ok - pet peeve time.
The GS segment does not have either a Sender ID or a Receiver ID. What it
has is an Application Sender's Code and an Application Receiver's Code.
These are very different. They are intended to be used for routing and
translation map identification. We are using these elements to determine
both routing and mapping. In some cases, we need this information to
determine which application gets the data.
In fact, I would say that the GS elements can not be standardized.
Bob
Martin Scholl
<mscholl@martins To: WEDi/SNIP ID & Routing
<[EMAIL PROTECTED]>
choll.com> cc:
Subject: Trading Partner ID
05/29/2002 01:11
PM
I have a conceptual problem with the different Sender and Receiver IDs.
If I receive a transaction, I key the trading partner to the ISA_06
element. Under this number I record the transmission mode, like ftp or
email or dial-up, passwords etc.
Then I have another Sender ID in the GS_02. Should this be the same as
ISA_06? The IG recommends to define this in the trading partner agreement.
My feeling would be to make these numbers identical or could they identify
different departments within the trading partner's organization? are they
subordinate to ISA_06?
Then in the 837 I also have this pesky 1000A loop with another set of
Sender IDs. Again, I would intuitively think that this could be the same
as ISA_06 and GS_02.
For me the issue is: What do I use as a unique key to store trading partner
rules and information under?
What do others in the field do?
Martin Scholl
Scholl Consulting Group, Inc.
301-924-5537 Tel
301-570-0139 Fax
[EMAIL PROTECTED]
www.SchollConsulting.com
