[Gnumed-devel] gmReferrals.py - lengthy comment

[Karsten Hilbert]

> 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 
> flexible.
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 
> have 
> 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
appropriately date-stamped.

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), 
> the 
> 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:

table config_item:
 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 
> via 
> 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
appropriate options.

> I've left off the 'Department/branch label. If we are going to allow on 
> screen 
> editing this will need to be included.
Or display even less and branch out if necessary.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346