[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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