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

["Rishel,Wes" <wes.rishel@xxxxxxxxxxx>]

This note implies a characteristic of AS2 that I had not previously
recognized. I will state it here and then perhaps someone can tell me if I
am reading it wrong.

The note seems to imply 

(a) that AS2 does not support SMTP or FTP
(b) that AS2 exchanges between business partners follow a pattern where the
partner that initiates the exchange has to poll for the application
response.

Previously I had thought that AS2 supported all of HTTP, HTTP/S, SMTP and
FTP, and that it was necessarily to develop a set of profiles for there to
be meaningful communications among trading partners.

Furthermore, I had assumed that if messages were to go asynchronously
between point A and point B and back, that each of point A and point B could
offer HTTP servers or FTP servers. In particular, if A is the payer and B is
the provider, then B could initiate a claim by posting to A's HTTP server.
Later on, A could post a response to B's HTTP server. B would have the
option of handling the event immediately or building a queue of inbound
transactions to process when it wanted.

Was I wrong before?

Now, given that a significant number of payer organizations are small
practices they may not wish to spend the $40/month that it takes to have a
permanent presence on the Internet. Such practices might prefer to poll the
payer for responses. (To be honest I didn't realize that EDIINT supported
that mode. I thought it was basically a way to send a message and optionally
get an immediate response giving the gross status of the initial
transmission.)

I would agree with Kepa that it would be preferable to use SMTP to HTTP for
these small payers, but using e-mail is a somewhat dicey proposition. In the
ideal world, where someone establishes an isolated SMTP server just to deal
with transactions, and gives that server direct access through the firewall,
then it should be fairly robust. But large enterprises tend to have
enterprise mail systems that include very complex interrelationships between
servers that have many more functions than simple mail transfer and are
difficult to maintain. Although mail delivery of AS2 transactions would
probably work most of the time, it would be significantly less robust than
HTTP or FTP implementations, where there is only one server involved on each
side and its administration can be dedicated to the purpose of handling
transactions.

So, what is happening? How much do I have to relearn since my last coffee
break (:-)


> -----Original Message-----
> From: Kepa Zubeldia [mailto:Kepa.Zubeldia@xxxxxxxxxxx]
> Sent: Tuesday, November 21, 2000 3:04 PM
> To: Gunther Schadow
> Cc: dick@xxxxxxxx; Rishel,Wes; Rik Drummond; CLEM; Gary Crough; Beth
> Morrow; David@Drummondgroup. Com; GISB1@xxxxxxx; ietf-ediint@xxxxxxx
> Subject: Re: HL7 Standards Process (was RE: EDIINT and HIPAA)
> 
> 
> Gunther,
> 
> Here is some food for thought concerning AS1...
> 
> When a provider files a batch of claims, the transmission can 
> easily be
> sent with AS1 or AS2.  The claims will adjudicate over a 
> period of a few
> days.  When the claims adjudicate, there is an X12 835 
> transaction that
> the payer needs to send back to the provider with the 
> remittance advice.
> 
> A typical provider will deal with about 400 payers on a 
> routine basis. 
> A typical payers will deal with about 100,000 providers on a routine
> basis.
> 
> So, if the provider must be using AS2 only, the provider will have to
> periodically (probably daily) poll all the payers in case 
> they have some
> remittance advice or other transaction from that payer.  The payer, on
> the other hand, will have to hold "mailboxes" for 100,000+ 
> providers and
> be polled by them periodically, so the remittance advices can be
> distributed back to the providers.  Not strikingly efficient.
> 
> But if the provider can send the claims with either AS1 or 
> AS2, and the
> payer can send the remittance advices back with AS1, all the 
> polling and
> mailboxing is eliminated, as the flow goes through the standard email
> pathways.  The provider does not have to maintain an internet 
> server to
> received EDI, only the capability to receive internet mail.  
> Sounds like
> a much simpler approach.  Of course, this assumes that the AS1 is not
> only signed but also encrypted.
> 
> So, if you ask me, I would say that AS1 should not go away, 
> even if the
> fancier and better way to do it is with AS2.  There is 
> certain beauty in
> simple solutions.
> 
> Kepa
> 
> 
> 
> Gunther Schadow wrote:
> > 
> > Dick,
> > 
> > yes, I think that the HL7 and HIPAA profiles would be 
> similar if not the
> > same. My goal is to get all the healthcare standards 
> together (in fact
> > it is only two of them, HL7 and NCPDP, since X12 is covered 
> already) and
> > develop one profile with options to account for the 
> specific EDI payload
> > used. We have an AS#1 profile already for HL7 and I'd like 
> to take this
> > to go over a couple of issues that we found. As much as I 
> can see why
> > AS#2 is very useful, I would not want to throw out the 
> AS#1/email option
> > if not absolutely necessary. You mention ebXML -- we have 
> some interest
> > in ebXML but we're not sure if any of this is ready for 
> prime time, but
> > would like to get your thoughts on this.
> > 
> > regards
> > -Gunther
> > 
> > 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
> > > dick@xxxxxxxx
> > > 205-250-8053
> > > Fax: 205-250-8057
> > > http://www.8760.com/
> > >
> > > InsideAgent - Empowering e-commerce solutions
> > >
> > > > -----Original Message-----
> > > > From: Kepa Zubeldia [mailto:Kepa.Zubeldia@xxxxxxxxxxx]
> > > > 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; GISB1@xxxxxxx; 
> ietf-ediint@xxxxxxx
> > > > 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
> > > > > dick@xxxxxxxx
> > > > > 205-250-8053
> > > > > Fax: 205-250-8057
> > > > > http://www.8760.com/
> > > > >
> > > > > InsideAgent - Empowering e-commerce solutions
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Rishel,Wes [mailto:wes.rishel@xxxxxxxxxxx]
> > > > > > Sent: Friday, November 17, 2000 8:32 PM
> > > > > > To: 'dick@xxxxxxxx'; Gunther Schadow
> > > > > > Cc: Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; 
> Beth Morrow;
> > > > > > David@Drummondgroup. Com; GISB1@xxxxxxx; ietf-ediint@xxxxxxx
> > > > > > 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 
> indapps@xxxxxxxxxxx
> > > > > > wes.rishel@xxxxxxxxxxx
> > > > > > 510 522 8135
> > > > > > 510 521 2423 (fax)
> > > > > >
> > > > > >
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Dick Brooks [mailto:dick@xxxxxxxx]
> > > > > > > Sent: Thursday, November 02, 2000 10:27 AM
> > > > > > > To: Gunther Schadow
> > > > > > > Cc: Rik Drummond; Kepa Zubeldia; CLEM; Gary 
> Crough; Beth Morrow;
> > > > > > > David@Drummondgroup. Com; GISB1@xxxxxxx; 
> ietf-ediint@xxxxxxx; 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>
> > > > > > >
> > > >
> > > >
>