William, It's for the reasons you state below that I early on encouraged everyone to agree on terms and definitions. We've been bandying about the terms sender, submitter, receiver, etc., without any clear, unambiguous agreement on the definition of each of these terms....and not just in the context of a claim transaction, but across the entire scope of HIPAA transactions - and beyond.
In each of the HIPAA IG's there are terms, such as information receiver, information source, sender, submitter, patient, subscriber, dependent, member, and so on that have somewhat different definitions. And what about the term intermediary? It too has different meanings depending on the viewpoint of the user and the context. Is an intermediary a clearinghouse, a TPA, a repricer, a billing service....what? Unambigous and standard semantics are essential. Rachel Foerster Rachel Foerster & Associates, Ltd. Phone: 847-872-8070 -----Original Message----- From: William J. Kammerer [mailto:[EMAIL PROTECTED]] Sent: Friday, January 25, 2002 3:53 PM To: WEDi/SNIP ID & Routing Subject: Re: Transactions with mult. senders and mult. receivers Bob's description of the 837 with respect to multiple providers and payers has been fascinating, and there's no doubt it helps us to understand what really goes on out there. And like Chris, someday I'd like to find out why things are done this way within the confines of a particular intermediary. But I differ with Chris: I don't think this is a problem of routing. It's important to remember that for any one X12 interchange, there's only *one* sender (or submitter) and *one* receiver - regardless of the number of payers or providers whose "stuff" is embedded in a single 837. To get some boundary on definitions, is it safe to say that the sender is definitely the guy who creates the ISA? What can we say about the receiver? I would submit that our job is only concerned with the identification of the trading partners (who may be clearinghouses, billing services, repricers, etc. - not just providers or payers) at the ISA level, and the issues of routing - what's needed to be known in order get the interchange from here to there. What any intermediary - such as a clearinghouse - does with the enclosed transactions (and functional groups) is simply none of our business - project scope-wise. Such a simplifying assumption should assist us in maintaining focus. William J. Kammerer Novannet, LLC. +1 (614) 487-0320 ----- Original Message ----- From: "Christopher J. Feahr, OD" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Cc: "Joe Fuchs" <[EMAIL PROTECTED]>; "Michael Smith" <[EMAIL PROTECTED]>; "Ross Hallberg" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Friday, 25 January, 2002 02:06 PM 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
