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

[J Busser]

At 9:58 PM +0200 8/22/04, Karsten Hilbert wrote:
>  > For the case of apostrophe
> I would just replace them with a "." and do a regex search.

Does "replace" mean that it is in one's *search criteria*
that you suggest a "." be input and what does this do / how
does it work?

> Same with spaces, I suppose. Problem with spaces is that we
> don't know whether they separate truly separate name parts,
> eg. first from lastname, or just some admonition.

... although do we not input/store these in separate fields?

>  > umlaut and... the french accents acute, grave and circumflex
> Those we take care of already.

Is it regex that achieves this? Is the current state of gnumed
(when one inputs into the search box) a regex search?

>  > There may be others but maybe it is not necessary to catalog every
> >  possible occurrence?
> It would make for a nice regression test database ...  Very
> helpful.

Meaning we should retain the examples from this thread and
have people add to them?

> [current state]
> >  - disregard case (iLike?)
> No. *~

Does this mean "for now, one must type *~ "
and what does this do?

>  > - disregard accents (plain letters would need to be substituted for
> >  accented ones)
> yes

regex?

>  > - disregard spaces (drop them; would cover  two and three part surnames)
> not done yet, but not the correct approach for many-part
> names, rather for van/van der/de etc.
>
> will do

currently supported or will do in future?
needs road-mapping?

>  > - disregard punctuation (e.g. apostrophes and hyphens)
> will do

ditto?

>  > We could in addition optionally offer soundex searching per the url
> >  given by Syan which specifies dropping to vowels in order to extend
> >  the matches, this would cover the van/von and also the Mc/Mac
> >  challenge.
> which unfortunately only works for English names

but still useful?

>  if it would be faster, at the time of creating or editing a
>  > patient name, for Gnumed to store a converted form of the names for
> >  search purposes.
> that's another idea worth considering, actually
>
> >  Surely it is faster to search a key or index file
> >  than it is to have to locate on the physical hard drive every name in
> >  order to evaluate? If the user were permitted to see how the name is
> >  proposed to be converted and stored for search purposes, people might
> >  wish to edit it to capture the misspelling used by official agencies
> >  or insurers in dealing with the patients (although if this
> For that I'd actually even suggest adding a flag
> incorrect-but-legal to arbitrary name rows.

is a decision required on the above and/or needs it go on a to-do list?