Hello Horst,
While EMail will work most of the time, its our experience that users
do want realtime delivery and the order of delivery is important as
well.
I frequently get the response to a post on this list before I have
seen the original, and sometimes it comes days later. EMail is
designed to be robust to network downtime etc and is simple, which is
good, however its not designed to be fast and its reliable if you can
afford to wait for days. (eg Backup Telstra mail servers wait for up
to 5 days before they resend messages!!!!!)
We frequently hear of people faxing results because its wanted NOW. If
I am talking to a surgeon about a patient I want to be able to send
him the histology, the ERCP report, the ERCP Images and the Liver
function tests while I have them on the phone and allow them the look
at it themselves. This is what is working on the Sunshine Coast now
and we could not do this reliably with EMail. I can appreciate that in
many cases urgency is not important, but if you have had realtime
messaging for a while the realtime ability is hard to give up.
Its all tcp/ip, but I don't think EMail is a format which which to
move forward in a connected world, Its a format to fall back on for
edge cases.
The EMail headers for the quoted message tell it all
----------------------
Received: from lon-postoffice.telstra.net (lnip-postoffice.telstra.net
[203.50.2.186])
by sv1.medical-objects.com.au (Postfix) with SMTP id 209A2C3F0
for <[EMAIL PROTECTED]>; Mon, 22 May 2006 12:29:32 +1000 (EST)
Received: (qmail 31091 invoked from network); 22 May 2006 10:37:33 +1000
Received: from 85-10-195-135.clients.your-server.de (HELO ozdocit.org)
(85.10.195.135)
by lon-postoffice.telstra.net with SMTP; 22 May 2006 10:37:33 +1000
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by ozdocit.org (Postfix) with ESMTP id 2C7CAEDC1CF;
Sun, 21 May 2006 11:34:33 +1000 (EST)
X-Original-To: [email protected]
Delivered-To: [email protected]
Received: from cic.net.au (unknown [66.249.3.236])
by ozdocit.org (Postfix) with ESMTP id 84D73EDC1CA
for <[email protected]>; Sun, 21 May 2006 11:34:31 +1000 (EST)
Received: from [192.168.1.139] (182.96.233.220.exetel.com.au [220.233.96.182])
by cic.net.au (8.11.6/8.11.6) with ESMTP id k4L1YTv19601
for <[email protected]>; Sat, 20 May 2006 18:34:29 -0700
----------------------
Andrew
Sunday, May 21, 2006, 11:34:26 AM, you wrote:
HH> On Sunday 21 May 2006 10:49, john dooley wrote:
>> Horst I didnt mean to imply you were against downloads. I also strongly
>> support standards based delivery and I totally agree with you on
>> everything except the bit about accessing my results delivery server
>> from outside with your own software ;) Would you let me access your
>> database from outside with my own software?
HH> Wrong question - because I do not advocate "accessing somebody elses
server".
HH> You stay away from mine, I stay away from yours, and we meet on neutral
HH> territory - with simple email as transport layer
HH> If we agree to a tried and proven protocol (email with SMTP for sending
HH> results / acknowledgements, and it is left to the respective side to decide
HH> whether they do the receiving end as POP or IMAP or whatever protocol)
HH> neither side ever has to worry about such things.
HH> Reports of any kind we use in medicine never depend on real time delivery,
so
HH> it is a no-brainer staying away from the problems of real time messaging
HH> protocols. And voila, we avoided all these security and stability issues in
HH> one single hit.
HH> If your database contains anything of interest for me, you can simply send
it.
HH> If you want to provide me with utmost comfort (ability to re-access past
HH> results, to search etc.) - see below for remote procedure call protocols
via
HH> http.
HH> If for whatever reasons we decide we need real time messaging of some kind,
it
HH> still wouldn't be a major problem if we'd use tried and proven SIMPLE
HH> protocols (like XML-RPC). Firstly, because you can then rely on tried and
HH> proven security mechanisms of your trusted http server for the transport
HH> layer, and secondly because you have a protocol that is very easy to lock
HH> down - because it is so simple. You are welcome to hit my XML-RPC services
HH> with anything you like - they will simply ban your IP number if you hit
them
HH> with incorrect / malformed requests too often, but you cannot compromise
the
HH> stability of my system by querying them (e.g. the drugref drug interaction
HH> service which was just a simple proof of concept gadget, got more than
10,000
HH> hits an hour during it's heydays from people testing it, and lots of hits
HH> from some morons trying to wiggle their way into my system, but it never
HH> caused ant trouble at all).
HH> Horst
HH> _______________________________________________
HH> Gpcg_talk mailing list
HH> [email protected]
HH> http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
HH> __________ NOD32 1.1551 (20060521) Information __________
HH> This message was checked by NOD32 antivirus system.
HH> http://www.eset.com
--
Best regards,
Andrew mailto:[EMAIL PROTECTED]
Andrew McIntyre
Buderim Gastroenterology Centre
www.buderimgastro.com.au
PH: 07 54455055 FAX: 54455047
_______________________________________________
Gpcg_talk mailing list
[email protected]
http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
