I want to bring up a concern regarding the advanced patient search functionality support from the backend. Currently the advanced patient search is present in the O3 frontend, but to work on the advanced patient search, it fetches all the search results for a certain query (id or name) and then do the further filtering.
This is a very heavy task for the frontend and will do make the application slower if the patients grows.
So I want to know about the implementation from the backend team.
Thanks!
This is implemented in the Community work, it’s not an EMR specific work to do.
This will surely take a toll on the app performance when the patient search will be running, and since searching is placed at various places (global, appointments, fast data entry, patient-lists, queues, etc.) it does become something to take care of.
I don’t know how to keep in order with the other practical problems but this is something that should atleast be on the list to be done.
I think we need product owners/domain experts (@burke@grace@jdick@jteich etc) to step in and speak to the original specs, so that we can understand how high on the priority list this is.
A good reference for us here is Bahmni that mixes in its patient search screen the usual one (search by name and/or ID) and the possibility to add a bunch of filters to the search, which is what I think we call here advanced search. For the latter a whole custom set of endpoints, plus service and DAO classes have been added to Bahmni Core - so this answers some of your questions @vasharma05. Basically the backend is taking care of it.
@dkayiwa I understand that you question and challenge @vasharma05 because he’s starting the thread and is the one coming with questions, but he is just the messenger trying to find his way through a roadmap laid out (by others) in front of him.
@mksd I haven’t seen the original specs (happy to look if needed) – but, as @burke suggested in the original Talk thread, it’s quite common for a name search to return a large number of matches, particularly in the many cultures where there are some very common names. When that happens, further filtering is required to get it down to a manageable level for the user.
Pretty much all EMRs that I can think of allow some advanced searching up-front: many allow birthdate and gender [although gender is more problematic these days], some allow address and post-code fields. Most do not process the search until the user indicates that they have finished entering these fields (typically by clicking a “Search” button).
I agree that for any system with a reasonably large patient database, it is likely to cause performance problems to bring down all name-matching patients and then to do advanced filtering in the frontend.
Thanks @jteich, I like the idea of expanding explicitly onto the advanced search (like many apps do out there) and have that search triggered only after the click of a button.
Assuming the designs support that, @vasharma05 do you have at your disposal the FHIR endpoints to actually search through the advanced search parameters?
Thanks @vasharma05. I would suggest that you attend the next TAC call or Platform call where this can be discussed, and work your way with @ibacher and @dkayiwa so that at least a backend roadmap exists. Whether it will be implemented sooner or later is another question.
So at the very least we should have a couple of backend tickets ready for work, does that make sense?
First the roadmap, and then we will see which resources can be assigned to it and when.
