Skip to content

shift incentives

current need for 2 pieces of data to be captured for a shift

  • paid travel
  • flexible hours

Third discussed was ‘promoted’ - this would be a flag that indicates a higher rate will be paid to a doctor.

initially the presence of the paid travel or flex hours incentives will be enough to show on the screens to users. As/when specific rules are needed to indicate constraints (time or distance caps, time range boundaries, etc) they can be encoded in metadata field for the specific shift.

May need a utility to change global constraint rule if an across the board change needs to be made.

Need to have a way to indicate if incentives are available for a hospital manager to flag when creating shift requests. Incentives may be global, but may need to be limited to specific hopsitals, geographies or customer accounts.

data

New tables

incentive table * id * full name * display info * code (short name) * enabled y/n * available_at - serialized list of hospitals, locations/regions or customers

shift_incentive * id * shift id * incentive id * enabled y/n * metadata

metadata will be incentive-specific info for this shift - if there are specific limits or caps to be enforced, for example

NOTE - see “incentives_parametric” for more detail

Null ‘available at’ would indicate globally available incentive. Presence of available at would be checked for hospitals, geo codes and/or customer ids.

tests

test 1

  1. as a hospital manager, create a shift with a paid travel incentive
  2. as an iv admin, review the shift and ensure paid travel is selected
  3. as iv admin, approve the shift
  4. as iv admin, view all shifts report and ensure paid travel flag is set
  5. as a dr, view available shifts via api - ensure shift in question has paid travel incentive info

test 2

  1. as a hospital manager, create a shift with a flex hours incentive
  2. as an iv admin, review the shift and ensure flex hours is selected
  3. as iv admin, approve the shift
  4. as iv admin, view all shifts report and ensure flex hours flag is set
  5. as a dr, view available shifts via api - ensure shift in question has flex hours incentive info

MARCH 2021 update / notes

We are planning an overhaul of incentive usage, but to hit a short term goal, a ‘promoted’ incentive will be added in the same style and pattern as the previous two incentives.

We will add a feature flag around ‘promoted incentive’ which will disable promoted incentive visibility to hospitals and doctors (no vet portal, or manager screens, etc) but still show ‘promoted’ incentive flag (just binary for now) on admit edit screens.

This is necessary to allow for a migration/reduction of position types and migrating their “promoted” state to a shift incentive, but needs to be done in stages.

April 2021 update / notes

table changes

incentives

  • ‘type’: string Type would be variations: ‘hospital_managed’ and ‘iv_managed’ - there may be more variations, but we can add more later.

  • ‘doctor_visibility’: boolean Is this incentive visible to doctors? This would indicate whether they should be notified if info on the incentive changed.

  • ‘Active between’ dates?

  • customer_id - incentive limited to single customer (‘banfield’)

  • location_id - incentive limited to single ‘geo/location’ (‘manhattan’)

  • soft-delete status - ability to manage shifts, including delete (soft only)

  • ‘active’ status - once ‘active’, no changes could be made (or not after first shift is in use with this incentive)

shift_incentives

  • ‘notes_to_doctor’ - if there are doctor-specific notes that need to be shown for this shift, put them here.

notes

  • ‘Hospital managed’ are incentives that show up to hospitals.

  • ‘IV managed’ are incentives that show up to IV (internal items).

  • If/when hospital_managed incentive data changed, hospital managers would be notified.

  • If/when iv_managed incentive data changed, IV internal list would be notified.

  • When sending notifications/reminders, when the recipient is a dr, only ‘dr_visibility:true’ incentive data is shared. LIKELY, for now, just a boolean concept, but.... the raw values may be shown in cards (what options are available, or chosen, etc).

  • Incentives should be able to be tied to specific customers, or… specific ‘location’ areas. (incentives for banfield, for example, or incentives specific to ‘manhattan’)

  • Need ability to define variables/ranges - these can be embedded in incentive.metadata, then the chosen values can be embedded in shift_incentives.metadata

REPORTING

How is reporting impacted by this?

Reports would need to show which incentives, and what type (iv/hospital). Existance of a shift_incentive - may still be enough to be just boolean in general reports?

April 17 discoveries

Incentives can/should have colors (just for icons? unsure) Incentives have different description text for hospitals vs doctors

April 27 update

Some initial review by Andy/Mikeala uncovered the notion of ‘multiple customers’ needing to be covered. Being able to say “incentive X is for customers A, B & C” (or geo/loc as well) was needed. Exclusion option - exclude from customer A, or PA_Philly, for example - was added.

Much of the include/exclude logic is in incentiveRepository, via getAvailableIncentivesForSite and getAvailableIncentivesForShift.

IncentiveRepositoryTest demonstrates basic usage of these methods.

Notion of ‘active’ - what does this mean? Intention was to just not show it in lists to actors, but there are also visibility flags.

If ‘inactive’, the incentive will not be used in calculations any longer, for any calculations which apply to financial data (payroll, invoice, etc).

Note: “Is incentive active or not? ‘Active’ incentive will be used in financial calculations (if necessary). ‘Inactive’ means the incentive data will not be used in financial calculations.”

This may actually require ‘effective dates’ (start/stop, etc) instead?

may 6 2021

Most of the work is ‘done’ although there will be more work done in future. Some notes to be aware of:

“active/inactive” presented some issues with earlier library methods, as there was an assumption to ‘get active’ in most methods. this was problematic because there are times when you need to show an incentive - because it’s been assigned to a shift - even if inactive. Need to bear this in mind.

Secondarily, Shift::renderIncentives method takes two params for visibility:

    public function renderIncentives($prefix = 'Incentives:', $emptyString = 'none',  $hospital = null, $doctor = null): string

If the hospital flag is ‘true’, incentives visible to hospitals will be included. If the hospital flag is ‘false’, incentives visible to hospitals will be excluded. If the hospital flag is null, a check for hospital visibility will be ignored altogether - we don’t care if the hospital visibility flag is true or false on the incentive definition.

When checking for incentives when emailing a doctor, we don’t really want to know or care if an incentive is explicitly on/off for a hospital - we only really care if an incentive is explicitly visible/invisible.

Same logic for the ‘doctor’ flag on renderIncentives.