William, I agree in principle with all you say below. But, there still remains the need to be able to indicate an interchange contains transactions intended for real-time processing rather than batch.
Use of the ISB segment would violate your desire not to place an undue burden on the provider by requiring the provider to have a system capable of generating the ISB and then each and every intermediary moving the transaction to its intended destination would also have to recognize the ISB and process it appropriately. Further, what about the provider that doesn't generate a fully compliant HIPAA interchange but only sends a non-standard transction to a clearinghouse. How would the provide designated such a non-standard transaction as one that is to be processed real-time? Seems to me that all of these types of potential service requests get subsumed into Peter's initial draft paper on EDI addressing and the necessary attributes of an EDI address. That paper seems to me to imply that a single EDI address with various attributes is the goal. The EDI address challenge is that in reality there could/may be a good and valid business reason why any given payer may wish to have more than one. For example, some payers may elect to have all of their electronic interchanges come through a single designated portal (clearinghouse); others may have several clearinghouse portals (perhaps as many as 5-8 or more); while yet other payers may selectively choose direct point-to-point with some providers while routing all other providers to a clearinghouse. Therefore, it's my opinion that a single EDI address for all players under HIPAA does not seem to be a realistic goal. And if one were to look at other forms of addressing in the non-EDI business information exchange model you would see that companies regularly have different addresses, e.g., street, P.O. Box, yet another for different departments, and yet another for receivables payments. If the business requirements in the non-EDI world demand multiple addresses for various business purposes, why wouldn't the same business requirement exist in the EDI world? Providing specifications for solutions to these potential business requirements will be a challenge, and if we didn't know that! Rachel Rachel Foerster Rachel Foerster & Associates, Ltd. Phone: 847-872-8070 -----Original Message----- From: William J. Kammerer [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 30, 2002 10:28 AM To: 'WEDi/SNIP ID & Routing' Subject: Re: Batch vs. Real Time transactions I hear what you're saying, Rachel. But to put the burden on the (many small) providers for solving a programming problem better handled by the (fewer and bigger) payers and their (expensive) EDI translator vendors would put another roadblock in the way of universal adoption of the HIPAA standard transactions. I envision the many (plebian) providers, with their pre-packaged practice management systems, generating standard transactions and dumping them into one funnel at their VAN. It's too bad the ISA doesn't have flags or what-not for indicating batch vs. real-time processing is requested - but it's the card we're dealt. Instead, the payer's translator should be parallel enough, with multiple threads handling any number of concurrent translations, so the issue of a "276 or a 270 ....queued behind another interchange containing an 837 with hundreds of claims" is not a problem; once the translator determined it was dealing with a task involving a real-time inquiry, the priority of that thread could be elevated. There are all sorts of programming ways to take care of these problems, and I don't think the provider should be called on to perform gymnastics to avoid them for the payer. And it would not be just the provider who would be penalized - how would the VAN know how to interpret entity addresses if a receiver code could really be a receiver code, plus, you know,...well, special flags? The ISA06 and ISA08 sender and receiver "addresses" should be unique and not overloaded with extra duty. That's the only way they can be interpreted unambiguously by all intermediaries. In addition, all the information needed for correct processing should be contained within the interchange itself - between the ISA and the IEA - as a self-contained package because it's too much to expect PM systems to support alternate "channels" for conveying information to the payer. And besides, the provider can be anticipated to only have a single "conduit" to the outside world - his VAN - the simplest model for supporting inter-company exchange. Actually, X12.5 does provide for the ISB - Grade of Service Request - segment, which can be used as sort of an "addendum" to the fixed length ISA; I think relying on the ISB for differentiating batch from real-time would be an acceptable compromise. The ISB occurs before the functional group is encountered. Unfortunately, the HIPAA IGs don't support it. William J. Kammerer Novannet, LLC. +1 (614) 487-0320 ----- Original Message ----- From: "Rachel Foerster" <[EMAIL PROTECTED]> To: "'WEDi/SNIP ID & Routing'" <[EMAIL PROTECTED]> Sent: Tuesday, 29 January, 2002 07:12 PM Subject: RE: Batch vs. Real Time transactions William, I believe that trying to distinguish batch vs real-time processing in the transaction or even at the GS level is too late. Say, for example, that one's real-time interchange containing a 276 or a 270 was queued behind another interchange containing an 837 with hundreds of claims or even a full 834 audit. Depending on the file access/database access methods used by the translator, as well as the throughput performance of the translator being used, your real-time 276 or 270 could get stuck in this queue. Therefore, I think it's critical that the detection of an interchange for real-time processing be done before the interchange is sent to the translator. Absent a different comm line or other mechanism which providers would use for routing real-time interchanges separate from batch, what would you propose. That's why it might be worthwhile - if one intends to process HIPAA transactions in both batch and real time to consider running another copy of the translator dedicated to real-time processing and the other copy dedicated to batch processing - to signal this at the ISA receiver id level. As you know, many companies in the supply chain routinely use multiple ISA receiver ids in order to separate priority interchanges from lower priority interchanges. Lastly, I also question whether suffixing the GS version identifier would be valid under HIPAA since the IG is quite explicit as to the total value of this element. Rachel Foerster Rachel Foerster & Associates, Ltd. Phone: 847-872-8070 -----Original Message----- From: William J. Kammerer [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 29, 2002 1:13 PM To: 'WEDi/SNIP ID & Routing' Subject: Batch vs. Real Time transactions The 270/271 implementation guide makes some recommendations on how to distinguish between Batch and Real Time transactions: If trading partners are going to engage in both real time and batch eligibility, it is recommended that they identify the method they are using. One suggested way of identifying this is by using different identifiers for real time and batch in GS02 (Application Sender's Code) for the 270 transaction. A second suggested way is to add an extra letter to the identifier in GS02 (Application Sender's Code) for the 270 transaction, such as "B" for batch and "R" for real time. Regardless of the methodology used, this will avoid the problems associated with batch eligibility transactions getting into a real time processing environment and vice versa. Overloading the GS sender code (using solely for internal routing by the recipient) is certainly preferable to requiring different sender or receiver IDs in the ISA, depending on Batch or real-time. But unless we come up with specific recommendations that apply across the board - for every provider and payer - stuff like what's in the IG will require a TPA (or "companion document"). We want to remove the need for TPAs, right? Anybody have specific ideas for differentiating batch from real-time? How about keying in on BHT03 - the Submitter Transaction Identifier? It's required to be used (in the 270) if the transaction is processed in Real Time - and since it can only be returned in a real-time 271 response, it seems like a most excellent marker. I do realize that makes it tougher for the payer to distinguish between batch and real-time inquiries, in that you have to drill into the bowels of the transaction set before knowing which queue to insert the request - but is that any more difficult than relying on the GS? William J. Kammerer Novannet, LLC. +1 (614) 487-0320
