Is the purpose to resolve routing of Transactions or to know which interchange data was routed? I believe most of the community would like to see the Transaction routing/auditing solved and to be able to verify where the transaction went or where it is. Therefore, the ISA isn't the only vehical to solve ths problem. ISA is simply the equivalent of allowing a user to login to your environment, I don't understand how given the current looping capabilities (multiple transactions from different submitters and too multiple receivers) of the 837, standardizing ISA information would solve anything, unless the only means of transmission was point-to-point - provider to payer (No CH's, Third Part Admins/Repricers, etc.).
If routing involves determining that all submitters data was properly routed to the receiver, then routing involves just about any segment that contains a Segment Control Numbers (possibly down to the detail) and ID's representing the TP's (Submitter/Reciever). One purpose of the Control Number I believe was to help manage routing and auditing - should we accomplish getting all the TP's to conform to the the idea of properly managing unique control numbers. The anologie we often used was the routing of a 837 is like shooting a large bullet down a barral that splits it into shotgun pellets. Then, what we wanted to know was if each pellet hit their target. Now imagine 300 people on the same firing range. Unless the target watcher knows what bullet the pellet came from, we'll never know who hit what and route tracking is lost. What makes this worse is when a target takes the pellet and either uses it as a bullet (i.e breaks it into more smaller transactions) or combines it with similar pellets from other guns (combines common claims for sending to a payer). In the end, we had to work with CH's and Payers to accept our Transaction Control Number and use it to forward down the line, or if they generate new numbers, we ask that they provide the cross-ref value so we could track it. This is much like a FedX routing number, but the logistics is more like a distribution channel and warehousing. The elements we identified for our internal tracking were as follows: File Name (because in our modle a file may contain multiple ISA's) ISA Control Number GS Control Number Transaction Control Number Transaction Date Submitter ID Receiver ID (transaction level) I believe we combined Our Sender ID + Submitter ID + Reciver ID + Transaction Date + Transaction Control Number to create a Global Unique Routing Number (GURN) within our data structures and claim status reporting system. Our hope was to have any receiver of the data, echo back our our GURN, letting us know their File, ISA, GS and Transaction Control Numbers. Typically the receiver would very rarely if ever change the Transaction level Submitter/Receiver (NAIC code) data. Then we (and those in between) could build a table from those responses and determine how far the transaction got, and whether it's made it's final destination. We would keep such information on file for as long as the customer or Trading Partner Agreement required. This met with some difficulties, mostly due to the inability to maintian referencial integrity between secondary TP's and the reluctance of TP's to build this capability into thier responses (i.e. Unsolicited 277, or I here theres an 824 and other possible EDI sets like the 242 that could now handle this). Also, if COT's can be transative, why can't TPA's? How do payers handle TPA's with out-of-Network Providers today that wish to submit electronically? Ronald Bowron
