Ron, This does sound useful, but I don't think there is anything like a 1000 loop in all transactions that might benefit from such a strategy. Your suggestion, however, does make me think that we should have a "smarter" ISA segment... one that could hold the "next stop" and the "final" destination (?). -Chris
At 02:29 PM 3/1/02 -0700, Ronald Bowron wrote: >Chris, > >Not to confuse the issue any further, I think I have a potential >business case: > >It may be possible to use the 1000 loop for non-edited "pass-through >processing". For example, if the 1000 loop contains the receiver ID of >the Business Associate, they would know that they need to do some >additional processing of the transaction before it goes onto it's >destination. If it contains any other receiver ID, then it is simply >queued to go to theat destination. > >This could be used in an environment where a VAN/Clearinghouse is also >acting as a re-pricer on specific claims. > >While I'm not sure why they would do it this way, rather than sending >two separate ISA/IEA sets, it's possible. > >-RB > > >>> "Christopher J. Feahr, OD" <[EMAIL PROTECTED]> 03/01/02 11:18AM > >>> >Jan, >Thanks for this explanation. It sounds like the "original" and >"ultimate" >concepts have essentially been removed from "submitter" and "receiver" >in >1000 loop, leaving it to describe the immediate, point-to-point >submitter/receiver. So how does loop 1000 provide more useful >information >than what we have in the ISA? This really ties into some of the issues >we >are struggling with in the "Routing and Identifiers" project. If all >the >"outside world" EDI addressing issues can be kept inside a >point-to-point >model, then we only need to put the principal identifiers and addresses >in >the ISA... eliminating the need for loop 1000 all together, and using >the >plan, provider and subscriber/patient ID information further down in >the >transactions to accomplish "internal" addressing and routing. > >A dichotomy seems to be developing within the "addressing and routing" > >discussion between a model that makes sense conceptually to a "small >provider" and/or his software vendor, and one that makes sense to a >CH... >at least in the CH-world as it exists today. (Trying to predict what >the >CH world will look like in 2004 is threatening to make my head >explode!) > >What would be the consequence of just erasing Loop 1000 from the IG? > >Regards, >Chris > >At 12:15 PM 2/25/02 -0700, Jan Root wrote: > >Chris/Raj, > >This is a very interesting question and it may have several answers. >It > >has been > >discussed at great length by both the 837 and the 276/277 WGs in the > >past. I know > >there are several people on this list serve who might have a different > > >memory than > >I do of this discussion so feel free to chime in if you think I have > >mis-remembered anything! > > > >Chris has it correct as far as the description of Loop 1000 in the 837 > > >goes. We > >did originally intend that the original submitter would be whoever >actually > >packaged up the 837 to begin with and the receiver would be whoever >was > >supposed > >to ultimately get it. It was not intended to be a point-to-point > >identification. > >But sometimes intentions don't match well with reality. > > > >The difficulty comes in that that approach doesn't work well for > >clearinghouses. > >Our intention did not align well with current practices. >Clearinghouses > >currently > >act as gathering points for many small sources of claims, and it is >more > >efficient > >for them to be able to bundle all these many small sources into one >large > >transaction to send to the next receiving entity. Clearinghouses want >to > >become > >the 'submitter' when they send a package of claims (that they've >collected > >from > >many providers) to a payer (or to the next clearinghouse or whatever) >who > >is then > >the 'receiver'. > > > >As you know, there can be many intermediary entities on the path of >getting a > >claim from a provider to a payer: clearinghouses and various repricers >can all > >have edits and even add/change claim data depending on their contracts > > >with each > >other. In this model, the 'submitter' is who ever is the immediate > >submitter of > >the 837 and the 'receiver' is the point-to-point receiver, that is, >the > >entity who > >is receiving the 837 from the 'submitter' (all of which information is > > >redundant > >with the information in the ISA). > > > >This issue was discussed at some length during a 276/277 WG conference > > >call last > >year and, to make a longish discussion short, the conclusion was that >the > >definition of who is the receiver and who is the submitter in the 837 >Loop > >1000 is > >left to the trading partners. We went through a lot of detail tracking > > >tracing > >numbers (we were trying to model the flow of trace numbers between the >837 > >and the > >277 Front-end Acknowledgement transaction to make sure the 277FE > >transaction would > >work) and this trading-partner-by-trading-partner variation will work >as > >long as > >everyone clearly knows what's going on. I can send you a diagram of >this > >flow if > >you'd like to see it although the details of the 277FE information >won't > >make a > >lot of sense without a copy of the transaction. Still, you can >probably get a > >sense of what is involved in tracking these trace numbers through >various > >transmission entities. > > > >Hope this helps. > > > >Jan Root > > > > > > > > > > > >"Christopher J. Feahr, OD" wrote: > > > > > Raj, > > > "Submitter" (in Loop 1000 of the 837) seems to refer to the entity >who did > > > the original packaging of the transaction (within the first >interchange > > > that it traveled in)... generally either the provider or the >provider's > > > business associate. The "Receiver" in loop 1000 would be the >original > > > destination target for the claim... generally either the payor or >the > > > payor's designated business associate. Based on my reading of the >front > > > matter on the Loop 1000, these submitter/receiver designations >remain fixed > > > for the life of the transaction. A repricing function would not >seem to > > > change the identities of the original submitter/receiver. An >alternative > > > use of loop 1000 as an audit trail of all parties who "opened" the > > > > transaction is mentioned, but the IG advises against using Loop >1000 in > > > this way. > > > > > > Based on my reading of the IG, I would say that a "repricer" would >leave > > > loop 1000 information on the repriced claim exactly the same as >when he > > > received it. What is not clear to me, however, is the intended >business > > > use of loop 1000. EDI addressing for the interchange will always be > > > > accomplished with the ISA sender/receiver fields. So is the loop >1000 > > > "submitter" ID supposed to contain an EDI address for "answering" >messages > > > like requests for additional information, error messages, possibly >even > > > claim payments? If so, then every transaction capable of triggering >an > > > "answering" message should have one of these and its usage in the >IG should > > > be explained a little better. > > > > > > Am I interpreting the IG correctly? > > > > > > Regards, > > > Chris > > > > > > At 06:22 PM 2/22/02 -0500, Thuppanna, Raj wrote: > > > > > > >I have a question about submitter/receiver in a re-pricing model. >In this > > > >example, we receive the claim for re-pricing. We are not >destination > > payer. > > > > > > > >According to 837 IG in the scenario where a provider (or providers >billing > > > >service) sends the electronic claim to us for re-pricing, the >provider is > > > >the submitter and we are receiver. We then re-price the claim and > > > forward it > > > >to destination payer. Who should be the submitter and receiver >when we > > > >forward the claim to payer? My understanding based on IG is that >submitter > > > >and receiver should remain same when we forward the claim to >destination > > > >payer. But It doesn't make sense for us to be receiver here. > > > > > > > >In the same model, it we get a paper claim from a provider and >then > > forward > > > >the re-priced claim, who should be submitter and receiver? My > > understanding > > > >is that we are the submitter and destination payer is the >receiver. > > > > > > > >Any help is appreciated > > > > > > > >Thanks > > > > > > > > > > > >Raj Thuppanna > > > >770 444 4468eho is the receiver and who is the sub > > > > > > > > > > > > > > > > > > > > >********************************************************************** > > > > >To be removed from this list, send a message to: > > [EMAIL PROTECTED] . > > > >Please note that it may take up to 72 hours to process your >request. > > > > > > Christopher J. Feahr, OD > > > http://visiondatastandard.org > > > [EMAIL PROTECTED] > > > Cell/Pager: 707-529-2268 > > > > > > >********************************************************************** > > > To be removed from this list, send a message to: > > [EMAIL PROTECTED] . > > > Please note that it may take up to 72 hours to process your >request. > > > > > > > >********************************************************************** > > >To be removed from this list, send a message to: >[EMAIL PROTECTED] . > >Please note that it may take up to 72 hours to process your request. > >Christopher J. Feahr, OD >http://visiondatastandard.org >[EMAIL PROTECTED] >Cell/Pager: 707-529-2268 Christopher J. Feahr, OD http://visiondatastandard.org [EMAIL PROTECTED] Cell/Pager: 707-529-2268
