William, The facilities to identify Batch versus Real time processing may be provided by an underlying messaging service which would eliminate the need for "flags" within the transaction sets. For example, ebXML's Message Service contains a header attribute, called syncReply, to inform the receiver that a sender is expecting a "Real Time" (synchronous) response. Batch mode processing is indicated by absence of the syncReply attribute.
Perhaps it would be worthwhile for the group to define some expectations/requirements with regard to the infrastructure needed to support transaction exchanges. One example requirement might be: - The Transport mechanism MUST support Batch and Real Time processing. - ... Dick Brooks Systrends, Inc 7855 South River Parkway, Suite 111 Tempe, Arizona 85284 Web: www.systrends.com <http://www.systrends.com> Phone:480.756.6777,Mobile:205-790-1542,eFax:240-352-0714 -----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
