[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnumed-devel] gmReferrals.py - lengthy comment
[Gnumed-devel] gmReferrals.py - lengthy comment
Sat, 3 Aug 2002 15:50:36 +0200
> This module has always worked brilliantly in my medical records program, but
> I'd like to make the following comments. The 'For' line exists because in
> australia we have certain regulations about referrals to specialist. it can
> be 'an opinon', 'continuing management', 'indefinate referral', to which I
> added things 'feedback' 'education' (eg where referring to a diabetic
> education service etc', and one would also add 'legal report...' etc. Very
Same here: we have For: "do some designated procedure",
"specialist opinion" and "continuing/accompanying management".
The form itself has a bunch of additional fields such as
"curative" vs. "prevention", "related to accident", "off-work
until", "task/diagnosis/suspicion" (free text field) ... The
latter is rather very small and not suitable for any
noticeable amount of information. So, usually we write an
accompanying referral letter if more than a trifle needs to be
said. There should be the possibility to print a letter as
well as the form. Most of the information is the same apart
from the content of the letter. In case a referral _letter_ is
generated the form might just contain the diagnosis + "see
referral letter" in the aforementioned field.
> 1)It was originally designed to allow full entry of a new
> organisation/person/clinic etc. What happened was the program when faced with
> a non-existant person added the person, checked in the organisation existed,
> if it did, linked the person to the organisation, or created it first if non
> existant. One has to fill in a category if non existant.
This functionality is very useful and is one of the strong
points of the software my parents use. I wonder, however,
whether it wouldn't be better to branch to the pertinent part
of the GUI for adding a contact (actually, in an ideal world,
this would the the user-level contact manager outside GNUmed).
> One can search by doctor surname and up pops the pick list, or search by
> category eg if one types in Surgeon, all the surgeons pop up and you select
> the one you want. If a person/organisation has more than one address, the
> default (more commonly used - weighted) address pops into the text boxes, but
> if one clicks on say the street line, up pops a list of all the other street
> addresses which exist for this person/organisation and one can scroll down
> and select one. Additionally one should be able to search on this screen by
> say typing in the postcode, then the category say surgeon and up will pop a
> list of only the surgeons in that postcode, similarly one could type in a
> town and up will pop the names of all the surgeons in that town.
"Must" haves and very useful !!
> Q)Do you think the on screen editing should be allowed, or should we just
> a single street line, and only allow entry of person and organisation details
> via the contact manager?
Yes, but we should allow immediate jumping from here to the
contact manager without further deviations.
> 2)This format allows this 'referrals' section to also carry out the function
> of writing reports, legal letters etc for the patient.
May I suggest two modes for the "details" section:
"Default letter" pulling in predefined data from a predefined
period of history with the entries appropriately date-stamped.
"Customized letter" popping up a succession of lists from
which to select data for the letter. Entries again
The referral letter itself should be a
template that can be changed by the user.
> 3) Referrals_savedletters.png shows the result once the letter is saved. My
> code created a rich text file and saved it with the specialists
> name/organisation name and date.
This can be stored as a patient-linked BLOB, no problem. An
arbitrary number of text fields may be associated with a given
BLOB to accomodate structured auxiliary meta-data, a digital
signature, whatever. In fact, this way it doesn't really
matter what format the letter is in.
> 4)Where the letter is short, as in the example shown here (referrals.png),
> area under the editing area suffices. Where a longer letter, or where one
> wants to edit the pre-formatted clinical data e.g delete a non relevant part
> of say family history or past history, then clicking preview shows the letter
> full page and one can type/edit at will.
This might link to AbiWord, LyX, mc, or whatever the
preferred word processing mechanism is.
> 5)Default behaviours need to be configured eg always set the firstname
> checkbox if you want the letters to automatically say 'Dear fred, instead of
> Dear Doctor Whatsyourname.
This is where the "cookie" field in the config table comes into play:
user - gnumed user
machine - well, not relevant here
option - "address colloquially"
cookie - "gmDoctor.id where name == a_particular_doctor"
value - true
type - boolean
That's why I "invented" the cookie field. Of course, one
could also tag doctors as friends but then how do you deal
with many-to-many relationships if you have several local doctors
using one GNUmed installation.
> 6). The Save and print icons on the patients tool bar will always be context
> sensitive. ie when in the referrals section and one clicks print, it just
> prints the letter, not any other outstanding say scripts, requests etc.
Ah ! Good. The button should have another mode, too, that
invokes a list with all outstanding printouts for _this_
patient with a hotkey to convert to listing outstanding printouts
for all patients.
> 7). In this electronic age one also needs the facility to email the letter
> say a context sensitve email button on the top bar (which I'll have to stick
> on) - hey - we could have a built in email client - I know there is a project
> going to have one in wxPython!!) on another tab
I am not sure that's such a good idea. Why not process mail
with your standard mail client invoked from within GNUmed with
> I've left off the 'Department/branch label. If we are going to allow on
> editing this will need to be included.
Or display even less and branch out if necessary.
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346