[Top][All Lists]

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

Re: [Gnumed-devel] Mock up of Potential Patient Data Entry screen

From: Horst Herb
Subject: Re: [Gnumed-devel] Mock up of Potential Patient Data Entry screen
Date: Thu, 9 May 2002 11:16:54 +1000

On Thu, 9 May 2002 01:32, Karsten Hilbert wrote:

> 1) I type the last name (auto-completion) - possibly
>    word-wheeled to a query
>    "SELECT unique(last_name) FROM PERSON"

gnumed=# select count(distinct lastnames) from names;
(1 row)

For my miserable 3000+ patients in Dorrigo I have already 1000+ distinct 
surnames :-(

gnumed=# select count(distinct substring(lastnames,1,2)) from names;
(1 row)

With two characters typed in already it starts making more sense, as for 
any combination of two letters it will always be only a a few - but 
unfortunately rarely only one

Thus, I would not start the word wheel befiore the third character has been 
typed in otherwise we would be very wasteful with ressources.
Otherwise, depending on the number of patients, we would need to set the 
number of chars to be typed before the word wheel loads from the database 
based on individual database statistics (just run a few count(distinct 
...)) whenever you  start the client)

> | postcode : ___________________________[v]  |
> | street   : ___________________________[v]  |
> | suburb   : ___________________________[v]  |
> |
> | street2  : ___________________________[v]  |
> | street3  : ___________________________[v]  |

Instead of street2, street3 I would definitely go for a multi line text 
control. No need to clutter the ecreen with rarely used input widgets, and 
no need to limit ourselves to only two additional lines either. I hate it 
when an input form deprives me of the flexibility of paper - especially 
when the underlying database structure allows that degree of flexibility

> Of course, this "design" does not lend itself well to
> displaying of patient details. Neither is it the best possible
> interface for later editing of patients.

I don't think we should fall back to "modal" behaviour of entry / display 
widgets unless there is an outstanding benefit. The user should always be 
able to edit data in the widget that displays the data, otherwise it gets 
too complicated for most computer naive users


reply via email to

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