Re: EDIINT and HIPAA

[Terry Harding <tharding@xxxxxxxxxxxxxxxxxxx>]

Dick,

This may have been mentioned in your email, but i must ask.

You mentioned within your email, that AS2 supports two distinct types of
packaging,
a  GISB style and an AS1 style. EDIINT(AS1) also specifies two packaging
standards,
one based around S/MIME(RSA) and another around openPGP(PGP).

Will the gas industry support an AS2 compliant product which produces a GISB
style message using RSA security, or must the security layer be PGP as in
your example...

Terry Harding
Cyclone Commerce

----- Original Message -----
From: "Dick Brooks" <dick@xxxxxxxx>
To: "Gunther Schadow" <gunther@xxxxxxxxxxxxxxxxxxxxxx>
Cc: "Rik Drummond" <rvd2@xxxxxxxxxxxxxxxx>; "Kepa Zubeldia"
<Kepa.Zubeldia@xxxxxxxxxxx>; "CLEM" <clem@xxxxxxxxxxxxxxxxxx>; "Gary Crough"
<gcrough@xxxxxxxxxxxxxxxxxxx>; "Beth Morrow" <Beth@xxxxxxxxxxxxxxxxx>;
"David@Drummondgroup. Com" <david@xxxxxxxxxxxxxxxxx>; <GISB1@xxxxxxx>;
<ietf-ediint@xxxxxxx>; "Dick Brooks" <dick@xxxxxxxx>
Sent: Thursday, November 02, 2000 11:26 AM
Subject: RE: EDIINT and HIPAA


> Gunther,
>
> In my travels I've realized there is a great deal of confusion regarding
> AS2, your questions/comments are a great lead-in to help clear up some of
> the misunderstandings. I apologize for sending such a long e-mail but I
> think it is necessary at this point. I've provided my responses inline
> bounded by <DB> </DB>, so here goes:
>
>
> > -----Original Message-----
> > From: Gunther Schadow [mailto:gunther@xxxxxxxxxxxxxxxxxxxxxx]
> > Sent: Thursday, November 02, 2000 10:13 AM
> > To: Dick Brooks
> > Cc: Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; Beth Morrow;
> > David@Drummondgroup. Com; GISB1@xxxxxxx; ietf-ediint@xxxxxxx
> > Subject: Re: EDIINT and HIPAA
> >
> >
> > Dick,
> >
> > I appreciate your warning. Please me (and others) understand ...
> >
> > You say:
> > > AS2 contains two distinctly different  ways to package and send EDI
> > > and other data over HTTP:
> > >
> > > 1. The HTTP standard approach,  ref: HTTP spec
> > (www.ietf.org/rfc/rfc2616.txt),
> > > Multipart/form-data spec (www.ietf.org/rfc/rfc2388.txt formerly
> > rfc 1867) and
> > > HTML 4.0 spec (http://www.w3.org/TR/REC-html40/)
> > > This is the approach used by GISB and the Automotive Industry (AIAG
E5)
> > >
> > > 2. E-mail based packaging as specified in EDIINT AS1
> > > (http://www.ietf.org/internet-drafts/draft-ietf-ediint-as1-11.txt ).
> >
> > Hmm, my understanding is that, while AS#1 uses SMTP (which I still
believe
> > is good ... but we had enough of that discussion :-), both AS#2
> > and the GISB
> > profile use HTTP. The difference may be the payload of the HTTP request.
> >
>
> <DB>
> There are many good reasons why people prefer HTTP over E-mail (SMTP) for
> their mission critical EDI data exchanges, but we won't re-hash them here.
> If people want to know the details send me an e-mail mailto:dick@xxxxxxxx
>
> There are three key concepts when discussing EDIINT AS2;
> 1. Packaging
> 2. Payload
> 3. Data Transport
>
> 1. Packaging defines the way in which EDI data and header information is
> packaged together in preparation for transport. The packaging also
includes
> a definition the headers that will be used for purposes such as
identifying
> senders, receivers, etc. (e.g. within the GISB - multipart/form-data
> packaging of AS2 there is a "To" header which contains a DUNS number that
> identifies the intended recipient. Within the e-mail based packaging of
AS2
> there is a new header, called "AS2-To", which serves the same purpose as
> GISB's "To" header. The "AS2-To" header is one of the changes that came
out
> of the EDIINT AS2 interoperability tests and this will be defined in the
> next draft release of AS2.)
>
> 2. Payload is the actual data a party wishes to send, typically a business
> transaction formatted in X12, EDIFACT, XML, etc.
>    A payload is contained within a "package", as defined by 1.
>
> 3. Data Transport defines the mechanism used to send/receive data (HTTP,
> SMTP, FTP are all data transports).
>
> With regard to EDIINT AS2 it:
>     Defines two types of packaging;
> 1. Multipart/form-data (as in GISB)
> 2. E-mail (as in AS1)
>
>     Can package and send any type of payload (X12, XML, JPEG, etc.),
> regardless of the packaging used. The data can be
>     encrypted and digitally signed.
>
>     Mandates that all "packages" be exchanged via HTTP.
>
>     Can support both batch and interactive (web forms) modes when using
> Multipart/form-data packaging.
>
> Here are two examples to help make this clear:
>
> GISB/AS2 example sending a signed/encrypted X12 file over HTTP using a
> non-interactive batch browser:
>
> POST c:\execute HTTP/1.0
> Connection: Keep-Alive
> User-Agent: Group 8760 Batch Browser
> Content-type: multipart/form-data;
> boundary=---------------------------87453838942833
> Content-Length: 5379
>
> -----------------------------87453838942833
> Content-Disposition: form-data; name="from"
> 123456789
> -----------------------------87453838942833
> Content-Disposition: form-data; name="to"
> 234567890
> -----------------------------87453838942833
> Content-Disposition: form-data; name="version"
> 1.4
> -----------------------------87453838942833
> Content-Disposition: form-data; name="receipt-disposition-to"
> 123456789
> -----------------------------87453838942833
> Content-Disposition: form-data; name="receipt-report-type"
> GISB-Acknowledgement-Receipt
> -----------------------------87453838942833
> Content-Disposition: form-data; name="input-format"
> X12
> -----------------------------87453838942833
> Content-Disposition: form-data; name="input-data"; filename=
> c:\temp\smallnom.bin
> Content-Type: multipart/encrypted; boundary=8760;
> protocol="application/pgp-encrypted"
> --8760
> Content-Type: application/pgp-encrypted
> Version: 1
> --8760
> Content-Type: application/octet-stream
> -----BEGIN PGP MESSAGE-----
> Version: PGP 6.5
>
> hQCMAzRG1pEOIOvdAQP+JMr0m/9+8yOL60Z9Vr6fFV81FCExB/o0xmwiMkiwYsHs
> z0e8sb7ErC340MrNA/dw3taGMjmI+CXYRF/PLEdg1NZE1ZCtNeL4YdIHAMLWwODG
> lQxhSucz8rMSgQ5mZzcOJwBdWLW70efgsu/9UljuJjYc1uZ6C03eFQv/43fkB+al
> ATtgydxX4g8QK664ad+Jo/XUICSmWBL66fqJR1KLeLf4wTaqGy174Aq48Wpwvg1E
> h785zC03UAw0qg0ugMt86dPeyd91e2JigqwDYEf/DYEKD0J9BGiGpS/uAupNKj8O
> cp2IWClxKOGUbxpVNOnNTqWHS/GntegvDE/7/ewCxDxsnmQS95pOl141QZ1RQbeN
> aqx2Dq/ra9g65HNchOCzjul5Vi8HHf6Yhg2WnROe+npByyCue6rihqgNVOJwj0cV
> zpb4JE+gMDf3q4ISUb1Fv7/+SSFHDdnhdC5YTpqf1Bc3B07hiLmtTXqNit31EbX9
> UVElObzSa9ZhxbC6/eSl7Nuf5ZTDsh9nrk+QQJ6FeC9W4cqXLj7IZySaRO8Vtff+
> 4ktqeuhYusT4kSpnk027aw4O/5jomUkfb22CAe4=
> =Oiuo
> -----END PGP MESSAGE-----
> --8760--
> -----------------------------87453838942833
>
>
> Here is an e-mail based example, taken directly from the current AS2
> interoperability testing underway (this was provided by Dale Moberg).
> NOTE: the AS2-To and AS2-From headers are NOT defined by the current AS2
> draft (these will be included in the next draft release of AS2):
>
> POST / HTTP/1.0
> User-Agent: Somebodys AS2 implementation
> AS2-From: ZZCYCLONE
> AS2-To: someone@xxxxxxxxxxxxxx
> Date: Wed, 18 Oct 2000 23:24:59 GMT
> Message-ID: <4fd79e5b-9e71-4655-8f98-d61f832dc11d@xxxxxxxxxxxxxxxxxx
> <mailto:4fd79e5b-9e71-4655-8f98-d61f832dc11d@xxxxxxxxxxxxxxxxxx>>
> Subject: EDI Document
> Content-Type: MULTIPART/SIGNED;
> protocol="application/pkcs7-signature";micalg=sha1;boundary="_=boundary1"
> Content-Disposition: attachment; filename="ZZIPNET-000000022.edi"
> Content-Length: 1507
>
> --_=boundary1
> Content-Type: APPLICATION/EDI-X12
> Content-Disposition: attachment; filename="ZZIPNET-000000022.edi"
>
> ISA*00*ssssssssss*00*rrrrrrrrrr*ZZ*ipnet *ZZ*btrade
> --_=boundary1
> Content-Type: APPLICATION/pkcs7-signature; name=smime.p7s
>
> ??Binary signature here??
> --_=boundary1--
>
> </DB>
>
> > Isn't it true that both AS#2 and GISB use the MIME security wrappers?
> >
>
> <DB> The AS2 compliant version of GISB uses the MIME security wrappers,
the
> old GISB simply placed encrypted data into an application/octet-stream
> wrapper. </DB>
>
> > Isn't the only difference that AS#2 uses RFC1767 application/EDI-*
> > payload while GISB use multipart/form-data?
> >
>
> <DB> The AS2 compliant GISB also packages X12 payload data in a RFC 1767
> compliant manner before placing it inside a multipart/form-data package.
For
> example, here is an unencrypted X12 file in multipart/form-data packaging:
>
> Content-type: multipart/form-data;
> boundary=---------------------------87453838942833
> Content-Length: 5379
>
> -----------------------------87453838942833
> Content-Disposition: form-data; name="from"
> 123456789
> -----------------------------87453838942833
> Content-Disposition: form-data; name="to"
> 234567890
> -----------------------------87453838942833
> Content-Disposition: form-data; name="version"
> 1.4
> -----------------------------87453838942833
> Content-Disposition: form-data; name="receipt-disposition-to"
> 123456789
> -----------------------------87453838942833
> Content-Disposition: form-data; name="receipt-report-type"
> GISB-Acknowledgement-Receipt
> -----------------------------87453838942833
> Content-Disposition: form-data; name="input-format"
> X12
> -----------------------------87453838942833
> Content-Disposition: form-data; name="input-data"; filename=
> hipaa-institution-claim.x12
> Content-Type: application/EDI-X12
>
> healthcare claim data in X12 format goes here
> -----------------------------87453838942833
> </DB>
>
> > Since you use form data, does that mean that GISB's operational model
> > is that of a user interacting with a web-based e-commerce system
> > directly (i.e. filling out an HTML form?)
> >
>
> <DB> This is the biggest misconception - GISB's operational model supports
> BOTH unattended (aka batch mode) and interactive types of data exchange.
> Both use the exact same packaging (multipart/form-data). By supporting
both
> interactive and batch mode GISB has been able to support the small trading
> partner, via an interactive web form upload and the large multi-national
> using the batch file upload.
> </DB>
>
> > Most of X12, HL7, and NCPDP, certainly do not work with direct user
> > interactions but use an EDI message payload formatted according to
> > X12, HL7 and NCPDP specifications respectively. (Though I know that
> > NCPDP has done something in direct user interaction too, but not
> > sure how much that is actually used.)
> >
>
> <DB> No problem HL7 and HIPAA can support both interactive and batch mode
> clients using the GISB/AS2 profile.
> </DB>
>
> > > The EDIINT AS2 interoperability test currently underway by the
> > Drummond Group
> > > and sponsored by UCC is exercising  the e-mail specifications
> > (option #2 above).
> > > The "profile" defined and adopted by GISB and AIAG (option #1
> > above) is not
> > > included in the EDIINT test, however there are numerous
> > implementations of GISB
> > > EDM and AIAG-E5 (the foundation specs that formed the basis of
> > AS2 profile #1)
> > > that have been used daily since 4/1997 for E-Commerce on the
> > Internet (Enron
> > > recently announced $200 Billion dollars in E-Commerce on the
> > Internet; they were
> > > the first company to implement the GISB standard for Internet
> > E-Commerce).
> >
> > this is good and fine. The only requirement would be that these
> > implementations can also support the EDI payload method of AS#2,
> > either now or easily soon (I suppose they can.)
> >
> > We certainly do not want to change the underlying EDI standards to
> > use form-data presentation.
> >
>
> <DB> This is no need to change X12 - the X12 data is simply a payload
within
> the multipart/form-data package. No changes are needed to package and send
> X12 following the GISB AS2 profile. In fact all of GISB's business
> transactions use standard X12 representation and there were no changes
> required to X12.
> </DB>
>
>
> > > The EDIINT AS2 interoperability test has uncovered some issues
> > that required
> > > changes to the e-mail formatting specifications within AS2 (Rik
> > can provide the
> > > details of the problems, but they were "show stoppers" that had
> > to be fixed).
> > > These changes do NOT affect the GISB or AIAG profiles of AS2
> > (option #1), the
> > > changes are limited to the e-mail section (option #2).  This
> > means the AS2
> > > authors (Dale Moberg, Rik Drummond and myself) will have to
> > make appropriate
> > > adjustments to AS2 and republish as an IETF draft. This will
> > begin a review
> > > process and will most likely require a face-to-face meeting at
> > the IETF to move
> > > the process along.  This could delay the standardization of AS2 by
IETF,
> > > depending on the feedback received regarding the changes. The
> > GISB profile of
> > > AS2 (option #1) has remained unchanged, so I don't expect any
> > opposition/issues
> > > to arise.
> >
> > Gulp, this means another year delay until the final RFC is out, the IESG
> > has got to speed up its processes!
> >
>
> <DB> I'm not sure how long a delay we're looking at to make AS2 an RFC.
When
> I worked on the development of RFC 1767 I thought we would finish in 3
> months (we only had to define 3 MIME types). We started in 1993 and it
> didn't reach RFC status until March 1995. You just can't predict what will
> happen within the IETF.
> </DB>
>
> > > I'm willing to discuss this further and help move AS2 closer to
> > becoming an IETF
> > > and government approved standard, beyond the endorsement
> > received by GISB from
> > > DOE/FERC.
> > >
> > > FYI - Group 8760 has assisted in performing interoperability
> > testing (Internet
> > > transport only), using the GISB standard (with PGP
> > encryption/signatures),
> > > between an institutional provider and a large Insurance Carrier
> > (payer) for
> > > HIPAA compliance within the last 3 months with successful results.
> >
> > Would you be willing to come to a couple of HL7 meetings and help us
> > release the IETF specs as HL7 standard (for ANSI approval) and
> > communicate
> > our few additional requirements back into the IETF?
> >
>
> <DB> I'm interested in talking with you about your requirements and would
be
> happy to assist.</DB>
>
> > In addition, I would like to have some other IETF-EDIINT members
(vendors)
> > to step up and join that fast track group for EDIINT ANSI approval. If
we
> > could get three people who see this as a valuable investment, it would
> > help. May be on the next IETF-EDIINT meeting we should talk about this.
> > Either Kepa and/or I should come see you to discuss the ANSI question
and
> > get the ball rolling.
> >
> > But, you have to understand, I'm kind of looking for a clear sign
> > from the
> > EDIINT group to say "yes, this ANSI thing makes sense, so let's
> > go do it,"
> > you know, some committment. Note that neither I nor HL7 has a
> > particularly
> > huge selfish interest in this to happen, we would not participate in
that
> > sudden market growth, we are not vendors selling products to
> > every Medicare
> > provider in the US :-). We are just kind of hoping to help the right
thing
> > to happen for the sake of sanity :-)
> >
>
> <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>
>
> > regards
> > -Gunther
>
> Thanks, and sorry for the loooong message,
>
> Dick Brooks
> Group 8760
> 110 12th Street North
> Birmingham, AL 35203
> dick@xxxxxxxx
> 205-250-8053
> Fax: 205-250-8057
> http://www.8760.com/
>
> InsideAgent - Empowering e-commerce solutions