Having worked in several clearinghouse environments, I can tell you that the Sender/Receiver ID in the ISA was not used much and usually not relied upon for Batch processing, which is how clearinghouses typically do business. Because users generally logged into BBS's or FTP'd data, we already knew who they were and managed the identity of the sender and assumed we were the receiver. - Why else would they be sending it - ;) One specific distinction that I see with regards to the ISA Sender/Receiver would be who's responsible for bundling and processing the transactions within. For example, in a pure routing schema, the Sender (Provider) bundles transactions and therefore is the ISA Sender, the VAN routes, but doesn't process the transactions, and the Payer receives them and processes them. Therefore the Payer is the ISA Receiver. This example also assumes every transaction between the ISA/IEA including all GS/GE's belong to the Receiver or will be processed by the Receiver in some form. The objective for this example is for the VAN to have routing capabilities to all receivers - otherwise we have all kinds of problems being introduced to support multiple connections at the providers location. In a Sender-CH-Receiver example, the Sender bundles the transaction or multiple transactions for multiple payers and providers. So for example, the Sender could be the Provider(create of transactions) and the Receiver is the Clearinghouse. Why? Because the Clearinghouse must process every transaction in order to separate them by ultimate payer/provider/receiver. When the Clearinghouse finishes separating, it will batch them into new ISA/IEA GS/GE loops or into propriety formats. The Clearinghouse becomes the Sender and the Payer/Provider (or another Clearinghouse) becomes the next Receiver. So I see our definition of the ISA Sender/Receiver ID being quite easy to define. If you create (or bundle) the transactions, you are the ISA Sender. If you must process the transactions upon receipt, even if it's to simply aggregate similar transactions together, your a ISA Receiver. 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. Notice that the ISA Sender is not necessarily the entity the created the transaction. This is because a Billing Service may be the ISA Sender for a Provider of the Transaction. And if a 997 is sent back stating the interchange failed, the entity that built them should be responsible for correcting it and transmitting the data. Within the ISA RECEIVER definition, I didn't know how to avoid the situation where the 997 is not sent. But I figured, even if it's not required they have responsibility for sending it should it be requested.
This definition could also be functional in a propriety schema simply by removing the X12N segment examples - and giving words like Interchange, functional group, transaction set generic meanings that fit most if not all proprietary formats. Comments? Ronald Bowron >>> "William J. Kammerer" <[EMAIL PROTECTED]> 02/01/02 02:56PM >>> See "EDI Meets the Internet: Frequently Asked Questions about Electronic Data Interchange (EDI) on the Internet," RFC 1865 at http://www.ietf.org/rfc/rfc1865.txt , especially sections 5.8. Can the ISA 06 or 08 identify any entity other than the 'end' Trading Partners (i.e. a routing entity)?, and 5.10. Are there other options for routing EDI X12 messages? ...although the ISA06 and ISA08 elements are supposed to be used to identify the sender and receiver of the interchange, the receiver of the interchange could be a clearinghouse (as well as a VAN) that processes the interchange and then forwards the data to the ultimate recipient. In this case, you could put the receiver ID of the clearinghouse into the ISA08. The clearinghouse would probably have to determine the ultimate recipient of the message by looking inside the transaction set (or perhaps by using the GS03). Though this IETF RFC is obviously not a HIPAA document, it proves as of 1996 that this was not a weird practice. The TA1 and 997 go back to the sender in the ISA, whether a CH, billing service or the "real" provider. What's the problem with calling the CH who builds the ISA the "sender" or "submitter" in order to differentiate him from the "providers" he's aggregating? If the provider (or his agent) puts the provider's ID in ISA06, then the provider is also the sender (or submitter). Analogously, the "receiver" could be a CH or payer. A payer is always a payer, and even sometimes the "receiver" in the ISA. I appreciate that we eventually have to get unambiguous definitions put down, but none of the stuff Bob Poiesz is describing violates some sacrosanct rule about ISAs or 837s. William J. Kammerer Novannet, LLC. +1 (614) 487-0320 +1 (614) 638-4384 (c) +1 (928) 396-6310 (FAX) ----- Original Message ----- From: "Rachel Foerster" < [EMAIL PROTECTED] > To: "WEDi SNIP 4 (E-mail 3)" < [EMAIL PROTECTED] > Sent: Friday, 01 February, 2002 01:02 PM Subject: Sender/Receiver Definitions for HIPAA As a follow up to the intermittent, but continuing, discussion of who is the "real" sender and receiver for HIPAA interchanges I did a search on the current HIPAA IG's to see what I could find. Interestingly, no where do the HIPAA guides ever indicate that the sender is or could be a clearinghouse. I think we need to clearly get this out on the table and reach consensus on this issue as well before the water gets so muddied it can't be cleared. Below are some excerpts from the various guides that illuminate this topic. Rachel Rachel Foerster Rachel Foerster & Associates, Ltd. Phone: 847-872-8070
