I am starting this talk post to raise concern and need for a few functionalities from the backend. As per the designs and requirements for the Advanced Patient search, I need the following 2 APIs:
1. API support for advanced patient search on basis of different params.
Currently, we use the /ws/rest/v1/patient?q=<patient name/ identifier>. This endpoint returns the patients, filtered on the query, which is either a patient identifier, or a patient name. According to the designs for the Advanced patient search, I need the patients to be filtered on the following params:
Sex
Date/month/year of birth
Phone Number
Post code
Date of last visit
First name/ last name
Sorting the patients on the basis of Younger first/ Older first / First name(a-z and z-a)/ Last Name(a-z and z-a).
All the fields being optional meaning, it shouldn’t be compulsory to fill all the details (it is implied from the screenshot below)
The user, when opening the patient search should have a list of previous patient charts opened by the user, which needs to be stored on the backend. This can be cached on the frontend, but needs to be saved and fetched from the backend as per the requirements.
Please do update the thread on further discussions. This is a requirement from the app.
The use case is that there can be multiple patients by the same name, say John Smith. If the patient doesn’t remember his/her assigned ID, then it will be difficult to find the correct name.
In the practical reality, do you expect the match to have so many results that need filtering? I thought that by the time you finish typing the full name, the results are already filtered to just a few of them that can be displayed to quickly glance at and select the real one.
It’s not uncommon to have a patient with a common name for whom you don’t have their patient identifier and dozens of results come back when searching by name, so EMRs typically have an advanced search option that allows the user to specify additional details for the search, such as birthdate, address, or other demographics used during patient registration. The specific details most useful for advanced search likely vary based on implementation (e.g., name and date of birth may cover 99% of cases in one country, but be unreliable in another context). As another example, some implementations might collect mother’s name to help reliably identify patients; it would make sense to include this within advanced search in those cases.
@burke because we have never had such a feature in OpenMRS, do you have any idea how implementations have been dealing with those cases? Has it really been a pain point? If yes, then we definitely should do it. But if we are simply trying to align with other EMRs, then i do not see it as a priority. Given the scarce resources that we have, i would love to see them prioritised based on the real practical problems that our implementations face.
