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 ----- Original Message ----- From: "Rachel Foerster" <[EMAIL PROTECTED]> To: "'WEDi/SNIP ID & Routing'" <[EMAIL PROTECTED]> Sent: Saturday, 26 January, 2002 11:13 AM Subject: RE: Whose name is it, anyway? - and just how many do you think I have? William, The determination of a batch versus real-time use of the 270/271 or the 276/277 cannot be determined by the GS segment, nor even anything within the ST/SE envelope either. The Functional Group ID for these transactions is the same regardless. Rachel Foerster Rachel Foerster & Associates, Ltd. Phone: 847-872-8070 -----Original Message----- From: William J. Kammerer [mailto:[EMAIL PROTECTED]] Sent: Friday, January 25, 2002 5:51 PM To: 'WEDi/SNIP ID & Routing' Subject: Whose name is it, anyway? - and just how many do you think I have? There are only so many IDs that an entity might have - what if a Payer only has (one) NAIC that it publishes as its EDI ID, and refuses to use its D-U-N-S or FEIN? Isn't the purpose of the interchange (test, production, real-time) a separate issue from the ID of either the receiver or the sender? I realize many people feel queasy about using the ISA I14 Usage Indicator (e.g., P for Production Data, T for Test Data) to indicate whether an interchange is batch or production, but surely it is overloading the ISA receiver ID to burden it with the duty of segregating test from production. Further, I would be loathe to burden the sender with the need to pick ISA receiver IDs from a list depending on whether the interchange is batch or real-time. Why should a provider have to make that decision - to select the appropriate receiver ID arbitrarily imposed by the payer for a particular purpose - when the function of the interchange can be readily determined by the payer? For example, the payer can discern that real time transactions, like the Eligibility Request, are included in the interchange simply by looking at the functional group ID on the GS. 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, 22 January, 2002 01:59 PM Subject: RE: Whose name is it, anyway? William, Additionally, payers may wish to use more than one ISA id for different business purposes: one for trading partner implementation testing; another for when the TP is rolled into production; another for real-time processing, and so. Thus, I concur with your conclusion that the payer should establish their ISA id(s) and make these publicly available. Rachel Foerster Rachel Foerster & Associates, Ltd. Phone: 847-872-8070
