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

From: "Rishel,Wes" <[email-masked]>
Date: Wed, 22 Nov 2000 02:19:51 -0500

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:[email-masked]]
> Sent: Monday, November 20, 2000 7:42 AM
> To: Rishel,Wes
> Cc: [email-masked]; 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)
> 
> 
> 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: Terry Harding <[email-masked]>
Date: Wed, 22 Nov 2000 16:31:00 -0700

> means works best. If that means that HL7 adopts it, so be it. (I just hope
Many vendors are already supplying that capability.  Several vendors are
AS1 and AS2 compliant and create a transport independant signed, secured
message which is transferred using SMTP or HTTP.
The packaging remains the same for either transport and returned MDNs
also follow the same format, transport independant.

Terry Harding
Cyclone Commerce

---

From: "Dick Brooks" <[email-masked]>
Date: Wed, 22 Nov 2000 18:14:58 -0600

Terry,

regarding the following:
> AS1 and AS2 compliant and create a transport independent signed, secured

I don't mean to nit-pick but I don't believe this is accurate. Didn't the
AS2 testers discover a problem with the To and From headers that are used in
AS1, that resulted in a "packaging change" to use AS2-To and AS2-From within
AS2. IMO, this means that AS1 and AS2 use DIFFERENT packaging, not hugely
different, but different. Would you agree?

Dick Brooks
Group 8760
110 12th Street North
Birmingham, AL 35203
[email-masked]
205-250-8053
Fax: 205-250-8057
http://www.8760.com/

InsideAgent - Empowering e-commerce solutions

> From: Terry Harding [mailto:[email-masked]]
> Sent: Wednesday, November 22, 2000 5:31 PM
> To: Rishel,Wes; 'Gunther Schadow'
> Cc: Dick Brooks; Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; Beth

---

From: Terry Harding <[email-masked]>
Date: Thu, 23 Nov 2000 11:19:43 -0700

> different, but different. Would you agree?
Dick, you are not nit-picking....
Yes, you are correct with the header issue. But lets look at the creation of
a
multipart/signed message.

Step 1:
Place payload inside a MIME body part
Step 2:
Place bodypart inside a S/MIME multipart/signed construct
Step 3:
Add transport dependant headers

So during the creation of a message, I perform steps 1 and 2 the same way
for either AS1 or AS2.  Next i add the top level transport headers for SMTP
or HTTP and send the message.

The headers you referred to are actually top level transport specific
headers.
When i made the statement about the packaging being the same regardless of
transport, i am referring to the actual MIME construct of the message.
Transport
specfic headers will vary from transport to transport. AS2 added
AS2-To and AS2-From to the top level headers, but i still packaged
the payload the same way.

Terry Harding
Cyclone Commerce

---

From: "Dick Brooks" <[email-masked]>
Date: Thu, 23 Nov 2000 21:32:59 -0600

Terry,

Thanks for the excellent explanation - I understand what you meant by
packaging now... However I still think there is
some room for differences between AS1 and AS2 packaging of the SAME
document. Suppose I want to send a JPEG image of a medical X-Ray.

Based on the IANA registration for the image/jpeg media type, ref:
http://www.isi.edu/in-notes/iana/assignments/media-types/image/jpeg

It states:

"Encoding considerations :

Image/jpeg objects consist of binary data.  A content-transfer-encoding of
"Binary" is strongly encouraged for messaging environments which
support binary transport.  A content-transfer-encoding of Base64 (and
the associated transformation) is strongly encouraged for messaging
environments that do not support binary transfer."

Because HTTP (and AS2) contain direct support for binary data the JPEG CAD
drawing can be packaged as pure binary. However, this same JPEG data, when
sent over SMTP (AS1) would most likely be base64 encoded and a
content-transfer-encoding header would be required.

Example of the same JPEG data packaged for AS2 and AS1:

AS2 PACKAGING		 	         AS1 PACKAGING
-------------------------------        ----------------------------------
Content-type: image/jpeg               Content-type: image/jpeg
						   Content-transfer-encoding: base64
[binary jpeg data here]
                                       [base64 encoded jpeg data here]

Dick Brooks
Group 8760
110 12th Street North
Birmingham, AL 35203
[email-masked]
205-250-8053
Fax: 205-250-8057
http://www.8760.com/