gnumed-devel
[Top][All Lists]
Advanced

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

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


From: J Busser
Subject: Re: [Gnumed-devel] type of search pattern for demographics
Date: Mon, 23 Aug 2004 07:35:49 -0700

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?




reply via email to

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