Sam, Unfortunately, I was leaving Argus for last in my absorption process. My only comment based on what I have read, is that you appear to be erecting a lot of superstructure that already exists in IMAP (the database in particular). Gavin's quote is operative here:
"The goal of software re-use has driven a trend towards object-oriented cross-platform components. Whenever previously developed software can be re-used without going back to the program code system development ought to accelerate [Brooks 1995]. Healthcare institutes that successfully adopt the components within Internet browsers and Intranet servers would demonstrate exemplary re-use." You say, in your documentation, one thing that, to me, shows how upside-down things have gotten. You say that "power users" will take advantage of the HL-7 attachment to, presumably, produce an automatic connection to another computer system. I think that, upon reflection, the "power users" of a clinical computing system are the providers who take the best care of their patients. What's more, no message in any clinical computing system achieves any power at all until it reaches the cerebral cortex of a provider. And, I submit, in order to reach the cortex, it must be in natural language/numbers. There is an inherent tension in current "messaging" protocols such as HL-7. On the one hand, HL-7 was born out of the realization that the lab computer had to talk to the user interface computer. On the other hand, vendors want to keep their black boxes separate, and certainly don't want to share too much. That's where we are today. It's where we've been, without progress, for many years. The only counter example is VISTA/CPRS which is about the same vintage as SABRE. I would say that if Argus embraced IMAP technology, centralized the database, and called itself a record system, it would sweep the field (I'm still absorbing and may take a future opportunity to be more specific). And I think that you, not I, have clearly demonstrated that that can be done in complete compliance with all current messaging, etc. standards. You have shown that HL-7 is just another MIME-type. Thanks for the Interbase reference. One would grow old and die before one found a reference to it on the Borland site. John >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 >> >> >>
