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