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

From: "Rishel,Wes" <[email-masked]>
Date: Mon, 20 Nov 2000 01:07:11 -0500

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
>

---

From: "Dick Brooks" <[email-masked]>
Date: Mon, 20 Nov 2000 08:33:01 -0600

Wes,

You make some excellent points, I want to focus on a few that I believe are
critical in moving forward.

>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.

>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.

>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)

> make it for 1/8/2001. Thank you for your help.

Subject: AD review of EDIINT documents (was RE: Status and Future of EDIINT)
From: <[email-masked]>
To: "Rik Drummond" <[email-masked]>
Cc: <[email-masked]>
Date: Fri, 3 Nov 2000 01:20:13 -0600

> well it is not dead. the spec is in the loop for rfc approval... and we
now
> have 12 vendors supporting as1 and 9 supporting as2. these are all
> interoperable. if we don't get something back from the ietf shortly it
might
> be wise to go the ansi route... rik

Well, as it happens I've been working on the AD review of these documents. I
just completed that review today. I've attached my review comments below.

Sorry it took so long.

				Ned

------

AD review of draft-ietf-ediint-req-08.txt:

I started to write a bunch of comments on this document, but then decided
against it. The basic problem is that due to the substantial amount of time
that has passed since this text was written (through no fault of the authors
or
the WG, I hasten to add), quite a bit of it seems dated. For example, a
discussion of the use of VPNs in contrast to VANs would seem appropriate.
Some
of the symmetric cipher discussion is likely dated as well. But given that
it
is informational I see little harm in publishing it as-is. Note that it may
end
up with an IESG note pointing out the timing issue, however.

AD review of draft-ietf-ediint-as1-11.txt:

This is where the issues are. Some are very minor, but a couple must
be addressed.

Security considerations section. The word "Technologies" is
capitalized when it should not be.

The security considerations section is normally at the end of the
document. It also should cover actual considerations rather than
restating what the document is about.

1.0 Introduction, first paragraph. The impression is given here
that this is purely an Applicability Statement. However, the
very next paragraph then indicates otherwise. I suggest that
this be clarified by referring to "the bulk of this document
is an Applicability Statement", or something similar.

1.0 Introduction, second paragraph. There's a reference to section
3.1.8, which does not exist in the current document. I believe this
is supposed to be 5.3.1.

1.0 Introduction, third paragraph. "Used" -> "used".

2.1. Reference to "standard" is premature. I suggest saying
"document" instead.

2.2.2, first paragraph. "The functional requirements document, [9]
"Requirements for Inter-operable Internet EDI" (can be found at
www.ietf.org)," needs to be rewritten as a reference to an RFC-to-be.

2.2.2, first paragraph, "Provides" -> "provides".

2.2.2, second paragraph. Use of the term "transport" here is
confusing. I suggest "environment" or something similar
instead.

2.2.2, last paragraph. "Satisfy" -> "satisfy".

2.2.3, first bullet item. This section doesn't identify RFC 2298 as
the mechanism being used to request EDI receipts. Suggest making it
clear here rather than having to get further into the document to find
out.

2.3.2, fourth bullet item. Now that PGP itself is an IETF standard,
should reference RFC 2440 as well as RFC 2015 here and elsewhere in
the document.

2.3.2, fourth bullet item. REQUIRES is not a keyword on the 2119 list;
suggest rewording to use REQUIRED instead.

5.4.1, first paragraph. The phrase

   Using message, "partial",

should be

   Using message/partial

5.4.1, second paragraph. The phrase "so that if fragmentation does occur,"
isn't right in this context. I suggest "so that if fragmentation is needed"
instead.

5.4.1. Recommending that partial be used but saying that support for it
is optional could lead to interoperability issues. I suggest that you
add that in the absence of knowledge that the recipient supports partial
it SHOULD NOT be used.

5.4.1, last paragraph. This is the biggie. Saying it is OK to use
content-encoding in email even as an option just isn't acceptable. The
problem is one of interoperability: An unextended agent that receives
a message with, say, a content-encoding of gzip won't recognize the
field for what it is and will cheerfully decode the base64 expecting to
find text or whatever. Instead it will find garbage.

Unfortunately, the only way to add compression to email in a backwards
compatible way is to define new content-transfer-encodings. If this is a
real issue this is the mechanism that needs to be pursued.

Note that it is fine to recommend use of content-encoding if the
transport is HTTP. Content-encoding is well-defined there and agents
are required to check for it and handle it.

Finally, this document defines new disposition-notification-options
and a new MDN field received-content-mic. Both of these things
require IANA registration. It is customary in standards track documents
to do this with an appendix containing the appropriate registration
forms. This needs to be done per sections 10.2 and 10.3 of RFC 2298.

That's it!

---

From: Gunther Schadow <[email-masked]>
Date: Mon, 20 Nov 2000 10:41:39 -0500

Wes, 

> 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.
 
> 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: Kepa Zubeldia <[email-masked]>
Date: Mon, 20 Nov 2000 18:14:38 -0700

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:
>   ------------------------------------------------------------------------
> 
>    Part 1.2    Type: Microsoft MHTML Document 5.0 (message/rfc822)
>            Encoding: 7bit

---

From: "Dick Brooks" <[email-masked]>
Date: Tue, 21 Nov 2000 18:02:55 -0600

Kepa,

>Does this shed some light ?

Thank you, your framing of the issues regarding digital signatures and HIPAA
helped me a great deal.

>signature standard ?  Then, I think you know what to do.

The ideal solution is an ANSI approved digital signature standard. In lieu
of such an ANSI standard would HHS "seriously" consider a standard that has
been adopted by another government department (e.g Department of Energy) IF
it met HIPAA's requirements? How about a standard created by a non-ANSI SDO
(e.g. IETF, GISB)?

If HHS wouldn't seriously consider anything that is non-ANSI standard then
the path ahead is quite clear; an ANSI standard is needed, ASAP.

> "trust" issues, then the wheels could slow down.

I agree, there are still many issues plaguing PKI, both technical and
business related. Given the scale, visibility and criticality of HIPAA
deployments I think it would be best to leverage a "trust" approach that is
easy to implement, widely deployed and has proven to be scalable and
interoperable (for example PGP).

> that are also necessary but not "mandated" by HIPAA at this time.

I think this should be specified as a core requirement.

Very helpful..

Thanks,

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: Kepa Zubeldia [mailto:[email-masked]]
> Sent: Monday, November 20, 2000 7:15 PM
> To: Dick Brooks
> Cc: Rishel,Wes; 'Gunther Schadow'; Rik Drummond; CLEM; Gary Crough; Beth