[TRUNK-3048] When searching for patients by name, exact matches should be shown first Created: 2012-02-05  Updated: 2012-03-07  Resolved: 2012-03-06

Status: Closed
Project: OpenMRS Core
Component/s: None
Affects Version/s: OpenMRS 1.8.3
Fix Version/s: OpenMRS 1.8.4, OpenMRS 1.9.0, Feb 2012 Bug Fixing Sprint

Type: Bug Priority: Should
Reporter: James Arbaugh Assignee: Wyclif Luyima
Resolution: Fixed Votes: 3
Labels: exact, patient, results, search
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Complexity: Medium
Ben Wolfe, Daniel Kayiwa, Darius Jazayeri, Ellen Ball, James Arbaugh, Wyclif Luyima


When searching for Franchard Charles from the find/create patient screen, it says...
Minimal patients returned. Results for: fran char

It then includes lots of partial matches. Eventually, I find Franchard Charles on the 10th page of search results. It should show exact matches first, and then show other potential matches afterwards. This bug was introduced in OpenMRS 1.8. It continues to be problematic with OpenMRS Version: 1.8.3 Build 24510.

Comment by Wyclif Luyima [ 2012-02-06 ]

I actually don't know why we have this feature i.e if there are few hits for 'xxx' then search against 'xx', is it really needed?

Comment by James Arbaugh [ 2012-02-06 ]

I suppose it could help with misspellings, but we should search for exact matches before we go searching for other partial matches.

Comment by Darius Jazayeri [ 2012-02-06 ]

I've always hated this feature. I assume it was something AMPATH wanted (or at least Burke and Ben thought AMPATH wanted) back in the 1.0 days.

So my vote would be for getting rid of this.

Ideally we'd observe some data clerks at work, and see if they actually use this feature, or whether they'd be fine just pressing backspace a few times if their search doesn't find any hits.

James, how do your data clerks work? Do they use this feature?

Comment by James Arbaugh [ 2012-02-06 ]

Most of the time we search with the HAS Identifier. But when searching by name, I liked the way it used to be; if it didn't find exact matches, then it went looking for partial matches.

Comment by Ben Wolfe [ 2012-02-14 ]

Yes, this was supposed to be helpful to entry clerks that don't know how to search correctly.

I'd be fine changing this to "zero results found, here are more partial matches", instead of "minimal". This would eliminate the problem James states.

Or, as James initially suggested, show the "minimal" ones before the other partial ones. Either solution is fine with me.

Comment by Wyclif Luyima [ 2012-02-28 ]

While working on this, i have noticed that with paging in the new widgets, this actually causes bugs where some hits get missed out, my view is we either get rid of this feature or only do the partial search when there are no results at all.

Comment by Darius Jazayeri [ 2012-02-28 ]

How about we make it so that when you do a search:

  • If there are any results, we just show those. Even if there's just 1 results, we do not do another search.
  • Only if there are zero results, and the query string can be shortened, we do another search:
    • flash a message saying what Ben says two comments ago
    • change the query string shown in the search field, and fire the search again
      • thus we're not trying to merge exact + partial results into a single paged list, but rather we're just doing another search
    • (at this point if we get zero results again, the search string can't be shortened, so we won't recurse)
Comment by Wyclif Luyima [ 2012-02-28 ]

Sounds fine to me, as long triggering a new search is not something done by the core widget but just a custom behavior to be performed by a specific one.

Comment by Darius Jazayeri [ 2012-02-28 ]

I was even thinking that could be a custom behavior in the find patient page.

Comment by Wyclif Luyima [ 2012-02-28 ]

Actually this behavior is in the DWRPatientService

Comment by Wyclif Luyima [ 2012-02-28 ]

committed fix in rev:26163 and back ported in rev:26164

Comment by Wyclif Luyima [ 2012-02-29 ]

We should back port this to 1.8.x

Comment by Ben Wolfe [ 2012-03-06 ]

Looks good to me. Go ahead and backport to 1.8.x and then you can close.

Comment by Wyclif Luyima [ 2012-03-06 ]

back ported to 1.8.x in rev:26328

Comment by Ben Wolfe [ 2012-03-06 ]

Be sure you update the fixVersion whenever closing a ticket.

Generated at Wed Jan 23 00:42:39 UTC 2019 using JIRA 7.5.1#75006-sha1:7df2574a6cc842da727f00de4c5ce9ac07701368.