Subject: We do have a marketing problem ...

From: Gunther Schadow <[email-masked]>
Date: Mon, 19 Apr 1999 17:18:17 -0500 (EST)

Hi,

I remember from speaking with a representative of a supporting EDI
vendor that EDIINT has a problem. Not a technical problem but a
marketing problem. I just have the HL7 document out for HL7 internal
ballot and the returns I get from health care vendors and public
health care agencies alike are discouraging.  The hardest argument to
break is the dull feeling that "e-mail is unreliable."

The world does not seem to understand the opportunities.  Everyone
seems to wait for heavy-weight integrated proprietory
security-super-systems rather than daring to take the little step into
a great future.  E-mail is cheap, abundant, very reliable if used
wisely, and more powerful than the solutions that are often
preferred. It is so strange that direct TCP or even FTP (that's
ridiculous!) is often preferred by such user organizations.

What are we going to do about this?

Are there articles and success stories published in some major
management-level journals?  Those of you who are vendors, do you have
cool marketing brochures describing and defending the e-mail approach?
EDI is a field of business computing that where decisions are made in
the belly not in the mind. So, we need to address this somehow or we
are doing all the work in vain.  How does CommerceNet create the
support in the market?

any comments are appreciated,
regards
-Gunther

Gunther Schadow ----------------------------------- http://aurora.rg.iupui.edu
Regenstrief Institute for Health Care
1001 W 10th Street RG5, Indianapolis IN 46202, Phone: (317) 630 7960
[email-masked] ---------------------- #include <usual/disclaimer>

---

From: "Carl Hage" <[email-masked]>
Date: Mon, 19 Apr 1999 16:05:00 -0800

Date sent:      	Mon, 19 Apr 1999 17:18:17 -0500 (EST)
From:           	Gunther Schadow <[email-masked]>

> ...The hardest argument to

I think you are right. In fact email is more reliable than http (email 
has error-retry whereas www broken/inaccessable connections 
simply fail).

Perhaps the problem is using the term "email". There is a big 
difference between uucp email gatewayed into a proprietary LAN 
email system and EDIINT. Why not use the term "EDIINT 
Messaging", which has the properties:
  - real time message transfer (if recipient has a dedicated 
connection)
  - guaranteed delivery confirmed by receipts
  - legal non-repudiation
  - ability to use redundant network providers and processing sites
   for ultra-high reliability
  - compatible with dedicated (real-time) or dial-up net connections
  - compatible with standard Internet software

The irony is that traditional EDI using vans _is_ email, but 
proprietary email.

Compared with HTTPS (SSL Secure-HTTP), EDIINT offers:
  - Legal nonrepudiation
  - Automated recovery on delivery failures
  - Support for backup sites/networks

It is incorrect to state that SMTP is not real-time whereas HTTP is.

Compared with traditional VANs, EDIINT offers:
  - Real-time messaging
  - Interoperability across all network providers
  - Increased security
  - Increased reliability
  - Lower network cost

The main problem with VANs (other than cost) is potential poor 
reliability across VANs. I lost my reference (US government 
electronic filing) where cross-VAN deliveries took several days.
Simply changing VANs creates major problems since it requires 
manual intervention with all TPs.

Also, a VAN is a single point of failure. Two internet-compatible 
network providers (ISPs) with independent networks can be 
obtained for less than the cost of one VAN. Changes in ISPs or 
routing across alternate providers is transparent. (The DNS system
replaces proprietary VAN email addresses.)

Security is improved since data can be exchanged encrypted and 
cannot be intercepted or altered by VANs/ISPs/wiretaps. Non-
repudiation is provided by digital signatures, not the just the 
testimony of a third-party VAN which can offer logging service.
--------------------------------------------------------------------------
Carl Hage                                              C. Hage Associates
<mailto:[email-masked]> Voice/Fax: 1-408-244-8410      1180 Reed Ave #51
<http://www.chage.com/chage/>                          Sunnyvale, CA 94086

---

From: "Carl Hage" <[email-masked]>
Date: Mon, 19 Apr 1999 16:12:10 -0800

Oh, here's the reference on the reliability of traditional EDI,

<http://www.epa.gov/oms/regs/fuels/rfg/attstrtp.txt>

[The names of the VANs are xxxx/yyyy to protect the guilty.]

"This is to inform you that effective on April 1, 1996 the
EPA Reformulated Gasoline and Anti-Dumping System (REFGAS) 
will cease to accept Electronic Data Interchange-filed reports at the
xxxx EDI Value Added Network (VAN).  On that date REFGAS will 
begin to accept transmissions at the yyyy VAN.
...
Fourth quarter and annual reports for 1995 should be sent to
xxxx EDI by such a time that they will arrive at the xxxx VAN
and be available to the EPA no later than 11:59 PM on March 31,
1996.  The EPA will not be able to receive any incoming
transmissions on the xxxx VAN after that time.  It has been the
EPA s experience that some transmissions that involve
interconnections with other VAN providers can take multiple days
to reach the EPA."
--------------------------------------------------------------------------
Carl Hage                                              C. Hage Associates
<mailto:[email-masked]> Voice/Fax: 1-408-244-8410      1180 Reed Ave #51
<http://www.chage.com/chage/>                          Sunnyvale, CA 94086

---

From: "Kit Christopher J. Lueder" <[email-masked]>
Date: Tue, 20 Apr 1999 11:01:36 -0400

I agree that there is a perception problem that e-mail is unreliable.
That is why EDIINT was developed in the first place.

However... with FTP you know immediately at the end of the session
whether the FTP transfer succeeded or failed, so you can act on the
failure now or archive the document that was successfully sent. With
e-mail, even using the EDIINT secure receipt, you don't know untill
later whether it succeeded or failed (including the use of a timeout if
you don't receive a response at all). So EDIINT takes more effort to
implement, since you have to keep track of it and save the original
files, and not know whether they are "checked off" until later.

There is also the risk that your EDIINT transmission succeeded, but the
receipt that was sent back in response failed, in which case you resend
your original transmission after a timeout of waiting for the receipt.
This would result in the recipient receiving duplicate copies of the
transaction, which some VANs or users would consider to be a problem.
This generally does not happen with FTP, since you can see if the file
resides on the destination system at the end of the transfer.

> Compared with traditional VANs, EDIINT offers:

I don't see why e-mail is "real-time" (unless the only alternative is
"batch"). You send and wait for an asynchronous reply. Maybe we need a
definition of "real-time". You don't have a session or a virtual
connection with e-mail. Can't you have a session with http (maybe that
is what cookies are used for), in which case http is real-time?

Kit.

-- 
    _/    _/             Kit C. J. Lueder       
   _/   _/         _/   The MITRE Corp.         Tel:  703-883-5205
  _/_/_/    _/  _/_/_/ 1820 Dolley Madison Bl  Page: 703-331-7656
 _/   _/   _/    _/   Mailstop W658           FAX:  703-883-3383
_/    _/  _/    _/   McLean, VA 22102        Mail: [email-masked]
God offers to every mind its choice between truth and repose
-Emerson, Essays: Intellect

---

From: "Carl Hage" <[email-masked]>
Date: Tue, 20 Apr 1999 11:12:56 -0800

Date sent:      	Tue, 20 Apr 1999 11:01:36 -0400
From:           	"Kit Christopher J. Lueder" <[email-masked]>

> With
> you don't receive a response at all).

It depends on whether a store-and-forward gateway is used. Most 
people use a gateway by default since it's easier and automatically 
queues if the recipient is inaccessable.

With direct SMTP connection, the system knows when the 
message has been received. A receipt is still important, since the 
message could be lost on the recipients system before it's 
processed.

 So EDIINT takes more effort to
> implement, since you have to keep track of it and save the original files,
> and not know whether they are "checked off" until later.

You'd have to do the same with FTP, or even with a VAN if you 
wanted maximum reliability and detection of problems.

> your original transmission after a timeout of waiting for the receipt.

Most failures can be detected and the sender can retry. For 
completeness, the original can be resent.

> Maybe we need a
> definition of "real-time".

Messaging within a few seconds, on a non-overloaded link. Of 
course this is what SMTP can do technically, not necessarily what 
implementations do.

> You don't have a session or a virtual
> connection with e-mail.

With SMTP you have a socket connected to the recipients system, 
and using the TURN operation, the same socket can be used for 
the reply. Otherwise, a separate socket would be used.

The asynchronous wait for reply includes processing of the 
message. If the recipient system can't process immediately, then
the checkoff of the reply needs to wait.

The smtp (or http post) is synchronous in that the incoming 
message is immediately delivered to a processing application. 
With FTP, normally, the file system must be polled and checked 
for changes. There is a problem in that it is not always easy to tell 
when the FTP file transfer is complete and correct. Errors can 
occur, undetected to the sender, leaving partially complete files 
laying around. I suppose FTP could be made to work 
synchronously, but it's more complex than SMTP.

Any high-reliability system is going to need to keep a log of 
transactions, and check to make sure there are no problems, so I 
don't see that checking for missing reciepts is any extra effort. It's 
much simpler than getting FTP to work.

 Can't you have a session with http (maybe that is
> what cookies are used for), in which case http is real-time?

A cookie "session" is a way to associate separate transactions, 
which otherwise have no relationship. With EDIINT, Message-Ids 
are used to establish a relationship. BTW, with FTP there are 2 
connections made: 1 a "session" control link, and a separate link 
for each file transmitted.
--------------------------------------------------------------------------
Carl Hage                                              C. Hage Associates
<mailto:[email-masked]> Voice/Fax: 1-408-244-8410      1180 Reed Ave #51
<http://www.chage.com/chage/>                          Sunnyvale, CA 94086