[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] demographics editor

From: J Busser
Subject: Re: [Gnumed-devel] demographics editor
Date: Wed, 15 Sep 2004 20:25:46 -0700

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]