Re: Argus usefulness, was Re: Learning from Argus, Re: How to kill open-source project via funding, was Re: Argus correction

2003-12-21 Thread Andrew Ho
On Sun, 21 Dec 2003, Richard D Piper wrote:
...
 |   Specifically, what are the benefits of inter-connecting distributed
 | systems via email messages instead of https, for example?

 I think either solution would work.

Richard,
  If either approach is acceptable to you, my preference is to go with
https. There are just so many more tools and systems that will be using
https (to transport XML).

 They are both simple methods to transmit patient data, in the absence of
 a state of the art electronic health record.

  As I understand it, Argus is also meant to inter-connect diverse
electronic health records systems currently in use in Australia? In any
case, I anticipate all free EMR systems will be accessible over https
anyways (actually, that may already be the case).

 Unfortunately, although email and https are consumer technologies,
 PKI/PKC have not reached that status,

The current standard appears to be username-password pair for
authenticating client-systems and SSL/certificate for servers -- over
https encrypted link.

Since this is good enough for banking, I suspect it is fine for health
information too. Client-side certificate is just too much of a hassle for
most people to use.

 I have not used Argus, but it seems to be trying to address this problem
 with respect to email. I doubt it has a chance of being successful
 unless it becomes an opensource/open standard 

I doubt it. Even if Argus is free/open source, I doubt there will be much
interst for it in the U.S..

 An advantage of an https approach is that the software (except for the
 ssl related client) is maintained centrally on a server,
...

You bet - and when we tell our patients and administrators: OIO uses the
same security as used by banks - they feel very secure.  Email evokes
thoughts about virus and spam. :-)

Best regards,

Andrew
---
Andrew P. Ho, M.D.
OIO: Open Infrastructure for Outcomes
www.TxOutcome.Org



Re: Argus usefulness, was Re: Learning from Argus, Re: How to kill open-source project via funding, was Re: Argus correction

2003-12-21 Thread Tim Churches
On Sun, 2003-12-21 at 21:19, Richard D Piper wrote:
 An advantage of an https approach is that the software (except for the
 ssl related client) is maintained centrally on a server, and a remotely
 installed application (such as argus, which looks complex), does not
 need to be installed and maintained. Just imagine the problems that
 could occur with ensuring that version of a particular JVM's on the
 workstations of 12,000 GPs throughout Australia.

Sure, but HTTPS browser-to-web server communication assumes that the
practice is always connected to the Internet, which is usually not the
case. It is the ubiquitous store-and-forward, asynchronous messaging
infrastructure provided by SMTP email which makes it an attractive
target. Also, Argus targets automated information exchange between
applications, and browsers are not good automation targets, although the
HTTPS protocol can certainly be used for automated data exchange (but
each application then needs to handle its own store-and-forward
buffering, unlike the SMTP infrastructure, which handles it for you). Of
course, the Jabber protocol offers both synchronous and asynchronous
messaging, and as Horst Herb has said (elsewhere), would be a better
choice for healthcare secure messaging (with an encryption layer added).

-- 

Tim C

PGP/GnuPG Key 1024D/EAF993D0 available from keyservers everywhere
or at http://members.optushome.com.au/tchur/pubkey.asc
Key fingerprint = 8C22 BF76 33BA B3B5 1D5B  EB37 7891 46A9 EAF9 93D0




signature.asc
Description: This is a digitally signed message part


Re: Argus usefulness, was Re: Learning from Argus, Re: How to kill open-source project via funding, was Re: Argus correction

2003-12-21 Thread Horst Herb
On Sun, 21 Dec 2003 20:56, Andrew Ho wrote:
   Specifically, what are the benefits of inter-connecting distributed
 systems via email messages instead of https, for example?

Because we *don't* have distributed systems. Interoperability of systems in 
Australia is very close to zero.
All we can hope for at present is to exchange messages in some format most 
systems will understand (HL7), and the transport of these messages needs to 
be secured AND *users* (not necessarily systems)  need to be authenticated.

Horst
-- 
On two occasions I have been asked [by members of Parliament!], 'Pray, Mr.
Babbage, if you put into the machine wrong figures, will the right answers
come out?'  I am not able rightly to apprehend the kind of confusion of ideas
that could provoke such a question.
-- Charles Babbage



Re: Argus usefulness, was Re: Learning from Argus, Re: How to kill open-source project via funding, was Re: Argus correction

2003-12-21 Thread Andrew Ho
On Sun, 21 Dec 2003, Tim Churches wrote:
...
 Sure, but HTTPS browser-to-web server communication assumes that the
 practice is always connected to the Internet, which is usually not the
 case.
...

Tim,
  Browser-to-remote web server is not the only possible architecture when
using HTTPS. We can also deply Browser-to-local web server-to-remote web
server. The local web server can provide store-and-forward function.

Best regards,

Andrew
---
Andrew P. Ho, M.D.
OIO: Open Infrastructure for Outcomes
www.TxOutcome.Org



Re: Argus usefulness, was Re: Learning from Argus, Re: How to kill open-source project via funding, was Re: Argus correction

2003-12-21 Thread Horst Herb
On Sun, 21 Dec 2003 21:47, Tim Churches wrote:
 buffering, unlike the SMTP infrastructure, which handles it for you). Of
 course, the Jabber protocol offers both synchronous and asynchronous
 messaging, and as Horst Herb has said (elsewhere), would be a better
 choice for healthcare secure messaging (with an encryption layer added).

Especially since you can easily run XML-RPC (remote procedure calls) via 
Jabber in the most elegant and fail proof way (including store-and-forward 
for remote procedure calls!). This allows sort of distributed systems even on 
the unreliable and slow connetions we have in most of Australia.

Horst
-- 
On two occasions I have been asked [by members of Parliament!], 'Pray, Mr.
Babbage, if you put into the machine wrong figures, will the right answers
come out?'  I am not able rightly to apprehend the kind of confusion of ideas
that could provoke such a question.
-- Charles Babbage



Re: Argus usefulness, was Re: Learning from Argus, Re: How to kill open-source project via funding, was Re: Argus correction

2003-12-21 Thread Andrew Ho
On Sun, 21 Dec 2003, Horst Herb wrote:

 On Sun, 21 Dec 2003 20:56, Andrew Ho wrote:
    Specifically, what are the benefits of inter-connecting distributed
  systems via email messages instead of https, for example?

 Because we *don't* have distributed systems. Interoperability of systems in
 Australia is very close to zero.

Horst,

  I make use of web-based email services and they work quite nicely.
Perhaps that could work well in Australia too?
  Each physician (using web-browser or their EMR) can log-onto a web-site
(via https) to retrieve messages meant for them and/or their EMR (via
attached HL7 messages).  There can be more than one such web-sites - in
which case they can swap email messages. These web-base email systems are
quite well developed.  UCLA happens to use IMP, from the GNU Horde project
(http://horde.org/imp/). It can probably be easily modified if Australia
needs something special.

  How is Argus better than this?

Best regards,

Andrew
---
Andrew P. Ho, M.D.
OIO: Open Infrastructure for Outcomes
www.TxOutcome.Org



Re: Argus usefulness, was Re: Learning from Argus, Re: How to kill open-source project via funding, was Re: Argus correction

2003-12-21 Thread Tim Churches
On Sun, 2003-12-21 at 21:40, Andrew Ho wrote:
 The current standard appears to be username-password pair for
 authenticating client-systems and SSL/certificate for servers -- over
 https encrypted link.

The main problem with simple username/password pairs, HTTPS
nothwithstanding, is the need for the client to prove his or her
identity to **each** server **every** time the user's password is
negotiated or re-negotiated. Such proof needs to be conducted
out-of-band to be secure. That kight be acceptable when you are dealing
with one server, but typically you would have to deal with tens or
hundreds in the course of normal interaction with the health care
system. PKI (including the GPG web-of-trust system) is much more
scalable. Username/passwords might be OK in a highly centralised system
like the UK NHS, but I can't see it being viable as the universal
solution to security and authentication here in Australia, where things
are much more distributed and organisations more discreet. 

 Since this is good enough for banking, I suspect it is fine for health
 information too. Client-side certificate is just too much of a hassle for
 most people to use.

Most people deal with only one or two banks at a time, whereas most
health practitioners deal with dozens of organisation, and specialist
physicians with hundreds (since each GP is effectively a different
organisation). That's a big difference between health care and banking.

-- 

Tim C

PGP/GnuPG Key 1024D/EAF993D0 available from keyservers everywhere
or at http://members.optushome.com.au/tchur/pubkey.asc
Key fingerprint = 8C22 BF76 33BA B3B5 1D5B  EB37 7891 46A9 EAF9 93D0




signature.asc
Description: This is a digitally signed message part


Re: Argus usefulness, was Re: Learning from Argus, Re: How to kill open-source project via funding, was Re: Argus correction

2003-12-21 Thread Tim Churches
On Sun, 2003-12-21 at 21:49, Andrew Ho wrote:
 On Sun, 21 Dec 2003, Tim Churches wrote:
 ...
  Sure, but HTTPS browser-to-web server communication assumes that the
  practice is always connected to the Internet, which is usually not the
  case.
 ...
 
 Tim,
   Browser-to-remote web server is not the only possible architecture when
 using HTTPS. We can also deply Browser-to-local web server-to-remote web
 server. The local web server can provide store-and-forward function.

Which web server is that? I bet you are going to tell me that with extra
programming to make it do so, any web server can provide store and
forward functions for applications which need to communicate with each
other. Well, in anticipation, yes, but isn't that what email systems and
other purpose-built messaging platforms (like Jabber) are for?
-- 

Tim C

PGP/GnuPG Key 1024D/EAF993D0 available from keyservers everywhere
or at http://members.optushome.com.au/tchur/pubkey.asc
Key fingerprint = 8C22 BF76 33BA B3B5 1D5B  EB37 7891 46A9 EAF9 93D0




signature.asc
Description: This is a digitally signed message part


Re: Argus usefulness, was Re: Learning from Argus, Re: How to kill open-source project via funding, was Re: Argus correction

2003-12-21 Thread Horst Herb
On Sun, 21 Dec 2003 22:08, Tim Churches wrote:
 The main problem with simple username/password pairs, HTTPS
 nothwithstanding, is the need for the client to prove his or her
 identity to **each** server **every** time the user's password is
 negotiated or re-negotiated. Such proof needs to be conducted

There is a solution to even this - ssh-agent (see OpenSSH documentation or 
do a man ssh-agent if you are using a Linux/BSD/MacOSX system).

 I use it for accessing my surgery server from the hospital via remote X 
sessions.

In theory, each application I start remotely needs authentication.
In practice, ssh-agent does this for me. Currently, it times out after 10 
minutes or whenever the screen saver kicks in. But it is trivial to 
configure it so that it works as long as a USB memory stick is plugged in, 
and you can tie the stick to your belt etc.

Horst

-- 
On two occasions I have been asked [by members of Parliament!], 'Pray, Mr.
Babbage, if you put into the machine wrong figures, will the right answers
come out?'  I am not able rightly to apprehend the kind of confusion of ideas
that could provoke such a question.
-- Charles Babbage