Patient queues in Bahmni currently allow searches only by patient id and name. Other columns being shown in the listing queue cannot be searched for and this becomes hard when the queue sizes are long and only a particular set of patients are to be viewed. Allowing search by all visible columns on a patient listing queues will help to narrow down to a patient or a set of patients.
Sounds like a possible work item for the core team.
Thoughts? @darius @angshuonline @arjun @shruthipitta @binduak @pkanchankar
Yes. This has been there for some time and I have preached for usage of Lucene for patient search for quite some time. (As recently as last week) However doing this using Lucene is kinda tricky because Lucence will not allow cross joining document types.
- Doing it over patient identifiers and attributes is easy because its just one doc that you have to search.
- If you want to search patients with open visits for example - this will require you to integrate with visit start and close API calls and updating another attribute on the patient document in the index.
But very doable overall.
@psaxena can you elaborate a bit more what’s the real world usecase for having advanced search exactly at that place? Why does a user not know id or name of the patient whose record she is going to read / write? Some bulk update scenario? Can a report work or
Can a search on a separate app/browser tab serve the purpose?
The reason i say so is I am being more inclined towards this approach
- at all places have search very simple and barebones - i.e. by id and name (even name recently caused performance troubles in appointment search and we had to add configurability of implementation choosing not to search by name). The simple search would cost less in terms of code and performance issues, etc.
- Have an advanced search at one separate place, say one section in registration or another dedicated app which supports searching by wildest things - name, address, person_attributes, visit status, visit type, visit date, diagnosis, appointment, orders, etc ). Could be a very dynamic search which at runtime populates search criteria based on what has been configured at a particular implementation. With this advanced search one can find the id if not known.
I could be missing a real world scenario which absolutely demands tight integration. Please feel free to point so. In that case we should explore the advanced search as a widget option.
In our implementations we have custom program queues that we use to segregate patients. In these queue we have a lot of columns like date of arrival, speciality, surgeon name, date of appointment etc.
it would be easier to be able to search by date of appointment or date of arrival or even sometimes filter patients by their speciality to be able to enter data.
@arjun The search columns are configurable. You can specify on what columns you want the search to be enabled on. You can keep it simple by only adding id. This will not add to any performance issues as the filtering is done dynamically in the frontend.
We would also like to be able to search by visit start date in the registration screen, and have a way to limit results to the current location.