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

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

I doubt if XML will ever be a meaningful content type for EDIINT. Saying
that the content is HL7, X12, or NCPDP implies the availability of a
semantic interpretation of the payload. This would be true whether the
payload was in the current HL7, X12, or NCPDP syntaxes or in the particular
applications of XML that they may adopt.

If the only claim is that the payload is XML there is no such linkage to a
semantic standard, even if the XML instance contains a pointer to a schema
in a repository somewhere. A schema is far less than a semantic
representation of the instance; it simplify enables a better and more
thorough parsing of the message.

> -----Original Message-----
> From: Kepa Zubeldia [mailto:[email-masked]]
> Sent: Tuesday, November 21, 2000 2:52 PM
> To: [email-masked]
> 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,
> 
> Probably the requirements are identical, except that the 
> content will be
> in X12 or NCPDP syntax instead of HL7 or XML.
> 
> Kepa
> 
> Dick Brooks wrote:
> > 
> > Kepa,
> > 
> > > Are you volunteering to create an interoperability 
> profile for digital
> > > signatures of the HIPAA standard transactions ?
> > 
> > My offer to assist in the development of an 
> interoperability profile was in
> > response to a need identified within HL7. However, I would 
> be willing to
> > help the HIPAA folks create an interoperability profile, 
> provided it's based
> > on a technology that I'm familiar with (e.g. EDIINT AS2, 
> GISB EDM, ebXML).
> > 
> > I would hope the investment in developing an 
> interoperability profile for
> > HL7 could be leveraged in other areas (e.g. HIPAA, ASTM), 
> without any
> > additional work. Do you see HIPAA's requirements being significantly
> > different enough from HL7 to require a separate 
> interoperability profile?
> > 
> > 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
> > 
> > > -----Original Message-----
> > > From: Kepa Zubeldia [mailto:[email-masked]]
> > > Sent: Monday, November 20, 2000 6:13 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,
> > >
> > > Are you volunteering to create an interoperability 
> profile for digital
> > > signatures of the HIPAA standard transactions ?  X12, 
> NCPDP, and X12+HL7
> > > (in which the signature could be on the HL7 or on the X12 
> components)
> > > are the immediate needs.  However, keep in mind that 
> NCPDP could also be
> > > in EDIFACT syntax (e.g. prescriptions) and HL7 could be 
> in different
> > > syntaxes.  But, for HIPAA purposes, at this time we need 
> something for
> > > the 275 attachment only.  Other HL7 messages could come 
> later through
> > > other interoperability profiles.
> > >
> > > If we have a very narrow scope (HIPAA transactions as 
> they were released
> > > in the Final Rule, plus attachments as we know them) then 
> it is possible
> > > to get an agreement, even if there is not yet an 
> agreement on other
> > > issues or on PKI issues.
> > >
> > > Other volunteers ?
> > >
> > > Kepa
> > >
> > > 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?
> > > >
> > > > FYI - other groups that have adopted AS2 have found it
> > > necessary to define
> > > > "interoperability profiles". These profiles identify 
> the exact set of
> > > > "options" from AS2 that everyone in the "trading 
> community" agrees to
> > > > follow, in order to ensure interoperability. For example, GISB
> > > has already
> > > > defined an AS2 interoperability profile and the New York
> > > Collaborative, in
> > > > accordance with the Public Service Commission regulations, is
> > > in the process
> > > > of defining their interoperability profile. I'm 
> familiar with both these
> > > > groups and the process used to develop their profiles. 
> I could help HL7
> > > > develop an AS2 interoperability profile, if the group decides
> > > to pursue this
> > > > approach.
> > > >
> > > > Regards,
> > > >
> > > > 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
> > > >
> > > > > -----Original Message-----
> > > > > From: Rishel,Wes [mailto:[email-masked]]
> > > > > Sent: Friday, November 17, 2000 8:32 PM
> > > > > To: [email-masked]'; Gunther Schadow
> > > > > Cc: Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; 
> Beth Morrow;
> > > > > David@Drummondgroup. Com; [email-masked]; [email-masked]
> > > > > Subject: HL7 Standards Process (was RE: EDIINT and HIPAA)
> > > > >
> > > > >
> > > > > As the chair-elect of HL7 I would like to respond to DB's
> > > > > question about HL7
> > > > > process.
> > > > >
> > > > > HL7 has two kinds of specifications that are 
> published using slighly
> > > > > different processes: a Standard is submitted to ANSI for
> > > > > certification once
> > > > > it has passed ballot; a Recommendation is published 
> by HL7 but is not
> > > > > submitted to ANSI and does not become an ANSI standard. Some
> > > > > Recommendations
> > > > > have had substantial acceptance among the HL7 community,
> > > including it's
> > > > > "lower level protocols" which define ways to reliably pass
> > > > > discrete messages
> > > > > over RS-232 and TCP, and were published sometime in 
> the early 1990s.
> > > > >
> > > > > A Standard originates under the sponsorship of a Technical
> > > > > Committee. If HL7
> > > > > were to create a Standard for EDIINT it would be the 
> Control/Query
> > > > > committee. It is balloted at the committee level. 
> (Actually anyone can
> > > > > participate in the committee ballot, but in practice those who
> > > > > choose to do
> > > > > so are usually those who participate in, or follow 
> the work of, the
> > > > > Technical Committee.) When it passes a committee 
> level ballot it is
> > > > > submitted for ballot by the full HL7 Working Group (which is
> > > the entire
> > > > > organization). If it passes at this level it is automatically
> > > submitted to
> > > > > ANSI for certification. The ANSI review allows time for public
> > > > > comment, but
> > > > > it is primarily a certification that the process was fair and
> > > consistent
> > > > > with our bylaws. To date, have never had an issue arise that
> > > prevented or
> > > > > delayed the certification process.
> > > > >
> > > > > In addition to Technical Committees HL7 has Special Interest
> > > > > Groups. Gunther
> > > > > is co-chair of our SIG on security. Strictly speaking, a SIG
> > > > > cannot initiate
> > > > > the balloting of a standard; but SIGs can prepare 
> such a document, and
> > > > > obtain the consent of a Technical Committee which 
> sponsors the ballot.
> > > > >
> > > > > The other kind of document, the Recommendation, is easier to
> > > get out the
> > > > > door. It can be originated by a SIG, and it has only 
> one level of
> > > > > balloting.
> > > > > The majority that is required to pass a Recommendation is
> > > less severe than
> > > > > the majority required to pass a Standard (67% vs. 90%).
> > > > >
> > > > > Ballots are conducted using the Web. Assuming that both
> > > ballots pass an
> > > > > energetic committee can easily complete the entire process in
> > > two of our
> > > > > three-per-year Working Group meetings (roughly 8 months
> > > elapsed time). (Of
> > > > > course most committees have substantial time invested 
> in debating the
> > > > > document before it begins the process.)
> > > > >
> > > > > Most of the meetings required at certain points in 
> the process can be
> > > > > handled using conference calls; in theory a REALLY motivated
> > > > > committee could
> > > > > accomplish the two-level ballot in five months and then wait
> > > about three
> > > > > months for ANSI certication. (That is a theoretical figure
> > > that has never
> > > > > been realized in practise.)
> > > > >
> > > > > Recommendations can be passed in roughly four months.
> > > > >
> > > > > Best regards,
> > > > >
> > > > > Wes Rishel
> > > > > Research Director
> > > > > Healthcare Industry Research & Advisory Services
> > > > > GartnerGroup
> > > > > Alameda, CA
> > > > > Client inquiries: call +1-203-316-1288 or email to 
> [email-masked]
> > > > > [email-masked]
> > > > > 510 522 8135
> > > > > 510 521 2423 (fax)
> > > > >
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Dick Brooks [mailto:[email-masked]]
> > > > > > Sent: Thursday, November 02, 2000 10:27 AM
> > > > > > To: Gunther Schadow
> > > > > > Cc: Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; 
> Beth Morrow;
> > > > > > David@Drummondgroup. Com; [email-masked]; 
> [email-masked]; Dick
> > > > > > Brooks
> > > > > > Subject: RE: EDIINT and HIPAA
> > > > > >
> > > > > >
> > > > > >
> > > > > > <DB> I'm not familiar with the HL7 standards process, all of
> > > > > > my experience
> > > > > > has been with IETF, DISA, GISB and recently ebXML. 
> Each of these
> > > > > > organizations has a different process for developing
> > > standards. If we
> > > > > > brought AS2 to HL7 today, how long would it take to 
> become an
> > > > > > ANSI standard?
> > > > > > I would like to read HL7's operational process document, can
> > > > > > you provide a
> > > > > > pointer?
> > > > > > </DB>
> > > > > >
> > >
> > >
>

---

From: "Kit (Christopher) Lueder" <[email-masked]>
Date: Wed, 22 Nov 2000 11:05:38 -0500

No! XML must be accommodated in EDIINT! I was figuring XML content would
be carried as edi-consent, but that seems like a back-door fix rather
than a happy solution.

This sounds like Wes has raised a new requirement that should be
considered in the AS2 spec (and maybe AS1?). I do consider XML to be a
type of EDI, since both are computer-processable electronic
representations of business transactions, so I request we add a type of
edi-xml. And I request we add an attribute/field that indicates the kind
of XML document ("semantic standard") being carried in the payload.
Kit Lueder,
MITRE.

-- 
    _/    _/             Kit C. J. Lueder       
   _/   _/         _/   The MITRE Corp.         Tel:  703-883-5205
  _/_/_/    _/  _/_/_/ 1820 Dolley Madison Bl  Cell: 703-577-2463
 _/   _/   _/    _/   Mailstop W658           FAX:  703-883-3383
_/    _/  _/    _/   McLean, VA 22102        Mail: [email-masked]
Worse than an unanswered question is an unquestioned answer.

---

From: "Dick Brooks" <[email-masked]>
Date: Wed, 22 Nov 2000 11:26:34 -0600

Kit,

The original EDIINT AS1 draft was restricted to supporting RFC1767 payload
types only.

AS2 is payload neutral which means it will transport XML, X12, as well an
any other IANA registered MIME media type. AS2 is explicit in this regard
ref: this excerpt from the AS2 specification:

    "In general, both HTTP servers and HTTP clients handling the message
    templates of [AS1] should be prepared to process these basic EDIINT
    data formats when they are embedded within MIME multiparts.

    In addition to the enveloping and MIME media type options defined in
    sections 4.2.x and 4.3.x of "MIME-based Secure EDI" [AS1], this
    specification enables the transport of payload objects containing
    other MIME media types. Implementors are to follow the
    appropriate specifications identified under "References"
    in [MIME-TYPES], for the type of object being transmitted.
    For example, to send an XML object, the MIME media type
    of application/xml is used in the Content-type MIME header
    and the specifications  for enveloping the object are contained in
    [XMLTYPES]; for example:

        Content-type: application/xml; charset="utf-8" "

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

> From: Kit (Christopher) Lueder [mailto:[email-masked]]
> Sent: Wednesday, November 22, 2000 10:06 AM
> To: Rishel,Wes
> Cc: 'Kepa Zubeldia'; Dick Brooks; Gunther Schadow; Rik Drummond; CLEM;
> Gary Crough; Beth Morrow; David@Drummondgroup. Com; [email-masked];
> [email-masked]
> Subject: AS2 XML requirements (was Re: HL7 Standards Process)
>
>

---

From: Dave Roberts <[email-masked]>
Date: Thu, 23 Nov 2000 17:41:58 +0000 (GMT)

> The original EDIINT AS1 draft was restricted to supporting RFC1767 payload

I'll try to be careful about how I phrase this response: the original
draft of AS1 may have only referred to a payload of EDI, but that's not a
strict requirement, and not the case now.

The later (and current) drafts do not specify that the payload MUST be
EDI, and I believe that since Terry took over authorship, generic EC
payloads are now mentioned, although they may not be highlighted by
example. 

During the rounds of AS1 testing, a Word Document was sent as one of the
tests to prove that non EDI data could be handled by both parties.

- Dave.

PS Can people please trim their posts?

--
Dave Roberts                    Servicing the Online Organisation
Principal Technical Consultant  http://www.saaconsultants.com/
SAA Consultants Ltd             Tel: +44 1752 606000  Fax: +44 1752 606838

---

From: "Dick Brooks" <[email-masked]>
Date: Thu, 23 Nov 2000 20:31:46 -0600

Dave, see responses inline.

> payloads are now mentioned, although they may not be highlighted by

Dave, the AS1 draft (ref:
http://www.ietf.org/internet-drafts/draft-ietf-ediint-as1-11.txt) does state
in section 2.1:

   "This standard is also NOT limited to
   strict EDI use, but applies to any electronic commerce
   application where business data needs to be exchanged over the
   Internet in a secure manner."

However, there is no definitive text describing how non-rfc1767 types are
supported in AS1. The AS1 specification is tightly intertwined with
references to RFC 1767 and all examples are based on RFC 1767 payloads.

As both you and Terry have pointed out, many AS1 vendors have added support
for non-RFC1767 payloads in their products. I'm concerned the lack of
definitive language in AS1 describing support for non-RFC1767 types leaves
it to up to the individual AS1 vendors to decide how non-RFC1767 payloads
are supported in their products and this opens the door to interoperability
issues.

AS2 contains definitive text describing support for ANY MIME media type. I
believe the AS1 authors should consider adding language similar to what is
contained in AS2. I also believe it would be beneficial to include some
non-RFC1767 payloads in their interoperability testing.

Rik, does the AS2 interoperability test currently underway include a test
case using a non-rfc1767 payload? If not I would suggest adding a test case
exchanging XML payloads.

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

---

From: Terry Harding <[email-masked]>
Date: Mon, 27 Nov 2000 09:38:55 -0700

> payloads are now mentioned, although they may not be highlighted by
Currently AS1 is under review by the IETF Area Directors.

I will be forwarding the requested changes to the list for feedback.

After we receive approval from the Area Directors the specification
will be passed onto the IETF RFC Editors for their review and
feedback..

....Lets move EDIINT(AS1) into RFC status....

Terry Harding
Cyclone Commerce

---

From: Terry Harding <[email-masked]>
Date: Mon, 27 Nov 2000 09:40:43 -0700

> references to RFC 1767 and all examples are based on RFC 1767 payloads.
Now is the time to add this definitive text to AS1.

Terry Harding
Cyclone Commerce

---

From: "Dick Brooks" <[email-masked]>
Date: Mon, 27 Nov 2000 12:33:13 -0600

> Now is the time to add this definitive text to AS1.

I totally agree. For consistency I suggest using similar text as what
appears in section 2 on page 6 of AS2.

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

---

From: "Dick Brooks" <[email-masked]>
Date: Mon, 27 Nov 2000 13:01:54 -0600

> I will be placing similar text inside of AS1.
> 
> Terry Harding
> Cyclone Commerce

Thanks Terry.

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

---

From: Terry Harding <[email-masked]>
Date: Mon, 27 Nov 2000 11:58:54 -0700

Dick,

Terry Harding
Cyclone Commerce

---

From: Dave Roberts <[email-masked]>
Date: Tue, 28 Nov 2000 12:18:04 +0000 (GMT)

> references to RFC 1767 and all examples are based on RFC 1767 payloads.

Right.

Terry, is it possible to change the text within the Security
Considerations paragraph and the Introduction?  I don't know if that's ok
at this late stage.  Changing most of the EDI references to "EC or EDI"
should set the tone for the remainder of the document.

> are supported in their products and this opens the door to interoperability

I see your point.  There is no clear guidance on what MIME type is to be
used for non-EDI data.  Whilst some may use the IANA MIME type, others may
not.

> contained in AS2.

Right, so an EDI payload uses the MIME types laid down in RFC 1767.
Non-EDI payloads should use the MIME types as laid down by the IANA.

Perhaps also a statement on the MIME types that MUST be supported (i.e. 
those specified by RFC1767), and a statement that any other MIME type is
up to the vendor to handle.  Or would that be too liberal?

- Dave.

--
Dave Roberts                     Servicing the Online Organisation
Principal Technical Consultant   http://www.saaconsultants.com/
SAA Consultants Ltd              Tel: +44 1752 606000 
Plymouth, UK.                    Fax: +44 1752 606838

---

From: "Kit (Christopher) Lueder" <[email-masked]>
Date: Tue, 28 Nov 2000 09:38:08 -0500

I don't get it. Why should we change AS1 by saying that "all examples
are based on RFC 1767 payloads"? Are we trying to squash extensibility?
Kit.

Chris Davenport wrote:
> I'm quite happy to see the EDI-consent sub-type disappear.  As Gunther
> was at pains to point out a couple of years ago, it raises important
> interoperability issues.  

Ouch. That would make edi-int gradually become useless and irrelevant, I
think, as XML and other internet technologies evolve. The problem that
needs to be solved is that there is no good extensibility mechanism in
edi-int.
Kit.

---

From: "Dick Brooks" <[email-masked]>
Date: Tue, 28 Nov 2000 10:18:57 -0600

Kit,

Nobody is suggesting that AS1 be changed to say that all examples be based
on RFC1767. The problem is that all AS1 examples ARE based on RFC 1767. I,
and others (yourself included, I presume), are advocating the expansion of
AS1 to explicitly include support for other MIME types.

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

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Kit (Christopher)
> Lueder
> Sent: Tuesday, November 28, 2000 8:38 AM
> To: dick
> Cc: [email-masked]
> Subject: Re: AS2 XML requirements (was Re: HL7 Standards Process)
>
>

---

From: "Kit (Christopher) Lueder" <[email-masked]>
Date: Tue, 28 Nov 2000 11:50:36 -0500

Sorry, I guess I read that as the opposite of the authors' intention.
Yes, I advocate expanding the types. I think something like an
"XML-consent" MIME type (or "edi-XMLconsent" if you prefer) would
provide a general mechanism of carrying XML content that the recipient
knows needs to be handed to the XML parser. I consider XML to be a type
of EDI in the general sense (not the X12/Edifact sense), since it is
structured data, computer processable. 

Yes, I know that HL7 can be encoded in XML, but if you are happy using
the edi-hl7 tag for HL7 XML, that is fine too. It seems like a burden on
you to figure out which encoding you are using for HL7, but if you
aren't worried about it, I'm not either. Personally, I would have a tag
of "edi-hl7XML"...
Kit.