Scheduling In Oscar

On this page:
Setting Schedules
Caveats using the existing Scheduling GUI
Sample activity types


Scheduling in Oscar means defining the date(s) --- and optionally within those dates, the times and kinds of activity --- for which a clinician will be available. This information is used to draw a grid to facilitate the selection of dates and times for appointments.

Scheduling as implemented builds on up to three stages of preparation. Is is possible to skip the first two steps, and proceed directly to schedule any date, or any combinations of days of the week (in the range Sunday through Saturday) across a range of dates (and optionally, defining a schedule only as alternate-weeks).

Redefining any date(s) overwrites all prior schedule settings for those dates - but does leave the appointment information untouched :-).

The advantage of having set-up the first two steps enables groupings of activity type codes, called Template Code Types, to get attached to the schedule. This is achievable after the prior assembly of these codes into defined day-types, called Templates. Templates can be created and stored as Public (shareable), or can be created and stored so as to only be available under individual providers.

Scheduling offers a step in which can be specified, on any dates visible in the calendar, whether a person be confirmed as "available", or defined or redefined as "unavailable", on date(s) of interest. There seems no choice, in this dialog, to leave out a template selection... a template must be selected and (re)applied.

Holidays can be defined within Oscar, and are kept visible during scheduling to guide decisions for particular days. But they do not otherwise interact with the scheduling logic.

Appointments can be made directly within Oscar's GUI "Day" tab, or from a patient's master demographic record.

Appointments permit the direct updating of the "stage" of the current visit (the "in-office" flow), as well as direct jumping to access the patient's electronic summary or master demographic record, or to bill the visit.

For more information on appointments, see AppointmentsInOscar

Setting Schedules

These are managed under Administration tab, "Schedule Setting" should be Set Schedule(s)

"Selecting a provider" can be done without any templates having been set up. But as discussed above, any such scheduling would be limited to defining the days on which they will, or will not, normally be available, along with any specific-date clarifications as to confirmed-available or confirmed-unavailable. The activity codes would not be there to guide on planned activities. This step is therefore best deferred until after the desired template codes, and prototypical day-types, have been defined as below.

"Schedule templates", stored in the table scheduletemplate, are best understood to mean prototypical -- or stock -- "day types" each built up from portions of hours, or whole hours, each of which has been "coded" (see below) to mean any desired combination of
  • location, or
  • types, or
  • urgency of patient care; or
  • indirect care tasks; or
  • administrative work, or
  • any variety of other work.

The building-blocks for schedule templates are the "codes" stored in the table scheduletemplatecode, each of which are one-character designations that are co-definable as to
  • a default activity duration
  • whether to issue a confirmatory prompt "Are you sure you would like to book an appointment here?" when the associated time is clicked
  • optional colour-code preference

Schedule templates can be used for particular providers or, if defined to be 'Public", can be re-used among and for them. Such templates get saved into the table scheduletemplate using a special value for provider_no.

The "Schedule setting" function in the Administration tool is a per-provider tool that, subject to the caveats below, works as follows:
  • in its first screen is assembled the general rule to be applied to a set of dates:
    • requires the input of a range of dates that are to be (re)scheduled
    • any days of the week that are check-marked will have each corresponding dates written, or updated, into a scheduling table row
    • included with each date written (or updated) will be any reference to a "day type" template selected an applied onto any day(s) of the week
    • any days of the week that had not been check-marked will be ignored. If they did already exist in the scheduling table, they will get deleted.
  • in its second screen is assembled a calendar that supports the addition of explicit availability status, also a chance to make exceptions to the rule pending committment:
    • the calendar will display, within the rule's date range, the pending schedule
    • it will include any overlay of any holidays from the scheduleholidays table
    • it will display, for dates outside the date range of interest, any "day type" templates that had been previously saved for these other dates.
    • the calendar also displays any dates previously saved, or pending being saved, as "yes - provider confirmed available" (yellow) or "no - provider confirmed not available" (blue). For any dates where "yes" is chosen, there is an option to substitute a different "day type" template. There is also an option to delete a date's entry altogether.
  • results for the dates that were affected get stored, per provider per date, in the backend table scheduledate
  • all "rules" that had been assembled get stored per-provider in the table rschedule until that rule is manually deleted, making it easier to modify a rule across a range of dates should a provider's schedule need to change. A rule can be cloned to a different set of dates by changing the start date, whereas any changes applied without changing the start date, will treat the original rule as having been altered.
    • Programmer FYI: the detail within each rschedule record includes a start date, an end-date, one to seven involved days of the week and, for each of these days of the week, up to one "dayType" template, saved as a parseable string.

Holidays are simply defined one a one-off basis (no "recurrence") by the check-boxing of one or multiple specific calendar dates. Each acquires whatever "label" had been entered into the user interface's free-text box and the information is inserted as records into the table scheduleholiday. One or multiple of these can be deleted using the same interface. The oscardata.sql file is full of dates that would best be removed from the oscardata.sql file and might better be deployed as scheduleholidays2006_ca.sql, scheduleholidays2006_bc.sql etc

Caveats using the existing Scheduling GUI:

  1. For any one provider, each rschedule must maintain a unique start date. If one or more rschedules exist, one will always default into view with the others selectable from a popup.
  2. Changing the start date of the currently-displayed rschedule will result in the creation of a new schedule, whereas other changes that applied while preserving the start date will update the rschedule record.
  3. When creating a new schedule by taking an existing one and then modifying the start date: any dayTypes could have a "stale" on-screen display and would have to be recopied from the list in order to be remembered (stored). 1 The calendar "preview" may appear to affect days that are, in fact, outside of the date boundaries of the schedule that is being created.
  4. Holidays that had been defined in the administrative interface seem apparent only in the month-views, not in the day or week views.
  5. The "flip" grid fails to display a status as "unavailable" and so if any schedule template had been applied, those codes will remain apparent and able to be chosen from the flip view. Therefore it seems that any date for which the doctor will be unavailable ought not be signalled using the "status" option within the scheduler tool, but ought to instead have the particular date(s) (re)applied without a day-type template having been selected.

Draft schema for scheduling/booking:

"Hard" codes understood operationally to mean *"do not book me!!"*
V = Vacation protection
C = Conference protection
L = Leave protection (unless we use L for lunch)
X = other protection

Variable codes: Upper case when importance warrants
Aa = Admin protection/time
Ee = Education/Events
Rr = Research protection/time
Tt = Teaching protection/time
Mm = Meeting (unless D)
Dd = Dept or Division meeting
Hh = Hospital protection/time
Ii = Inpatient protection/time
Ww = Working time (uncategorized)

The idea is to differentiate when we feel we must be asked before anyone gets our time for other purposes. Upper-case would denote relatively firmly scheduled time, like on-call/post-call, and important events, including any we chair. Offsite activity might tend to be upper-case to limit disruptions. Our agreement might, by policy, be needed prior to the over-ride.

Lower-case could denote time that is less rigid. Lower-case could mean we don't insist to be asked, the staff can judge to put something in.

At times when we have new or temporary staff help, we can set all the variable codes "Are you sure", but when it is only regular staff around, we could leave the warning off.

Patient booking
o = outpatient clinic
s = supervisory review
p = private office
u = urgent cases only
f = fit-ins when other slots full (deploy as two, half-hours per day?)

Note these are all lower-case. These patient-booking slots, when clicked, would not issue warnings. Given temporary staff are unlikely to need to put in non-patient appointments for us, this could be nearly dummy-proof... if the worker gets a warning, they should not book whatever they were going to book, except after clearing with us.

Default slotting lengths
An activity code can be associated with a default slotting length that enables auto-completion of the end time. Vacation is commonl as whole days. Education events ("E") are commonly an hour in length. Are all other activity types so variable to permit no assumptions?

-- JamesBusser - 24 Jun 2006
Topic revision: 13 Mar 2010, JamesBusser
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback
Powered by Olark