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

From: "Rishel,Wes" <[email-masked]>
Date: Wed, 22 Nov 2000 01:29:43 -0500

I guess I missed more than I realized. I have always held that there are two
distinct applications of digital signature technology:

(1) to authenticate a block of data that might represent an EDI message, a
binary executable program, a digital certificate or any of a myriad of other
objects that come from the world of technology, and 

(2) as a way of accomplishing electronic signature, the binding of the
identity of a person to an electronic document in a way that approximates
the forensic robustness of a handwritten signature on a paper document.

Now (2) is clearly accomplished by using the processes described in (1), but
there are myriad functional issues around the representation of the document
or parts of the document; clearly demarking the scope of what is
electronically signed; being able to demonstrate that what the person saw
when he signed was the only valid interpretation of the block of data that
represents the signed text; being able to demonstrate that the human
readable interpretation of the binary data that represents the document has
not changed in the years since it was signed; and a signature model that
includes distinct concepts such as multiple signatures that apply to
different, possibly overlapping parts of documents, countersignatures and
signed amendments.

I have always thought of EDIINT as a clear example of (1). I have never read
anything about it that addresses any of the issues listed in (2). 

Did I miss a meeting?

> -----Original Message-----
> From: Kepa Zubeldia [mailto:[email-masked]]
> Sent: Monday, November 20, 2000 5:15 PM
> To: Dick Brooks
> Cc: Rishel,Wes; 'Gunther Schadow'; Rik Drummond; CLEM; Gary 
> Crough; Beth
> Morrow; David@Drummondgroup. Com; [email-masked]; [email-masked]
> Subject: Re: HL7 Standards Process (was RE: EDIINT and HIPAA)
> 
> 
> Dick, Wes,
> 
> Now I need to throw in my $.02
> 
> Under HIPAA, the Secretary of HHS is required to adopt a standard for
> electronic signatures of the HIPAA transactions.  Simple and reduced
> scope.
> 
> The Secretary is required to adopt Standards (with capital S) 
> developed
> by a SDO from the American National Standards Institute.  If no such
> standard is available, the Secretary can create her own standards.
> 
> The HIPAA Security Final Rule will reflect security standards 
> created by
> HHS because there are no other security standards for healthcare
> developed by an ANSI SDO that meet the security requirements expressed
> in the HIPAA Law.  However, the security final rule will NOT have a
> standard for electronic signatures, and this standard will 
> come out in a
> later final rule.
> 
> If the healthcare SDOs were to agree on an ANSI standard for digital
> signatures that could be used for the HIPAA transactions, and a very
> specific "implementation guide" on how to use this standard 
> to sign the
> HIPAA transactions, the Secretary would have a much easier job in
> adopting such standard.  Until this happens, the digital 
> signature final
> rule may have to be put on hold, as the DHHS does not want to create
> standards in this area in an ivory tower (i.e. in a vacuum).
> 
> In addition, the HIPAA electronic signature standard must be 
> adopted in
> conjunction with the Department of Commerce.
> 
> Does this shed some light ?
> 
> Do you want EDIINT to be adopted by the Secretary as the HIPAA digital
> signature standard ?  Then, I think you know what to do.
> 
> Please understand that I am not making any promises here.  I 
> am stating
> something that will make easier for the NCVHS to recommend a standard
> for the Secretary to adopt.  This is a self-serving request 
> as I am one
> of the NCVHS members.  The NCVHS looked at the possible standards last
> month, and as a result, I have sent invitations to the 
> affected SDOs to
> work under HISB in coming up with something "adoptable".  I think that
> if the group of experts on this list was to work on such task with the
> ANSI SDOs, then we could have something that benefits the entire
> healthcare industry.
> 
> However, if we let the scope creep to cover other topics, 
> such as PKI or
> "trust" issues, then the wheels could slow down.
> 
> I hope that having a "HIPAA Signature Implementation Guide" does not
> preclude other "implementation guides" for things like encryption,
> consent form signature, multiple signatures, counter signatures, etc.
> that are also necessary but not "mandated" by HIPAA at this time.
> 
> Keep up the good work.
> 
> Kepa
> 
> Dick Brooks wrote:
> > 
> > Wes,
> > 
> > You make some excellent points, I want to focus on a few 
> that I believe are
> > critical in moving forward.
> > 
> > >a) there is interest in having a healthcare group give its 
> imprimatur to
> > >AS2, since it "rounds out" the Internet protocols to make 
> a complete
> > package
> > >for HIPAA-compliant, B2B messaging based on ubiquitous 
> Internet protocols
> > >such as HTTP, FTP and SNMP.
> > 
> > Many people (not specifically in healthcare) are confused 
> by the number of
> > "B2B standards" that exist, for example:
> > - Vendor initiated (BizTalk and SOAP)
> > - Consortia initiated (ebXML by OASIS and UN/CEFACT, XML 
> Protocols Activity
> > by the World Wide Web Consortium )
> > - Internet related standards bodies initiated (IETF - 
> EDIINT ASx, IETF -
> > BEEP)
> > - Industry specific standards bodies initiated (HL7, GISB, 
> UIG, AIAG, etc.)
> > 
> > Not to mention all the proprietary initiatives.
> > 
> > They look at all these "standards" and they're afraid 
> they'll choose the
> > "wrong standard". I believe industry organizations, like HL7, play a
> > critical role in helping people choose a B2B standard 
> that's appropriate for
> > their needs.
> > 
> > >b) there is some despair at seeing AS2 get out of IETF 
> before quantum
> > >computers pretty much obsolete everything based on computers with
> > >deterministic states (this last was an attempt at humor)
> > 
> > Actually this is an excellent point. The IETF is very 
> particular when it
> > comes to designing/endorsing standards, as it should be. 
> Some of the recent
> > concerns with AS1 (see Ned Freed's comments attached) raise the
> > probabilities of a longer delay for AS2, because the 
> non-GISB portion of AS2
> > depends on AS1. I'm not aware of any issues with the GISB 
> portion of AS2.
> > 
> > >c) there is a sense that being an ANSI Standard is a 
> requirement if one
> > >desires to get the government to mandate its use.
> > 
> > The Department of Energy, via the Federal Energy Regulatory 
> Commission,
> > mandated use of the GISB standard and I don't believe it is an ANSI
> > standard. Perhaps Rae McQuade, Executive Director of GISB 
> ([email-masked]),
> > can comment on this.
> > 
> > I certainly don't understand many of the idiosyncrasies of 
> HL7 Standards
> > versus Recommendations so I'll listen and learn as this  
> discussion evolves.
> > I have been an active participant in many of the 
> initiatives mentioned above
> > including:  ebXML, GISB, UIG, W3C XP, and of course IETF 
> EDIINT. I look
> > forward to working with the HL7 organization on this very 
> important decision
> > during the coming months.
> > 
> > Regards,
> > 
> > Dick Brooks
> > http://www.8760.com/
> > 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of Rishel,Wes
> > Sent: Monday, November 20, 2000 12:07 AM
> > To: 'Gunther Schadow'; Dick Brooks
> > Cc: Rishel,Wes; Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; Beth
> > Morrow; David@Drummondgroup. Com; [email-masked]; [email-masked]
> > Subject: RE: HL7 Standards Process (was RE: EDIINT and HIPAA)
> > 
> > For many reasons it would be more desirable to be a 
> Standard, but I am not
> > sure that there aren't some shades of gray, particularly if 
> the difference
> > in the required time is important. I will wait to hear from 
> Gunther about
> > the HIPAA issue, but I am suspecting that the following is true:
> > 
> > a) there is interest in having a healthcare group give its 
> imprimatur to
> > AS2, since it "rounds out" the Internet protocols to make a 
> complete package
> > for HIPAA-compliant, B2B messaging based on ubiquitous 
> Internet protocols
> > such as HTTP, FTP and SNMP.
> > 
> > b) there is some despair at seeing AS2 get out of IETF 
> before quantum
> > computers pretty much obsolete everything based on computers with
> > deterministic states (this last was an attempt at humor)
> > 
> > c) there is a sense that being an ANSI Standard is a 
> requirement if one
> > desires to get the government to mandate its use.
> > 
> > I would take issue with item (c). It is surely helpful to 
> be a standard, but
> > it is also helpful to be any sort of publication of an 
> ANSI-accredited
> > standards development organization. Furthermore, unless 
> someone knows
> > something specific, I would be skeptical that the current 
> administration
> > would introduce another delay in the final rule on security 
> by attempting to
> > add AS2 at this late date.
> > 
> > Rather than a government mandate, I suspect that the 
> benefit of an HL7
> > imprimatur, and perhaps a profile or two, would be to 
> assist in promoting
> > the Internet and AS2 as means to exchange the HIPAA 
> transactions without
> > reliance on value added networks. At the same time it would 
> be very valuable
> > to HL7 to have ways to exchange standard (old syntax) HL7 
> messages and
> > HL7-XML messages over the Internet using the same infrastructure
> > (integration brokers and servers) as are being sold for other B2B
> > applications in healthcare, the power industry, etc.
> > 
> > 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.
> > 
> > > -----Original Message-----
> > > From: Gunther Schadow [mailto:[email-masked]]
> > > Sent: Saturday, November 18, 2000 8:06 PM
> > > To: [email-masked]
> > > Cc: Rishel,Wes; Rik Drummond; Kepa Zubeldia; CLEM; Gary 
> Crough; Beth
> > > Morrow; David@Drummondgroup. Com; [email-masked]; 
> [email-masked]
> > > Subject: Re: HL7 Standards Process (was RE: EDIINT and HIPAA)
> > >
> > >
> > > Dick Brooks wrote:
> > > >
> > > > Thanks Wes.
> > > >
> > > > Based on your description I would anticipate the EDIINT AS2
> > > spec taking the
> > > > "Recommendation" route, IF the group decides to go forward.
> > > Do you see it
> > > > the same way?
> > >
> > > Dick, I actually do see it the other way. The EDIINT work in
> > > HL7 as we
> > > discussed it in relation to HIPAA is only useful if we end up
> > > with an ANSI
> > > approved standard. That must be a standard, not a recommendation.
> > >
> > > I'll fill in Wes on the HIPAA issue under separate cover. 
> Glad you can
> > > make it for 1/8/2001. Thank you for your help.
> > >
> > > regards,
> > > -Gunther
> > >
> > 
> >   
> --------------------------------------------------------------
> ----------
> > 
> >    Part 1.2    Type: Microsoft MHTML Document 5.0 (message/rfc822)
> >            Encoding: 7bit
> 
>

---

From: "Dick Brooks" <[email-masked]>
Date: Wed, 22 Nov 2000 08:13:42 -0600

Wes,

There is a very fine article from Bruce Schneier in this months Crypto-gram
( ref: http://www.counterpane.com/crypto-gram-0011.html ), regarding the
"semantics" of digital signatures, that echoes some of your comments.

PGP and S/MIME can be used to construct and apply a digital signature to a
document for the purpose described in both 1 and 2. However, in order for
the digital signature to have any legal standing a legally binding
"contract" is needed that clearly defines a parties "intent" when applying a
digital signature to a document. Typically, a trading partner agreement is
used to define digital signature semantics and specifies a party's "intent".
A digital signature alone will address #1, a digital signature WITH a
trading partner agreement addresses both #1 and #2.

Caveat 1, Digital signatures, regardless of whether one uses PGP or S/MIME
are still imperfect. Secret keys can be stolen and  fraud can be committed
using a stolen "identity". How does one know when their secret key has been
stolen? When a fraudulent act has been committed. Unfortunate but true.

Caveat 2, I'm a software engineer - not a lawyer, so the information I've
provided is based on "opinions" from others I've spoken with in the Energy
industry who have dealt with these "digital signature semantics" issues.
It's always wise to seek "legal advice" before engaging in electronic
transactions involving digital signatures.

-----Original Message-----
From: Rishel,Wes [mailto:[email-masked]]
Sent: Wednesday, November 22, 2000 12:30 AM
To: 'Kepa Zubeldia'; Dick Brooks
Cc: Rishel,Wes; 'Gunther Schadow'; Rik Drummond; CLEM; Gary Crough; Beth

Did I miss a meeting?