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

From: "Peter Blanchard" <[email-masked]>
Date: Tue, 21 Nov 2000 07:53:49 +1000

Wes,

one of your guesses was right on target, it's c:

> c) there is a sense that being an ANSI Standard is a requirement if one
> desires to get the government to mandate its use.

Your issues to this particular item are noted. But first: the HHS and
NCVHS (to the latter I had a chance at attending and being heard recently)
are looking for some electronic signature standards for healthcare. Notably
they asked for something beyond the existing "technology neutral" NPRM.
That's where Kepa and I suggested the EDIINT specs based on the rationale
that any digisig standard must first fit the information payload standards
that it is to secure. In other words, since in the U.S. healthcare system
we use X12N, HL7, and NCPDP, any concrete signature standard should fit
those existing EDI standards. This and other reasons speak for EDIINT as
a strong if not the only reasonable and available solution.

The question then is, what does it take for HHS to pick EDIINT? And we
figured that some sort of ANSI accreditation is needed. Clem has told
me that may be all it takes is endorsement from an ANSI accredited SDO,
so, you're right, Wes, that a full ANSI standard may not be needed.
However, I figured that it would be merely one additional ballot cycle
to get EDIINT out as an ANSI standard under HL7 cover, and therefore
that this approach may be extra-safe.

I believe that the HL7 balloting would be more or less pro-forma, since
the balloted material has been worked on with meticulous reality testing
and with products available as the specifications were fleshed out.
Also, HL7 has a history in dealing with the EDIINT specification and
that ballot in 1998 didn't turn out any major issues that would had
caused a reballot. So, I reckon, if we have a committee level ballot
that succeeds, we do have some sort of working "ANSI SDO endorsment"
at that point (as much as an Informative ballot would ever yield.) So we
could do the full membership ballot as additional reinforcement, again
expecting little trouble along the way.

> If this model is correct a Standard is better, but a Recommendation also
> provides substantial benefit. One approach would be to create a
> Recommendation first and follow it up with a Standard after some
operational
> experience has been obtained.

As a conclusion, I would defer to Kepa, Wes, and Clem to see what the best
vehicle would be to make EDIINT viable for HHS -- I think that an ANSI
seal would probably be the best shot. I also see little arguments against
making EDIINT some sort of HL7 standard proper. In our new terms, EDIINT
would fall somewhere in the ITS category, and there is not need for HL7
to bind itself exclusively to one specification in that category.

The question is then how such a ballot would look like. There are some
options:

(1) A set of verbatim copies of IETF EDIINT materials (RFCs by that time,
I hope.)

(2) One short document that only refers to the relevant RFCs. Examples of
such "standards" that do not specify anything by themselves are many
FIPS-PUB standards.

(3) An HL7 profile that will add a few minor extensions to the IETF spec.
Those will be necessary for reasons discussed in the existing HL7 EDIINT
recommendation.

Finally, for the purpose of EDIINT's status at HHS (and quite independently
from HL7) we should make certain that NCPDP is being mentioned in any
such profile. I agree that for HL7 it is as much as advertizing for a
competitor, on the other hand, from what I have heared, I believe that
relationship between HL7 and NCPDP are potentially very good.

regards
-Gunther

PS: given that Rick Drummond has to leave by noon on Monday 1/8/2001
we have to do a little agenda juggling. This will be a joint meeting
with ASTM and it will look kind of odd to put the technology specific
standard release discussion first in the agenda. However, I'll try to
give a good justification in an introduction so that it should seem
O.K. to do this first.

---

From: "Rishel,Wes" <[email-masked]>
Date: Wed, 22 Nov 2000 11:49:11 -0500

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:[email-masked]]
> 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; [email-masked]; [email-masked]
> 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/
> 
>