Kepa, Thanks for the popcorn. :) Did you remember to get some milkduds?
I'm thankful to see that we're trying to ensure we don't repeat the efforts of the past, but are we missing a simple issue here. Much of the original EDI standards were developed not knowing what type of transport layer would be used. Today, TCP/IP has given us technologies that actually are more sophisticated than what was available when EDI was originally being developed. For example, when you compare the purpose of segments such as ISA and GS, I see Login (user IDs/passwords) and set application profile, with ST, I see Select the message type (mail,appt, task). So, if we are trying to discuss routing in the IP context, the problem isn't with the ISA it's with the layer before the ISA (Transport) that we need to solve the problem in the IP world. We should be talking about developing open standard TCP/IP EDI Sender and Receiver tools (much like an FTP client/server interface). And then define best practices for using these client/server services. The EDI Sending Client would be passed the EDI file and read the ISA and GS to obtain the necessary information to leverage the exiting DNS model for finding the host the file will be sent, whether it's a clearinghouse to parse through and separate the transactions by payer, or to send a ISA/IEA straight through to the receiver. The Server Side would then listen for clients looking to send EDI transactions. We can use all the existing TCP/IP services to protect infrastructure for unwanted access requests. The client/server could even resolve the issue of compression and encryption. Each player in the IP world for EDI would use the EDI Client/Server open source code standards to support the transport method over IP. And then we're not trying to re-invent anything, just leverage what we already have with some specific EDI capabilities. Then we simply ask that all payers to put there payer host IP + Plan codes on their Plan Cards, and we ask HIAA create a publically available list for looking up payer plans both members and non-members - don't know why they wouldn't. The Server side code should not assume the data will simply be written to a file (although the open source could do this) - let the receiver of the data have the liberty of putting additional intelligence in the Server to parse or separate data as their business requirements need. The standards should only dictate from login sequence (of course I'd prefer to see LDAP) and the begin receive methods would look like based on new and existing RFC's. The server could even be responsible for sending back the 997 as part of the requirements (TA1 could be optional server services). 95% or more the code is in the FTP RFC's, so, all we need to do if define the standards for how the ISA and GS can be used by the Client/Servers to managing the transport of the Transaction (or message). We should not be concerned with the actual transaction that's application specific. If you want to solve this for some other transport layer, the resolution may be slightly different, but IP looks like the best solution to offer given the move to that as the most favored transport. In short, EDI over IP needs a Service that leverages the transport layer and let other TCP/IP services do the job they do best, including routing. I don't claim to be a TCP/IP expert, but I have dabbled a bit and just thought this would be a better way of addressing the issue. Comments? Ronald Bowron
