[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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 (gisb1@xxxxxxx),
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: owner-ietf-ediint@xxxxxxxxxxxx
[mailto:owner-ietf-ediint@xxxxxxxxxxxx]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; GISB1@xxxxxxx; ietf-ediint@xxxxxxx
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:gunther@xxxxxxxxxxxxxxxxxxxxxx]
> Sent: Saturday, November 18, 2000 8:06 PM
> To: dick@xxxxxxxx
> Cc: Rishel,Wes; 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)
>
>
> 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
>
--- Begin Message --- 
> 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!

--- End Message ---