Schedule list

This is a revival of the earlier ‘calendar’ work, based on fullcalendar.io component.

The component provides both a calendar view and a list view, and both will be supported, but the ‘list’ idea will be a default (during development) and keep the word ‘calendar’ away from the development process as a default, as it has some connotation and history that may add delays.

schedule naming

There are extant URLs using ‘shift’ in various ways - we’ll use ‘schedule’ as a main reference point in the URL to differentiate.

There is a ‘shift_list’ component which may serve as basis or reference point for new work.

Audience

First audience for this will be Andy/IV staff. Hospital manager support will come later.

Functionality

This will provide a way of grabbing all shifts from core, and filtering them based on shift status, assigned doctor, date range and hospital. Other filter/search functionalty may come out of this (filtering based on notes, for example).

API needs

• Get all shifts for a date range (may default to all to start if no range is passed)
• Create a shift
• View info about a shift
• Delete/hide/suspend shift (may require new ‘status’ logic)
• Assign shift to dr.
• Unassign shift from dr.
• Send notifications (email? SMS?) about shift to dr or hospital

Creating/updating/modification will need to ensure appropriate logical and business rules are documented and respected.

Tech notes

fullcalendar.io component is currently at a “release candidate” of their version 5, but initial testing showed basic setup (with vue) was problematic. We will do initial prototyping with the latest v4 and revist the v5 later.

vuejs support - we will continue with vue2 development at the moment. depending on the estimated time and effort, we may investigate the use of ‘vue-composition’ plugin for this effort. vue-composition is the existing plugin for vue2 which provides support for a vue3 transition, and vue3 release is anticipated in Q2 or Q3 in 2020.

fullcalendar notes:

https://fullcalendar.io/docs/v5/upgrading-from-v4

HOWEVER, you’ll need a build system that is able to handle CSS. for Webpack you’ll need css-loader.

Testing

Related, but separate from this, we will need a way to create a known quantity of repeatable shifts of various types/states, associated with known (or repeatable) users and sites. They key differentiation here will be the ability to create shifts between specific date ranges, to facilitate testing (primarily end user testing).

For testing purposes, these shifts should likely just remain in core, without any need to export/publish to wheniwork.

NOTE

The need for this MIGHT be reduced or eliminated by having a core/client-side way to create shifts in the first place. Creating dozens/hundreds of shifts by hand (repeatedly) might be difficult, the core concern of testing is to review behaviour of known states transitioning to new states. Core does not yet provide a way to create a new shift, so allowing for that will allow manual set up of specific custom scenarios.