The ISA receiver ID is defined as follows in the IG: "Identification code published by the receiver of the data; When sending, it is used by the sender as their sending ID, thus other parties sending to them will use this as a receiving ID to route data to them"
The definition seems to imply that ISA08 is some sort of an "EDI address". But even if you can identify the receiving entity with one of the permitted numbers, it is still likely to have a variety of application-specific or possibly sender-specific EDI addresses... that might change over time. Can interchanges be going out the door with identical ISA08 values (identifying the receiver), but be going to different EDI addresses... because of their specific transaction payloads? With only 15 characters in the receiver ID, I don't see how we can identify the entity (via DUNS, FEIN, etc.) and have enough room left to fully specify even a unique registry-pointer to the rest of the "collaboration" details. This fuzziness about what the standard requires in ISA identifiers, combined with the "creative" uses that Michael Mattias has described is making it hard for me to visualize how anyone could route these messages WITHOUT drilling down into the transactions to get information about the true communicating parties. I'm beginning to think that there may not be enough intelligence in the ISA/ISE envelope to route these things. Either the current (several week long) trading partner negotiation and testing process would have to take place for every messaging-entity-pair, or we would have to implement something like the full-bore ebXML CPP/CPA for fully automatic negotiation. In that case, we could use the ebXML transport protocol to carry the X12 interchange as a "dumb" payload... rendering the ISA identifier unimportant. Does it still seem feasible to the group to have hundreds of thousands of communicating parties trying to route these messages on the basis of a 15 character ISA identifier? -Chris At 04:40 PM 3/29/02 -0500, William J. Kammerer wrote: >Keep in mind that if the Registry is powerful enough to be searched by >any (non-proprietary) ID, then the sender could just blindly stick the >FEIN in the ISA receiver ID, knowing full well that a VAN or CH >intermediary could search the Registry for the CPP which contains the >EDI addresses and ports. The whole concept of a "preferred" ID may give >way to a more powerful notion whereby a receiver can be identified in >the ISA by any of its known IDs (whose domains or type are allowed by >the HIPAA IG). Christopher J. Feahr, OD http://visiondatastandard.org [EMAIL PROTECTED] Cell/Pager: 707-529-2268
