RE: HL7 Standards Process (was RE: EDIINT and HIPAA)

["Dick Brooks" <dick@xxxxxxxx>]

Wes, see responses inline.

>Previously I had thought that AS2 supported all of HTTP, HTTP/S, SMTP and
>FTP, and that it was necessarily to develop a set of profiles for there to
>be meaningful communications among trading partners.

AS2 only supports HTTP and HTTPS (using TLS). AS1 only supports SMTP.

In our previous phone discussions I described the capabilities of our
GISBAgent product,
which supports HTTP, HTTPS, FTP and SMTP. This may have caused some
confusion, sorry.

>Furthermore, I had assumed that if messages were to go asynchronously
>between point A and point B and back, that each of point A and point B
could
>offer HTTP servers or FTP servers. In particular, if A is the payer and B
is
>the provider, then B could initiate a claim by posting to A's HTTP server.
>Later on, A could post a response to B's HTTP server. B would have the
>option of handling the event immediately or building a queue of inbound
>transactions to process when it wanted.

>Was I wrong before?

No, this is exactly the model used throughout the Energy industry. Two
parties
"push" data to each others HTTP server. Both parties MUST have an HTTP
server
listening for "incoming" transfers. But what about........

>Now, given that a significant number of payer organizations are small
>practices they may not wish to spend the $40/month that it takes to have a
>permanent presence on the Internet. Such practices might prefer to poll the
>payer for responses. (To be honest I didn't realize that EDIINT supported
>that mode. I thought it was basically a way to send a message and
optionally
>get an immediate response giving the gross status of the initial
>transmission.)

The Energy industry also has a similar situation with smaller participants
that
cannot afford/justify a full time HTTP server and Internet connection.
There are clearinghouses that offer services for these smaller players, they
are
very similar to traditional VAN's in this regard. A small party "dials-up"
their
clearinghouse to send/receive data.

>I would agree with Kepa that it would be preferable to use SMTP to HTTP for
>these small payers, but using e-mail is a somewhat dicey proposition. In
the
>ideal world, where someone establishes an isolated SMTP server just to deal
>with transactions, and gives that server direct access through the
firewall,
>then it should be fairly robust. But large enterprises tend to have
>enterprise mail systems that include very complex interrelationships
between
>servers that have many more functions than simple mail transfer and are
>difficult to maintain. Although mail delivery of AS2 transactions would
>probably work most of the time, it would be significantly less robust than
>HTTP or FTP implementations, where there is only one server involved on
each
>side and its administration can be dedicated to the purpose of handling
>transactions.

The organizations I've spoken with aren't willing to trust their E-commerce
data to an e-mail server. In addition to the well known reliability issues
of e-mail
there are also some significant security issues, for example:

-lack of access control (anyone can send an e-mail message to an e-mail
server - spammers)
 People don't want their E-commerce server spinning it's wheels on spam mail
or worse.
-many viruses travel via e-mail and E-Commerce servers are designed to
automatically process
 a received message; it could be disastrous if an E-commerce server
automatically processed a virus.

Certainly, there are ways to deal with each of these issues, but a lot of
"off-the-shelf" mail software
doesn't address these security issues.

>So, what is happening? How much do I have to relearn since my last coffee
>break (:-)

EDIINT AS2 defines a protocol for securely and reliably exchanging data via
HTTP and HTTPS.
EDIINT AS1 defines a protocol for securely and reliably exchanging data via
SMTP.

There are products available (from several vendors) that support the
secure/reliable transport of
any type of payload (X12, XML, binary, etc.) via HTTP, HTTPS, FTP and SMTP
transport.

Did this help?

Dick Brooks
http://www.8760.com/