Subject: RE: AS2 XML requirements (was Re: HL7 Standards Process)

From: "Rishel,Wes" <[email-masked]>
Date: Wed, 22 Nov 2000 16:12:32 -0500

Sorry, I am not that familiar with the spec. I was misusing the word
content, I guess. 

The original note to which I responded talked about "HL7, NCPDP, X12, and
XML" as if they were equivalent concepts. My point was merely that XML all
by itself does not define the semantics of an interface contract, whereas
the other three do. 

One thing about which I would still quibble. You say:

> If you re-encode HL7 into XML syntax, you 
> shouldn't send it
> as type of EDI-HL7, since it is not pure HL7 syntax. You 
> should send it
> as EDI-XML (if we add that to AS2), and have the "semantic standard"
> field/attribute set to "HL7".

I am not talking about "re-encoding" HL7 in XML. 

Effective 14 Nov 2000, when ANSI certified our CDA standard, XML is actually
one of the three official syntaxes of HL7. We expect many more transactions
to roll out in XML over the next year. Many of the HL7 messages in XML
syntax, including those just certified, will have no equivalent
representation in the older HL7 Syntax, although we expect there to be a lot
of messages in the old syntax for a long time.

> -----Original Message-----
> From: Kit (Christopher) Lueder [mailto:[email-masked]]
> Sent: Wednesday, November 22, 2000 9:39 AM
> To: Rishel,Wes
> Cc: [email-masked]
> Subject: Re: AS2 XML requirements (was Re: HL7 Standards Process)
> 
> 
> I disagree. If you re-encode HL7 into XML syntax, you 
> shouldn't send it
> as type of EDI-HL7, since it is not pure HL7 syntax. You 
> should send it
> as EDI-XML (if we add that to AS2), and have the "semantic standard"
> field/attribute set to "HL7".
> Kit.
> 
> "Rishel,Wes" wrote:
> > 
> > I was not saying that AS2 should not carry XML ... quite 
> the contrary. Over
> > the years I believe the percentage of AS2 payloads that are 
> encoded using
> > XML will rapidly grow to predominate over any other syntax.
> > 
> > I was saying that XML should not be a content type, in the 
> sense that HL7,
> > X12, and NCPDP are content types.
> > 
> > HL7 already has an ANSI-approved specification for data 
> encoded in XML. X12
> > and NCPDP are working on it. Would you suddenly lump the 
> content of all
> > three organizations into a general bucket called "XML"? It 
> just doesn't make
> > sense.
> > 
> > Furthermore, if all you know about a message is that it is 
> encoded in the
> > XML syntax you really don't know enough to do an EDI function on the
> > message. The EDI standards specify a lot more than syntax and these
> > specifications are very much a part of the interface 
> contract. With the
> > improvements in XML Schema Language 1.0 (and presuming that 
> Schema Language
> > manages to predominate over XDR and RELAX) one can tightly 
> nail down the
> > syntax of an XML instance, but one cannot directly specify 
> anything about
> > workflow, the semantics of the tags (which are NOT 
> self-evident when you get
> > to the details), or obligations that are created by sending 
> or accepting
> > messages.
> > 
> > Put it another way, HL7, X12, NCPDP standards (and those of 
> many other
> > organizations) define EDI content, maybe using XML maybe 
> using another
> > syntax. The W3C XML standard is no more than a building 
> block in defining
> > EDI content, just as the standards for TCP, HTTP, MIME etc. 
> are building
> > blocks.
> > 
> > > -----Original Message-----
> > > From: Kit (Christopher) Lueder [mailto:[email-masked]]
> > > Sent: Wednesday, November 22, 2000 8:06 AM
> > > To: Rishel,Wes
> > > Cc: 'Kepa Zubeldia'; [email-masked]; 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)
> > >
> > >
> > > 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.
> > >
> > > "Rishel,Wes" wrote:
> > > >
> > > > 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>
> > > > > > > > > >
> > > > > > >
> > > > > > >
> > > > >
> > >
> > > --
> > >     _/    _/             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.
> > >
> 
> -- 
>     _/    _/             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: "Rishel,Wes" <[email-masked]>
Date: Fri, 24 Nov 2000 02:51:51 -0500

response follow

> From: Gunther Schadow [mailto:[email-masked]]
> Sent: Thursday, November 23, 2000 9:19 PM
> To: Rishel,Wes
> Cc: [email-masked]'; 'Kit (Christopher) Lueder'; 'Kepa Zubeldia'; Rik
> Drummond; CLEM; Gary Crough; Beth Morrow; David@Drummondgroup. Com;
> [email-masked]; [email-masked]
> All these worries are worth thinking about to some extent, but then
> there is the sheer pragmatic fact that the world won't stop spinning
> and e-signatures are here to stay in some form. In fact, the ESIGN
> act -- according to my reading -- is quite loose in what it requires
> of a signature. I see no demand for screenshots or XSL in it. I 
> see simply the statmement that no for of a signature can be denied 
> a legal status merely on the basis that it is not "in written form".
> Much of the rest is left open to hopefully close investigation of 
> each individual case that goes to the courts.

If the ESIGN act is the one that passed last summer it is primarily about
the law, not about technology. As I recall it says three things"

1) No law shall make an electronic signature invalid, solely because it is
an electronic signature; this clears the legal pathway and overrides state
laws to the contrary, but it doesn't actually say what does constitute a
legal e-sig

2) a valid contract can be formed by an electronic signature as long as both
parties agree to what constitutes an e-signature; so if Amazon.com wants to
accept my entering a credit care number and pressing a button that says SEND
as a signature, and if I understand that I am signing something and what I
am signing, that is cool. If Ford decides that it wants something more
tangible when it sells me a car on credit over the Web that is cool, too. 

3) the Secretary of Commerce shall promulgate further standards about
esignature to facilitate commerce. I am wondering if these regulations are
out. I have not seen them.

My primary concern is not about what constitutes an electronic signature. It
is that EDIINT has a clear purpose and that purpose is different than that
of being a digital implementation of an electronic signature. If HL7 or ASTM
tries to pass EDIINT with the intention of making into a legal electronic
signature we will spend endless hours debating all the issues that Gunther
and I discussed and EDIINT STILL won't become a standard.

---

From: [email-masked] (Chris Davenport)
Date: Tue, 28 Nov 2000 15:47:55 +0000 (GMT)

>AS1 needs to be "reworked" to be become a "generic" secure
>transport
>standard which supports all MIME media types as payloads. Contradictory
>statements,
>such as the one you cited would be eliminated and some non-RFC1767 examples
>should
>be included (perhaps an XML example would help).
>

Dick,

Thanks for the explanation.  I look forward to reading the revised
AS1/AS2 drafts in due course.

Regards,

Chris.

--
Chris Davenport              [email-masked]
Davros Computer Systems