Gavin's paper, Brian's Picnic project, and Sam's Argus project contain a large quantity of reading material. Large as in a 169 page Word document for Picnic alone. I have not absorbed this material yet :-)
During the absorption process, I would like to introduce another punch line: this list can create the basic templates and attachments that would underlie 98% of the medical record. After all, this list is a series of e-mail messages and there's no law that says that a portion of these messages cannot be examples of the kind of messages/documents/reports/notes/etc. one would want to find in a medical record stored on/beside an IMAP server. I will post a few samples soon. My other thought during absorption is that the person who I would dearly love to interest in e-mail applied to medical record keeping is Philip Hazel (http://freshmeat.net/~ph10/), who created Exim. It would seem to me that he, or his designee, would be the fellow to take on the non-domain stuff that the world of HIPAA will be looking carefully at. Seeing that Philip is in Cambridge, would one of the British members be interested in talking to him or having him talk to us? Just a thought... And a quick question about Argus. Interbase does not seem to be either a) open source or b) free. As someone who bit about as hard as a human being can bite on the Java hype (I have switched to Perl), I respect those who are using Java, but Interbase doesn't even seem to claim any relation to open source. Am I missing something? John >Dear All > >I have been involved in an effort to achieve some of what you are talking >about in the list - and also in the effort to ensure that the work is >opensource. > >http://www.ballarat.edu.au/cceh/Argus/ > >It is a project in AUstralia to set up a clinical encrypted email service >which is based on an interbase server - the server is the POP client for as >many addresses as required. The client looks like an email client but works >from the database - email forwards and copies are all virtual - and there is >a tracking mechanism. Automatic processing - export from the server to >applications can be enabled and an API is being developed at present for >communications in the other direction. > >The site is the Collaborative Centre for eHealth and the Division of General >Practice >www.tedgp.asn.au >here in Darwin is the fundholder of the grant. > >Cheers, Sam > > > > >> -----Original Message----- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED]]On Behalf Of Tim Churches >> Sent: Wednesday, 22 May 2002 5:18 AM >> To: [EMAIL PROTECTED] >> Cc: [EMAIL PROTECTED] >> Subject: Re: More on Re: Medical messaging using e-mail >> >> >> Adrian Midgley wrote: >> > >> > On Monday 20 May 2002 20:34, Tim Churches wrote: >> > >> > > OK, sorry, I missed that last part: >> > > > > It has total control of who it talks >> > > > > to and what path it uses to transfer mail. >> > >> > This is important... _total_ >> >> I'm not convinced of this (see below). >> >> > >> > > a) If Dr A sends a message to Dr C via Dr B's mail server, Dr >> A probably >> > > doesn't want Dr B to be able to read the message to Dr C >> > >> > So don't do that! >> > >> > > b) How will these special purpose routing tables be maintained? Easy >> > > when there are >> > > only 10 mail servers, not so when there are 1,000 or 10,000. >> > >> > DNS >> > >> > SMTP is used in two ways. Routinely. >> > Small dial-up systems tend to use SMTP - relay, where they pass on tehir >> > messages to a smarthost which then relays them... >> > >> > Larger always-on systems, or mine if I flick the switch, >> usually use Direct >> > SMTP >> > >> > In this case they look up the Mail eXchanger record in DNS >> (which could be a >> > collegiate DNS, or a private one, it doesn't have to be public) for the >> > recipient, and connect to it and pass the mail file to it. > > > > Yes, but surely the MX (mail exchange) records in the DNS for the target > > (recipient) mail server > > are under control of whoever administers that mail server, and are not > > under the control of the sender? >> >> To use the example above: >> >> Last week, the DNS MX record for Dr C's mail address pointed >> directly to Dr C's mail server located in her offices. Dr A felt >> perfectly safe in discussing >> the botched hemicolectomy performed by Dr B on one of her patients in an >> email message to Dr C. >> >> This week: Dr C's mail server has suffered a software melt-down (it was >> running proprietary software...), >> so Dr C changes her MX record to direct messages to Dr B's mail server >> while she converts to a more >> reliable open source server solution. She plans to pick up her mail from >> Dr B's server. Dr A sends Dr C another >> message complaining about a hamfisted sigmoidoscopy performed by Dr B on >> another of her patients. Meanwhile, >> Dr B thinks that something might be wrong with the configuration of his >> mail server, and being a surgeon, >> he cant't stop himself from digging around in the guts of sendmail. >> While doing so, he innocently stumbles >> across the stored message from Dr A to Dr C which calls into question >> his competence with the scalpel and the `scope. >> Oh dear! His ego wounded, Dr B initiates divorce proceedings against Dr >> A (to whom he is married). Another medical >> marriage on the rocks! >> >> A contrived example, but the point is that DNS-based routing is under >> the control of the recipient, not the sender. >> >> > >> > I think the story about having no control over where messages >> go is actually >> > FUD, probably spread about by X.400 vendors or users, since the >> controlson >> > path for SMTP and X.400 are not that different - IE if you are >> using a chain >> > (not obvious since your smarthost probably spends all day doing >> Direct SMTP >> > to destination mailservers) the route on from each machine is >> dependent on >> > the good judgement of the owners and administrators of that >> machine, and why >> > owuld the previous link choose them if it didn't know and trust >> them. It >> > isn't random. >> >> I agree that X.400 based systems are not necessarily any different in >> this respect. >> I used the word different not better, because I don't think there is >> anything wrong >> with the currenet DNS system - it is difficult to conceive of a workable >> system which >> would allow the sender to completely determine the physical routing of >> messages, rather >> than the recipient. >> >> Of course, all of the above discussion relates to the upper levels of >> the network. >> The route which the TCP/IP packets which actually comprise the message >> being >> transferred is another matter entirely, and you have even less control >> over their routing. >> Those packets can be "sniffed" very simply at every router involved. >> Thus, encryption of >> the payload of those packets is still essential even when the message is >> transferred directly >> from Dr A's mail server to Dr C's mail server - the packets involved >> still go via other people's >> routers and networks. >> >> Tim C >>
