[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnumed-devel] Re: patient searches (was: web frontend/patient singleton
From: |
Karsten Hilbert |
Subject: |
[Gnumed-devel] Re: patient searches (was: web frontend/patient singleton) |
Date: |
Mon, 14 Feb 2005 09:48:19 +0100 |
User-agent: |
Mutt/1.3.22.1i |
> >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/
That needs updating. The automatic updating still chokes on
wxPython to which no one apparently has an answer.
> 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.
Well, you look for a person with an intent. Likely the intent
of making it a patient. So, the before-the-fact state doesn't
matter, does it ?
> - when searching for persons, rather than having to search through
> two different GUI widgets
You search with the same widget.
> (depending on the kind of person one is
> searching for, patient or non-patient),
That doesn't make a difference.
> would it be practical to have
> options within a single widget which either
> a) permits the search to be constrained to patients or
difficult
> 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?)
That is surely imaginable.
Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346