[Gnumed-devel] still having a hard time with address input and Search

[Jim Busser]

'Search' continues to bother me.

While I did think the earlier comments (re: 'like' being "unimaginative and 
untranslatable") to be a tad harsh, they did motivate me further into 
soliciting offlist input ...


On 2011-09-22, at 9:17 AM, M wrote:

> Hmmm
> 
> An address search for me would either:
> 
> Help me find existing addresses like google maps does (searching outside of 
> my EMR)
> 
> Help me find addresses based on building names (e.g. Shady Oaks Retirement 
> Home)
> 
> I can see that this particular version of search is an easy technical 
> solution that provides some value, particularly for families with the same 
> address. I think there is an issue if you want to use this to partially 
> populate addresses that are similar.  i.e. you then have to re-confirm 
> address and postal code and that is about as much work as typing it in de 
> novo.
> 
> I have seen this implemented differently: at the family level.  When adding a 
> new patient you can link them to other family members and then say if they 
> are living at the same location. This does two things:  links families, which 
> could have some advantages and reduces duplicate entry. I think this is a 
> better solution and fits the most typical use case of shared addresses:
> 
> Adding in families of patients into a record.


> Response #2
> 
> I think "near" is challenged from a user workflow perspective.
> First they have understand the process / what "near" does and doesn't do – 
> but the same is true for Search.
> Next, they have to then select whatever was "near" (or Searched / found) and 
> then modify it. Modifying is probably slower than just direct entry.
> 
> Especially if the system has good defaults.  Most patients will be from a 
> local catchment area, so City, Province, and Country could be defaulted.
> 
> You could suggest having postal code auto populate street, city, province - 
> that might be helpful and would reduce errors in entry.
> 
> My last parting thought is: I don't know how much of an issue this data entry 
> is to office staff. Maybe it isn't a problem [that] needs to be fixed. How 
> often is "search" being used? Are staff complaining about having to look up 
> addresses / postal codes?

So here are my thoughts after more reflection:

1. The problem with Search is that you cannot pick a limited level of 
resolution of a postal code, i.e. you cannot avoid to pick a number and unit, 
even if they are wrong. So unless an exact match is available (or unless the 
number and unit would remain the default null), it becomes a waste of time and 
a risk to leave wrong information in the fields. An additional colleague to 
whom I showed this, was quite concerned that it is too easy to keep (save) 
wrong information. Either the number and unit should default empty, or Search 
should be renamed

        Same as

and used purely in that scenario as in the case of co-habiting people.

2. Except in the case of exact matches, post-match modification will be 
required and will involve the number and the unit, but the current layout 
requires to tab through the already-matched postal and street to get to these.

(i) Can we reposition the postal field below the Place / Community and even the 
Region?

(ii) can we swap the positions of the Street row and the Number / Unit row? 
This would place number / unit immediately below Search. It also matches 
english convention (UK, Canada, AU, US, Israel, China, Taiwan, Hong Kong) where 
we always speak our addresses as

        number, street
not
        street, number

but I recognize this is the opposite to european (including romance language) 
countries and Russia. Does the european convention "win" or is there some way 
for the conditionality to be supported in a preference, so that it does not 
have to be locally hacked every time there is an update?

3. Postal (if it exists) is more important to choose than street, because it 
can avoid a keyboard error in the postal / zip code which is probably of more 
consequence than keyboard error misspellings in a street name, and because 
filtering on postal still makes possible the selection of an exact number (and 
unit) on the street when the desired values already exist.

We should really drop 'match on street', because -- except for exact matches 
(already accessible via postal code) -- the number and unit and often the 
postal will have to be changed as well. Maybe it saves you entering the city, 
but existing city input can already be short-cutted from its own dropdown 
anyway.

-- Jim