William, Thanks for your ongoing concern for us "little people (providers)", but the more I think about divorcing the payor/plan ID info in the transactions from the receiverID info in the ISA, the more I like it... because it embraces the models in use today in which there really is no relationship between these two addresses. If the industry is willing to adopt the distributed address directory model that Kepa is proposing, then the "little people" can either hound their office system vendors to include that capability... or the smart vendors will see the business opportunity and sell the address discovery process to the provider as a value-add... or the small provider can just shovel all of his claims to one clearinghouse and let the CH worry about routing them. Since the need to know where to send these interchanges is going to be so acute for the provider, I can't imagine a situation in which no one was willing to create a system that would do the address discovery for them.
-Chris At 09:16 PM 2/8/02 -0500, William J. Kammerer wrote: >Ronald Bowron wrote "...based on the definition of the routing >objectives, the ability to communicate based on the ST/SE transaction >type was defined as out of scope, and that routing should be limited to >the ISA/IEA and possibly the GS/GE." > >Using the transaction set as one component to determine the destination >of an interchange was never defined out of scope. But *requiring* >anything other than what's available in the ISA to determine routing >would place a burden on providers new to the standard transactions - or >their agents (VANs). Altruistically, my concern is motivated solely by >the needs and capabilities of the "little" people (providers). > >Generally, anyone producing standard transactions is aware not only of >the ISA sender or receiver fields, but also stuff in the GS and the ST - >theoretically they could make decisions for routing, selecting the >appropriate node in Kepa's DNS scheme. But it might be asking too much >of their off-the-shelf practice management software to traverse Kepa's >DNS tree (or even to use a CPP type of arrangement). Instead, they (the >providers) should be able to dump all their interchanges into one >conduit and be assured their "stuff" will get there safely, securely and >reliably based solely on receiver ID. > >If that conduit were a VAN, wouldn't it be too much to expect the VAN to >burrow within each and every interchange, group and transaction set to >determine routing? It's not impossible, certainly. But, again, why >should the sender (or her agent) have to concern herself with each of >the variables present in the ISA, GS and ST (and possibly more, if you >consider real-time requests which are evident only by looking within the >transaction set) and figure it out on her own where to send the >interchange? Isn't the ISA receiver ID enough? She has already >specified the recipient's NAIC, Plan ID, or whatever, in the ISA. Once >it gets to the payer, I think it should be incumbent on him to figure >out how to internally route the interchange (or functional groups >within). > >This situation isn't directly analogous to Kepa's example of different >addresses for snail mail - Kaysville for inquiries and payments to >Montclair - as Kaysville and Monclair are probably separated by really >big mountains or deserts in the real world (I'm not that good at >geography, but I know things like that got in the way of the >California-bound settlers). But in the virtual Internet world, they >are separated by a few micro-seconds. The receiver knows best where to >route his incoming stuff.... so let him do it. Delegating the >"mailroom" function to the sender (usually the provider) is an >impediment to frictionless e-commerce and an extra cost providers can do >without. > >William J. Kammerer >Novannet, LLC. >+1 (614) 487-0320 > >----- Original Message ----- >From: "Ronald Bowron" <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]> >Cc: <[EMAIL PROTECTED]> >Sent: Friday, 08 February, 2002 07:24 PM >Subject: Re: Using a hybrid DNS > > >Kepa, > >Thanks Kepa. I believe I understood this but have a much better >understanding now, and look forward to the day it is standardized. > >I can see how easy it would be for the NAIC (Payer ID + SubID) to >represent the Plan Codes. When they finally do develop Unique Plan >ID's, I would hope they keep this simple structure in mind and add the >support for alpha numeric(base 36, 0-Z - although this could cause >problems if bar coding were required) or at least a checksum digit . > >In using a NAIC method, I would suggest the DNS lookup format of >PlanID.PayerID.naic.hipaa.net. Payers could accept all Interchanges to >PayerID.naic.hipaa.net or specify which plans codes they accept allowing >the system to be more easily managed. This also fits the hierarchical >model better. > >The biggest assumption this model seems to make is an ISA/IEA will only >contain transactions destined for a single Transaction Receiver >(PayerID). Below I put a future concept forward that may address this. > >I also believe that setting up standards for how this interface will >work is a good idea. But based on the definition of the routing >objectives, the ability to communicate based on the ST/SE transaction >type was defined as out of scope, and that routing should be limited to >the ISA/IEA and possibly the GS/GE. You may recall that I was against >such a tight scope, for the very reason your logic points out. So, >knowing the Payer/PlanID may not be within scope. > >In an attempt to see the future as well, I looked to a Client Server or >Web Services (IP World) model where the Client, Server and Applications >leverage the EDI format. (This may be how it is already done in other >industries or some EDI Commerce shops). > >A Client Application uses a DNS service to locate the appropriate >Server based on ISA contents. Once the Client is routed to the Server >and the ISA is authorized (currently in scope), the Server can then >request the GS/GE and identify the application resources necessary to >handle the functional group and open a channel to the application >queuing service (AQS). The AQS would request the ST and determine >transaction type and priority (out of scope) and begins requesting the >remaining loops. Once the AQS receives the SE, it informs the Server >that the Transaction is complete and ask for another ST. If the Server >gets the GE, it tells the application it's done. So routing could be >handled all the way down to the transaction level and the Transaction >Sets queued up for processing (either real time or batch) by these >processes. Each process could also publish their current processing >state and other reporting/monitoring statistics. > >I also see the future possibility of the VAN/CH providing the ISA and >GS support services to locate the appropriate resource to process the >transactions (ST/SE) via the optional extensions to your DNS model. >That way the Transaction Receiver may not need to know the Interchange >Sender, only the Transaction Sender. The Transaction Receiver having >established a Trading Agreement with the VAN/CH, has given the VAN the >authority to verify Interchange Sender. Then it is only the Transaction >Receivers responsibility to let the VAN/CH know the transaction has been >received. It would then be the VAN/CH's responsibility to build the >997, and optionally the 824 depending on the information received back >from the Transaction Receiver. So if an ISA Sender wishes to send >multiple PayerID's within a ST/SE, they should have a VAN/CH that can >separate them appropriately and route them to their appropriate >destinations. > >Exposing or pushing the transaction type and priority out to your DNS >model could significantly over complicate the issue of routing, so I >agree with keeping it optional. And, with our scope focused on the >routing of interchanges, determining transaction type and processing >priority could be left to the receiving entity to address as part of >their business processes based on the information provided within the >GS/GE or ST/SE loops as described above. > >If we attempt to put too much logic into the interchange routing >process, we may kill it's adoption simply due to complexity and >restrictions that adopters may not wish to support. > >I do believe defining some basic standards on how the three application >layers (Client/Server/App) would communicate could significantly improve >the adoption of a standard routing methodology, that is why I suggested >we consider addressing routing from the File, Batch, Transaction >perspective early on and set recommendations for how these physical >components should be handled in the Logical structure of EDI >(Interchange, Functional Group, Transaction Set) and then establish >routing standards at each logical level. > >Do you see this interchange routing method supporting multiple >Transaction Set Receivers (PayerID's) within the same GS/GE? How do we >address this if not via the VAN/CH example, or by expanding the routing >scope? > >It's my understanding that the X12N standards support this today, and >that the receiver must receive them, even if to report back that the >transaction contains an invalid PayerID. > >Regards, >-RB Christopher J. Feahr, OD http://visiondatastandard.org [EMAIL PROTECTED] Cell/Pager: 707-529-2268
