Status and Future of EDIINT

[Gunther Schadow <gunther@xxxxxxxxxxxxxxxxxxxxxx>]

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

begin:vcard 
n:Schadow;Gunther
tel;fax:+1 317 630 6962
tel;home:+1 317 816 0516
tel;work:+1 317 630 7960
x-mozilla-html:FALSE
url:http://aurora.rg.iupui.edu
org:Regenstrief Institute for Health Care
adr:;;1050 Wishard Blvd;Indianapolis;Indiana;46202;USA
version:2.1
email;internet:gschadow@xxxxxxxxxxxxxxx
title:M.D., Medical Information Scientist
note;quoted-printable:Al oppinions expressed in this message are my own and do =0D=0Anot necessarily represent those of the Regenstrief Institute.
fn:Gunther Schadow
end:vcard