appointment scheduling module,

(Jacinta Gichuhi) #1

can i save appointments in the appointments table through an encounter object @dkayiwa @mogoodrich @adamz

(Jacinta Gichuhi) #2

does this module allow saving of appointments through an encounter object

(Daniel Kayiwa) #3

Can you give more details regarding your use case? What exactly are you eventually trying to do?

(Jacinta Gichuhi) #4

the same way that’s possible to save orders through an encounter payload i would also like to achieve the same with appointments.

having appointments as a class property of encounters, would help achieve this

this ensures that the order placed is saved whenever an encounter is being saved

extending the Enconters class in the appointment module like this would help achieve saving of appointments through an encounter payload

(Jacinta Gichuhi) #5

does the module support this yet?

(Jacinta Gichuhi) #6

does the module support this yet

(Jonathan Dick) #7

@jecihjoy, an AMPATH dev, is working on this module.

Is anyone else using the appointment_scheduling module? @burke, @mseaton, @mogoodrich, @ssmusoke

If you are not using the appointment_scheduling module, are you using something else?

(Mark Goodrich) #8

We are using the Appointment Scheduling module, and to answer @jecihjoy 's question, this is not currently supported.

I’m reluctant to extend core OpenMRS domain objects in outside modules unless there’s a strong reason to… I also don’t really think that an Appointment is “subresource” of an Encounter. What’s your use case? Is there a reason you can’t just issue two REST calls?

Take care, Mark

(Jonathan Dick) #9

Thanks Mark! This is very good to know.

(Jacinta Gichuhi) #10

I wanted to enforce setting of the next appointment of a patient before a visit is completed, I however figured that I could instead use the visit property of the appointment class to achieve this. Your response was helpful, thank you

(Jacinta Gichuhi) #11

I’m trying to understand the relationship between appointment and appointment_status_history data models.

On the appointment table, the is no column for appointment_date, this implies that i’m getting the date from the appointment_status_history start_date column. If that is the case do we still need to make 2 REST calls while saving an appointment; for inserting entries to the appointment and appointment_status_history respectively or modifications needs to be done so that saving an appointment can be done as a ‘unit’ ??

@mogoodrich @dkayiwa please advice

(Mark Goodrich) #12

Appointment_status_history is an object used to track the status of an appointment, and is not related to the actual appointment time.

The actual appt time comes from the time slot and appt block… for a understanding of how the modelling works, I’d check out the OpenMRS University video here (this uses the old UI, but the underlying concepts between a time slot and an appointment block are still relevant):

(Jacinta Gichuhi) #13

I went through the video and it was really helpful

I however still don’t understand when data gets inserted to the Appointment_status_history table.

since it is keeping track of appointment statuses, for statuses such as scheduled, rescheduling, and cancelled, would you advice that updating this on the appointment table and inserting this status entries on the Appointment_status_history table to be one REST call (atomic)?

(Mark Goodrich) #14

@jecihjoy I took a little look into the Appointment modelling to refresh my memory on how Appointment Status works, and I understand your question/confusion now… I forget the details of our decision, but it looks like we (PIH) don’t use the Appointment Status History table (and I don’t think the Appointment Scheduling UI supports it at all). We do update the status of an appointment (see example in link below) but this just updates the status on the appt object/table itself, it doesn’t result in anything being added to the history table. If it became important to do this, I would suggest seeing if we could come up with a way to support this automatically… ie when you do “appointment.setStatus(status)” if there’s a change in status it would update the appointment status history table as well.

Also note… I had forgotten this, but in Appointment Scheduling UI we use the full model provided by the Appointment Scheduling module, but if I recall correctly, the UI configuration doesn’t support multiple “Time Slots” per an Appointment Block… when you create an Appointment Block it creates a single Time Slot that fills that whole block.

Take care, Mark

(Jacinta Gichuhi) #15

concerning your response on Time Slots and appointment block, I actually experimented that.

If I create a block with start_date 25/03/2019 and end_date 31/03/2019, that means i’ll only have one time-slot for 6 days. This is not okay because i’ll not be able to get a specific date of an appointment scheduled on that time-slot but instead i’ll only get a date range.

The idea of creating the time-slots automatically once an appnt-block is created is really great but it would be best if it allows users to specify the duration of the time-slot, this could be 60mins, 3hrs, 12hrs etc. The tables already allows that so this would be a modification of the code to take argument of time-slot duration

(Mark Goodrich) #16

@jecihjoy yes, the backend already supports time slots and I’d support adding them to the UI… I think the reason we didn’t when we built the Appointment Scheduling UI module was 1) we didn’t need them to start out with and 2) we didn’t want to make the UI too confusing. But if there’s a need, and we can add them in a non-confusing manner, I’m all in favor.

That being said, I’m not sure if time slots are relevant for you either, if you are only booking by the day… I would say that time slots are mainly helpful if you are trying to break a single day into multiple time periods… I don’t think that an appointment block that lasts multiple days makes sense, unless you are actually giving 24-hour care, because I think an appointment block is always evenly broken into timeslots, without a break… if you have a period where you aren’t scheduling appts (ie overnight) that would suggest having two separate appointment blocks.

I do think I see the issue you are trying to address though… we are as well… right now you have to set up the schedule for each block one-by-one, which is incredibly tedious. I don’t think the solution is multi-day blocks with time slots, but rather the ability to create an appointment block and then say “repeat this block every Monday until 12/1/2019” or something like that. But I’d be interested in more of your thoughts as well… it’s been a few years since I thought about this in any real detail.

Take care, Mark

(Jacinta Gichuhi) #17

hello, thank you for your response I now understand this clearly. As for our use case we can work with the time-slots the way they are now. As for the appointment blocks we need to add the repeat block functionality for a given period, this will avoid the tedious work of having to create them one-by-one manually

my suggestion to is

  1. We add the ability of creating multiple appointment block through a single REST call
  2. We create a service that handles the repeat of the appointment block as per user specified duration

In our case, we want to create multiple appointment blocks once, with start-date (2019-03-22 06:00:00) and end-date (2019-03-22 18:00:00). The first time we create them, we want them to repeat for 3 years. Then after three years they repeat again for the next 3 years and so on. To achieve this i’ll need like a function that returns for me all the calendar dates, I’ll then loop through the dates keeping the start-time and end-time constant while saving the appointment blocks to the database.

To standardize this to all module users I would suggest we give users the ability of select the repeat duration before posting the appointment blocks the first time.

I would like to hear your thoughts concerning this. regards.

(Mark Goodrich) #18

@jecihjoy in general, this sounds good… specifying a repeat duration when creating a block and having a REST call that could support this makes sense… the tricky part will come with editing and deleting the blocks… I don’t know if editing support needs to happen from “Phase 1” but we would need to be able to delete groups of blocks… if you create a repeating block for every Monday for a year and realize you did it in error, you wouldn’t want to have to delete every block one-by-one. But, on the other hand, you should be able to delete individual blocks from that group if you want to.

We we wondering if we wanted to create some sort of new domain element to store this repeating logic, so that when you delete a block it knows it is part of a repeating set and can ask if you want to delete the single block or the whole set. Thoughts?

Take care, Mark