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

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

Is the transaction identifier qualified by another field or is there a need
to set up a registry of transaction set identifiers? I suspect that HL7
would prefer to maintain its own identifiers without worrying about
collision with another standard or having to sit through length debates
about whether to use a hyphen or an underbar.

> -----Original Message-----
> From: Dick Brooks [mailto:[email-masked]]
> Sent: Wednesday, November 22, 2000 9:57 AM
> To: Rishel,Wes; 'Kit (Christopher) Lueder'
> Cc: 'Kepa Zubeldia'; Gunther Schadow; Rik Drummond; CLEM; Gary Crough;
> Beth Morrow; David@Drummondgroup. Com; [email-masked];
> [email-masked]
> Subject: RE: AS2 XML requirements (was Re: HL7 Standards Process)
> 
> 
> Wes,
> 
> > 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. [snip]
> 
> You are right on, that's why AS2 has a header field called
> "Transaction-Set". The sender uses this header to identify
> exactly what type of data is contained in the payload 
> (regardless of the
> encoding syntax X12, XML. et al). For example, GISB uses the 
> same ANSI X12
> 850 transaction set for different purposes so they created 
> transaction set
> identifiers (e.g. G850NMST or G850RQCF) to provide more precision when
> identifying a payload.  A sender would insert either "G850NMST" or
> "G850RQCF" in the "transaction-set" header, this way the 
> receiving party can
> "dispatch" processing to different "process flows" based on 
> the "transaction
> set" identifier.
> 
> 
> 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: "Dick Brooks" <[email-masked]>
Date: Wed, 22 Nov 2000 17:59:00 -0600

Wes,

I expect that HL7 will define "Transaction-set" identifiers when
constructing the Interoperability Profile. That's how it happened with GISB.
Perhaps a "namespace" qualified Transaction-Set identifier would be useful,
e.g. HL7:XXXyyyy

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: Rishel,Wes [mailto:[email-masked]]
> Sent: Wednesday, November 22, 2000 3:15 PM
> To: [email-masked]'; 'Kit (Christopher) Lueder'

---

From: Gunther Schadow <[email-masked]>
Date: Fri, 24 Nov 2000 00:18:35 -0500

Wes, Dick, Kepa, and all ...

wow, you've had quite an e-mail day today (I mean yesterday), we can be really 
lucky that I see all this only after the fact that way I didn't get involved 
and didn't write my usual e-mail bombs :-) So, I can summarize a few key 
issues:

1) AS1 vs. AS2 / email vs. HTTP

2) XML as payload and how to process payload

3) digital e-signatures, the law, and whatnot

4) what else?

1) AS1 vs. AS2 / email vs. HTTP

Kepa, I agree with you. Dick and Wes, I see a good place for email routes 
especially to smaller participants. However, we had been engaged in endless
hard debates on this issue before and it's like everything had been said.
All I ask is that we will continue to offer AS1 for email and AS2 for
HTTP and whatever else we need. I didn't see you object against continuing
to offer AS1, and that is enough for me. I don't need to change your mind
to thing less negative about email.

2) XML as payload and how to process payload

I agree with Wes. XML don't mean s... (I spent my day with car mechanics,
so I picked up some of their jargon :-). HL7 v3 has fully embarked XML,
and I agree, but it's not XML that's important but HL7, NCPDP, X12 or
what have you. EbXML might provide a common message "header", but that's
going to be about all, and ebXML is out of the question at this time.

I have long ago tried to convince people at IETF EDIINT to revise the 
RFC 1767 spec to add additional EDI-* MIME types, to add parameters
to the EDI-* MIME type, and to devise a way to use EDI-consent more
robustly. I talked high and low, long and short, but I didn't get my
point accross. Might it be that now is the time to get some agreement
about this? At least some of this is a precondition to do any of the
HL7/NCPDP profiles in that ANSI/HHS process.

3) digital e-signatures, the law, and whatnot

I have heard a lot of very cautious statements about e-signatures
in healthcare and have read 3 articles now that caution more or 
less bluntly that "digital signatures" are no signatures. I am 
also aware of ths issue of requiring to see exactly what is signed
and to freeze that representation as part of the signed document.
XSL stylesheets or screenshots are then discussed, and I believe
that if we'd take that serious we could only allow screenshots to
be signed and that wouldn't even be enough.

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.

4)  what else?

Ah, to reiterate Kepa: limit the scope. With the transaction standards
in the HIPAA scope, we do not need very elaborate signature and
countersignature attribution mechanics, since those transaction 
standards don't have much of that elaborate notion. So, the EDIINT
route with one signature per transaction is probably all that's 
needed for now.

Down the road, of course, we have HL7 v3 and XML digital signatures
and we are ready for fine grained multi-signature and countersignature 
control with attributions along the lines of ASTM E1762 requirements,
etc. But that isn't what the HHS would consider adopting anytime 
soon because it is simply too new and too advanced.

regards
-Gunther

PS: thanks to Peggy Leiby and the HL7 headquarter, we now have a 
room for our Monday 1/8 meeting. So we can send out invitations rather
soon. We will have people from ASTM, IETF, NCPDP, ABA, NCVHS, and HL7
present. This is great stuff!

---

From: "Dick Brooks" <[email-masked]>
Date: Fri, 24 Nov 2000 10:09:34 -0600

Gunther, see responses inline.

> to thing less negative about email.

No argument here. I think it was Kepa who suggested that a provider may
need HTTP when sending to a Payer and a Payer may need SMTP when sending
to a provider. Both parties should be free to implement the "inbound"
delivery approach that meets their security, performance, reliability and
business requirements.

The HL7 interoperability profile needs to specify these details.

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