Recurring Appointments in Appointment Module

Software Bahmni
1

We are planning to build a functionality to enable recurring appointments, just like in Google Calendar. We would appreciate feedback and inputs on the same.

More details available in this word doc: https://docs.google.com/document/d/1ocgz6ROKmntc9G_BC07wnBUEwAYWLFmrCJT_kD8XLxM/edit

2
  1. Would there be any data model changes for this?
  2. How would you support ‘cancellation’ of all appointments in the series?
3

  1. We do not expect any changes to the data model. We are planning to use Appointment number to map the common appointments

  2. Cancellation of appointments will be supported, prompting the user to choose whether to cancel the appointment for only that day or for all recurring appointments, similar to Google Calendar

4

Awesome. Beware, the current appointment-number generation will need to be worked on. Also, try to keep this generation extensible. meaning, specific implementation should be able to override the default.

5

Noted, thanks!

6

You should think ideas over how to bring this extensibility. Lets say you have defined an interface like “AppointmentNumberGenerator”, you can think of multiple ways to do this. For Example

  1. have a “registerGenerator(AppointmentNumberGenerator)” method - this will allow others to wire up such an implementation from their modules.
  2. Or have a Groovy script based solution like Bahmni provides for Observations.

Do post back with what approach you thought of.

7

Hello, The approach for

Recurring appointments:

  • Have a “registerGenerator(AppointmentNumberGenerator)” method - this will allow others to wire up such an implementation from their modules.

  • Modify appointments creation api and add additional params- recurring type, number of occurrences and recurring days (for weekly only)

Same appointment number will be given for all recurring appointments

@pramidat @angshuonline @swathivarkala @binduak

8

for 
 "same appoint number will be given 
 ", try to provide an extensible way for that as well.

Generating an appointment number, may have other logics, and we should not assume that the same number will be valid. For example, if someone provides a generator which generates unique numbers but only for the day, then reassigning the same number may not work.

Maybe something like below?

public interface AppointmentNumberGenerator { 
   String create(Appointment apptTobeCreated, Optional<String> prevApptNumber);

}

9

Hi @angshuonline ,

The idea is to make a single API call which would create all the recurring appointments. We will need to have a common appointment number for all recurring appointments so that we can implement future functionalities like edit or cancel of that recurring appointment in entirety. A common appointment number is the logical link to group together all the recurring appointments. So, the extensibility will be provided to generate a custom appointment number, which will be common across all recurring appointments.

10

Ok. I understand that you are trying to use the “Appointment number” to tie all the appointments together. My point

  • is that generation of appointment number for a new one or reassign (group appointments) should be left to implementation. Therefore think of an injectable interface instance, which can customize both.
  • Lets not assume that same “Appointment Number” will be applicable.

Question:

  • the effected appointments (group) will be “voided”? or will you just edit the existing ones?
  • if you are not voiding and just editing the existing records, please add an entry in the appointment audit table “patient_appointment_audit” appropriately.
  • How have you thought of the web endpoint? for creation of series and also change for a series? For example, are you thinking of a different Web endpoint to accept list of “appointments”? Or will you modify the existing API to accept more information? What would you do for editing effected appointments?

For generation of appointment number, assuming, AppointmentsServiceImpl have a “AppointmentNumberGenerator” reference.

  • AppointmentsService Interface should have a “register(AppointmentNumberGenerator)”
  • AppointmentsServiceImpl should probably invoke “appointmentNumberGenerator.create(newappointment)” - e.x from here

(obviously this would be effected how you devise the interactions to the Web endpoint)

11

Hi @angshuonline,

As already mentioned we will make the appointment number generation logic pluggable, but it would be same for one give set of recurring appointments.

Answers:

  • the effected appointments (group) will be “voided”? or will you just edit the existing ones? --> It would behave in the same manner as the existing appointments with an additional option of cancelling one or all in that group of recurring appointments

  • if you are not voiding and just editing the existing records, please add an entry in the appointment audit table “patient_appointment_audit” appropriately. --> does this happen for appointments today?

  • How have you thought of the web endpoint? for creation of series and also change for a series? For example, are you thinking of a different Web endpoint to accept list of “appointments”? Or will you modify the existing API to accept more information? What would you do for editing effected appointments? --> We are thinking of reusing the existing endpoint and have few additional params (recurring type, number of occurrences and recurring days (for weekly only))

12

Hi,

In PAT call on 24th April (Bahmni PAT call 24th April 2019), the following approaches were spoken about:

  1. Adding a new column called ‘parent_appointment_id’ to ‘patient_appointment’ table. With this approach, we can get all past occurrences of an appointment, even when its recurrence pattern has been changed. It also becomes easier to cancel a set of appointments.

  2. Appointment Number: A unique appointment number for a specific set of ‘recurring appointments’. With this approach, we are not making the model clear enough for a developer to understand the logic out of the box, as we are overloading the appointment number with a responsibility it is not responsible for.

We would like to suggest the 1st approach, as it is independent and does not club with the logic of Appointment number generation. Giving the liberty to the system to use Appointment Number for just identifying an appointment.

@angshuonline @ramses @binduak @sowmika

1 Like
13

Hi - sorry to jump in late - does Bahmni use the OpenMRS Appt Module in your backend? At AMPATH (and I believe PIH too) we’re interested in the ability to create recurring appointment blocks that essentially match the very nice mockups you’ve presented.

I suspect canceling/editing a repeating appt would be similar to typical Calendar App - with ability to cancel or edit only that occurrence, or all future ones

cc: @mogoodrich @darius @jecihjoy @jdick

14

Bahmni uses it’s own module for appointments.

15

Hi, Attaching the document describing the way we are planning to functionally implement the edit functionality for recurring appointments. Two thumb rules are:

  • Edit this appointment
  • Edit this and following appointments

Also at any point of time we will not edit past appointments.

FUNCTIONALITY DETAILS - RECURRING APPOINTMENTS.pdf (90.6 KB)

@snehabagri @binduak @angshuonline @ramses @gschmidt @sravya @megkmcguire @abhinavpc @vmalini @mohitd

16

Seems good.

  • would like to see some mockups to visualize.
  • can you please specify what would be the API and model change for that
  • any change in appointment, hopefully you will be writing to the audit logs as well.
  • caution about editing: change of metadata (like speciality, type etc) - constitute cancellation and re-creation of appointments - are we respecting that.
  • keep in mind of future tractability as well. e.g. Notification - how would I notify someone that their previous appointment is now rescheduled?

Let me know if you want to discuss over slack or zoom

17

Hi,

Attaching the documents with model changes and how data gets modified on editing appointments.

Technical Details - Recurring Appointments.pdf (407.0 KB)

18

As per discussion with Angshu, we are fine with the functional approach for edit.

We need to finalize the database model and the API structure.

The data model should be designed keeping in mind that the Notifications can be implemented easily in future.

The API should follow FHIR model, but looks like FHIR does not provide it out of box and we need to extend it. Talk thread here - http://community.fhir.org/t/recurring-appointments/1321.

19

There is no recurring appointment concept in FHIR (but you can always use an extension to main contract, as suggested by FHIR guys).

Not to say, that I am suggesting that you stick to FHIR format, but you can take ideas from there.

You could just add another object as part of the “appointment-create-request” POST

Check: http://hl7.org/fhir/datatypes.html#timing

This should cover all aspects of your multiple occurances. You may not use the entire definition, but this should meet your needs

20

Sure, if we need to extend it can we do it like below just for the recurrence part of it:

    {
   
    "frequency" : "<positiveInt>",// no. of occurances
    "period" : "<decimal>", // repetition interval 
    "daysOfWeek" : ["<code>"],  // week days
    "endDate" :"", // date for the appointment to end
    "type":"" // DAY, MONTH or WEEK
 
}