William, The provider clearinghouse model typically receives proprietary formats and converts them to standard formats, and therefore ISA is not used and a 997 is not generated. What does happen is the user that sent the file has both inbox and outbox (BBS or FTP) for uploading and downloading data based on their user ID they used to connect to the Clearinghouse. The response was typically a proprietary response that feeds into the reporting/mgt system so the user could confirm receipt of each claim/transaction. If a ISA/IEA was sent for parsing into payer specific ISA/IEA, the business policy of the Clearinghouse was that the Sender ID was to be the same (or one to one relation) as the BBS/FTP User ID to avoid any confusion. Regardless of what was put in the ISA, the response was always placed into the BBS/FTP users outbox - this was a business decision to not support alias sender/receiver capability. The reverse is typically true for the Payer Clearinghouse, only the payer receives data in propriety format and responds in proprietary format, and the CH converts it to the Standards. Therefore, again the ISA or 997 has no part to play until the CH sends the ISA/IEA out to it's destination. In response to your example, I agree that an ISP is more like a VAN offering connectivity services, but a VAN may also include store and forward capabilities (file level transfers) between known entities. Very rarely did any of the VAN's we used offer the ability for someone to send anonymously or using an alias as you suggest in your e-mail example. That is why VAN's are still quite popular over the Internet for healthcare business transactions ( it's provides a simplified layer of authentication). IP based e-mail is an application service and it's also possible that the SMTP server is not even owned by the ISP, but by an ASP like Hotmail.com. If the ISP chooses to offer ASP services such as e-mail, then they offer addition value added services beyond connectivity and take on a more active roll in the delivery process. Depending on the sophistication of the services, ISP's providing ASP services could be acting more like a clearinghouse than a VAN, especially if the service involves any type of translation or modification of data. If I were to attempt providing a similar service via the EDI X12N format, I'd suggest the ISA Sender represents the ISP login and the GS is the e-mail Login (application functional group). Then if the routing service so chose to allow the user to submit under an Alias for another, the GS Sender could represent the alias "From" ID you use in your e-mail example. Of course this assumes the Interchange will provide such flexibility in it's routing and trading partner tables and the trading partners will support it as well.
As for having to breakdown the transactions to identify the original transaction owner - I believe that has been defined as beyond the scope of this group. Based on the remainder of your response, are you suggesting that the definitions offered are inappropriate? >>INTERCHANGE(ISA) SENDER: Entity responsible for preparing the transaction sets (ST/SE) into functional groups (GS/GE) and interchange controls (ISA/IEA) for transmission to the INTERCHANGE RECEIVER and for resolving a functional acknowledgment (997) that contains errors regarding the interchange. >> >>INTERCHANGE RECEIVER: Entity responsible for processing the function group and transaction sets (GS/GE, ST/SE) within an interchange control (ISA/IEA) and sending a functional acknowledgment (997) back to the ISA SENDER.<< Is it your position that the ISA Sender is equivalent to the return address label on the outside of an envelop? (i.e. it's only needed to send back a failed attempt to deliver?) If so, I agree and I believe the ISA Sender definition supports that position. If not, what changes would you recommend to either definition? Regards, Ronald Bowron
