Martin Scholl's impression that the HIPAA IGs allow you to choose the
ISA qualifier "ZZ" so you can put "anything in there" is correct.  As
far as I know, the guides have not changed since I last saw them.

And we can accommodate the ZZ qualifier in our CPP Electronic Partner
Profile: the receiver can specify in his DeliveryChannel ("EDI
Address") that the ISA Receiver Interchange ID Qualifier and ID are to
be whatever he deems fit.  Perhaps his DeliveryChannel is assigned to
his clearinghouse, and the clearinghouse only knows him by some
*contrived* (CH-assigned) receiver ID using the ZZ "mutually-defined"
qualifier.   Since the receiver is a customer of the clearinghouse, he
knows ahead of time what his proprietary CH-assigned receiver ID is, and
can place it in the CPP so senders know what to use in the ISA receiver
field.

Just make sure you understand that the sender would have no way, a
priori, of knowing what proprietary ID to use in the ISA receiver field
until he accessed the receiver's CPP.   Remember that no proprietary IDs
could be used to *search* the Healthcare CPP Registry since there would
be no way to ensure their uniqueness across all CPPs for all entities -
i.e., your notion of ZZ-BILLYJOE might be different from another's
notion of the same pair.  That same ambiguity doesn't exist for RA
centrally managed identifier domains, e.g., HIBCC HIN, NAIC Company
Code, Dun & Bradstreet D-U-N-S, IRS Tax ID (FEIN), etc.  NAIC Company
Code 54771 is Highmark, regardless who's doing the talking.

Keep in mind that there's no way to compel a sender to identify herself
with a proprietary ID.  Given the Open-EDI aspect of HIPAA, a payer may
not even know ahead of time that he's about to receive a transaction
from some provider:  how would he ever manage to assign a proprietary
payer-assigned ID to her?  On the other hand, if she chooses, a sender
may identify herself with a ZZ qualified sender ID (in actuality, she
may have been forced to by her one and only VAN or clearinghouse).

It doesn't matter that the sender ID is mutually defined:  the receiver
never uses the pair except when turning around the TA1 or 997.  This
forces me to backtrack a little on what I told Todd Velnosky this
morning:  if an interchange using a ZZ-qualified sender field were being
acknowledged, then the TA1 and 997 would have to be returned to the same
clearinghouse the original interchange arrived from, simply because only
that clearinghouse is guaranteed to know how to interpret the ZZ-pair.

To determine the receiver ID of application responses, the sender would
use one of the NM1 "application" identifiers (say, the Tax ID) to locate
his partner's CPP, which in turn (using the DeliveryChannel) says how to
get the response where it's going and what to stuff in the ISA receiver
field.

William J. Kammerer
Novannet, LLC.
Columbus, US-OH 43221-3859
+1 (614) 487-0320

----- Original Message -----
From: "Bill Chessman" <[EMAIL PROTECTED]>
To: "'WEDI Routing & ID List'" <[EMAIL PROTECTED]>
Sent: Friday, 31 May, 2002 12:38 PM
Subject: RE: Trading Partner ID

There is at least one network that uses ZZ in ISA qualifiers (mind you,
this does not represent advocacy or condoning on my part--it's just an
observation): When sending X12 interchanges via Advantis (IBM, right?),
when you specify ZZ as the qualifier, the receiver identifier, specially
formatted, contains an Advantis-specific account value that tells the
network exactly which mailbox to deliver to.

The idea in this particular case is that there's no extra protocol
stuff. Dump the file onto Advantis (no control statements, just the raw
interchange) and the network will do two things: 1) recognize and
classify the data as X12-style EDI and 2) deliver it to the recipient
based on the value in the ISA receiver ID. Of course, this service is
only available when sender and receiver are both Advantis users...

For what it's worth...

Best regards,
Bill Chessman
Peregrine Systems, Inc. (though the opinions expressed, if any, are my
own)

-----Original Message-----
From: Martin Scholl [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 31, 2002 8:45 AM
To: William J. Kammerer; WEDi/SNIP ID & Routing
Subject: Re: Trading Partner ID

William, you wrote:

The ISA sender and receiver IDs must be valid identifiers from a limited
set of domains, e.g., HIBCC HIN, NAIC Company Code, Dun & Bradstreet
D-U-N-S, IRS Tax ID (FEIN), etc. It is my impression that when you
choose the qulifier "ZZ" you can put anything in there. Whatever you and
your trading partner deem to be fit.

Martin

----- Original Message -----
From: "William J. Kammerer" <[EMAIL PROTECTED]>
To: "WEDi/SNIP ID & Routing" <[EMAIL PROTECTED]>
Sent: Friday, 31 May, 2002 09:43 AM
Subject: Re: Trading Partner ID


I don't think the 1000A (Submitter Name) and 1000B (Receiver Name)
"audit trail" in the 837 are all that important.  Besides, the other
transactions (like the 270/271, 276/277 and 835) don't have an analog of
this "audit trail."   Based on previous observations, though, it's
probably the usual case that the 1000A and 1000B Electronic Transmitter
Identification Numbers exactly reflect the sender and receiver IDs on
the enclosing  interchange envelope.

The ISA is incapable of carrying application data - unless you can
manage to squeeze it into a ZZ-qualified sender or receiver ID!  The ISA
sender and receiver IDs must be valid identifiers from a limited set of
domains, e.g., HIBCC HIN, NAIC Company Code, Dun & Bradstreet D-U-N-S,
IRS Tax ID (FEIN), etc.  IDs of this sort can serve as both routing
identifiers *and* application identifiers.  Therefore, it's entirely
possible that any of these also appear in the "application" NM1s (e.g.,
the 837's 2000A loop to identify the billing provider).

Generally, you would use one of the NM1 "application" identifiers (say,
the Tax ID) for a provider to locate his CPP (Electronic Partner
Profile).  The CPP would then tell you what identifier to use in the ISA
for the receiver.   It would be mere serendipity if it turned out to be
the same (the Tax ID in this case) - it could just as well be the
D-U-N-S or HIN of the provider.

William J. Kammerer
Novannet, LLC.
Columbus, US-OH 43221-3859
+1 (614) 487-0320




Reply via email to