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

[Karsten Hilbert]

> > 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;
>   1017
> gnumed=# select count(distinct substring(lastnames,1,2)) from names;
>    157
> 
> 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.
Absolutely. That's why I introduced the thresholds into the
match provider which I showed to Ian and discussed with
Richard:

threshold 1:
 - if substring has this many characters -> find only
   phrases that start with the substring
threshold 2:
 - find only phrases that have a word starting with the
   substring
threshold 3:
 - find phrases that have the substring anywhere, even inside
   words

These thresholds need to be very different for different input
fields:

A patient search field will likely require higher thresholds
as you point out.

A context-dependant field (say, referral target doctor) will
likely require rather low thresholds.

> 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)
Good idea.

> > | postcode : ___________________________[v]  |
> > | street   : ___________________________[v]  |
> > | suburb   : ___________________________[v]  |
> > |
> > | street2  : ___________________________[v]  |
> > | street3  : ___________________________[v]  |
> 
> Instead of street2, street3 I would definitely go for a multi line text 
> control.
Duh ! Of course ! Didn't think of that.

> 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
Well, sure, Richard also made some good points why it may be
Good to have the same widget for _display_ and _editing_
patient details.

However, I still think it quite beneficial (and I am
thinking of our receptionists) to have a super-efficient
widget for entering _new_ patients. One could, in parallel to
entering data, fill up the "normal" widget displayed next to
the entry form.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346