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
