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 4468 > > > > > > > > > > > > > > >********************************************************************** > > >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
