John Gage wrote (in a message containing both text/plain and text/html MIME types): > This is not exactly the paradigm I have in mind. The "patient" is > actually an account on an IMAP server that, usually, only receives > messages. The administrator of an LDAP server grants GP's and other > care-givers access rights to view various mail folders on the IMAP > server belonging to the "patient's" account: GP's get full access, > patients get access only to the patient instruction folder, etc. > > The "patient" account would *automatically* send a message to certain > recipients: notification of an allergy or drug interaction, > prescription to a pharmacy, for example, but these events are very > well defined and limited in number. > > In general, however, the care-givers would send messages to the > patient: GP "A" wishing to write a progress note on patient "x" uses > her/his client to create a message addressed to > "x:[EMAIL PROTECTED]". Because there is a template > for this message and some script that creates a bill, for example, the > message is multi-part and puts the various parts into the appropriate > folders. Note that, in this case, a duplicate of the message is, in > fact, created on the physician's client, which is probably > appropriate. Same thing for labs, etc. > > In each case, both for the server and the client, each box, no matter > what it is, also has a mail transfer agent on it (preferably Exim) > making it so the headers can be encrypted and the message is worthless > to someone intercepting it. It really is an e-mail system that can > run on the Internet, but be in parallel with it.
OK, now I am beginning to get a better idea of the idea you are pursuing. It might be worth collecting your (interesting and worthwhile) thoughts into a discussion paper - it is becoming a bit difficult to follow all the threads of thought relating to your concept. Reading your description above, I was immediately struck by parallels with software support systems - maybe health care systems are really just biological wetware support systems? Consider each patient as a "software product", with various bugs and problems with the product being identified and tracked to resolution (or until the product is withdrawn or sold to another vendor?), with various experts advising or prescribing corrective or mitigating action. Thus it might be worth looking at software support systems for some insights: Such systems accept input in a number of ways - almost always via e-mail, but also via a Web interface and sometimes a dedicated client-server GUI. Each problem or issue is assigned (somehow) to one or more persons who are then responsible for dealing with the problem. Most systems allow rules to be defined which send automated (usually email) alerts to interested parties when certain events occur (eg "closing" a problem"). Various management reports can be created eg lists of all unresolved issues. All information relating to each issue is grouped into a "thread", presented in reverse chronological or other orders. Some systems allow a single running summary for each thread to be maintained as well. Details (including an excellent overview) for an open source software support system can found be http://roundup.sourceforge.net Roundup implements the great idea of "nosy lists", although I am not sure how these might work in an EHR context. We are seriously looking at Roundup to manage public health issues (which is a different problem to patient-specific EHRs). Tim C
