I have followed this from day 1. (on this listserv) I find the facts as they really exist point to an unavoidable conclusion. I strongly suggest that anyone out there that is considering a movement forward in technology just do your own objective research, won't take much...and decide for yourself.
Dale W. Pocklington, MS, MHA, CISSP, CDIA, CCA
"William J. Kammerer" <[EMAIL PROTECTED]> wrote:
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
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, and more --- 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
