Now I'm really stumped. Can someone explain the business use-case for a single 837 transaction set needing to have multiple "senders" and/or multiple "receivers"? I assume that Bob was not referring here to secondary payors, but to real, honest-to-god, multiple addressees for a single transaction set?
I understand that a single interchange envelope can have many claim transactions in it, but I always though of that as "many 837s". And I also understand that a single interchange can even contain a "functional group" of many 837s, a "functional group" of 271s, etc. But if a single provider wants to send 2 PRIMARY claims, one to payor A and the other to payor B, why wouldn't he sent 2 separate 837 transactions sets? And if Doctor A has a claim for Payor X and Doctor B also has a claim for Payor X, why wouldn't this also [always] be two separate 837 transactions? Even if the IG allowed the combining either of the last two scenarios into a single 837, I cannot imagine why anyone would ever want to do something that difficult to route. Cant' we strongly advise against such a practice even if it is permitted in the standard? -Chris At 08:14 AM 1/25/02 -0500, [EMAIL PROTECTED] wrote: >Also, note that loop 2000A occurs >1 times, allowing for the identification >of multiple billing providers, or "submitters", in each 837. > >While most of X12 defined transactions as single business 'documents' (i.e. >one invoice in a transaction), health care in its wisdom defined a >transaction that contained MULTIPLE business documents. That is causing us >problems now. It adds levels of complexity that do not exist in other parts >of the EDI community. Christopher J. Feahr, OD http://visiondatastandard.org [EMAIL PROTECTED] Cell/Pager: 707-529-2268
