Thanks again for the insight, Ed... and I think we are gathering that information in a survey about how CHs and others are handling this now. There seems to be no disagreement that we need a "directory" or "registry" of addressing/routing info, but I believe the prevailing "real world" belief is that it will not be centralized... at least, for a few years. I think we envision some sort of distributed model, but it's not clear (to me, anyway) how we would keep all the distributed piles of this information RELIABLY synchronized and up-to-date. That's what made me think about standardizing routing table structures and the table query/update EDI transactions, including some reliability index (possibly, just the # of days since the last refresh of the data).
Even if other fields in that table (or a separate table) held the proprietary "family jewels" client information, VANs and CHs could agree to continuously maintain the "public" address/routing info cooperatively and offer free access to it (one address per query) for all healthcare EDI players, including providers, who may only need to maintain a local table of the 20 or 30 entities THEY need to connect to. For the added fee, the VAN could actively *manage* the whole message-stream for the provider. But as a free, public service, it could choose to open up the "public" parts of its address table... if that's all the provider thought he needed. The provider's system could be programmed with "primary" "secondary", and maybe "tertiary" address-service-provider addresses. Then each time the provider wanted to update his own address tables, he could query his favorite 3 VANs and accept the answers with the most recent refresh-dates into his own routing table... unless his table already had one with an even more recent refresh-date. How does this idea sound to the VANs and CHs who are listening? (kinda like all the gas stations near interstate highways volunteering to be America's free rest room... anticipating that the increased candy and soda sales will more than offset the added bathroom maintenance costs!) Thanks, Chris At 10:25 AM 4/8/02 -0400, Ed Hafner wrote: >Chris, > >I am glad it helped some. We need to get some confirmation out there from >clearinghouses how their world works in relation to the old EDI VAN >world. Did some research this morning and found just one exception to my >previous e-mail related to the old TDCC grocery community where the BG04 >(similar to the ISA08) was used as a place holder for the dial-out >telephone number for the next stop. This was carried over to the >grocery/retail ISA usage where the ISA08 had the telephone number of the >next stop and the ISA04 had the real receiver ID. As a VAN, you had to >check both IDs for routing if you did not recognize the ISA08 ID. I doubt >very much this is carried over to the health care world since it was used >as a technique to relieve administrative burdens of the VAN to set up all >non-customers in the early days. I knew that I should not have used >"always" in my previous e-mail:) > >Not sure if you can replace the clearinghouse profiles since it most >likely contains data that indicate the types of value add services that >the clearinghouse will perform such as IDs to be used with maps, default >elements for translations, carbon copy info, special reporting, error >notification rules, etc. A lot of those functions are proprietary and >could expose the world (using the public directory) to their proprietary >competitive advantage. Would think though that a directory in the sky >containing things like IDs, routing information, access control, security >info, and types of accepted/transmittable documents could do very well. I >truly believe that such a offering would be very beneficial to the health >care community. > >Just a little insight on how the internal profile directories that I have >seen are organized. It includes general information about the end user >such as IDs used, address info, and passwords. For each application under >the profile (document type) it will include communication routing, >communication techniques, translations/editing options, special >clearinghouse functions. For each partner (under the application) it >contains overrides to the application record plus access control information. > >Again, we really need to take a poll of the clearinghouses to determine if >this is applicable in their world. Another interesting phenomena is the >clearinghouse jumps. In the old VAN world, it is not unusual to see an >interchange jump through two hops and recently a trend for three >hops. One to the sender's VAN then to the receivers VAN. The new trend >is one to the sender's VAN, then to the an intermediate VAN (because the >receiver VAN won't interconnect with the sender's VAN), and then to the >receiver VAN. I have heard from many people that this complexity is not >as strong in health care community since providers typically go to >clearinghouses that are directly subscribed to by the payer. If their are >jumps in health care, then that makes the public directory a bit more >challenging. > >Hope this is not too far from reality. > >Ed > >-----Original Message----- >From: Christopher J. Feahr, OD [mailto:[EMAIL PROTECTED]] >Sent: Sunday, April 07, 2002 6:24 PM >To: Ed Hafner; William J. Kammerer; WEDi/SNIP ID & Routing >Subject: RE: Who am I? Sender, Receiver, Intermediary, or just plain >Chump? > > >Wow! Thanks. This helps a lot. It would be reassuring to know that >the ISA receiver is ALWAYS going to be the unique identifier for the "end >receiver" and that people have typically avoided the creation of single >interchanges filled with transactions destined for different payors. If >that is not a "standard" practice, then perhaps we should recommend that it >become one. Unless I misunderstood, there has even been talk on this list >of businesses wanting to send individual 837s that had service lines >targeted for multiple/different payors. (Did I hallucinate that, or did >someone say that was actually being done?? Seems like it was Bob Poisze >who mentioned that he had seen that). > > If we could nail down a few conventions like "only one ultimate addressee >per interchange" and "only one addressee per transaction", then what our >group is essentially considering is a universal standard for that internal >routing table that you described being maintained by the VAN. With a >standard routing table structure, we could create (or likely there already >is one) a transaction for use by use by VANs and CHs for selectively or >globally updating one VAN/CH's routing table from another. Isn't this how >DSN enteries propagate? (I remember the "family jewels" aspect of this, >but this might be such a cool system... massive pooling of these "family >jewel" addresses... that it would save the original jewel-owners MORE money >than if they had kept the information secret. I'm not sure of that, but it >might be worth doing the math to find out. It sure as heck will be a big >help to the businesses stepping into EDI for the first time... who >presently don't know how to find anybody!) > >Ed, can you share an example of the innards of one of those tables? Does >it look anything like the MX record we were talking about a few weeks ago? > >Thanks, >-Chris > >At 08:54 AM 4/7/02 -0400, Ed Hafner wrote: > >Hello all, > > > >In my past life I spent many years in the EDI Value Added Network world > >(VAN) where our company provided a number of "clearinghouse" services for > >large health care organizations and many other industries. Consistent > >across the board was how organizations communicated its envelope > >information. The ISA receiver ID always reflected the end > >address. Inside the VAN existed a directory that would provide a look-up > >to describe the next communication stop. This next stop was often the > >intended receivers communication end point but could also be another third > >party service via an "interconnect". If it went to an interconnected > >service, the same logic was used there as the next stop would query its > >database to see what should be done with the data. I am getting older now > >and my memory is getting a little fuzzier, but I cannot remember any > >exceptions from at that time 26,000 customers and more than double the > >interconnect entities. > > > >It is true that a communication can contain multiple interchanges with > >each going to a separate end-point but the interchange reflects one > >sender-receiver pair. The VAN would handle each interchange separately. > > > >Just for kicks, I will throw in some communication routing logic. There > >was some very special logic inside the VAN that would make determinations > >for the type of communication services that were required depending on > >application group in the GS segment and the sender/receiver pair. For > >example one partner pair with a particular application group would require > >immediate connectivity via a dedicated connection while another > >application group was safe stored in a mailbox for latter > >retrieval. There was even logic to simulate a human interaction session > >sending and receiving responses to the user interface (systems like Abbot > >Labs and Baxter). I could go on and on about other services such as > >translations and conversions but again, it was all driven by that > >end-point receiver ID. I can also reference other VAN logic from multiple > >acquisitions or near acquisitions. > > > >It would be a great idea if the clearinghouses that are out there > >contribute their experiences. Hope this helps things and does not cloud > >any issues. > > > >Ed > > > >Edward A. Hafner > >Chief Technology Officer > >Foresight Corporation > >+1.614.526.4328 > > > > > > > >-----Original Message----- > >From: Christopher J. Feahr, OD [mailto:[EMAIL PROTECTED]] > >Sent: Sat 4/6/2002 9:14 PM > >To: William J. Kammerer; WEDi/SNIP ID & Routing > >Cc: > >Subject: Re: Who am I? Sender, Receiver, Intermediary, or just plain Chump? > > > > > > > > Willian (and Rachel).. > > I remember this thread well and I actually did start a list of > > terms that I > > intended to propose definitions for, including concepts like > > "ultimate > > receiver". (I'll resurrect that as soon as I slay a couple > > optical dragons > > that are breathing in my face). But the thing that would seem to > > kill the > > idea of the ISA receiver being the "ultimate" receiver (rather > > than the > > "next stop") is the fact that so many CHs are apparently receiving > > interchanges filled with transactions for all kinds of different > > "ultimate" > > receivers... not just from other CHs, but possibly even from a > > provider who > > is using the CH only for routing/addressing services. > > > > Michael Mattias also seemed to be making a point a couple weeks > > ago about > > the ISA being intended ONLY for routing to the next > > destination... which > > does make sense to me, and I don't recall any protest when he said > > that. Plus.. if someone got an interchange with some other > > party's address > > in the ISA receiver field, how would they know that the > > interchange was > > intended for them and not sent there by mistake? > > > > As I've suggested a few times before, it would seem necessary in > > virtually > > every case for the ISA receiver-entity to look down in the > > transactions for > > the identities of those "ultimate" receivers. People have often > > referred > > to this as "opening" or "going into" the transaction, but it > > doesn't seem > > that invasive to me, really... or substantially different from > > "goiny into" > > the ISA. It's a big long line of text and if the ISA receiver > > entity can > > tell which segments constitute the ISA, he ought to be able to > > tell just as > > easily which segments represent the "ultimate addressee" fields > > down in the > > transactions. Why is this "going down into the transactions" > > stuff taboo > > if he can go into the ISA segment? All he'd be doing is > reading the > > address headers to see where the transactions were supposed to go. > > > > How do CHs know how to repackage and reroute these transactions > > today if > > they don't look into the transactions? Couldn't a "functional > > group" still > > be a bunch of 837s destined for different payors? > > > > (Sorry if these are dumb questions...I've never operated or even > > seen the > > software that receives and reads these things) > > > > Thanks, > > -Chris > > > > At 07:49 PM 4/5/02 -0500, William J. Kammerer wrote: > > >Unless an interchange is going through a pass-thru > intermediary - a > > >switch or a VAN - which delivers EDI for many entities, it > probably > > >really doesn't matter what's in the receiver field of the ISA, > > does it? > > >If I deliver an interchange to Anthem, directly, doesn't it > stand to > > >reason that the interchange is somehow for none other than Anthem? > > >Maybe Anthem will use the GS envelope for further routing, but > > would it > > >even pay attention to the ISA receiver field? > > > > > >But if the interchange is passed through an intermediary, such > > as a VAN > > >or CH, clearly the immediate destination (the VAN or CH) will > not be > > >identified as the receiver on the ISA. The ISA receiver field > > probably > > >should be that of the next entity to open the transaction > set: this > > >might be the payer (for a claim), but could just as well be a > > Re-pricer > > >or Third Party Administrator - who I assume are not classified as > > >"payers." Actually, the "real" payer (the insurance company > > behind a > > >self-funded Employer plan) may never see standard transactions > for a > > >plan - is it correct in this case, then, to call the payer a > > "receiver"? > > > > > >William J. Kammerer > > >Novannet, LLC. > > >+1 (614) 487-0320 > > > > > >----- Original Message ----- > > >From: "Rachel Foerster" <[EMAIL PROTECTED]> > > >To: "'Christopher J. Feahr, OD'" <[EMAIL PROTECTED]>; "'Dave > > Minch'" > > ><[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > > >Sent: Friday, 05 April, 2002 06:43 PM > > >Subject: RE: Are only 15 characters in the ISA receiver ID enough? > > > > > > > > >Chris, > > > > > >This issue of defining who the "real" sender and receiver are was > > >brought up early in this list's history. At that time I strongly > > >recommended that a project glossary be developed so that, at > > least for > > >discussion purposes here, we would have clear definitions of > terms. > > >Alas.... > > > > > >On the other hand, at that time I also did a rather thorough > > search of > > >all of the HIPAA IGs and throughout all of them there is the > > consistent > > >intent and use of the sender being either the provider or payer > > and the > > >receiver being either the payer or provider. Nowhere in any of > > the HIPAA > > > > > >guides is there a explicit or implicit statement that the sender > > is just > > >the next hop for the interchange. In other words, the provider > > and payer > > >are the real trading partners for purposes of the HIPAA > > transactions, > > >and intermediaries, whether clearinghouses or something else, > > are just > > >that - an intermediary between the true end-point business > partners. > > > > > >Perhaps it's useful to think about the U.S. Postal Service as a > > >metaphor. The address on the envelope is always the end-point > > receiver, > > >and not the next Post Office facility that the envelope may pass > > >through. This is the model that the X12 interchange envelopes > > follow as > > >well. > > > > > >Rachel > > >Rachel Foerster > > >Principal > > >Rachel Foerster & Associates, Ltd. > > >Professionals in EDI & Electronic Commerce > > >39432 North Avenue > > >Beach Park, IL 60099 > > >Phone: 847-872-8070 > > >Fax: 847-872-6860 > > >http:/www.rfa-edi.com > > > > Christopher J. Feahr, OD > > http://visiondatastandard.org > > [EMAIL PROTECTED] > > Cell/Pager: 707-529-2268 > > > > > >Christopher J. Feahr, OD >http://visiondatastandard.org >[EMAIL PROTECTED] >Cell/Pager: 707-529-2268 Christopher J. Feahr, OD http://visiondatastandard.org [EMAIL PROTECTED] Cell/Pager: 707-529-2268
