Enhancements on Bahmni Appointment Scheduling Module

Hello Team,

As discussed in the previous few talks, we are working on making Bahmni Appointments Module Compatible with OpenMRS.

We have got a few requirements from our client, and we wanted to discuss with the community on how to go about implementing them in the appointments module.


  • Ability to create an Appointment of different type based on the few conditions

    • For Specific Service type(s), the Appointment Type will always be SCHEDULED.
    • For other service types, it depends upon
      • If created by the provider itself the appointment status will be SCHEDULED.
      • If created by a receptionist, the appointment status will be PENDING.
  • Ability to create an Appointment with different Provider Response.

    • For Specific service type(s), the provider response will always be ACCEPTED.
    • For other service types, it depends upon
      • If created by the provider itself, the provider response will be ACCEPTED.
      • If created by a receptionist, the provider response will be AWAITING. It needs to be accepted/confirmed by the provider.
      • If created by the provider including other providers for the creator(one creating appointment) response will be ACCEPTED and for others, it will be AWAITING.
  • Ability to change the Provider Response for a Specific appointment on confirming.

We wanted to discuss these requirements with the community and find out the approach to implement these. We would like to implement these in such a way that these could be reused by other implementations.

Let us know your thoughts.

@angshuonline @snehabagri @binduak @swetha184 @vmalini @mksrom

CC: @mksd @rrameshbtech @sukreet @dirkg @ramses

1 Like

Hi Dubey,

It would we nice if you can also provide business use case that you are trying to solve here.

Can you provide a high level detail of what model changes we will need to make for these changes? Also how will this work for recurring Appointments?

Hello Sneha,

Here are the scenarios from our client:

  • A receptionist can create appointment with a specific provider. The provider needs to confirm his/her availability. The Appointment will not take place unless provider has confirmed.

  • A receptionist can create appointment with a specific provider. The provider can edit the appointment based on his/her availability. After the edit the confirmation from same provider is not needed.

  • A receptionist can create appointment with a specific provider. After confirming his/her availability the provider can add other providers as part of appointment. The appointment will take place regardless of other providers availability. The main provider(added by receptionist) is mandatory.

  • A provider can create appointment with multiple other providers along with himself/herself. No confirmation needed by creator. The Appointment will take place regardless of other providers availability. The main provider(creator) is mandatory.

  • A receptionist will not schedule an appointment with multiple providers. It will always happen as step 3 apart from Exception case.

Exception: A receptionist can schedule an appointment with multiple provider for “specific” services. These appointments will always take place, because it is guaranteed at-least one provider will be present.

Notes: The providers who are added by main provider to the appointment shouldn’t edit the appointment. We are thinking if this can be a training thing and not in system.

Let us know if there are any questions or suggestions.

CC: @angshuonline @binduak @vmalini @rrameshbtech @sukreet @rmkanda

Hello Sneha,

Please find the response to your questions.

Can you provide a high-level detail of what model changes we will need to make for these changes?

On a high level below are the model changes we are expecting:

  • A new field as Initial Appointment Status in AppointmentService. This will hold the Initial status for an Appointment Service by default. As of now, every Appointment starts as Scheduled. After this, we can choose what it should be.

  • Another additional field we were thinking of MarkSelfAppointmentsAsScheduled (Boolean). That would mean, if A provider is creating/editing an Appointment for himself/herself, it will always be Scheduled. The provider doesn’t need to confirm for his availability and it is already accepted.

  • A new Appointment Status Requested. It comes before Scheduled in the order of statuses.

Apart from above, we haven’t got any other model changes as of now. We are working on preparing a technical approach doc. We would share it with the community ASAP.

How will this work for recurring Appointments?

As of now, we have not got any specific requirements regarding recurring appointments. We are thinking that any changes(Accept/Edit) will be applied to all the Appointments if it is a recurring appointment.

Let us know your thoughts.

Hello Everyone,

Our team did an analysis of the requirements posted above and has come up with a technical approach in the form of a list of tasks.

Please find the link to the google document where we have put the approach. Let us know your thoughts/comments on the approach.

@snehabagri @angshuonline @binduak @swetha184 @vmalini @mksrom

CC: @mksd @rrameshbtech @sukreet @dirkg @ramses

A couple of questions

  • In case the provider never accepts, will the appointment go to rejected status? Or what will be the final status?
  • Technically with every edit by self will make the appointment go to scheduled status?
  • Does it mean, we will not allow multiple providers to be added until the first provider added confirms?
  • This is a process flow? Or will there be some code level restrictions for this?
  • Even if its . training thing, we need to make sure we do not break the system in case someone does update it.

How will the existing reset appointment status behaviour work with this change?

Will you have any changes in calendar and list view to indicate requested status?

Hello Sneha,

Below are the answers to the questions.

  • We can mark even a requested appointment as checked-in/missed even if provider forgot to accept the invite but is available for appointment. In case there was no action performed on an appointment at all, it will stay requested even if the date is passed. It cannot be considered as Missed/Completed automatically. (Please find the detailed reply in the doc).
  • Yes. The assumption is, providers would be aware of their availability while making an edit.
  • This is just the scenario in our use case. Though we will not be restricting the system for any such scenario. Anyone can add a number of people in the appointment.
  • Same as above.
  • Yes. The system will handle the edits. It’s just not advised.

A high-level idea is Reset Appointment Status will move the appointment back to the Initial Appointment Status for the service. The person Reseting the appointment would need to inform the providers that they will have to confirm again.

Note: We think that “reset appointment” would not be an action done frequently. It will be needed in certain situations and the privilege will be given to certain people only.

Edit: We have gone ahead with the status moving to Scheduled when the appointment gets reset.

Yes. Right now, we are thinking of adding a dotted border around the appointments on the calendar. Something like below.

In the last PAT call on 13 Nov we discussed this topic. There was a suggestion by @macmillant that the behavior of deciding the AppointmentStatus and ProviderResponse should be overridable for different implementations.

We have provided a hook on the client side, where we can write custom javascript and set the Status/ProviderResponse. We are adding another js file which will not be bundled as part of appointments.js and can be editted based on the need.

The appointments folder will have two js files

  • appointments.js => The bundled appointments module
  • appointmentStatusHandler.js => This will expose a function updateAppointmentStatusAndProviderResponse which will be invoked on the AppointmentsSave. It can be defined as below:
    function (appointmentForRequestData, allAppointmentDetails, providerForLoggedInUser) {
            appointmentForRequestData.status = 'Requested';    
            appointmentForRequestData.providers[0].response = 'AWAITING';

Let us know your thoughts. @snehabagri @angshuonline @binduak

CC: @rrameshbtech @sukreet @mksd