Schedule blocking
Development Project Status: Seeking Funding
Forum: http://www.openvpms.org/forum/staff-time
Jira: http://jira.openvpms.org/jira/browse/OVPMS-1083
The initial idea for this very welcome suggestion came from Tim.
Tim suggested as part of fixing a bug discovered by Jocelyn, that we develop a blocking option for our schedules. Furthermore that this blocking option might have a recurring basis. The first step towards templating our schedules re availability. Gerrie suggested a more detailed model for building schedules and this development project was born!
After some discussion on the forums the project was appended to include the ability to create recurring appointments. This will allow customer based recurring appointment setup which will in turn allow non customer blocking appointments using the current "dummy" or “placeholder” customer approach.
Essentially the new appointment screen will include a new "recurring" tickbox which, when ticked, will display some recurring appointment fields.
The start time, end time, appointment type, customer, patient, reason, notes and clinician fields are already available in the new appointment screen and these will be replicated on every recurring appointment.
Revision 23/11/11
The project has been split into two parts.
Part 1 (This Project) - Creates the ability to "Block" or mark the schedule as busy. These examples were provided by Tim.
E.g.
- To specify a period of closure over 4 days, an act.calendarBusy could be created for the closure times with daily recurrence of 4 times
- To specify rostered time off each month, an act.calendarBusy act could be created for 9:00-17:00, for every last friday
- To specify christmas, an act.calendarBusy act could be created for times 12:00-23:59 with yearly recurrence of december 25
Part 2 - (Add Recurrence to Appointments Project) Extend the Recurrence functionality in Part 1 to regular consultations.
Revision 03/11/11
Using recurring appointments the users present felt that it would be possible to "block" the schedule easily.
The ability to create a recurring appointment will be specified as;
- Daily, Weekly, Monthly, Yearly
- The number of recurrences as Infinite or Defined (eg. Once, twice etc)
- When editing/deleting a recurring appointment it should be
- Visible in some way (eg. A symbol).
- Prompt the user if the change should occur for all instances.
Comments
Re: Schedule blocking
After some recent discussion on the forums this project will be rejuvenated to deal with the ability to create recurring appointments. This will allow customer based recurring appointment setup which will in turn allow non customer blocking appointments using the current "dummy" customer approach.
Essentially the new appointment screen will include a new "recurring" tickbox which, when ticked, will display some recurring appointment fields including:
Start Date
End Date
Days (check boxes for Sunday to Saturday with ability to quickly select all days)
The start time, end time, appointment type, customer, patient, reason, notes and clinician fields are already available in the new appointment screen and these will be replicated on every recurring appointment.
Once the recurring appointment is saved all the appointments will be created automatically.
If changes need to be made after the appointment is saved these will need to be backed out individually unless we save the recurring information and use this to allow deletion of all appointments ?
What should we do if a recirring appointment overlaps an existing appointment in a schedule that doesn't allow double bookings ? i.e not book that specific appointment or all appointments ?
Once the finer details are discussed and agreed I will create a JIRA and get some costings.
Cheers
Tony
Re: Schedule blocking
Hi all,
We think this would be a fantastic addition! It is such a hassle doing it manually.
I think it would be fine to have to manually make changes once the recurring appointment is saved, however if you made a mistake or made major changes to scheduling it would be nice to be able to manually delete the whole lot of recurring appointments.
If it overlaps an existing appointment couldn't it just come up with an error message the way it does now if you try and overlap existing appointments? The user would have to manually find the offending appointment but this is unlikely to be a big deal except for when it is first enable as usually this would be used to block out lunch times, etc a long way in advance before appointments were made (I hope I understood that question correctly).
Cheers,
Eleanor
Re: Schedule blocking
o It was suggested that this could be redefined to provide for recurring appointments.
o Using recurring appointments the users present felt that it would be possible to “block” the schedule easily.
o The ability to create a recurring appointment will be specified as;
o Daily, Weekly, Monthly, Yearly
o The number of recurrences as Infinite or Defined (eg. Once, twice etc)
o When editing/deleting a recurring appointment it should be
§ Visible in some way (eg. A symbol).
§ Prompt the user if the change should occur for all instances
Re: Schedule blocking
In terms of database and memory use, defining recurrence and blocking using appointments is very inefficient.
This can be better supported via the addition of two new archetypes, act.calendarSeries and act.calendarBusy.
The act.calendarBusy act would contain:
The act.calendarSeries act would contain:
E.g.
To determine if a particular time can be used for an appointment, the schedule would be checked to determine no appointment already exists. If not, then the act.calendarBusy acts and any associated act.calendarSeries for the schedule would check to determine schedule availabilty. If the period is not marked as busy, then the appointment can be made.
When creating busy schedules, existing appointments need to be consulted to ensure an appointment doesn't clash.
Re: Schedule blocking
Thanks Tim,
I think this would suit the requirements admirably.
Where would these acts be created?
Matt C
Re: Schedule blocking
I think they would be created and edited from within the scheduling workspace. As it is a less common task than adding a new appointment, it would be launched with a different button.
This button would only appear if the user has permission to create/edit act.calendarBusy/act.calendarSeries.
The creation of act.calendarSeries would occur within the editor for act.calendarBusy, by ticking a 'Recurrence' box. This would expand an editor showing the various recurrence options.
By default, only one act would be linked to an act.calendarSeries. This is the 'master'. Recurring busy acts would only be generated in memory, when displaying schedules.
When editing a busy act linked to a series, an option would be presented to edit the series (i.e. edit the master act), or edit the instance.
When editing an instance that doesn't physically exist in the series, the master act would be copied with the selected instance date and linked to the series (i.e, the series would now have two act.calendarBusy acts - the master, and the instance. Not sure yet if the instance should determine the properties of the recurring busy acts after it, or if they should still be derived from the master).
Once saved, changing recurrence would cause any other acts in the series to be removed.
In terms of performance, this should be faster than representing busy time by dummy appointments, as fewer acts need to be loaded from the database.
In terms of appearance, busy time could be represented as a different background colour. For contiguous blocks of time, the name of the busy time would only be displayed once (i.e, not in every cell).
If a user has permission to edit busy time, the cells would be selectable, otherwise they would not be selectable.
Re: Schedule blocking
Hey Tim,
One more question. An inferred functionality to be created from the description from the users meeting is that "normal" appointments would have the ability to be recurring.
If we adopt the approach above for "blocking" apppointments, this would mean that the recurring functionality for normal appointments would proabbly be specified in a different project?
Matt C
Re: Schedule blocking
Appointments could certainly use act.calendarSeries to be made recurring, although I'd do it as a separate project.
In order to make appointments recurring, they would use act.calendarSeries in the same manner.
There is a bit of work to do to add support for act.calendarSeries, so I'd do it as a separate project.
The following tasks are required to implement schedule blocking:
1. change appointment service to cache act.calendarBusy acts
2. change appointment service to cache act.calendarSeries acts
3. change scheduler to display busy time
4. add support for editing collections of participations to enable act.calendarBusy acts to be associated with multiple schedule
5. create editor for act.calendarBusy acts
6. add support to edit act.calendarSeries act within act.calendarBusy editor
7. add support to edit master act.calendarBusy act, or an instance in the series
8. add support to delete master act.calendarBusy act, including any other instances in the series
9. add support to delete an instance of an act.calendarBusy act in the series
10. change appointment save rules to ensure the appointment doesn't overlap busy time
There's approximately 2 weeks work there.
-Tim
Re: Schedule blocking
Thanks Tim,
- So 2 weeks for adding recurring capacity to appointments (what is that in hours? (2 x 38?)
- What about for the blocking feature?
Cheers,
Matt C
Re: Schedule blocking
80 hours to implement schedule blocking + 24 hours to implement recurring appointments.
The recurring appointment support requires the schedule blocking changes.
-Tim