Re: [Gnumed-devel] type of search pattern for demographics

[J Busser]

At 2:11 PM +0200 8/20/04, Karsten Hilbert wrote:
> This covers:
>
> - "digits": patient ID then DOB
> - "#digits": patient ID
> - "di g it s": DOB then patient ID
> - "d i git s" with "./-": DOB
> - "$ ...": DOB
> - "* ...": DOB

above, "patient ID" is a numeric key value rather than a chart or 
"health" number?
if so, how is it expected users will input "patient ID"s
i.e. from where will the user get the key in order to know what to type?
It is not as if patients will have a plastic card in their wallet:
"Here is my laminated Gnumed card with my Gnumed number"

In a locale where any one type of health insurance number dominates
(in my own locale owing to the public health system >95% of
patients have what we call a "Personal Health Number")
this would be immensely helpful to be searched but perhaps it will
reside in a non-demographic table among other types of health insurance
numbers and may be less manageable?

> We do allow for case sensitive/insensitive searching

Does postgres support index or key files and does gnumed use them?
Is searching faster by maintaining an index or key of 
upperCase(surname) and uppercase(givenNames)
and hen searching the index?

> and account for umlauts.

Is accounting for umlauts an i18N function?
For a search to "account for" umlauts, does this require that an 
unidexed search be done, using a function that is applied to the 
names and which as a result slows the search?

Other challenges with name searching that would be worth solving:

1) apostrophes
O"Malley
OMalley
D'Arcy
Darcy

2) spaces
de Groot
deGroot

- would people want the above accounted for?

3) sound-alikes
MacDonald
McDonald
deGroot
deGroet
daGroot

- dBASE and FoxBASE features a SOUNDEX() function that would have 
helped the above scenario, is it available to Postgres? Matches could 
be included automatically or only to expand a failed search.