Re: [Gnumed-devel] demographics editor

[Richard Terry]

I find this whole debate interesting or should I say ridiculour,  for the 
following reasons.

Imagine you use a paper system. Before sitting down to your desk, you look up 
your manual appointment system and find out who the last patient was. Then 
you go to the file and get out their records. Then you take that file and sit 
at your desk. Next you look up who you really want to see next. You then go 
and get out their records etc.et etc

This whole business of pulling in either 'anyone' or the last patient seems 
ludicrous to me. Why on earth would you want to to it. I cannot think of a 
situation where I've ever wanted either a random patient, or the last patient 
I've just seen when I first boot up my program. How confusing for users.

The system should surlely act simply to respond to the users inputted request 
and pull up the requested patient or list multiple occurrences of the search 
criteria.

Regards

Ricahrd

On Thu, 16 Sep 2004 01:25 pm, J Busser wrote:
> 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.
>
>
> _______________________________________________
> Gnumed-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnumed-devel