Schedule blocking
Donate to this project
Development Project Status: Completed
Overview
Schedule blocking enables date and time ranges on schedules to be marked as unavailable.
This can be used to prevent appointments being made outside business hours or public holidays for example.
Currently OpenVPMS supports limited schedule blocking by defining a start and end time between which appointments can be created. There is no support to prevent scheduling between these times or on particular days.
Users currently work around this by creating dummy appointments.
This project will enable users to create blocks on a schedule, such that:
- a warning is displayed if an attempt is made to schedule an appointment where there is a block e.g. if the appointment is scheduled outside hours, or on a public holiday.
- schedules can be reserved so that appointments can only be created for customers with specific classifications e.g. it could be used to reserve boarding cages during holidays for valued customers
Block Creation
Schedule blocks will be created within the Workflow - Scheduling screen, via a new Block button.
A block:
- may optionally be named (e.g. Public Holiday, Team Meeting etc)
- must have have start and end dates
- may be recurring. It has the same recurrence options as appointments
- may have a Block Type. This provides
- a default name for the Block
- customer classifications that the Block is restricted to (e.g. Puppy Class, Valued Customer, Health Club Member)
- a colour for the Block when it is displayed
- may not be created if it overlaps an existing appointment
- may not be created if it overlaps an existing block
Block Display
Blocks are displayed as contiguous regions, with a name, if one has been specified, and the colour of the Block Type, if any.
If an appointment overlaps a block, it hides the portion of the block it overlaps.
Saving Appointments
When an appointment is saved, an additional check will be made to determine if it overlaps a block. If so, and the block has no Block Type with customer classifications, a warning will be displayed e.g.:
This appointment overlaps a schedule block (Public Holiday). Do you want to save it?
If the block has a Block Type with customer classifications, and the appointment is for a customer with one of those classifications, then no message is displayed.
If the block has a Block Type with customer classifications, and the appointment customer doesn't have any of those classifications, then an error message will be displayed e.g.:
This appointment overlaps a schedule block (Reserved for Puppy Class) and cannot be saved.
JIRA: OVPMS-1763
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
Re: Schedule blocking
This project has been re-specified so that it is now uses functionality from the Recurring Appointments project.
Re: Schedule blocking
A member has generously donated 26% of the funding required to get this project kick-started.Thanks very much! This is a feature we can all use so why not help get its development going?