Bob, I understand today's situation as you describe it below. On the other hand, if the industry is to truly achieve **administrative simplification** it must recognize that merely implementing EDI does not achieve the goal of taking cost out of the process and that administrative simplification is not a byproduct of achieving HIPAA compliance.
The reality is - and other industries have learned this over the years - that the real benefits of EDI lie not in the mere exchange of electronic information, but in truly improving (redesigning) the underlying business processes. Most critical to be addressed are not the interfaces where an organzation's business process is exposed to an external business entity, but the internal business processes that enable and support the organization's business goals. However, this is where the real pain and effort is rather than just slapping an integration engine (EDI translator) in front of an application system. Without making this hard, long and arduous effort to truly address the inefficient and ineffective internal business processes, it's all cost and and window dressing. EDI, whether one uses the X12 or UN/EDIFACT standards, or the new kid on the block, XML, is just an enabler, it's not the solution. The willingness to change business processes is where the big win will be. Rachel Foerster Rachel Foerster & Associates, Ltd. Phone: 847-872-8070 -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, January 25, 2002 3:25 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; Joe Fuchs; Michael Smith; Ross Hallberg; [EMAIL PROTECTED] Subject: Re: Transactions with mult. senders and mult. receivers Chris, Right - I was not talking about secondary claims. What I was saying was - if you define sender and receiver as original sender and ultimate receiver then you loose the one to one relationship. A clearinghouse can receive 10 837s from 10 providers. Each provider can be sending claims to 10 different payers in their 837. When the clearinghouse resorts and organizes the claims they produce 10 837s for each of the 10 payers that contain claims from each of the 10 providers. Each 837 from the CH to a payer contains claims from multiple original senders. Each 837 from a provider contains claims for multiple ultimate receivers. We can't standardize an ISA identifier on an end to end basis without first adding a restriction to the existing process that would establish a one to one relationship that does not exist today. That is why I have tried to focus on the point to point concept for addressing, where original sender and ultimate receiver are not identified within the ISA at all. Bob "Christopher J. Feahr, OD" To: [EMAIL PROTECTED], [EMAIL PROTECTED] <chris@optiser cc: Joe Fuchs <[EMAIL PROTECTED]>, Michael Smith v.com> <[EMAIL PROTECTED]>, Ross Hallberg <[EMAIL PROTECTED]>, [EMAIL PROTECTED], [EMAIL PROTECTED] 01/25/2002 Subject: Transactions with mult. senders and mult. receivers 02:06 PM 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
