There will be a 'lock button' to achieve denying access. Also I think yours is a good idea, that at first login the general/status/inbox area be displayed. And I agree that we must for once and for all get rid of this defaulting to displaying the last patient. when you are finished with a patient the clinical record should be empty. If a search fails the clinical record should default to empty - not the last patient seen.
PS: Seems I'm the only one who routinely adds my name to the bottom of the comments. As the headers on a reply are sometimes snipped, I wish otheres would do it as I have difficulty seeing who wrote what. Perhaps its just little old dumb me. Richard On Thu, 10 Mar 2005 04:41 pm, J Busser wrote: > At 7:45 PM +1100 3/9/05, Ian Haywood wrote: > >AFAIK Richard's design would have two "Inboxes": one > >patient-specific, in the clinical > >tab, and a general mail client-like one as a top-level notebook tab (which > > of course shoud run standalone, &c) > > I would think it desirable that whenever one logs in, a person would > log into a general/ status area which would display numbers of > messages etc. I had believed it was already suggested overall that > when one logs in, it may be safer to NOT automatically activate the > last patient that had been accessed, it would be safer to have to > deliberately choose a patient. Of course, it would remain useful to > be able to access a *list* of the patients one had just finished > accessing. Not sure if that list is "lost" upon logging off or after > a timed auto-logoff if and when such a feature is enabled. > > A different feature that I have seen in some systems is the ability > to "park" the login. For example if, while in the midst of a patient > visit, one must leave the exam room, it is wise to be able to "park" > the system so that instance cannot be re-accessed without a password. > Here, if it can be asserted different than a true logoff, it would be > desirable to keep the last patient "active". > > > _______________________________________________ > Gnumed-devel mailing list > [email protected] > http://lists.gnu.org/mailman/listinfo/gnumed-devel _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
