Oftentimes, information from the ISA and GS envelopes is lost by the time the partner would have processed the eligibility inquiry. There may be no way to insert an image of the original GS02 in the turnaround response's GS03 for reverse routing, unless additional work is done on the partner's side. The whole job becomes exponentially more complicated when clearinghouse intermediaries are involved. In general, it's best not to count on using any information other than what is supplied in the application transaction set (e.g., the 271 response) for internal routing decisions.
Additionally, I doubt there's anything in the HIPAA IG that keeps a information source (the payer) from bundling multiple patient responses to any number of separate batch inquiries in the same 271, somewhat along the lines of what Rafael Sosa alluded to. So, even though the 270/271 and 276/277 are called "paired" transactions, there may not be a one-for-one correspondence between any particular 270 or 271. This makes it impractical to rely on the BHT03 Submitter Transaction Identifier, except in the context of real-time transactions where the IG mandates one logical inquiry (e.g., patient request). Thus, the TRN02 Claim Submitter Trace Number seems to be the only 100% reliable way of matching inquiries to responses. I think it would be a Sisyphean task for Jean to get the payer to change his systems to accommodate business unit logic at the GS level. Especially, after having read this list for a couple of months, considering it's like pulling teeth to get payers to follow the HIPAA IGs for the simple, mandated things! Jean says Almost Family has "one server and each business unit has its own database." I assume that means one translator at the front door. If so, there really should be no need to pre-process the EDI or "parse it out by subscriber." The transactions should only need to be translated once, as soon as they come in the door. The data extracted by the translator then could be shuffled and dealt to the individual business unit databases using TRN02. William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 ----- Original Message ----- From: "Laurance Stuntz" <[EMAIL PROTECTED]> To: "WEDI SNIP Transactions Workgroup List" <[EMAIL PROTECTED]> Sent: Wednesday, 02 April, 2003 01:41 PM Subject: RE: 276/277 BHT Reference Identification I would use the GS02 to identify the application (business unit) that sent the request and then your trading partners have to reflect that in the GS03 they send back ensuring that you can route the response to the correct core application (business unit). You could build the BHT03/TRN02 using business unit as part of the key but then in order to route the transaction your router has to "open up" the envelope, understand the structure of the individual transaction, and then find the right part of the transaction before it can figure out where to route it. Are your trading partners claiming that they can define what you put into the GS02? I have run into organizations doing that, but have never understood why they think that is a reasonable activity. Maybe someone on the list could defend this "process" if your organization engages in it? Regards, Laurance Laurance Stuntz Principal Global Health Solutions Computer Sciences Corporation office phone: 781.290.1479 fax: 781.890.1208 ----- Original Message ----- From: "Jean Gidcumb" <[EMAIL PROTECTED]> To: "WEDI SNIP Transactions Workgroup List" <[EMAIL PROTECTED]> Sent: Wednesday, 02 April, 2003 12:08 PM Subject: RE: 276/277 BHT Reference Identification No my fingers didn't slip, but I didn't copy everything from my original email. Here is the last of the paragraph. I am, also, going to have a similar problem with the 270/271 and 278, but I noticed in these transaction sets the BHT03 is used. Would it be reasonable to use this data element to put the originating business unit in the 270 and 278 request, if I do will the trading partner send back my information i n the 271 and 278 response or will they put their own information? We do put the location and client number in the TRN02 data element, we have added the business unit code, but I was hoping we could do this in upper level loop, so we wouldn't have to parse it out by subscriber. Our problem is that we have one server and each business unit has its own database, so we need to know where the information from the file needs to be loaded and our trading partner is telling me I can't have a Trading Partner for each of my business units. Thanks, Jean Gidcumb HIPAA Project Manager Almost Family, Inc -----Original Message----- From: William J. Kammerer [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 02, 2003 11:27 AM To: WEDI SNIP Transactions Workgroup List Subject: Re: 276/277 BHT Reference Identification Jean, can't you just use the Claim Submitter Trace Number in the 2000D Subscriber Level loop in the 276? The submitter (you, I presume) gets to pick the arbitrary "cookie" to be placed in TRN02 - which the receiver (the payer) is obliged to return, verbatim, in the Subscriber Level loop within the 277. "but I...."?? Did your fingers just slip? William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 ----- Original Message ----- From: "Jean Gidcumb" <[EMAIL PROTECTED]> To: "WEDI SNIP Transactions Workgroup List" <[EMAIL PROTECTED]> Sent: Wednesday, 02 April, 2003 09:04 AM Subject: 276/277 BHT Reference Identification Hi, We are trying to setup a way to identify which business unit a particular claim status transaction set needs to be sent when we receive the response from our Trading Partner. I am looking at the BHT segment data element BHT03. It seemed like this would be the place to put the Originating business unit information. The problem is that in the 276 the data element is not used, but in the 277 the data element is used. Also, in the 277 it is a required data element. Does anyone know why they did it this way and if it will change in future versions? I am, also, going to have a similar problem with the 270/271 and 278, but I Jean Gidcumb HIPAA Project Manager Almost Family, Inc --- The WEDI SNIP listserv to which you are subscribed is not moderated. The discussions on this listserv therefore represent the views of the individual participants, and do not necessarily represent the views of the WEDI Board of Directors nor WEDI SNIP. If you wish to receive an official opinion, post your question to the WEDI SNIP Issues Database at http://snip.wedi.org/tracking/. These listservs should not be used for commercial marketing purposes or discussion of specific vendor products and services. They also are not intended to be used as a forum for personal disagreements or unprofessional communication at any time. You are currently subscribed to wedi-transactions as: [EMAIL PROTECTED] To unsubscribe from this list, go to the Subscribe/Unsubscribe form at http://subscribe.wedi.org or send a blank email to [EMAIL PROTECTED] If you need to unsubscribe but your current email address is not the same as the address subscribed to the list, please use the Subscribe/Unsubscribe form at http://subscribe.wedi.org
