Tony, there has been no "debate" on the WEDI SNIP Transactions Workgroup List about ebXML [MSH] vs. EDI-INT AS2. Discussions on transport protocols belong on the WEDI SNIP Routing Subworkgroup List, or perhaps on the WEDI SNIP Security Workgroup List where the ebXML vs. EDIINT "debate" actually took place.
The ebXML MSH and EDI-INT AS2 specifications are not security protocols, per se. They are interoperable standards for the exchange of business documents, which happen to support payloads that can be encrypted and authenticated. "Interoperation" is key: any program implementing either of these standards can "talk" via the Internet to any other vendor's program which supports the same standard. Both partners, the sender and the receiver, can be authenticated using X.509 digital certificates. Both standards provide elaborate acknowledgement processes so either end can be assured that the message was successfully transported and decrypted. I suppose the "debate" centered around the "push" of AS2 vs. the "push-pull" of ebXML MSH. This may be a rather fine point; any entity that can support AS2 is ahead in the game anyway in that they can support real-time EDI over the Internet in a standard, interoperable fashion. The ebXML MSH standard may be "better" - but it's probably only a matter of time when most vendors' AS2 offerings also support ebXML MS. This would make the "debate" moot: if the sender's program detects the trading partner can support the more robust transport protocol, it can automatically select the "better" method for that exchange. Obviously, the advantage of interoperable standards is that they can be easily implemented in an automated, "lights-out" operation. This is difficult - if not impossible - to do with your SSL HTTP/S upload function, for example. Each payer could potentially have a different way of authenticating the sender and doing the upload. An automated "screen-scraper" would have to "learn" each payer's way of doing the submission - akin to the drag Direct Data Entry (DDE) puts on Administrative Simplification. Combining the HIPAA X12 and NCPDP standards with interoperable real-time protocols for transport, packaging and security, like EDI-INT AS2 and ebXML MSH, will go a long ways in ushering in an era of frictionless e-commerce. William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 ----- Original Message ----- From: "Tony Kurzendoerfer" <[EMAIL PROTECTED]> To: "WEDI SNIP Transactions Workgroup List" <[EMAIL PROTECTED]> Sent: Friday, 07 March, 2003 12:50 AM Subject: RE: EDIINT best practices workgroup Can someone explain to me why there is so much debate about eb-xml vs. edi-int when SSL is an existing proven encryption protocol and EDI can be transported in HTTP using standard html form posting technology? To see an example of what I mean go to: http://68.58.126.245/hipaaweb/logonframeset.aspx Login as: EDILive Password: EDILive By clicking the submit button you are actually submitting EDI live from your browser to a translator running on a test server (granted it is not SSL but that is just because I have not set up the certificate on this test server yet.) The translator actually receives the EDI, translates it and responds in real-time to your live 270 requests or 276 requests or 278 requests. Now obviously, this would not be done using a browser but a server can be set up to post EDI transactions this same way from one server to another. In essence allowing provider's software to connect directly to payer's and get the eligibility and claim status information requested. I realize that the implementation guides don't specify protocol for real-time transactions but it seems like overkill to create new security protocols over and above SSL. I also realize that some form of authentication must take place to allow only authorized users access to this information. There have been discussions here lately about using the ISA fields to pass username and passwords. Other payers are creating other forms of authentication, but what are the majority of payers doing to give access to eligibility and claim status in real-time to providers? Tony Kurzendoerfer TKSoftware Inc. -----Original Message----- From: William J. Kammerer [mailto:[EMAIL PROTECTED] Sent: Friday, February 21, 2003 8:48 AM To: WEDI SNIP Routing Subworkgroup List Subject: EDIINT best practices workgroup Take a look at the thread entitled "EDIINT best practices workgroup," started by David Frenkel over on the WEDI SNIP Security Workgroup List; see http://www.mail-archive.com/wedi-security%40lists.wedi.org/ and scroll down for the thread. It's an animated discussion arguing the pros and cons of ebXML Messaging Services and EDI-INT (AS2). Though there's a lot a security techno-talk (SAML, WS-Security, TLS, public key crypto, XML-DSIG, pkcs#7 and s/MIME), this discussion is really more relevant to Routing. Both EDI-INT and ebXML MSH provide robust authentication and encryption - that's a given. The more important issue is which standard those who wish to exchange transactions point-to-point should settle on: the tried and true EDI-INT now used extensively in the retail industry (consider Wal-Mart's mandating AS2 on all suppliers) or the new sexy ebXML MSH which hasn't the penetration of EDI-INT but may be better at handling all types of payloads besides traditional EDI. EDI-INT (AS2) exclusively "pushes" messages to other clients who must be live 24X7. On the other hand, ebXML MSH can "push-pull," allowing the sender to "mailbox" messages for the recipient until he's ready to retrieve them. William J. Kammerer Novannet, LLC. Columbus, US-OH 43221-3859 +1 (614) 487-0320 --- The WEDI SNIP listserv to which you are subscribed is not moderated. The 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/. These listservs should not be used for commercial marketing purposes or discussion of specific vendor products and services. They also are not intended to be used as a forum for personal disagreements or unprofessional communication at any time. You are currently subscribed to wedi-transactions as: [EMAIL PROTECTED] To unsubscribe from this list, go to the Subscribe/Unsubscribe form at http://subscribe.wedi.org or send a blank email to [EMAIL PROTECTED] If you need to unsubscribe but your current email address is not the same as the address subscribed to the list, please use the Subscribe/Unsubscribe form at http://subscribe.wedi.org
