Chris, Bravo. Well said. I fear we've headed down a path of such complexity that the complexity itself becomes the barrier to the goal. Somehow the KISS principle seems to have gotten left in the dust.
Rachel Foerster Rachel Foerster & Associates, Ltd. Phone: 847-872-8070 -----Original Message----- From: Christopher J. Feahr, OD [mailto:[EMAIL PROTECTED]] Sent: Friday, January 25, 2002 1:07 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: Joe Fuchs; Michael Smith; Ross Hallberg; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Transactions with mult. senders and mult. receivers 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
