Re: [Gnumed-devel] demographics editor

[J Busser]

At 3:17 AM +0200 9/16/04, Karsten Hilbert wrote:
> 2) declaring a special widget that doesn't need a patient to
>    be the mandatory widget being raised initially
>    - just doesn't feel right technically (special values should
>      be avoided where possible, not created),
>    - doesn't sit well with the idea of loadable plugins
>
> 3) take the design decision to *always* load a patient, even
>    before the user selected one

What do we currently (or what do we want to) store or cache at the 
end of any user's -- or client computer's--  GnuMed session?

I earlier suggested that if a patient were to be loaded automatically 
at log-in, it would make the most sense for it to be the patient who 
had been last accessed by that user. That could be determined most 
reliably from the server (which covers the case in which the user had 
moved to a different machine) although this is slower than to select 
the patient based on a locally (client machine side) stored value.

If the data pair (tuple?) {last user / last patient} is cached at the 
level of the client machine, and if the user logging in is the same, 
the "last patient" stored locally would be the actual last patient 
accessed by the user but only if they had not in the meantime logged 
in somewhere else but that could only be determined by querying the 
server. The decision of whether to ignore the locally stored patient 
value could be based on a stored preference that is either binary or 
could be elapsed time since last local logout.

If it is a *different* user logging into the local machine, then the 
locally-saved patient pk should be ignored, because it could confuse 
the user who at login (in a large practice) may not even recognize 
the patient who was being worked on by someone else not to mention 
potential privacy issues.

If no patient value had been stored on the local client machine, the 
widget could check whether the user had ever logged in
- if yes, query for whoever was their last patient accessed, and if 
they had never accessed a patient go to the next case (below)
- if no patient previously accessed, or never before logged in, query 
whether number of records in the patient database is zero. If zero, 
then find a clean way to not bother loading, and display/return a 
message like "Awaiting creation of GnuMed's first patient!" :)

If there are patients in the database, but if the user had never 
accessed any of them, it is hard to know if there is any relevance to 
choosing a patient in advance. I suppose for a new doctor joining the 
system, someone could have pre-scheduled a patient for the doctor to 
see and that could be the patient offered, But for non-doctors this 
would have no relevance, I suppose the system could identify and load 
whoever is the patient with the earliest upcoming appointment.