Hi,
We are trying to leverage lucene search as documented on BAH-273 . I have looked at the OpenMRS-Core search API specifically this method and we would like to leverage this but unfortunately our use case requires a partial match on identifier search.
We would like something like this asked by @raff here Partial match on patient identifiers.
Optionally we would like to separate the methods for searching by identifier, by name and other attributes while still maintaining the default method.
I would love to here your thoughts on this. @raff @dkayiwa is a pull request viable ? 
findPatients behavior for names and attributes can be changed globally by the means of global properties to match anywhere, see here and here. Would such an approach work for you when implemented for patient identifiers?
I also support adding separate methods for searching by identifier, name and other attributes. PRs are always welcome.
Also, be careful. Supporting partial identifier search can both make it easier to find a patient and make it easier to select the incorrect patient.
If you implement partial identifier search, I’d suggest monitoring closely for an increased incidence of users mistakenly selecting the incorrect patient. This can be hard to detect, but at least be aware you might be increasing the likelihood of these types of errors.
Sure, however this is already the case in Bahmni right now. Just that it doesn’t leverage the Lucene effort that was put in the Core.
Do you feel uncomfortable exposing an API in OpenMRS Core that facilitates this?
Having the capability is fine, but I would favor not doing partial identifier search by default (i.e., it should be easier for a developer to not do partial identifier lookups than to enable them). In other words, having a method in the API and/or a global property that can be switched on is fine, but anyone using it would ideally understand as they opt in they might be unintentionally causing harm.
Ok great, yes that’s absolutely fine.
Great! Thanks. We will explore these options.
In OpenMRS Core directing patient searches to using Lucene is driven by a global setting that affects all searches. In Bahmni Core however this switch is currently made through using ad-hoc services implementations: search() or luceneSearch().
I guess the longer term goal would be to extend the Core API to handle more and more search fields via Lucene. Nevertheless there will always remain some leftover search to be done with Hibernate. See my example below in pseudo code:
patients = luceneSearch(identifier, name, personAttributes)
if otherSearchParams // intersecting with Hibernate
patients = hibernateSearch(patients.identifiers, otherSearchParams)
We could try to go as far as what the Lucene search allows (patient identifiers searches, name searches, person attributes searches), but the rest must be intersected with an Hibernate query to filter on the remaining search parameters that are not (yet) supported by Core’s Lucene API.
Does that make sense? @angshuonline, @arjun, @darius
Cc @ningosi
@mksd tangentiailly, you mentioned that Lucene searches are driven by a global setting… do you know where that setting is? I had searched global properties for it but didn’t search much farther than that.
(It’s relevant because I’d want to change ticket to only set “searchOnExactIdentifier” = true if Lucene was running, as opposed what version of OpenMRS is running)
Thanks and take care! Mark
Sorry @mogoodrich, I don’t know where I got that from. PatientService always uses Lucene (see here and here.) And findPatients(..) is the method that implements the Lucene search.
No worries… cool, that’s what I thought!
Take care, Mark