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

[Karsten Hilbert]

> Ok, am up to undertanding the actual search logic. I think your logic is
> currently overkill, however:
Note how it first tries to get away with a "simple" query.

cPatientSearcher_SQL.__make_simple_query()

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

If that doesn't produce any queries it starts to interpret the
input. Note that you can write your own query generators and
just plug them in.

> 1)commonest: I know patient well he  peter blackwell:
> 
> - I type in  pe bl <enter> or bl,pe
Both work and are pretty much the first queries that are
generated.


>       if > 1 pe bl up pops list and I choose, else single result
>  (though with experience if this is the case with him I'd type pet bla to get
> a single result)
Same here and works.

> 2) next: remember firstname, not whole of second
> 
> - I type peter b > list > recognise surname
that's how it works

> 3) know his name is peter, cannot remember any surname
> 
> - I type ,peter, up comes list of all the peters
This isn't currently hardcoded as meaning firstname only but
it *will* produce the peters you are looking for.

It does support it now :-)


> In any scenario the query is something like:
> 
> Select * from patients where 'firstname like 'pe*' and lastname like 'bl*',
> order by id, surname, firstname, street, suburb, postcode, dob.
Same here. Only in more exotic cases do we produce more complex
queries. We do allow for case sensitive/insensitive searching
and account for umlauts.

We also only retrieve additional data if more than one patient
is found. That may be a mistake, however, performance-wise.

IMO ordering by "id" first isn't that clever.

> -> list -> pick one.
Same here.


> Name is plonked in top bar and under the hood the datbase is queried for
> all the clinical records for a patient with the unique Id from this query.
Exactly the same here.

> Now I can here your objections.
I am interested.

> I cannot however think of ANY situations
> where I have ever had to do an instring search of surname or lastname,
We don't do any unless non-INstring searches don't produce
results.

> So question: How come you just get the patients Id:
Because I have no idea what the caller wants to do with the
results. gmPatientSearcher_SQL.get_patient_ids() assumes
nothing about the caller. That's why it is named
get_patient_IDs(). Anyone is free to write
get_patient_briefs() and plug that into gmPatientSelector as
appropriate.

> ids = self.pat_searcher.get_patient_ids(curr_search_term), which yields 8 and
> 9 and will force  you to do another query when the result is picked -
> whearase you could get all the basic info in one hit, as you are, even in a
> huge hospital with thousands of beds only going to be getting a small number
> of similar names anyway.
Sure, write a get_patient_briefs() and plug it into
gmPatientSelector.

> In any case, you most often will not be able to
> identify the patient by firsname, surname and DOB, moreoften we use the
> suburb , and in fact where in doubt one usually asks the patient 'Do you live
> in Market st Cooks Hill, or 'do you live in dudley etc.
That doesn't mean the query conditions should be any different, just
what is returned from the queries should usefully be more.

> As an idea we could use that little button next to the search box to pop up a
> little list of how to search options eg
Or for allowing to select "search term interpreters" eg.
query generators.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346