Ron, I understand your argument, and it may in fact be true that healthcare transactions are very much different from other industries using X12 & the ISA/IEA packages. If we use the approach of placing the "processor's" identifier in the ISA08 (as distinguished from the "end point's" identifier), then my question is where does the "processor" get the identifier of the next hop (whether it be the endpoint or another processor). It seems to me looking at the transaction that the only place it would be available is loop 1000B or at the Detail Subscriber hierarchical level - loop 2010BC (Payer).
If 1000B is used, NM109 is the only place I can find where an identifier can go, and it only allows code 46 (Electronic Transaction Identification Number (ETIN) in NM108 which leaves out DUNS, EIN, TIN, and all those other identifiers proposed. Perhaps these other identifiers can be used to look up the ETIN? What also bothers me about using loop 1000B is that there is no loop 1000 in the 270/271 or 276/277, which means that we would be recommending a different place to get the identifier between the 837 and these other transactions. If the "processor" uses loop 2010BC, then there are 2 potential places to look, but the same problem exists - these other identifiers are not allowed: NM109 (only codes allowed in NM108 are PI & XV); or REF02, which at least allows the TIN (REF01 code TJ). For 270/271 & 276/277 the equivalent would be 2100B or 2100A. It would seem to me to make sense to use whatever standards are already set by the X12 standards organization regarding use of the ISA/IEA. If, as Rachel points out, ISA use in other transactions in other industries is always the endpoint processor, then we should probably follow that lead - even though it means more transactions and more 997s. Dave Minch T&CS Project Manager John Muir / Mt. Diablo Health System Walnut Creek, CA (925) 941-2240 -----Original Message----- From: Ronald Bowron [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 09, 2002 1:39 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: Are only 15 characters in the ISA receiver ID enough? Rachel, You may recall that we had submitted definitions for ISA sender and ISA receiver that I thought were considered acceptable. The basic concept is that the sender is the entity responsible for creating the exchange and it's contents and the receiver is responsible to processing the contents of the exchange. So, if the contents of the entire exchange (ISA to IEA) will be processed entirely by the receiver, then yes the ISA receiver will most likely be the provider or payor. But in many cases, data will be sent to a clearinghouse for the expressed purpose of processing the contents within the ISA to IEA and the repackaging the contents for transport to the ultimate receivers. In these cases, the ISA sender is a provider, but the receiver is the clearinghouse. While it may seem logical for a provider to send an ISA/IEA for each payor to the clearinghouse, that could make managing the transmission cumbersome. Instead of one 10Mb transmission with a 997 response, they could end up with 100+ transmitted files and 100+ responses. This can make managing the EDI interface too complicated for the average system environment. Although, there are some valid arguments regarding the complexities associated with bundling transactions within a single ISA/IEA. The mistake we keep making with regards to the Post Office comparison is we leave out two very important concepts - the type of Stamp we place on the envelope and the mailbox we initially place the letter into. If you put a FedEx package in your U.S. post office box, would it be sent? You first must determine the routing service (U.S. Post Office, UPS, Fedx). The other attributes on the package or envelop are dictated by the service chosen. The U.S Post office expects all envelops to be filled out the same way, but FedEx and UPS use another labeling method (although with similar routing attributes). We cannot assume a single transport or exchange, just like all packages currently do not get sent via one mailing service. The we previous challenges we faced within the current healthcare industry was the potential number of possible exchanges (VANs, Clearinghouses, direct connects, etc.). Each of these must be considered as a potential delivery service that has their own exchange (stamps and labeling) methods. Fortunately the EDI/X12 standards requires all players to accept the same exchange format (ISA/IEA). To fulfill the proper analogy with the existing mailing services, I believe the ISA/IEA is more closely associated with the Return Address (Sender) and the Stamp or mailing method (Receiver) - if a problem occurs, the receiver knows where to return the package. The type of package is represented by the GS/GE and ST/SE segments (priority, ground/air, letter, box , etc.) and the final destination address is something evaluated by the receiving party (U.S. Post office) to determine how to route it internally until it can be delivered to it's final destination (transaction level address) so the details of the transaction can ultimately be processed by the receiver of the package. While it is difficult to build a complete correlation between physical mailing vs. electronic mailing of transactions, we cannot ignore the stamps and labels required by the mailing services. Regards, Ronald Bowron
