Ronald: I wasn't implying there's any need for "anonymous" healthcare transactions - that sounds too much like spam! And there really isn't the equivalent need for broadcasted RFQs - which aren't anonymous, anyway, as the sender is always known (it's just the receivers who don't know of each other) - as there would be in the supply chain world.
Again, the ISA should be used only to get an interchange from here to there. If a VAN or CH wishes to restrict usage of sender IDs depending on who logged on (determined from user ID and password in a separate logon process), that's their business. I've always thought the ISA should not be used for authentication (just identification) - that's a job for other controls, such as user logon or certificates, which may or may not be in scope for this project. Once we've established recommendations for getting stuff from here to there based on the ISA, we might suggest uses for the GS in handling internal routing - we should add that to our list of things to possibly do. The definitions for Interchange Sender and Receiver seem quite adequate and appropriate - they say what I've maintained all along. The ISA Receiver field is only needed to return TA1s and 997s (and possibly 824s reflecting IG violations). Application acknowledgements, such as the 835 answer to the 837, and the 277 answer to the 276, would not necessarily be sent to the ISA sender of the original request - instead, the ISA receiver would be "calculated" based on NM1s in the original request. William J. Kammerer Novannet, LLC. +1 (614) 487-0320 ----- Original Message ----- From: "Ronald Bowron" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, 06 February, 2002 09:42 PM Subject: Re: Sender/Receiver Definitions for HIPAA 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
