Subject: Status and Future of EDIINT

From: Gunther Schadow <[email-masked]>
Date: Tue, 31 Oct 2000 10:41:10 -0500

Dear EDIINTers,

EXECUTIVE SUMMARY

Some sectors of the U.S. government have a need for EDI security that
is technically best serverd by EDIINT at this time. In particular,
the HHS department might possibly adopt EDIINT. This kind of adoption
would mean a very important growth potential for all vendors who are
now supplying EDIINT solutions. An HHS adoption would basically open
up the entire U.S. healthcare market to the EDIINT vendors, including
HCFA/MEDICARE and other governmental agencies, not to mention good
contracting and consulting oportunities. There are lots of incentives.

However, in order for this to happen, certain issues should be 
dealt with.

#1 EDIINT WG appears dead or slow working, we need new livelyhood and
faster progress and document turn-around to RFC status.

#2 The U.S. government mandates its agencies to primarily adopt ANSI 
standards. HL7, an ANSI SDO, could be willing to process and release 
the EDIINT specifications under HL7 cover, so that they may become 
ANSI standards. This requires willingness and focused cooperation on
the part of EDIINT. Timeframe would be relatively short, about 6 months.

#3 Some minor technical issues need to be addressed, mainly the 
official blessing and successful registration of media type for 
healthcare related EDI standards (HL7, NCPDP) and potentially 
another AS applying EDIINT structures to miscellaneous documents. 

DETAILS

There is great oportunity for strong growth of EDIINT specifications and
products in the healthcare marketplace. The reason is that there are certain
security standards to be adopted by the U.S. Dept. of Health and Human 
Services to secure EDI transactions using X12, HL7, and NCPDP/EDIFACT EDI
message standards. To make a long story short, EDIINT looks like a perfect
candidate for the HHS Secretary to choose. EDIINT's outstanding advantage
before all other similar message security standards is it's strong support
of various non-repudiation services not available with, say, SSL or plain
PKCS#7 (aka "S/MIME"). The other great advantage is that EDIINT specs are
interoperability tested with several major vendors ready to sell/deploy 
products. EDIINT is not too new, and relatively mature, which is important
for HHS too, since the government can't embark on a trial and error
endeavor with bleeding edge hyped technology. 

So, the future of EDIINT is bright, ... right?

There are certain mjor issues, however, that stand in the way, and this
message is both an inquiry on the status of EDIINT and a plea to get these
issues resolved ASAP.

ISSUE #1 EDIINT IS DEAD?

EDIINT appears dead -- several of its major drafts have expired
by now, supposedly waiting in the queue of the heavily overloaded RFC
editor. Last calls have long passed, and yet nothing ever happened in terms
of RFC releases. While this may not be the EDIINT WG's fault in particular,
it sends a bad "vital sign".

The fact that the EDIINT-HL7 draft has expired is my fault, but frankly
with everything moving so slowly, and lack of overall interest in HL7 
matters by this group, the incentives for cycling through this 6-month
draft expiration are not very high. I was hoping that the next draft
could be one that cites all RFCs and that it could move up to last call
soon...

Whoever has contacts into the IETF/IESG policy might want to suggest that
the backlog at the RFC editor is a serious problem deserving attention.

BTW: I am very worried that the working group constituency and its 
leadership have turn to ebXML without having brought the EDIINT effort 
to a conclusion. I reckon that the slowness of EDIINT progress stands
in reciprocal relation with the feverish ebXML work. However, the
business case for ebXML is hard to see if you take away all the hype.
Particularly when it comes down to strong government bet on a 
specification the more bleeding edge thing has disadvantages. You
want to have one thing in place that works now. That is EDIINT.
We should finish that first and worry about the omni-XMLification 
later.

ISSUE #2 ANSI ACCREDITATION

EDIINT is not an ANSI standard and IETF not an ANSI SDO. The
government mandates that governmental agencies look first at adopting
ANSI standards. There is one ANSI SDO that has certain security
related standards and that is well positioned to push those 
politically. Those specification, however, haven't been widely
implemented and may be too peculiar to healthcare to be cost-
effectively deployed. 

Now, there may or may not be reasons why IETF has never
become an ANSI SDO, about which we could talk off line (being an ANSI
SDO doesn't mean serious changes in policies and procedures for IETF
AFAIK ... yes IETF is international, but I think that being an ISO SDO
is more encumbering than simply operating under ANSI ... there is nothing
in ANSI statutes that would limit strong international involvement.)

For EDIINT specifications, however, HL7 could help out w/r/t the ANSI
approval. We could cast all EDIINT specifications under HL7 cover, 
go through a formal ballot procedure, and get these specs declared as
ANSI standards. HL7 has a certain momentum in getting this done, and
I do not expect our balloting to bring significant turmoil and changes
to the specs.

If there is interest, I suggest that one or a few people out of the 
EDIINT group should get in contact with HL7, which I am glad to catalyze.
The easiest way to get through the HL7-ANSI process would be if it 
were managed by EDIINT people. The HL7 executive branch would assist
and guide through the process, the major editorial work, however, 
would be born by the people that EDIINT delegates to working with HL7.
Time estimate, once the process is established, about 6 months.

While HL7 is a healthcare information standard, the ANSI approval gained
through HL7 is in no way "encumbered" by terms that would limit 
applicability to healthcare. So, the EDIINT's ANSI approval gained 
through HL7 would be worth in other U.S. governmental adoptions, of
which there is plenty of oportunity at this time.

ISSUE #3  TECHNICAL THINGS

There are certain technical things that would need quick
resolution. For example, we would need to get new application/EDI-*
MIME types approved rather quickly. I have submitted a request to the
MIME type registry for application/EDI-HL7 several months ago, but
I never heard back and my request hasn't been acted on. This again 
may be a symptom of overload at the IETF/IANA and somebody should
do something about this.

Anyway, we would need application/EDI-NCPDP and application/EDI-HL7
at least. Then we might need an AS for a simple file based documents
(simple and stupid). Basically this would use the same EDIINT mechanism,
but the payload could be anything, plain text, XML, proprietory formats.
The use case is, e.g., electronic patient consents, etc. 

CONCLUSION

I am being a little forward-looking here because I want to get the 
attention of the existing vendors asking them to help and suggesting
that they would have a good ROI from this effort in terms of growth
potential.

Note that there is a window of oportunity open now, that requires 
quick action and a certain dedication. No promise can be made but
chances are quite good if enough people work on this. This project
would not stand without a certain political infrastructure helping
its success, but the main thing we need is committment of the EDIINT
group.

regards
-Gunther

---

From: "Rik Drummond" <[email-masked]>
Date: Tue, 31 Oct 2000 10:34:43 -0600

well it is not dead. the spec is in the loop for rfc approval... and we now
have 12 vendors supporting as1 and 9 supporting as2. these are all
interoperable. if we don't get something back from the ietf shortly it might
be wise to go the ansi route... rik

-----Original Message-----
From: Gunther Schadow [mailto:[email-masked]]
Sent: Tuesday, October 31, 2000 9:41 AM
To: [email-masked]; Rik Drummond; Kepa Zubeldia; CLEM
Subject: Status and Future of EDIINT

Dear EDIINTers,

EXECUTIVE SUMMARY

DETAILS

ISSUE #1 EDIINT IS DEAD?

CONCLUSION

regards
-Gunther

---

From: "Rik Drummond" <[email-masked]>
Date: Tue, 31 Oct 2000 10:38:44 -0600

also the current version of as2 is being edited again as a result of the
finding of the current interoperability pilot.... if yon wish info on its
state over the next few weeks please send email to david.... best regards,
rik

-----Original Message-----
From: Gunther Schadow [mailto:[email-masked]]
Sent: Tuesday, October 31, 2000 9:41 AM
To: [email-masked]; Rik Drummond; Kepa Zubeldia; CLEM
Subject: Status and Future of EDIINT

Dear EDIINTers,

EXECUTIVE SUMMARY

DETAILS

ISSUE #1 EDIINT IS DEAD?

CONCLUSION

regards
-Gunther

---

From: "Dick Brooks" <[email-masked]>
Date: Tue, 31 Oct 2000 12:50:43 -0600

Gunther, see comments inline marked with <db></db>

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: [email-masked]
> [mailto:[email-masked]]On Behalf Of Gunther Schadow

<db>
EDIINT is certainly not dead, however I would agree it has been slow moving.
The adoption rate of EDIINT AS2 has been steady within the Energy industry,
which was the first industry group to my knowledge to formally embrace it as
a standard. The Gas Industry Standards Board (www.gisb.org) has adopted
EDIINT AS2 as it's E-Commerce standard. The state of New York has publicly
endorsed the Gas Industry Standards Board EDIINT AS2 interoperability
profile.

The Energy industry in general prefers the reliability and security of HTTP
based solutions, such as EDIINT AS2, as opposed to E-mail based solutions,
such as EDIINT AS1, mainly due to issues with poor reliability and security
of e-mail.
</db>

> the backlog at the RFC editor is a serious problem deserving attention.

<db>
I attended the IETF meeting in Pittsburgh this July and spoke with Ned Freed
about this very issue. There is a huge backlog within the IESG and Ned
assured me that the EDIINT request was in the queue. I believe there will be
more changes to AS2 and another draft review before we can move forward with
a last call/IESG action.
</db>

> We should finish that first and worry about the omni-XMLification

<db>
EDIINT is here today and people are using it for secure/reliable B2B
E-commerce. ebXML promises broader (international) support tomorrow and may
well be the "next generation" of B2B e-commerce, only time will tell.
</db>

> which there is plenty of oportunity at this time.

<db>
I spoke with Wes Rishel about assisting HL7 regarding the possible
adoption/use of EDIINT and I'm still willing to assist. Let me know the best
way to proceed.
</db>

> The use case is, e.g., electronic patient consents, etc.

<db>
EDIINT AS2 supports ANY file type today (using the "INPUT-FORMAT" header)
and can also identify the particular type of transaction contained in the
"payload" (via the "TRANSACTION-SET" header). This solution has been used by
the Natural Gas industry since 1997 for Internet B2B E-commerce (and was
mandated by the Department of Energy/FERC) and the Automotive industry
(AIAG).
</db>

> its success, but the main thing we need is committment of the EDIINT

You can certainly count on my employer for support. But more importantly, I
believe you may also receive the support of other organizations that
currently support EDIINT AS2, such as the Gas Industry Standards Board and
other government bodies within the Energy sector (perhaps DOE, FERC and some
state PUC's). I'm willing to help open a dialog with some of these
organizations.