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

["Rishel,Wes" <wes.rishel@xxxxxxxxxxx>]

Dick,

Thanks. This was very helpful. My remaining concern is that if we in
healthcare attempt to apply EDIINT as a way of using digital signatures to
accomplish electronic signatures we will end up with EDIINT mired in
discussions and revisions that would prevent its being published for its
primary business purpose.

It is possible that I am misunderstanding other messages and this is not a
concern. It is, however, a hypothetically scenario that could happen, and it
would be unfortunate to continue to keep EDIINT from the world if it did.

Wes



> -----Original Message-----
> From: Dick Brooks [mailto:dick@xxxxxxxx]
> Sent: Wednesday, November 22, 2000 7:02 AM
> To: Rishel,Wes; 'Kepa Zubeldia'; Gunther Schadow
> Cc: Rik Drummond; CLEM; Gary Crough; Beth Morrow; David@Drummondgroup.
> Com; GISB1@xxxxxxx; ietf-ediint@xxxxxxx
> Subject: RE: HL7 Standards Process (was RE: EDIINT and HIPAA)
> 
> 
> 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/
> 
>