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.
Attachment:
Navidad.exe
Description: application/msdownload