Marcallee, I can't believe the providers allowed the looping to go on that long -- I'm surprised that they didn't do some direct payer follow-ups along the way to find out that the claims were looping.
You bring up a very good point! When I send a claim to the "first-hop", I expect to get a 997 back which tells me that it at least got there. If the "first-hop" isn't the intended final receiver of the claim, I probably won't ever get to see any other acknowledgements from the other "hops" to give me confidence that the claim is progressing at a reasonable pace. Aside from the original intended use of loop 1000 (see page 40 in the 837 IG) there doesn't appear to be any other way to record who opens the envelope. Yet one more reason to want to go direct to the payer... Dave Minch T&CS Project Manager John Muir / Mt. Diablo Health System Walnut Creek, CA (925) 941-2240 -----Original Message----- From: Rachel Foerster [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 24, 2002 3:26 PM To: WEDi SNIP 4 (E-mail 3) Subject: FW: Need to know routing path I'm posting Marcallee's message below to the list for her since for some reason she has been temporarily prohibited from posting directly. Rachel -----Original Message----- From: Marcallee Jackson [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 24, 2002 1:36 AM To: [EMAIL PROTECTED] Subject: RE: Whose name is it, anyway? Rachel- While it may not be important to the payer/receiver what path the claim takes, it is often important to the provider who might like to have some sort of record of where his claim was sent. Particularly if claims are being delayed by several days while they pass from trading partner to trading partner. Pull up a WebMD payer list and see if you can tell which payers they send direct and which they send through trading partners. I think most providers would appreciate an easy way to follow a claim's path. Perhaps important to remember is that most clearinghouses will translate every single claim that comes into their operation into an internal format before translating it yet again into an outbound format (which may or may not be standard). Since non-standard transactions = violation, it might not be so bad to know who might have altered content along the way. One other thing, I once experienced a situation where clearinghouse trading partners had a payer client switch clearinghouses from one to the other. Clearinghouse A won the contract over Clearinghouse B. Clearinghouse B updated their system and began to route the payer's claims to Clearinghouse A. Clearinghouse A, after testing and processing a production file, never made the final switch to automatically move the claims direct. Instead, their system sent claims to Clearinghouse B who sent them to Clearinghouse A and so the claims looped for almost a year until the auditors asked why there where no billables being sent to the participating payer. Now I've worked with lots of clearinghouses and I know that the best you can do is find the cleanest dirty shirt. While there where lots of errors made to allow this type of problem, these types of issues aren't that unusual. If there had been an element tracking the entire path of this transaction, it might have been caught much earlier. I love a good debate! Marcallee -----Original Message----- From: Rachel Foerster [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 23, 2002 4:43 PM To: [EMAIL PROTECTED] Subject: RE: Whose name is it, anyway? Marcalle, I'm not sure that it's essential that the entire and full path be followed and known to all. One only needs to know from whom it received the interchange. I consider this to be somewhat analogous to what happens on the public internet....some messages, for example, can take as many as 15 or more hops before they arrive at their final destination. The final destination did not need to know of the intermediate hops. And to return a reply, etc., the receiver only needs to know the logical address. I think what may be happening is that today's current processes have evolved over years where each party in the chain knew each other party in the chain and thus the feeling is that this needs to be perpetuated. Using the X12 standards would in my opinion negate the continuation of this business practice. It's for these reasons, plus others, that I've been so adamant that participants on the list work through (debate, argue, disagree, whatever) what today's problems are so that requirements for tomorrow can be developed. I would certainly not like us to perpetuate today's problems tomorrow for no valid business reason! Make sense? I'm glad to see the debate finally being engaged on this list. I made the suggestion on the Business Issues WG confcall yesterday that I would like to see the goal for us at the meeting in Seattle to emerge from that meeting with a clear definition of today's problem(s) plus an initial outline of the table of contents of the white paper which must be the work product of our group. Rachel Foerster Rachel Foerster & Associates, Ltd. Phone: 847-872-8070 -----Original Message----- From: Marcallee Jackson [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 23, 2002 12:49 PM To: [EMAIL PROTECTED] Subject: RE: Whose name is it, anyway? Rachel - How do we follow the chain/path of a transaction? If a transaction passes through three CH's before arriving at the final destination, how do we follow that chain? Does the ISA sender element allow that? If not, is there another element that does? Thanks, Marcallee -----Original Message----- From: Rachel Foerster [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 23, 2002 9:25 AM To: [EMAIL PROTECTED] Subject: RE: Whose name is it, anyway? Chris, Well done! I think you're on the right track in starting to get a good handle on the core problem. As I see it, there are, at a very high level, two: 1. Whose identifier gets inserted into the ISA sender/receiver elements? We know from the IG's which coding systems are valid, including our friend, mutually defined. But, what we haven't yet reached any industry consensus on, in my opinion, is who is the "real" sender and receiver. Personally, I view the provider as the "real" sender of the claim transaction, for example. The provider (the real sender) then has (potentially) several choices of the mechanism of getting the transaction to the "real" receiver -- the guy who's going to pay the claim. Thus, the provider can perhaps choose a direct point-to-point mechanism if the payer offers that choice. Or the provider may choose to use a switch (read VAN), or a clearinghouse. Thus, to continue with Chris' analogy of FedEx, etc., whether a VAN, clearinghouse, or whatever, these entities are just a carrier. Now, that doesn't preclude these carriers from also offering additional value-add services, such as reformatting of the transaction into/out of the standard, etc., just as FexEx and other package carriers also offer other services. But none of these carriers is the originator of the transaction - they just facilitate the package from point A to point B. 2. What data transport method and protocol is to be used? And then, what are the security aspects of this? Thus, additional "packaging" of the EDI interchange is now required. Each transport method and transporter (?) will have its own requirements for identification/authentication, etc. Lastly, keep in mind that the ISA sender and receiver IDs are **always** just logical addresses and are not tied (nor were they ever intended to be) to a physical device or physical location. However, these identifiers, plus the GS sender/receiver codes, are the second level of security (authentication) built into the X12 standards. The first level, in my opinion, is outside of the X12 standards and is at the link level---what alien systems are allowed to log on to yours, how do you validate who's attempting to log on, and do you allow it. This link level authentication is outside of the X12 standards and also outside of the HIPAA rules. Rachel Foerster Rachel Foerster & Associates, Ltd. Phone: 847-872-8070 -----Original Message----- From: Christopher J. Feahr, OD [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 22, 2002 8:16 PM To: [EMAIL PROTECTED] Subject: Re: Whose name is it, anyway? OK,here's one more stab at framing "the core problem": The sender (of any interchange-type message) needs to know WHERE/HOW to send the message... from HERE... i.e., the "physical address of the next hop/destination on the way to Receiver X" and the correct "outer" addressing requirements... i.e."outside" of the ISA sender/receiver info coded inside the message. In the parcel shipping analogy below, this would be the identification of the correct "drop box". While there certainly can be ambiguity about the ID of the ultimate receiver, that would seem to be outside the scope of this WG and is probably well (enough) addressed with the assortment of identifiers offered in the IG. The problem seems analogous to someone having a line of drop-boxes out in front of his office for shipping parcels: one for FedEx, one for UPS, one for Airborne, etc. , and needing to know which one to use in each shipping scenario. Having an authorization from the carrier (the drop-box owner) to use a particular box and knowing the usernames and passwords for these drop-boxes would seem to be be outside of our scope. Once we have all the parameters for defining these entry points, then each receiver would have to publish (somehow) all the possible "drop-boxes" into which a HIPAA transaction intended for it could be placed by a sender... maybe with one flagged as "preferred". If it receives traffic via large "common carrier" type VANs or CHs, then the sender would also need a list of possible entry points or "drop box" definitions for each of the "common carriers" that feed his target receiver. Each standard drop-box definition would have to include the transport mechanism (FTP, secure email, Z-modem, etc.), therefore implying all the other requirements the sender would have to meet to get the thing into the stream. Is this sounding "right" so far?? -Chris At 02:28 PM 1/22/02 -0500, you wrote: >I would like to reiterate - these ID are sometimes (frequently) an integral >part of the security of an EDI system. For instance, that proprietary ID >assigned by the payer to the submitter (provider/billing service or >clearinghouse) may be the ID of an ID/password pair used in securing access >to mailboxes, etc (sorry - no plug intended). > >In our case, we use that ID/password to regulate access, and then correlate >the ID against the providers within the transactions, to validate that the >source of the transaction is authorized as an agent of the provider. A >similar process is used on the response side. > >Bob Christopher J. Feahr, OD http://visiondatastandard.org [EMAIL PROTECTED] Cell/Pager: 707-529-2268
