gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] secure messaging


From: Horst Herb
Subject: Re: [Gnumed-devel] secure messaging
Date: Thu, 8 Sep 2005 21:38:03 +0000
User-agent: KMail/1.7.2

On Thu, 8 Sep 2005 20:56, you wrote:
> Wagtail, if I understand correctly, is intended to address all these
> issues. I think the idea is to complement ArgusConnect and provide even
> more choice for open secure health messaging, rather than to try to
> usurp ArgusConnect. Indeed, it would be great if ArgusConnect (the
> company) eventually provided commercial support contracts for Wagtail as
> well as for their own software product. The real targets are the
> proprietary health messaging providers.
>
> A secondary goal is, I think, to demonstrate that "good enough" health
> informatics facilities can in fact be created and deployed at very
> modest expense - all that is needed is some vision and some smarts, but
> not necessarily a lot of time or money.

That about sums it up
 How it is intended to work:
1.) messages dropped into an "inbox" directory (either by our GUI, or even a 
proprietary program) are polled, parsed for sender / receiver addresses, 
2.) depending on that information, the appropriate keys for the appropriate 
encryption / signature method (X.509, OpenPGP) are fetched automatically form 
a specified LDAP server, in most cases without any user interaction
3.) the message is then encrypted with the receivers public key, optionally 
signed with the sender private key, and sent via specified transport 
(currently only email, but other transport methods considered)
4.) the system keeps track of sent messages and tries to account receipt 
acknowledgements, notifying the user about missing acknowledgements and/or 
resending automatically when ACKs are missing
5.) the system fetches incoming messages, decrypts them, verifies signatures, 
parses them (e.g. PIT format, HL7 format *.doc, rtf etc) and puts them into 
an "inbox" directory in an XML based meta format
6.) in most cases, a process will import those messages into an EHR system, 
but a GUI allows to read these messages similar as in an email client, and 
that GUI also allows to review non-parsable messages etc. 

The point is that in most cases, all a secretary or health professional has to 
do is save messages from whatever message composing program he is using into 
a specified directory. If using a non-structured format (e.g. doc), they'll 
have to use templates to facilitate parsing of sender/receiver, but otherwise 
they don't have to worry about keys, encryption, signatures, key servers etc 
- everything is handled fully automatically if possible without any human 
interaction.

Horst




reply via email to

[Prev in Thread] Current Thread [Next in Thread]