[Top][All Lists]

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

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

From: Karsten Hilbert
Subject: Re: [Gnumed-devel] type of search pattern for demographics
Date: Sun, 22 Aug 2004 21:58:16 +0200
User-agent: Mutt/

> For the case of apostrophe, I expect the Irish O' and French d' may 
> be commonest. It is hard to know whether office staff and doctors 
> would reliably enter the apostrophe or whether they might (though I 
> doubt) use a quotation (") or, for those with much font knowledge and 
> keyboard savvy, a curly apostrophe.
I would just replace them with a "." and do a regex search.
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.

> "Al *" and Al-* (Arabic)
Of course, didn't even think of that.

Also just Al*...

> Au and Au- (Oriental e.g. Au-Yeung)
Ah ! Something to learn every day...

> You have already brought up the umlaut and then of course there are 
> the french accents acute, grave and circumflex (sorry Dominique, I 
> forget how to spell the french forms!).
Those we take care of already.

> even correct spelling is carried through (e.g. in the printing of 
> plastic cards).
Sure enough I have recollections of exactly that when Germany
first introduced plastic health care cards. Things have
improved, though.

> You may see a patient for the first time in the 
> emergency room and take to the office information derived from the 
> plastic cards used by the hospital to emboss paper records or may 
> carry forward to your office a hospital error.
Can happen, sure. But first I'd worry about getting him OUT OF
MY EMERGENCY ROOM no matter what the name ;-)

> Sounds like Tim has been all through this.
I guess so. That's why I favour using his code in 2.0.

> 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

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

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

> - 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

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

> 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

> One question that I have is whether it is efficient to have all of 
> this factored into a search function,
it is currently

> or whether this will be slow 
> and 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.

> essentially becomes an "alternate name" it may be better served 
> through an "alias" function wherein we permit each patient to have 
> multiple names as can happen with marriage/divorce as well as in 
> other circumstances.
We already do. Any patient can have arbitrary amounts of
names. Only one of them can be marked active, however. IOW,
those marked incorrect-but-legal would be considered semi-active...

GPG key ID E4071346 @
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

reply via email to

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