appointment scheduling module,

jecihjoy · March 14, 2019, 11:22am

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

jecihjoy · March 18, 2019, 7:48am

does this module allow saving of appointments through an encounter object

dkayiwa · March 18, 2019, 8:56pm

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

jecihjoy · March 18, 2019, 9:54pm

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 https://github.com/openmrs/openmrs-core/blob/master/api/src/main/java/org/openmrs/Encounter.java ensures that the order placed is saved whenever an encounter is being saved

extending the Enconters class in the appointment module like this https://pastebin.com/jNaGeKEb would help achieve saving of appointments through an encounter payload

jecihjoy · March 19, 2019, 6:30am

does the module support this yet?

jecihjoy · March 19, 2019, 6:30am

does the module support this yet

jdick · March 19, 2019, 3:42pm

@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?

mogoodrich · March 19, 2019, 4:29pm

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

jdick · March 19, 2019, 5:11pm

Thanks Mark! This is very good to know.

jecihjoy · March 20, 2019, 9:28am

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

jecihjoy · March 20, 2019, 9:37am

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

mogoodrich · March 20, 2019, 12:43pm

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):

https://wiki.openmrs.org/display/docs/Appointment+Scheduling+Module

jecihjoy · March 21, 2019, 11:51am

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)?

mogoodrich · March 21, 2019, 12:37pm

@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.

github.com

PIH/openmrs-module-mirebalais/blob/master/api/src/main/java/org/openmrs/module/mirebalais/task/MarkAppointmentsAsMissedOrCompletedTask.java

package org.openmrs.module.mirebalais.task;

import org.joda.time.DateTime;
import org.openmrs.api.context.Context;
import org.openmrs.module.appointmentscheduling.Appointment;
import org.openmrs.module.appointmentscheduling.api.AppointmentService;
import org.openmrs.module.emrapi.adt.AdtService;
import org.openmrs.scheduler.tasks.AbstractTask;

import java.util.Arrays;
import java.util.Date;

/**
 * Custom task to update appointment statuses; looks at all the appointments that happened the previous day or earlier and
 * 1) sets any with a StatusType of SCHEDULED to MISSED, and 2) sets any with a StatusType of ACTIVE to COMPLETED *if* that appointment
 * has a visit with one or more consult encounters associated with it
 */
public class MarkAppointmentsAsMissedOrCompletedTask extends AbstractTask {

    @Override

This file has been truncated. show original

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

jecihjoy · March 21, 2019, 6:40pm

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

mogoodrich · March 21, 2019, 7:04pm

@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

jecihjoy · March 22, 2019, 11:59am

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

We add the ability of creating multiple appointment block through a single REST call
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.

mogoodrich · March 22, 2019, 1:24pm

@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

jecihjoy · March 22, 2019, 3:04pm

This logic is getting deeper than it looks, I have another suggestion Instead of creating future appointment blocks:

We create a table location_availability_table indicating a location and its availability i.e start-date and end-date etc We give the user a calendar-like UI where he/she will be indicating the appointment date, after choosing the appointment date and the appointment location the user then sends the request to the backend

On the backend, we get the user request and process it as follows

query to check if their is a time-slot for that location for that date, if there is we return it and then append the time-slot to the appointment the user created and save it
If that time-slot doesn’t exist, we create the appointment block with the date and location the user selected using the start-time and end-time as indicated here on the location_availability_table, this will automatically create the time-slot for that block, we then return the time-slot and append it to the appointment the user created and save it

This will help us avoid having to create future blocks and time-slots which might never be used.

I would like to here what are your opinions on this regards

mogoodrich · March 25, 2019, 1:57pm

@jecihjoy I don’t 100% understand what you are suggesting, but it generally seems to be adding complications that aren’t necessary?

I think it’s fine to create time slots and appointment blocks that are never used… if it is a legitimate time that an appointment could be scheduled, the correct way to represent this is with an appointment block.

We just need some way to handle the manipulations of appointment blocks in bulk. I don’t know if this means it would be good to create something like an “appointment_block_group” that that makes it easier to manipulate blocks as a group… or perhaps we don’t need any more data module elements, but the UI could be smart enough if you try to delete, say, and appointment block on a Monday and it sees that future Monday’s have the same schedule, it asks if you want to delete just the single block or all the repeating ones?

Take care, Mark