Ronald: I don't think EDI would necessarily have looked any different if it had been devised in the "TCP/IP world." Look at MIME: it's not any prettier. If XML had been available from the outset, maybe EDI would have used XML for its syntax. But you have to admit there's nothing inherent in the syntax of ANSI ASC X12 or UN/EDIFACT that keeps EDI from being a first-class Internet passenger. Peter Barry has suggested that payers with elaborate, web-based DDE services could allow providers to upload standard X12 interchanges right into a field in the DDE system, presumably wrapping EDI in MIME for an HTTP POST or something like that. And high tech messaging services like ebXML MS don't care whether they're carrying payloads of X12 or XML.
The HIPAA standard transactions based on X12 and NCPDP already exist (and maybe new interactive ones based on the UN/EDIFACT syntax will be added into the mix later), and we can't do anything about it even if we wanted to. We should concentrate on devising recommendations for means of routing these packages safely, securely and reliably. If the next incarnation of HIPAA standard messages were based on XML schemas or core components, we'd still be left with the same problems we have today: how to get the claim to the payer, or the remittance to the provider. If we had a Healthcare CPP and Registry, they would work "out-of-the-box" for XML just as well as for EDI - trust me. EDI's market acceptance has nothing to do with the "protocols" it's built on: the syntax (ASC X12.5 and X12.6, ISO 9735 or XML) is the simple part - the semantics are difficult. FTP, SMTP, MIME and other Internet protocols have far fewer variables to deal with, and hence are simpler to interoperate. But I'll grant you one thing: if the (Healthcare) world were standardized on a single transport layer (TCP/IP), it would make things far less painful. For example, we wouldn't have much work left to do to customize the CPP DeliveryChannel, as it's already designed around TCP/IP protocols like HTTP and SMTP. And I certainly agree that "there should be no need to duplicate the sender identification effort with another login process much like BBS's and FTP require." You should only have to logon once to your own ISP, VAN or CH, and not duplicate that process for every payer you might conceivably access; that's the whole point of eliminating payer-centric mailboxes. As an aside, Open Source isn't the answer to all that ails us. Most of us don't still live at home with Mom, and therefore we have to charge for our labor. Open Source is often a model which works well for hardware manufacturers (i.e., using Open Source infrastructure software to encourage development for their platform), but I've never seen it applied to e-commerce applications. William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 ----- Original Message ----- From: "Ronald Bowron" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, 21 June, 2002 01:39 PM Subject: Re: Route through email and attach EDI files As a long time fan of efficient transfer of business data (i.e. EDI vs. XML), I've often wondered why the Open Source community has never taken EDI under it's wing like they have other services (FTP, SMTP, Telnet). I guess the market wasn't there. Anyway, to keep in line with our efforts, I've always wondered what EDI would be like if it were developed in the TCP/IP world vs. the legacy BBS (async protocols) VAN (SNA/Bysnc protocols) world. I've also believed that part of the reason other application or file transfer protocols (FTP, SMTP, XML) seem to gain wider acceptance more rapidly than EDI is simply that they've standardized on a single transport layer (TCP/IP). So I ponder on this as I look out over the issues raised in this forum. Can a standard interface be developed that would work much like SMTP but without all the overhead of another addressing schema? Imagine if an EDI client application were built in the open source community (much like SendMail), that when given the EDI filename, would access the ISA Header and GS segment, use that information to locate (Either via ACL, LDAP, DSML, ebXML/CPP) in an "ID Repository" the proper destination and communication method and protocol (of course today, the TCP/IP protocol would be nice). The EDI Server (much like an SMTP Server) would acknowledge the EDI Client request, (assuming TCP/IP) establish a VPN or SSL channel (for encryption purposes) and validate digital certificates, and then receive the ISA header. Verify the Sender/Receiver information, and request the GS segment. From there, the GS segment would be used by the EDI Server to set the Functional processing of the transactions (Realtime/Fast-Batch/Batch) and send the I/O stream on its way to the appropriate application service queues or simply stored as a file. So basically, all the necessary information to login the user, determine what they are needing to do is in the ISA and GS segments as EDI was intended. There should be no need to duplicate the sender identification effort with another login process much like BBS's and FTP require. The EDI Server could also be responsible for sending back the TA1 and possible the 997 acknowledgments (assuming the EDI Server can perform structural integrity checks). The EDI Server could have folder management capabilities much like a SMTP server for Sent/Received and possible transaction specific folders. The EDI Server could also support Self-Registration - allowing business partners to decide if they will use a hosted EDI Server (possibly for a fee) for sending and receiving their files via a service provider, much like SMTP services such as MyRealbox or Hotmail accounts, or if they setup their own internal server. It would seem to me that such EDI Client and Server applications could easily be developed in the open source community based on the SendMail and SMTP Server open source code fairly quickly. Then it would be up to this body to help develop the standards for what the "ID repository" would contain and how it would be communicated to EDI Clients and Servers. We could also help establish standards for routing the ISA Header from one EDI Server to another securely based on the existing SMTP model. The problem with the current situation is that much of the healthcare EDI infrastructure is still dependant on 10 year old technology (dial-up/asynchronous protocols). They are looking for the least intrusive method complying with HIPAA, while still supporting their existing infrastructure (i.e. don't rip and replace). I believe, without a significant advancement in the applications that manage the "Communication Protocol Layer", EDI will continue to struggle with asynchronous protocols(X,Y,Z-Modem, Kermit) and dial-up support of TCP/IP protocols (FTP) and wrapper solutions such as SMTP. If the EDI Client were standardized, freeware, I'm sure the servers would bring in sufficient revenue to support the open source efforts. Practice Management systems could simply include the EDI Client in their products and then connect to an existing EDI Server either via dial-up or dedicated TCP/IP, and hopefully soon via IPv6. I don't believe the repository would be widely accepted if we didn't have a real compelling reason to use it. So, anyone on this list know any good open source developers? -RB discussions on this listserv therefore represent the views of the individual participants, and do not necessarily represent the views of the WEDI Board of Directors nor WEDI SNIP. If you wish to receive an official opinion, post your question to the WEDI SNIP Issues Database at http://snip.wedi.org/tracking/. Posting of advertisements or other commercial use of this listserv is specifically prohibited.
