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

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

I won't repeat my previous note about the difference between EDIINT using
digital signatures to authenticate messages and somehow using it to
implement electronic signatures; but this note clearly implies that the itch
we are trying to scratch is electronic signatures. 

Whatever happens to electronic signatures I would be delighted if AS2
somehow got launched for the simple purpose of providing authentic,
encrypted B2B messages built on top of ubiquitous Internet protocols. I
would like to offer my enthusiastic support to enabling that by whatever
means works best. If that means that HL7 adopts it, so be it. (I just hope
we don't adapt it.)

I am very much planning to be at the meeting 1/8. Since Rik has got a plane
to catch, is there any way to do some work on Sunday? I am not sure I would
be able to make it, but we ought to be able to make some progress at least
informally that will help to streamline things on Monday. (Given the
somewhat ill-defined other requirements of a Chair Elect I don't know if I
can stay in the meeting all day or not. But I will be there as much as I
can.)



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