Dear John Here is the opensource material - Modzilla lisence: http://sourceforge.net/projects/interbase
The content of the sort of documents you are trying to do is not simple. You are pushing for a solution that will cut right across all standards work at the moment - perhpas this is appropriate - but we have been working for years in GEHR/openEHR to achieve this and are now having some success. I would argue that you probably have to use HL7 CDA or GEHR/openEHR at the moment to do this in a generic way. It is our hope that we will extract data and send it via Argus in the way you have described but the problem is a large one and not easily solved. You can create GEHR/openEHR compliant XML files with perl and display them as HTML in the DSTC GEHR/openEHR viewer. Contact [EMAIL PROTECTED] - he is leading the Titanium team who are doing the technical work. Good luck - Sam > -----Original Message----- > From: John Gage [mailto:[EMAIL PROTECTED]] > Sent: Friday, 24 May 2002 6:25 AM > To: [EMAIL PROTECTED] > Subject: Medical record keeping using e-mail protocols > > > 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 > >> >
