[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] Unintended GNUmed patient search result
From: |
Karsten Hilbert |
Subject: |
Re: [Gnumed-devel] Unintended GNUmed patient search result |
Date: |
Mon, 25 Feb 2013 16:16:57 +0100 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Fri, Feb 22, 2013 at 09:56:46PM +0000, Jim Busser wrote:
> I was searching for a patient
>
> last name = Kan
> first names = D
>
> so I searched
>
> Kan D
>
> which did not find the above patient, which is ok, because it turns out I had
> not yet created that patient.
>
> However, GNUmed did "find" (and auto-activated) a patient with
>
> last name = Andersson
> first names = Steve K
>
> see log output below. I gather the above patient was found because of a match
> of the search string with spaces removed
>
> kand
>
> inside the concatenated name parts
>
> stevekanderson
>
> which is not a request to change it. Mainly it is an
> observation that praxis recption and doctors may end up
> innocently activating patients who were the unintended
> result of a search. I suppose the only way to change this
> would be to present a dialog even for single matches, which
> some people may not desire.
Good catch. Actually, I should like to think that, indeed,
it would never be intentional to find
Steve K Anderson
when typing
"Kan D" (or "D Kan", for that matter)
so I modified all queries like ...
SELECT DISTINCT ON (id_identity)
vbp.*,
%s::text AS match_type
FROM
dem.v_basic_person vbp,
dem.names n
WHERE
vbp.pk_identity = n.id_identity
AND
... containing ...
lower(n.firstnames || n.lastnames) ~* lower(%s)
AND
lower(n.firstnames || n.lastnames) ~* lower(%s)
... to read ...
lower(n.firstnames || ' ' || n.lastnames) ~* lower(%s)
...
which still maintains the "find search term anywhere name"
idea but prevents matches crossing name part boundaries
(except if explicitely requested by, say, "Kan\sD").
Karsten
--
GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346