[Gnumed-devel] patient searches (was: web frontend/patient singleton)

[J Busser]

At 12:46 PM +0100 1/30/05, Karsten Hilbert wrote:
> gmPatient.py... should have been gmPerson.py.
> That is the reason why gmPatient.gmPerson is
> named like that: it is a person, not a patient. It only
> becomes a patient when you start requesting clinical data from
> it (eg. after the first request of get_clinical_record()).

I thought the above was being renamed (maybe postponed?)  as I still 
see gmPatient.gmPerson at http://salaam.homeunix.com/~ncq/gnumed/api/

Anyhow, when searching or viewing a list of persons, it is not clear 
how one would discern whether or not they are patients because 
whether or not a person is a patient depends on information not 
contained in identity, name and demographic tables.

Therefore:

- when searching for persons, rather than having to search through 
two different GUI widgets (depending on the kind of person one is 
searching for, patient or non-patient), would it be practical to have 
options within a single widget which either
a) permits the search to be constrained to patients or
b) displays whether the person has had any clinical contact (and if 
so, maybe some data about that contact such as the most recent date, 
type, and doctor involved?)

I imagine it will also be slower to have search results that depend 
on a combination of patient identity and demographic information on 
the one hand, and some clinical information (such as I suggested 
above) on the other hand. Yet is that likely to make up most of the 
searches yes, i.e. the searcher will want that combination of info 
anyway. Or do we think that performance constraints will cause people 
to prefer to identify the "likely" correct patient based on identity 
and demographics, and only then call up the clinical data (and reject 
if it is not the desired patient).