Currently, the provider drop down list also shows some of the system providers (e.g. Billing System, Superman etc).
Ideally, we should be able to filter the provider list shown. To do this, one of the possible ways:
Define a provider attribute “available_for_appointments”. This need to be bundled along with the OMOD.
Filter using a query like:
select p.provider_id, p.name, from provider p where p.provider_id not in (select distinct pa.provider_id from provider_attribute pa join provider_attribute_type pat on pat.provider_attribute_type_id = pa.attribute_type_id where pat.name = 'available_for_appointment' and pa.value_reference = 'false')
Runtime, just mark any of the providers as “available_for_appointments” as false.
Yes, I was going to suggest using provider_attribute for this. I was going to suggest that you have to set the attribute to true to show the provider in the list and avoid doing a “not in” query, which might be expensive with a large provider table. But I agree it’s nicer if the default is to include the provider without requiring more work from the admin, and I guess the performance issue won’t be a big deal.
Also, can we follow the standard OpenMRS practice and not hardcode a specific name for this provider_attribute, but instead use the Metadata Mapping module to indicate it.
we are working on this approach suggested for our implementation. the following is the proposed solution:
In OpenMRS, a new provider attribute will be added called “Role”. For each provider that we want to see in appointment scheduling, the value of the attribute should be filled as “Provider for appointments”. There can be multiple roles for a provider and each one can be specified “|” separated in “Role” attribute.
A new attribute will be added to the provider management page, against each provider this attribute has to be checked for the provider to show up on the provider drop down.
It does not make sense to squash multiple meaningful pieces of data into a single “|”-separated attribute, because you’re naturally allowed to have multiple attributes for a single provider.
So you should have one attribute specifically for this functionality, like “Available for appointments” or “Supports appointments”.
Also, do not use the term “Role” because “Provider Role” has meaning in the domain and it will be introduced in a future OpenMRS verson: [TRUNK-4791] - OpenMRS Issues
Which provider management page is this? One in the OpenMRS admin UI? If so, that page is dynamic/generic, and should not be hardcoded to support a specific Bahmni attribute type. (But I guess that if you create a provider attribute type with datatype=boolean, this should automatically behave correctly.
I wanted to understand why we are using provider attribute and not roles and privileges of the provider? Isn’t the providers list is all providers who have a certain role or privilege (of providing the service in this case ) ?
We will add a new attribute “Available for appointments” of type boolean.
Users can go to provider management page in openmrs shown below and mark this attribute as “true” for providers available for booking appointments.
Good question. (And when I first read it I thought maybe Anghsu and I had overlooked a better solution.)
There are two reasons I would not use roles/privileges for this:
roles/privileges are tied to Users, not Providers. And there’s not a 1:1 relationship between those in OpenMRS (in particular there might be 0 or >1 user accounts associated with a provider’s person record).
roles/privileges are designed for access control of the logged-in user. E.g. superuser.hasPrivilege(“anything”) == true, and we wouldn’t want this.
One of the approach given in Rest API to get providers list based on provider attribute is to write a new search api handler.
Now that we are already done with the changes and also raised a PR, can we keep the code of filtering the providers in the frontend side and move writing of new API to backlog?
IMO, for a short term thats ok. I am assuming that the new SearchHandler is in the appointments OMOD.
You should create a card for Web Services Rest so that we remember to move it to the webservices rest.
Hi Angshu,
We haven’t created any search handler in appointments OMOD, We are getting all the providers using providers API and filtering them based on if attribute type ‘isAvailableForAppointments’ is true on the frontend side.
I wish you did that on the server side. I can imagine this being used in Bangladesh and they have to have thousands of providers but only 10-20 of them available for “appointments” based on the hospital they are in.
Doing this on the server side would have also meant,
opening up a possible extension to decide who are available. (now this is hardcoded in front end logic without a possibility of extension).
The default handler would have checked for “isAvailableForAppointments” attribute but if someone was overriding the default, then another implementation can use a different logic altogether.
At least the solution from the contributing team doesn’t close the door to a more robust implementation. @pramidat could you outline quickly the changes that would be needed to achieve @angshuonline’s suggested solution?
That would help get things on the core team’s radar, starting by creating JIRA tickets.