Well, let me ask the group something else.
1.) How many of you are planning to use a VAN?
2.) How many will just set up an ftp server on your network and let trading
partners drop off their files and pick up their files from a trading partner
specific outbox?
For the latter, you can put into the identifiers whatever you want. This is
my intent for a payer solution that I am writing.
It's cheap, (free, the ftp server comes with Windows/linux/Unix).
Privacy is an issue that I could overcome with encryption but I don't want
to touch this issue right now, maybe in two weeks.
3.) Are there other routing and EDI transport mechanisms out there that I
forgot? Maybe email attachments? Those would be easy to encrypt at least.
Martin Scholl
Scholl Consulting Group, Inc.
301-924-5537 Tel
301-570-0139 Fax
[EMAIL PROTECTED]
www.SchollConsulting.com
----- Original Message -----
From: "William J. Kammerer" <[EMAIL PROTECTED]>
To: "WEDi/SNIP ID & Routing" <[EMAIL PROTECTED]>
Sent: Friday, May 31, 2002 4:54 PM
Subject: Re: Trading Partner ID - 'ZZ' rears its head
> 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
>
>
>
>
